Централізоване логування: чому це критично для веб-застосунків
Після чергового інциденту на продакшені з 5xx помилками ми витратили 3 години, перебираючи логи на десяти серверах. Це повторювалося щомісяця. Коли веб-застосунок обслуговує тисячі користувачів, логи генеруються у величезних обсягах — до 50 ГБ на день на 10 серверах. Без централізації знайти помилку — як голку в копиці сіна. ELK Stack вирішує цю проблему: всі логи стікаються в єдине сховище з пошуком за секунди. У нашій практиці час інциденту скорочується на 70% після впровадження ELK. Алерти в Telegram сигналізують про 5xx, повільні запити, помилки застосунку. Ми беремо на себе повний цикл: від розгортання Elasticsearch до дашбордів і алертів. Строк — від 2 до 7 днів залежно від складності.
Як ELK Stack вирішує проблеми збору та аналізу логів?
ELK — це зв'язка Elasticsearch (зберігання та пошук), Logstash (парсинг та трансформація) і Kibana (візуалізація). Filebeat доставляє логи з серверів. У результаті ви отримуєте єдину точку входу для всіх логів, що значно спрощує моніторинг логів та пошук помилок.
Вибір схеми: ELK vs EFK vs без Logstash
| Схема | Складність | Продуктивність | Гнучкість |
|---|---|---|---|
| ELK | Висока | Середня | Висока |
| EFK | Середня | Вища | Середня |
| Без Logstash | Низька | Висока | Низька |
Logstash виграє в можливостях: парсить старі формати логів за допомогою grok, збагачує дані (geoip, useragent). У 80% проектів використовуємо його. Однак Ingest Pipelines Elasticsearch швидші: обробляють до 15 000 подій/с — у 3 рази більше, ніж Logstash (5 000). Але Logstash справляється з неструктурованими даними, де Ingest безсилий.
Як ми налаштовуємо ELK під ваш проект
Docker Compose для тестового середовища
Використовуємо такий compose-файл:
version: '3.8'
services:
elasticsearch:
image: docker.elastic.co/elasticsearch/elasticsearch:8.13.0
environment:
- discovery.type=single-node
- xpack.security.enabled=true
- xpack.security.http.ssl.enabled=false
- ELASTIC_PASSWORD=changeme
- "ES_JAVA_OPTS=-Xms2g -Xmx2g"
volumes:
- esdata:/usr/share/elasticsearch/data
ports:
- "9200:9200"
ulimits:
memlock:
soft: -1
hard: -1
kibana:
image: docker.elastic.co/kibana/kibana:8.13.0
environment:
- ELASTICSEARCH_HOSTS=http://elasticsearch:9200
- ELASTICSEARCH_USERNAME=kibana_system
- ELASTICSEARCH_PASSWORD=changeme
ports:
- "5601:5601"
depends_on:
- elasticsearch
logstash:
image: docker.elastic.co/logstash/logstash:8.13.0
volumes:
- ./logstash/pipeline:/usr/share/logstash/pipeline
- ./logstash/config/logstash.yml:/usr/share/logstash/config/logstash.yml
ports:
- "5044:5044"
- "5000:5000"
depends_on:
- elasticsearch
volumes:
esdata:
Logstash Pipeline: парсинг Nginx access та JSON-логів
input {
beats { port => 5044 }
tcp { port => 5000; codec => json_lines }
}
filter {
if [fields][log_type] == "nginx_access" {
grok { match => { "message" => '%{IPORHOST:client_ip} - %{DATA:user} \[%{HTTPDATE:timestamp}\] "%{WORD:method} %{DATA:request} HTTP/%{NUMBER:http_version}" %{NUMBER:status_code:int} %{NUMBER:bytes_sent:int} "%{DATA:referrer}" "%{DATA:user_agent}" %{NUMBER:request_time:float}' } }
date { match => ["timestamp", "dd/MMM/yyyy:HH:mm:ss Z"]; target => "@timestamp" }
geoip { source => "client_ip"; target => "geoip" }
useragent { source => "user_agent"; target => "ua" }
mutate { remove_field => ["message", "timestamp"] }
}
if [fields][log_type] == "app_json" {
json { source => "message"; target => "app" }
mutate { remove_field => ["message"] }
}
}
output {
if [fields][log_type] == "nginx_access" {
elasticsearch { hosts => ["http://elasticsearch:9200"]; user => "elastic"; password => "changeme"; index => "nginx-access-%{+YYYY.MM.dd}" }
} else {
elasticsearch { hosts => ["http://elasticsearch:9200"]; user => "elastic"; password => "changeme"; index => "app-logs-%{+YYYY.MM.dd}" }
}
}
Відправка логів з Laravel
Через кастомний Monolog handler:
class LogstashLogger
{
public function __invoke(array $config): Logger
{
$handler = new SocketHandler("tcp://{$config['host']}:{$config['port']}");
$handler->setFormatter(new JsonFormatter());
return new Logger('app', [$handler]);
}
}
Тепер Log::error(...) відправляє JSON напряму в Logstash.
На одному з проектів з навантаженням 10 000 RPS ми налаштували кластер Elasticsearch з 3 нод з ILM і Logstash з grok-патернами для парсингу специфічних логів застосунку. В результаті час пошуку помилки скоротився з 40 хвилин до 10 секунд. Це дозволило команді швидше реагувати на інциденти та знизити середній час відновлення (MTTR) на 65%.
Чому ILM обов'язковий?
Без ILM індекси неконтрольовано ростуть, і через місяць диск забитий. Налаштовуємо політику: hot (5 ГБ або 1 день) → warm (3 дні) → cold (30 днів) → delete (90 днів). Все через шаблон індексу. Це основа економічного зберігання логів. Додатково можна налаштувати rollover за розміром або віком, щоб уникнути перевантаження вузлів.
Продуктивність Elasticsearch: поради з практики
- Heap — не більше 50% RAM і не більше 31 ГБ (через compressed oops)
- Кількість шардів: 1 шард ≈ 20–40 ГБ даних. Oversharding — часта помилка
- Slow log:
index.search.slowlog.threshold.query.warn: 2s - Заборона свопу:
bootstrap.memory_lock: true
Порівняння: Logstash vs Ingest Pipelines
| Параметр | Logstash | Ingest Pipelines |
|---|---|---|
| Продуктивність | ~5 тис. подій/с | ~15 тис. подій/с |
| Гнучкість | Grok, enrich, маршрутизація | Тільки прості парсинги |
| Складність | Потребує налаштування сервера | Вбудований в ES |
Для складних трансформацій Logstash незамінний. Вбудовані pipeline-процесори справляються з типовими завданнями, але не вміють працювати з довільними текстовими патернами.
Що входить у налаштування ELK
- Розгортання кластера Elasticsearch з оптимальними налаштуваннями (шарди, ILM, безпека)
- Конфігурація Logstash для парсингу Nginx, PHP і прикладних логів
- Підключення Filebeat на всіх серверах
- Створення дашбордів у Kibana для моніторингу логів (5xx, latency, traffic)
- Налаштування ILM для економії дискового простору
- Інтеграція алертів у Telegram або Email
- Документація з експлуатації та навчання команди
Процес роботи
- Аналітика — вивчаємо поточні логи, джерела, вимоги до зберігання
- Проєктування — обираємо схему (ELK/EFK), намічаємо ILM і дашборди
- Реалізація — розгортаємо кластер, налаштовуємо конвеєри
- Тестування — перевіряємо надходження даних, алерти, час пошуку
- Деплой — впроваджуємо в продакшен, передаємо документацію
Гарантуємо SLA 99.9% для кластера. Наші інженери мають досвід понад 5 років і реалізували 30+ проєктів. Отримайте консультацію з налаштування ELK під ваш проєкт. Заплануйте впровадження ELK та скоротіть час пошуку помилок.