Filebeat 7.10.2 "Unexpected Build Flavor"

[Zero Two]

Greetings:

I had posted earlier about the fact that new indices are no longer being created and alerts are not being written to Wazuh-Indexer.  No one replied so I ventured out on my own.  I have completely  reinstalled Wazuh-Server and Filebeat.  Everything seems to be fine but, same issue.  This is the lone error I have been able to track down:

Apr 21 18:35:17 wazuhmanager-0 filebeat[35230]: {"log.level":"info","@timestamp":"2025-04-21T18:35:17.626Z","log.logger":"esclientleg","log.origin":{"function":"github.com/elastic/beats/v7/libbeat/esleg/eslegclient.(*Connection).getVersion","file.name":"eslegclient/connection.go","file.line":453},"message":"Got unexpected build flavor ''","service.name":"filebeat","ecs.version":"1.6.0"}

(repeated infinitum)

And thats about it. 

Any ideas?

[Gonzalo Acuña]

Hi.
Please, answer the following questions:
1. What Wazuh version have you installed? Can you share the output of the following commands? (run them on every central component host of the environment)
- `apt list --installed | grep wazuh` | `rpm-qa | grep wazuh`
- `apt list --installed | grep filebeat` | `rpm-qa | grep filebeat`
2. In the Wazuh manager host, run the following command and share the output:
- `filebeat test output`
3. What steps did you follow to install?

[Zero Two]

Gonzalo:

Thank you for your response.  To answer your questions:

1. root@wazuhmanager-0:~# filebeat version
filebeat version 7.10.2 (amd64), libbeat 7.10.2 [aacf9ecd9c494aa0908f61fbca82c906b16562a8 built 2021-01-12 22:10:33 +0000 UTC]

root@pve2:~/scripts# ./check_wazuh.sh
=== Checking Wazuh packages in CTID 308 ===
--> apt list --installed | grep wazuh
wazuh-indexer/stable,now 4.11.2-1 amd64 [installed]
--> rpm -qa | grep wazuh

=== Checking Wazuh packages in CTID 802 ===
--> apt list --installed | grep wazuh
wazuh-indexer/stable,now 4.11.2-1 amd64 [installed]
--> rpm -qa | grep wazuh

=== Checking Wazuh packages in CTID 803 ===
--> apt list --installed | grep wazuh
wazuh-indexer/stable,now 4.11.2-1 amd64 [installed]
--> rpm -qa | grep wazuh

=== Checking Wazuh packages in CTID 804 ===
--> apt list --installed | grep wazuh
wazuh-indexer/stable,now 4.11.2-1 amd64 [installed]
--> rpm -qa | grep wazuh

=== Checking Wazuh packages in CTID 805 ===
--> apt list --installed | grep wazuh
wazuh-manager/stable,now 4.11.2-1 amd64 [installed]
--> rpm -qa | grep wazuh

=== Checking Wazuh packages in CTID 806 ===
--> apt list --installed | grep wazuh
wazuh-dashboard/stable,now 4.11.2-1 amd64 [installed]
--> rpm -qa | grep wazuh

2. root@wazuhmanager-0:~# filebeat test output

elasticsearch: https://192.168.88.2:9200...
  parse url... OK
  connection...
    parse host... OK
    dns lookup... OK
    addresses: 192.168.88.2
    dial up... OK
  TLS...
    security: server's certificate chain verification is enabled
    handshake... OK
    TLS version: TLSv1.3
    dial up... OK
  talk to server... OK
  version: 7.10.2
elasticsearch: https://192.168.88.3:9200...
  parse url... OK
  connection...
    parse host... OK
    dns lookup... OK
    addresses: 192.168.88.3
    dial up... OK
  TLS...
    security: server's certificate chain verification is enabled
    handshake... OK
    TLS version: TLSv1.3
    dial up... OK
  talk to server... OK
  version: 7.10.2
elasticsearch: https://192.168.88.4:9200...
  parse url... OK
  connection...
    parse host... OK
    dns lookup... OK
    addresses: 192.168.88.4
    dial up... OK
  TLS...
    security: server's certificate chain verification is enabled
    handshake... OK
    TLS version: TLSv1.3
    dial up... OK
  talk to server... OK
  version: 7.10.2
elasticsearch: https://192.168.88.8:9200...
  parse url... OK
  connection...
    parse host... OK
    dns lookup... OK
    addresses: 192.168.88.8
    dial up... OK
  TLS...
    security: server's certificate chain verification is enabled
    handshake... OK
    TLS version: TLSv1.3
    dial up... OK
  talk to server... OK
  version: 7.10.2

3. I did the official Wazuh step-by-step instructions as provided on the website.  It is important to note that this installation by way of those instructions had been working from October 2024 until early April 2025 (within incremental upgrades within 2 weeks of release, usually)

[Gonzalo Acuña]

Hi.
I was not able to reproduce that Filebeat log message.
The output of the commands looks fine.
Can you restart the Filebeat service and then share the /var/log/filebeat/filebeat log from the restart?

Regards.

Gonzalo.

[Zero Two]

Gonzalo:

I feel this issue has succumb to the irresistible force of IT magic where the mere mention of the issue followed by acknowledgment by a professional is enough to correct the issue.

I woke up this morning to find a new index had been created and it appears logs are being written to the indexers, again. 

Further, per your request, here is the filebeat output:

root@wazuhmanager-0:~# systemctl status filebeat.service
● filebeat.service - Filebeat sends log files to Logstash or directly to Elasticsearch.
     Loaded: loaded (/lib/systemd/system/filebeat.service; enabled; preset: enabled)
     Active: active (running) since Tue 2025-04-22 14:57:14 UTC; 2s ago
       Docs: https://www.elastic.co/products/beats/filebeat
   Main PID: 233745 (filebeat)
      Tasks: 13 (limit: 153736)
     Memory: 20.9M
        CPU: 125ms
     CGroup: /system.slice/filebeat.service
             └─233745 /usr/share/filebeat/bin/filebeat --environment systemd -c /etc/filebeat/filebeat.yml --path.home /usr/share/filebeat ->

Apr 22 14:57:14 wazuhmanager-0 systemd[1]: Started filebeat.service - Filebeat sends log files to Logstash or directly to Elasticsearch..

root@wazuhmanager-0:~# tail -f /var/log/filebeat/filebeat
2025-04-22T14:57:16.197Z INFO [index-management] idxmgmt/std.go:298 Loaded index template.
2025-04-22T14:57:16.200Z INFO [publisher_pipeline_output] pipeline/output.go:151 Connection to backoff(elasticsearch(https://192.168.88.4:9200)) established
2025-04-22T14:57:16.201Z INFO [esclientleg] eslegclient/connection.go:314 Attempting to connect to Elasticsearch version 7.10.2
2025-04-22T14:57:16.203Z INFO template/load.go:97 Template wazuh already exists and will not be overwritten.
2025-04-22T14:57:16.203Z INFO [index-management] idxmgmt/std.go:298 Loaded index template.
2025-04-22T14:57:16.206Z INFO [publisher_pipeline_output] pipeline/output.go:151 Connection to backoff(elasticsearch(https://192.168.88.8:9200)) established
2025-04-22T14:57:16.207Z INFO [esclientleg] eslegclient/connection.go:314 Attempting to connect to Elasticsearch version 7.10.2
2025-04-22T14:57:16.208Z INFO template/load.go:97 Template wazuh already exists and will not be overwritten.
2025-04-22T14:57:16.209Z INFO [index-management] idxmgmt/std.go:298 Loaded index template.
2025-04-22T14:57:16.212Z INFO [publisher_pipeline_output] pipeline/output.go:151 Connection to backoff(elasticsearch(https://192.168.88.2:9200)) established

That said, the number of alerts I am receiving seems suspiciously low.  How would I verify whether any specific agent is having issues communicating or whether any alerts are being dropped rather than written?

[Zero Two]

Yes, there is definitely something still wrong.  My integrations log is completely empty despite having several integrations.  I know the integrations are "working" because I Have one that sends notifications to NTFY and while I have notifications in NTFY, I don't have any evidence of the corresponding events in the Wazuh Dashboard.

[Gonzalo Acuña]

Hi.
You will need to verify the agents' status; you can do this from the Wazuh dashboard Agents page.
Also, verify the agents' logs. If all the agents are active, you can determine what agents are not generating alerts by filtering by agent name or ID from the Wazuh dashboard Discover section.
Also, please verify if the Wazuh manager processes are up and running. You can do this by running the /var/ossec/bin/wazuh-control status command in the Wazuh manager host.
Please, share the findings/output.

Regards.
Gonzalo.