Где находятся логи etcd?

Расположение логов etcd: от стандартной конфигурации до управления в продакшене

Логи etcd — распределенного хранилища ключ-значение, являющегося «мозгом» Kubernetes и многих других распределенных систем, — не находятся в одном фиксированном месте по умолчанию. Их расположение и формат сильно зависят от способа запуска и используемого процесса-менеджера (init-системы). Я поделюсь системным подходом к их поиску, основанным на многолетнем опыте эксплуатации etcd в различных средах.

1. Основные каналы логирования и стандартные пути

Etcd по умолчанию пишет логи в стандартный поток ошибок (stderr) процесса. Поэтому конечное расположение файлов определяется тем, куда этот поток направлен.

• При запуске из командной строки (например, для тестирования) логи сразу выводятся в терминал.
• При запуске как системного сервиса (через systemd, upstart, sysvinit) stderr процесса перенаправляется в журнал этой init-системы.

Наиболее распространенные пути для etcd, управляемого через systemd (стандарт для современных дистрибутивов Linux):

Используйте команду journalctl, специально созданную для работы с журналами systemd:

# Просмотр всех логов юнита etcd
sudo journalctl -u etcd

# Просмотр логов в реальном времени (follow)
sudo journalctl -u etcd -f

# Просмотр логов за последний час с детальными метаданными
sudo journalctl -u etcd --since "1 hour ago" -o verbose

# Экспорт логов в файл для дальнейшего анализа
sudo journalctl -u etcd --since "today" > /tmp/etcd_today.log

Конкретные файлы на диске, куда systemd может сохранять журналы, зависят от конфигурации (systemd-journald). По умолчанию это /var/log/journal/, но сами файлы бинарные и читаются только через journalctl.

2. Альтернативные сценарии и ручная конфигурация

• Контейнеризированный etcd (например, в kubeadm-кластерах): Логи находятся внутри контейнера. Используйте инструменты оркестрации для доступа:

  # Для Kubernetes, если etcd работает как Pod (часто на control-plane нодах)
  kubectl logs -n kube-system etcd-<node-name>
  # Или, если доступ к ноде, через crictl/docker
  sudo crictl logs <container_id>
  

• Запуск через Docker напрямую: Логи можно найти через docker logs <container_name> или в драйвере логирования Docker (по умолчанию JSON-файлы в /var/lib/docker/containers/).
• Явная настройка файлового логгера: В параметрах запуска etcd можно указать флаг --log-outputs для дублирования логов в файл. Например:

  etcd --log-outputs=stderr,/var/log/etcd.log
  

    В этом случае логи будут **и** в journald (через stderr), **и** в указанном файле `/var/log/etcd.log`.

3. Критически важные аспекты эксплуатации (Production Considerations)

Как опытный инженер, я должен подчеркнуть, что поиск логов — это только первый шаг. Для эффективного управления etcd в продакшене необходимо:

1. Централизованное логирование: Никогда не полагайтесь только на локальные журналы ноды. Настройте сбор логов etcd в такие системы, как ELK Stack (Elasticsearch, Logstash, Kibana), Loki, или Splunk. Это необходимо для:

    *   Агрегации логов со всех узлов кластера.
    *   Сквозного поиска и анализа инцидентов.
    *   Сохранения истории после пересоздания нод.
    *   Пример фильтра для отправки логов etcd из systemd в Loki/Vector.

1. Настройка уровня детализации (Log Level): По умолчанию используется info. Для отладки можно временно повысить до debug (--log-level=debug), но это генерирует огромный объем данных. В продакшене warn или error может быть достаточно для мониторинга.

2. Мониторинг метрик, а не только логов: Логи — это для постфактум анализа. Для предотвращения проблем настройте мониторинг ключевых метрик etcd через его HTTP /metrics endpoint (часто на порту 2379):

    *   `etcd_server_leader_changes_seen_total` — частые смены лидера указывают на проблемы.
    *   `etcd_disk_wal_fsync_duration_seconds` — задержки записи WAL говорят о проблемах с диском.
    *   `etcd_server_has_leader` — наличие лидера в кластере (1/0).

1. Ротация и политики хранения: Если используется файловый логгер, настройте его ротацию (например, через logrotate). Для journalctl сконфигурируйте SystemMaxUse в /etc/systemd/journald.conf.

Практический алгоритм поиска (Troubleshooting Cheat Sheet)

Если вы зашли на ноду и не знаете, как запущен etcd:

# 1. Проверяем, работает ли etcd как systemd-сервис
sudo systemctl status etcd
# Если активен, смотрим логи через journalctl (см. выше)

# 2. Проверяем, работает ли процесс etcd
ps aux | grep etcd
# В выводе ищем ключевые флаги: --data-dir, --log-outputs

# 3. Проверяем, работает ли в контейнере (общие команды)
sudo docker ps | grep etcd
sudo crictl ps | grep etcd

# 4. Проверяем наличие файлов в стандартной директории данных etcd
sudo ls -la /var/lib/etcd/  # Стандартный --data-dir
# Иногда там могут находиться файлы .log, если велась отдельная файловая запись.

Итог: В 95% случаев в production-средах с Linux вы найдете логи etcd через sudo journalctl -u etcd. Однако ключевая задача инженера — не просто найти их, а построить отказоустойчивую pipeline-систему их сбора, анализа и интеграции с метриками для обеспечения надежности всего кластера. Понимание контекста запуска (systemd, контейнер, бинарник) — фундамент для быстрого решения проблем.