Дата публикации: 11.08.2025
В статье представлено описание настройки мониторинга:
Витрины данных конфигурации «Стандарт» – версий 1.x
Наличие мониторинга сложной системы, такой как Витрина данных Стандарт, предоставляет возможность отслеживать ее состояние и производительность. Эта система состоит из множества взаимосвязанных компонентов, каждый из которых отвечает за определенную функциональность в общей архитектуре системы. Возможность отслеживание ключевых метрик и показателей каждого компонента позволяет выявлять проблемы и своевременно предотвращать неисправности.
В статье – Общая информация и пример настройки мониторинга описан процесс конфигурирования и установки Grafana с Prometheus на основе Docker-контейнеров с использованием плагина Docker Compose.
В данной статье будут рассмотрены способы мониторинга многокомпонентной системы Витрины данных Стандарт.
Настройка мониторинга Витрины Стандарт реализуется следующими шагами:
1. Настройка конфигурации:
Примечание
В статье - Общая информация и пример настройки мониторинга при разворачивании Prometheus уже была создана базовая конфигурация prometheus.yml, который определяет, какие источники данных будет остлеживать Prometheus
Необходимо дополнить файл prometheus.yml, добавив новые источники данных для мониторинга компонентов Витрины, например:
- prostore;
- podd-adapter-mppr;
- podd-adapter-mppw;
- podd-adapter-query;
- data-uploader;
- rest-uploader.
В качестве примера ниже описана часть конфигурации для мониторинга Prostore, которую можно использовать для любых других истоников данных. Для добавления нового источника потребуется создать новую секцию job_name с указанием имени сервиса.
|
scrape_configs: . . . - job_name: 'prostore' static_configs: - targets: - '{IP_ADDRESS}:{METRICS_PORT}' |
При заполнении также важно заменить {IP_ADDRESS} на внешний IP-адрес виртуальной машины, на которой развернут компонент витрины, и {METRICS_PORT} на порт, по которому выгружаются метрики этого сервиса. Значение порта, по которому выгружаются метрики, отличаются для каждого компонента и необходимо уточнять дополнительно.
После внесения изменений в конфигурационный файл, не забудьте перезапустить Prometheus, чтобы применить новую конфигурацию. При использовании Docker Compose в качестве инструмента установки всех компонентов мониторинга, для перезапуска Prometheus используется команда ниже:
|
docker compose up -d --force-recreate prometheus |
2. Создание базовых панелей мониторинга Витрины Стандарт
После настройки конфигурации Prometheus и добавления новых источников данных, следующим шагом будет создание панелей визуализации в Grafana. Для каждого из новых источников данных, добавленных в конфигурацию Prometheus вам потребуется создать соответствующие панели визуализации в Grafana. Этот процесс включает в себя определение необходимых метрик и построение наглядных графиков и диаграмм.
Чтобы создать дашборд необходимо выполнить следующие действия:
1) На примере ниже порт для доступа в Grafana – 3000. В окне браузера укажите адрес до Grafana (Рисунок 1):
Рисунок 1 – Окно браузера. Адрес до Grafana
2) В открывшемся окне необходимо ввести данные учётной записи (по умолчанию: admin/admin, в целях безопасности рекомендуется изменить данные для входа от учётной записи в настройках Grafana):
Рисунок 2 – Авторизация в Grafana
3) После авторизации вы попадаете на главную страницу Grafana (Рисунок 3):
Рисунок 3 – Главная страница Grafana
4) В левом боковом меню страницы Grafana нажмите на стрелочку для раскрытия всех функций. На открывшейся плашке необходимо раскрыть Dashboards (Дашборды) и в выпадающем списке выбрать + New dashboard (Новый дашборд):
Рисунок 4 – Главная страница Grafana. Создание дашборда
5) На появившейся новой странице выбрать Add a new panel (Добавить новую панель):
Рисунок 5 – Новый дашборд. Создание панели дашборда
6) В открывшемся окне генерации дашборда на правой панели необходимо найти плашку с визуализацией и раскрыть выпадающий список страницы (по умолчанию будет выставлено значение Time series):
Рисунок 6 – Панель дашборда. Плашка визуализации
7) Выберите тип визуализации Gauge как на рисунке 7:
Рисунок 7 – Панель дашборда. Выбор визуализации
8) Далее ниже можно выставить необходимые значения для визуализации. Например в поле Title введите название дашборда. Следом перейдите в запросную часть на панели внизу:
Рисунок 8 – Панель дашборда
Для отслеживания состояния работы компонентов можно использовать метрику liveness. Это позволит отслеживать состояние всех подключенных компонентов разом, либо каждого компонента по отдельности с использованием следующих PromQL запросов:
|
avg(sum_over_time(liveness{job=~".+"}[$__range])) clamp_max(sum_over_time(liveness{job=~".+"}[$__range]), 100) |
Эти запросы визуализируют среднее значение liveness метрики за заданный период времени, а также ограничивают максимальное значение до 100. На следующем рисунке (Рисунок 9) показан пример панелей, визуализирующих эти два запроса соответственно.
Рисунок 9 – Отображение доступности компонентов Витрины
К дополнительным метрикам мониторинга можно отнести req_count_total и req_err_total. Метрика req_count_total отображает общее количество успешных входящих запросов, а метрика req_err_total - количество входящих запросов с ошибками. Эти метрики можно использовать для визуализации динамики запросов за определенный период времени. В качестве примера можно использовать следующие PromQL запросы:
|
sum by (job) (round(increase(req_count_total{job=~".+"}[$__range]))) sum by (job) (round(increase(req_err_total{job=~".+"}[$__range]))) |
На следующем рисунке (Рисунок 10) показан пример панелей, визуализирующих эти два запроса соответственно.
Рисунок 10 – Отображение количества обращений к компонентам
3. Отслеживание логирования
Логи содержат ценную информацию, необходимую для диагностики проблем, анализа производительности, обеспечения безопасности и многого другого. Поэтому мониторинг и управление логами имеют ключевое значение в отслеживании состояния набора систем. Однако традиционные подходы к управлению логами часто сталкиваются с проблемами масштабируемости, высокой стоимости хранения и сложности поиска нужной информации.
В качества готового решения, которое позволяет управлять логами в современных распределенных средах предлагается рассмотреть Loki и Promtail.
Loki - это система управления логами, которая предназначена для эффективного сбора, хранения и поиска логов. В отличие от традиционных систем управления логами, Loki использует более эффективный подход, фокусируясь на индексировании меток (labels) вместо полного текста логов. Это позволяет значительно снизить затраты на хранение данных и повысить производительность поиска.
Promtail - это агент, который устанавливается на серверах и отвечает за сбор логов с различных источников и отправку их в Loki. Promtail может собирать логи из файлов, журналов systemd, Docker-контейнеров и других источников. Он также поддерживает динамическое обнаружение источников логов, что упрощает развертывание и управление.
Настройка логирования делится на несколько этапов:
- Подготовка конфигурации;
- Запуск и проверка работы Loki и Promtail;
- Получение логов из Docker-образов;
- Установка плагина Docker;
- Добавление источника данных в Grafana.
1) В директории /home/user/monitoring необходимо создать две дополнительные директории для конфигурационных файлов Loki и Promtail. Для этого создайте директорию loki с файлом внутри loki.yml и директорию promtail, которая будет содержать файл promtail.yml:
|
mkdir /home/user/monitoring/loki touch /home/user/monitoring/loki/loki.yml mkdir /home/user/monitoring/promtail touch /home/user/monitoring/promtail/promtail.yml |
2) Ниже представленная базовая конфигурация для системы управления логами Loki, которая полностью описывает значения по умолчанию для конфигурации необходимых сервисов, портов, путей внутри контейнера и другие важные настройки для работы сервиса. Откройте файл loki.yml на редактирование следующей командой:
|
nano /home/user/monitoring/loki/loki.yml |
3) Cкопируйте содержимое ниже в файл loki.yml:
|
auth_enabled: false server: http_listen_port: 3100 grpc_listen_port: 9096 log_level: info grpc_server_max_concurrent_streams: 1000 common: instance_addr: 127.0.0.1 path_prefix: /tmp/loki storage: filesystem: chunks_directory: /tmp/loki/chunks rules_directory: /tmp/loki/rules replication_factor: 1 ring: kvstore: store: inmemory query_range: results_cache: cache: embedded_cache: enabled: true max_size_mb: 100 schema_config: configs: - from: 2020-10-24 store: tsdb object_store: filesystem schema: v13 index: prefix: index_ period: 24h ruler: alertmanager_url: http://localhost:9093 |
4) И также представлен пример конфигурации для сборщика логов Promtail с базовыми настройками. Откройте файл promtail.yml на редактирование следующей командой:
|
nano /home/user/monitoring/promtail/promtail.yml |
5) Скопируйте содержимое ниже в файл promtail.yml:
|
server: http_listen_port: 9080 grpc_listen_port: 0 positions: filename: /tmp/positions.yaml clients: - url: http://loki:3100/loki/api/v1/push scrape_configs: - job_name: local static_configs: - targets: - localhost labels: job: varlogs __path__: /var/log/*log |
Основная цель этой конфигурации – обеспечить централизованный сбор и хранение логов с локальной машины в Loki для упрощения процесса мониторинга и последующего их анализа.
Запуск и проверка работы Loki и Promtail
В статье – Общая информация и пример настройки мониторинга для разворачивания Grafana и Prometheus использовался инструмент Docker Compose, для которого создавался файл описания сервисов docker-compose.yml в директории /home/user/monitoring/. Для добавления сервисов Loki и Promtail необходимо дополнить конфигурацию следующими параметрами:
|
services: . . . loki: image: grafana/loki:3.2.1 container_name: loki volumes: - /home/user/monitoring/loki:/etc/loki ports: - 3100:3100 restart: unless-stopped command: - --config.file=/etc/loki/loki.yml networks: - monitoring promtail: image: grafana/promtail:3.1.2 container_name: promtail volumes: - /var/log:/var/log - /home/user/monitoring/promtail:/etc/promtail restart: unless-stopped command: - --config.file=/etc/promtail/promtail.yml networks: - monitoring |
После обновления конфигурации следует запустить добавленные сервисы с использованием команды ниже:
|
docker compose up -d --force-recreate loki promtail |
Для проверки готовности сервиса можно обратиться из терминала к сервису Loki, например, с использованием адреса отображения статуса готовности или получения списка метрик. Проверка готовности должна отобразить значение ready или можно увидеть сообщение об ожидании готовности. Следует подождать некоторое время и выполнить запрос снова.
|
# Готовность Loki curl –X GET localhost:3100/ready # Получение метрик Loki curl –X GET localhost:3100/metrics |
Получение логов из Docker-образов
Работа с Docker-контейнерами часто сопряжена с необходимостью отслеживать состояние логов каждого отдельного запущенного сервиса. Выполнение команды получения логов для конкретного контейнера по отдельности может быть неэффективным и отнимать много времени на дополнительный анализ.
Для решения этой задачи хорошо подходит Promtail – инструмент, который обрабатывает и анализирует логи Docker-контейнеров. Однако, по умолчанию Promtail не имеет возможности для сбора логов и требует дополнительной настройки.
Для настройки Promtail на сбор логов Docker-контейнеров, необходимо добавить следующий блок в конфигурационный файл promtail.yml в раздел scrape_configs.
|
scrape_configs: . . . - job_name: docker pipeline_stages: - docker: {} static_configs: - labels: job: docker __path__: /var/lib/docker/containers/*/*-json.log |
После обновления конфигурации сервиса Promtail, необходимо установить дополнительный Docker-плагин, который будет считывать логи из Docker-контейнеров и передавать их в Loki. Подробнее об этом можно прочитать в официальной документации Docker driver client.
Для установки необходимого плагина, выполните следующую команду:
|
docker plugin install grafana/loki-docker-driver:2.9.2 --alias loki --grant-all-permissions |
Чтобы проверить успешность установки плагина, используйте команду:
|
docker plugin ls |
Если необходимо, чтобы установленный плагин Loki был драйвером по умолчанию для всех контейнеров, то следует обновить файл /etc/docker/daemon.json со следующей конфигурацией:
|
{ "log-driver": "loki", "log-opts": { "loki-url": "http://localhost:3100/loki/api/v1/push", "loki-batch-size": "400" } } |
После успешного обновления конфигурационного файла daemon.json перезапустите сервис Docker командой ниже:
|
sudo systemctl restart docker |
Важно!
Использование плагина Loki будет применено только для новых запущенных Docker-контейнеров. Поэтому, после обновления конфигурации Docker и перезапуска сервиса, необходимо также перезапустить все уже запущенные приложения, чтобы они начали использовать Loki в качестве драйвера логирования
Добавление источника данных в Grafana
Завершающей важной частью по разворачиванию инструментария логирования, будет добавление Loki как источника данных в Grafana. Для этого необходимо запустить web-бразуер и пройти по адресу, на котором развернута Grafana и авторизироваться.
1) Для добавления нового источника данных, необходимо в левом боковом меню страницы Grafana перейти в раздел Configuration (Настройки конфигурации), затем выбрать пункт Data sources (Источника данных). Найти кнопу Add data source (Добавить источник данных):
Рисунок 11 – Grafana. Окно с настройками конфигурации. Добавление нового источника данных
2) В поисковике введите Loki. Выберите его:
Рисунок 12 – Grafana. Окно с настройками конфигурации. Добавление нового источника данных Loki
Рисунок 13 – Grafana. Окно с настройками конфигурации. Выбор источника данных Loki
Рисунок 14 – Grafana. Окно с настройками конфигурации. Системные настройки Loki
5) После чего в самом низу формы проверить настройки Loki по кнопке “Save & Test” (Сохранить и тестировать). После чего появится информационное окно с успешным коннектом:
Рисунок 15 – Grafana. Тест коннекта с Loki
При успешном добавлении Loki как источника данных можно нажать кнопку «Explore» (см. рисунок 15), выбрав соответствующий раздел в боковом меню страницы, для проверки работоспособности сервиса. В качестве источника данных запросов в самом начале страницы выбрать Loki и перейти в раздел написания запросов.
Следующий пример запросов отобразит все сообщения логирования на локальной машине, дополнительно можно отсортировать сообщения по интересующим словам, например, по уровню логирования INFO:
|
{job="varlogs"} {job="varlogs"} |~ "(info|INFO)" |
Или использовать запрос для получения доступа к логам конкретного контейнера по его наименованию:
|
{container_name="prostore"} |
Дополнительные возможности
Мониторинг состояния инфраструктуры
Исчерпывающий шаблон использования node_exporter в качестве мониторинга можно получить на официальном сайте Grafana:
https://grafana.com/grafana/dashboards/1860-node-exporter-full/.
Рисунок 16 – Grafana. Мониторинг node_exporter
Конфигурация для node_exporter будет иметь следующий вид:
|
services: . . . node_exporter: image: prom/node-exporter:latest container_name: node_exporter ports: - 9100:9100 volumes: - /proc:/host/proc:ro - /sys:/host/sys:ro - /:/rootfs:ro command: - '--path.procfs=/host/proc' - '--path.rootfs=/rootfs' - '--path.sysfs=/host/sys' - '--collector.filesystem.mount-points-exclude=^/(sys|proc|dev|host|etc)($|/)' network_mode: host restart: unless-stopped |
Необходимо также доработать конфигурацию prometheus.yml и вставить следующую запись:
|
scrape_configs: . . . - job_name: 'node_eporter' static_configs: - targets: - 'localhost:9100' |
Заключение
Мы рассмотрели возможности и пример настройки мониторинга Витрины данных Стандарт. В статье – Возможности мониторинга агентаСМЭВ4 рассмотрены особенности подготовки Агента СМЭВ4 к выгрузке собственного набора метрик и пошаговое создание дашборда в Grafana с формированием первой панели и написанием простого PromQL запроса.











