Налаштування централізованого логування через ELK Stack — під ключ

Налаштування централізованого логування через 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. Економія може сягати 150 000 гривень на місяць для великих проектів.

Що входить у роботу

Строки

Вартість розраховується індивідуально та залежить від складності архітектури. Зв'яжіться з нами для оцінки вашого проекту. Наші сертифіковані інженери гарантують зниження витрат на зберігання логів.