DevOps
ELK Stack и логирование
Slack обрабатывает 10 миллиардов событий в день. Когда в 3 ночи падает сервис, инженер on-call открывает Kibana и за 2 минуты находит первопричину по trace_id, прошедшему через 15 микросервисов. Без structured logging и ELK это занимает часы grep-а по гигабайтам plain text файлов.
- **GitHub** использует Elasticsearch для поиска по 100+ миллиардам строк кода и логам CI/CD - кластер из 100+ нод обрабатывает тысячи запросов в секунду с ILM для контроля стоимости
- **Cloudflare** хранит DNS и HTTP логи (2 триллиона запросов в день) в Elasticsearch с ILM: горячие данные на NVMe SSD, архив в R2 через searchable snapshots
- **Uber** перешёл с plain text на structured JSON с ECS-полями - время расследования инцидентов сократилось с часов до минут за счёт корреляции по trace_id между 4000+ микросервисами
Elasticsearch
Elasticsearch - распределённый поисковый движок на базе Apache Lucene. Хранит данные в индексах, разбитых на shards (основные + реплики). Для логов используют Index Lifecycle Management (ILM): горячая фаза (SSD, последние 7 дней), тёплая (HDD, 30 дней), холодная (объектное хранилище), удаление.
Ключевые настройки: number_of_shards = количество data-нод (нельзя менять без reindex), number_of_replicas = минимум 1 (0 означает потерю данных при падении ноды). Типичный production кластер для логов: 3 master-eligible + N data nodes + 2 coordinating-only для запросов.
Что происходит с индексом Elasticsearch при переходе в warm-фазу ILM?
Logstash и Fluent Bit
Logstash - pipeline для обработки логов: input (Filebeat, Kafka, syslog) → filter (grok, mutate, drop) → output (Elasticsearch, S3). В Kubernetes чаще используют Fluent Bit (450KB RAM против 512MB+ у Logstash) как DaemonSet. Logstash остаётся там где нужна сложная трансформация данных.
Grok - это named regex паттерны для парсинга неструктурированных логов. Встроен в Logstash и Elastic. Паттерн `%{COMBINEDAPACHELOG}` парсит nginx/apache access log без написания regex вручную. Для production отладки grok-паттернов используют Kibana Dev Tools → Grok Debugger.
Почему в Kubernetes для сбора логов предпочитают Fluent Bit вместо Logstash?
Kibana
Kibana - визуализация и поиск по данным Elasticsearch. Ключевые инструменты: Discover (ad-hoc поиск с KQL), Dashboard (real-time мониторинг), Lens (drag-and-drop визуализации), Alerting (оповещения). Для DevOps особенно важны Log stream views и интеграция с APM.
KQL (Kibana Query Language) - синтаксис для поиска логов: `response:500 AND service.name:payment-api` найдёт все 500-ошибки в payment-api. `http.response_time_ms > 1000` - запросы дольше секунды. Wildcards: `user.email:*@gmail.com`. Сохранённые запросы (Saved Searches) - основа рабочих dashboard.
Что такое KQL в Kibana?
Structured Logging
Structured logging - запись логов в машиночитаемом формате (JSON) вместо plain text. Каждое поле - отдельный ключ, который Elasticsearch индексирует. `level`, `service`, `trace_id`, `user_id`, `duration_ms` - стандартные поля, позволяющие строить корреляции между сервисами без grok-парсинга.
Elastic Common Schema (ECS) стандартизирует имена полей: `@timestamp`, `log.level`, `service.name`, `http.request.method`, `http.response.status_code`, `trace.id`. Использование ECS позволяет применять готовые Kibana dashboards и правила обнаружения угроз Elastic Security без дополнительной настройки.
ELK Stack - единственный правильный выбор для логирования в production
Grafana Loki - популярная альтернатива: хранит логи в object storage (S3/GCS) и индексирует только labels, а не всё содержимое - в 10x дешевле. ELK выигрывает когда нужен полнотекстовый поиск по телу логов
Elasticsearch индексирует каждое поле каждого лога - дорого по CPU и RAM при масштабе. Loki хранит сырые логи дёшево и выдаёт их по labels - подходит для большинства use cases
Почему JSON structured logging предпочтительнее plain text в production?
Ключевые идеи
- **Elasticsearch + ILM** - хранит логи с автоматическим управлением жизненным циклом: SSD для горячих, S3 для архива, автоудаление через год
- **Logstash / Fluent Bit** - pipeline для сбора и трансформации; Fluent Bit предпочтителен в K8s DaemonSet за минимальный RAM footprint
- **Structured logging (JSON + ECS)** - основа: каждое поле индексируется, корреляция по trace_id, готовые KQL-запросы без grok
Связанные темы
Логирование работает в связке с трейсингом и инцидент-менеджментом:
- Distributed Tracing — trace.id в логах ELK связывает записи со spans в Jaeger - полная картина запроса от frontend до БД
- On-Call и Incident Management — Kibana Alerting создаёт PagerDuty инциденты при аномалиях в логах - error rate spike, latency рост
Вопросы для размышления
- Как ILM помогает контролировать расходы на хранение логов при росте трафика в 10x?
- Если сервис логирует в plain text, какие шаги нужны для перехода на structured logging без даунтайма?
- Когда Grafana Loki предпочтительнее Elasticsearch для централизованного логирования?