Был ли доступ к логам у разработчиков на последнем проекте?

«Был ли доступ к логам у разработчиков на последнем проекте?» — вопрос из категории Мониторинг и логирование, который задают на 23% собеседований Devops Инженер. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

Да, доступ к логам для разработчиков был ключевым принципом нашей DevOps-культуры. Мы реализовали централизованное логирование, чтобы дать командам возможность самостоятельно отлаживать свои сервисы.

Архитектура и доступ:

  1. Сбор логов: В Kubernetes-кластере использовался DaemonSet Fluent Bit для сбора логов со всех Pod'ов и их отправки в Grafana Loki.
  2. Визуализация и поиск: Разработчики имели доступ к дашбордам в Grafana, где могли выполнять запросы LogQL для фильтрации логов по неймспейсу, поду, лейблам приложения или конкретным ошибкам.
    {namespace="staging", app="order-service"} |= "panic" | logfmt
  3. Ролевой доступ (RBAC): Доступ был настроен через Grafana Teams. Разработчики видели логи только своих неймспейсов (dev, staging). Доступ к продакшен-логам требовал отдельного запроса и предоставлялся временно для расследования инцидентов.
  4. Экстренный доступ: Для быстрой отладки в нестандартных ситуациях у senior-разработчиков также была возможность использовать kubectl logs:
    kubectl logs -n staging deployment/order-service --tail=200 -f

Политика хранения: Логи staging-окружения хранились 15 дней, продакшена — 30 дней. Критические ошибки (уровень ERROR и выше) также дублировались в Alertmanager и создавали алерты в Slack-канал команды для немедленного реагирования.