Настройка сбора и проверка

Настройка конфигураций

В каждой конфигурации Smart Monitor Data Collector повторите блок между маркерами #@instance-block-begin и #@instance-block-end для каждого инстанса. Для pg_objects нужен отдельный блок для каждой наблюдаемой базы.

Замените токены подключения, включая:

• PG_CLUSTER, PG_HOST, PG_INSTANCE, PG_PORT и PG_DB
• PG_ENVIRONMENT и PG_MON_USER
• PG_CONN_PARAMS с sslmode=verify-full
• адреса Smart Monitor Data Storage и путь к корневому сертификату
• порты Patroni, PgBouncer и входа beats, если используются соответствующие уровни

После подстановки в рабочих строках не должно остаться токенов PG_*, ES_*, LST_* и условных маркеров генератора.

Добавьте пароль роли мониторинга в защищенное хранилище Smart Monitor Data Collector:

sudo -u logstash /app/logstash/bin/logstash-keystore \
  --path.settings /app/logstash/config add DB_PG_PWD

Проверьте конфигурации штатной командой проверки Smart Monitor Data Collector. Затем добавьте отдельный pipeline.id для каждого файла в pipelines.yml и согласуйте одно окно перезапуска службы. Перезапуск останавливает все конвейеры этого узла.

Для Tier 2 и Tier 3 настройте приложение Smart Beat filebeat_postgresql_logs. Оно читает jsonlog и передает данные в pg_logs; события pgaudit отделяются внутри конвейера.

Проверка потока данных

Проверьте появление документов во всех индексах, соответствующих выбранным уровням зрелости. Для базового профиля обязательны db_metrics, db_activity, db_replication, db_statements и db_meta.

Откройте DB Observability: Диагностика сбора и проверьте:

• каждый инстанс есть в таблице источников
• версия PostgreSQL отмечена как поддерживаемая
• роль сбора имеет pg_monitor и не является суперпользователем
• задержка сбора не превышает порог
• активные и неактивные сценарии соответствуют настройке источника

Проверка объектов модуля

Проверьте состояние объектов утилиты командами чтения:

export SM_PASSWORD='<пароль>'
./bin/make_rsm.py show --host <SMART_MONITOR_HOST>:5601
./bin/apply_incident_types.py show --host <SMART_MONITOR_HOST>:5601
./bin/make_sla_policies.py show --host <SMART_MONITOR_HOST>:5601
./bin/make_ai_presets.py show --host <SMART_MONITOR_HOST>:5601
./bin/make_lookups.py show --host <SMART_MONITOR_HOST>:5601
./bin/make_custom_icons.py show <SMART_MONITOR_HOST> <SSH_USER>

Убедитесь, что задания db_00_lookup_refresh и db_00_thresholds_seed выполнились без ошибок. В db_instances должны появиться инстансы, в db_thresholds — значения по умолчанию.

Откройте восемь дашбордов и проверьте переходы между ними. Затем проверьте активы кластеров, инстансов и расширений в Inventory, сервисы модели «DB Observability: Базы данных» в МАЯК и тип db_incident в Incident Manager.

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

Первые расчеты

Новый актив появляется по расписанию Inventory, модель здоровья пересчитывается отдельно, а метрики МАЯК рассчитываются по собственным расписаниям. Серое значение сразу после установки не означает ошибку.