Мониторинг работы сервиса и сбор логов
В зависимости от используемой в организации системы мониторинга, специалист должен выбрать способ отслеживания состояния процессов сервиса.
На странице описаны все процессы, которые необходимо поддерживать в рабочем состоянии для полноценной работы сервиса.
Процессы сервиса
Работу MoodRec обеспечивают следующие микропроцессы:
| Сервис | Назначение |
|---|---|
| vectors | Работа с векторным хранилищем и поиск |
| trans | Преобразование описаний товаров в векторные представления |
| tasks | Выполнение отложенных заданий |
| offers | Управление продуктами |
| gateway | Проксирование HTTP (JSON) → gRPC (Proto) |
| events | Обработка событий |
| catboss | Работа с рекомендациями |
| auth | Авторизация |
| audience | Управление аудиториями |
Проверка статуса всех сервисов:
moodrec status
Проверка статуса конкретного сервиса:
moodrec status vectors
moodrec status trans
moodrec status tasks
moodrec status offers
moodrec status gateway
moodrec status events
moodrec status catboss
moodrec status auth
moodrec status audience
Если сервис запущен корректно, вывод содержит active (running). Если сервис остановлен — inactive или failed.
Управление конкретным сервисом выполняется отдельно для каждого микропроцесса.
Запуск:
moodrec start vectors
Остановка:
moodrec stop vectors
Перезапуск:
moodrec restart vectors
Аналогично для остальных сервисов:
moodrec start <service>
moodrec stop <service>
moodrec restart <service>
где <service> — один из: vectors, trans, tasks, offers, gateway, events, catboss, auth, audience.
После выполнения операций рекомендуется проверить состояние:
moodrec status <service>
Рекомендуется использовать проверку на существование процесса по имени встроенными средствами системы мониторинга либо с помощью pidof.
В обязательном порядке по хосту (или виртуальной машине) должна собираться такая информация:
- потребление и количество свободного ОЗУ;
- потребление и количество свободного времени CPU;
- количество свободного места и информация по утилизации дисков (скорость, задержки, SMART);
- количество открытых файлов и соединений.
Базы данных и сервисы
| Сервис | IP адрес по умолчанию | Порт | Важность | Доступ | Уведомление |
|---|---|---|---|---|---|
| Интерфейс платформы MoodRec | 0.0.0.0 | 443 (HTTPS) | Чрезвычайная | Публичный или через VPN / allowlist | Недоступен веб-интерфейс |
| Публичный API (события, рекомендации, импорт) | 0.0.0.0 | 443 (HTTPS) | Чрезвычайная | Публичный или в сетевом периметре клиента | Недоступны API-методы |
| MongoDB | 127.0.0.1 | 27017 (TCP) | Чрезвычайная | Только из внутренней сети | Невозможно установить TCP-соединение |
| ClickHouse | 127.0.0.1 | 9000 (TCP) | Чрезвычайная | Только из внутренней сети | Невозможно установить TCP-соединение |
| Apache Kafka | 127.0.0.1 | 9092, 9093 (TCP) | Чрезвычайная | Только из внутренней сети | Невозможно установить TCP-соединение |
| KV Rocks | 127.0.0.1 | 6666 (TCP) | Чрезвычайная | Только из внутренней сети | Невозможно установить TCP-соединение |
| Сервис работы с продуктами | 127.0.0.1 | 1111 (TCP) | Высокая | Только из внутренней сети | Сервис недоступен по TCP |
| Сервис управления задачами | 127.0.0.1 | 2222 (TCP) | Высокая | Только из внутренней сети | Сервис недоступен по TCP |
| Сервис расчёта продуктовых представлений | 127.0.0.1 | 3333 (TCP) | Высокая | Только из внутренней сети | Сервис недоступен по TCP |
| Сервис обращений к векторному индексу | 127.0.0.1 | 4444 (TCP) | Высокая | Только из внутренней сети | Сервис недоступен по TCP |
| Сервис выдачи рекомендаций | 127.0.0.1 | 5555 (TCP) | Чрезвычайная | Только из внутренней сети | Сервис недоступен по TCP |
| Сервис аудиторий | 127.0.0.1 | 7777 (TCP) | Высокая | Только из внутренней сети | Сервис недоступен по TCP |
| Сервис работы с пользователями | 127.0.0.1 | 8888 (TCP) | Высокая | Только из внутренней сети | Сервис недоступен по TCP |
| Сервис обработки событий | 127.0.0.1 | 9999 (TCP) | Чрезвычайная | Только из внутренней сети | Сервис недоступен по TCP |
| SMTP / SMTPS (оповещения) | внешний SMTP-сервер | 25 или 465 | Средняя | Исходящее соединение к SMTP-провайдеру | Невозможно установить соединение с SMTP |
Дополнительно по каждому процессу
Можно собирать дополнительные данные: потребление памяти, количество открытых файлов и соединений, использование CPU и т.д. Пример — в разделе «Диагностика проблем», блок «Сбор информации для запроса в поддержку».
Процессорное время
CPU time: https://en.wikipedia.org/wiki/CPU_time
| Тип метрики | Описание | Важность | Уведомление |
|---|---|---|---|
| CPU system time | Использование CPU процессом в процентах (system) | Информация | - |
| CPU iowait time | Использование CPU процессом в процентах (iowait) | Высокая | > 15% * количество ядер CPU |
| CPU user time | Использование CPU процессом в процентах (user) | Информация | - |
| CPU utilization | Использование CPU процессом в процентах (total) | Высокая | > 50% * количество ядер CPU |
Память
RSS: https://en.wikipedia.org/wiki/Resident_set_size SWAP: https://en.wikipedia.org/wiki/Paging#Unix_and_Unix-like_systems
| Тип метрики | Описание | Важность | Уведомление |
|---|---|---|---|
| RSS (resident set size) | Память процесса (RSS) | Высокая | > 20% от общего количества памяти |
| SWAP | Использование SWAP | Высокая | > 5% от общего объема SWAP |
Сеть
Рекомендуется мониторить количество соединений по каждому состоянию: https://en.wikipedia.org/wiki/Transmission_Control_Protocol#Protocol_operation
| Тип метрики | Описание | Важность | Уведомление |
|---|---|---|---|
| CLOSE | Закрыт. Сокет не используется. | Информация | - |
| CLOSE_WAIT | Удаленная сторона отключилась; ожидание закрытия сокета. | Средняя | Количество соединений > 2500 |
| CLOSING | Сокет закрыт, затем удаленная сторона отключилась; ожидание подтверждения. | Информация | - |
| ESTABLISHED | Соединение установлено. | Средняя | Количество соединений > 5000 |
| FIN_WAIT1 | Сокет закрыт; отключение соединения. | Информация | - |
| FIN_WAIT2 | Сокет закрыт; ожидание отключения удаленной стороны. | Информация | - |
| LAST_ACK | Удаленная сторона отключилась, затем сокет закрыт; ожидание подтверждения. | Информация | - |
| LISTEN | Ожидает входящих соединений. | Информация | - |
| SYN_RECV | Идет начальная синхронизация соединения. | Информация | - |
| SYN_SENT | Активно пытается установить соединение. | Высокая | Количество соединений > 5000 |
| TIME_WAIT | Сокет закрыт, но ожидает пакеты в сети для обработки. | Высокая | Количество соединений > 5000 |
Сбор и хранение логов приложения
Сбор логов сервиса может быть организован разными способами, в зависимости от инфраструктуры. Ниже описана типовая схема, в которой используется связка systemd — journald — Filebeat — Logstash — OpenSearch.
Архитектура хранения и обработки
Логи приложения хранятся в OpenSearch — это основное хранилище для долгосрочного хранения и индексации.
Для поиска, анализа и построения дашбордов используется OpenSearch Dashboards.
Сбор логов с серверов, контейнеров или подов выполняется агентом Filebeat.
Обработка, парсинг, обогащение и нормализация логов выполняется в Logstash.
Типовая цепочка движения логов:
Приложение — journald — Filebeat — Logstash — OpenSearch — OpenSearch Dashboards
Все компоненты рекомендуется использовать в совместимых версиях (желательно в рамках одной ветки OpenSearch или OSS-совместимых релизов).
Итоговый результат может выглядеть так:
Логирование сервиса через systemd
Для каждого бинарного файла микросервиса скрипт-установщик создаёт unit-файл systemd. Пример:
[Unit]
Description=moodrec-offers
Wants=network-online.target
After=network-online.target
[Service]
Type=simple
ExecStart=/opt/moodrec/bin/offers
StandardOutput=journal
StandardError=journal
SyslogIdentifier=moodrec-offers
Restart=always
RestartSec=2
KillSignal=SIGTERM
KillMode=control-group
TimeoutStopSec=20
[Install]
WantedBy=multi-user.target
Сервис пишет логи в journald через stdout и stderr.
Чтение логов из journald через Filebeat
Filebeat может напрямую читать события из journald и отправлять их в Logstash.
Пример конфигурации:
filebeat.inputs:
- type: journald
id: moodrec-journald
seek: cursor
include_matches:
- "_SYSTEMD_UNIT=moodrec-offers.service"
processors:
- add_host_metadata: {}
- rename:
fields:
- from: "systemd.unit"
to: "service.name"
ignore_missing: true
fail_on_error: false
output.logstash:
hosts: ["logstash:5044"]
logging.level: info
logging.to_files: true
logging.files:
path: /var/log/filebeat
name: filebeat
keepfiles: 7
В этой схеме:
- Filebeat считывает записи из journald в реальном времени.
- Logstash принимает события, разбирает строки логов (
grok,dissectи другие фильтры), добавляет метаданные (application,environment,pod_nameи др.), нормализует формат и отправляет данные в OpenSearch. - OpenSearch индексирует события и хранит их.
- OpenSearch Dashboards используется для поиска и визуализации логов.