Jan 30, 2025
Organization admins can now manage notifiers at the organization level, simplifying application setup for organizations with multiple applications.
This feature is automatically enabled for new AppSignal customers and is being gradually rolled out to existing customers.
Existing customers can contact us to enable this feature and migrate their current notifiers. During migration, existing notifiers will be duplicated in the organization settings to ensure continuity, but no additional notifications will be sent as a result of this duplication.
You can learn more about organization-level notifier management in our documentation.
Add support for the Ownership gem, which is used to mark different segments of the application as owned by specific teams.
The AppSignal sample will be tagged with the given owner:
class OrdersController < ApplicationController owner :logistics # Transactions for requests handled by this controller will be tagged # in AppSignal with the "owner" tag set to "logistics" end
If several owners are set within the same transaction, the last owner will take precedence. If an error is reported in the transaction, the owner tag will be set to the owner that was set when the error was raised.
Set the ownership_set_namespace configuration option to true to also set the AppSignal sample's namespace to the owner. Note that doing so will cause existing performance and error incidents to be re-created with the new namespace.
Set the instrument_ownership configuration option to false to disable the integration with the Ownership gem.
SystemExit errors from our Rake integration.SignalException errors from our Rake integration.View the Ruby gem v4.3.3 changelog for more information.
View the AppSignal JavaScript react v1.0.29 changelog for more information.
View the AppSignal JavaScript stimulus v1.0.19 changelog for more information.
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.
INSERT INTO ... VALUES queries.View the Elixir package v2.13.3 changelog for more information.
INSERT INTO ... VALUES queries.View the Node.js package v3.5.5 changelog for more information.
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.INSERT INTO ... VALUES queries.View the Python package v1.4.1 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.
adduser dependency is declared as such on the Debian package.This fixes an issue in certain environments, such as in Ubuntu Noble container images, where the appsignal-agent user fails to be created during installation because the adduser and addgroup command-line utilities are not present by default.
Fix file ownership issue on stand-alone Debian packages. Ensure that the /etc/appsignal-agent.conf configuration file is owned by the appsignal-agent user.
Fix a performance issue when sanitising INSERT INTO ... VALUES queries.
This release can be installed through our standalone agent packages and as a Docker image.
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.
View the Elixir for Phoenix package v2.6.0 changelog for more information.
id on the incident attributes page.Allow custom backtrace sanitization.
Warning: This is an advanced feature meant for specific use cases. For most use cases, you should not need this functionality. If in doubt, leave
matchBacktracePathsunset.Using
matchBacktracePathswill cause public sourcemap detection to fail. If usingmatchBacktracePaths, use our private sourcemap API to upload sourcemaps to AppSignal.
Some applications, such as those running on Electron or React Native environments, emit backtrace lines containing paths relative to the device in which the application is running.
The unpredictability of these backtrace line paths interferes with the correct functioning of backtrace error grouping, and makes it impossible to upload sourcemaps for these files using our private sourcemap API, as it is not possible to know the expected path beforehand.
You can set the matchBacktracePaths configuration to a list of one or more regexes, which will be used to attempt to match the relevant section of the backtrace line path.
For example, suppose you have an Electron application, which your users install at unpredictable locations. Your backtrace line paths may look something like this, with the username changing for each installation:
/Users/${USERNAME}/Applications/CoolBeans.app/Contents/Resources/app/index.js
To ignore these parts of the path that are not predictable, you can configure AppSignal to ignore everything before the app folder as follows:
const appsignal = new AppSignal({ matchBacktracePaths: [ new RegExp("CoolBeans\\.app/Contents/Resources/(.*)$") ] })
If set, the matchBacktracePaths configuration option must contain a regular expression, or an array of one or more regular expressions, which attempt to match the whole backtrace line path. These regular expressions must have one or more match groups, such as (.*) in the example above, which attempt to match against the relevant segments of the backtrace line path.
AppSignal will attempt to match the whole backtrace line path against these regular expressions in order. If any of the regular expression matches and produces a match group, AppSignal will replace the path in the backtrace line with the matched segment.
Make sure your regular expressions provide unique and stable points of reference in the path, such as CoolBeans.app/Contents/Resources in the example above.
g global flag are used on ignoreErrors. Before this change, after successfully matching on an error to ignore, if the following error would also match the same regular expression, the regular expression would then fail to match it.View the @appsignal/javascript v1.5.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!