Support Kamal deployments

Support Kamal-based deployments. Read the KAMAL_VERSION environment variable, which Kamal exposes within the deployed container, if present, and use it as the application revision if it is not set. This will automatically report deploy markers for applications using Kamal.

See the Elixir package 2.10.2 changelog for more information.

Handle live_view render messages

Handle live_view :render messages received through :telemetry.

See the changelog for AppSignal for Phoenix package 2.3.8 for more information.

Instrument `fetch` and other improvements

Instrument calls to fetch in Node.js. Requests made using Node.js' global fetch, or through the underlying undici library, will be automatically instrumented and shown as events in your performance samples' event timeline.

Support Kamal-based deployments. Read the KAMAL_VERSION environment variable, which Kamal exposes within the deployed container, if present, and use it as the application revision if it is not set. This will automatically report deploy markers for applications using Kamal.

See the Node.js package 3.4.4 changelog for more information.

Support Kamal deployments

Support Kamal-based deployments. Read the KAMAL_VERSION environment variable, which Kamal exposes within the deployed container, if present, and use it as the application revision if it is not set. This will automatically report deploy markers for applications using Kamal.

See the Python package 1.3.3 changelog for more information.

ViewComponent support and other improvements

Support events emitted by ViewComponent. Rendering of ViewComponent-based components will appear as events in your performance samples' event timeline.

For AppSignal to instrument ViewComponent events, you must first configure ViewComponent to emit those events:

# config/application.rb
module MyRailsApp
  class Application < Rails::Application
    config.view_component.instrumentation_enabled = true
    config.view_component.use_deprecated_instrumentation_name = false
  end
end

Thanks to Trae Robrock (@trobrock) for providing a starting point for this implementation!

Support Kamal-based deployments. Read the KAMAL_VERSION environment variable, which Kamal exposes within the deployed container, if present, and use it as the application revision if it is not set. This will automatically report deploy markers for applications using Kamal.

Fix an issue where an error about the AppSignal internal logger is raised when sending a heartbeat.

See the Ruby gem 3.7.5 changelog for more information.

Read Linux package config from environment variables

Changed

• Read from environment variables for config in standalone agent. When the agent is started with the --config CLI option, it will now also read from the environment variables documented in the standalone agent config section. The environment variables are read first. Any option set in the config file (specified with --config) will override the environment variable value.
• Improve the error message that is logged for the standalone agent using a configuration while when it is not properly configured.

This release can be installed through our standalone agent packages and as a Docker image.

Fix LocalJumpError on Active Job < 7.1

Fix LocalJumpError in Active Job instrumentation initialization for Active Job < 7.1.

See the Ruby gem 3.7.4 changelog for more information.

Report Active Job errors only on discard

Added

• Add option to activejob_report_errors option to only report errors when a job is discard by Active Job. In the example below the job is retried twice. If it fails with an error twice the job is discarded. If activejob_report_errors is set to discard, you will only get an error reported when the job is discarded. This new discard value only works for Active Job 7.1 and newer.

  ruby

  class ExampleJob < ActiveJob::Base
    retry_on StandardError, :attempts => 2
   
    # ...
  end

  More information in our Active Job documentation.

• Track Active Job executions per job. When a job is retried the "executions" metadata for Active Job jobs goes up by one for every retry. We now track this as the executions tag on the job sample.

See the Ruby gem 3.7.3 changelog for more information.

Add support for amqplib

Added

Added support for amqplib. All spans containing amqplib will now have child spans related to the amqplib operations.

See the Node.js package 3.4.2 changelog for more information.

Support PostgreSQL and MySQL database adapters

Add support for the aiopg, asyncpg, mysql (from the mysql-connector-python package), mysqlclient, and pymysql database adapters.

To enable AppSignal to instrument queries performed using these packages, follow the instructions in our PostgreSQL and MySQL documentation pages.

See the Python package 1.3.2 changelog for more information.

Fix deprecation warnings

Fixed

• Fix deprecation warnings for Probes.probes introduced in 3.7.1 for internally registered probes.

See the Ruby gem 3.7.2 changelog for more information.

Support SQLAlchemy and SQLite

Add support for SQLAlchemy, SQLite and version 3 of the psycopg PostgreSQL adapter.

To enable AppSignal to instrument queries performed using these packages, follow the instructions in our SQLAlchemy, SQLite and PostgreSQL documentation pages.

See the Python package 1.3.1 changelog for more information.

Probe improvements and small fixes

Changed

• If the gem can't find a valid log path in the app's log/ directory, it will no longer print the warning more than once.
• Stop the minutely probes when Appsignal.stop is called. When Appsignal.stop is called, the probes thread will no longer continue running in the app process.
• Listen to the APPSIGNAL_HTTP_PROXY environment variable in the extension installer. When APPSIGNAL_HTTP_PROXY is set during gem instal appsignal or bundle install, it will use the proxy specified in the APPSIGNAL_HTTP_PROXY environment variable to download the extension and agent.
• Allow unregistering minutely probes. Use Appsignal::Probes.unregister to unregister probes registered with Appsignal::Probes.register if you do not need a certain probe, including default probes.
• Add Appsignal::Probes.register method as the preferred method to register probes. The Appsignal::Probes.probes.register and Appsignal::Minutely.probes.register methods are now deprecated.
• Automatically start new probes registered with Appsignal::Probes.register when the gem has already started the probes thread. Previously, the late registered probes would not be run.
• Rename the Minutely constant to Probes so that the API is the same between AppSignal integrations. If your apps calls Appsignal::Minutely, please update it to Appsignal::Probes. If your app calls Appsignal::Minutely after this upgrade without the name change, the gem will print a deprecation warning for each time the Appsignal::Minutely is called.
• Log debug messages when metrics are received for easier debugging.

Fixed

• Clear the AppSignal in memory logger, used during the gem start, after the file/STDOUT logger is started. This reduces memory usage of the AppSignal Ruby gem by a tiny bit, and prevent stale logs being logged whenever a process gets forked and starts AppSignal.

See the Ruby gem 3.7.1 changelog for more information.

Fix unused variable warnings

Fix unused variables warnings introduced in the previous release.

See the changelog for AppSignal for Phoenix package 2.3.7 for more information.

Link templates for Log Attributes

We've expanded our link templates feature to include log attributes. This allows you to create links to external services based on the attributes of a log message.

One caveat to note is that in order to use the same link template for both sample tags and log attributes, we match the attribute name without the type extension.

E.g, a log attribute user_id_string will match a link template based on user_id

Support parial key matches in Phoenix's filter_parameters

Fix the Phoenix filter_parameters config option support for partial key matches. When configuring config :phoenix, filter_parameters with ["key"] or {:discard, ["key"]}, it now also matches partial keys like "my_key", just like Phoenix's logger does.

See the Elixir package 2.10.1 changelog for more information.

Improved Phoenix.ActionClauseError support

Set an action name for Phoenix.ActionClauseError errors. It will now group these errors per controller-action combination for more convenient grouping.

See the changelog for AppSignal for Phoenix package 2.3.6 for more information.

Add heartbeats and `ignore_logs` config option

Added

ignore_logs configuration option

Add the ignore_logs configuration option, which can also be configured as the APPSIGNAL_IGNORE_LOGS environment variable.

The value of ignore_logs is a list (comma-separated, when using the environment variable) of log line messages that should be ignored. For example, the value "start" will cause any message containing the word "start" to be ignored. Any log line message containing a value in ignore_logs will not be reported to AppSignal.

The values can use a small subset of regular expression syntax (specifically, ^, $ and .*) to narrow or expand the scope of lines that should be matched.

For example, the value "^start$" can be used to ignore any message that is exactly the word "start", but not messages that merely contain it, like "Process failed to start". The value "Task .* succeeded" can be used to ignore messages about task success regardless of the specific task name.

Heartbeats

Heartbeats are currently only available to beta testers. If you are interested in trying it out, send an email to support@appsignal.com!

Add heartbeats support. You can send heartbeats directly from your code, to track the execution of certain processes:

def send_invoices do
  # ... your code here ...
  Appsignal.heartbeat("send_invoices")
end

You can pass a function to Appsignal.heartbeat, to report to AppSignal both when the process starts, and when it finishes, allowing you to see the duration of the process:

def send_invoices do
  Appsignal.heartbeat("send_invoices", fn ->
    # ... your code here ...
  end)
end

If an exception is thrown within the function, the finish event will not be reported to AppSignal, triggering a notification about the missing heartbeat. The exception will bubble outside of the heartbeat function.

Changed

Remove a broken link pointing to a 1.x upgrade page during the installation flow.

See the Elixir package 2.10.0 changelog for more information.

Add heartbeats and `ignoreLogs` config option

Added

ignoreLogs configuration option

Add the ignoreLogs configuration option, which can also be configured as the APPSIGNAL_IGNORE_LOGS environment variable.

The value of ignoreLogs is a list (comma-separated, when using the environment variable) of log line messages that should be ignored. For example, the value "start" will cause any message containing the word "start" to be ignored. Any log line message containing a value in ignoreLogs will not be reported to AppSignal.

The values can use a small subset of regular expression syntax (specifically, ^, $ and .*) to narrow or expand the scope of lines that should be matched.

For example, the value "^start$" can be used to ignore any message that is exactly the word "start", but not messages that merely contain it, like "Process failed to start". The value "Task .* succeeded" can be used to ignore messages about task success regardless of the specific task name.

Heartbeats

Heartbeats are currently only available to beta testers. If you are interested in trying it out, send an email to support@appsignal.com!

Add heartbeats support. You can send heartbeats directly from your code, to track the execution of certain processes:

import { heartbeat } from "@appsignal/nodejs"
 
function sendInvoices() {
  // ... your code here ...
  heartbeat("send_invoices")
}

You can pass a function to heartbeat, to report to AppSignal both when the process starts, and when it finishes, allowing you to see the duration of the process:

import { heartbeat } from "@appsignal/nodejs"
 
function sendInvoices() {
  heartbeat("send_invoices", () => {
    // ... your code here ...
  })
}

If an exception is raised within the function, the finish event will not be reported to AppSignal, triggering a notification about the missing heartbeat. The exception will bubble outside of the heartbeat function.

If the function passed to heartbeat returns a promise, the finish event will be reported to AppSignal if the promise resolves. This means that you can use heartbeats to track the duration of async functions:

import { heartbeat } from "@appsignal/nodejs"
 
async function sendInvoices() {
  await heartbeat("send_invoices", async () => {
    // ... your async code here ...
  })
}

If the promise is rejected, or if it never resolves, the finish event will not be reported to AppSignal.

Changed

Appsignal.stop() must be awaited

Appsignal.stop() now returns a promise. For your application to wait until AppSignal has been gracefully stopped, this promise must be awaited:

import { Appsignal } from "@appsignal/nodejs"
 
await Appsignal.stop()
process.exit(0)

In older Node.js versions where top-level await is not available, terminate the application when the promise is settled:

import { Appsignal } from "@appsignal/nodejs"
 
Appsignal.stop().finally(() => {
  process.exit(0)
})

See the Node.js package 3.4.0 changelog for more information.

Add heartbeats

Heartbeats are currently only available to beta testers. If you are interested in trying it out, send an email to support@appsignal.com!

Add heartbeats support. You can use the heartbeat function to send heartbeats directly from your code, to track the execution of certain processes:

from appsignal import heartbeat
 
def send_invoices():
  # ... your code here ...
  heartbeat("send_invoices")

It is also possible to pass a defined function as an argument to the heartbeat function:

def send_invoices():
  # ... your code here ...
 
heartbeat("send_invoices", send_invoices)

If an exception is raised within the function, the finish event will not be reported to AppSignal, triggering a notification about the missing heartbeat. The exception will be raised outside of the heartbeat function.

See the Python package 1.3.0 changelog for more information.