🚨 Filebeat Error: 'Non-zero metrics in the last 30s' — Cause, Fix, and Troubleshooting Guide

Overview

This is not an error — it is Filebeat’s periodic internal metrics snapshot, logged every 30 seconds whenever counters changed:

Non-zero metrics in the last 30s	{"monitoring": {"metrics": {"filebeat":{"harvester":{"open_files":12,"running":12}},"libbeat":{"output":{"events":{"acked":0,"failed":2048,"total":2048}},"pipeline":{"events":{"published":2048,"retry":2048}}}}}

People search for it because it shows up constantly and they assume it signals trouble. It does not by itself — but it is the single most useful diagnostic line in the log. The counters tell you whether events are being read (harvester), queued (pipeline), and acknowledged by the output (libbeat.output.events.acked). A healthy pipeline shows acked climbing; a broken one shows failed/retry climbing while acked stays at zero.

Symptoms

• The Non-zero metrics in the last 30s line repeats every 30s in the log.
• Interpreted alone it looks alarming, but it is expected output at the default log level.
• Real trouble shows as output.events.failed or pipeline.events.retry rising while acked is flat.
• If the line stops appearing entirely, Filebeat is idle (nothing changed) or wedged.

Common Root Causes

This message is informational; the reason it worries you is usually one of:

• Output failing — acked: 0 with failed/retry climbing means Elasticsearch/Logstash rejects or drops events.
• No harvesters — harvester.running: 0 means no files match your inputs.
• Backpressure — pipeline.events.active pinned at the queue max means the output cannot keep up.
• Dropped events — output.events.dropped incrementing means non-retryable failures (bad mapping, 400s).

How to diagnose

Tail the metrics line and watch acked vs failed:

journalctl -u filebeat -f | grep -i 'Non-zero metrics'

Query the live metrics endpoint instead of parsing the log (enable HTTP first):

# filebeat.yml
http.enabled: true
http.host: localhost
http.port: 5066

curl -s localhost:5066/stats | \
  jq '.libbeat.output.events, .filebeat.harvester, .libbeat.pipeline.events'

Fixes

If acked is stuck at 0, the problem is the output, not this line — test it directly:

filebeat test output

If harvester.running is 0, no files match; verify your paths resolve:

ls -l /var/log/app/*.log
filebeat -e -d "harvester,input"

To quiet noisy healthy metrics, raise the interval or narrow the selectors rather than suppressing them:

logging.metrics.period: 60s      # default is 30s

What to watch out for

• Do not silence metrics entirely — they are your primary signal when ingestion stalls.
• acked is the number that matters; total and published count attempts, not successes.
• A sudden absence of the line can mean Filebeat is blocked, not that all is well.
• Prefer the :5066/stats HTTP endpoint for dashboards over scraping the log text.

Related

• Filebeat Error Guide: ‘temporary bulk send failure’
• Filebeat Error Guide: ‘429 Too Many Requests’
• Filebeat Error Guide: ‘connection refused’