ТЕХНИЧЕСКОЕ ЗАДАНИЕ: Настроить monitoring сообщений в системе inter-agent communication

1. Цель задачи

Сконфигурировать сбор и визуализацию ключевых метрик обмена сообщениями между агентами: количество сообщений в секунду (msg/s), задержка сообщений (latency), доля ошибок (error rate) и размер очереди недоставленных сообщений (DLQ size). Построить дашборд в Grafana для оперативного контроля состояния коммуникации между агентами и выявления аномалий.

Ключевой результат Рабочий дашборд Grafana с четырьмя панелями (msg/s, latency, error rate, DLQ size) на данных из Prometheus, полученных от instrumented-кода агента или симулированного брокера сообщений.

2. Исходные данные

Если нет реального брокера — симулируем:

1. Написать Python-скрипт simulate_agent.py, который имитирует отправку сообщений (через простую очередь asyncio.Queue) и собирает статистику (время отправки, успешность).
2. Выставить метрики в Prometheus формате через prometheus_client на порту 8000 (например, /metrics).
3. Запустить скрипт и Prometheus (локально или в Docker) так, чтобы Prometheus scraper собирал метрики.

3. Технологический стек

4. Этапы выполнения

Этап 1: Настройка брокера сообщений и сбор метрик (45–60 минут)

Действия

1. Запустить брокер сообщений (выберите любой доступный).

   • RabbitMQ: docker run -d --name rabbitmq -p 5672:5672 -p 15672:15672 rabbitmq:3-management
   • Kafka: docker-compose с Zookeeper + Kafka (образы confluentinc/cp-kafka:latest)
   • NATS: docker run -d --name nats -p 4222:4222 nats:latest

2. Настроить экспорт метрик в Prometheus:

   • Для RabbitMQ: скачать rabbitmq_exporter (например, kbudde/rabbitmq-exporter) и запустить его, указав RABBITMQ_URL
   • Для Kafka: kafka_exporter (danielqsj/kafka-exporter)
   • Для NATS: nats-prometheus-exporter
   • Проверить, что на <exporter_ip>:9419/metrics отдаются метрики

3. Написать/сконфигурировать prometheus.yml:

   scrape_configs:
     - job_name: 'rabbitmq'
       static_configs:
         - targets: ['localhost:9419']
     - job_name: 'custom_agent_metrics'
       static_configs:
         - targets: ['localhost:8000']
   

4. Запустить Prometheus:
   docker run -d --name prometheus -p 9090:9090 -v /path/to/prometheus.yml:/etc/prometheus/prometheus.yml prom/prometheus

5. Проверить в http://localhost:9090/targets — состояние UP для всех таргетов.

Ожидаемый результат этапа Prometheus собирает метрики брокера (и/или кастомного Python-экспортера).

Этап 2: Генерация тестового трафика и измерение базовых метрик (30–45 минут)

Действия

1. Создать Python-скрипт agent_traffic.py, который:

   • Подключается к брокеру (pika/Kafka-Python/nats-py)
   • Публикует сообщение каждые 0.1–1 секунду (random interval)
   • Измеряет время отправки (до подтверждения от брокера)
   • В случайном порядке симулирует ошибки (таймауты, отказ публикации), увеличивая счётчик error_total
   • Выставляет метрики через prometheus_client:

     from prometheus_client import Counter, Histogram, Gauge, start_http_server
     
     msg_counter = Counter('messages_total', 'Total messages sent', ['status'])
     msg_latency = Histogram('message_latency_seconds', 'Latency of message send', buckets=(0.001, 0.01, 0.05, 0.1, 0.5, 1.0))
     error_rate = Counter('message_errors_total', 'Total send errors')
     dlq_gauge = Gauge('dlq_size', 'Current DLQ size')
     

   • Периодически (раз в N сообщений) увеличивает DLQ_gauge на случайную величину (симуляция недоставленных)

2. Запустить скрипт (убедиться, что брокер доступен) и дать поработать 2–3 минуты.

3. Проверить в Prometheus Graph: rate(messages_total[1m]), message_latency_seconds_bucket, message_errors_total — данные есть.

Ожидаемый результат этапа Prometheus содержит временные ряды четырёх ключевых метрик.

Этап 3: Расчёт производных метрик (latency percentiles, error rate, msg/s) (20–30 минут)

Действия

1. Проверить, что Prometheus записывает latency гистограмму — из неё можно получить p50, p95, p99 с помощью PromQL:
   histogram_quantile(0.95, rate(message_latency_seconds_bucket[5m]))

2. Рассчитать error rate как отношение ошибок к общему числу:
   rate(message_errors_total[5m]) / rate(messages_total[5m]) * 100

3. Рассчитать msg/s:
   rate(messages_total[5m])

4. Записать эти PromQL-запросы — они понадобятся для панелей дашборда.

Ожидаемый результат этапа Заготовлены 4 PromQL-запроса для панелей дашборда.

Этап 4: Создание дашборда в Grafana (30–45 минут)

Действия

1. Запустить Grafana:
   docker run -d --name grafana -p 3000:3000 grafana/grafana

2. Добавить источник данных Prometheus:

   • URL: http://prometheus:9090 (если Docker сети — используйте имя контейнера или host.docker.internal)

3. Создать новый дашборд (ID: 188-monitoring-agents) с четырьмя панелями:

   Панель	Тип	PromQL-запрос	Единицы
   Messages per second	Time series	rate(messages_total{status="success"}[5m])	msg/s
   Message latency	Time series (с перцентилями)	histogram_quantile(0.95, rate(message_latency_seconds_bucket[5m]))	seconds
   Error rate	Time series	rate(message_errors_total[5m]) / rate(messages_total[5m]) * 100	%
   DLQ size	Gauge / Stat	dlq_size	сообщения

   • Для панели latency добавить несколько запросов: p50, p95, p99 (Overrides).
   • Настроить переключатели временного диапазона (last 1h, 6h, 24h).

4. Настроить alert (опционально): для error rate > 5% и DLQ > 1000.

5. Сохранить дашборд, экспортировать JSON в файл dashboard_188.json.

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

Этап 5: Документирование и проверка интеграции (15–20 минут)

Действия

1. Написать краткий README.md:

   • Как запустить эмулятор / брокер
   • Как подключиться к дашборду
   • Какие метрики отображаются
   • PromQL-запросы для каждой панели

2. Протестировать отказоустойчивость: временно остановить брокер — убедиться, что msg/s упал до нуля, error rate вырос, на DLQ прибавилось.

3. Зафиксировать скриншоты дашборда (две контрастные ситуации: нормальная работа + момент сбоя).

Ожидаемый результат этапа Комплект артефактов: дашборд (JSON), README, скриншоты.

5. Критерии приемки (Definition of Done)

• Дашборд Grafana отображает 4 панели: msg/s, latency (p95), error rate (%), DLQ size
• Все панели обновляются в режиме реального времени (интервал не более 15 секунд)
• Prometheus успешно собирает метрики из брокера/экспортера (targets UP)
• При симуляции сбоя (остановка публикации) метрики мгновенно отражают изменения
• Latency панель показывает минимум два перцентиля (p50 и p95)
• Error rate корректно вычисляется как отношение ошибок к общему числу сообщений
• DLQ size отображается в виде gauge (текущее значение)
• Дашборд имеет понятные названия, единицы измерения, легенду
• README описывает шаги запуска и PromQL запросы
• Все компоненты запускаются в Docker (или эквиваленте) одной командой docker-compose up

6. Ожидаемый результат

Основной артефакт

• Файл dashboard_188.json — экспорт дашборда Grafana

Дополнительные артефакты

• agent_traffic.py — симулятор трафика (если брокер не используется)
• prometheus.yml — конфиг Prometheus
• README.md с инструкцией
• Скриншоты дашборда в нормальном режиме и в момент сбоя

Содержимое дашборда

• Название: «Monitoring inter-agent communication»
• Переменные: нет (или выбрать временной диапазон)
• 4 панели: msg/s, latency (p50/p95/p99), error rate (%), DLQ size
• Alert-правила: error rate > 5%, DLQ > 1000 (опционально)

7. Возможные сложности и их решение

8. Бюджет времени (оценка)

Примечание: При первом выполнении (если нет опыта работы с Prometheus/Grafana/брокерами) время может увеличиться до 5–6 часов. Рекомендуется заложить резерв.

9. Связанные вопросы из базы знаний

10. Чек-лист самопроверки

• Я запустил брокер/симулятор и убедился, что метрики попадают в Prometheus
• Я написал все PromQL-запросы, которые планирую использовать в дашборде, и проверил их в Prometheus Graph
• В дашборде есть как минимум 4 панели, указанные в ТЗ
• Панель latency показывает не менее двух перцентилей (p50 и p95)
• Я добавил понятные заголовки и единицы измерения на каждую панель
• Я экспортировал дашборд в JSON-файл
• Я написал README с инструкцией по запуску стека
• Я сделал скриншоты дашборда в двух состояниях (норма и сбой)
• Я проверил, что при остановке эмиттера сообщений метрики адекватно падают до нуля
• Все файлы (docker-compose.yml, config, скрипты, дашборд) собраны в одной папке и готовы к передаче