Кейс: Elastic Stack (ELK)

Связь с легендой: ../../legend/LEGEND.md — раздел «АО ТНИИС», централизованный сбор и анализ логов в дополнение к метрикам из Prometheus.

Что нужно реально сделать (домашний стенд)

Docker Compose стенд Elasticsearch + Kibana + Filebeat, собирающий логи уже готового кейса ../nginx/CASE.md — реальная связка «есть логи → собрали → увидели в Kibana», а не абстрактный пример.

1. docker-compose.yml

version: "3.8"

services:
  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:8.13.0
    container_name: elasticsearch
    environment:
      - discovery.type=single-node
      - xpack.security.enabled=false
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
    ports:
      - "9200:9200"

  kibana:
    image: docker.elastic.co/kibana/kibana:8.13.0
    container_name: kibana
    environment:
      - ELASTICSEARCH_HOSTS=http://elasticsearch:9200
    ports:
      - "5601:5601"
    depends_on:
      - elasticsearch

  filebeat:
    image: docker.elastic.co/beats/filebeat:8.13.0
    container_name: filebeat
    user: root
    volumes:
      - ./filebeat.yml:/usr/share/filebeat/filebeat.yml:ro
      - nginx_logs:/var/log/nginx:ro
    depends_on:
      - elasticsearch

volumes:
  nginx_logs:

Чтобы подключить реальные логи из кейса ../nginx/CASE.md, в его docker-compose.yml у сервиса proxy нужно смонтировать тот же named volume nginx_logs на /var/log/nginx — тогда Filebeat читает те же файлы логов, что пишет живой nginx.

2. filebeat.yml

filebeat.inputs:
  - type: log
    enabled: true
    paths:
      - /var/log/nginx/access.log
    fields:
      service: nginx-lab

output.elasticsearch:
  hosts: ["elasticsearch:9200"]
  index: "nginx-logs-%{+yyyy.MM.dd}"

setup.template.name: "nginx-logs"
setup.template.pattern: "nginx-logs-*"

3. Шаги воспроизведения

В ../nginx/CASE.md настроить access_log в формате, откуда легко выделить статус-код (стандартный combined-формат nginx это уже делает).
docker compose up -d для обоих стендов (или объединить в один docker-compose.yml).
Сгенерировать трафик через nginx-стенд (curl в цикле из шагов ../nginx/CASE.md), чтобы появились строки в access.log.
Проверить, что данные дошли: curl http://localhost:9200/nginx-logs-*/_search?pretty.
В Kibana (localhost:5601) создать index pattern nginx-logs-*, зайти в Discover — увидеть живые записи логов.
Построить простую визуализацию: количество запросов по HTTP-статус-коду (парсинг статуса из строки лога через встроенный nginx module Filebeat или простой grok-подобный dissect-фильтр).

4. Простой parse-фильтр для нестандартных логов

processors:
  - dissect:
      tokenizer: '%{client_ip} - - [%{@timestamp}] "%{method} %{url} %{http_version}" %{status_code} %{bytes}'
      field: "message"
      target_prefix: ""

dissect — более простой и быстрый аналог grok для логов со стабильным, предсказуемым форматом (не требует регулярных выражений, работает через явные разделители) — здесь разбирает стандартную строку access-лога nginx на отдельные поля (status_code, method, url), которые дальше можно фильтровать и агрегировать в Kibana.

Что это даёт в разговоре с интервьюером

Реально собранная связка «источник логов (nginx) → shipper (Filebeat) → хранилище/поиск (Elasticsearch) → визуализация (Kibana)».
Понимание, зачем нужен index pattern и что такое shard/index на базовом уровне (см. QUESTIONS.md).
Понимание разницы Filebeat (лёгкий shipper, просто пересылает строки/файлы) vs Logstash (тяжёлый обработчик с богатыми фильтрами — grok, mutate, конвертация форматов).
Практика простого dissect/parse-фильтра для структурирования сырых текстовых логов.

Как это ложится в легенду

ELK упоминается в стеке отдела АО ТНИИС как часть инфраструктуры сопровождения, дополняющая метрики. Кейс замыкает цепочку с уже проработанным Nginx-кейсом — те же логи, которые нужно было бы разбирать вручную, теперь централизованно собираются и доступны для поиска и визуализации.

5.6 KiB Raw Blame History Unescape Escape