Adding Sample Data to a Request
You can add other types of metadata to a transaction or span besides tags. The helpers described on this page allow you to overwrite the metadata set by the AppSignal integration or add additional custom data.
Request parameters
By default, the AppSignal integrations track request parameters for web requests in supported libraries. These include query parameters and the POST request body. For background jobs, we store the job arguments in the parameters.
You can set custom parameters on a transaction or span. Modifying the parameters of a transaction will overwrite the data set by the AppSignal instrumentations.
All parameters are filtered by our integrations before being sent to our servers.
See the table below for a list of accepted root values per language. Each nested object can contain values that result in valid JSON (strings, integers, floats, booleans, nulls, etc.).
Language | Accepted root values |
---|---|
Ruby | Arrays, Hashes |
JavaScript | Arrays, Objects |
Elixir | Lists, Maps |
Python | Lists, Maps |
The below code sample shows how to set custom request parameters:
If the application sets parameters multiple times, the Ruby gem will merge values at the root level. For other integrations, only the last set value is stored.
Request headers
By default, the AppSignal integrations track request HTTP headers for web applications in supported libraries.
You can set custom request headers on a transaction or span. Modifying the request headers will overwrite the data set by the AppSignal instrumentations.
All request headers are filtered by our integrations before being sent to our servers.
See the table below for a list of accepted value types for request headers.
Language | Accepted header name | Accepted header value |
---|---|---|
All | String | String |
The below code sample shows how to set custom request headers:
Only the last value for a request header is stored if the application sets a request header multiple times.
For Elixir, if the helper is called multiple times, only the last set of request headers (environment) is stored.
Session data
By default, the AppSignal integrations will track request session data for web applications in supported libraries.
You can set custom request session data on a transaction or span. Modifying the session data will overwrite the data set by the AppSignal instrumentations.
All request session data is filtered by our integrations before being sent to our servers.
See the table below for a list of accepted root values per language. Each nested object can contain values that result in valid JSON (strings, integers, floats, booleans, nulls, etc.).
Language | Accepted root values |
---|---|
Ruby | Arrays, Hashes |
JavaScript | Arrays, Objects |
Elixir | Lists, Maps |
Python | Lists, Maps |
If the application sets session data multiple times, the Ruby gem will merge values at the root level. For other integrations, only the last set value is stored.
Custom data
You can use custom sample data to set more dynamic values than other types of sample data allow. See the table below for a list of accepted root values per language. Each nested object can contain values that result in valid JSON (strings, integers, floats, booleans, nulls, etc.).
Language | Accepted root values |
---|---|
Ruby | Arrays, Hashes |
JavaScript | Arrays, Objects |
Elixir | Lists, Maps |
Python | Lists, Maps |
It is impossible to filter or search on the data set as custom data. It only provides an additional area in the interface to list more metadata.
When using custom data for nested objects, you can view the object on the Incident Sample page for both Exception and Performance samples formatted as JSON, like in the example below:
If the application sets custom data multiple times, the Ruby gem will merge values at the root level. For other integrations, only the last set value is stored.