Exclude logs from a Fluentd match

The clearest way to exclude a Fluentd tag is usually to send it to a null output before a broader route. To exclude records based on their contents, use a grep filter instead. These operate on different things: a match selects an event's tag, while a filter examines its record.

Exclude records by field value

Place this before the output handling app.**:

<filter app.**>
  @type grep
  <exclude>
    key message
    pattern /healthcheck|heartbeat/
  </exclude>
</filter>

A matching message field causes the event to be discarded. The regex searches within the field; it is case-sensitive. Use anchors if you want a whole-field match rather than a substring. For multiline strings, Ruby's \A and \z anchor the entire string, whereas ^ and $ describe line boundaries.

Discard a tag before the general route

<match app.debug.**>
  @type null
</match>

<match app.**>
  @type stdout
</match>

app.debug and its descendants stop at the first output; other app events reach stdout. Replace stdout with your configured destination after checking the routes. A broad match placed first would consume the events before the specific rule could see them.

For content-based routing, the separately installed rewrite_tag_filter plugin can assign a distinct tag such as drop.app. Send that tag to null, retain an explicit route for other events, and ensure rewritten tags do not loop back into the same rewrite rule.

A regular expression is another option

Fluentd 1.11.2 and later support regex tag patterns. For example:

<match /\A(?!app\.debug(?:\.|\z))app(?:\.|\z).*\z/>
  @type stdout
</match>

This excludes app.debug and its descendants while matching app and other app.* tags. Excluded events still need another route if you want an intentional discard rather than an unmatched-tag warning. A specific null route is often easier to maintain than a negative-lookahead expression.

FAQ

Does a filter after a matching output still run?

No. Put the filters before the output that consumes the event. Multiple matching filters before that point can run in sequence.

Can I count what gets discarded?

Do not assume every plugin exposes a dedicated dropped-event metric. Inspect the metrics available in your deployed version; if discard counts matter, instrument the discard route or compare input/output counters with buffering and retries accounted for.

References: match patterns and ordering, grep filtering, and tag rewriting.