Appsignal::Logger#broadcast_to, would format again messages that have already been formatted by the broadcaster, causing the resulting message emitted by the logger to contain double newlines.View the Ruby gem v4.3.2 changelog for more information.
Add logger broadcasting. This change implements an alternative within Appsignal::Logger to ActiveSupport::BroadcastLogger, following the same interface. This enables a proper workaround to the issues with ActiveSupport::BroadcastLogger ((#49745, #51883)) when used alongside tagged logging.
For example, to use tagged logging both in logs emitted by the default Rails.logger and in logs sent to AppSignal, replace the Rails.logger with an AppSignal logger that broadcasts to the default Rails.logger:
appsignal_logger = Appsignal::Logger.new("app") appsignal_logger.broadcast_to(Rails.logger) Rails.logger = ActiveSupport::TaggedLogging.new(appsignal_logger)
Remove tagged logging support from Appsignal::Logger.
Tagged logging is still supported by wrapping an instance of Appsignal::Logger with ActiveSupport::TaggedLogging:
appsignal_logger = Appsignal::Logger.new("rails") tagged_logger = ActiveSupport::TaggedLogging.new(appsignal_logger) Rails.logger = tagged_logger
Removing this functionality allows for a workaround to issues within Rails (#49745, #51883), where using the broadcast logger to log to more than one tagged logger results in incorrect behaviour of the tagged logging methods, resulting in breakage throughout Rails' internals:
# We use the built-in request ID middleware as an example that triggers # the issue: Rails.config.log_tags = [:request_id] appsignal_logger = Appsignal::Logger.new("rails") tagged_logger = ActiveSupport::TaggedLogging.new(appsignal_logger) # This does not work correctly, because the default `Rails.logger` is a # broadcast logger that is already broadcasting to a tagged logger. # When asked to broadcast to a second tagged logger, the return value of # `Rails.logger.tagged { ... }` will be incorrect, in turn causing the # `RequestID` middleware, which uses it internally, to return broken # Rack responses. Rails.logger.broadcast_to(tagged_logger)
By reverting the changes to our logger so that it is no longer a tagged logger, we enable a workaround to this issue:
Rails.config.log_tags = [:request_id] appsignal_logger = Appsignal::Logger.new("rails") # This works correctly, because `appsignal_logger` is not a tagged logger. # Note that `appsignal_logger` will not have the `request_id` tags. Rails.logger.broadcast_to(appsignal_logger)
#silence implementation for Appsignal::Logger.View the Ruby gem v4.3.0 changelog for more information.
INSERT INTO ... VALUES queries.View the Ruby gem v4.3.1 changelog for more information.
ArgumentError error when using tagged logging in Rails 8.View the Ruby gem v4.2.3 changelog for more information.
Support Rails/ActiveSupport tagged logging. When tags are set in apps using Rails.logger.tagged { ... } or with the Rails.application.config.log_tags = [...] config option, these tags are now included in the collected log messages.
Rails.logger.tagged(["Tag 1", "Tag 2"]) { Rails.logger.info("My message") }
Reports this log message:
[Tag 1] [Tag 2] My message
Appsignal.stop is called.View the Ruby gem v4.2.2 changelog for more information.
View the Ruby gem v4.2.1 changelog for more information.
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:
# 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:
# 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:
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.
# 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:
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:
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.
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:
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.
View the Ruby gem v4.2.0 changelog for more information.
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.
# 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.
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:
# 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:
# 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
View the Ruby gem v4.1.3 changelog for more information.
View the Ruby gem v4.1.2 changelog for more information.
reported_by tag to errors reported by the Rails error reporter so the source of the error is easier to identify.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.View the Ruby gem v4.1.1 changelog for more information.
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:
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:
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.
View the Ruby gem v4.1.0 changelog for more information.
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">
View the Ruby gem v4.0.9 changelog for more information.
ThreadError from being raised on process exit when Appsignal.stop is called from a Signal.trap block, like when Puma shuts down in clustered mode.View the Ruby gem v4.0.8 changelog for more information.
#<Date> and #<Time>. Now they will show as #<Date: 2024-09-11> and #<Time: 2024-09-12T13:14:15+02:00> (UTC offset may be different for your time objects depending on the server setting).View the Ruby gem v4.0.7 changelog for more information.
arguments key for positional arguments and keyword_arguments for Ruby keyword arguments.View the Ruby gem v4.0.6 changelog for more information.
lowlevel_error reporter. This will report errors previously not caught by our instrumentation middleware.Log a warning when loader defaults are added after AppSignal has already been configured.
# Bad Appsignal.configure # or Appsignal.start Appsignal.load(:sinatra) # Good Appsignal.load(:sinatra) Appsignal.configure # or Appsignal.start
Rename the path and method transaction metadata to request_path and request_method to make it more clear what context this metadata is from. The path and method metadata will continue to be reported until the next major/minor version.
Internal change to how OpenTelemetry metrics are sent.
at_exit hook reporting no error on process exit when the process exits without an error.View the Ruby gem v4.0.5 changelog for more information.
Send check-ins concurrently. When calling Appsignal::CheckIn.cron, instead of blocking the current thread while the check-in events are sent, schedule them to be sent in a separate thread.
When shutting down your application manually, call Appsignal.stop to block until all scheduled check-ins have been sent.
SignalException errors from our at_exit error reporter.View the Ruby gem v4.0.4 changelog for more information.
Sidekiq::JobRetry::Handled and Sidekiq::JobRetry::Skip errors. These errors would be reported by our Rails error subscriber. These are an internal Sidekiq errors we do not need to report.Remove the app_path writer in the Appsignal.configure helper. This was deprecated in version 3.x. It is removed now in the next major version.
Use the root_path keyword argument in the Appsignal.configure helper (Appsignal.configure(:root_path => "...")) to change the AppSignal root path if necessary.
View the Ruby gem v4.0.3 changelog for more information.
Errno::EPIPE errors when instrumenting response bodies. We've noticed this error gets reported when the connection is broken between server and client. This happens in normal scenarios so we'll ignore this error in this scenario to avoid error reports from errors that cannot be resolved.View the Ruby gem v3.13.1 changelog for more information.
We've released version 4.0 of the AppSignal gem! Read all about it in the Ruby gem 4.0 blog post.
When upgrading, follow our guide for upgrading from Ruby gem 3 to 4.
Add an at_exit callback error reporter. By default, AppSignal will now report any unhandled errors that crash the process as long as Appsignal started beforehand.
require "appsignal" Appsignal.start raise "oh no!" # Will report the error StandardError "oh no!"
To disable this behavior, set the enable_at_exit_reporter config option to false.
Report errors from Rails runners. When a Rails runner reports an unhandled error, it will now report the error in the "runner" namespace.
Support adding multiple errors to a transaction.
Using the Appsignal.report_error helper, you can now report more than one error within the same transaction context, up to a maximum of ten errors per transaction. Each error will be reported as a separate sample in the AppSignal UI.
Before this change, using Appsignal.report_error or Appsignal.set_error helpers, adding a new error within the same transaction would overwrite the previous one.
Add a helper for parameters sample data to be unset. This is a private method until we stabilize it.
Change the default Rake task namespace to "rake". Previously, Rake tasks were reported in the "background" namespace.
Do not start AppSignal when the config file raises an error. Previously, the file source would be ignored.
Freeze the config after AppSignal has started. Prevent the config from being modified after AppSignal has started to avoid the expectation that modifying the config after starting AppSignal has any effect.
Do not start Appsignal multiple times if Appsignal.start is called more than once. The configuration can no longer be modified after AppSignal has started.
The transaction sample data is now merged by default. Previously, the sample data (except for tags) would be overwritten when a sample data helper was called.
# Old behavior Appsignal.set_params("param1" => "value") Appsignal.set_params("param2" => "value") # The parameters are: # { "param2" => "value" } # New behavior Appsignal.add_params("param1" => "value") Appsignal.add_params("param2" => "value") # The parameters are: # { "param1" => "value", "param2" => "value" }
New helpers have been added:
Appsignal.add_tagsAppsignal.add_paramsAppsignal.add_session_dataAppsignal.add_headersAppsignal.add_custom_dataThe old named helpers that start with set_ will still work. They will also use the new merging behavior.
Set the Rails config defaults for Appsignal.configure when used in a Rails initializer. Now when using Appsignal.configure in a Rails initializer, the Rails env and root path are set on the AppSignal config as default values and do not need to be manually set.
Global transaction metadata helpers now work inside the Appsignal.report_error and Appsignal.send_error callbacks. The transaction yield parameter will continue to work, but we recommend using the global Appsignal.set_* and Appsignal.add_* helpers.
# Before Appsignal.report_error(error) do |transaction| transaction.set_namespace("my namespace") transaction.set_action("my action") transaction.add_tags(:tag_a => "value", :tag_b => "value") # etc. end Appsignal.send_error(error) do |transaction| transaction.set_namespace("my namespace") transaction.set_action("my action") transaction.add_tags(:tag_a => "value", :tag_b => "value") # etc. end # After Appsignal.report_error(error) do Appsignal.set_namespace("my namespace") Appsignal.set_action("my action") Appsignal.add_tags(:tag_a => "value", :tag_b => "value") # etc. end Appsignal.send_error(error) do Appsignal.set_namespace("my namespace") Appsignal.set_action("my action") Appsignal.add_tags(:tag_a => "value", :tag_b => "value") # etc. end
Include the Rails app config in diagnose report. If AppSignal is configured in a Rails initializer, this config is now included in the diagnose report.
Include the config options from the loaders config defaults and the Appsignal.configure helper in diagnose report. The sources for config option values will include the loaders and Appsignal.configure helper in the output and the JSON report sent to our severs, when opted-in.
Calculate error rate by transactions with an error, not the number of errors on a transaction. This limits the error rate to a maximum of 100%.
Appsignal.listen_for_error helper. Use manual exception handling using rescue => error with the Appsignal.report_error helper instead.Appsignal::Transaction::FRONTEND constant. This was previously used for the built-in front-end integration, but this has been absent since version 3 of the Ruby gem.Appsignal.config= writer. Use the Appsignal.configure helper to configure AppSignal.Transaction.new method Transaction ID argument. The Transaction ID will always be automatically generated.View the Ruby gem v4.0.0 changelog for more information.
AppSignal offers a 30-day free trial, no credit card is required. All features are available in all plans. Start monitoring your application in just a few clicks!