Интеграция стека ELK: Синхронизация Logstash, Elasticsearch и Kibana
Поддерживайте согласованность Logstash, Elasticsearch и Kibana с помощью соответствующих конвейеров, маппингов, имен индексов, TLS и представлений данных.
Интеграция стека ELK: синхронизация Logstash, Elasticsearch и Kibana
Когда Logstash, Elasticsearch и Kibana рассинхронизированы, логи исчезают, панели мониторинга выглядят пустыми, а поля отображаются с неправильным типом. Интеграция стека ELK заключается не столько в запуске трех сервисов, сколько в обеспечении согласованности имен индексов, маппингов, временных меток, учетных данных и представлений данных.
Это руководство описывает практический конвейер логирования: Logstash получает события, разбирает их, отправляет в Elasticsearch, а Kibana считывает результирующие индексы или потоки данных. Примеры используют классический синтаксис конвейера Logstash и API Elasticsearch, которые можно запускать из Kibana Dev Tools.
Понимание потока данных
Проследите одно событие через стек:
- Logstash получает данные от Beats, TCP, syslog, файлов, очередей или другого источника.
- Фильтры Logstash разбирают, обогащают, переименовывают и нормализуют поля.
- Elasticsearch индексирует событие, используя шаблоны, маппинги и политики жизненного цикла.
- Kibana запрашивает Elasticsearch через представление данных и отображает событие в Discover, панелях мониторинга, Lens или оповещениях.
Большинство ошибок интеграции возникают на границах. Logstash не может подключиться, Elasticsearch отклоняет документ, или Kibana смотрит на неправильное представление данных или временной диапазон.
Конфигурация Logstash для чистого потока данных
Конвейеры Logstash имеют три основных блока: input, filter и output. Делайте каждый блок простым и тестируемым.
Плагины ввода
Распространенные плагины ввода включают:
beats: Получает события от Filebeat, Metricbeat и других Beats.tcp/udp: Получает события через сетевые сокеты.file: Читает локальные файлы. Это полезно для небольших развертываний и тестов, но для распределенных производственных хостов обычно лучше использовать агенты.syslog: Получает сообщения syslog.
Пример ввода Beats с TLS:
input {
beats {
port => 5044
ssl_enabled => true
ssl_certificate => "/etc/pki/tls/certs/logstash.crt"
ssl_key => "/etc/pki/tls/private/logstash.key"
}
}
Убедитесь, что порт открыт, сертификат соответствует тому, как клиенты подключаются, а имена параметров соответствуют установленной версии плагина. В последних версиях плагина ввода Beats используется ssl_enabled.
Плагины фильтров
Фильтры превращают необработанные события в полезные поля. Порядок имеет значение, поскольку Logstash выполняет фильтры последовательно.
filter {
grok {
match => { "message" => "%{COMBINEDAPACHELOG}" }
}
date {
match => [ "timestamp", "dd/MMM/yyyy:HH:mm:ss Z" ]
}
mutate {
remove_field => [ "message" ]
}
}
Используйте grok для неструктурированного текста, date для установки @timestamp, mutate для очистки полей и geoip, когда требуется обогащение на основе IP-адреса. Тестируйте шаблоны grok на реальных строках логов перед внедрением в производство. Небольшая ошибка разбора может привести к отправке тысяч событий в Elasticsearch с отсутствующими полями.
Плагин вывода
Для стека ELK вывод Elasticsearch является обычным назначением.
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"
}
}
Значение index является контрактом с шаблонами Elasticsearch и представлениями данных Kibana. Если Logstash записывает my-logs-2026.05.23, ваш шаблон и представление данных должны соответствовать my-logs-*.
Для более крупных сред рассмотрите потоки данных и управление жизненным циклом индексов вместо ручного управления ежедневными индексами. Если вы используете потоки данных, следуйте текущим рекомендациям Elastic по выводу Logstash для настроек data_stream, а не смешивайте параметры потока данных и классического индекса.
Шаблоны и маппинги Elasticsearch
Elasticsearch нуждается в согласованных маппингах до поступления документов. В противном случае первый документ может установить тип поля, который нарушит последующие события. Код состояния, который сначала поступает как "200", может стать текстом или ключевым словом вместо числа.
Пример составляемого шаблона индекса:
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"}
}
}
}
}
Используйте keyword для точного сопоставления и агрегаций, text для полнотекстового поиска, числовые типы для метрик и кодов состояния и date для временных полей. Поддерживайте скромное количество шардов, если у вас нет обоснованной причины для их увеличения. Слишком много маленьких шардов может ухудшить производительность кластера.
Представления данных Kibana
Текущий интерфейс Kibana использует представления данных. В старых версиях они назывались шаблонами индексов. Создайте представление данных, которое соответствует именам индексов или потоков данных, которые фактически есть в Elasticsearch.
Типичная настройка:
- Перейдите в Stack Management -> Kibana -> Data Views.
- Создайте представление данных, например
my-logs-*. - Выберите
@timestampв качестве поля времени. - Откройте Discover и расширьте выбор времени при тестировании.
Если Discover пуст, не предполагайте, что Logstash не сработал. Проверьте временной диапазон, шаблон представления данных и правильность разбора @timestamp.
Устранение распространенных проблем интеграции
Данные не отображаются в Kibana
Проверьте каждый шаг:
GET _cat/indices/my-logs-*?v
GET my-logs-*/_search?size=1&sort=@timestamp:desc
Затем проверьте:
- Логи Logstash на наличие ошибок подключения, аутентификации, TLS или маппинга.
- Логи Elasticsearch на наличие отклоненных документов и ошибок безопасности.
- Шаблон представления данных Kibana и выбранный временной диапазон.
- Находится ли временная метка события в будущем, прошлом или отсутствует.
Документы отклоняются Elasticsearch
Конфликты маппинга распространены. Например, одно событие отправляет http.response.status_code как 200, а другое — как "OK". Elasticsearch не может хранить оба значения в поле integer.
Исправьте фильтр Logstash, чтобы поле было последовательно типизировано, или направляйте плохие события в отдельный индекс для проверки. Не удаляйте и не пересоздавайте индексы без исправления конвейера, который создает плохие документы.
Logstash использует слишком много CPU
Дорогостоящие шаблоны grok, высокий объем событий и большие многострочные события могут быстро увеличить загрузку CPU Logstash. Начните с измерения того, какой конвейер загружен, затем упростите шаблоны, закрепите регулярные выражения и перенесите простой разбор на Beats или конвейеры приема Elasticsearch, когда это проще в эксплуатации.
Запросы Kibana медленные
Медленные панели мониторинга часто возникают из-за широких временных диапазонов, агрегаций с высокой кардинальностью, слишком большого количества шардов или полей, отображаемых как text, когда Kibana требуется keyword. Используйте более узкие настройки панели мониторинга по умолчанию, ILM rollover и маппинги полей, соответствующие вашим визуализациям.
Вывод
Относитесь к интеграции стека ELK как к контракту между тремя уровнями. Logstash должен генерировать предсказуемые поля, Elasticsearch должен правильно их отображать и хранить, а Kibana должна запрашивать правильное представление данных в правильном временном диапазоне. Когда что-то ломается, проследите одно примерное событие от ввода до индекса и панели мониторинга.