Fixed

• Fix a performance issue when sanitising INSERT INTO ... VALUES queries.

View the Elixir package v2.13.3 changelog for more information.

Fixed

• Fix a performance issue when sanitising INSERT INTO ... VALUES queries.

View the Node.js package v3.5.5 changelog for more information.

Added

• 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.

Fixed

• Fix a performance issue when sanitising INSERT INTO ... VALUES queries.

View the Python package v1.4.1 changelog for more information.

Added

• 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:

  Ruby

  appsignal_logger = Appsignal::Logger.new("app")
  appsignal_logger.broadcast_to(Rails.logger)
  Rails.logger = ActiveSupport::TaggedLogging.new(appsignal_logger)

Removed

• Remove tagged logging support from Appsignal::Logger.

  Tagged logging is still supported by wrapping an instance of Appsignal::Logger with ActiveSupport::TaggedLogging:

  Ruby

  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:

  Ruby

  # 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:

  Ruby

  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)

Fixed

• Fix #silence implementation for Appsignal::Logger.

View the Ruby gem v4.3.0 changelog for more information.

Fixed

• Fix a performance issue when sanitising INSERT INTO ... VALUES queries.

View the Ruby gem v4.3.1 changelog for more information.

Fixed

• Fix an ArgumentError error when using tagged logging in Rails 8.

View the Ruby gem v4.2.3 changelog for more information.

Added

• 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.

  Ruby

  Rails.logger.tagged(["Tag 1", "Tag 2"]) { Rails.logger.info("My message") }

  Reports this log message:

  [Tag 1] [Tag 2] My message

Fixed

• Fix a thread safety issue where sending check-in events simultaneously from different threads would cause several check-in schedulers to be initialised internally. This could cause some of the scheduled check-in events to never be sent to AppSignal when Appsignal.stop is called.

View the Ruby gem v4.2.2 changelog for more information.

Changed

• Improve the way we show partial outages on the uptime monitor page.

Fixed

• Visual updates to the invitation pages.
• Fix long logbook notes breaking the layout.

Changed

• Minimize difference between Rack transaction duration and total child event durations.

View the Ruby gem v4.2.1 changelog for more information.

Added

• Instrument LiveComponent update events in the LiveView integration, in addition to the already instrumented mount events

View the Elixir for Phoenix package v2.6.0 changelog for more information.

Fixed

• Minor visual fix to address the truncation of id on the incident attributes page.
• We've made the "Change password" flow clearer and more explicit.

Added

• 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 matchBacktracePaths unset.

  Using matchBacktracePaths will cause public sourcemap detection to fail. If using matchBacktracePaths, 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:

  Shell

  /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:

  JavaScript

  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.

Fixed

• Fix an issue when regexes with the 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.

Fixed

• Allow Pino transport to be used as a transport. Before, our Pino transport could only be used as a destination:

  Node.js

  import pino from "pino";

  JavaScript

  import pino from "pino";
  import { Appsignal, AppsignalPinoTransport } from "@appsignal/nodejs";
   
  pino(
    AppsignalPinoTransport({
      client: Appsignal.client,
      group: "pino",
    }),
  );

  This meant it was not possible to log both to our transport and to another destination.

  Now, it is also possible to use it as a Pino transport, with the transport Pino config option or the pino.transport() function:

  JavaScript

  import pino from "pino";
   
  pino({
    transport: {
      target: "@appsignal/nodejs/pino",
      options: {
        group: "pino",
      },
    },
  });

  It is no longer necessary to pass the AppSignal client to the Pino transport. AppSignal must be active for the Pino transport to work.

  By enabling its use as a transport, it is now possible to use it alongside other transports:

  JavaScript

  pino({
    transport: {
      targets: [
        // Send logs to AppSignal...
        { target: "@appsignal/nodejs/pino" },
        // ... and to standard output!
        { target: "pino/file" },
      ],
    },
  });

View the Node.js package v3.5.4 changelog for more information.

Fix the logo image path for MS Teams workflows notifiers integration. We've added a way for you to verify webhooks that are being sent from our platform. In your Webhook notifier, you can find a token; this token can be used to verify the webhook by creating a sha256 hash:

sha256(token+message)

This token can be verified against the X-Appsignal-Signature header. Fix a bug in the date picker that caused unnecessary whitespace.

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.

View the Ruby gem v4.2.0 changelog for more information.

Changed

• Fix an issue where objects given as tags or breadcrumb metadata would have their values modified in place.

View the AppSignal JavaScript javascript v1.4.1 changelog for more information.

Fixed

• Fix an issue where the extension fails to build on ARM64 Linux.

View the Elixir package v2.13.2 changelog for more information.

Added

• 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.

Fixed

• Fix an issue where the extension fails to build on ARM64 Linux.

View the Node.js package v3.5.3 changelog for more information.

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.

View the Ruby gem v4.1.3 changelog for more information.

Added

• Add reported_by tag to errors reported by the legacy error backend. This makes it easier to understand whether an error is being reported by the error backend.
• 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

• Change the primary download mirror for integrations.

Fixed

• Fix parentheses warning for Tesla on Elixir 1.17.x.

• Fix an issue where, after a certain amount of time, check-ins would no longer be sent.

  This issue also caused the default Hackney connection pool to be saturated, affecting other code that uses the default Hackney connection pool.

View the Elixir package v2.13.1 changelog for more information.