Integrazione ELK Stack: Sincronizzazione di Logstash, Elasticsearch e Kibana
Mantieni Logstash, Elasticsearch e Kibana allineati con pipeline, mapping, nomi degli indici, TLS e viste dati corrispondenti.
Integrazione dello Stack ELK: Sincronizzazione di Logstash, Elasticsearch e Kibana
Quando Logstash, Elasticsearch e Kibana non sono sincronizzati, i log scompaiono, le dashboard appaiono vuote o i campi mostrano il tipo sbagliato. L'integrazione dello stack ELK riguarda meno l'avvio di tre servizi e più la garanzia che i nomi degli indici, i mapping, i timestamp, le credenziali e le viste dati siano tutti concordi.
Questa guida illustra una pipeline di logging pratica: Logstash riceve gli eventi, li analizza, li invia a Elasticsearch, e Kibana legge gli indici o i flussi di dati risultanti. Gli esempi utilizzano la sintassi classica della pipeline Logstash e le API Elasticsearch che puoi eseguire da Kibana Dev Tools.
Comprendere il Flusso dei Dati
Traccia un evento attraverso lo stack:
- Logstash riceve dati da Beats, TCP, syslog, file, code o un altro input.
- I filtri di Logstash analizzano, arricchiscono, rinominano e normalizzano i campi.
- Elasticsearch indicizza l'evento utilizzando template, mapping e policy del ciclo di vita.
- Kibana interroga Elasticsearch tramite una vista dati e visualizza l'evento in Discover, dashboard, Lens o avvisi.
La maggior parte dei bug di integrazione si verifica ai confini. Logstash non riesce a connettersi, Elasticsearch rifiuta il documento o Kibana guarda la vista dati o l'intervallo di tempo sbagliato.
Configurazione di Logstash per un Flusso di Dati Pulito
Le pipeline di Logstash hanno tre blocchi principali: input, filter e output. Mantieni ogni blocco semplice e testabile.
Plugin di Input
I plugin di input comuni includono:
beats: Riceve eventi da Filebeat, Metricbeat e altri Beats.tcp/udp: Riceve eventi tramite socket di rete.file: Legge file locali. Utile per piccole distribuzioni e test, ma gli agenti sono solitamente migliori per host di produzione distribuiti.syslog: Riceve messaggi syslog.
Esempio di input Beats con TLS:
input {
beats {
port => 5044
ssl_enabled => true
ssl_certificate => "/etc/pki/tls/certs/logstash.crt"
ssl_key => "/etc/pki/tls/private/logstash.key"
}
}
Assicurati che la porta sia aperta, che il certificato corrisponda a come i client si connettono e che i nomi delle opzioni corrispondano alla versione del plugin installato. Le versioni recenti del plugin di input Beats utilizzano ssl_enabled.
Plugin di Filtro
I filtri trasformano gli eventi grezzi in campi utili. L'ordine è importante perché Logstash esegue i filtri in sequenza.
filter {
grok {
match => { "message" => "%{COMBINEDAPACHELOG}" }
}
date {
match => [ "timestamp", "dd/MMM/yyyy:HH:mm:ss Z" ]
}
mutate {
remove_field => [ "message" ]
}
}
Usa grok per testo non strutturato, date per impostare @timestamp, mutate per la pulizia dei campi e geoip quando hai bisogno di arricchimento della posizione basato su IP. Testa i pattern grok su righe di log reali prima di metterli in produzione. Un piccolo errore di analisi può inviare migliaia di eventi a Elasticsearch con campi mancanti.
Plugin di Output
Per lo stack ELK, l'output Elasticsearch è la destinazione usuale.
output {
elasticsearch {
hosts => ["https://elasticsearch-node1:9200", "https://elasticsearch-node2:9200"]
index => "my-logs-%{+YYYY.MM.dd}"
user => "logstash_writer"
password => "${LOGSTASH_ES_PASSWORD}"
ssl_enabled => true
cacert => "/etc/logstash/certs/http_ca.crt"
}
}
Il valore index è il contratto con i template Elasticsearch e le viste dati di Kibana. Se Logstash scrive my-logs-2026.05.23, il tuo template e la vista dati dovrebbero corrispondere a my-logs-*.
Per ambienti più grandi, considera i flussi di dati e la Gestione del Ciclo di Vita degli Indici invece di indici giornalieri gestiti manualmente. Se usi flussi di dati, segui le linee guida attuali di Elastic per l'output Logstash per le impostazioni data_stream piuttosto che mescolare opzioni di flusso di dati e indici classici.
Template e Mapping di Elasticsearch
Elasticsearch ha bisogno di mapping coerenti prima che i documenti arrivino. Altrimenti, il primo documento può impostare un tipo di campo che rompe gli eventi successivi. Un codice di stato che arriva prima come "200" potrebbe diventare testo o parola chiave invece di un numero.
Esempio di template di indice componibile:
PUT _index_template/my_log_template
{
"index_patterns": ["my-logs-*"],
"template": {
"settings": {
"number_of_shards": 1,
"number_of_replicas": 1
},
"mappings": {
"properties": {
"@timestamp": {"type": "date"},
"message": {"type": "text"},
"host.name": {"type": "keyword"},
"log.level": {"type": "keyword"},
"http.response.status_code": {"type": "integer"}
}
}
}
}
Usa keyword per corrispondenze esatte e aggregazioni, text per la ricerca full-text, tipi numerici per metriche e codici di stato, e date per campi temporali. Mantieni il numero di shard modesto a meno che tu non abbia una ragione misurata per aggiungerne altri. Troppi shard piccoli possono danneggiare le prestazioni del cluster.
Viste Dati di Kibana
L'interfaccia utente corrente di Kibana utilizza viste dati. Le versioni precedenti le chiamavano pattern di indici. Crea una vista dati che corrisponda ai nomi degli indici o ai flussi di dati che Elasticsearch ha effettivamente.
Configurazione tipica:
- Vai a Stack Management -> Kibana -> Data Views.
- Crea una vista dati come
my-logs-*. - Scegli
@timestampcome campo temporale. - Apri Discover e allarga il selettore temporale durante i test.
Se Discover è vuoto, non dare per scontato che Logstash abbia fallito. Controlla l'intervallo di tempo, il pattern della vista dati e se @timestamp è stato analizzato correttamente.
Risoluzione dei Problemi di Integrazione Comuni
I Dati Non Appaiono in Kibana
Controlla ogni salto:
GET _cat/indices/my-logs-*?v
GET my-logs-*/_search?size=1&sort=@timestamp:desc
Poi controlla:
- I log di Logstash per errori di connessione, autenticazione, TLS o mapping.
- I log di Elasticsearch per documenti rifiutati e fallimenti di sicurezza.
- Il pattern della vista dati di Kibana e l'intervallo di tempo selezionato.
- Se il timestamp dell'evento è nel futuro, nel passato o mancante.
I Documenti Vengono Rifiutati da Elasticsearch
I conflitti di mapping sono comuni. Ad esempio, un evento invia http.response.status_code come 200, mentre un altro invia "OK". Elasticsearch non può memorizzare entrambi in un campo integer.
Correggi il filtro Logstash in modo che il campo sia tipizzato in modo coerente, o instrada gli eventi errati a un indice separato per la revisione. Non continuare a eliminare e ricreare indici senza correggere la pipeline che crea i documenti errati.
Logstash Utilizza Troppa CPU
Pattern grok costosi, volume elevato di eventi e grandi eventi multilinea possono aumentare rapidamente la CPU di Logstash. Inizia misurando quale pipeline è occupata, poi semplifica i pattern, ancora le regex e sposta l'analisi semplice a Beats o alle pipeline di ingest di Elasticsearch quando è più facile da gestire.
Le Query di Kibana Sono Lente
Le dashboard lente spesso derivano da intervalli di tempo ampi, aggregazioni ad alta cardinalità, troppi shard o campi mappati come text quando Kibana ha bisogno di keyword. Usa impostazioni predefinite della dashboard più ristrette, rollover ILM e mapping dei campi che corrispondono alle tue visualizzazioni.
Conclusione
Tratta l'integrazione dello stack ELK come un contratto tra tre livelli. Logstash deve emettere campi prevedibili, Elasticsearch deve mapparli e memorizzarli correttamente, e Kibana deve interrogare la vista dati giusta nell'intervallo di tempo giusto. Quando qualcosa si rompe, segui un singolo evento di esempio dall'input all'indice alla dashboard.