Changelog

Improving AppSignal, one deploy at a time.

Jul 26, 2024

Code box tabs

Added

In our code boxes that have tabs, add the ability to wrap long code lines.

Add wrap toggle button
Jul 25, 2024

Fix monitor_and_stop helper block passing

Ruby3.12.1

Fixed

  • Fix Appsignal.monitor_and_stop block passing. It would error with a LocalJumpError. Thanks to @cwaider.

View the Ruby gem v3.12.1 changelog for more information.

Jul 25, 2024

Fix config defaults set from loader mechanism

Ruby3.12.2

Fixed

  • Fix the default env and root path for the integrations using loader mechanism. If APPSIGNAL_APP_ENV is set when using Appsignal.load(...), the AppSignal env set in APPSIGNAL_APP_ENV is now leading again.

View the Ruby gem v3.12.2 changelog for more information.

Jul 23, 2024

MS Teams notifier update

Added

We have released a new MS Teams notifier. The reason for releasing this new version is that Microsoft has deprecated the current way of ingesting webhooks. The new MS Teams notifier now works with the Workflow system. Please see our documentation on how to set this up.

Removed

We have deprecated the old Webhook-based MS Teams notifier, as it will no longer work after Microsoft's deprecation date. Please update your notifier to the new version as soon as possible.

Jul 22, 2024

Installation instructions update

We’ve updated the instructions for installing AppSignal for Elixir and Python. The installation process should be even smoother.

Jul 22, 2024

New configuration methods and integrations loader

Ruby3.12.0

Added

  • Add a Rails configuration option to start AppSignal after Rails is initialized. By default, AppSignal will start before the Rails initializers are run. This way it is not possible to configure AppSignal in a Rails initializer using Ruby. To configure AppSignal in a Rails initializer, configure Rails to start AppSignal after it is initialized.

    ruby
    # config/application.rb # ... module MyApp class Application < Rails::Application # Add this line config.appsignal.start_at = :after_initialize # Other config end end

    Then, in the initializer:

    ruby
    # config/initializers/appsignal.rb Appsignal.configure do |config| config.ignore_actions = ["My action"] end

    Be aware that when start_at is set to after_initialize, AppSignal will not track any errors that occur when the initializers are run and the app fails to start.

    See our Rails documentation for more information.

  • Add a new method of configuring AppSignal: Appsignal.configure. This new method allows apps to configure AppSignal in Ruby.

    ruby
    # The environment will be auto detected Appsignal.configure do |config| config.activejob_report_errors = "discard" config.sidekiq_report_errors = :discard config.ignore_actions = ["My ignored action", "My other ignored action"] config.request_headers << "MY_HTTP_HEADER" config.send_params = true config.enable_host_metrics = false end # Explicitly define which environment to start Appsignal.configure(:production) do |config| # Some config end

    This new method can be used to update config in Ruby. We still recommend to use the config/appsignal.yml file to configure AppSignal whenever possible. Apps that use the Appsignal.config = Appsignal::Config.new(...) way of configuring AppSignal, should be updated to use the new Appsignal.configure method. The Appsignal::Config.new method would overwrite the given "initial config" with the config file's config and config read from environment variables. The Appsignal.configure method is leading. The config file, environment variables and Appsignal.configure methods can all be mixed.

    See our configuration guide for more information.

Changed

  • Update the Sinatra, Padrino, Grape and Hanami integration setup for applications. Before this change a "appsignal/integrations/sinatra" file would need to be required to load the AppSignal integration for Sinatra. Similar requires exist for other libraries. This has changed to a new integration load mechanism.

    This new load mechanism makes starting AppSignal more predictable when loading multiple integrations, like those for Sinatra, Padrino, Grape and Hanami.

    ruby
    # Sinatra example # Before require "appsignal/integrations/sinatra" # After require "appsignal" Appsignal.load(:sinatra) Appsignal.start

    The require "appsignal/integrations/sinatra" will still work, but is deprecated in this release.

    See the documentation for the specific libraries for the latest on how to integrate AppSignal.

    When using a combination of the libraries listed above, read our integration guide on how to load and configure AppSignal for multiple integrations at once.

  • Disable the AppSignal Rack EventHandler when AppSignal is not active. It would still trigger our instrumentation when AppSignal is not active. This reduces the instrumentation overhead when AppSignal is not active.

Deprecated

  • Deprecate the Appsignal.config = Appsignal::Config.new(...) method of configuring AppSignal. See the changelog entry about Appsignal.configure { ... } for the new way to configure AppSignal in Ruby.
  • Deprecate the Hanami integration require: require "appsignal/integrations/hanami". Use the new Appsignal.load(:hanami) method instead. Read our Hanami docs for more information.
  • Deprecate the Padrino integration require: require "appsignal/integrations/padrino". Use the new Appsignal.load(:padrino) method instead. Read our Padrino docs for more information.
  • Deprecate the Sinatra integration require: require "appsignal/integrations/sinatra". Use the new Appsignal.load(:sinatra) method instead. Read our Sinatra docs for more information.
  • Deprecate the Grape integration require: require "appsignal/integrations/grape". Use the new Appsignal.load(:grape) method instead. Read our Grape docs for more information.

Fixed

  • Fix instrumentation events for response bodies appearing twice. When multiple instrumentation middleware were mounted in an application, it would create duplicate process_response_body.rack events.

View the Ruby gem v3.12.0 changelog for more information.

Jul 16, 2024

Intercom integration

Removed

Jul 15, 2024

New and improved instrumentation helpers

Ruby3.11.0

Added

  • Add Appsignal.monitor and Appsignal.monitor_and_stop instrumentation helpers. These helpers are a replacement for the Appsignal.monitor_transaction and Appsignal.monitor_single_transaction helpers.

    Use these new helpers to create an AppSignal transaction and track any exceptions that occur within the instrumented block. This new helper supports custom namespaces and has a simpler way to set an action name. Use this helper in combination with our other Appsignal.set_* helpers to add more metadata to the transaction.

    ruby
    # New helper Appsignal.monitor( :namespace => "my_namespace", :action => "MyClass#my_method" ) do # Track an instrumentation event Appsignal.instrument("my_event.my_group") do # Some code end end # Old helper Appsignal.monitor_transaction( "process_action.my_group", :class_name => "MyClass", :action_name => "my_method" ) do # Some code end

    The Appsignal.monitor_and_stop helper can be used in the same scenarios as the Appsignal.monitor_single_transaction helper is used. One-off Ruby scripts that are not part of a long running process.

    Read our instrumentation documentation for more information about using theAppsignal.monitor helper.

  • Add Appsignal.set_session_data helper. Set custom session data on the current transaction with the Appsignal.set_session_data helper. Note that this will overwrite any request session data that would be set automatically on the transaction. When this method is called multiple times, it will overwrite the previously set value.

    ruby
    Appsignal.set_session_data("data1" => "value1", "data2" => "value2")
  • Add Appsignal.set_headers helper. Set custom request headers on the current transaction with the Appsignal.set_headers helper. Note that this will overwrite any request headers that would be set automatically on the transaction. When this method is called multiple times, it will overwrite the previously set value.

    ruby
    Appsignal.set_headers("PATH_INFO" => "/some-path", "HTTP_USER_AGENT" => "Firefox")
  • Report request headers for webmachine apps.

Changed

  • Allow tags to have boolean (true/false) values.

    ruby
    Appsignal.set_tags("my_tag_is_amazing" => true) Appsignal.set_tags("my_tag_is_false" => false)
  • Optimize Sidekiq job arguments being recorded. Job arguments are only fetched and set when we sample the job transaction, which should decrease our overhead for all jobs we don't sample.

Deprecated

  • Deprecate Transaction sample helpers: Transaction#set_sample_data and Transaction#sample_data. Please use one of the other sample data helpers instead. See our sample data guide.

  • Deprecate the Appsignal::Transaction#set_http_or_background_queue_start method. Use the Appsignal::Transaction#set_queue_start helper instead.

  • Deprecate the Appsignal.without_instrumentation helper. Use the Appsignal.ignore_instrumentation_events helper instead.

  • Deprecate the Appsignal::Transaction::GenericRequest class. Use the Appsignal.set_* helpers to set metadata on the Transaction instead. Read our sample data guide for more information.

  • Deprecate the 'ID', 'request', and 'options' arguments for the Transaction.create and Transaction.new methods. To add metadata to the transaction, use the Appsignal.set_* helpers. Read our sample data guide for more information on how to set metadata on transactions.

    ruby
    # Before Appsignal::Transaction.create( SecureRandom.uuid, "my_namespace", Appsignal::Transaction::GenericRequest.new(env) # env is a request env Hash ) # After Appsignal::Transaction.create("my_namespace")
  • Deprecate the Appsignal.monitor_transaction and Appsignal.monitor_single_transaction helpers. See the entry about the replacement helpers Appsignal.monitor and Appsignal.monitor_and_stop.

View the Ruby gem v3.11.0 changelog for more information.

Jul 08, 2024

Improved web request instrumentation

Ruby3.10.0

Added

  • Add our new recommended Rack instrumentation middleware. If an app is using the Appsignal::Rack::GenericInstrumentation middleware, please update it to use Appsignal::Rack::InstrumentationMiddleware instead.

    This new middleware will not report all requests under the "unknown" action if no action name is set. To set an action name, call the Appsignal.set_action helper from the app.

    ruby
    # config.ru # Setup AppSignal use Appsignal::Rack::InstrumentationMiddleware # Run app
  • Add Rake task performance instrumentation. Configure the enable_rake_performance_instrumentation option to true to enable Rake task instrumentation for both error and performance monitoring. To ignore specific Rake tasks, configure ignore_actions to include the name of the Rake task.

  • Add instrumentation to Rack responses, including streaming responses. New process_response_body.rack and close_response_body.rack events will be shown in the event timeline. These events show how long it takes to complete responses, depending on the response implementation, and when the response is closed.

    This Sinatra route with a streaming response will be better instrumented, for example:

    ruby
    get "/stream" do stream do |out| sleep 1 out << "1" sleep 1 out << "2" sleep 1 out << "3" end end
  • Add the Appsignal.report_error helper to report errors. If you unsure whether to use the Appsignal.set_error or Appsignal.send_error helpers in what context, use Appsignal.report_error to always report the error.

  • Support nested webmachine apps. If webmachine apps are nested in other AppSignal instrumentation it will now report the webmachine instrumentation as part of the parent transaction, reporting more runtime of the request.

  • Report the response status for Padrino requests as the response_status tag on samples, e.g. 200, 301, 500. This tag is visible on the sample detail page. Report the response status for Padrino requests as the response_status metric.

  • Add support for nested Padrino apps. When a Padrino app is nested in another Padrino app, or another framework like Sinatra or Rails, it will now report the entire request.

  • Add Appsignal.set_params helper. Set custom parameters on the current transaction with the Appsignal.set_params helper. Note that this will overwrite any request parameters that would be set automatically on the transaction. When this method is called multiple times, it will overwrite the previously set value.

    ruby
    Appsignal.set_params("param1" => "value1", "param2" => "value2")
  • Add Appsignal.set_custom_data helper to set custom data on the transaction. Previously, this could only be set with Appsignal::Transaction.current.set_custom_data("custom_data", ...). This helper makes setting the custom data more convenient.

  • Add Appsignal.set_tags helper as an alias for Appsignal.tag_request. This is a context independent named alias available on the Transaction class as well.

  • Add a block argument to the Appsignal.set_params and Appsignal::Transaction#set_params helpers. When set_params is called with a block argument, the block is executed when the parameters are stored on the Transaction. This block is only called when the Transaction is sampled. Use this block argument to avoid having to parse parameters for every transaction, to speed things up when the transaction is not sampled.

    ruby
    Appsignal.set_params do # Some slow code to parse parameters JSON.parse('{"param1": "value1"}') end

Deprecated

  • Deprecate the appsignal.action and appsignal.route request env methods to set the transaction action name. Use the Appsignal.set_action helper instead.

    ruby
    # Before env["appsignal.action"] = "POST /my-action" env["appsignal.route"] = "POST /my-action" # After Appsignal.set_action("POST /my-action")
  • Deprecate the Appsignal::Rack::StreamingListener middleware. Use the Appsignal::Rack::InstrumentationMiddleware middleware instead.

  • Deprecate the Appsignal::Rack::GenericInstrumentation middleware. Use the Appsignal::Rack::InstrumentationMiddleware middleware instead. See also the changelog entry about the InstrumentationMiddleware.

Fixed

  • Fix issue with AppSignal getting stuck in a boot loop when loading the Padrino integration with: require "appsignal/integrations/padrino" This could happen in nested applications, like a Padrino app in a Rails app. AppSignal will now use the first config AppSignal starts with.
  • Fix the deprecation warning of Bundler.rubygems.all_specs usage.

View the Ruby gem v3.10.0 changelog for more information.

Jul 05, 2024

Add Prisma and BullMQ support

Added

  • Add prisma slow queries and highlighting
  • Add bullmq event color
  • Add better validation for warmup/cooldown in Anomaly detection form(s)
  • Add indicator of 2fa status on user list in the admin

Fixed

  • Fix table cell overflow on dashboard page
Jul 04, 2024

Fix same body in different events

Node.js3.4.8

Fixed

  • Fix different spans of the same category incorrectly being reported with the same body.

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

Jul 03, 2024

Add span override prop to React error boundaries

JavaScript@appsignal/react@1.0.26

Added

  • Add a span override prop to the ErrorBoundary and LegacyBoundary components.

    Pass an override function to the error boundary component in order to set properties, such as tags, params or breadcrumbs, in the error span that will be sent to AppSignal.

    The override function is only called when an error is about to be sent. This allows you to only perform expensive computation to add information to the error when an error will actually be reported.

    When defined within a component, the function should be memoized with useCallback to prevent unnecessary re-renders:

    jsx
    export default const SomeComponent = ({ someProp }) => { const override = useCallback((span) => { span.setTags({ someProp }) }, [someProp]); return ( <ErrorBoundary override={override}> { /* Your component here */ } </ErrorBoundary> ) }

View the AppSignal JavaScript react v1.0.26 changelog for more information.

Jul 02, 2024

Support Hanami 2.1, improve GVL metrics, and more

Ruby3.9.3

Added

  • Track error response status for web requests. When an unhandled exception reaches the AppSignal EventHandler instrumentation, report the response status as 500 for the response_status tag on the transaction and on the response_status metric.

Changed

  • Require the AppSignal gem in the Grape integration file. Previously require "appsignal" had to be called before require "appsignal/integrations/grape". This require "appsignal" is no longer required.
  • Report Global VM Lock metrics per process. In addition to the existing hostname tag, add process_name and process_id tags to the gvl_global_timer and gvl_waiting_threads metrics emitted by the GVL probe, allowing these metrics to be tracked in a per-process basis.

Deprecated

  • Deprecate Appsignal::Grape::Middleware constant in favor of Appsignal::Rack::GrapeMiddleware constant.

    To fix this deprecation warning, update the usage of Appsignal::Grape::Middleware like this:

    ruby
    # Grape only apps insert_before Grape::Middleware::Error, Appsignal::Rack::GrapeMiddleware # or use Appsignal::Rack::GrapeMiddleware # Grape on Rails app use Appsignal::Rack::GrapeMiddleware
  • Deprecate the Appsignal.start_logger method. Remove this method call from apps if it is present. Calling Appsignal.start will now initialize the logger.

Fixed

  • Fix an issue with invalid request methods raising an error in the GenericInstrumentation middleware when using a request class that throws an error when calling the request_method method, like ActionDispatch::Request.
  • Support Grape apps that are nested in other apps like Sinatra and Rails, that also include AppSignal middleware for instrumentation.
  • Support Hanami version 2.1. On older versions of our Ruby gem it would error on an unknown keyword argument "sessions_enabled".
  • Fix issue with AppSignal getting stuck in a boot loop when loading the Hanami integration with: require "appsignal/integrations/hanami" This could happen in nested applications, like a Hanami app in a Rails app. It will now use the first config AppSignal starts with.

View the Ruby gem v3.9.3 changelog for more information.

Jun 26, 2024

Python package v1.3.7

Python1.3.7

Added

  • AMQP messaging processing with Pika tracing data is now supported.

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

Jun 26, 2024

Improved Hanami and Sinatra instrumentation

Ruby3.9.2

Added

  • Improve instrumentation of Hanami requests by making sure the transaction is always closed. It will also report a response_status tag and metric for Hanami requests.

Changed

  • Instrument the entire Sinatra request. Instrumenting Sinatra apps using require "appsignal/integrations/sinatra" will now report more of the request, if previously other middleware were not instrumented. It will also report the response status with the response_status tag and metric.

Fixed

  • Fix deprecation warnings about Transacation.params= usage by updating how we record parameters in our instrumentations.
  • Fix error reporting for requests with an error that use the AppSignal EventHandler.

View the Ruby gem v3.9.2 changelog for more information.

Jun 25, 2024

Elixir package v2.12.1

Elixir2.12.1

Fixed

  • When running the installation script on Microsoft Windows, some components threw an error. AppSignal doesn't support Windows, so the installation script won't run on Windows anymore. Preventing errors from raising.

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

Jun 24, 2024

Fix parameter reporting for Sinatra and pure Rack apps

Ruby3.9.1

Fixed

  • Fix parameter reporting for Rack and Sinatra apps, especially POST payloads.

View the Ruby gem v3.9.1 changelog for more information.

Jun 21, 2024

Report Sidekiq job errors only on job discard

Ruby3.9.0

Added

  • Report Sidekiq errors when a job is dead/discarded. Configure the new sidekiq_report_errors config option to "discard" to only report errors when the job is not retried further.

Changed

  • Improve instrumentation for mounted Sinatra apps in Rails apps. The sample reported for the Sinatra request will now include the time spent in Rails and its middleware.
  • Support apps that have multiple Appsignal::Rack::EventHandler-s in the middleware stack.
  • Improve support for instrumentation of nested pure Rack and Sinatra apps. It will now report more of the request's duration and events. This also improves support for apps that have multiple Rack GenericInstrumentation or SinatraInstrumentation middlewares.

Fixed

  • Fix issue with AppSignal getting stuck in a boot loop when loading the Sinatra integration with: require "appsignal/integrations/sinatra" This could happen in nested applications, like a Sinatra app in a Rails app. It will now use the first config AppSignal starts with.

View the Ruby gem v3.9.0 changelog for more information.

Jun 20, 2024

OpenTelemetry dependency updates

Node.js3.4.7

Changed

  • Update OpenTelemetry dependencies.

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

Jun 19, 2024

App updates

Added

We now render the name of the log view in the title of the page

CleanShot 2024-06-17 at 16 21 42

Fixed

  • Fix ability to filter samples by tag values that contain commas
  • Fix bug that broke the layout when certain tables contained long values.

Start your free trial

Don’t let the bad bugs bite. Try AppSignal for free.

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!