Skip to content
DevOps AI ToolKit
Newsletter
All guides
AI for Filebeat By James Joyner IV · · 8 min read

Filebeat Error Guide: 'backoff(elasticsearch(...)): lookup: no such host' — Fix Output DNS Resolution

Quick answer

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
Free toolkit

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 containing lookup <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 domaines01 instead of the FQDN es01.internal.example.com.
  • Kubernetes DNS scope — using a bare Service name from a Pod in a different namespace without the .svc suffix.
  • Container has no access to the internal resolver, or /etc/hosts lacks 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 host is DNS, not connectivity — if you instead see connection refused or i/o timeout, the name resolved and the problem is the port/firewall, not resolution.
  • A search domain in /etc/resolv.conf can 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/hosts is a fine stopgap but drifts when the endpoint moves; prefer real DNS and treat /etc/hosts as temporary.
  • In Kubernetes, ndots:5 and namespace scoping cause bare Service names to fail from other namespaces; use the .svc.cluster.local FQDN.
  • While the output is unreachable, the memory queue fills and inputs stall — fix DNS promptly or events back up on the host.

More output troubleshooting is in the Filebeat guides.

Free download · 368-page PDF

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.