@monitorim_it

Создание платформы наблюдаемости с помощью SigNoz, ClickHouse и OpenTelemetry — Часть 1

2026-03-27T08:43:07.537Z

Перевод оригинальной статьи Building a Production-Grade Observability Platform with SigNoz, ClickHouse, and OpenTelemetry — Part 1

Перевод сделан специально для телеграм-канала Мониторим ИТ. Подписывайтесь! Там еще больше полезных постов о мониторинге.

Уроки, полученные в ходе нашей внутренней настройки наблюдения, и то, что мы узнали помимо документации и долгих ночей настройки кластера.

1. Обзор

Мы поставили перед собой задачу создать собственную платформу на базе SigNoz, ClickHouse и OpenTelemetry (OTEL), способную обрабатывать метрики и трассировки в различных средах в производственных масштабах. Мы постоянно запускаем тысячи экземпляров EC2 и хранилищ данных, генерирующих миллионы метрик и событий трассировки. Кроме того, это помогает нам экономить миллионы долларов на счетах других коммерческих решений, которые мы использовали раньше. 💸

О чем этот блог (и серия)

В этой публикации мы рассмотрим архитектуру и ключевые системные выводы, сделанные в ходе масштабного запуска — от проектирования до наблюдения за стеком наблюдения!
Мы выйдем за рамки обучающих материалов и рассмотрим операционные реалии высокопроизводительных систем наблюдения.

В следующих частях мы подробно рассмотрим:

Единый двоичный пользовательский интерфейс SigNoz и схемы *MergeTree

Различные компонент пользовательского интерфейса Signoz и их практические последствия при настройке продакшна.
*Схемы MergeTree для хранения метрик и трассировок в ClickHouse и то, как они используют “fingerprints” для оптимизации хранения.

Внутреннее устройство ClickHouse для телеметрических нагрузок

Как ведут себя репликация, очереди слияний и компрессия в масштабах петабайт.
Почему решения по ключам сортировки могут как ускорить, так и полностью разрушить латентность запросов.
Как несоответствие форм вставки тихо убивает пропускную способность.
Реальное влияние пакетной обработки, ограничений памяти и асинхронных вставок через коллектора.

Давайте же приступим!

Высокоуровневая архитектура

Корпоративный конвейер OTEL для метрик и трассировок Cloudwatch и Host

Проектирование высокого уровня (HLD)

Вот высокоуровневая архитектура конвейера наблюдаемости, который мы настроили с использованием OpenTelemetry (OTEL), Kafka и SigNoz. Цель была проста: создать масштабируемый, независимый от вендора конвейер телеметрии, который мог бы обрабатывать метрики и трассировки десятков сервисов, не ограничиваясь одним проприетарным решением.

Всё начинается с источника — наших приложений и систем данных, таких как PostgreSQL, Spark и различных микросервисов. Они генерируют телеметрию (метрики и трассировки), которые мы собираем с помощью OTEL-коллекторов и SDK. Коллекторы отвечают за пакетирование, сэмплинг и преобразование данных в единый формат OTEL перед их дальнейшей отправкой.

Для мониторинга метрик собственных сервисов AWS мы передаем метрики CloudWatch через Firehose. На пути потока находится лямбда-функция для обогащения тегами, добавляя полезные метаданные, такие как имена сервисов, окружения или кастомные теги, которые значительно упрощают поиск данных в будущем. Далее обогащенные данные резервируются в S3 и направляются на уровень коллектора OTEL через балансировщик нагрузки.

Совет 🚀В Firehose мы использовали размер буфера 0,2 МБ и интервал между буферами 60 секунд. Это даёт нам около 200 одновременных вызовов лямбда. Увеличение размера буфера может уменьшить количество лямбда вызовов. Однако необходимо учитывать размер сообщения после обогащения тега. Чем больше буфер, тем больше пакет после обогащения, и вы можете столкнуться с ошибками «Message size too large» в логах Firehose. Настройте значение для оптимизации затрат.

Лямбда для обогащения метрик тегами: мы использовали модификацию этой лямбды для OTLPv1.0. Она использует ResourceGroupsTaggingAPI для обогащения метрик тегами в потоке.

Используйте sending_queue и retry_on_failure в конфигурации OTEL collector. При экспорте в Kafka, в случае сбоя, коллектор будет хранить сообщения в памяти в зависимости от установленного лимита и пытаться отправить их повторно. Если очередь переполнена, начнется потеря сообщений. Слишком длинная очередь может привести к исчерпанию памяти экземпляра, вплоть до полной потери ответа. Поэтому лимит очереди критически важен.

Все эти телеметрические данные — как метрики, так и трассировки — поступают в Kafka, которая служит основой нашего конвейера наблюдения. У нас есть отдельные топики Kafka для метрик и трассировок, поддерживаемые шестью брокерами, с фактором репликации 3 и сроком хранения 3 дня. Это обеспечивает надёжный, отказоустойчивый буфер, способный справляться с пиковыми нагрузками без потери данных.

Из Kafka данные получают коллекторы SigNoz и записывают их в ClickHouse, нашу основную базу данных временных рядов. Кластер ClickHouse состоит из 3 шардов и 3 реплик, координируемых ZooKeeper для обеспечения согласованности и отказоустойчивости. Для управления расходами старые данные (более 90 дней) автоматически выгружаются в S3, что обеспечивает долгосрочное хранение без избыточных расходов на локальное хранилище.

Совет 🚀

- Убедитесь, что брокеры размещены в разных зонах доступности для высокой отказоустойчивости. У нас есть 6 брокеров с коэффициентом репликации 3 и сроком хранения 3 дня.

– Нам пришлось обновить max_message_bytes, поскольку батчи OTEL-коллектора превышали стандартный размер в 1 МБ. Настройте это значение в соответствии с вашей пропускной способностью.

- Конфигурация memory_limiter на коллекторе Signoz OTEL оказалась настоящим спасением! Она ограничивает потребление памяти заданным порогом и оказывает обратное давление на приемник Kafka при превышении лимитов памяти экземпляра, защищая экземпляр от выполнения OOM.

- Мы используем 8xlarge-инстанс для каждого узла ClickHouse с SSD-накопителем на 250 ГБ. Мы будем экспериментировать с уменьшением размера экземпляра после бенчмаркинга с использованием трёхмесячных метрик. В настоящее время загрузка ЦП составляет около 8%.

Наконец, все данные выводятся на сервер SigNoz, предоставляющий единую интерфейс-панель для запросов и визуализации как метрик, так и трассировок. Именно здесь команды непосредственно взаимодействуют с данными — устраняют скачки задержек, анализируют тенденции и находят узкие места в производительности.

Короче говоря, эта архитектура обеспечивает чёткое разделение приёма, обработки и хранения данных. Она устойчива к пиковым нагрузкам, достаточно модульна для развития со временем и даёт нам полный контроль над тем, как данные наблюдения проходят через наш стек, — без зависимости от непрозрачного ("чёрного ящика") SaaS-решения.

Масштаб и производительность

Производственная инфраструктура, находящаяся под наблюдением, включает в себя более 10 тыс. экземпляров EC2 и хранилищ данных, работающих на пике производительности, генерирующих метрики и трассировки.
Скорость приема данных: ~200 Мбит/с (Cloudwatch + метрики хоста + трассировки)
~100 млн уникальных метрик на пике
~1 млн строк/сек реплицируется на все 9 узлов ClickHouse
Время вставки запросов в ClickHouse: 25 мкс.
357 ТБ загруженных спанов в месяц.

2. Почему OpenTelemetry (OTEL), а не Prometheus

Prometheus многие годы был стандартным выбором для наблюдаемости, но когда нам понадобилась телеметрия «сквозных сигналов» (метрики + трассировки + логи), его ограничения стали очевидными. Подробнее об этих различиях читайте в этой статье.

Prometheus против OpenTelemetry

Точки принятия решений:

Модель pull в Prometheus отлично подходит для простых кластеров, но плохо масштабируется для распределенных рабочих нагрузок с высокой мощностью.
Конструкция OTEL на основе push-уведомлений и настраиваемые процессоры обеспечили нам более точный контроль и отказоустойчивость.
Использование OTEL означало, что при необходимости мы могли экспортировать данные в несколько бэкэндов (например, ClickHouse + S3 + kafka).

Почему SigNoz

Тесно интегрируется с OTEL и ClickHouse.
По умолчанию он предоставляет UI для трассировки, дашборды для метрик и систему алёртинга.
В отличие от SaaS-инструментов, он имеет открытый исходный код и является расширяемым — вы можете модифицировать экспортёр, менять схему ClickHouse и напрямую анализировать работу запросов.
У него очень активная поддержка сообщества.

В последующих публикациях этой серии я поделюсь более подробной информацией о сервере SigNoz и архитектуре схемы, а также о том, как они себя покажут на платформе промышленного масштаба.

Signoz поддерживает PromQL для создания панелей мониторинга и мониторов

3. Наблюдение за стеком наблюдаемости

Наблюдаемость не будет полной, если вы не можете наблюдать за самим стеком наблюдаемости.
Наш конвейер телеметрии оснащен Prometheus и коллекторами OTEL, но с одной особенностью: мы создали устойчивый уровень сбора метрик с буферизацией через Kafka, который устраняет необходимость в статических scrape-таргетов Prometheus и допускает простои сервера Prometheus.

PS: Мы решили не настраивать отдельный конвейер Signoz + CH для этого, поскольку настройка еще одного кластера CH + ансамбля Zookeeper потребовала бы слишком больших затрат на обслуживание ради наблюдаемости самого конвейера наблюдаемости, который работает на фиксированных инстансах.

3.1 Мотивация дизайна

По мере масштабирования наших кластеров OTEL и ClickHouse поддержка статических конфигураций сбора данных Prometheus для каждого коллектора, брокера или узла ClickHouse становилась неуправляемой.

Мы хотели:

Динамическое автообнаружение — не требуется ручное изменение конфигурации при масштабировании экземпляров.
Отказоустойчивость — метрические данные должны выдерживать кратковременные сбои Prometheus.
Единый путь приема данных — объединение телеметрии на уровне инфраструктуры и приложения в один поток.

Поэтому вместо того, чтобы позволить Prometheus напрямую опрашивать каждый endpoint, мы перевернули архитектуру: Prometheus получает метрики всего из одного OTEL-коллектора, который читает метрики из Kafka, куда отправляют их все компоненты конвейера.

3.2 Примеры конфигураций коллектора

На каждом хосте (узлы Kafka, ClickHouse, OTEL Collector):

Экспортирует метрики Prometheus в Kafka.

receivers:
  prometheus:
      config:
        global:
          scrape_interval: 30s
        scrape_configs:
          - job_name: otel-collector-binary
            static_configs:
              - targets: ['localhost:8888'] # OTEL internal metrics
  hostmetrics:
      collection_interval: 30s
      scrapers:
        cpu: {}
        load: {}
        memory: {}
        disk: {}
        filesystem: {}
        network: {}
processors:
  resourcedetection/aws:
      detectors: [ec2]
      timeout: 2s
      override: true
      ec2:
        tags:
          - aws:autoscaling:groupName
          - service_name
          - environment_name
          - cluster
          - provisioned-by-user
          - resource_type
exporters:
  kafka:
    brokers: ["observibility-kafka.prod.local:<port>"]
    topic: "pipeline-metrics"

Центральный коллектор (обращённый к Prometheus):

Использует данные из Kafka, повторно выставляет метрики для Prometheus.

receivers:
  kafka:
    brokers: ["kafka-1:9092", "kafka-2:9092"]
    topic: "pipeline-metrics"

exporters:
  prometheus:
    endpoint: "0.0.0.0:9464"

service:
  pipelines:
    metrics:
      receivers: [kafka]
      exporters: [prometheus]

Конфигурация Прометея

Prometheus требуется только один таргет:

scrape_configs:
  - job_name: 'otel-metrics-aggregator'
    static_configs:
      - targets: ['otel-central-collector:9464']

Это делает настройку полностью независимой от топологии — можно масштабировать Kafka, ClickHouse или OTEL-коллекторы вверх/вниз, не меняя YAML-конфигурацию Prometheus.

3.3 Что мы отслеживаем

Из множества показателей у нас есть лишь немногие оповещения и панели мониторинга для мониторинга конвейера.

Просмотр показателей приемника OTEL в Grafana.

4. Инструменты для отслеживания

Масштабное отслеживание требует тщательной координации между агентом OTEL и коллекторами, а также использования специальных инструментов для работы с устаревшим кодом. Вот обзор того, как мы справляемся с этим на нашей платформе.

Обзор агента + коллектора

Агент OTEL: запускается вместе с приложениями (sidecar или in-process), перехватывая входящие и исходящие запросы для создания интервалов. Для HTTP, gRPC и поддерживаемых фреймворков агент автоматически инструментирует запросы.
Сборщик OTEL: получает данные от агентов, выполняет батчинг, семплинг и обогащение, а также экспортирует их в Kafka для обеспечения устойчивости. Коллектор SigNoz из Kafka записывает данные в ClickHouse для хранения и визуализации.

Такое разделение гарантирует, что агенты остаются легкими, в то время как коллекторы выполняют тяжелую работу, такую как батчинг, backpressure и экспорт в больших масштабах.

Кастомное инструментирование для устаревших систем

Некоторые из наших сервисов используют старые версии фреймворков и библиотек, которые не инструментируются автоматически OTEL:

Vert.x 3.9: Требуется специальный инструментарий для корректного захвата асинхронных циклов событий.
Клиенты SQL (старые версии JDBC) и клиенты Redis: мы написали небольшие оболочки OTEL для захвата областей запросов/команд без изменения существующей бизнес-логики.

Эти специальные инструменты имели решающее значение для поддержания сквозной видимости трассировки для критически важных устаревших потоков.

Семплинг

Мы применяем вероятностный семплинг 1% для трейсов:

Это означает, что только 1% всех запросов фиксируется как трейсы.
Это снижает нагрузку на систему, при этом позволяя проводить статистически значимый анализ ошибок и скачков задержки.
Даже при таком семплинге большинство ошибок фиксируются, так как спаны с ошибками чаще встречаются в запросах с высокой задержкой или сбоев.

Полезный совет:
если уровень ошибок у вас крайне низок, рассмотрите tail-based sampling (сбор всех трейсов с ошибками) в сочетании с вероятностной выборкой, чтобы не пропустить критические события сбоя.

Метрики охвата

Все метрики интервала (задержка, количество ошибок, длительность) хранятся в ClickHouse.
Это позволяет строить дашборды без необходимости повторной обработки необработанных трассировок.

# Sample signoz config for span metrics
signozspanmetrics/delta:
    aggregation_temporality: AGGREGATION_TEMPORALITY_DELTA
    dimensions:
    - default: default
      name: service.namespace
    - default: default
      name: deployment.environment
    - name: signoz.collector.id
    dimensions_cache_size: 100000
    latency_histogram_buckets:
    - 100us
    - 1ms
    - 2ms
    - 6ms
    - 10ms
    - 50ms
    - 100ms
    - 250ms
    - 500ms
    - 1000ms
    - 1400ms
    - 2000ms
    - 5s
    - 10s
    - 20s
    - 40s
    - 60s
    metrics_exporter: signozclickhousemetrics

Вспомогательные библиотеки OTEL

Для поддерживаемых библиотек OTEL предлагает богатый набор инструментов в opentelemetry-contrib. Он включает в себя автоматический инструментарий для баз данных, систем обмена сообщениями, веб-фреймворков и многого другого. Использование этих инструментов снижает потребность в специальных оболочках и обеспечивает совместимость с будущими версиями.

5. Итоги и что дальше

В этой части мы рассмотрели общие принципы проектирования и эксплуатации платформы наблюдения промышленного уровня с использованием SigNoz, ClickHouse и OpenTelemetry. Ключевые выводы:

Масштабируемая архитектура: разделение приема, обработки и хранения позволяет системе обрабатывать миллионы показателей и трассировок в секунду, оставаясь при этом устойчивой к скачкам нагрузки.
Практические уроки настройки: такие конфигурации, как ограничения памяти коллектора OTEL, пакетирование Kafka и размеры буфера Lambda, имеют решающее значение для надежности и оптимизации затрат.
Самонаблюдаемость: Инструментирование самого конвейера наблюдаемости обеспечивает динамический мониторинг метрик Prometheus и обратного давления, без необходимости управлять сотнями статических конфигураций сбора данных.
Трейс-инструментирование: правильная настройка агента и коллектора, а также специализированный инструментарий для устаревших библиотек обеспечивают полноту распределённых трейсов, в то время как вероятностная выборка позволяет контролировать затраты на хранение и прием данных.

Эта статья посвящена вопросам «почему» и «как» на архитектурном уровне. Мы надеемся, что она даст вам конкретные идеи и практические рекомендации по созданию и настройке собственного телеметрического стека.

Что дальше (часть 2):
В следующей публикации мы подробно рассмотрим сервер SigNoz, настройки коллектора и схемы ClickHouse. Вы получите подробную информацию о:

Как коллекторы обрабатывают пакетирование, повторные попытки и обратное давление.
Шаблоны проектирования схемы Signoz *MergeTree для метрик и диапазонов с высокой кардинальностью, а также то, как она использует отпечатки для оптимизации хранения.
Однобинарный UI-сервер SigNoz с компонентами alert-manager и query-builder.

Оставайтесь с нами, если хотите узнать подробности, выходящие за рамки документации, — то, что делает платформу наблюдения за производством по-настоящему надежной и производительной. 👋

2 часть статьи на момент публикации перевода так и не вышлаю (примечание переводчика).

Подписывайтесь на телеграм-канал Мониторим ИТ, там еще больше полезной информации о мониторинге!

Масштабирование метрик Prometheus с помощью Grafana Mimir: пошаговая настройка

2026-03-22T13:51:54.029Z

Это перевод оригинальной статьи Scaling Prometheus Metrics with Grafana Mimir: Step-by-Step Setup and Demo.

Prometheus отлично подходит для мониторинга, но при масштабировании возникают реальные проблемы, такие как высокая кардинальность, долговременное хранение и высокая доступность. Вот тут-то и приходит на помощь Grafana Mimir.

На недавнем митапе Grafana & Friends x Kubernetes я выступил с докладом и живой демонстрацией того, как Grafana Mimir может масштабировать метрики Prometheus.

В этой статье вы шаг за шагом узнаете обо всем, что я показал в демонстрации.

Настройка панели мониторинга Grafana Mimir в качестве источника данных TSDB.

Что мы рассмотрим

Ограничения Prometheus
Введение в Grafana Mimir
Архитектура и компоненты Mimir
Конфигурация remote write из Prometheus → Mimir
Настройка Grafana → Mimir в качестве источника данных
Визуализация метрик + изучение административного интерфейса

Почему именно Grafana Mimir?

Prometheus — мощная система сбора метрик, но у неё есть следующие проблемы:

Отсутствует встроенная кластеризация или высокая доступность.
Только локальное хранилище
Интенсивное использование памяти при работе с данными высокой кардинальности.

Grafana Mimir — это высокомасштабируемый backend для долгосрочного хранения метрик Prometheus, который решает все эти проблемы.

Архитектура Mimir Architecture (краткий обзор)

Mimir подразделяется компоненты:

Distributor — принимает remote write от Prometheus
Ingester — временно хранит данные
Compactor — компактизирует блоки
Querier — обрабатывает запросы
Store-gateway — извлекает блоки из объектного хранилища.

Это делает Mimir горизонтально масштабируемым и совместимым с HA.

Пошаговая настройка

Запуск экземпляра EC2 (виртуальной машины)

Перед установкой чего-либо я запустил экземпляр Amazon EC2, который использовал в качестве демонстрационной среды.

Настройка Prometheus

Статус Mimir TSDB

Prometheus Targets

Собранные метрики через Grafana Mimir

Скачайте и распакуйте Prometheus:

wget https://github.com/prometheus/prometheus/releases/download/v2.52.0/prometheus-2.52.0.linux-amd64.tar.gz
tar -xvzf prometheus-2.52.0.linux-amd64.tar.gz
cd prometheus-2.52.0.linux-amd64

Отредактируйте файл prometheus.yml, чтобы включить удаленную запись в Grafana Mimir:

Добавьте удаленную запись

remote_write:
- url: http://localhost:9009/api/v1/push

Файл конфигурации Prometheus

Настройка Grafana Mimir

Скачайте Mimir:

wget https://github.com/grafana/mimir/releases/download/v2.12.0/mimir-linux-amd64.zip
unzip mimir-linux-amd64.zip
chmod +x mimir

Создайте конфигурационный файл demo.yaml (базовая настройка для одного процесса):

# Do not use this configuration in production.
# It is for demonstration purposes only.
multitenancy_enabled: false

blocks_storage:
  backend: filesystem
  bucket_store:
    sync_dir: /tmp/mimir/tsdb-sync
  filesystem:
    dir: /tmp/mimir/data/tsdb
  tsdb:
    dir: /tmp/mimir/tsdb

compactor:
  data_dir: /tmp/mimir/compactor
  sharding_ring:
    kvstore:
      store: memberlist

distributor:
  ring:
    instance_addr: 127.0.0.1
    kvstore:
      store: memberlist

ingester:
  ring:
    instance_addr: 127.0.0.1
    kvstore:
      store: memberlist
    replication_factor: 1

ruler_storage:
  backend: filesystem
  filesystem:
    dir: /tmp/mimir/rules

server:
  http_listen_port: 9009
  log_level: error

store_gateway:
  sharding_ring:
    replication_factor: 1

Конфигурация Mimir

Настройка Grafana

Запуск Grafana:

sudo systemctl start grafana-server

Подключите Mimir к Grafana

Настройка Mimir в качестве источника данных

Войдите в Grafana по адресу http://<ip>:3000(по умолчанию: admin/admin)
Перейдите в Settings → Data Sources → Add Data Source
Выберите Prometheus

Теперь Grafana подключена к Mimir!

Обзор административного интерфейса Mimir

Административный интерфейс Grafana Mimir

Статус сервисов

Статус Hash Ring

Статус Ingester

Grafana Mimir Memberlist — пары ключ-значение

Эта конфигурация демонстрирует, насколько легко масштабировать Prometheus с помощью Grafana Mimir — без изменения способа сбора метрик.

Подписывайтесь на телеграм-канал Мониторим ИТ, там еще больше полезной информации о мониторинге!

О чём логи Kubernetes не расскажут вам во время инцидента

2026-03-21T07:31:48.335Z

Это перевод оригинальной статьи What Kubernetes Logs Won’t Tell You During an Incident.

Если вы достаточно долго используете Kubernetes в продакшене, то уже знаете этот ритуал:

Срабатывает алерт.
Вы открываете логи.
Они выглядят нормально.
А продакшен всё ещё «горит».

Это не плохая наблюдаемость. Это неоправданное доверие.

Логи Kubernetes отлично показывают, что, по мнению вашего приложения, произошло. Но они совершенно не помогают понять, почему система ведет себя именно так. Именно в этот промежуток времени тратится большая часть времени впустую во время инцидентов.

Вот что обычно не показывают логи — и на что следует обратить внимание вместо них.

1. В логах не отображается информация о нехватке ресурсов (пока не станет слишком поздно).

В ваших логах указано:

«Request processed successfully»

Ваши пользователи говорят:

«Приложение работает ужасно медленно».

Чего вам не расскажут логи:

Ваши поды ограничены по CPU
Ваши контейнеры технически "работают".
Ваши запросы находятся в очереди, а не завершаются с ошибкой.

Ограничение использования CPU не приводит к сбоям в работе подов. Оно незаметно увеличивает задержку. Kubernetes будет спокойно поддерживать работоспособность вашего контейнера, получая при этом 20 мс ресурсов CPU каждые 100 мс.

К тому моменту, когда в логах появляются сообщения о таймаутах, ущерб уже нанесен.

Что действительно помогает

Метрики CPU контейнера и его ограничение
Нагрузка CPU на узле
Процентили задержки запроса (не средние значения)

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

2. Логи не объясняют, почему поды перезапускаются

Вы видите:

«Container terminated with exit code 137»

Отлично. Это ничего полезного вам не скажет.

Логи не скажут:

Был ли pod убит (OOM-killed) из-за нехватки ресурсов на узле
Выселил ли его kubelet по собственной инициативе
Был ли ограничен другим нагрузкой другого процесса

Логи контейнера обрываются внезапно — потому что контейнер так и не успел зафиксировать собственную гибель.

Что действительно помогает

Последнее состояние pod (OOMKilled или Evicted)
События, связанные с нехваткой памяти узла
Какие ещё pod одновременно вызвали всплеск потребления памяти?

Моя давняя ошибка, допущенная на позднем этапе разработки: я
пытался исправить ошибки в приложении, когда реальная проблема заключалась в конфликтах за память на уровне узлов.

3. Логи не показывают решения планировщика (scheduler)

Деплой «застрял».

В логах отображается следующее:

«Scaled to 10 replicas»

Но реально работает только 6 подов.

В логах вы не узнаете:

Почему планировщик не может разместить оставшиеся pod
Какие ограничения препятствуют планированию?
Провал упаковки в контейнеры произошел незаметно.

Планировщик не записывает в логи причины, по которым он отклонил узлы, так чтобы это было видно в логах приложения.

Что действительно помогает

События планирования подов
Доступные vs запрошенные ресурсы узла
Конфликты affinity и taint

Суровая правда: большинство «ошибок Kubernetes» во время инцидентов связаны с математическими ошибками планировщика.

4. Логи не фиксируют ухудшение качества сети.

Логи говорят:

«Request sent»

Они не говорят:

Разрешение DNS-запроса заняло 800 мс.
Между узлами резко возросла потеря пакетов.
Правила kube-proxy вышли из строя

С точки зрения приложения, всё работает нормально. С точки зрения пользователя, всё тормозит.

Проблемы в сети сначала приводят к ухудшению качества, а затем к поломке.

Что действительно помогает

метрики задержки DNS
Потеря пакетов между узлами
Частота повторных попыток подключения

Совет от опытного пользователя: если работа нескольких сервисов
тормозит, перестаньте читать логи и начните проверять DNS и сеть.

5. Логи обманывают во время Rolling Updates

Во время rollout’ов логи могут вводить в заблуждение.

Вы увидите:

«Pod started successfully»

Чего вам не расскажут логи:

Проверки на готовность были пройдены слишком рано.
Трафик попал в pod до того, как кеши прогрелись.
Старые pod освобождались слишком медленно (или вообще не освобождались)

Приложение считает, что готово. Система — нет.

Что действительно помогает

Реальные показатели успешности трафика во время rollout
Задержка готовности против фактической готовности
Поведение балансировщика нагрузки при исчерпании ресурсов соединения

Урок усвоен на горьком опыте: зелёное развертывание — это не то же самое, что безопасное внедрение.

6. Логи не показывают проблемы control plane

В логах вашего приложения мало информации.
Ваш кластер работает медленно.

В логах вы не узнаете что:

API-сервер ограничивает количество запросов.
Контроллеры отстают
Watch-события задерживаются

С точки зрения рабочей нагрузки, проблема заключается в Kubernetes — но Kubernetes не сообщает об этом вашему приложению.

Что действительно помогает

Задержка API-сервера
Метрики ограничения запросов
Задержка reconcile контроллеров

Если kubectl работает медленно во время инцидента — это сигнал, а не просто неудобство.

7. Логи не показывают того, чего не произошло

Это самая опасная вещь.

В логах показано, что произошло.
В них не показано:

Запросы, которые так и не дошли до pod
Pod, которые так и не получили трафика
Джобы, которые не запустились

Отсутствие логов редко рассматривают как данные — но во время инцидентов это часто главный сигнал.

Что действительно помогает

Метрики трафика vs ожидаемый объём
Коэффициенты отброса запросов upstream
Пропуски событий control plane

Апгрейд инстинкта старшего инженера: когда логи пусты, спрашивай: что должно было залогироваться, но не залогировалось?

Главный вывод: логи — это запаздывающий сигнал

Логи показывают симптомы, а не причины.

К тому моменту, когда логи «кричат»:

Задержка уже плохая.
Пользователи уже это заметили
Инцидент уже идёт

Опытные инженеры не перестают использовать логи — они перестают полагаться только лишь на них.

Что я теперь проверяю до логов?

В каждом инциденте я неукоснительно следую одному и тому же списку правил:

CPU и память на узлах
События планирования подов
Сигналы троттлинга и eviction-сигналы
DNS и задержка сети
Состояние API-сервера
Несоответствие между трафиком и пропускной способностью

Только после этого я читаю логи — чтобы подтвердить, а не чтобы обнаружить.

Финал

Если ваше реагирование на инцидент начинается и заканчивается логами, значит, отладка выполняется слишком поздно.

Инциденты в Kubernetes происходят в пространстве между компонентами — scheduler, узлы, сеть, control plane — и логи никогда не предназначались для того, чтобы рассказывать эту историю.

Логи не лгут. Они просто не рассказывают всей правды.

А в продакшене половина правды — это причина, почему простои длятся дольше, чем должны.

Подписывайтесь на телеграм-канал Мониторим ИТ, там еще больше полезной информации о мониторинге!

Опыт прохождения собеседования на должность SRE в компании Cisco

2026-03-01T21:32:35.252Z

Это перевод оригинальной статьи Cisco SRE (Site Reliability Engineer) Interview Experience.

Получение приглашения на собеседование в Cisco стало захватывающей возможностью, а сам процесс оказался одновременно сложным и поучительным. Вот подробный рассказ о моем опыте собеседования и заданных вопросах.

Заявки и рекомендации

Я подал заявки на несколько вакансий через LinkedIn и обратился за рекомендациями к 4-5 друзьям. Все, кого я нашел в LinkedIn, кто работал в Cisco, получили мое резюме и краткое представление о себе.

К счастью, мне позвонили по поводу одной из вакансий, и с этого начался процесс собеседований.

HR-проверка 💻

Первый этап представлял собой официальную беседу с представителем отдела кадров. Специалист по кадрам расспросил меня о моих сильных сторонах в работе с различными инструментами и предложил выбрать место работы — Бангалор или Хайдарабад.

Она также упомянула, что в Cisco действует политика полной удаленной работы, что стало большим плюсом.

Первый раунд — Раунд программирования

Этот этап проверял практические технические навыки. Задания включали:

Загрузка файла из хранилища S3 в контейнере.
Написание Terraform-кода для создания EC2-инстанса с настройкой EMR.
Создание Dockerfile для контейнера httpd, который копирует файлы из локальной среды в контейнер и обновляет страницу при изменении URL.
Написание Python-скрипта с использованием boto3 для получения списка всех S3-бакетов в AWS-аккаунте с указанием их размеров.

После осле выполнения около 70% кода интервьюер попросил объяснить мой подход и задал несколько дополнительных вопросов, чтобы проверить понимание.

Второй раунд — собеседование на должность SRE-специалиста.

В этом раунде основной упор делался на практики SRE и наблюдаемость (observability).

Мне предоставили архитектуру следующего вида:
Client -> Load Balancer -> Web Tier -> DB Tier -> Messaging Queue -> SMTP -> Process

Интервьюер попросил реализовать лучшие практики SRE в этой системе. Обсуждение длилось 1 час и касалось мониторинга, надежности и методов построения отказоустойчивой архитектуры.

Третий этап — Техническое собеседование

В третьем раунде проверялись более глубокие технические знания:

Настройка Istio для кластера Kubernetes.
Создание AWS EventBridge с помощью Terraform.
Добавление аннотаций и меток к существующему Pod.
Проектирование кластера Kubernetes с использованием Ingress.
Обработка внезапного всплеска трафика, приводящего к зависанию веб-приложения.
Развертывание Pod с replica set = 3, работающим на контейнере apache httpd.
Уменьшение размера Dockerfile.

В этом раунде оценивались как архитектурные навыки, так и практическое решение задач в облачной и контейнеризированной среде.

4-й раунд — Менеджерский/технический раунд

Я ожидал вопросов исключительно управленческого характера, но этот раунд оказался на 60% техническим. Темы включали Docker, Java, инфраструктуру, Terraform и другие основные инструменты DevOps, проверяя глубину технических знаний, так и управленческое понимание.

Основные выводы из моего собеседования в Cisco:

Подготовьтесь к изучению концепций программирования, облачных технологий и SRE одновременно.
Будьте готовы к практическим техническим обсуждениям, даже на встречах с руководством.
Для руководящих должностей в сфере DevOps/SRE необходимы практические знания Docker, Kubernetes, Terraform и AWS.

Собеседование в Cisco было строгим, но справедливым, с акцентом как на технические знания, так и на навыки решения проблем.

Это был отличный опыт, который подчеркнул важность подготовки, уверенности и ясности в коммуникации.

Подписывайтесь на телеграм-канал Мониторим ИТ, там еще больше полезной информации о мониторинге!

Разбираем конвейеры OpenTelemetry Collector: стандартный OTel vs. Grafana Alloy — Часть 1

2026-03-01T21:27:05.587Z

Это перевод оригинальной статьи Demystifying OpenTelemetry Collector Pipelines: Standard OTel vs. Grafana Alloy — Part 1.

Введение

В современных системах наблюдаемости данные телеметрии (трейсы, метрики и логи) должны надежно передаваться из приложений в бэкэнды, такие как Tempo, Mimir или Loki. OpenTelemetry Collector эффективно справляется с этой задачей, а Grafana Alloy (мощный дистрибутив от Grafana) добавляет расширенную гибкость и дополнительные возможности управления.

В этой статье подробно разбираются основные концепции, конфигурации и различия между этими решениями — с примерами кода, официальными диаграммами и подробными пояснениями.

Понятная аналогия: система обработки багажа в аэропорту

Телеметрические данные подобны багажу пассажира — они должны добраться от стойки регистрации (приложения) до нужного рейса (системы наблюдаемости) без риска потери.

Grafana Alloy — это современная интеллектуальная система обработки багажа с программируемыми развилками и маршрутизацией в реальном времени: высокоскоростные автоматизированные сортировщики, RFID-отслеживание и программно-управляемые шлюзы позволяют динамически изменять маршрут, распределяя багаж по нескольким рейсам (fan-out), объединяя багаж с разных мест регистрации или мгновенно перенаправляя его в случае задержек. Идеально подходит для загруженных, постоянно развивающихся аэропортов.

Стандартный OpenTelemetry Collector представляет собой традиционную систему с фиксированной конвейерной лентой: заранее определенные ленты, разделенные по терминалам (signal type), механические сортировщики и линейные пути от стоек регистрации (receivers) через сканеры (processors) к фиксированным каруселям (exporters). Надежен для стандартных операций, но изменения потребуют серьезной переработки конструкции.

Коннекторы? Например, специальные соединительные ленты, соединяющие клеммы.

Основные компоненты

Обе программы используют общие компоненты OpenTelemetry:

Receivers — стойки регистрации (приём данных: otlp, prometheus, jaeger).
Processors — сканеры/фильтры безопасности (обработка и трансформация: batch, memory_limiter, attributes).
Exporters — погрузочные ленты/карусели (отправка данных: otlp, prometheus, loki).
Connectors — мосты передачи (маршрут между сигналами, например, трейсы → метрики).
Extensions — утилиты для аэропорта (health_check, pprof).

Стандартный OpenTelemetry Collector: линейные YAML-пайплайны

Как фиксированные конвейерные ленты — пайплайны определяются по типу сигнала в service.pipelines.

Простой пример

receivers:
  otlp:
    protocols:
      grpc: {}
      http: {}

processors:
  batch: {}
  memory_limiter:
    check_interval: 1s
    limit_percentage: 75

exporters:
  otlp:
    endpoint: "tempo:4317"

service:
  pipelines:
    traces:
      receivers: [otlp]
      processors: [memory_limiter, batch]
      exporters: [otlp]

Grafana Alloy: Программируемая River Wiring

Как интеллектуальные программируемые сортировщики — явные соединения компонентов через блоки output.

Grafana Alloy — это дистрибутив Grafana на основе OpenTelemetry Collector, полностью совместимая с OTLP, с добавленными Prometheus-нативными пайплайнами, кластеризацией и программируемым синтаксисом. Вместо YAML используется язык конфигурации River (похожий на Terraform / HCL).

Grafana Alloy построена на основе OpenTelemetry Collector и использует обертки otelcol.* для стандартных компонентов (otelcol.receiver.otlp, otelcol.processor.batch и т. д.). Это означает, что ваши существующие знания OpenTelemetry переносятся без проблем — вы просто получаете более выразительный язык конфигурации.

Компоненты OTel имеют префикс otelcol.

Приёмники: otelcol.receiver.* (например, otelcol.receiver.otlp)
Обработчики: otelcol.processor.* (например, otelcol.processor.batch)
Экспортеры: otelcol.exporter.* (например, otelcol.exporter.otlp)
Коннекторы: otelcol.connector.*
Расширения: otelcol.extension.*

Как соединяются компоненты в Alloy

Нет глобального раздела service или pipelines, как в стандартном OTel
Компоненты объявляются по отдельности (с метками, например, «default»).
Соединения задаются явно через блоки output и ссылки на .input следующего компонента
Передача данных осуществляется путем соединения выходов с входами, часто для каждого сигнала отдельно (метрики, логи, трейсы).
Это позволяет создавать гибкие, программируемые пайплайны: (fan-out, условная маршрутизация, смешивание с компонентами Prometheus).

Базовый эквивалент

otelcol.receiver.otlp "default" {
  grpc { endpoint = "0.0.0.0:4317" }
  http { endpoint = "0.0.0.0:4318" }

  output {
    traces = [otelcol.processor.memory_limiter.default.input]
  }
}

otelcol.processor.memory_limiter "default" {
  output { traces = [otelcol.processor.batch.default.input] }
}

otelcol.processor.batch "default" {
  output { traces = [otelcol.exporter.otlp.tempo.input] }
}

otelcol.exporter.otlp "tempo" {
  client { endpoint = "tempo:4317" }
}

Пример fan-out (отправка в несколько бэкендов)

otelcol.processor.batch "default" {
  output {
    traces = [otelcol.exporter.otlp.tempo.input, otelcol.exporter.otlp.backup.input]
  }
}

Сравнительный анализ:

Стандартный OpenTelemetry Collector (Линейные пайплайны, разделенные по типам сигналов) против Grafana Alloy (Явная программируемая разводка с поддержкой fan-out).

Когда что выбрать?

Стандартный OTel → Простые, независимые от поставщика настройки.
Grafana Alloy → стек Grafana, сложная маршрутизация, кластеризация.

Общие советы

Всегда размещайте memory_limiter первым в пайплайне
Используйте пользовательский интерфейс Alloy для отладки пайплайнов.

В заключение следует отметить, что, подобно тому как хорошо организованный аэропорт гарантирует, что каждый чемодан доберется до нужного пункта назначения — эффективно, надежно и вовремя, несмотря на задержки, высокий трафик или неожиданные перенаправления, — так и грамотно настроенный пайплайн OpenTelemetry Collector обеспечивает доставку трейсов, метрик и логов, которые поступят в ваши бэкэнды мониторинга в целостном, обогащенном виде и готовыми к анализу.
Стандартный OpenTelemetry Collector предлагает надежность классических стационарных конвейерных систем: он прост в использовании, не зависит от поставщика и проверен в реальных условиях, где минимализм и чистота архитектуры имеют первостепенное значение.

Однако Grafana Alloy поднимает все это на уровень современной интеллектуальной инфраструктуры — программируемые маршрутизаторы, визуализация пайплайнов через встроенный пользовательский интерфейс (:12345/graph), возможности разветвления, встроенная интеграция с Prometheus и кластеризация для масштабирования. Это очевидный выбор, если вы глубоко используете стек Grafana (Mimir, Loki, Tempo) или вам нужна максимальная гибкость без управления множеством агентов.

Независимо от выбора — классической надежности OTel или интеллектуальной адаптивности Alloy — владение этими пайплайнами позволяет строить устойчивые, перспективные системы мониторинга.

Начните с малого, экспериментируйте локально и обязательно используйте интерактивный граф Alloy — он действительно открывает глаза.

Подписывайтесь на телеграм-канал Мониторим ИТ, там еще больше полезной информации о мониторинге!

Создание системы мониторинга Logstash с использованием Prometheus и Grafana (пошаговое руководство)

2025-12-26T10:26:17.358Z

Это перевод оригинальной статьи Building a Logstash Monitoring Stack with Prometheus and Grafana (Step-by-Step Guide).

Когда вы работаете со сложными пайплайнами, управляемыми Logstash, наблюдаемость — это не опция, а необходимость. Без мониторинга небольшое изменение конфигурации или перегруженный input могут привести к тому, что ваши логи и метрики начнут тихо накапливаться, что нанесёт ущерб нижестоящим системам. Эта статья поможет создать стек мониторинга Logstash с использованием Prometheus, Grafana и prometheus-logstash-exporter, чтобы вы всегда знали, как работают ваши конвейеры Logstash.

Постановка проблемы

Logstash — мощный инструмент для сбора, преобразования и передачи данных. Однако по мере роста объемов данных могут возникать такие проблемы, как:

Внезапные падения пропускной способности
Увеличение задержки пайплайна
Утечки памяти в JVM или чрезмерное накопление мусора (GC)
Высокая загрузка CPU приводит к потере сообщений.

Эти проблемы часто остаются незамеченными до тех пор, пока ваш пайплайн данных не перестанет работать должным образом. Цель этого стека мониторинга — обеспечить видимость показателей производительности Logstash в режиме реального времени, чтобы вы могли быстро обнаруживать, диагностировать и устранять проблемы.

Почему необходим мониторинг?

Мониторинг имеет решающее значение для поддержания работоспособности инфраструктуры данных. Вот почему:

Оптимизация производительности: выявление медленных пайплайнов или фильтров, влияющих на пропускную способность.
Планирование ресурсов: анализ тенденций использования памяти и процессора для эффективного распределения ресурсов.
Устранение неполадок: выявление узких мест до того, как они повлияют на критически важную для бизнеса аналитику.
Надежность: обеспечение бесперебойной работы и предотвращение потери данных в периоды высокой нагрузки.

Инструменты, используемые в этом стеке

Данная конфигурация использует несколько инструментов с открытым исходным кодом, которые бесперебойно взаимодействуют друг с другом:

Logstash

Что это: конвейер обработки данных, который получает данные из множества источников, преобразует их и отправляет в такие целевые системы, как Elasticsearch или Kafka.
Зачем это нужно: это ключевой компонент стека ELK, но его внутренние метрики (такие как скорость обработки событий, размер очереди, показатели JVM) должны быть открыты для внешнего мониторинга.

Prometheus

Что это: база данных временных рядов, предназначенная для мониторинга и оповещения.
Почему используется: Prometheus собирает метрики от экспортеров и эффективно их хранит. Он позволяет выполнять гибкие запросы с использованием PromQL и поддерживает оповещения.

Prometheus-logstash-exporter

Что это: небольшой сервис, который получает метрики из API мониторинга Logstash и предоставляет их в формате Prometheus.
Почему используется: Prometheus не может напрямую опрашивать Logstash, поэтому этот экспортер устраняет эту проблему.

Grafana

Что это: платформа для визуализации данных, предназначенная для создания дашбордов и аналитических отчетов.
Почему используется: Grafana подключается к Prometheus и предоставляет многофункциональные дашборды для визуализации метрик, тенденций и аномалий Logstash.

Docker и Docker Compose

Что это: инструменты для контейнеризации и оркестрации приложений.
Почему их используют: они упрощают развёртывание — одной командой запускаются все компоненты (Prometheus, экспортер, Grafana) в изолированных контейнерах.

Настройка проекта

Клонируйте репозиторий:

git clone https://github.com/yash22091/logstash-monitoring-stack.git
cd logstash-monitoring-stack/ls-monitor

Если у вас zip-архив:

unzip logstash-monitor.zip && cd logstash-monitor/ls-monitor

Конфигурация окружения

Скопируйте пример файла окружения:

cp .env.example .env

Настройте переменные среды:

LS_HOST=172.17.0.1  # IP of host running Logstash (avoid 127.0.0.1)
LS_PORT=9600
EXPORTER_PORT=9304
PROM_PORT=9090
GRAFANA_PORT=3001
GF_ADMIN_USER=admin
GF_ADMIN_PASSWORD=admin

Обзор Docker Compose

Файл docker-compose.yml определяет три контейнера:

prometheus-logstash-exporter — подключается к Logstash и предоставляет доступ к метрикам.
Prometheus — собирает данные каждые 15 секунд.
Grafana — предоставляет дашборды для визуализации данных.

Запустите стек:

docker compose --env-file .env up -d

Получите доступ к пользовательским интерфейсам:

Prometheus → http://localhost:9090
Grafana → http://localhost:3001

LoginScreen

Логин:admin / admin
Затем система попросит изменить пароль по умолчанию

Импорт дашборда Grafana

Для визуализации данных:

Перейдите в Grafana → Dashboards → Import
Введите ID дашборда: 17918
Нажмите Load → выберите Prometheus как источник данных → Import

Импорт

Выберите источник данных

если это не происходит автоматически

Затем установите:

job = logstash
instance = logstash-exporter:9304

Вы увидите дашборды для:

Частота событий (input, filtered, output)
Использование JVM Heap
Статистика сбора мусора (GC)
Использование CPU и задержка пайплайнов

Общий

Использование JVM

Краткий обзор событий

Трубопровод

Фильтры конвейера

Как это работает

Logstash (9600) → prometheus-logstash-exporter (9304) → Prometheus (9090) → Grafana (3001)

Экспортер использует API мониторинга Logstash для сбора данных.
Prometheus получает метрики от экспортера.
Grafana визуализирует эти метрики в режиме реального времени.

Устранение неполадок

Экспортер не работает? Проверьте, что LS_HOST — не 127.0.0.1.

Grafana не отображает данные?

Откройте Prometheus → Status → Targets → убедитесь, что все они активны.
Выполните:

curl http://localhost:9304/metrics | head

Конфликты портов? Отредактируйте .env и перезапустите стек.

Варианты использования и сценарии

Этот набор идеально подходит для:

Мониторинга производительности и пропускной способности пайплайнов Logstash в боевой среде.
Dev-сред — быстрый тест изменений конфигурации и визуализация эффекта.
Реагирование на инциденты — устранить неполадки медленной загрузки данных или заблокированных пайплайнов.
Планирование ресурсов — отслеживайте тренды, прежде чем масштабировать окружение.

Он легковесный, полностью контейнеризированный и может быть расширен другими экспортерами (например, Elasticsearch, Node Exporter или Alertmanager).

Заключение

Этот набор инструментов мониторинга превращает мониторинг Logstash из догадок в получение ценной информации. Сочетание Prometheus, Grafana и Docker дает вам следующие преимущества:

Полную видимость состояния пайплайнов.
Раннее выявление проблем с производительностью
Простая настройка и воспроизводимость.

Независимо от того, используете ли вы кластеры ELK или автономные экземпляры Logstash, эта настройка гарантирует, что ваши конвейеры обработки данных будут работать быстро, стабильно и надежно.

Подписывайтесь на телеграм-канал Мониторим ИТ, там еще больше полезной информации о мониторинге!

12 дашбордов для дежурных, которые успокаивают всех

2025-12-26T09:01:42.446Z

Это перевод оригинальной статьи 12 On-Call Dashboards That Calm Everyone Down.

Практичный план действий для специалистов по реагированию на инциденты, позволяющий превратить хаос в ясность.

Создайте 12 дашбордов для дежурств, которые сокращают среднее время восстановления и панику, охватывая SLO, золотые сигналы, зависимости, развертывания, очереди, затраты и влияние на пользователей с помощью реальных запросов.

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

Как эти дашборды сочетаются друг с другом

Подумайте о пирамиде: начните с результатов для пользователей (SLO), затем перейдите к состоянию сервиса (золотые сигналы), затем углубитесь в зависимости, развёртывания и затраты. Обеспечьте повторяемость каждой панели для разных сервисов и сред.

[Users/SLO]
   └─> [Golden Signals]
        └─> [Dependencies]
             └─> [Infra/Runtime]
                  └─> [Release/Feature Flags]
                       └─> [Queues/Jobs]
                            └─> [Costs]

Все 12 дашбордов могут храниться в виде папок в Grafana, Datadog или New Relic с использованием шаблонных переменных: service, env, cluster, version.

1) SLO и Error Budget (вид «Мы горим?»)

Почему это успокаивает: объединяет всех по единственному важному вопросу: соответствует ли пользовательский опыт целевому уровню прямо сейчас?

Дашборды:

Скорость сжигания скользящего SLO (окна 1 ч/6 ч)
Оставшийся бюджет ошибок (% и время до исчерпания)
Наиболее проблемные SLI (доступность, задержка, качество)

Пример PromQL:

# 1h burn rate example (availability SLI)
(rate(http_requests_total{service="$service",code=~"5.."}[1h]))
/
(rate(http_requests_total{service="$service"}[1h]))

Совет: закрепите правила аннотаций для крупных релизов и всплесков трафика.

2) Четыре золотых сигнала (задержка, трафик, ошибки, насыщение)

Почему это успокаивает: классический вид SRE, который быстро показывает, что сломано.

Дашборды:

Задержка p50/p95/p99, разделенная по маршруту
Тенденции RPS/QPS
Частота ошибок 4xx/5xx
Насыщенность ресурсов (CPU, память, открытые дескрипторы)

Раскладка (ASCII):

[ p95 Latency ]  [ Error Rate   ]
[ RPS Trend   ]  [ Saturation % ]

3) Тепловая карта состояния зависимостей

Почему это успокаивает: большинство сбоев вызваны зависимостями. Позволяет видеть состояние upstream/downstream мгновенно.

Дашборды:

Тепловая карта зависимостей с SLO и частотой ошибок
Таблица выбросов: «Зависимости с отклонением ошибки >3x»
Повторные попытки и тайм-ауты для каждой зависимости

Совет по запросу (в стиле LogQL):

sum by (dependency) (rate(http_client_errors_total{service="$service"}[5m]))

4) Развертывание и разница версий

Почему это успокаивает: подтверждает, имеете ли вы дело с неудачным развертыванием или скрытой ошибкой.

Дашборды:

Запросы/уровень ошибок по version
Сравнение канареечных и базовых значений
Флаги функций с временными метками

Фрагмент PromQL:

sum by (version) (rate(http_requests_total{service="$service"}[5m]))

Включить: развертывание аннотаций, извлеченных из CI/CD (version, commit, author).

5) Мониторинг реальных пользователей (RUM) и синтетические пинги

Почему это успокаивает: если браузер кричит, вы это поймете — особенно в регионах, где вас нет.

Дашборды:

Веб-показатели (LCP, CLS, FID) по странам
Синтетические проверки успеха/задержки по POP
Ошибки фронтенда (stack traces)

Подсказка по сортировке: зеленый бэкенд с красным RUM обычно означает проблемы с CDN, DNS или JavaScript.

6) API-контракт и «горячие» эндпоинты

Почему это успокаивает: концентрирует внимание на нескольких шумных маршрутах, которые являются причиной 80% инцидентов.

Дашборды:

Топ N эндпоинтов по трафику/ошибкам
Изменения версии схемы контракта
Выбросы размеров запросов/ответов

Пример Datadog-метрики:

avg:service.request.duration{service:$service,resource:$route}.rollup(p95)

7) Очереди, задачи и обратное давление

Почему успокаивает: подавляет панику, показывая, восстановится ли система сама или ситуация будет ухудшаться.

Дашборды:

Глубина очереди и время ожидания (time-in-queue)
Задержка потребителя по каждому разделу
Коэффициент DLQ и основные причины сбоев

Пример PromQL для Kafka:

max by (topic, partition) (kafka_consumergroup_lag{group="$service"})

8) Эффективность базы данных и кэша

Почему это успокаивает: позволяет различать ошибки приложения и нагрузку на систему хранения данных.

Дашборды:

DB p95/p99 по группам запросов
Ожидание блокировки и взаимоблокировки
Коэффициент попаданий в кэш (чтение/запись)

Пример Redis LFU:

# Ensure smarter eviction for hot keys
maxmemory-policy allkeys-lfu

Пример SQL (медленные запросы Postgres):

SELECT query, mean_time, calls
FROM pg_stat_statements
ORDER BY mean_time DESC
LIMIT 10;

9) Ограничения скорости, троттлинг и защитные механизмы

Почему успокаивает: показывает, сработали ли «ремни безопасности» — полезно во время наплыва трафика или атак ботов.

Дашборды:

Запросы, заблокированые правилом
Фактический RPS (запросов в секунду) по сравнению с установленным лимитом
Распределение ответов 429 по IP/тенантам

PromQL:

sum by (rule) (rate(rate_limit_blocked_total{service="$service"}[5m]))

10) Стоимость и эффективность (да, во время инцидентов)

Почему это успокаивает: предотвращает необдуманное избыточное резервирование и информирует об откатах с учетом финансового контекста.

Дашборды:

Стоимость за 1 тыс. запросов (амортизированная)
Стоимость за минуту по сервису и региону
Простаивающий и загруженный CPU

Пример оценки: добавьте таблицу, в которой штраф за пропуск умножается на объем, чтобы спрогнозировать стоимость облака, если вы сохраняете деградировавший кэш.

11) Таксономия ошибок и трассировки

Почему успокаивает: позволяет отделить «известные шумные» ошибки от «новых пугающих».

Дашборды:

Классы ошибок с трендом (тайм-аут, валидация, аутентификация, зависимость)
Новые сигнатуры ошибок за последний час
Трассировочная диаграмма (waterfall) для трёх наиболее проблемных маршрутов

Фильтр OTel трассировок (псевдокод):

service.name = "$service" AND status.code = ERROR
| top span.attributes["http.target"] by count

12) Руководство на одном экране (человеческий дашборд)

Почему это успокаивает: ставит чеклист рядом с графиками. Никому не приходится искать ссылки в Confluence в 3 часа ночи.

Дашборды:

Руководство в формате Markdown с деревом решений
Расписание дежурств и кнопки эскалации
Хронология недавних инцидентов и шаблон сообщений

Фрагмент ASCII-кода (путь решения):

[Budget burning?]--No-->[Monitor]
        |
       Yes
        v
[Latency spike?]--Yes-->[Check Dependencies Heatmap]
        | No
        v
[Error spike]-->[Rollout & Version Diff]->Rollback?

Минимальный шаблон настройки (чтобы можно было развернуть на этой неделе)

Переменные: service , env, region, version, dependency.
Стандартные аннотации: деплои, изменения конфигураций, изменения флагов функций, изменения правил rate-limit.
Распространенные условные обозначения: красный = воздействие на пользователя, желтый = риск, синий = норма, серый = фон.
Доступ: делитесь ссылками только для чтения с продуктовой командой/саппортом; добавьте подсказку «Что означает этот вид» на каждой панели.

Пример: спокойный инцидент на 15 минут

Минута 1–3: SLO показывает расход за 1 час выше порога; золотые сигналы указывают на p99 задержку только для GET /search.
Минута 4–6: индикатор зависимостей высвечивает ошибки кэша; БД выглядит нормально.
Минута 7–9: дашборд с деплоями показывает новую версию на 25% канареечного деплоя, коррелирующую с обращениями к кэшу.
Минута 10: устранение канареечных ошибок.
Минуты 11–15: очереди освобождаются; расход SLO снижается. Дашборд стоимости подтверждает отсутствие неконтролируемых расходов. Все выдыхают.

Заметки и фрагменты реализации

Alert burn-rate (многооконный):

# Alerts if both short and long windows exceed thresholds
( rate(sli_errors_total{service="$s"}[5m]) / rate(sli_total{service="$s"}[5m]) > 0.02 )
and
( rate(sli_errors_total{service="$s"}[1h]) / rate(sli_total{service="$s"}[1h]) > 0.01 )

Пример шаблона Grafana (JSON):

{
  "templating": {
    "list": [
      {"type":"query","name":"service","query":"label_values(up, service)"},
      {"type":"query","name":"env","query":"label_values(up, env)"},
      {"type":"query","name":"version","query":"label_values(http_requests_total, version)"}
    ]
  }
}

Пример аннотации таймлайна инцидента (псевдо):

curl -X POST "$GRAFANA/api/annotations" \
  -H "Authorization: Bearer $TOKEN" \
  -d '{"text":"Canary 3 deployed","tags":["deploy","canary"],"time":1699999999999}'

Распространенные ошибки (и как эти дашборды их предотвращают)

Разрастание панели управления: этих 12 достаточно. Не дублируйте по командам; используйте переменные.
Отсутствие общего языка: называйте панели терминами SRE (SLO, burn rate, p95) и сохраняйте единообразие.
Нет контекста: всегда аннотируйте деплои, флаги функций и изменения инфраструктуры.
Устаревшие панели: Просматривайте ежемесячно; привязывайте графики к оповещениям, чтобы они никогда не смещались.

Заключение

Спокойствие — это результат ясности. Благодаря этим 12 дашбордам мониторинга вы предоставляете каждому сотруднику дежурной смены единый, надежный путь от устранения последствий для пользователя до первопричины — быстро и эффективно. Инциденты всё ещё случаются. Паника не обязательна.

Подписывайтесь на телеграм-канал Мониторим ИТ, там еще больше полезной информации о мониторинге!

Автоматизированные процессы реагирования на инциденты с помощью n8n и Prometheus

2025-12-26T08:42:58.384Z

Это перевод оригинальной статьи Automated Incident Response Workflows with n8n and Prometheus.

Это руководство поможет команде использовать n8n и Prometheus для автоматизации реагирования на некоторые инциденты.

1. Процесс реагирования на инциденты

Эффективное управление инцидентами предполагает структурированный подход, который можно улучшить с помощью автоматизации на каждом этапе:

Подготовка

Документация: ведение runbook’ов и процедур реагирования
Настройка мониторинга: настройте алерты Prometheus с соответствующими порогами.
Готовность команды: убедитесь, что графики дежурств и пути эскалации четко определены.

Обнаружение и анализ

Активация оповещений: Prometheus обнаруживает аномалии на основе предопределенных правил.
Первоначальная оценка: автоматическая классификация по уровню критичности и влиянию.
Контекстное обогащение: добавление релевантной системной информации в оповещения.

Восстановление

Маршрутизация уведомлений: направление оповещений по соответствующим каналам (PagerDuty, Slack)
Руководство по реагированию: ссылки на соответствующие руководства или документацию.
Автоматическое устранение: запуск скриптов восстановления для известных проблем.

Действия после инцидента

Документация: фиксация хронологии и деталей реагирования.
Анализ: определение корневых причин и возможностей для предотвращения.
Улучшение процесса: обновление правил мониторинга и рабочих процессов реагирования.

На следующих этапах мы создадим поток автоматизации, который будет охватывать обнаружение и анализ, а также направлять оповещения на основе контекста.

2. Создание процесса реагирования на инциденты с n8n + Prometheus

Давайте создадим практичный рабочий процесс, который будет разумно управлять оповещениями Prometheus, гарантируя, что критически важные проблемы будут отправляться с учетом критичности, рабочего времени,…

Обзор рабочего процесса

Наша цель — построить систему, которая:

Получает оповещения от Prometheus/AlertManager
Анализирует уровень критичности и рабочее время.
Направляет критически важные алерты вне рабочего времени в PagerDuty для немедленного реагирования.
Отправляет менее срочные или алерты в рабочее время в Slack/Discord.
Автоматизирует разрешение инцидентов на основе предложений AI-агента.
Lambda-функция выполняет ваши операции (можно кастомизировать для ECS, EKS и других).
Документирует все инциденты в структурированном формате (Notion)

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

Настройка стека мониторинга

Перед построением нашего рабочего процесса n8n необходимо правильно настроить систему мониторинга:

Установить стек Prometheus

Сервер Prometheus для сбора метрик
Exporters для ваших конкретных сервисов
AlertManager для обработки оповещений
Grafana для визуализации

Для облегчения настройки стека я подготовил скрипты для развёртывания «Node Exporter — Prometheus — Alert Manager — Grafana Stack» по щелчку мыши. Вы можете посмотреть, скачать и развернуть самостоятельно.

2. Настройка правил алертов в Prometheus

Ниже приведен пример кода для активации оповещений.

groups:
- name: example
  rules:
  - alert: HighCPU
    expr: 100 - (avg by (instance) (irate(node_cpu_seconds_total{mode="idle",job="exporters"}[5m])) * 100) > 10
    for: 1m
    labels:
      severity: critical
      service: node
    annotations:
      description: "CPU usage on {{ $labels.instance }} is {{ $value }}%"
  - alert: HighLatency
    expr: rate(http_request_duration_seconds_sum[5m]) / rate(http_request_duration_seconds_count[5m]) > 0.5
    for: 1m
    labels:
      severity: warning
      service: web
    annotations:
      description: "Response time on {{ $labels.instance }} is {{ $value }}s"

3. Настройка AlertManager для пересылки на n8n

route:
  receiver: 'n8n-webhook'
  group_by: ['alertname', 'instance']
  group_wait: 30s
  group_interval: 1m
  repeat_interval: 30m

receivers:
- name: 'n8n-webhook'
  webhook_configs:
  - url: '<http://your-n8n-instance:5678/webhook/prometheus>'
    send_resolved: true

Создание рабочего процесса n8n

Теперь давайте создадим наш рабочий процесс n8n для интеллектуальной обработки этих оповещений:

Создайте узел Webhook

Это позволит получать оповещения от AlertManager.
Настройте его на разбор JSON-данных.

Примечание: чтобы использовать «Production URL», необходимо перевести рабочий процесс в состояние «Active» (активный).

2. Добавьте узел Function для классификации оповещений

Чтобы проанализировать полезную нагрузку от Prometheus, мы попытаемся разобрать JSON. Также мы рассчитаем рабочее время и продолжительность инцидента, что поможет нам точнее оценить ситуацию.

Добавьте узел кода, введите следующий код JavaScript:

const alerts = items[0].json.body.alerts || [];
return alerts.map(alert => ({
  const startsAt = new Date(alert.startsAt);
  const endsAt = new Date(alert.endsAt);
  const hour = endsAt.getUTCHours();
  const isBusinessHours = hour >= 9 && hour < 17; // 9 AM–5 PM UTC
  const durationMinutes = (endsAt - startsAt) / 1000 / 60; // Duration in minutes
  json: {
    status: alert.status, // firing or resolved
    alertname: alert.labels.alertname, // e.g., HighCPU
    severity: alert.labels.severity, // e.g., critical
    instance: alert.labels.instance, // e.g., 47.129.163.27:9100
    service: alert.labels.service, // e.g., node
    description: alert.annotations.description, // e.g., CPU usage description
    startsAt: alert.startsAt, // e.g., 2025-05-25T06:40:29.682Z
    endsAt: alert.endsAt, // e.g., 2025-05-25T06:42:59.682Z
    fingerprint: alert.fingerprint, // e.g., 80e7d055dbb50b48
    isBusinessHours: isBusinessHours, // true if within 9 AM–5 PM UTC
    durationMinutes: durationMinutes // Duration in minutes
  }
}));

3. Добавьте узел Switch для маршрутизации.

Маршрутизация будет осуществляться на основе критичности и рабочего времени, будет три пути:

Критический + вне рабочего дня → PagerDuty
Критический + Рабочие часы → Discord (канал для срочных сообщений)
Некритический → Discord (общий канал оповещений)

4. Настройте интеграцию с сервисами

Узел PagerDuty:

Подключитесь к сервису PagerDuty
Сопоставьте данные оповещения с полями инцидента
Установите соответствующую критичность

Узел Discord:

Создайте отформатированные сообщения с подробностями об оповещении.
Включите ссылки на дашборды Grafana
Добавьте ссылки на runbook’и, если они доступны.

5. Добавьте интеграцию с Notion для документации

Создайте узел базы данных Notion
Регистрируйте все инциденты с временными метками, уровнем серьёзности и деталями реагирования
Добавляйте статус решения и последующие задачи

При запуске указанного выше процесса вы будете направлять оповещения на основе определенных вами правил. Это всего лишь мой пример:

Оповещения среднего уровня отправляются в Discord, команда может проверить их позже.

Критические оповещения, поступающие поступающие вне рабочих часов или в праздничные дни, отправляются в PagerDuty. На панели управления PagerDuty вы можете настроить правила звонков и эскалации.

Урегулировать инцидент

Предлагаемая подсказка(prompt) для ИИ-агента, которая обработает контекст для вас:

Analyze the following Prometheus alert to determine if it should be auto-resolved by restarting the EC2 instance to handle issues like high CPU usage, especially when the team is unavailable. The context is:

- Alert Name: {{ $node["Code"].json["alertname"] }}
- Severity: {{ $node["Code"].json["severity"] }}
- Duration: {{ $node["Code"].json.durationMinutes }} minutes
- Business Hours: {{ $node["Code"].json["isBusinessHours"] }} (true if 9 AM–5 PM UTC, false otherwise)
- Description: {{ $node["Code"].json["description"] }}

Extract the CPU usage (X%) from the description, formatted as: "On <instance> at <alertname>: CPU usage is X%, Memory available is Y%, Swap usage is Z%, Disk I/O is A s, Network received is B MB/s, Latency is C s".

Decide to auto-resolve (restart the EC2 instance) if:
1. CPU usage > 80% AND outside business hours (isBusinessHours is false).
2. CPU usage > 90% AND duration < 5 minutes.
3. Severity is "critical" AND outside business hours (isBusinessHours is false).

Return only the following JSON object, with no additional text, explanations, or markdown:
{
  "shouldAutoResolve": boolean,
  "reason": "Explanation of the reason why this action should or should not be auto-resolved, referencing CPU usage, duration, severity, and business hours if relevant."
}

- If shouldAutoResolve is true, a Lambda function will be triggered to restart the EC2 instance.
- If shouldAutoResolve is false, no restart will occur.
- Keep the reason concise and clear, referencing the specific criteria met or not met.
- If CPU usage cannot be extracted, assume 0% and include it in the reason.

Он будет следовать ожидаемому контексту и принимать решение о том, перезапускать сервис или нет:

3. Улучшение рабочего процесса

Вы можете улучшить рабочий процесс в соответствии со своими потребностями. Я порекомендую несколько подходов:

Этап уведомления

N8n поддерживает различные типы интеграций, такие как Slack, Telegram, Rocketchat и т.д. Вы можете интегрировать все, что вам нужно.

Этап анализа

Можно подключить ИИ-агента, LLM-chain или OpenLLM для оценки метрик и маршрутизации инцидентов.

Вы можете значительно улучшить рабочий процесс следующим образом:

Реализуйте интеллектуальное подавление: агрегируя метрики из Prometheus Alertmanager, можно использовать узел ИИ в n8n, чтобы подавлять или эскалировать проблему для команды.
Проверки внешних зависимостей: мы можем интегрироваться с некоторыми внешними сервисами, такими как DNS, Vercel, AWS и т. д., чтобы убедиться, что инцидент обработан корректно.

Этап логирования инцидентов

Вы можете интегрировать в хранилища, такие как GoogleSheet, MongoDB, SQL и т. д. Поддерживаются многие типы баз данных.

4. Примеры кодов и рабочего процесса

Рабочий процесс реагирования на инциденты (json) — https://github.com/Bubobot-Team/automation-workflow-monitoring/blob/main/n8n/n8n___Incident_Response___1.json
Развертывание Node Exporter — Prometheus — Alert Manager — Grafana Stack в режиме Click-Run: https://github.com/Bubobot-Team/monitoring-stack/tree/main/stacks/prometheus-stack

Подписывайтесь на телеграм-канал Мониторим ИТ, там еще больше полезной информации о мониторинге!

10 вопросов о наблюдаемости Kubernetes, которые задают на каждом собеседовании в DevOps.

2025-12-26T08:25:44.144Z

Это перевод оригинальной статьи 10 Kubernetes Observability Questions That Show Up in Every DevOps Interview.

Вопросы о наблюдаемости Kubernetes, от которых зависит ваш успех или провал на следующем собеседовании по DevOps.

Я провёл собеседования с более чем 150 кандидатами на должность DevOps за последний год. И тема, на которой я больше всего сосредотачиваюсь, — наблюдаемость.

Когда я спрашиваю: «Расскажите мне о вашей архитектуре логирования», я обычно получаю в ответ либо пустые взгляды, либо расплывчатые ответы вроде «использую Prometheus и Grafana». Но этого уже недостаточно.

Компании ищут не просто людей, знающих названия инструментов. Им нужны инженеры, которые понимают, как на самом деле работают производственные системы. Как происходит обмен логами. Как собираются метрики. Как оповещения доходят до нужных людей в 3 часа ночи.

Поэтому я делюсь теми самыми вопросами, которые задаю, вместе с ответами, которые отличают младших специалистов от старших.

Расскажите, пожалуйста, о вашей текущей архитектуре логирования. Как вы собираете и храните логи в своей среде Kubernetes?

Вот как должен звучать хороший ответ:

Мы используем паттерн сайдкара. Основной контейнер пишет логи в общий том. Sidecar Fluentd считывает эти логи и отправляет их в CloudWatch. Оттуда логи проходят через Kinesis Firehose в OpenSearch для быстрых запросов. Мы храним 7 дней в OpenSearch, 30 дней в CloudWatch и архивируем все в S3 для соответствия требованиям.

Почему этот ответ работает: он показывает, что вы понимаете весь поток данных, а не только отдельные инструменты. Вы знаете, зачем нужен каждый компонент и как долго следует хранить данные на каждом этапе.

Что делает этот ответ неработоспособным: утверждение «мы используем Fluentd» без объяснения архитектуры. Или, что еще хуже, незнание того, куда на самом деле попадают ваши логи.

Я вижу, вы используете OpenSearch. Почему бы просто не хранить все данные в CloudWatch? Разве это не проще?

Этот вопрос проверяет ваше понимание компромиссов, а не только используемых инструментов.

CloudWatch становится дорогим и медленным при обработке петабайтов данных. OpenSearch создан для высокоскоростных запросов к огромным массивам данных. Для небольшого стартапа CloudWatch вполне подойдет. Но в больших масштабах OpenSearch необходим для анализа в реальном времени, и он обходится дешевле при частых запросах.

Почему это важно: боевые системы генерируют тонны логов. Вам нужно быстро запрашивать их, когда что-то ломается. CloudWatch для этого не предназначен. А вот OpenSearch — предназначен.

Тревожный ответ: «Потому что все используют OpenSearch» или «В моей предыдущей компании его использовали». Это говорит о том, что вы не принимаете архитектурные решения, а просто копируете то, что делают другие.

Вопрос 3: Можете объяснить разницу между логами и метриками? Когда следует использовать каждый из них?

Большинство людей считают, что это одно и то же. Это не так.

Правильный ответ:

Логи событий похожи на дневник. В них записывается всё, что произошло. Пользователь вошёл в систему из Индии. API выдал ошибку 500. Платеж не удался при оформлении заказа.

Метрики — как монитор состояния. Они измеряют, как всё работает. CPU на уровне 80 %. Время ответа — 250 мс. Приложение работает 99,5 % времени.

Подумайте об этом так:

Логи = что произошло, Метрики = насколько хорошо работает

Вот почему вам нужны оба в продакшене:

Ваш API внезапно стал работать медленно. Метрики показывают, что проблема существует. Латентность выросла со 100 мс до 5 секунд. Что-то не так.

Но метрики не говорят вам, ПОЧЕМУ это происходит медленно. Вот тут-то и пригодятся логи. Вы проверяете логи и обнаруживаете, что один конкретный запрос к базе данных выдал ошибку тайм-аута.

Метрики говорят вам, что есть пожар. Логи говорят вам, где он начался и что горит.

Невозможно устранить проблемы, используя только один из методов. Вам нужны оба.

Я вижу Prometheus и Grafana в вашем наборе инструментов. В чём разница? Зачем вам оба?

Это сбивает с толку многих людей, потому что, видя, как эти инструменты используются вместе, они предполагают, что делают одно и то же.

Prometheus собирает и временно хранит метрики, обычно 10–15 дней. Он сканирует конечные точки вашего приложения каждые 15–30 секунд. Grafana просто визуализирует данные. Она делает некрасивые цифры красивыми. Представьте Prometheus как сборщик данных, а Grafana — как слой их визуализации.

Вот в чём большинство людей ошибаются: Prometheus НЕ хранит долговременные данные. Если вам нужны исторические метрики за период более нескольких недель, вам потребуется что-то другое. Именно поэтому в боевых системах часто добавляют Thanos или Cortex для долговременного хранения данных.

В вашем соглашении об уровне обслуживания (SLA) клиентам гарантируется 99,5% времени бесперебойной работы. Что это на самом деле означает с точки зрения допустимого времени простоя?

Я задаю этот вопрос, чтобы проверить, понимают ли кандидаты влияние своей работы на бизнес, а не только техническую сторону вопроса.

В 30-дневном месяце у вас есть 2 592 000 секунд. 99,5% времени безотказной работы означает, что допустимый простой составляет 0,5%. Это 12 960 секунд, или максимум около 3,6 часов в месяц. Мы отслеживаем это в режиме реального времени, и клиенты могут видеть фактическое время безотказной работы на панелях мониторинга.

Почему это важно: DevOps — это не просто поддержание работоспособности систем. Это выполнение обязательств перед бизнесом. Если вы не можете перевести технические показатели в бизнес-результаты, вы упускаете половину картины.

Как вы аутентифицируете Grafana для получения данных из CloudWatch? Расскажите подробнее о вашем подходе к обеспечению безопасности.

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

Никогда не используем ключи доступа. Мы создаём роль IAM с правами чтения CloudWatch, а затем сопоставляем её с сервисной учётной записью пода Grafana с помощью OIDC. Тот же паттерн, что и у AWS Load Balancer Controller. Под автоматически получает эту роль. Никакие учётные данные не хранятся в коде.

Тревожный сигнал: если кто-то упоминает о жестком кодировании учетных данных AWS или их хранении в ConfigMaps, собеседование практически закончено. Это потенциальный инцидент, связанный с безопасностью боевой среды.

Какой интервал скрапинга вы используете для Prometheus и почему выбрали именно его?

Это проверяет соответствие практических знаний теоретическим.

Наш стандарт — 15–30 секунд. Меньшее значение нежелательно, так как это приведет к перегрузке системы запросами. Мы настраиваем путь endpoint’а, обычно /metrics, частоту сбора данных и время хранения в манифесте ServiceMonitor.

В продолжение я всегда спрашиваю: «Что произойдет, если установить время на 5 секунд?» Хорошие кандидаты знают, что это создает ненужную нагрузку. Отличные кандидаты действительно ломали систему таким образом и извлекали из этого урок.

Мы рассматриваем Datadog. Вы использовали и Datadog, и Prometheus плюс Grafana. Что вы думаете о том, когда стоит использовать каждый из них?

Этот вопрос покажет, понимаете ли вы компромисс между стоимостью и сложностью.

Datadog — это универсальное решение. Мониторинг, логи, метрики, панели мониторинга — всё встроено. Не требует настройки. Но оно очень дорогое. Prometheus плюс Grafana — это решение с открытым исходным кодом, более дешевое, но требует специальных знаний для правильной настройки. Ключевой момент: есть ли у вас команда и время? Используйте Prometheus. Хотите быстро продвинуться вперед и у вас есть бюджет? Используйте Datadog.

По сути, я спрашиваю: можно ли принимать архитектурные решения, исходя из размера команды, бюджета и технических требований? Или вы просто выбираете то, что популярно в LinkedIn?

Я заметил, что вы упомянули sidecar контейнеры для логирования. Можете объяснить, как работает этот паттерн?

Этот тест проверяет, понимаете ли вы Kubernetes-паттерны, а не просто отдельные контейнеры.

Оба контейнера работают в одном поде и используют общий смонтированный том. Ваше приложение записывает логи в этот том. Sidecar, например Fluentd, читает из того же тома и отправляет логи в CloudWatch или OpenSearch. Это позволяет отделить ведение логов от вашего приложения. Вы можете менять инфраструктуру логирования без изменения кода приложения.

Почему этот паттерн важен: в продакшене вам нужно менять backend логирования, добавлять новые назначения или менять вендоров. Если логирование встроено в код приложения, любое изменение требует нового деплоя. Sidecar решает это.

Если бы завтра вы настраивали мониторинг для нового микросервисного приложения, какие метрики вы бы отслеживали с первого дня?

Это мой любимый вопрос, потому что он показывает, как кандидаты оценивают готовность к работе в боевых средах.

Задержка. Время ответа в миллисекундах. Частота ошибок. 500-е, 400-е по эндпоинтам. Пропускная способность. Количество запросов в секунду. Процент времени безотказной работы. Использование CPU и памяти по сервисам. Типы запросов. Шаблоны GET, POST, DELETE. Географические данные. Откуда поступает трафик. Это помогает соблюдать SLA и выявлять проблемы до того, как их заметят клиенты.

Кандидаты, которые произвели на меня впечатление, добавляют: «И я бы настроил оповещения по этим показателям до запуска системы, а не после возникновения инцидента».

Фото Мари Лежавы на Unsplash

Вот что важно на собеседованиях по DevOps.

Речь идёт не о запоминании инструментов, а о понимании процесса. От приложения к сбору данных, к хранению, к визуализации и к оповещениям.

Освоив этот принцип, вы сможете объяснить работу любой системы мониторинга. Будь то Prometheus и Grafana, Datadog, New Relic или любой новый инструмент, который появится в следующем году.

Я видел кандидатов с двухлетним опытом, которые отлично понимают этот процесс, и они с легкостью проходят собеседования. А также видел ветеранов с пятилетним стажем, которые запомнили команды инструментов, но не могут объяснить архитектуру, и терпят сокрушительное поражение.

Чего на самом деле хотят компании?

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

Можете ли отследить поток данных через несколько систем?

Понимаете ли вы влияние простоев на бизнес? Можете ли вы принимать компромиссные решения, учитывая стоимость, сложность и размер команды?

Если вы умеете это делать, конкретные инструменты не имеют значения. Вы освоите тот набор технологий, который использует компания.

Как на самом деле подготовиться к этим вопросам

Прекратите смотреть 10-часовые курсы по каждому инструменту мониторинга. Вместо этого постройте один полный стек мониторинга с нуля.

Возьмите Prometheus и Grafana.
Настройте его для реального применения.
Сломайте. Почините.
Поймите, зачем существует каждый элемент.
Затем проделайте то же самое с логами.
Настройте Fluentd или Fluent Bit.
Отправьте логи в CloudWatch или Loki.
Делайте запросы. Ломайте пайплайн. Чините его.

За две недели практических занятий вы узнаете больше, чем за шесть месяцев просмотра обучающих видеороликов.

Подписывайтесь на телеграм-канал Мониторим ИТ, там еще больше полезной информации о мониторинге!

10 дашбордов Grafana, которые позволяют выявлять инциденты на ранней стадии

2025-12-19T11:34:05.058Z

Это перевод оригинальной статьи 10 Grafana Dashboards That Catch Incidents Early.

В этой статье собраны практичные, легко копируемые и вставляемые дашборды, которые выявляют проблемы на ранней стадии, позволяя устранить их до того, как это заметят клиенты.

Десять дашбордов Grafana — расход SLO, путь пользователя, насыщение, очереди, база данных, кэш, CDN, механизмы контроля релизов и «ситуационная комната» дежурного — которые позволяют обнаруживать инциденты на ранней стадии.

Давайте будем реалистами: тысяча графиков не спасет вас в 2 часа ночи. Спасут вас десять правильных графиков, основанных на фундаментальных принципах и настроенные на сигнал, а не на шум. Ниже приведены дашборды, которые я снова и снова видел превращающими «загадочные падения» в «незначительные сбои». Каждый из них объясняет, как он работает, и содержит фрагмент кода, который вы можете адаптировать под себя.

Предположения: в примере использованы Prometheus/PromQL для метрик, Loki для логов, Tempo/OTel для трассировок. Меняйте компоненты в своей системе по мере необходимости; основные принципы остаются неизменными.

1) SLO Pulse: расход бюджета ошибок (канарейка среди канареек)

Что показывает: расходуется ли бюджет ошибок прямо сейчас?
Панели: скорость расхода за 4 часа и за 30 дней, коэффициент расхода, коэффициент успешности, наиболее проблемные конечные точки.

PromQL (многооконное вычисление выгорания):

# 99.9% SLO
ratio_5m = sum(rate(http_request_duration_seconds_count{status!~"5.."}[5m]))
 / sum(rate(http_request_duration_seconds_count[5m]))
ratio_1h = sum(rate(http_request_duration_seconds_count{status!~"5.."}[1h]))
 / sum(rate(http_request_duration_seconds_count[1h]))
burn = ((1 - ratio_5m) / (1 - 0.999)) + ((1 - ratio_1h) / (1 - 0.999))

Почему это работает: функция Burn Rate сопоставляет оповещения с проблемами клиентов, а не с поверхностными скачками загрузки CPU.

2) Воронка пользовательского пути: где произошло снижение конверсий?

Что показывает: какой этап в последовательности «поиск → товар → оформление заказа → оплата» вызывает сбой — практически в режиме реального времени.
Панели: процент конверсии на каждом этапе, отклонение относительно прошлой недели, задержка на этапе p95, тепловая карта отвалов по регионам.

PromQL:

# Per-step success ratios
sum(rate(app_event_total{event="checkout_success"}[5m]))
/ ignoring(event) group_left
sum(rate(app_event_total{event="checkout_start"}[5m]))

Почему это работает: вы обнаруживаете неработающие кнопки, сбои сторонних разработчиков или предупреждения о проблемах с функциями задолго до того, как это сделает Twitter.

3) USE-дашборд для инфраструктуры(Utilization, Saturation, Errors)

Что показывает: нагрузка на CPU/память/ввод-вывод и фактическая загрузка (очереди, ограничение скорости).
Панели: загрузка CPU узла, длина очереди выполнения, загрузка диска (%), время ожидания диска (disk await), потери в сети, контейнеры с ограничением (throttled).

PromQL:

# CPU saturation (runnable tasks)
node_load1 / count(count(node_cpu_seconds_total{mode="idle"}) by (instance))
# Disk saturation
rate(node_disk_io_time_seconds_total[5m])

Почему это работает: метод USE выявляет запас прочности. Вы увидите надвигающуюся конкуренцию за ресурсы ещё до того, как показатели упрутся в 100%.

4) Очереди и обратное давление: панель «Справляемся ли мы?»

Что это показывает: задержки и пропускную способность для Kafka/Rabbit/SQS; состояние потребителей.
Панели: задержка по группам потребителей, скорость записи и чтения, количество сообщений в dead-letter очередях, возраст самого старого сообщения.

PromQL:

# Kafka consumer lag (exporter varies)
max(kafka_consumergroup_lag{group="payments"}) by (topic, partition)
# Oldest message age (seconds)
max_over_time(kafka_topic_oldest_message_age_seconds[5m])

Почему это работает: медленные потребители услуги часто являются первым первым признаком проблем на последующих этапах обработки.

5) Проверка базы данных в реальных условиях: соединения, блокировки, медленные запросы

Что это показывает: насколько работоспособна Postgres/MySQL под реальной нагрузкой?
Панели: активные соединения против максимального количества, количество и длительность ожидания блокировки, время выполнения запроса p95 по типу, топ-N медленных запросов (Loki), задержка репликации.

PromQL (Postgres):

# Waiting locks
sum(pg_locks_count{mode!="AccessShareLock",state="waiting"})
# Replication lag seconds
max(pg_stat_replication_lag_seconds)

Loki (медленный запрос к таблице):

{app="postgres"} |= "duration:" | json | duration > 200ms
| stats count() by query

Почему это работает: ожидания блокировок резко растут перед тем, как приложение падает.

6) Cache Truth Serum: обращения с учетом контекста

Что это вам говорит: не переплачиваете ли вы за обращения к основному хранилищу?
Панели: соотношение обращений/потерь во времени, причины потерь (новые данные — cold, или удалённые из кэша — evicted), задержка кэша p95, объём вытесненных данных.

PromQL (Redis/Dragonfly):

sum(rate(redis_keyspace_hits_total[5m]))
/ (sum(rate(redis_keyspace_hits_total[5m])) + sum(rate(redis_keyspace_misses_total[5m])))

Почему это работает: незаметное падение hit ratio — одно из самых ранних предупреждений о проблемах.

7) Раннее предупреждение на уровне CDN и edge: задержки, TLS и ошибки на источнике.

Что это показывает: есть ли помехи на сети?
Панели: p90 и p99 задержки edge по POP, время установления соединения TLS, процент ошибок 5xx от источника, состояние кэша (HIT/MISS/BYPASS).

LogQL (структурированные логи edge):

{source="edge"} | json | status >= 500
| stats sum(count) by pop, route

Почему это работает: вы быстро отделяете проблемы origin от неисправного POP или провайдера, не тратя время на ложные поиски.

8) Ограничения при развертывании: feature-флаги и изменения ошибок по когортам

Что это показывает: навредила ли новая функция какой-то конкретной когорте пользователей?
Панели: разница в уровне ошибок при flag=on и при off, разница в задержке p95, наиболее затронутые конечные точки, подсказка по автоматическому откату.

PromQL (сравнение когорт):

err_on  = sum(rate(http_requests_total{status=~"5..",flag="on"}[5m]))
/ sum(rate(http_requests_total{flag="on"}[5m]))
err_off = sum(rate(http_requests_total{status=~"5..",flag="off"}[5m]))
delta   = err_on - err_off

Почему это работает: вы получаете не просто корреляцию, а причинно- следственные связи. Идеально подходит для поэтапной подачи информации.

9) Мини-карта трассировок: куда на самом деле уходит время?

Что это показывает: какой сервис или эндпоинт отвечает за последний всплеск задержек.
Панели: граф зависимостей сервисов (Tempo/OTel), p95 длительности спанов по операциям, очаги ошибок, автоматическая фокусировка на «красной ноде».

Преобразование Grafana: используйте панель «График сервисов» (Tempo) и таблицу со столбцами service.operation, p95, error_rate.

Почему это работает: трассировка устраняет взаимные обвинения. Горячий узел светится красным; вы связываетесь с нужной командой.

10) Ситуационная комната дежурного: один взгляд, одно место

Что это вам говорит: «Всё ли у нас в порядке?» И если нет, куда смотреть в первую очередь.
Структура:

Строка 1: Индикатор расхода SLO, активные оповещения (небольшая таблица), контакт дежурного.
Строка 2: задержка p95 + частота ошибок (глобальная), объем запросов, насыщение (CPU/очередь).
Строка 3: «Последние 5 релизов» (аннотации), ошибки по конечным точкам, топ медленных запросов.
Строка 4: Ссылки на руководство по выполнению заданий и переключатель «убрать шум» (сравнение с прошлой неделей).

ASCII-эскиз:

+------------------+----------------------+------------------+
|  SLO Burn Gauge  |   Active Alerts      |  On-call: @you   |
+------------------+----------------------+------------------+
| p95 Latency      | Error Rate           | Request Volume   |
+------------------+----------------------+------------------+
| CPU Saturation   | Queue Lag            | DB Lock Waits    |
+------------------+----------------------+------------------+
| Deploy Annotations | Endpoint Errors    | Slow Queries     |
+--------------------+--------------------+------------------+
| Runbooks | Feature Flags | Toggle: compare to last week      |
+--------------------------------------------------------------+

Почему это работает: во время инцидента вам не нужна навигация. Вам нужна приборная панель пилота.

Алерты, которые не засыпают вас сообщениями.

Каждый дашборд сопоставьте с одним алертом, учитывающим бюджет:

SLO Burn: срабатывание при 2× burn (быстро), 1× burn (медленно) с группировкой по меткам ({service, region}), 10 минут для быстрого, 30 минут для медленного.
Очереди: оповещение по наклону задержки, а не по абсолютному значению: deriv(lag[10m]) > 0 и lag > threshold.
БД: время ожидания блокировки > 20 с в течение 3 мин; задержка репликации > 60 с.
CDN: ошибки origin 5xx > 1% в любом POP в течение 5 минут.

Grafana Mimir/Alerting JSON (скетч):

{
  "title": "Fast burn (99.9% SLO)",
  "condition": "B",
  "data": [
    {
      "refId": "A",
      "expr": "((1 - ratio_5m)/(1-0.999)) > 2",
      "intervalMs": 60000
    }
  ],
  "for": "10m",
  "labels": {"severity":"page","team":"api"},
  "annotations": {"runbook":"https://…/runbooks/slo-burn"}
}

Маленькие привычки, которые дают большой эффект

Сдвиги во времени ( now-1w) на ключевых панелях нормализуют сезонность, связанную с днями недели.
Аннотации, полученные в ходе CI/CD (развертывания, изменения функций), уменьшают количество догадок.
Единообразие единиц измерения: отображать миллисекунды (а не секунды), проценты (а не десятичные дроби).
Связи: каждая панель должна вести либо на углублённый дашборд, либо в режим исследования.

Заключительные мысли

Вам не нужно больше графиков — вам нужно более четкое понимание цели. Начните с SLO и ситуационной комнаты для дежурных, добавьте очереди и базу, затем внедрите механизмы контроля, позволяющие выявлять проблемы в группе на ранней стадии. Сделайте это, и инциденты перестанут быть внезапными пугающими событиями и начнут превращаться в управляемые истории.

Подписывайтесь на телеграм-канал Мониторим ИТ, там еще больше полезной информации о мониторинге!