Настройка Asterisk и Prometheus для получения уведомлений об авариях на сервере

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

Сбор данных основан на извлечении и сборе метрик. Каждый полученный элемент заносится в хранилище Prometheus. Хранение метрик происходит в виде временных рядов. Каждый временной ряд идентифицируется именем метрики и парами ключ/значение, называемыми метками. Включает в себя сервер Prometheus и дополнительные инструменты.

Для интеграции с системой мониторинга Prometheus в Asterisk используется модуль, который позволяет отслеживать активные вызовы, активные каналы и обработку вызовов. Поддержка модуля res_prometheus началась с версии Asterisk 17. 

Целью данной статьи является рассмотрение и осуществление настройки Asterisk с Prometheus:

1. для мониторинга:

• статуса службы Asterisk;
• статуса службы MySQL;
• загрузки CPU и Memory;
• активных каналов PJSIP (внутренних номеров и транка).

2. для получения сообщений на почту и telegram при возникновении аварий на сервере. 

Используемое программное обеспечение:

• CentOS 7;
• Asterisk 20.0.0;
• MariaDB;
• Prometheus;
• Node Exporter –  содержит показатели оборудования и ядра.
• Alertmanager — менеджер уведомлений;
• NodeMySQL– содержит показатели БД.

Произведем установку Prometheus и требуемых компонентов с помощью статьи https://voxlink.ru/kb/linux/ustanovka-sistemy-monitoringa-prometheus/ .

Важно обратить внимание, чтобы на сервере с Asterisk была установлена служба httpd. В случае отсутствия службы httpd метрики доступны не будут. Пример установки можно взять из статьи: https://voxlink.ru/kb/linux/ustanovka-lamp-na-centos-7/ .

  Ниже на скриншотах указаны созданные юниты для работы Prometheus.

[Unit]
Description=Prometheus
Documentation=https://prometheus.io/docs/introduction/overview/
Wants=network-online.target
After=network-online.target
[Service]
User=prometheus
Group=prometheus
Type=simple
ExecStart=/usr/local/bin/prometheus \
--config.file /etc/prometheus/prometheus.yml \
--storage.tsdb.path /var/lib/prometheus/ \
--web.console.templates=/etc/prometheus/consoles \
--web.console.libraries=/etc/prometheus/console_libraries

[Install]
WantedBy=multi-user.target

[Unit]
Description=Alertmanager Service
After=network.target

[Service]
EnvironmentFile=-/etc/default/alertmanager
User=prometheus
Group=prometheus
Type=simple
ExecStart=/usr/local/bin/alertmanager \
          --config.file=/etc/alertmanager/alertmanager.yml \
          --storage.path=/var/lib/prometheus/alertmanager \
	  --log.level=debug \
          $ALERTMANAGER_OPTS
ExecReload=/bin/kill -HUP $MAINPID
Restart=on-failure

[Install]
WantedBy=multi-user.target

[Unit]
Description=MySQL Exporter Service
Wants=network.target
After=network.target

[Service]
User=prometheus
Group=prometheus
Type=simple
Environment="DATA_SOURCE_NAME=prometheus:asterisk@tcp(127.0.0.1:3306)/"
ExecStart=/usr/local/bin/mysqld_exporter \
--config.my-cnf /etc/mysql_exporter/.my.cnf
--collect.global_status \
--collect.info_schema.innodb_metrics \
--collect.auto_increment.columns \
--collect.info_schema_processlist \
--collect.binlog_size \
--collect.global_variables \
--collect.info_schema.tablestats \
--collect.global_variables \
--collect.info_schema.query_response_time \
--collect.info_schema.userstats \
--collect.info_schema.tables \
--collect.perf_schema.tablelocks \
--collect.perf_schema.file_events \
--collect.perf_schema.eventswaits \
--collect.perf_schema.indexiowaits \
--collect.perf_schema.tableiowaits \
--collect.slave_status \
Restart=always

[Install]
WantedBy=multi-user.target

[Unit]
Description=Node Exporter
After=network.target

[Service]
User=prometheus
Group=prometheus
Type=simple
ExecStart=/usr/local/bin/node_exporter

[Install]
WantedBy=multi-user.target

Произведем конфигурирование файла /etc/prometheus/prometheus.yml:

global:
  scrape_interval: 10s 
  evaluation_interval: 10s 

alerting:
  alertmanagers:
    - static_configs:
        - targets:
           - localhost:9093

rule_files:
  - "alertasterisk.yml"

scrape_configs:
  - job_name: "prometheus"
    static_configs:
      - targets: ["localhost:9090"]
  - job_name: "node_export"
    static_configs:
      - targets: ["localhost:9100"]
  - job_name: "mysql_exporter"
    static_configs:
      - targets: ["localhost:9104"]
  - job_name: "Asterisk-PBX"
    static_configs:
      - targets:
           - "localhost:8088"
    basic_auth:
      username: "Asterisk"
      password: "пароль"

Рассмотрим указанные параметры подробнее:

  scrape_interval – интервал сбора метрик;

  evaluation_interval – интервал серки с правилами;

  alerting – параметры для Alertmanager;

  rule_files – файлы правил;

  scrape_configs – секция с базовыми настройками сбора метрик, указываем откуда считывать метрики.

  Обратите внимание на указанные порты в секции scrape_configs, по которым будет осуществляться сбор метрик.

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

 Перейдем к конфигурированию файла правил /etc/prometheus/alertasterisk.yml, указанного в rule_files.

Описание параметров:

name – название правила;

alert – название тревоги;

еxpr – выражение ожидающее срабатывания условия;

for – ожидание;

severity – статус тревоги;

summary – описание тревоги;

description – краткая характеристика тревоги.

В описании можно использовать переменные:

{{$value}} — содержит значение переменной, участвующей в выражении;

{{$labels.instance}} — IP адрес и порт экспортёра, с которым возникла проблема;

{{$labels.job}} — имя задачи из конфигурационного файла prometheus.

Содержимое файла alertasterisk.yml:

groups:
  - name: alertasterisk
    rules:
        - alert: Asterisk_down
          expr: up == 0
          for: 0m
          labels:
            severity: critical
          annotations:
            summary: "Сервер  {{$labels.instance}} недоступен"
            description: "Cервис Asterisk недоступен \n VALUE = {{$value}} \n Alert: {{$labels.job}}"
        - alert: MySQL_down
          expr: mysql_up == 0
          for: 0m
          labels:
            severity: critical
          annotations:
            summary: "MySQL на сервере  {{$labels.instance}} недоступен"
            description: "Cервис MySQL недоступен \n VALUE = {{$value}} \n Alert: {{$labels.job}}"
        - alert: PJSIP_down
          expr: count(asterisk_endpoints_state == 1) == 3
          for: 0m
          labels:
            severity: warning
          annotations:
            summary: "Требуется проверка Asterisk-PBX"
            description: "Отсутствуют регистрации телефонов на сервере {{$labels.instance}} \n VALUE = {{$value}}"
        - alert: PJSIP_101
          expr: asterisk_endpoints_state{id="PJSIP/101"} == 1
          for: 0m
          labels:
            severity: warning
          annotations:
            summary: "Требуется проверка Asterisk-PBX"
            description: "Отсутствуют регистрация номера 101 \n VALUE = {{$value}}"
        - alert: PJSIP_102
          expr: asterisk_endpoints_state{id="PJSIP/102"} == 1
          for: 0m
          labels:
            severity: warning
          annotations:
            summary: "Требуется проверка Asterisk-PBX"
            description: "Отсутствуют регистрация номера 102 \n VALUE = {{$value}}"
        - alert: PJSIP_trunk
          expr: (asterisk_pjsip_outbound_registration_status{username="sip:410484848@домен"} == 0) or (asterisk_pjsip_outbound_registration_status{username="sip:410484848@домен"} == 2)
          for: 0m
          labels:
            severity: warning
          annotations:
            summary: "Требуется проверка Asterisk-PBX"
            description: "Возникли проблемы с транком \n VALUE = {{$value}}"
        - alert: CPU_load
          expr: ((sum by(instance) (irate(node_cpu_seconds_total{mode!="idle"}[1m]))) / on(instance) group_left sum by (instance)((irate(node_cpu_seconds_total[1m]))) * 100) >= 80
          for: 0m
          labels:
            severity: warning
          annotations:
            summary: "Высокая загрузка процессора {{$value}}%"
            description: "Загрузка процессора \n VALUE = {{$value}}% \n LABELS = {{$labels}}"
        - alert: MEMORY_load
          expr: (((node_memory_MemTotal_bytes - node_memory_MemFree_bytes) / (node_memory_MemTotal_bytes)) * 100) >= 80
          for: 0m
          labels:
            severity: warning
          annotations:
            summary: "Высокая загрузка RAM {{$value}}%"
            description: "Загрузка RAM \n VALUE = {{$value}}% \n LABELS = {{$labels}}"

Рассмотрим созданные правила:

1.Alertasterisk_down – правило для мониторинга статуса узлов, указанных в scrape_configs файла prometheus.yml. В случае, если статус равен 0 в течение 0m, то будет срабатывать alert с описанием тревоги.

 2.  MySQL_down — правило для мониторинга БД. В случае, если статус mysql равен 0 в течение 0m, то будет срабатывать alert с описанием тревоги.

3. PJSIP_down – правило для мониторинга каналов PJSIP. На астериск  создано 3 канала PJSIP (2 номера и 1 транк). В случае, если 3 канала недоступны, то будет срабатывать alert с описанием тревоги.

4. PJSIP_101, PJSIP_102, PJSIP_trunk – правила для мониторинга конкретного канала. В случае, если канал недоступен, то будет срабатывать alert с описанием тревоги.

5. CPU_load – правило для мониторинга CPU. В случае, если загрузка CPU будет >= 80%, то будет срабатывать alert с описанием тревоги.

6. MEMORY_load — правило для мониторинга памяти. В случае, если загрузка памяти будет >= 80%, то будет срабатывать alert с описанием тревоги.

Произведем конфигурацию файла /etc/alertmanager/alertmanager.yml для оповещения.

Описание параметров:

1. resolve_timeout – при опросе в течение этого времени тревога неактивна, то приходить сообщение;
2. group_by — указывается какие метки использовать (в примере используем метка имени);
3. group_wait – время для ожидания отправки уведомления;
4. group_interval – сколько времени ждать для отправки новых уведомлений;
5. repeat_interval – интервал времени через, который необходимо повторно отправить уведомление;
6. receiver – список получателей уведомления;
7. name – имя получателя;
8. параметры для telegram: bot_token, api_url, chat_id,
9. параметры для email: to (кому), from (от кого), smarthost (почтовый сервер), auth_username, auth_password, auth_identity.
10.  send_resolved – включение или отключение resolve_timeout;
11.  inhibit_rules – список для, которых будет использоваться уведомление ‘critical’ и ‘warning’;
12.  Equal — для каких меток используется (выше указали ‘alertname’).

Пример содержания файла конфигурации для отправки сообщения на электронную почту:

Пример содержания файла конфигурации для отправки сообщения в telegram:

Важно соблюдать отступы при конфигурировании файлов. Проверку можно осуществить следующими командами:

promtool check config /etc/prometheus/prometheus.yml
amtool check-config /etc/alertmanager/alertmanager.yml

В конфигурационном файле /etc/asterisk/http.conf укажем для прослушивания порт 8088:

Создадим конфигурационный файл модуля Prometheus /etc/asterisk/prometheus.conf  и укажем следующие параметры:

Для выполнения дальнейших действий необходимо убедиться в работоспособности всех требуемых компонентов и служб. Также не забываем загрузить в Asterisk модуль Prometheus:

module load res_prometheus.so

Проверить статус модуля можно следующими командами:

module show like res_prometheus.so
рrometheus show status

Проверка метрик Asterisk:

рrometheus show metrics

Введем в браузере адрес Prometheus с используемым портом 9090. На данный момент нас интересуют следующие вкладки:

1. вкладка «Alert» — отображает все созданные ранее правила и их статус (имеет 3 состояния: неактивна, в ожидании, запуск);
2.  вкладка «Targets» — отображает добавленные узлы с метриками, все добавленные узлы должны иметь состояние «Up»;
3. вкладка «Rules» — отображает созданные правила.

Проверим доступность метрик Asterisk. Введем в браузере адрес Asterisk, используемый порт 8088. Если метрики доступны, то увидите следующее:

Ранее в /etc/prometheus/alertasterisk.yml внесены условия для мониторинга каналов PJSIP. Эти значения взяты из метрик Asterisk, указанных выше. Рассмотрим их:

1. # HELP asterisk_endpoints_state Individual endpoint states. 0=unknown; 1=offline; 2=online.

asterisk_endpoints_state имеет два состояния 1 – офлайн, 2 – онлайн.

В каждой метрике присутствуют метки id=»PJSIP/номер», по которым в запросе можно следить за конкретным каналом. Если в условии метку не указывать, то вывод будет осуществляться по всем каналам. 

Пример:

• (asterisk_endpoints_state == 1) == 3

Если по всем трем каналам статус будет офлайн (равен 1), то их значение будет равно 3.

• asterisk_endpoints_state{id=»PJSIP/101″} == 1

Если канал PJSIP/101 офлайн, то его значение будет равно 1.

2. # HELP asterisk_pjsip_outbound_registration_status Current registration status. 0=Unregistered; 1=Registered; 2=Rejected.

asterisk_pjsip_outbound_registration_status имеет 3 состояния 0 - не зарегистрирован, 1 – зарегистрирован, 2 – есть проблема с регистрацией.  

В нем также присутствуют метка, по которой можно отследить требуемый транк username=«строка регистрации».

(asterisk_pjsip_outbound_registration_status{username="sip:410484848@домен"} == 0) or (asterisk_pjsip_outbound_registration_status{username="sip:410484848@домен"} == 2)

Приступим к тестированию. Первым рассмотрим отправку сообщений в telegram. Рассмотрим событие, когда два номера 101 и 102 офлайн.

После отработке аварии придут 2 сообщения с информацией о тревоге, которую описали в конфигурационном файле.

После того, как 2 номера стали активны, придут 2 уведомления.

Все происходящие события можно отследить в веб-интерфейсе Alertmanager и Prometheus.

Рассмотрим отправку сообщений на электронную почту. Для примера будет использовать уведомление при высокой загрузке процессора. Повышение нагрузки на виртуальной машине осуществлял с помощью утилиты stress.

После отработки аварии на почту придет сообщения с информацией о тревоге, которую мы описали в конфигурационном файле. После того, как тревога стала неактивна уведомление об этом поступит в почтовый ящик, как и в примере с telegram.  

На мой взгляд Prometheus — это мощный инструмент для мониторинга сервера с Asterisk. Метрики содержать довольно большой набор информации для сбора и анализа. Получение, которых не требует выполнение команд из консоли. Отправка уведомлений об авариях позволяет отслеживать состояние сервера в режиме реального времени и быть в курсе всех событий, происходящих на нем.