Filebeat Error Guide: 'backoff(elasticsearch(...)): lookup: no such host' — Fix Output DNS Resolution
Fix Filebeat 'backoff(elasticsearch(...)): lookup es01: no such host': repair DNS, hostnames, and endpoints so the output resolves and events ship.
- #filebeat
- #logging
- #troubleshooting
- #errors
Fixing errors like this? Get 500 free DevOps AI prompts
500 copy-paste AI prompts for the stack you actually run — one PDF, free.
Overview
Filebeat cannot ship events when the DNS name in its output cannot be resolved, and it retries with exponential backoff while logging:
Failed to connect to backoff(elasticsearch(https://es01:9200)): Get "https://es01:9200": dial tcp: lookup es01 on 10.0.0.2:53: no such host
The backoff(...) wrapper tells you this is the output connection layer retrying — Filebeat will keep trying on an increasing interval, so it is not lost, just stalled. The operative part is lookup es01 ... no such host: the failure is name resolution, not a refused connection or a timeout. The hostname in output.elasticsearch.hosts (or the Logstash output) does not resolve from where Filebeat runs. Until the name resolves to an address, no events leave the agent and the queue fills.
Symptoms
- Repeating
Failed to connect to backoff(...)lines containinglookup <host> ... no such host. - No documents arriving in Elasticsearch even though Filebeat is running and reading files.
- The Filebeat memory queue fills and inputs eventually experience backpressure.
- The same host works from another machine but not from the Filebeat host (split-horizon DNS).
- A recently renamed cluster endpoint or a typo’d hostname in the output config.
Common Root Causes
- Typo or wrong hostname in
output.elasticsearch.hosts/output.logstash.hosts. - DNS not configured on the Filebeat host, or the wrong resolver in
/etc/resolv.conf. - Short name with no search domain —
es01instead of the FQDNes01.internal.example.com. - Kubernetes DNS scope — using a bare Service name from a Pod in a different namespace without the
.svcsuffix. - Container has no access to the internal resolver, or
/etc/hostslacks the mapping in an air-gapped setup. - Endpoint decommissioned/renamed and the config never updated.
How to diagnose
Reproduce the resolution failure from the Filebeat host itself — not your laptop:
getent hosts es01
nslookup es01 || dig +short es01
cat /etc/resolv.conf
Confirm exactly what Filebeat is configured to reach, then use its own connectivity test:
grep -A3 'output.elasticsearch\|output.logstash' /etc/filebeat/filebeat.yml
filebeat test output -c /etc/filebeat/filebeat.yml
filebeat test output prints the DNS step separately from TCP/TLS, so it pinpoints resolution vs connection:
elasticsearch: https://es01:9200...
parse url... OK
dns lookup... ERROR lookup es01: no such host
Inside a container or Pod, check the resolver the runtime injected:
kubectl exec -it filebeat-xxxxx -- getent hosts es01
kubectl exec -it filebeat-xxxxx -- cat /etc/resolv.conf
Fixes
Use the resolvable name. The most common fix is simply the correct FQDN in the output:
output.elasticsearch:
hosts: ["https://es01.internal.example.com:9200"] # FQDN, not bare 'es01'
Point Filebeat at a working resolver if the host DNS is misconfigured:
# /etc/resolv.conf (sanitized)
nameserver 10.0.0.2
search internal.example.com
Add a static mapping for air-gapped or bootstrap hosts where DNS is unavailable:
# /etc/hosts
10.0.0.21 es01 es01.internal.example.com
In Kubernetes, use the fully qualified Service name so cross-namespace lookups resolve:
output.elasticsearch:
hosts: ["https://elasticsearch-master.logging.svc.cluster.local:9200"]
After any change, re-run the test and confirm the queue drains:
filebeat test output -c /etc/filebeat/filebeat.yml
journalctl -u filebeat -f | grep -iE 'backoff|no such host|connection to .* established'
What to watch out for
no such hostis DNS, not connectivity — if you instead seeconnection refusedori/o timeout, the name resolved and the problem is the port/firewall, not resolution.- A
searchdomain in/etc/resolv.confcan make a short name work interactively but fail under a container that has a different resolver — always test from where Filebeat actually runs. - Baking IPs into
/etc/hostsis a fine stopgap but drifts when the endpoint moves; prefer real DNS and treat/etc/hostsas temporary. - In Kubernetes,
ndots:5and namespace scoping cause bare Service names to fail from other namespaces; use the.svc.cluster.localFQDN. - While the output is unreachable, the memory queue fills and inputs stall — fix DNS promptly or events back up on the host.
Related
- Filebeat Error Guide: connection refused
- Filebeat Error Guide: dial tcp i/o timeout
- Filebeat Error Guide: 503 Service Unavailable
More output troubleshooting is in the Filebeat guides.
Get 500 Battle-Tested DevOps AI Prompts — Free
500 battle-tested, copy-paste AI prompts engineered by a senior systems engineer — every one with fill-in placeholders and safety/back-out notes. Drop your email and it's yours.
- 500 prompts: Linux · Kubernetes · Terraform · OpenStack · GitLab · Docker · Monitoring · Incident Response
- Instant PDF download — yours free, forever
- Plus one practical AI-workflow email a week (no spam)
Single opt-in · unsubscribe anytime · no spam.