# Filebeat 8.15.1 connection error when writing monitoring data

**URL:** <https://discuss.elastic.co/t/filebeat-8-15-1-connection-error-when-writing-monitoring-data/366188>\
**Category:** Beats\
**Tags:** elastic-stack-monitoring, filebeat\
**Created:** [September 7, 2024, 10:28am UTC](https://discuss.elastic.co/t/filebeat-8-15-1-connection-error-when-writing-monitoring-data/366188 "2024-09-07T10:28:34Z")\
**Posts on this page:** 4\
**Page:** 1

<div class="post-metadata">

**Author:** ![memir](https://avatars.discourse-cdn.com/v4/letter/m/49beb7/32.png) [@memir](https://discuss.elastic.co/u/memir)\
**Post date:** [September 7, 2024, 10:28am UTC](https://discuss.elastic.co/t/filebeat-8-15-1-connection-error-when-writing-monitoring-data/366188/1 "2024-09-07T10:28:35Z")

</div>

Hello everyone!

Yesterday, on a test system, we have installed the Elastic Stack at version 8.15.1.

After the procedure was concluded, we saw the following error in the filebeat logs and in particular we saw that no monitoring data was present under the _.monitoring-beats_\* index pattern (hostname info redacted from the original log).

```auto
Sep 06 16:19:36 master filebeat[141482]: {"log.level":"error","@timestamp":"2024-09-06T16:19:36.094Z","log.logger":"publisher_pipeline_output","log.origin":{"function":"github.com/elastic/beats/v7/libbeat/publisher/pipeline.(*netClientWorker).run","file.name":"pipeline/client_worker.go","file.line":148},"message":"Failed to connect to backoff(monitoring(https://<address>:9200)): cannot connect underlying Elasticsearch client: Get \"https://<address>:9200\": context canceled","service.name":"filebeat","ecs.version":"1.6.0"}

```

As an additional information, downgrading Filebeat to version 8.15.0 resolved the issue.

Following, you can find also the content of the _filebeat.yml_ file related with the monitoring part (path to certificates and the hostname were redacted).

```auto
monitoring:
  enabled: true
  cluster_uuid: <uid>
  elasticsearch:
    username: ""
    hosts: ["https://<address>:9200"]
    ssl.certificate_authorities: ["/path/to/root-ca.crt"]
    ssl.certificate: "/path/to/cert.crt.pem"
    ssl.key: "/path/to/key.key.pem"

```

Can I ask if anyone has any idea of what could be causing the issue?

Thanks in advance for the help!

---

<div class="post-metadata">

**Author:** ![BBQigniter](https://avatars.discourse-cdn.com/v4/letter/b/3da27b/32.png) [@BBQigniter](https://discuss.elastic.co/u/BBQigniter)\
**Post date:** [September 16, 2024, 12:16pm UTC](https://discuss.elastic.co/t/filebeat-8-15-1-connection-error-when-writing-monitoring-data/366188/2 "2024-09-16T12:16:48Z")

</div>

having the same issue - had to rollback so that the monitoring data is finally showing up in "Stack Monitoring" - no clue what's wrong with 8.15.1

---

<div class="post-metadata">

**Author:** ![BBQigniter](https://avatars.discourse-cdn.com/v4/letter/b/3da27b/32.png) [@BBQigniter](https://discuss.elastic.co/u/BBQigniter)\
**Post date:** [September 16, 2024, 12:25pm UTC](https://discuss.elastic.co/t/filebeat-8-15-1-connection-error-when-writing-monitoring-data/366188/3 "2024-09-16T12:25:15Z")

</div>

ah, I think it's a known issue ☹

> <https://github.com/elastic/beats/issues/40705>
>
> \- Relates https://github.com/elastic/ingest-docs/pull/1312
> \- Relates https://git…hub.com/elastic/beats/pull/40767
> 
> For confirmed bugs, please report:
> \- Version: \`main\`, \`v8.15.1\`
> \- Operating System: Linux
> 
> \# Steps to reproduce
> 1. Deploy a Filebeat sending data to a remote Elasticsearch using a domain name in the configuration
> 2. Confirm Filebeat is running and sending data
> 3. Disable the network
> 4. Wait for a DNS lookup error and the publisher errors:
> \`\`\`json
> {
> "log.level": "warn",
> "@timestamp": "2024-09-06T08:30:33.240-0400",
> "log.logger": "transport",
> "log.origin": {
> "function": "github.com/elastic/elastic-agent-libs/transport.TestNetDialer.func1",
> "file.name": "transport/tcp.go",
> "file.line": 53
> },
> "message": "DNS lookup failure \\"remote-es.elastic.cloud\\": lookup remote-es.elastic.cloud: Temporary failure in name resolution",
> "service.name": "filebeat",
> "ecs.version": "1.6.0"
> }
> \`\`\`
> \`\`\`json
> {
> "log.level": "error",
> "@timestamp": "2024-09-06T15:50:15.140-0400",
> "log.logger": "publisher\_pipeline\_output",
> "log.origin": {
> "function": "github.com/elastic/beats/v7/libbeat/publisher/pipeline.(\*netClientWorker).run",
> "file.name": "pipeline/client\_worker.go",
> "file.line": 148
> },
> "message": "Failed to connect to backoff(elasticsearch(https://remote-es.elastic.cloud:443)): Get \\"https://remote-es.elastic.cloud:443\\": context canceled",
> "service.name": "filebeat",
> "ecs.version": "1.6.0"
> }
> {
> "log.level": "info",
> "@timestamp": "2024-09-06T15:50:15.140-0400",
> "log.logger": "publisher\_pipeline\_output",
> "log.origin": {
> "function": "github.com/elastic/beats/v7/libbeat/publisher/pipeline.(\*netClientWorker).run",
> "file.name": "pipeline/client\_worker.go",
> "file.line": 139
> },
> "message": "Attempting to reconnect to backoff(elasticsearch(https://remote-es.elastic.cloud:443)) with 475 reconnect attempt(s)",
> "service.name": "filebeat",
> "ecs.version": "1.6.0"
> }
> \`\`\`
> 5. Enable the network
> 6. Ensure the machine can reach the internet and the remote Elasticsearch
> 7. Filebeat will keep logging the same publisher errors and not sending data
> 
> 
> The configuration I used:
> \`\`\`yaml
> filebeat.inputs:
> - type: filestream
> id: my-filestream-id
> paths:
> - /tmp/some-logs.txt
> 
> output.elasticsearch:
> hosts: \["https://remote-es.elastic.cloud:443"\]
> username: elastic
> password: some-very-secret-password
> \`\`\`

see [Beats version 8.15.1 | Beats Platform Reference [8.15] | Elastic](https://www.elastic.co/guide/en/beats/libbeat/current/release-notes-8.15.1.html)

---

<div class="post-metadata">

**Author:** ![memir](https://avatars.discourse-cdn.com/v4/letter/m/49beb7/32.png) [@memir](https://discuss.elastic.co/u/memir)\
**Post date:** [September 16, 2024, 12:35pm UTC](https://discuss.elastic.co/t/filebeat-8-15-1-connection-error-when-writing-monitoring-data/366188/4 "2024-09-16T12:35:29Z")

</div>

Yes exactly, nearly at the same time the issue was opened on GitHub, so definitely it is a known issue.  
I will close the topic as answered since we can now wait for the fix to be released.
