> ## Documentation Index
> Fetch the complete documentation index at: https://docs.appsignal.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Drop logs after extracting metrics

> Record a metric from high-volume log lines as they arrive, then drop the lines so you keep the number without storing every one. Set it up through AppSignal MCP.

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](/mcp-server) 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.

<Note>
  Log line actions only affect lines ingested after you create them. They do not change logs that are already stored.
</Note>

### Record the metric as logs arrive

Recording the metric at ingestion is what makes the drop safe. A [log-based metric](/logging/metrics) 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](/mcp-server) 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`:

```json theme={null}
{
  "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](/logging/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.

<Warning>
  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.
</Warning>

## 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`.

```json theme={null}
{
  "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.

## Related

* [AppSignal MCP](/mcp-server) and the [MCP tool reference](/mcp/reference)
* [Log-based metrics](/logging/metrics), built from stored log lines
* [Ignore logs](/guides/filter-data/ignore-logs), to stop sending lines from your integration in the first place