Updates and product improvements
View the Ruby gem v5.0.7 changelog for more information.
HEROKU_BUILD_COMMIT
environment variable, which is set by Heroku at build time when the
runtime-dyno-build-metadata Heroku Labs
feature is enabled.View the Ruby gem v4.10.6 changelog for more information.
View the Ruby gem v5.0.6 changelog for more information.
View the Ruby gem v4.10.5 changelog for more information.
HEROKU_BUILD_COMMIT
environment variable, which is set by Heroku at runtime when the
runtime-dyno-build-metadata Heroku Labs
feature is enabled.View the Ruby gem v5.0.5 changelog for more information.
View the Ruby gem v5.0.4 changelog for more information.
preload_app!. Before this change, applications running several forked processes would lose data points or report incorrect values for them.View the Ruby gem v5.0.3 changelog for more information.
Use the revision set by Heroku, Render, Kamal or Scalingo when the application also has a REVISION file. Since version 4.6.0, a REVISION file took precedence over the HEROKU_SLUG_COMMIT, RENDER_GIT_COMMIT, KAMAL_VERSION and CONTAINER_VERSION environment variables, so an application that kept a placeholder REVISION file in source control reported that placeholder as its revision. The revision config option and the APP_REVISION environment variable still take precedence over both.
Thanks to @rmm5t for their contribution!
View the Ruby gem v5.0.2 changelog for more information.
response_status counter with a service tag. Response statuses can then be graphed per service when several services report to one app.View the Ruby gem v5.0.1 changelog for more information.
View the Ruby gem v5.0.0 changelog for more information.
This release also includes all the changes from AppSignal for Ruby version 4.10.4 and below.
Detect the revision that is being deployed from the environment variables set by Heroku, Render, Kamal and Scalingo: HEROKU_SLUG_COMMIT, RENDER_GIT_COMMIT, KAMAL_VERSION and CONTAINER_VERSION. Applications deployed on those platforms now report their revision without setting the revision configuration option.
This affects collector mode, where deploys were reported as unknown when the revision was not configured.
Detect the hostname of the machine the application runs on. On Heroku this is the name of the dyno, and everywhere else it is the name the host reports for itself. Set the hostname configuration option to report a different name.
This affects collector mode, where all data was reported for a host named unknown when the hostname was not configured.
Report the host, the port and the HTTP version of an incoming web request in collector mode. These are sent as the server.address, server.port and network.protocol.version OpenTelemetry attributes. The host is read from the Forwarded and X-Forwarded-Host headers when a proxy sets them, so it is the host the client used rather than the one the proxy connected to.
Report the request environment in collector mode. The request_headers configuration option is an allowlist of Rack environment names, and some of those names are not request headers. Those values are now reported as appsignal.environment.* OpenTelemetry attributes and shown in the request's Environment panel, instead of being left out.
Values that describe the request itself are not repeated there, because they are already reported as the request's method, path, host, port and protocol version.
Add the keep_request_headers and keep_request_environment configuration options, which are used in collector mode. They replace request_headers, which is deprecated in collector mode.
keep_request_headers lists the request headers to report, using the names OpenTelemetry uses for them, such as accept and content-length. keep_request_environment lists the Rack environment values to report that are not request headers, using the names Rack uses for them, such as REMOTE_ADDR.
Both options default to a value derived from request_headers, which lists Rack environment keys and mixes the two kinds together. So an application that only ever set request_headers keeps reporting the same values when it moves to collector mode.
The request_headers configuration option is deprecated in collector mode, and a warning will be emitted at startup, containing the values of keep_request_headers and keep_request_environment that should be used to replace it.
In agent mode, request_headers still lists every Rack environment key to report, and the two new options have no effect.
Add the Appsignal.add_request_headers and Appsignal.add_request_environment helpers.
Use add_request_headers to report request headers, naming each header in lowercase and with dashes, such as content-length. Use add_request_environment to report the values a Rack environment holds that are not request headers, naming each one the way Rack names it, such as REMOTE_ADDR.
In agent mode, both write to the "Environment" sample data, formatted as Rack environment keys. In collector mode, they write different span attributes.
Together they replace Appsignal.add_headers, which is now deprecated, as it accepts Rack environment keys and works out which ones are headers.
Report request headers for Webmachine applications.
Report app instead of unknown as the OpenTelemetry service name when the service_name configuration option is not set and collector mode is in use.
The filter_parameters and send_params configuration options are deprecated in collector mode. Use filter_request_payload, filter_function_parameters and filter_request_query_parameters to filter different kinds of parameters, and send_request_payload, send_request_query_parameters and send_function_parameters to choose which kinds of parameters to report.
In collector mode, each kind of parameter is now filtered and reported according to its own options, and the deprecated options' values are only used to fill in values when the new options are unset. AppSignal logs which values to set to keep reporting what it reports now.
In agent mode, filter_parameters and send_params still apply to every kind of parameter, and the new options have no effect.
ignore_logs option now filters out the log lines that match its patterns in collector mode.ca_file_path and http_proxy options now apply to the data sent to the collector in collector mode. Before this change they only applied to the data sent by the agent, so a custom certificate authority file or a proxy had no effect in collector mode.filter_metadata configuration option being ignored in collector mode.response_headers configuration option names some. The option had no effect at all, so every response header captured by the application's own OpenTelemetry instrumentation was reported whatever the option said.config/appsignal.yml as the empty list it means. Options such as filter_parameters and ignore_actions raised a NoMethodError when AppSignal started, and filter_metadata and filter_session_data raised one while a transaction was sampled.View the Ruby gem v5.0.0.rc.2 changelog for more information.
config/initializers. In those applications Appsignal.active? returned
false inside an initializer, errors raised by initializers were not reported,
and with config.appsignal.start_at = :after_initialize the Rails defaults for
log_path and ignore_actions were not applied.View the Ruby gem v4.10.4 changelog for more information.
Fix the sanitization of function arguments in SQL statements.
Before this release, SQL sanitization of function arguments stripped out parts of the SQL statement after the function argument list.
View the Ruby gem v4.10.3 changelog for more information.
Add support for Grape 4. On Grape 4, every request through a Grape API raised a NoMethodError. Applications on Grape 3 and below were not affected.
On Grape 4, the action name and the reported path now describe the endpoint's full route, so they include the API prefix, the path version and the mount point. They also no longer end in a trailing slash when the endpoint declares no path of its own, so an endpoint reported as GET::My::Api#/users/:id/ is now reported as GET::My::Api#/users/:id. Action names on Grape 3 and below do not change.
Load the host Rails application before the appsignal demo command reads the
AppSignal configuration. This matches the behavior of appsignal diagnose.
Thanks @Guflly for your contribution!
Fix events showing as unknown in long-running applications. An application process that kept running for thirty days without restarting could lose the names and queries of the events it recorded, both in slow traces and in the "Slow events" panel.
Prevent gc events from appearing in the "Slow events" panel.
Report Delayed Job jobs that fail to load. Before this change, a job whose payload could not be deserialized was not reported to AppSignal at all.
This can happen when a deploy removes or renames a job class while jobs of that
class are still queued. Those jobs are now reported as failed, with the
Delayed::DeserializationError they raised, and are named after the class
recorded in the job's handler. When even that cannot be read, they are named
DelayedJobInternal.
Record a single event for a bulk enqueue of Active Job jobs. Before this change,
enqueuing jobs with ActiveJob.perform_all_later would record an event for the
batch and, if the adapter was instrumented with AppSignal, another event for each
job in it. A job that slices a large collection and enqueues it in batches was
therefore reported with an event per job enqueued, where before version 4.9.0 it
had one event per batch.
A bulk enqueue is now recorded as a single enqueue_all.active_job event, named
after the job class when every job in the batch shares one.
View the Ruby gem v4.10.2 changelog for more information.
[timeout] processes on Alpine Linux containers.gc events from appearing in the "Slow events" panel.View the Ruby gem v3.13.2 changelog for more information.
Add a collector_endpoint configuration option (APPSIGNAL_COLLECTOR_ENDPOINT environment variable) that puts the integration in collector mode. In collector mode AppSignal reports traces, metrics and logs to an AppSignal Collector, over OTLP/HTTP.
Collector mode requires Ruby 3.1 or newer, and the OpenTelemetry gems, which are not installed by default. Add the appsignal-opentelemetry gem alongside appsignal to install them. When they are missing or too old, AppSignal logs a warning and keeps reporting through its agent.
Add configuration options that map to OpenTelemetry resource attributes in collector mode: service_name, filter_attributes, filter_function_parameters, filter_request_query_parameters, filter_request_payload, response_headers, send_function_parameters, send_request_query_parameters and send_request_payload.
In collector mode, existing options are passed to the collector as resource attributes as well: name, environment, hostname, revision, ignore_actions, ignore_errors, ignore_namespaces, request_headers, filter_session_data and send_session_data.
Setting any of these without collector_endpoint, or setting filter_parameters, filter_metadata or send_params with it, logs a warning at startup.
Add the appsignal-opentelemetry gem. It installs the OpenTelemetry gems that AppSignal needs to run in collector mode. Add it alongside appsignal to opt into collector mode with a single gem instead of listing each OpenTelemetry gem yourself:
gem "appsignal"
gem "appsignal-opentelemetry"Collector mode requires Ruby 3.1 or newer, so this gem does too. Its version stays in lockstep with the appsignal gem.
View the Ruby gem v5.0.0.rc.1 changelog for more information.
Use the CA certificate configured in APPSIGNAL_CA_FILE_PATH to download the
AppSignal agent when installing this gem.
The gem downloads the agent from our servers over HTTPS during installation. It
always used the CA certificate bundled with the gem to verify that connection,
whatever the value of the ca_file_path configuration option. This meant the
installation failed behind a proxy that intercepts TLS connections, such as
Zscaler, even when APPSIGNAL_CA_FILE_PATH pointed to a CA bundle that trusts
the proxy.
The bundled CA certificate is still used when APPSIGNAL_CA_FILE_PATH is not
set.
Thanks @Cosmo for your contribution!
View the Ruby gem v4.10.1 changelog for more information.
Fix Excon requests being reported as taking almost no time. An Excon request is now recorded as a single request.excon event covering the whole request, so the event lasts as long as the request did. The response.excon, retry.excon and error.excon events no longer exist. AppSignal also no longer registers itself as Excon's instrumentor.
Report which template was rendered for collection and layout render events.
Name ROM query events after ROM, rather than after the database they ran
against. A query made through ROM was reported as query.postgres, or query.sqlite,
or whatever else the application's database was. Those queries are now all reported as
query.rom.
Events that dry-monitor reports and AppSignal has no formatter for are now named
after their event id followed by .dry, so an event reported as foo becomes
foo.dry. They had no group at all before.
If you have a dashboard, trigger or saved filter that names one of these events, point it at the new name.
Fix a rare hang when stopping AppSignal in an application that sends check-ins. Stopping AppSignal waits for any check-in events that have not been transmitted yet, and it could wait forever instead of finishing.
Fix event formatters that register or unregister themselves. Calling
unregister on the formatter itself, as in MyFormatter.unregister("my.event"),
did nothing at all. The formatter stayed registered, and no error was raised and
nothing was logged to say so. Calling register on the formatter itself stored
it where AppSignal never looked for it, so it was never used to format an event.
Registering and unregistering through Appsignal::EventFormatter itself, as in
Appsignal::EventFormatter.unregister("my.event", MyFormatter), was not
affected and keeps working the same way.
View the Ruby gem v4.10.0 changelog for more information.
View the Ruby gem v4.9.1 changelog for more information.
Improve Faraday support. AppSignal now instruments Faraday requests automatically, without double-instrumenting the underlying HTTP client. Turn it off with the instrument_faraday option. Read more in our Faraday integration docs.
Add config options to turn individual integrations off. Set
instrument_sidekiq, instrument_shoryuken, instrument_que,
instrument_resque, instrument_delayed_job, instrument_active_job,
instrument_excon or instrument_mongo to false to disable that
integration entirely. This turns off both the instrumentation of the jobs or
requests and the enqueue instrumentation for that integration. They all
default to true. Each can also be set through its environment variable, such
as APPSIGNAL_INSTRUMENT_SIDEKIQ.
Instrument background job enqueues. Enqueuing a job now records an enqueue
event on the active transaction, so enqueues made from within a web request or
another job show up in the event timeline. This is recorded for Sidekiq
(enqueue.sidekiq), Que (enqueue.que, plus bulk_enqueue.que for bulk
enqueues on Que 2), Resque (enqueue.resque), Shoryuken (enqueue.shoryuken)
and Delayed Job (enqueue.delayed_job). Each event is titled after the job
being enqueued.
For Active Job, the enqueue.active_job event is now recorded by AppSignal's
own instrumentation rather than by Rails' native enqueue.active_job
notification. The native notification is suppressed so the enqueue is recorded
once, and the event is now titled after the job being enqueued.
These enqueue events can be turned off with the
enable_job_enqueue_instrumentation config option. Set it to false to stop
recording enqueue events across all integrations, without affecting the
instrumentation of the jobs themselves. It defaults to true and can also be
set through the APPSIGNAL_ENABLE_JOB_ENQUEUE_INSTRUMENTATION environment
variable.
Report the grape gem version in the environment metadata. For more information, see our environment metadata docs.
HTTP.follow.get(...), HTTP.headers(...).get(...), and so on -- go
through HTTP::Session rather than HTTP::Client, and were not being recorded.
They now produce a request.http_rb event like any other request.View the Ruby gem v4.9.0 changelog for more information.
Free for 30 days. No credit card. Two-minute install.
Need help or have a feature request? Talk to a real engineer. Not a bot, not a ticket queue.
AppSignal is built by a small, dedicated team spread across the world. We love stroopwafels. If you do too, let us know. We might send you some.
