Где смотришь логи?

Мониторинг и анализ логов в DevOps-практике

В современной DevOps-среде логи рассматриваются не как разрозненные файлы на отдельных серверах, а как централизованный поток структурированных данных, критически важный для observability (наблюдаемости) системы. Место и способ просмотра логов полностью зависят от этапа их жизненного цикла: сбор, агрегация, хранение, анализ и визуализация.

1. Источники логов (Куда смотрю в первую очередь)

Логи поступают из множества источников, и я всегда определяю контекст проблемы:

• Контейнеры (Docker/Kubernetes): Для быстрой проверки использую kubectl logs или docker logs.

  # Просмотр логов пода в Kubernetes
  kubectl logs -f <pod-name> -n <namespace> --tail=100
  # Просмотр логов предыдущего контейнера (если он упал)
  kubectl logs -p <pod-name>
  

• Виртуальные машины и bare-metal сервера: Традиционные локации (/var/log/), но доступ через централизованную систему.
• Приложения (Application Logs): Файлы логов приложения, стандартные потоки вывода (stdout/stderr), которые теперь чаще всего направляются не в файлы, а в систему сбора логов.
• Системные и аудит-логи (systemd, auditd): Для анализа проблем с ОС, правами доступа.
• Логи сетевого оборудования, балансировщиков (HAProxy, Nginx), баз данных, брокеров сообщений.

2. Централизованные системы агрегации и анализа (Основное "место" для просмотра)

Ключевой принцип — никогда не заходить на продакшен-сервер для tail -f. Все логи стекаются в централизованное хранилище:

• ELK-стек (Elasticsearch, Logstash/Fluentd, Kibana): Де-факто стандарт. Kibana — это основной веб-интерфейс, где я провожу 80% времени при анализе. Позволяет строить сложные запросы (KQL), дашборды, выявлять аномалии.

  // Пример запроса в Kibana для поиска ошибок 5xx в Nginx логах
  {
    "query": {
      "bool": {
        "must": [
          { "match": { "component": "nginx-access" } },
          { "range": { "status_code": { "gte": 500 } } }
        ],
        "filter": { "range": { "@timestamp": { "gte": "now-1h" } } }
      }
    }
  }
  

• Grafana Loki + Promtail + Grafana: Легковесная альтернатива ELK, особенно эффективна для логов в Kubernetes. Просмотр происходит в Grafana через язык запросов LogQL, что унифицирует опыт с метриками (Prometheus).

  -- Пример LogQL запроса в Grafana для подсчета ошибок по приложению
  count_over_time(
    {namespace="production", app="api-service"} |= "ERROR" | logfmt | status_code >= 500 [5m]
  )
  

• Коммерческие и облачные решения: Datadog Logs, Splunk, AWS CloudWatch Logs Insights, GCP Cloud Logging. Они предоставляют мощные UI, интеграцию с алертингом и трейсами.

3. Практический рабочий процесс просмотра и анализа

1. Триггер: Получаю алерт из системы мониторинга (Prometheus, Datadog) или сообщение от пользователя.
2. Контекстуализация: Перехожу в Grafana или Kibana, открываю соответствующий дашборд, который объединяет метрики, логи и трейсы (distributed tracing). Это связывает симптом (высокая задержка) с причиной (ошибки в логе конкретного микросервиса).
3. Поиск и фильтрация:

    *   Использую **структурированное логирование (JSON)**. Это позволяет фильтровать по полям: `level: "ERROR"`, `trace_id: "abc-123"`, `user_id: 4567`.
    *   Применяю временные диапазоны, группировку и агрегацию.

1. Корреляция: Сопоставляю логи с метриками (рост ошибок 500 и падение rate запросов) и трейсами (вижу полный путь запроса с задержками).
2. Отладка и эскалация: Найдя корневую причину в логах (например, OutOfMemoryError или таймаут к БД), я либо исправляю конфигурацию, либо передаю конкретную ссылку на запрос в логах разработчику, приложив trace_id.

4. Ключевые инструменты командной строки (для ад-hoc анализа)

Даже при наличии централизованной системы, для быстрого прототипирования парсинга или работы с raw-файлами незаменимы:

• grep, awk, sed — классика для фильтрации и трансформации.
• jq — must-have для работы с JSON-логами.

  # Извлечение всех ERROR сообщений из JSON-лога и подсчёт уникальных ошибок
  cat app.log | jq 'select(.level == "ERROR") | .error_message' | sort | uniq -c | sort -nr
  

• tail -f, less, multitail — для отслеживания логов в реальном времени на staging или dev-окружении.
• logcli — CLI для Grafana Loki.

Итог: Я "смотрю логи" преимущественно в веб-интерфейсах Kibana или Grafana, которые являются витриной централизованной системы сбора логов. Это позволяет не просто видеть строки, а проводить комплексный анализ, коррелируя события из разных источников, что является основой для эффективного troubleshooting и обеспечения надежности (reliability) системы. Выбор конкретного стека зависит от бюджета, масштаба и облачной платформы, но философия едина: логи — это стратегические данные, а их анализ — инженерный процесс, а не рутинный поиск по файлам.