Руководство по мониторингу¶

Состав системы мониторинга¶

Система мониторинга продукта состоит из следующих компонентов:

Централизованный мониторинг¶

Система мониторинга функционирует в пределах своего региона и собирает метрики о работе региона, в котором она развёрнута. Иными словами, каждый регион содержит (при включении соответствующей опции) собственную полноценную систему мониторинга.

При наличии нескольких регионов может возникнуть потребность как в централизованном хранении метрик о работе нескольких регионов, так и в визуализации метрик нескольких регионов на одном дашборде. Для решения данной задачи предусмотрена система централизованного мониторинга. Данная система реализована на базе сервиса VictoriaMetrics, разворачиваемого отдельно от регионов с нагрузками (например, в отдельном регионе). Системы мониторинга каждого региона самостоятельно реплицируют собранные метрики в централизованную систему.

На данный момент реализована репликация всех метрик.

Состав системы централизованного мониторинга¶

Система централизованного мониторинга состоит из следующих компонент:

Сервис хранения метрик: VictoriaMetrics.

Сервис отображения метрик: Grafana.

Сервис уведомлений: Prometheus Alertmanager.

Установка¶

Для развёртывания системы централизованного мониторинга выполните следующие действия:

Создайте отдельный пустой регион.
В конфигурационный файл региона (по умолчанию /globals.d/REGION.yml) добавьте переменную enable_victoriametrics со значением yes, переменную enable_prometheus_server со значением no и переменную enable_grafana со значением yes. Пример конфигурации региона централизованного мониторинга с отключёнными сервисами OpenStack:
enable_openstack_core: "no" enable_memcached: "no" enable_fluentd: "no" enable_rabbitmq: "no" enable_cinder: "no" enable_barbican: "no" enable_keystone: "no" enable_prometheus_server: "no" enable_mariadb: "yes" enable_grafana: "yes" enable_victoriametrics: "yes"
Запустите пайплайн с тегами prometheus, victoriametrics, grafana. При необходимости можно отключить неиспользуемые сервисы OpenStack.
После завершения пайплайна должны быть развёрнуты и предварительно настроены VictoriaMetrics, набор экспортёров, Alertmanager, Grafana.

Примечание

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

Включение репликации метрик в систему централизованного мониторинга¶

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

В конфигурационный файл конкретного региона (по умолчанию /globals.d/region.yml) добавьте переменную enable_central_monitoring со значением yes, а также переменную central_monitoring_url, в значении которой укажите URL компонента vminsert централизованного мониторинга.
Пример конфигурации:
enable_central_monitoring: yes central_monitoring_url: "https://<central-monitoring-region-fqdn>:8480/insert/0/prometheus"
Если подключение к централизованному мониторингу требует авторизации, то дополнительно укажите имя пользователя в переменной central_monitoring_basic_auth_user. Пароль для учётной записи введите в Vault в качестве значения ключа central_monitoring_basic_auth_password в файле passwords_yml.
После этого запустите пайплайн с тегом prometheus или victoriametrics, в зависимости от того, какой компонент используется в качестве сервиса сбора и хранения метрик данного региона.

История и статистика алертов¶

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

Для включения функционала по сохранению алертов выполните следующие действия:

В конфигурационный файл региона /globals.d/REGION.yml добавьте переменную enable_alerts_state_history со значением yes.
Запустите пайплайн с тегами opensearch, vector, grafana, prometheus, victoriametrics.

В качестве базы данных хранения истории алертов используется OpenSearch. Подробнее описано в разделе OpenSearch — Логирование и поиск.

Передача алертов со статусами firing и resolving реализована через webhook, который принимает алерты от Alertmanager и пересылает их в OpenSearch.

Передача алертов со статусами active и inhibited реализована через веб-сервис, который периодически обращается к API Alertmanager, получает список алертов и пересылает их в OpenSearch.

Передача заглушек алертов реализована через веб-сервис, который периодически обращается к API Alertmanager, получает список заглушек и пересылает их в OpenSearch.

Хранение алертов и заглушек реализовано в разных индексах, поскольку набор полей для них существенно различается:

Для хранения алертов используется индекс alerts.alertmanager-%Y.%m.%d.

Для хранения заглушек используется индекс silences.alertmanager-%Y.%m.%d.

Примечание

Передача алертов со статусом pending на данный момент не реализована.

Реализация webhook и веб-сервисов выполнена с помощью сервиса Vector.

Контейнеры с vector размещаются на Control-узлах и работают независимо друг от друга.

Для передачи алертов из Alertmanager в Vector выполните следующие действия:

В конфигурацию Alertmanager конкретного региона (конфигурационный файл /config/prometheus/prometheus-alertmanager.yml) добавьте дополнительный приёмник алертов и соответствующий маршрут. Пример конфигурации:

global:
  resolve_timeout: 5m
route:
  receiver: 'vector'
  routes:
  - receiver: 'vector'
    repeat_interval: 8737h
    match_re:
      alertname: ".*"
    continue: true

receivers:
  - name: 'vector'
    webhook_configs:
    - send_resolved: true
      url: "http://{{ api_interface_address }}:8841/alerts_state_history"

Для применения изменений запустите пайплайн с тегом prometheus.

В качестве уникального идентификатора алерта в OpenSearch используется md5 хэш сумма от перечня меток алерта, времени его создания и статуса алерта. В этом случае OpenSearch перезаписывает ранее полученный алерт с тем же идентификатором, тем самым обеспечивая дедупликацию алертов.

В качестве timestamp для алертов со статусом firing используется значение поля startsAt, а для алертов со статусом resolving используется значение поля endsAt.

Визуализация аналитики по алертам реализована средствами OpenSearch dashboards.

Аналитика по алертам OpenSearch¶

Аналитика по заглушкам OpenSearch¶

Визуализация также может быть реализована с помощью Grafana. Для этого необходимо создать data source с типом OpenSearch.

Аналитика по алертам Grafana¶

Аналитика по заглушкам Grafana¶

Алерты на события в журналах, собираемых fluentd¶

Мониторинг определённых событий/ошибок, зафиксированных в журналах (лог-файлах) реализован с помощью сервиса fluentd. Сервис fluentd обеспечивает сбор и предварительную обработку журналов (лог-файлов) и последующую их отправку для длительного хранения и аналитики в сервис OpenSearch. Также сервис fluentd позволяет создавать метрики о своей работе в формате Prometheus.

Список служб подсистем и соответствующие им лог-файлы представлены в разделе:

Файлы журналов компонентов платформы

Копия событий, обработанных средствами fluentd, перед тем как направиться в сервис OpenSearch, с помощью плагина relabel направляется в отдельную очередь обработки. В этой очереди с помощью плагина rewrite_tag_filter происходит сравнение записи в журнале с заданными регулярными выражениями. По результатам сравнения событию присваивается определённый тег. Далее, в соответствии с присвоенным тегом, с помощью плагинов parser и prometheus, происходит увеличение значения метрики, связанной с конкретным событием.

Для включения механизма направления копии событий в отдельную очередь выполните следующие действия:

Скопируйте шаблон /fluentd/output/03-opensearch.conf.j2 с тем же именем, но без расширения .j2 в конфигурацию региона в /config/fluentd/output/03-opensearch.conf
Добавьте дополнительное место хранения с помощью следующей секции:
<store> @type relabel @label @prometheus </store>

Добавьте в конфигурацию региона файл с описанием маршрутизации в /config/fluentd/output, например /config/fluentd/output/04-prometheus.conf.

Ниже приведён пример конфигурации, когда создаётся:

метрика с типом Counter и названием fluentd_input_amqp_errors_records_total при появлении в журналах записей вида AMQP server on <ip_address>:<port> is unreachable,

метрика с типом Counter и названием fluentd_input_VM_unexpected_shutdown_records_total при появлении в журналах записей вида During _sync_instance_power_state the DB power_state (1) does not match the vm_power_state from the hypervisor (4). Updating power_state in the DB to match the hypervisor.

<label @prometheus>
  <filter prometheus.event.AMQP_is_unreachable>
    @type parser
    key_name Payload
    reserve_data true
    <parse>
      @type regexp
      expression /^\[.+?\].+(AMQP server on)\s(?<amqp_server>(?:[0-9]{1,3}\.){3}[0-9]{1,3}):\d+\s(is unreachable):.*$/
    </parse>
  </filter>
  <filter prometheus.event.AMQP_is_unreachable>
  @type prometheus
  <metric>
    name fluentd_input_amqp_errors_records_total
    type counter
    desc The total number of incoming records
    <labels>
    amqp_server ${amqp_server}
    error_desc AMQP is unreachable
    hostname ${hostname}
    programname ${programname}
    </labels>
  </metric>
  </filter>

  <filter prometheus.event.VM_unexpected_shutdown>
    @type parser
    key_name Payload
    reserve_data true
    <parse>
      @type regexp
      expression /^\[instance:\s(?<instance_id>.+?)\]\s(During _sync_instance_power_state the DB power_state \(1\) does not match the vm_power_state from the hypervisor \(4\). Updating power_state in the DB to match the hypervisor.)$/
    </parse>
  </filter>
  <filter prometheus.event.VM_unexpected_shutdown>
    @type prometheus
    <metric>
      name fluentd_input_VM_unexpected_shutdown_records_total
      type counter
      desc The total number of incoming records
      <labels>
        error_desc VM unexpected shutdown
        hostname ${hostname}
        programname ${programname}
        instance_id ${instance_id}
      </labels>
    </metric>
  </filter>

  <match **>
    @type rewrite_tag_filter
    <rule>
      key Payload
      pattern /^\[(.+?)\].+(AMQP server on)\s((?:[0-9]{1,3}\.){3}[0-9]{1,3}):(\d+)\s(is unreachable):(.*)$/
      tag prometheus.event.AMQP_is_unreachable
    </rule>
    <rule>
      key Payload
      pattern /^\[instance:\s(.+?)\]\s(During _sync_instance_power_state the DB power_state \(1\) does not match the vm_power_state from the hypervisor \(4\). Updating power_state in the DB to match the hypervisor.)$/
      tag prometheus.event.VM_unexpected_shutdown
    </rule>
  </match>
</label>

Запустите пайплайн с тегом common.

Уведомления об алертах на Портале администратора¶

На Портале администратора предусмотрено отображение активных уведомлений из Alertmanager уровня warning и critical.

Для просмотра списка уведомлений, выполните следующие действия:

В верхней панели Портала администратора нажмите на кнопку Alerts. На кнопке отображается количество непрочитанных уведомлений.

Кнопка Alerts в верхней панели Портала администратора¶
В открывшемся окне Alerts отобразится список активных уведомлений из Alertmanager уровня warning и critical.

Список уведомлений из Alertmanager на Портале администратора¶
Для просмотра более детальной информации об уведомлении нажмите на строку уведомления. В открывшемся окне отобразится краткое описание, даты, статус и прочая информация об уведомлении.

Детальная информация об уведомлении из Alertmanager на Портале администратора¶
После закрытия окна Alerts со списком уведомлений, все прочитанные уведомления будут скрыты из списка.

Мониторинг наличия blackholing¶

Для отслеживания состояния blackholing, когда на инфраструктуре происходит потеря пакетов между узлами платформы KeyStack, реализовано наблюдение за метриками сервиса Consul и наблюдение за доступностью эндпоинта сервиса nova-api на управляющих узлах со стороны остальных узлов платформы.

В случаях нарушения сетевой связности между узлами кластера Consul (располагающихся на управляющих узлах), сервис Consul переводит недоступный узел в состояние unhealthy, а соответствующий ему сервис переводит в состояние warning. При этом формируются алерты ConsulHealthNodeStatus и ConsulHealthServiceStatus.

В случаях нарушения сетевой связности от вычислительных узлов к управляющим узлам или между управляющими узлами становится невозможным подключение к эндпоинту сервиса nova-api, который располагается на управляющих узлах. В этом случае формируется алерт BlackboxProbeHttpNovaApi. При этом на панели Certificate & Connection Monitoring дашборда KS - SSL Certificate Monitor можно видеть результаты проверок подключения к nova-api.

Результаты проверок подключения к nova-api¶

Описанные выше алерты в первую очередь могут говорить о нарушении сетевой связности между отдельными узлами платформы. Как следствие нарушения нормального функционирования платформы могут формироваться и другие алерты, связанные с сервисами Nova, Neutron, Cinder, RabbitMQ, HAproxy.

Просмотр состояния сервисов мониторинга платформы¶

Просмотр состояния контейнеров OpenSearch (выполняется на управляющих узлах):

docker ps -f name=opensearch

Просмотр состояния контейнера Prometheus (выполняется на управляющих узлах):

docker ps -f name=prometheus

Просмотр состояния Grafana (выполняется на управляющих узлах):

docker ps -f name=grafana

Просмотр состояния fluentd (на любом сервере):

docker ps -f name=fluentd

Просмотр состояния VictoriaMetrics (выполняется на управляющих узлах):

docker ps -f name=victoriametrics