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

1. Многомерный мониторинг: рекомендации

Мониторинг работы можно рассматривать с разных сторон:

• Мониторинг процессов и портов. Разработчики могут писать собственные скрипты для мониторинга или настраивать предоставленный стартовый скрипт в crontab. Startup.sh проверяет наличие процесса через порт и автоматически запускает его, если процесс не существует. На практике модель процесса Небулы очень стабильна, и основная бизнес-логика находится в рабочем процессе. Если рабочий процесс зависает или становится недоступным, менеджер перезапускает его. Вспомогательные стартовые скрипты обеспечивают лишь дополнительную защиту, которая редко используется.
• Мониторинг Beacon. С помощью nebcli можно получить информацию о состоянии различных типов служб в кластере в режиме реального времени. Эта информация позволяет отслеживать состояние здоровья кластера. Если информации недостаточно, можно добавить плагины для получения дополнительных данных. Модуль администратора Beacon ModuleAdmin может помочь легко расширить мониторинг.
• Запуск NebulaLogger в кластере. Журналы в кластере будут отправляться на этот распределённый узел сбора журналов в соответствии с уровнем журнала и traceid. В узле NebulaLogger можно добавлять данные в базу данных или записывать файлы, а затем написать единый скрипт для сканирования журналов для мониторинга, например, количества ошибок, предупреждений и т. д.
• Использование Prometheus для сбора данных мониторинга и Grafana для визуализации.

2. Мониторинг процессов и портов

Стартовый скрипт Небулы startup.sh имеет функцию проверки порта и запуска процесса. Его можно настроить в crontab, и он автоматически запустит процесс, если он не существует.

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

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

• Режим потока: Manager, Worker и Loader — это разные потоки одного процесса. Worker и Loader создаются и отсоединяются от Manager при запуске.
• Режим процесса: Manager, Worker и Loader являются отдельными процессами. Worker и Loader запускаются менеджером и работают независимо. Основная бизнес-логика выполняется в рабочем процессе, и если рабочий процесс зависает или останавливается, менеджер перезапустит его.

3. Мониторинг Beacon

Узлы кластера Небулы отправляют информацию на сервер Beacon, который предоставляет HTTP-интерфейс для запроса этой информации. Вызов HTTP-интерфейса Beacon позволяет легко использовать эту информацию для создания отчётов и мониторинга. Запросы и ответы HTTP можно посмотреть в реализации ModuleAdmin Beacon.

Мы также предоставляем инструмент командной строки Python Nebcli, который можно использовать для удобного запроса информации об узлах. Nebcli также получает данные через HTTP-интерфейсы Beacon. Некоторые команды Nebcli:

show nodes                                      # Просмотр информации о доступных узлах
show nodes ${node_type}                         # Просмотр информации об узлах указанного типа
show node_report ${node_type}                   # Просмотр состояния работы узлов указанного типа (нагрузка, объём отправки и получения данных и т.д.)
show node_report ${node_type} ${node_identify}  # Просмотр состояния работы указанного узла
show node_detail ${node_type}                   # Просмотр подробной информации об узлах указанного типа (IP-адрес, количество рабочих процессов и т.д.)
show node_detail ${node_type} ${node_identify}  # Просмотр подробной информации о конкретном узле
show beacon                                     # Просмотр информации о сервере Beacon

4. Распределённый мониторинг журналов

Запустите NebulaLogger, и журналы в кластере будут автоматически отправляться на этот узел распределённого сбора журналов. В NebulaLogger вы можете добавить данные в базу данных или записать файлы, а затем создать единый сценарий сканирования журналов для мониторинга количества ошибок, предупреждений и других показателей. Отправка журналов на узел NebulaLogger происходит автоматически после запуска. Нет необходимости в дополнительных действиях. По умолчанию DEBUG и TRACE не отправляются, и их отправка не рекомендуется. Уровень журнала можно настроить в файле конфигурации службы net_log_level.

Пример конфигурации уровня журнала JSON:

"log_levels": { "FATAL": 0, "CRITICAL": 1, "ERROR": 2, "NOTICE": 3, "WARNING": 4, "INFO": 5, "DEBUG": 6, "TRACE": 7 },
"log_level": 7,
"net_log_level": 5

5. Prometheus и Grafana

В слое фреймворка Небулы есть статистика по количеству подключений, количеству отправленных и полученных пакетов и количеству отправленных и полученных байтов. Он также предоставляет HTTP-интерфейс для запросов. Любой сервис, основанный на Небуле, может получать данные после запуска. Это реализовано в actor/cmd/sys_cmd/ModuleMetrics.

Примеры показателей мониторинга слоя фреймворка:

$ curl http://10.16.47.53:16380/status

nebula{app="fps-user", key="connect"} 269
nebula{app="fps-user", key="send_byte"} 70497873
nebula{app="fps-user", key="recv_byte"} 69727450
nebula{app="fps-user", key="send_num"} 63798
nebula{app="fps-user", key="recv_num"} 63936
nebula{app="fps-user", key="client"} 239
nebula{app="fps-user", key="load"} 269

Примеры бизнес-показателей мониторинга:

$ curl http://10.16.47.53:16380/metrics

fps_server{app="fps-user", key="connect"} 269
fps_server{app="fps-user", key="send_byte"} 70497873
fps_server{app="fps-user", key="recv_byte"} 69727450
fps_server{app="fps-user", key="send_num"} 63798
fps_server{app="fps-user", key="recv_num"} 63936
fps_server{app="/fps-user", key="client"} 239
fps_latency{app="fps-user", key="HMGET", value_type="p999"} 9
fps_latency{app="fps-user", key="HMGET", value_type="p99"} 3
fps_latency{app="fps-user", key="HMGET", value_type="p95"} 1
fps_latency{app="fps-user", key="HMGET", value_type="p50"} 1
fps_server{app="fps-user", key="load"} 269
fps_req{app="fps-user", key="req", value_type="req_num"} 21478
fps_req{app="fps-user", key="req", value_type="success"} 21305
fps_req{app="fps-user", key="req", value_type="failed"} 0

Реализация этих показателей мониторинга осуществляется с помощью встроенной функции сбора данных Небулы. Описание данных PB находится в Nebula/proto/report.proto:

syntax = "proto3";
package neb;

message ReportRecord
{
    enum VALUE_TYPE
    {
        VALUE_ACC               = 0;
        VALUE_FIXED             = 1;
    }
    bytes key                   = 1;
    repeated uint64 value       = 2;
    string item                 = 3;
``` Воркер отправляет Report менеджеру (смотрите Worker::CheckParent()), менеджер Actor/Cmd/SysCmd/CmdDataReport получает данные и сохраняет их в Actor/Session/SysSession/SessionDataReport. ModuleMetrics генерирует метрики мониторинга на основе данных из SessionDataReport.

SessionDataReport периодически отправляет Report на узел Beacon. Если Worker на узле Beacon загружает CmdDataReport (менеджер по умолчанию загружает SysCmd() с помощью LoadSysCmd(), Worker на узле Beacon должен быть настроен для загрузки в boot_load конфигурационного файла), то он может получить сводку показателей всех узлов кластера.