Grafana и мониторинг

Для наблюдения за системой выделена отдельная Grafana: grafana.geek.moscow, рядом с ней prometheus.geek.moscow с сырыми метриками и страницей алертов. Учётные записи для просмотра приведены на странице доступов. Панели публичного стенда лежат в папке geek.moscow.

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

Что можно наблюдать

Вопрос	Полезные показатели
Доступен ли API?	Доступность Gateway, ответы HTTP и частота ошибок
Почему запросы замедлились?	Задержки обработки, event loop, ошибки внутренних вызовов
Хватает ли ресурсов?	CPU, память, перезапуски контейнеров и состояние узлов
Работает ли чат?	Соединения WebSocket, разрывы и ошибки
Успевает ли фоновая обработка?	Возраст outbox, очереди, повторы и DLQ, когда соответствующие метрики подключены
Что изменилось после выпуска?	Графики ошибок, задержек и ресурсов до и после развёртывания

Откуда приходят данные

Сервисы экспортируют метрики через prom-client, Prometheus собирает их, Grafana отображает в панелях. Для внутреннего стенда в документации зафиксированы отдельные задания сбора метрик публичного и административного Gateway: CPU, память, event loop, HTTP, WebSocket, gRPC и аутентификация. Описаны правила недоступности, роста 5xx и отказа хранилища лимитов.

Для публичного geek.moscow на производственном узле работает собственный Prometheus с экспортёрами: метрики приложений (Gateway, сервисы, воркеры), PostgreSQL, Redis, RabbitMQ, Kubernetes, хост, внешние HTTP-проверки всех публичных адресов и сроки TLS-сертификатов. Grafana по адресу grafana.geek.moscow читает этот Prometheus и содержит папку «geek.moscow» с десятью панелями: обзор, публичный и административный Gateway, сервисы, аутентификация, административные операции EXT-07, хранилища данных, Kubernetes, хост и внешний контур (проверки, TLS, DNS).

Бизнес-метрики и ресурсные метрики

В мониторинге можно сопоставить пользовательский результат с состоянием системы. Счётчики Identity показывают регистрации, входы, подтверждения email и отправку служебных писем по результату операции. Метрики Backoffice и EXT-07 показывают исходы административных действий, ожидание исполнения и ошибки сверки. HTTP/gRPC и WebSocket дополняют их задержками, отказами и состоянием соединений.

Рядом собираются CPU, память, event loop, GC, перезапуски контейнеров, диски и сеть узла, подключения к базам и очереди брокера. Например, рост времени ожидания служебных писем можно сопоставить с состоянием worker и RabbitMQ; увеличение p95 API — с нагрузкой сервиса, event loop и PostgreSQL. Пустой счётчик ещё не произошедшего события не равен ошибке сбора.

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

От графика к JSON-логам

Если график показывает отклонение, прикладные JSON-логи Pino помогают разобрать отдельные обращения: маршрут, код ответа, длительность и идентификатор запроса, а также ошибки вызовов сервисов и обработки очередей. Это дополняет агрегированные показатели Grafana деталями конкретного случая.

Следующий шаг для централизованного поиска — сбор контейнерных JSON-логов в Elasticsearch и просмотр через Kibana. Схема подключения и необходимые настройки описаны в разделе о логировании. В текущем комплекте инфраструктуры такая доставка не зафиксирована.

Как использовать

Выбрать окружение, панель и интервал времени; проверить источник данных.
Оценить доступность, ошибки, задержки и ресурсы.
Сопоставить начало отклонения со временем выпуска или изменения настроек.
Уточнить причину по журналам и состоянию сервисов, затем проверить результат исправления.

Для знакомства с поставкой используйте GitLab и CI/CD. Успешный pipeline не заменяет наблюдение за приложением после запуска.

Зафиксированное состояние

Источник данных, папка «geek.moscow» и десять панелей настроены 10 октября 2026 года и проверены по живым данным. Все ссылки ниже ведут сразу на соответствующую панель; для просмотра потребуется вход в Grafana из раздела доступов. Общая папка доступна по ссылке geek.moscow в Grafana.

Панель и прямая ссылка	За что отвечает и что смотреть
Overview	Главная оперативная сводка: доступны ли публичные адреса и оба Gateway, есть ли активные алерты, не растут ли 5xx, задержки, перезапуски подов, нагрузка CPU/памяти/диска, подключения PostgreSQL, готовые и dead-letter сообщения RabbitMQ. Это первая панель для оценки состояния стенда и перехода к деталям.
API Gateway	Публичный `api.geek.moscow`: доступность и перезапуски Gateway, запросы и ответы по статусам и маршрутам, p95/p99 задержек, доля 5xx, ошибки upstream gRPC, rate limit, ошибки auth-маршрутов, CPU/память Node.js, event loop, GC и открытые WebSocket чаты. Используется для поиска проблем на внешнем API и в чат-соединениях.
Admin Gateway	Административный `admin.geek.moscow`: те же HTTP-, gRPC-, latency-, runtime- и rate-limit-метрики, но для операторского контура; дополнительно видны замены ADMIN-сессий и ошибки `ValidateSession` (D-12). Нужна для проверки, что админские операции не ломаются отдельно от пользовательского API.
Auth	Аутентификация Identity и Gateway: успешные и неуспешные входы, регистрации и подтверждения, обновления сессий, повторное использование refresh-токена, rate limiting, сбросы паролей, служебные письма, Argon2id и зависшие подтверждения старше TTL. Помогает отличить проблему UI/Gateway от сбоя Identity или почтового потока.
Backend services	Девять NestJS-сервисов и два worker-процесса: доступность `/metrics`, gRPC-вызовы и non-OK-коды, p95 по сервисам и методам, HTTP-ответы, CPU/RSS/heap, event loop, GC, файловые дескрипторы и перезапуски. Фильтр `component` позволяет рассматривать один сервис; workers без HTTP-порта видны через cAdvisor и панели перезапусков.
PostgreSQL, Redis, RabbitMQ	Состояние хранилищ и брокера: PostgreSQL — подключения к лимиту, транзакции, cache hit ratio, deadlocks, долгие транзакции, размеры БД, блокировки и I/O; Redis — память, клиенты, команды, hit ratio, ключи, eviction и rejected connections; RabbitMQ — ready/unacked/dead-letter очереди, consumers, rates, connections/channels и resource alarm. Это основная панель для проблем с данными и фоновой обработкой.
Kubernetes (np1)	Состояние k3s-узла и workload'ов: Ready, поды и deployments, неготовые контейнеры, рестарты, OOMKilled, failed jobs, requests/limits, CPU и память по pod, сетевой трафик, filesystem I/O, PVC и kubelet/PLEG. Переменная `namespace` ограничивает просмотр нужным контуром (`geek-api`, `geek`, `geek-admin`, `fsp-mock`, `geek-monitoring` и другими).
Host nubble-prod-01	Ресурсы самого production-узла: CPU и load average, память и swap, свободное место и inode, throughput/IOPS/latency дисков, сеть, пакеты и ошибки, TCP/conntrack, retransmits/resets, file descriptors и процессы. Нужна, когда проблема шире одного pod или namespace.
Edge: probes, TLS, DNS, ingress	Внешний взгляд на платформу: blackbox HTTP-проверки всех публичных хостов, round-trip и фазы HTTP, DNS lookup, дни до окончания TLS-сертификатов по probe и cert-manager, готовность сертификатов, CPU/RSS ingress-nginx, ошибки ACME, запросы и коды ответов CoreDNS. Метрики request rate самого ingress-nginx пока не включены, поэтому нагрузку по хостам следует смотреть на панелях Gateway.
EXT-07 admin operations	Контур административных изменений аккаунтов и компаний по документу 30: DIRECT-операции и их результаты, pending/oldest, reconciliation и ошибки владельцев, deletion blockers, lifecycle transitions, permits/intents, очереди и DLQ, ValidateSession, integrity checks документов 29, `ACCOUNT_TYPE_MISMATCH`, WebSocket closes и latency Admin Gateway. Идентификаторы и email в labels намеренно не выводятся.

Prometheus отдаёт сырые ряды и страницу алертов по HTTP basic auth. Правила оповещений (Gateway, аутентификация, EXT-07, платформа: проверки доступности, TLS, хост, Kubernetes, хранилища) вычисляются в Prometheus и видны в Grafana → Alerting.

В документальном срезе внутреннего мониторинга нет Alertmanager и централизованного хранилища логов. Более широкое покрытие сервисов и доставка уведомлений ответственным требуют отдельной настройки. См. статус проекта и инфраструктуру.

GitLab и непрерывный CI/CD · Все разделы · Почта и подтверждение адреса