Конфигурация

Ссылка на публичный репозиторий: https://git.angara.cloud/gbgreenplum/greenplum.monitoring

Настройка алертов (Prometheus/Alertmanager)

Создание правил (алертов) в Prometheus

Правила для оповещений конфигурируются в виде YAML-файлов.
Путь до файлов с правилами указывается в конфигурационном файле prometheus.yml (например /etc/prometheus/prometheus.yml) в блоке rule_files:

Информация о текущих алертах и их параметрах отображается в WebUI Prometheus (host_ip:9090) во вкладке Alerts.
Prometheus генерирует алерты на основе правил и передает их в Alertmanager, который отправляет оповещения пользователям.

Пример конфигурационного файла prometheus.yml

groups:
  - name: node_exporter
    rules:
      - alert: HighCPUUtilization
        expr: (avg by(instance) (rate(node_cpu_seconds_total{job="node",mde="idle"}[1m]))) < 0.25
        for: 30m
        labels:
          severity: warning
        annotations:
          summary: "Высокая утилизация CPU на {{ $labels.instance }}"
          description: "Утилизация CPU на инстансе {{ $labels.instance }} выше 75% в течение 30 минут"

      - alert: DiskSpaceUtilization
        expr: (100 * (node_filesystem_size_bytes{fstype=~"ext4|xfs", mountpoint=~".*"} - node_filesystem_free_bytes{fstype=~"ext4|xfs", mountpoint=~".*"}) / node_filesystem_size_bytes{fstype=~"ext4|xfs", mountpoint=~".*"}) > 80
        for: 10m
        labels:
          severity: warning
        annotations:
          summary: "Файловая система {{ $labels.mountpoint }} почти полная на хосте {{ $labels.instance }}"
          description: "Файловая система {{ $labels.mountpoint }} использует место более 80%"

 - name: sql_exporter
    rules:
      - alert: LargeNumberConnections
        expr: gp_sess_info{cluster_conn="all_sess"} > 650
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Большое количество соединений к базе на мастер-инстансе {{ $labels.instance }}"
          description: "Количество соединений Greenplum на мастере {{ $labels.instance }} больше 650"

Алерты указываются в группах с указанным именем name. В одной группе может быть указано несколько алертов (alert).
Каждый алерт состоит из следующих полей:

Название поля	Назначение
alert	Имя алерта
expr	Выражение при true которого активируется alert
for	Время в течение которого выражение expr должно быть активно для активации алерта. В это время статус алерта будет иметь статус pending, а при большем времени статус firing
labels	Набор дополнительных значений, которые будут прикреплены к оповещению
annotations	Набор информационных меток для хранения более длинной информации

В полях labels и annotations можно использовать шаблоны на основе выражения из expr, например {{ $labels.<keyname> }} или {{ $value }}.

Добавление/изменение алертов

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

• Открыть существующий или создать новый файл правил в формате YAML.

• Создать в нем необходимые алерты (при необходимости создать новую группу) согласно шаблону:

Шаблон правила

rules:
  - alert: AlertName
    expr: metrics{filterkey="filtervalue"} > 0.5
    for: 
    labels:
      severity: 
    annotations:
      summary: 

• Сохранить файл правил и убедиться, что путь до файла указан в конфигурационном файле prometheus.yml.

• Проверить корректность файла правил:

Проверка ошибок в конфигурационном файле

promtool check rules path/to/file/rule-file.yml

• Перезапустить prometheus

sudo service prometheus restart
sudo service prometheus status

Конфигурация Alertmanager

Для подключения Alertmanager указать его адрес в конфигурационном файле prometheus.yml:

Файл конфигурации alertmanager.yml (по умолчанию /etc/alertmanager/alertmanager.yml) определяет правила запрета, маршрутизацию уведомлений и получателей уведомлений.

Структура конфигурационного файла

Файл конфигурации состоит из четырех основных секций:

• global — глобальные параметры (настройки email, API и других сервисов-получателей)
• route — конфигурация маршрутов
• receivers — сервисы-получатели для отправки оповещений
• inhibit_rules — правила игнорирования оповещений в зависимости от существующих алертов

Пример файла конфигурации alertmanager.yml

global: #глобальные параметры(smtp, api url, http config и т.д.)
  smtp_smarthost: 'smtp.gmail.com:587' #smarthost для отправки уведомлений
  smtp_from: 'your_mail@gmail.com' #email отправителя алерта
  smtp_require_tls: false #необходимость использования TLS
  smtp_hello: 'alertmanager' #значение hello для smtp протокола
  smtp_auth_username: 'your_mail@gmail.com' # логин для адреса smtp_from
  smtp_auth_password: 'your_password' # пароль для адреса smtp_from

route:  #конфигурация маршрутов
  receiver: 'email' #первичный получатель
  group_by: ['alertname'] #поля группировки правил
  group_wait: 10s #время ожидания правил для группировки
  group_interval: 10s #время до повторной отправки сообщений из этой же группы
  repeat_interval: 60m #время через которое можно повторить отправку действующего алерта
  routes: #маршруты рассылки
  - receiver: 'email_warning' #первый получатель
    match: #условие выбора данного маршрута
      severity: warning #проверка условия: alert_metric(severity="warning")
    repeat_interval: 360m
    continue: false #проверять ли последующие маршруты, если условие выполняется
  - receiver: 'tg_critical' #второй получатель
    match: #условие выбора данного маршрута
      severity: critical #проверка условия: alert_metric(severity="critical")

receivers: #получатели
  - name: 'email' #имя получателя
    email_configs:
    - to: 'email1@gmail.ru' #список email для рассылки
      send_resolved: true # отправка сообщения об окончании алерта
  - name: 'email_warning' #имя получателя
    email_configs:
    - to: 'email1@gmail.ru,email2@gmail.ru'
      send_resolved: true # отправка сообщения об окончании алерта
  - name: 'tg_critical' #имя получателя
    telegram_configs:
    - chat_id: -11111111111
      bot_token: '8881827277:sajhkdau819273jkashdmz62-asdasda_TY'
      api_url: 'https://api.telegram.org'
      parse_mode: ''

inhibit_rules: #блок условий игнорирования отправки алертов в зависимости от отправленных алертов
  - source_match: #существующий алерт
      severity: 'critical'
    target_match: #новый алерт
      severity: 'warning'
    equal: ['alertname', 'dev', 'instance'] # совпадающие теги для игнорирования

Описание секций конфигурации

• Секция global содержит глобальные параметры, используемые Alertmanager. В примере указаны настройки SMTP для отправки оповещений на email. Если параметры конфигурации не заданы для отдельного источника в поле email_configs, используются параметры по умолчанию. Полный список глобальных параметров представлен в официальной документации.

• Секция route определяет маршруты отправки уведомлений. Указывается первичный получатель (email) и его параметры. Дополнительные получатели указываются в routes и обрабатываются в указанном порядке. При отсутствии конкретного значения параметра для получателя в блоке routes, наследуются значения параметров от первичного получателя. Выбор получателя зависит от условия в поле match — при выполнении условия выбирается соответствующий получатель. Если у получателя установлено continue=false, проверка последующих маршрутов не выполняется.
  Все алерты, поступающие в Alertmanager, могут группироваться для избежания множественных уведомлений об одинаковых событиях. Директива group_by определяет поля для группировки. После создания новой группы алертов активируется параметр group_wait, который указывает время ожидания перед отправкой первого сообщения. Это позволяет получить все алерты группы одним сообщением вместо отдельных уведомлений для каждого алерта.

• Секция receivers содержит сервисы-получатели и их конфигурации для отправки уведомлений. Поддерживаются различные сервисы (email, Telegram, WeChat и другие). Параметры конфигурации указываются индивидуально для каждого сервиса-получателя. Все доступные сервисы и параметры их конфигурации представлены в документации. В примере используются email-оповещения с частичным наследованием глобальных параметров и уведомления в Telegram с локальной конфигурацией.

• Секция inhibit_rules определяет условия игнорирования алертов в зависимости от существующих оповещений. В примере конфигурации игнорируются warning-алерты при наличии critical-алертов с одинаковыми полями alertname, dev, instance.

Изменение маршрутов уведомлений Alertmanager

Для изменения маршрутов уведомлений Alertmanager:

• Отредактировать конфигурационный файл alertmanager.yml (например, по пути /etc/alertmanager/alertmanager.yml) в соответствии с требованиями:

  • Настроить маршруты уведомлений (блок route) и их параметры
  • Указать получателей (блок receivers) и настроить конфигурацию для выбранного типа получателя
  • При необходимости настроить блок игнорирования inhibit_rules

• Выполнить проверку конфигурационного файла:

amtool check-config alertmanager.yml

В случае успешной проверки перезапустить Alertmanager и Prometheus:

sudo systemctl restart alertmanager
sudo systemctl restart prometheus
sudo systemctl status alertmanager
sudo systemctl status prometheus

Настройка Grafana

• Добавить Prometheus в качестве поставщика метрик:

  • Перейти в веб-интерфейс Grafana
  • В разделе Configuration выбрать пункт Data Source
  • Нажать на кнопку Add data source и выбрать Prometheus
  • Задать имя сервиса и URL
  • Нажать кнопку Save & Test

Настройка дашбородов Grafana

Ссылка на репозиторий с дашбордами: https://git.angara.cloud/gbgp/greenplum.monitoring/grafana/-/tree/main/dashboards/master?ref_type=heads.monitoring

Общие заметки

Основные настройки для запуска дашбордов - задание переменных дашборда:

• IP адреса хостов ($master, $segments)
• Cсылка на Prometheus ($DS_PROMETHEUS)

Пример настройки переменной хоста

#Пример метрики для получения ip адресов кластера. Вводится в поле metric для переменной
up{instance=~".*(45|.*):9100", job="node"}

#Регулярка для получения ip адреса без порта. Вводится в поле regex переменной
/(\d{1,3}.\d{1,3}.\d{1,3}.\d{1,3})/

Пример использования переменных хоста в метрике

node_disk_io_time_seconds_total{device="sda",instance=~"($master|$segments):9100"}

Для задания фильтров по метрикам можно использовать ключи метрик, которые указываются в {}.

• на основе конкретно заданного значения, например up{job="pxf_exporter"}
• на основе регулярного выражения. В таком случае необходимо использовать тильду перед выражением с регулярным выражением, например up{job=~".*_exporter"} (выбор всех job заканчивающихся на _exporter)

Примеры

#Фильтрация по IP хоста
instance=~".*(ip1|ip2|ip3):.*"
instance=~".*(45|47|19):.*" --ip оканчивающиеся на 45,47,19 с любым портом
instance=~".*(45|47|19):5888" --ip оканчивающиеся на 45,47,19 с любым портом и 5888 портом

#Фильтрация по job
up{job="pxf_exporter"}

#Фильтрация по порту
up{instance=~".*:5888"}

Дашборд Greenplum Cluster

• В настройках дашборда указать маски для переменных master, segments. После этого должны появиться значения на всех панелях.
• Для панелей "I/O Utilization by disk", "I/O Utilization by disk history" по необходимости указать нужный device (sda/vda). По умолчанию sda/sdb

Пример

100 * rate(node_disk_io_time_seconds_total{device="sda",instance=~"($master|$segments):9100"}[1m])

Дашборд Maintance

• На панелях MTU bond0, MTU ensf0 указать требуемые интерфейсы

Пример указания интерфейса

node_network_mtu_bytes{device="bond0"}

Дашборд MetricDB stats

• В настройках указать адреса хостов переменных: mst, seg1 - seg6 c помощью маски или жестко задать значения

Пример

up{instance=~".*45:9100", job="node"}
up{instance=~"10.129.0.45:9100", job="node"}

Дашборд PXF

• В настройках поменять маску для переменных: master_instance, segment_instance:

Пример

up{instance=~".*(45|46|47):9100", job="node"}

Дашборд Resource Group

• В настройках поменять маску для переменной instance на адрес мастера:

Пример

up{instance=~".*(45|46|47):9100", job="node"}

Ошибка дашборд ${DS_PROMETHEUS} was not found

При возникновении ошибки ${DS_PROMETHEUS} was not found выполнить следующие действия:

1. Проверить наличие переменной DS_PROMETHEUS в настройках дашборда
2. При необходимости создать ее с datasource и выбрать prometheus

sql_exporter - настройка коллекторов

Ссылка на типовые конфигурации коллекторов для sql_exporter: https://git.angara.cloud/gbgp/greenplum.monitoring/sql_exporter

Ссылка на документацию по sql_exporter: https://github.com/burningalchemist/sql_exporter/tree/master

Инструкция по созданию/редактированию коллектора

• Создать новый или открыть существующий файл в директории sql_exporter (по умолчанию /opt/sql_exporter) с названием .collector.yml.

• В файле .collector.yml по приведенному шаблону заполнить необходимые метрики и запросы. При заполнении полей метрик и запросов сохранять отступы (key_labels, query).

Шаблон коллектора

collector_name: 

min_interval: 10s

metrics: # metric with 1 column and 1 rows
  - metric_name: 
    type: gauge
    help: ''
    values: []
    query: |
       # metric with >1 column and >1 rows
  - metric_name: 
    type: gauge
    help: ''
    value_label: ''
    key_labels:
      - 
      - 
    values: [, , ]
    query_ref: 

queries:
  - query_name: 
    query: |
      

• При добавлении нового коллектора - прописать в sql_exporter.yml имя нового коллектора для выбранного таргета

Пример редактирования sql_exporter.yml

target:
# Data source name always has a URI schema that matches the driver name. In some cases (e.g. MySQL)
# the schema gets dropped or replaced to match the driver expected DSN format.
data_source_name: 'postgres://gpmon:gpmon@localhost:5432/gpdb?sslmode=disable&application_name=sql_exporter'
# Collectors (referenced by name) to execute on the target.
collectors: [gp_collector,gp_collector_slow,alert_collector,gp_collector_terminate,]
# Collector files specifies a list of globs. One collector definition is read from each matching file.
collector_files:
- "*.collector.yml"

• Перезапустить сервис sql_exporter и проверить статус

Перезапуск sql_exporter

sudo systemctl stop sql_exporter
sudo systemctl start sql_exporter
sudo systemctl status sql_exporter

Конфигурация sql_exporter

sql_exporter - инструмент для экспорта метрик из БД в Prometheus на основе SQL-запросов.

Конфигурация sql_exporter заключается в настройке коллекторов и таргетов, на которых эти коллекторы будут работать.

• Коллектор - yml-файл с описанием того какие метрики будут запрашиваться на таргетах и как они будут получены.
• Таргет - экземпляр БД
  На высоком уровне конфигурация может быть представлена в виде:

Настройка коллекторов

Коллекторы определяют, какие операторы должны быть выполнены и как анализировать результаты, т.е. какие метрики мы можем получить из результатов.

Они определяются в отдельных файлах или в общем файле конфигурации (sql_exporter.yml) и имеют уникальное имя, которое впоследствии используется при указании того, какие коллекторы следует использовать с какими целями.

Текст конфигурации коллектора состоит из нескольких блоков:

Блок параметров коллектора - служит для задания параметров коллектора:

• collector_name - имя коллектора, которое используется в дальнейшем при указании того, какие метрики следует получить из каких таргетов;
• min_interval - минимальный интервала для запуска данного коллектора.

Блок метрик (metrics) - содержит информацию о собираемых метриках. Каждая метрика конфигурируется набором полей:

• metric_name - отображаемое имя метрики в Prometheus;
• type - тип метрики, передаваемой в Prometheus. Поддерживаются только датчики(gauge) и счетчики(counter);
• help - описание метрики. Необязательное поле;
• key_labels - список названий столбцов или значения, которые будут выводится в метке метрики. Например, если в результате запроса получено несколько строк. Необязательное поле;
• values - название столбцов, используемых как значение метрики. Если столбцов больше чем 1, то необходимо заполнить поле value_label, т.к. каждый столбец будет представлен в виде отдельной метрики;
• value_label - названия метки метрики, которое будет иметь имя выбираемых столбцов (указывается, если поле values имеет несколько значений);
• query - текст запроса для получения значений;
• query_ref - имя запроса из блока queries, который будет использован для расчета метрики.

Блок запросов (queries) - содержит информацию о запросах используемых в метриках. Каждый запрос задается полями:

• query_name - имя запроса, используемое для обращения к нему из метрики (поле query_ref);
• query - текст запроса для получения значений.

Пример содержания коллектора

collector_name: test_collector

min_interval: 10s

metrics:
  - metric_name: test_counts
    type: gauge
    help: 'count rows from test.exporter_test'
    values: [rows_count]
    query: |
      select count(*) as rows_count from test.exporter_test

  - metric_name: test_agrigation_info
    type: gauge
    help: 'agrigation from test.exporter_test'
    value_label: 'param'
    key_labels:
      - group_id
    values: [max_id, check_new]
    query_ref: agrg_info

queries:
  - query_name: agrg_info
    query: |
      select 1 as max_id,
        0 check_new,
        1 as group_id
      union all
      select 2 as max_id,
        1 check_new,
        2 as group_id

Примеры метрик полученных в Prometheus:

Конфигурация настроек sql_exporter (sql_exporter.yml)

Настройка взаимодействия коллекторов и тартегов задается в файле sql_exporter.yml.

Файл sql_exporter.yml состоит из 3 блоков:

Блок параметров - содержит информацию о глобальных параметрах работы sql_exporter:

• scrape_timeout - таймаут очистки метрики;
• scrape_timeout_offset - задержка таймаута очистки в мс;
• min_interval - минимальный интервала между запусками коллектора. По умолчанию коллекторы запускаются при каждом сборе данных.
• max_connections - максимальное количество подключений к таргету. Метрики могут получаться параллельно на нескольких подключениях.
• max_idle_connections - максимальное количество неактивных полдключений.

Блок таргетов - содержит информацию о таргете и используемых для него коллекторах:

• data_source_name - имя таргета для подключения (URI с учетом имени драйвера, например "postgres://gpmon:gpmon@localhost:5432/gpdb?sslmode=disable&application_name=sql_exporter")
• collectors - имена используемых коллекторов для данного таргета.

Блок файлов коллекторов - содержит информацию об используемых файлах-коллекторах (один файл - один коллектор).

Пример содержания sql_exporter.yml

---
# Global defaults.
global:
  # Subtracted from Prometheus' scrape_timeout to give us some headroom and prevent Prometheus from timing out first.
  scrape_timeout_offset: 500ms
  # Minimum interval between collector runs: by default (0s) collectors are executed on every scrape.
  min_interval: 30s
  # Maximum number of open connections to any one target. Metric queries will run concurrently on multiple connections,
  # as will concurrent scrapes.
  max_connections: 7
  # Maximum number of idle connections to any one target. Unless you use very long collection intervals, this should
  # always be the same as max_connections.
  max_idle_connections: 7

# The target to monitor and the collectors to execute on it.
target:
  # Data source name always has a URI schema that matches the driver name. In some cases (e.g. MySQL)
  # the schema gets dropped or replaced to match the driver expected DSN format.
  data_source_name: 'postgres://gpmon:gpmon@localhost:5432/gpdb?sslmode=disable&application_name=sql_exporter'

  # Collectors (referenced by name) to execute on the target.
  collectors: [gp_collector,gp_collector_slow,alert_collector,gp_collector_terminate,test_collector]

# Collector files specifies a list of globs. One collector definition is read from each matching file.
collector_files:
  - "*.collector.yml"
...