Skip to main content
Some log lines are worth counting but not worth keeping. An online store might log every catalog search a shopper runs, every product page they open, and every health check from its load balancer. Each line on its own tells you little, but the rate matters. You want to know how often it happens, not store every line. AppSignal can record a metric from matching log lines as they arrive, then drop those lines so they are never stored. You keep the number for dashboards and triggers, and your log storage stays down. Measure first, then discard, like an observability pipeline. The AppSignal app UI does not support this yet. You can set it up through AppSignal MCP by asking your AI agent to create two log line actions.

​
How it works

Log line actions run as AppSignal ingests your logs, in an order you set. There are three types:
  • metrics: records a metric from matching lines.
  • filter: drops matching lines so they are never stored.
  • trigger: fires an alert and incident when the query matches.
To keep the metric and drop the lines, use a metrics action and a filter action, with the metrics action first. A filter stops a line from reaching any later action, so if the filter ran first, the line would be dropped before it was counted.
Log line actions only affect lines ingested after you create them. They do not change logs that are already stored.

​
Record the metric as logs arrive

Recording the metric at ingestion is what makes the drop safe. A log-based metric built from the Logs page reads stored log lines, so once you drop the lines there is nothing left to read. A metrics log line action records the value from each line as it arrives, before the filter drops it, so the number survives.

​
Before you start, you will need

  • AppSignal MCP set up in your AI agent, with write access to the logging tools
  • A log source that receives the lines you want to measure
  • A query that matches those lines

​
Step 1: Record a metric from the lines

Ask your agent to add a metrics action. For example, to count how often shoppers search your catalog:
On MyStore production, add a metrics log line action that counts log lines matching message:search as a counter named log.catalog_searches, scoped to the application log source.
This calls manage_log_line_action: 
{
  "app_name": "MyStore",
  "app_environment": "production",
  "name": "Catalog search rate",
  "action_type": "metrics",
  "query": "message:search",
  "source_ids": ["<YOUR_LOG_SOURCE_ID>"],
  "log_line_metrics": [
    { "name": "log.catalog_searches", "metric_type": "counter" }
  ]
}
Three things to get right:
  • Write the query in AppSignal’s log query syntax, the same syntax as the Logs page. message:search matches lines whose message contains search. See query syntax.
  • Choose which sources it applies to. List them in source_ids, or omit source_ids to apply the action to every source.
  • Pick the metric type. A counter counts matching lines and needs no field. A gauge or distribution reads a number from each line, so it needs a field naming which value to read.

​
Step 2: Check the metric before you drop anything

Wait for a few matching lines, then read the metric back:
Show me the log.catalog_searches counter for MyStore production over the last 15 minutes.
Confirm the counter is recording before you add the filter. A filter drops matching lines permanently, so if the query is wrong you lose the lines without capturing the count.

​
Step 3: Drop the matching lines

Add a filter action with the same query:
On MyStore production, add a filter log line action that drops log lines matching message:search. 
{
  "app_name": "MyStore",
  "app_environment": "production",
  "name": "Drop catalog search logs",
  "action_type": "filter",
  "query": "message:search",
  "source_ids": ["<YOUR_LOG_SOURCE_ID>"]
}

​
Step 4: Keep the metrics action before the filter

New actions are added at the end of the order, so the filter already runs after the metrics action. Confirm the order:
List the log line actions on MyStore production, and keep the metrics action before the filter.
This uses get_app_resources to read the order, and reorder_log_line_actions only if the filter is ahead of the metrics action. If the filter ran first, it would drop the lines before the metrics action counted them.

​
Verify it works

Give the actions a few minutes to take effect, then confirm both halves on a small sample:
  1. Read the metric. The counter keeps rising as matching lines arrive.
  2. Search your logs for the same lines. New ones no longer appear, because the filter drops them.
If the counter is not rising, or the lines are still stored, the action may not have taken effect yet, or the query may not match. Check the query on the Logs page, then try again on fresh lines.

​
Behavior and limitations

  • Actions are not retroactive. They act on new lines only. Logs stored before you created the action stay as they are.
  • Allow a few minutes. A new or changed action takes a short time to take effect. Lines that arrive in the first moments may not be processed by it.
  • Dropped lines cannot be recovered. Keep the metric, and a trigger action if you want alerts, so the filter never removes the only record of an event.
  • The two queries are independent. Count one set of lines and drop another if that fits your goal. To count and drop the same lines, use the same query for both.