Рекомендации по настройке мониторинга

В данной статье представлены рекомендации по настройке мониторинга системы онлайн-консультирования Webim для обеспечения контроля за бесперебойной работой.

Параметры мониторинга

Круглосуточный мониторинг сервера реляционной базы данных (MySQL или PostgreSQL) осуществляется по следующим параметрам:

Наличие процесса MySQL или PostgreSQL;
Доступность порта 3306 (MySQL) или 5432 (PostgreSQL) с сервера приложений Webim;
Нагрузка на CPU с пороговым значением в 90% загрузки в течение 15 минут;
Наличие 5% свободной оперативной памяти на сервере;
Мониторинг здоровья жесткого диска по SMART и состояния RAID массива;
Наличие ошибок при реплицировании, отставание репликации;
Мониторинг корректности создания резервных копий MySQL или PostgreSQL, наличие файла последней резервной копии;
Ежедневная или еженедельная проверка на корректность таблиц в базе данных;
Мониторинг появления новых ошибок в логе сервера MySQL или PostgreSQL.

Требования к системе мониторинга

Рекомендуется настроить описанные ниже виды мониторинга.

Мониторинг нагрузки на CPU на сервере

Критическое длительное значение — 90%. Проверить запросы к nginx. Возможно, имеется ненормальная активность.

Мониторинг наличия процессов сервера, необходимых для работы Webim Server

В типовой hosted-поставке через Docker службы запускаются контейнерами из /etc/webim/docker-compose.yml.

Служба	Необходимые процессы	Действия при отсутствии процессов
nginx	master + worker процессы	`systemctl restart nginx`
`php-fpm` (необязательно)	Наличие master‑процесса и всех пулов: `webim-visitor`, `webim-visitor2`, `webim-admin`, `webim-admin2`, `webim-images`	`systemctl restart php-fpm`
`server.py`	Наличие процесса python `server.py` (`-port 8260` по умолчанию). Процессом управляет `supervisord`, поэтому он тоже должен быть запущен.	Перезапуск контейнера Webim Server
Admin Backend	Процесс приложения и доступность порта (по умолчанию `6001`)	Рестарт приложения согласно способу инсталляции
`php2db` (для СУБД, отличных от MySQL)	—	—

Мониторинг работоспособности процесса

Эндпоинт: /l/v/init

Проверка:

curl "/l/v/init" -v

Ожидается 200 и JSON‑ответ.

Реакция: проверить лог /var/log/pro/tornado-8260.log.

В нормальных условиях должны появляться сообщения о старте сессий чата/отправки сообщений. В случае отсутствия новых данных стоит проверить доступность сервера из сети.

Если доступ есть, перезапустить контейнер Webim Server либо сам процесс через supervisord:

Мониторинг доступности PHP

PHP в hosted-установке

В типовой hosted-поставке Webim Server 10.8 через Docker компонента PHP и php-fpm нет. Проверка ниже относится к установкам, в которых PHP ещё есть.

Мониторинг осуществляется следующим образом:

Эндпоинт: /client.php

Пример корректного ответа (заголовки):

$ curl /client.php -I
HTTP/1.1 200 OK
Server: nginx
Date:
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Vary: Accept-Encoding
Expires:
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Pragma: no-cache
Set-Cookie: PHPSESSID=1111; path=/; domain=. ; secure; HttpOnly

Реакция: проверить /var/log/pro/error.log.

Если имеются ошибки, то по ситуации исправить их.

Если недоступен или не отвечает PHP, то перезапустить php-fpm в том окружении, где он запущен:

systemctl restart php-fpm

Мониторинг данных аккаунта

Локальная проверка (только на сервере):

curl -u <login>:<password> http://127.0.0.1:8260/l/a/monitor/accounts-stat

Ниже представлена стандартная форма запроса (подробнее об этом и других эндпоинтах мониторинга смотрите в этой статье).

curl --request GET   --url 'https://companyname.webim.ru/l/a/monitor/accounts-stat'   --header 'Authorization: Basic S0me7eX7'

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

[
  {
    "name": "TOTAL",
    "sessions_cnt": 13,
    "visible_sessions_cnt": 13,
    "alive_sessions_cnt": 13,
    "pages_cnt": 12,
    "alive_pages_cnt": 0,
    "online_operators_cnt": 2,
    "working_operators_cnt": 2,
    "chats_cnt": 1,
    "offline_chats_cnt": 1,
    "in_queue_cnt": 2,
    "failed_to_store_objects_cnt": 0,
    "collected_to_store_objects_cnt": 0,
    "being_stored_now_objects_cnt": 0,
    "being_stored_now_processed_objects_cnt": 0,
    "failed_to_store_objects_cnt_1": 0,
    "collected_to_store_objects_cnt_1": 0,
    "being_stored_now_objects_cnt_1": 0,
    "being_stored_now_processed_objects_cnt_1": 0,
    "not_belongs_to_tornado_instance": 0
  },
  {
    "name": "demo",
    "domain": "demo.webim.ru",
    "sessions_cnt": 13,
    "visible_sessions_cnt": 13,
    "alive_sessions_cnt": 13,
    "pages_cnt": 12,
    "alive_pages_cnt": 0,
    "online_operators_cnt": 2,
    "working_operators_cnt": 2,
    "chats_cnt": 1,
    "offline_chats_cnt": 1,
    "in_queue_cnt": 2,
    "failed_to_store_objects_cnt": 0,
    "collected_to_store_objects_cnt": 0,
    "being_stored_now_objects_cnt": 0,
    "being_stored_now_processed_objects_cnt": 0,
    "failed_to_store_objects_cnt_1": 0,
    "collected_to_store_objects_cnt_1": 0,
    "being_stored_now_objects_cnt_1": 0,
    "being_stored_now_processed_objects_cnt_1": 0,
    "not_belongs_to_tornado_instance": false,
    "ignore_not_belongs_to_tornado_instance": false
  }
]

Переменные:

collected_to_store_objects_cnt и collected_to_store_objects_cnt_1 — не более 2000
failed_to_store_objects_cnt и failed_to_store_objects_cnt_1 — не более 0

Реакция: при срабатывании триггера по очереди на запись или по ошибкам записи проверить доступность базы и возможность записи в неё. Счётчики без суффикса относятся к первому хранилищу, с суффиксом _1 — ко второму.

Рост collected_to_store_objects_cnt и collected_to_store_objects_cnt_1 может быть вызван медленным доступом к базе.

Мониторинг доступности базы данных с сервера приложений

Для MySQL используйте mysqladmin ping.

Для PostgreSQL используйте pg_isready.

Также для проверки доступности базы данных со стороны Chat Backend можно использовать эндпоинт /l/a/monitor/connect-to-db (см. Описание эндпоинтов мониторинга). Проверка подходит и для MySQL, и для PostgreSQL.

Дополнительно контролируйте доступность Redis (порт по умолчанию 6379): он нужен Chat Backend.

Реакция: восстановить доступность базы данных.

Мониторинг доступности сервера из внешней сети

Проверку удобно производить по описанным выше эндпоинтам с внешних узлов. При проблемах — проверить интерфейсы и маршруты.

Реакция: проверить сетевые интерфейсы на сервере, маршруты до/с сервера.

Кроме этого, рекомендуем дополнительно использовать фоновый сервис atop на сервере со сбором статистики раз в минуту. Он поможет оптимизировать процесс анализа состояния сервера.

Дополнительная информация

Рестарт сервисов для ротации файловых логов не нужен. Ротировать надо логи nginx (access, error) и Chat Backend. Журналы PHP (myPHP, fpm) ротируйте только если компонент PHP установлен. Желательно, чтобы логи были доступны одну неделю. Больший объём логов будет занимать значительный объём диска.

Журналы контейнеров из /etc/webim/docker-compose.yml смотрите так:

docker compose -f /etc/webim/docker-compose.yml logs

При большой нагрузке рекомендуется проводить мониторинг блокировок. Актуальные версии реляционной СУБД для Webim Server 10.8 — MySQL 8.0.45 и PostgreSQL 18.1.

Ниже перечислены некоторые конечные точки, которые могут быть полезны при мониторинге:

/l/a/monitor – базовая информация о запущенном Chat Backend
/l/a/monitor/connect-to-db – проверка подключения Chat Backend к базе данных
/l/a/monitor/timer-stats – что запущено в таймерах и сколько выполнялось
/l/a/monitor/accounts-stat – оперативные показатели по аккаунтам (включая информацию о количестве чатов, сессий, страниц и прочего)
/l/a/monitor/zabbix/channels – ошибки по каналам
/l/a/object-stats – objgraph-данные от профайлера
/l/i/instance-id – идентификатор Chat Backend
/service/monitor/ – возвращает HTML-страницу для визуального мониторинга сервера

Возможности мониторинга Webim в примерах

Webim позволяет осуществлять мониторинг параметров на различных уровнях.

Мониторинг ответов

Компоненты Webim Server позволяют осуществлять внешний мониторинг в реальном времени при помощи систем мониторинга наподобие Zabbix, благодаря чему можно анализировать задержку, код и тело ответа.

Оперативная информация по серверу (количество активных аккаунтов, сессий и т.д.)

Таблицы мониторинга

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

Мониторинг текущего состояния

Мониторинг текущего состояния в режиме реального времени, сохранять показатели в БД за счёт контроля системных параметров сервера и специализированных параметров Webim Server с помощью стандартных систем мониторинга.

Визуализация данных мониторинга

Полученные показатели можно визуализировать при помощи различных сервисов для аналитики и визуализации, таких как Grafana.

Количество открытых чатов и операторов онлайн на один аккаунт в моменте

Количество объектов в очереди на запись, открытых сессий и т.д.

Совмещённые графики системных параметров при исследовании инцидента

Логи

Каждый серверный компонент Webim записывает значимую информацию в журнал контейнера или в файл. По журналам можно отслеживать ошибки и предупреждения. Файловые логи ротируются; рекомендуется хранить их неделю.

Формат строки Chat Backend задаётся в logging.json. Подробнее — в статье Логирование в Chat Backend. Шаблон строки:

[W 260930 12:00:00 +0300 <module>:<lineno>] <message>

Работа с логами

Log-файлы можно агрегировать и парсить при помощи различных сервисов (GrayLog, Logstash/ELK и т.д.), осуществлять поиск необходимых объектов, строить графики и диаграммы по сложным выборкам.

Поиск записей о событии operator.update_status внутри временного промежутка в GrayLog

Графики величины времени ответа компонентов сервера

Оповещения

Сверх этого, рекомендуется настраивать оповещающие системы, которые будут уведомлять сотрудников о превышении допустимых значений показателей через различные каналы (Telegram, SMS и т.д.).