Tags: appsignal/appsignal-ruby
Tags
## Added
- Add `config/appsignal.rb` config file support. When a `config/appsignal.rb` file is present in the app, the Ruby gem will automatically load it when `Appsignal.start` is called.
The `config/appsignal.rb` config file is a replacement for the `config/appsignal.yml` config file. When both files are present, only the `config/appsignal.rb` config file is loaded when the configuration file is automatically loaded by AppSignal when the configuration file is automatically loaded by AppSignal.
Example `config/appsignal.rb` config file:
```ruby
# config/appsignal.rb
Appsignal.configure do |config|
config.name = "My app name"
end
```
To configure different option values for environments in the `config/appsignal.rb` config file, use if-statements:
```ruby
# config/appsignal.rb
Appsignal.configure do |config|
config.name = "My app name"
if config.env == "production"
config.ignore_actions << "My production action"
end
if config.env == "staging"
config.ignore_actions << "My staging action"
end
end
```
- Add the `config/appsignal.rb` Ruby config file method to installer, `appsignal install`.
- Add `Appsignal.set_empty_params!` helper method. This helper method can be used to unset parameters on a transaction and to prevent the Appsignal instrumentation from adding parameters to a transaction.
Example usage:
```ruby
class PaymentsController < ApplicationController
def create
Appsignal.set_empty_params!
# Do things with sensitive parameters
end
end
```
When `Appsignal.add_params` is called afterward, the "empty parameters" state is cleared and any AppSignal instrumentation (if called afterward) will also add parameters again.
```ruby
# Example: Unset parameters when set
Appsignal.add_params("abc" => "def")
# Parameters: { "abc" => "def" }
Appsignal.set_empty_params!
# Parameters: {}
# Example: When AppSignal instrumentation sets parameters:
Appsignal.set_empty_params!
# Parameters: {}
# Pseudo example code:
Appsignal::Instrumentation::SomeLibrary.new.add_params("xyz" => "...")
# Parameters: {}
# Example: Set parameters after them being unset previously
Appsignal.set_empty_params!
# Parameters: {}
Appsignal.add_params("abc" => "def")
# Parameters: { "abc" => "def" }
```
- Add `Appsignal.configure` context `env?` helper method. Check if the loaded environment matches the given environment using the `.env?(:env_name)` helper.
Example:
```ruby
Appsignal.configure do |config|
# Symbols work as the argument
if config.env?(:production)
config.ignore_actions << "My production action"
end
# Strings also work as the argument
if config.env?("staging")
config.ignore_actions << "My staging action"
end
end
```
- Allow for default attributes to be given when initialising a `Logger` instance:
```ruby
order_logger = Appsignal::Logger.new("app", attributes: { order_id: 123 })
```
All log lines reported by this logger will contain the given attribute. Attributes given when reporting the log line will be merged with the default attributes for the logger, with those in the log line taking priority.
## Changed
- Read the Hanami Action name without metaprogramming in Hanami 2.2 and newer. This makes our instrumentation more stable whenever something changes in future Hanami releases.
- Ignore these Hanami errors by default:
- Hanami::Router::NotAllowedError (for example: sending a GET request to POST endpoint)
- Hanami::Router::NotFoundError
They are usually errors you don't want to be notified about, so we ignore them by default now.
Customize the `ignore_errors` config option to continue receiving these errors.
## Fixed
- Fix request parameter reporting for Hanami 2.2.
## Added
- Add `activate_if_environment` helper for `Appsignal.configure`. Avoid having to add conditionals to your configuration file and use the `activate_if_environment` helper to specify for which environments AppSignal should become active. AppSignal will automatically detect the environment and activate itself it the environment matches one of the listed environments.
```ruby
# Before
Appsignal.configure do |config|
config.active = Rails.env.production? || Rails.env.staging?
end
# After
Appsignal.configure do |config|
# Activate for one environment
config.activate_if_environment(:production)
# Activate for multiple environments
config.activate_if_environment(:production, :staging)
end
```
- Add a hostname AppSignal tag automatically, based on the OpenTelemetry `host.name` resource attribute. (Beta only)
- Add incident error count metric for enriched OpenTelemetry traces. (Beta only)
- Set the app revision config option for Scalingo deploys automatically. If the `CONTAINER_VERSION` system environment variable is present, it will use used to set the `revision` config option automatically. Overwrite it's value by configuring the `revision` config option for your application.
## Changed
- Ignore the Rails healthcheck endpoint (Rails::HealthController#show) by default for Rails apps.
If the `ignore_actions` option is set in the `config/appsignal.yml` file, the default is overwritten.
If the `APPSIGNAL_IGNORE_ACTIONS` environment variable is set, the default is overwritten.
When using the `Appsignal.configure` helper, add more actions to the default like so:
```ruby
# config/appsignal.rb
Appsignal.configure do |config|
# Add more actions to ignore
config.ignore_actions << "My action"
end
```
To overwrite the default using the `Appsignal.configure` helper, do either of the following:
```ruby
# config/appsignal.rb
Appsignal.configure do |config|
# Overwrite the default value, ignoring all actions ignored by default
config.ignore_actions = ["My action"]
# To only remove the healtcheck endpoint
config.ignore_actions.delete("Rails::HealthController#show")
end
```
## Fixed
- Fix an issue where the extension fails to build on ARM64 Linux.
## Changed - Add the `reported_by` tag to errors reported by the Rails error reporter so the source of the error is easier to identify. ## Fixed - Fix no AppSignal internal logs being logged from Capistrano tasks. - Report all the config options set via `Appsignal.config` in the DSL config source in the diagnose report. Previously, it would only report the options from the last time `Appsignal.configure` was called. - Fix 'no implicit conversion of Pathname into String' error when parsing backtrace lines of error causes in Rails apps.
## Added
- Add support for heartbeat check-ins.
Use the `Appsignal::CheckIn.heartbeat` method to send a single heartbeat check-in event from your application. This can be used, for example, in your application's main loop:
```ruby
loop do
Appsignal::CheckIn.heartbeat("job_processor")
process_job
end
```
Heartbeats are deduplicated and sent asynchronously, without blocking the current thread. Regardless of how often the `.heartbeat` method is called, at most one heartbeat with the same identifier will be sent every ten seconds.
Pass `continuous: true` as the second argument to send heartbeats continuously during the entire lifetime of the current process. This can be used, for example, after your application has finished its boot process:
```ruby
def main
start_app
Appsignal::CheckIn.heartbeat("my_app", continuous: true)
end
```
- Include the first backtrace line from error causes to show where each cause originated in the interface.
## Changed - Add the logger gem as a dependency. This fixes the deprecation warning on Ruby 3.3. - Do not report errors caused by `Errno::EPIPE` (broken pipe errors) when instrumenting response bodies, to avoid reporting errors that cannot be fixed by the application. - Normalize Rack and Rails `UploadedFile` objects. Instead of displaying the Ruby class name, it will now show object details like the filename and content type. ``` # Before #<Rack::Multipart::UploadedFile> #<ActionDispatch::Http::UploadedFile> # After #<Rack::Multipart::UploadedFile original_filename: "uploaded_file.txt", content_type: "text/plain"> #<ActionDispatch::Http::UploadedFile original_filename: "uploaded_file.txt", content_type: "text/plain"> ```
## Changed - Format the Date and Time objects in a human-friendly way. Previously, dates and times stored in sample data, like session data, would be shown as `#<Date>` and `#<Time>`. Now they will show as `#<Date: 2024-09-11>` and `#<Time: Time: 2024-09-12T13:14:15+02:00>` (UTC offset may be different for your time objects depending on the server setting). ## Removed - Do not include support files in the published versions. This reduces the gem package size.
PreviousNext