Настройка централизованного логирования через ELK Stack — под ключ

Отметим: когда приложение разбросано по десяти подам в Kubernetes и что-то падает в нерабочее время, последовательный перебор kubectl logs — не вариант. Централизованное логирование на основе ELK Stack (Elasticsearch + Logstash + Kibana) давно стало стандартом для отладки и мониторинга. Типичная стоимость хранения неструктурированных логов на облачных дисках может составлять до 30% бюджета на инфраструктуру — правильная архитектура снижает эти затраты вдвое.

Например, когда payments-api падает с ошибкой 500, а логов нет — приходится восстанавливать под с debug-режимом и ждать повторения. С ELK вы видите полный стек ошибок за последние 5 минут. Мы — команда DevOps-инженеров с многолетним опытом в high-load — развернём production-готовую систему сбора логов, которая найдёт проблему за секунды. Закажите аудит текущей системы логирования — мы найдем узкие места и предложим оптимизацию.

Типичные ошибки при самостоятельной настройке ELK

Самый частый сценарий: Elasticsearch поднимают без ограничения heap size и через пару недель получают OOM. По умолчанию ES берёт половину RAM, но если JVM heap превышает 30–32 GB, начинаются длительные GC паузы. Правильная конфигурация: -Xms16g -Xmx16g для dedicated ноды с 32 GB памяти — не больше. Вторая проблема — индексная стратегия. Один индекс на все данные за полгода — катастрофа производительности. Нужен ILM (Index Lifecycle Management) с этапами hot → warm → cold → delete и настройкой rollover и retention. Третья — Logstash как единая точка приёма в high-load средах. Logstash — тяжёлый JVM-процесс. Для агрегации с тысяч хостов ставят Filebeat на каждом узле → Kafka → Logstash → Elasticsearch. Kafka буферизует пики нагрузки и гарантирует доставку.

Как мы настраиваем ELK Stack для Kubernetes?

Настройка проходит в четыре шага:

1. Развёртывание Elasticsearch кластера (3+ ноды) с ILM политикой.
2. Установка Filebeat DaemonSet с autodiscover для сбора логов контейнеров. Настраиваем RBAC для доступа к API Kubernetes и используем sidecar pattern для сбора метрик с приложений.
3. Настройка Logstash pipeline для обогащения и парсинга (если нужна дополнительная трансформация).
4. Создание Kibana дашбордов и алертов через ElastAlert2.

В K8s среде используем стандартную схему: Filebeat DaemonSet читает /var/log/containers/*.log и отправляет данные напрямую в Elasticsearch или через Logstash. Ниже — конфигурация, которую мы применяем в продакшене.

# filebeat-daemonset.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:
  name: filebeat
  namespace: logging
spec:
  selector:
    matchLabels:
      app: filebeat
  template:
    spec:
      serviceAccountName: filebeat
      containers:
      - name: filebeat
        image: docker.elastic.co/beats/filebeat:8.12.0
        args: ["-c", "/etc/filebeat.yml", "-e"]
        env:
        - name: ELASTICSEARCH_HOST
          value: "elasticsearch-master.logging.svc.cluster.local"
        - name: ELASTICSEARCH_PORT
          value: "9200"
        volumeMounts:
        - name: config
          mountPath: /etc/filebeat.yml
          readOnly: true
          subPath: filebeat.yml
        - name: varlog
          mountPath: /var/log
          readOnly: true
        - name: varlibdockercontainers
          mountPath: /var/lib/docker/containers
          readOnly: true
      volumes:
      - name: varlog
        hostPath:
          path: /var/log

filebeat.yml с autodiscover для Kubernetes:

filebeat.autodiscover:
  providers:
    - type: kubernetes
      node: ${NODE_NAME}
      hints.enabled: true
      hints.default_config:
        type: container
        paths:
          - /var/log/containers/*-${data.kubernetes.container.id}.log
      templates:
        - condition:
            equals:
              kubernetes.labels.app: "payments-api"
          config:
            - type: container
              paths:
                - /var/log/containers/*-${data.kubernetes.container.id}.log
              processors:
                - decode_json_fields:
                    fields: ["message"]
                    target: ""
                    overwrite_keys: true
                - add_kubernetes_metadata:
                    host: ${NODE_NAME}
                    matchers:
                      - logs_path:
                          logs_path: "/var/log/containers/"
output.elasticsearch:
  hosts: ["${ELASTICSEARCH_HOST}:${ELASTICSEARCH_PORT}"]
  index: "k8s-logs-%{[kubernetes.namespace]}-%{+yyyy.MM.dd}"
  ssl.enabled: true
  ssl.certificate_authorities: ["/etc/ssl/certs/ca.crt"]

Почему ILM политика критична для стоимости хранения?

ILM управляет жизненным циклом индексов: горячие данные на быстрых NVMe, холодные — на HDD или S3. Пример политики:

PUT _ilm/policy/k8s-logs-policy
{
  "policy": {
    "phases": {
      "hot": {
        "min_age": "0ms",
        "actions": {
          "rollover": {
            "max_age": "1d",
            "max_size": "50gb"
          },
          "set_priority": {
            "priority": 100
          }
        }
      },
      "warm": {
        "min_age": "7d",
        "actions": {
          "forcemerge": {
            "max_num_segments": 1
          },
          "shrink": {
            "number_of_shards": 1
          },
          "set_priority": {
            "priority": 50
          }
        }
      },
      "cold": {
        "min_age": "30d",
        "actions": {
          "set_priority": {
            "priority": 0
          }
        }
      },
      "delete": {
        "min_age": "90d",
        "actions": {
          "delete": {}
        }
      }
    }
  }
}

В горячей фазе храним данные 1–7 дней, в тёплой — до 30, в холодной — до 90. После 90 дней — удаляем. Если нужен более долгий архив, используем Searchable Snapshots в S3. ILM может сократить затраты на хранение до 50%.

Kibana: поиск и алерты

В Kibana Discover ищем логи с помощью KQL. Пример: kubernetes.namespace: "production" AND level: "error" AND NOT kubernetes.pod.name: "batch-*". Для алертов используем ElastAlert2 — он гибче встроенного Kibana Alerting и не требует X-Pack лицензии:

# elastalert2 rule
name: "Payment service errors"
type: frequency
index: k8s-logs-production-*
num_events: 5
timeframe:
  minutes: 5
filter:
  - term:
      kubernetes.labels.app: "payments-api"
  - term:
      level: "error"
alert:
  - "slack"
slack_webhook_url: "https://hooks.slack.com/services/..."
alert_text: "Payment service: {num_matches} errors in last 5 minutes"

Почему стоит рассмотреть OpenSearch вместо Elasticsearch?

OpenSearch — форк ES 7.10, полностью бесплатен и не требует лицензий. Он дешевле Elasticsearch в 2–3 раза при аналогичной функциональности. Если ваш проект не использует X-Pack фичи, миграция на OpenSearch снижает затраты на лицензирование на 30–50%. Мы выполнили более 50 подобных проектов и поможем выбрать оптимальный вариант.

Результаты внедрения

После настройки ELK Stack под ключ вы сможете:

• Находить ошибки за секунды по trace ID.
• Строить дашборды по статусам HTTP, latency, error rate.
• Получать уведомления в Slack/Telegram при превышении порогов.
• Экономить на хранении данных за счёт ILM и cold storage. Экономия может достигать $1.4k–1.9k в месяц для крупных проектов.

Что входит в работу

Сроки

Стоимость рассчитывается индивидуально и зависит от сложности архитектуры. Свяжитесь с нами для оценки вашего проекта. Наши сертифицированные инженеры гарантируют снижение затрат на хранение логов.