Централизованное логирование с ELK Stack для веб-приложений

Централизованное логирование: почему это критично для веб-приложений

После очередного инцидента на продакшене с 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

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 незаменим. Встроенные pipeline-процессоры справляются с типовыми задачами, но не умеют работать с произвольными текстовыми паттернами.

Что входит в настройку ELK

• Развёртывание кластера Elasticsearch с оптимальными настройками (шарды, ILM, безопасность)
• Конфигурация Logstash для парсинга Nginx, PHP и прикладных логов
• Подключение Filebeat на всех серверах
• Создание дашбордов в Kibana для мониторинга логов (5xx, latency, traffic)
• Настройка ILM для экономии дискового пространства
• Интеграция алертов в Telegram или Email
• Документация по эксплуатации и обучение команды

Процесс работы

1. Аналитика — изучаем текущие логи, источники, требования к хранению
2. Проектирование — выбираем схему (ELK/EFK), намечаем ILM и дашборды
3. Реализация — развёртываем кластер, настраиваем конвейеры
4. Тестирование — проверяем поступление данных, алерты, время поиска
5. Деплой — внедряем в продакшен, передаём документацию

Гарантируем SLA 99.9% для кластера. Наши инженеры имеют опыт более 5 лет и реализовали 30+ проектов. Получите консультацию по настройке ELK под ваш проект. Запланируйте внедрение ELK и сократите время поиска ошибок.

Elasticsearch Guide