Guida: Risolvere i problemi di Filebeat nell’analisi dei log Mirth per Kibana

Ho pensato di analizzare i log di Mirth e rappresentarli con una applicazione Kibana per poter avere una visione d’insieme del funzionamento dei canali.
In questo articolo, esploreremo la soluzione a un problema riscontrato durante l’elaborazione dei log di Mirth usando Filebeat per la’anlidi dei log e l’invio a Elasticsearch, evidenziando le cause dei fallimenti e le azioni risolutive adottate.

Lo stack Elastic: Filebeat – Elasticsearch – Kibana

Kibana, Filebeat ed Elasticsearch sono componenti chiave all’interno dello stack Elastic, e ognuno di essi svolge un ruolo cruciale nel ciclo di gestione e visualizzazione dei log.

1. Filebeat: È il primo elemento della catena e si occupa della raccolta dei log da varie fonti (file di log, syslog, ecc.). Filebeat legge i log e li invia a Elasticsearch per l’indicizzazione, seguendo specifiche configurazioni e pipeline di elaborazione (tokenizer, dissect, ecc.). Nel nostro caso, Filebeat è stato configurato per raccogliere i log di Mirth, applicare un tokenizer, e inviare i dati elaborati a Elasticsearch.
2. Elasticsearch: Una volta che Filebeat invia i log, Elasticsearch li indicizza, rendendoli ricercabili e pronti per essere visualizzati. Elasticsearch archivia i dati e fornisce capacità di ricerca e analisi avanzate. Ogni documento inviato da Filebeat viene elaborato attraverso pipeline di indicizzazione per aggiungere campi e strutturare i dati in modo ottimale per le query successive.
3. Kibana: È l’interfaccia visiva per esplorare i dati indicizzati in Elasticsearch. Con Kibana, è possibile creare dashboard, eseguire ricerche avanzate, analizzare i log in tempo reale e visualizzare metriche. Nel nostro caso, abbiamo utilizzato Kibana per verificare se i campi tokenizzati da Filebeat (come logtime e loglevel) venivano indicizzati correttamente e per monitorare i risultati della pipeline di Filebeat.

La relazione tra questi componenti è stretta: Filebeat raccoglie ed elabora i dati, Elasticsearch li indicizza e li rende disponibili per la ricerca, e Kibana fornisce gli strumenti per visualizzarli e analizzarli. Quando uno dei componenti non funziona correttamente, come nel nostro caso con Filebeat, l’intero flusso di dati ne risente, e il troubleshooting può diventare complesso. Tuttavia, una volta che il flusso è ripristinato, l’integrazione tra questi strumenti offre una piattaforma potente e scalabile per la gestione e l’analisi dei log.

Risolvere l’Errore “Failed to Access State” in Filebeat

Recentemente, abbiamo affrontato un problema critico con Filebeat che non riusciva a partire, ripetendo continuamente un errore legato all’accesso al file di stato meta.json.

# journalctl -u filebeat -b
ott 03 17:08:00 poleni systemd[1]: filebeat.service: Failed with result 'exit-code'.
ott 03 17:08:01 poleni systemd[1]: filebeat.service: Scheduled restart job, restart counter is at 1.
ott 03 17:08:01 poleni systemd[1]: Stopped Filebeat sends log files to Logstash or directly to Elasticsearch..
ott 03 17:08:01 poleni systemd[1]: Started Filebeat sends log files to Logstash or directly to Elasticsearch..
ott 03 17:08:01 poleni filebeat[33176]: Exiting: Failed to access state when attempting take over: failed to open store 'filebeat': open /var/lib/filebeat/registry/filebeat/meta.json: no such file or directory
.....
ott 03 17:08:01 poleni systemd[1]: filebeat.service: Failed with result 'exit-code'.
ott 03 17:08:02 poleni systemd[1]: filebeat.service: Scheduled restart job, restart counter is at 5.
ott 03 17:08:02 poleni systemd[1]: Stopped Filebeat sends log files to Logstash or directly to Elasticsearch..
ott 03 17:08:02 poleni systemd[1]: filebeat.service: Start request repeated too quickly.
ott 03 17:08:02 poleni systemd[1]: filebeat.service: Failed with result 'exit-code'.
ott 03 17:08:02 poleni systemd[1]: Failed to start Filebeat sends log files to Logstash or directly to Elasticsearch..

Anche arrestando il servizio, lo stato continuava a rimanere “failed” invece di passare a “dead“, complicando la risoluzione del problema:

root@poleni:/etc/filebeat# systemctl stop filebeat
root@poleni:/etc/filebeat# systemctl status filebeat
× filebeat.service - Filebeat sends log files to Logstash or directly to Elasticsearch.
     Loaded: loaded (/lib/systemd/system/filebeat.service; enabled; vendor preset: enabled)
     Active: failed (Result: exit-code) since Thu 2024-10-03 17:02:03 CEST; 5min ago
       Docs: https://www.elastic.co/beats/filebeat
   Main PID: 31207 (code=exited, status=1/FAILURE)
        CPU: 104ms

Sintomi

Ogni volta che si tentava di avviare Filebeat, nel log appariva il seguente messaggio:

Exiting: Failed to access state when attempting take over: failed to open store 'filebeat': open /var/lib/filebeat/registry/filebeat/meta.json: no such file or directory

Questo errore si ripeteva rapidamente fino a raggiungere il limite di tentativi, facendo fallire il servizio dopo cinque ripartenze consecutive.

Diagnosi e Risoluzione

1. File di Stato Corrotto: Il problema principale risiedeva nel file di stato /var/lib/filebeat/registry/filebeat/meta.json, che risultava corrotto o mancante. Anche arrestando il servizio, lo stato non passava a “dead” come ci si aspettava.
2. Eliminare il File di Stato: La svolta è arrivata quando abbiamo eliminato completamente la directory del registro di stato con il comando:

   sudo rm -rf /var/lib/filebeat/registry/filebeat

Questo ha forzato Filebeat a ricreare il file di stato da zero, rimuovendo ogni traccia di configurazioni o stati corrotti.

3. Riavvio del Servizio: Una volta eliminata la directory di stato, abbiamo riavviato correttamente il servizio:

   sudo systemctl start filebeat

4. Verifica del Funzionamento: Dopo il riavvio, Filebeat ha creato correttamente un nuovo file meta.json, e il servizio ha iniziato a funzionare normalmente senza più ripetere l’errore.

Lezioni Apprese

• Stati Persistenti: Filebeat utilizza lo stato per tenere traccia dei file e delle loro posizioni, ma se lo stato diventa corrotto, può impedire il corretto avvio del servizio.
• Controllare lo Stato del Servizio: Anche quando si arresta il servizio, è fondamentale verificare che lo stato sia passato correttamente a “dead” e non rimanga bloccato in “failed”. In questo caso, l’errore ripetuto era dovuto al tentativo automatico di Filebeat di riavviarsi.
• Ripulire Manualmente lo Stato: Quando Filebeat non si avvia e continua a fallire ripetutamente, eliminare lo stato può essere una soluzione rapida e efficace.