РАЗРАБОТКА СИСТЕМЫ МОНИТОРИНГА И АНАЛИЗА ПРОИЗВОДИТЕЛЬНОСТИ В СИСТЕМЕ АУТЕНТИФИКАЦИИ И ЧАТ–БОТА С ИСКУССТВЕННЫМ ИНТЕЛЛЕКТОМ

DEVELOPMENT OF A MONITORING SYSTEM AND PERFORMANCE ANALYSIS IN AN AUTHENTICATION SYSTEM AND A CHATBOT WITH ARTIFICIAL INTELLIGENCE

Nikolaev Petr Undergraduate

Master’s student, Ufa State Petroleum Technological University

Russia, Republic of Bashkortostan, Ufa

Akhmetov Ilnur Vazirovich

Ph.D. in Physical and Mathematical Sciences, Associate Professor, Ufa State Petroleum Technological University

Russia, Republic of Bashkortostan, Ufa

АННОТАЦИЯ

В рамках данной работы разработана комплексная система мониторинга производительности для микросервисной платформы трейдинговой аналитики. Система построена на базе стека Prometheus-Grafana и включает инфраструктурный мониторинг через Node Exporter. Реализована pull-модель сбора метри. Настроены дашборды для визуализации ключевых показателей: время отклика HTTP-запросов, потребление памяти, частота сборки мусора (GC), загрузка процессора и дисковой подсистемы. Обеспечена возможность оперативного выявления аномалий и деградации производительности. Проведен анализ метрик уровня приложения и инфраструктуры, продемонстрирована эффективность разработанной системы для обеспечения наблюдаемости распределенных микросервисов.

ABSTRACT

This research presents the development of a comprehensive performance monitoring system for a microservices-based trading analytics platform. The system is built on the Prometheus-Grafana stack and includes infrastructure monitoring via Node Exporter. A pull-based metrics collection. Dashboards have been configured to visualize key performance indicators: HTTP request response time, memory consumption, garbage collection (GC) frequency, CPU and disk subsystem utilization. The system ensures timely detection of anomalies and performance degradation. An analysis of application-level and infrastructure metrics has been conducted, demonstrating the effectiveness of the developed system for ensuring observability of distributed microservices.

Ключевые слова: Микросервисная архитектура; Мониторинг; Prometheus; Grafana; Node Exporter; .NET 8; Метрики производительности; Наблюдаемость; Instrumentation; Docker.

Keywords: Microservice architecture; Monitoring; Prometheus; Grafana; Node Exporter; .NET 8; Performance metrics; Observability; Instrumentation; Docker.

Введение

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

Актуальность данного исследования обусловлена необходимостью создания комплексной системы наблюдения за микросервисной платформой трейдинговой аналитики, включающей несколько независимых компонентов: сервис обработки рыночных данных, пользовательский интерфейс аналитической платформы, базу данных PostgreSQL, а также инфраструктурные компоненты системы мониторинга.

Целью данной работы является разработка и внедрение системы мониторинга на базе стека Prometheus–Grafana с интеграцией метрик уровня инфраструктуры (Node Exporter) и уровня приложения (Application Performance Monitoring).

Концепция наблюдаемости в распределенных системах

Наблюдаемость (Observability) представляет собой свойство системы, позволяющее по ее внешним выходам делать выводы о внутреннем состоянии. В контексте программной инженерии наблюдаемость обеспечивается тремя основными столпами: метриками, логами и трассировкой [1]. Метрики представляют собой числовые показатели, характеризующие состояние системы в определенный момент времени. В отличие от логов, которые фиксируют дискретные события, метрики предоставляют непрерывную временную шкалу измерений, что делает их идеальным инструментом для выявления трендов и аномалий в поведении системы.

Согласно классификации Google Site Reliability Engineering (SRE), метрики подразделяются на три основные категории, известные как «RED method»:

1. Rate (частота) – количество запросов в единицу времени;

2. Errors (ошибки) – доля ошибочных запросов;

3. Duration (длительность) – время обработки запросов [2].

Архитектурные паттерны сбора метрик

Существует два основных архитектурных паттерна сбора метрик: push–based (проталкивание) и pull–based (вытягивание). В push–модели наблюдаемые системы самостоятельно отправляют метрики в центральный накопитель. Данный подход характерен для таких систем, как StatsD и Graphite. Преимуществом push–модели является простота реализации на стороне приложения, однако возникают сложности с обнаружением недоступных сервисов и обеспечением надежности доставки данных. Pull–модель, реализованная в Prometheus, предполагает периодический опрос целевых систем центральным сервером мониторинга. Такой подход обеспечивает ряд преимуществ:

1. автоматическое обнаружение недоступности сервисов (отсутствие ответа при опросе); централизованный контроль частоты сбора метрик;

2. упрощение конфигурации наблюдаемых систем; возможность кэширования метрик на стороне приложения [3].

Системы мониторинга на временных рядах работают с упорядоченной последовательностью значений, привязанных к моментам времени. Ряд обычно представляется парой «время-значение» и дополняется метками для различения измерений (хост, сервис, метод запроса). Для хранения и обработки используются TSDB, оптимизированные под быструю запись, сжатие и запросы по временным интервалам. В таких системах применяются четыре типа метрик: счётчик (монотонно возрастает, например число запросов или исключений), датчик/Gauge (может расти и уменьшаться, например память, активные потоки, температура), гистограмма (распределяет наблюдения по интервалам, например время отклика) и сводка (аналог гистограммы, но с процентилями, например «95 % запросов быстрее X мс») [4]. Prometheus стал де-факто отраслевым стандартом сбора метрик благодаря ключевым преимуществам, поэтому в данном исследовании выбран именно он в интеграции с Grafana.

Архитектура разработанной системы мониторинга, общая структура

Для лучшего понимания применения системы мониторинга, сначала рассмотрим, где она применяется, ниже показана общая архитектура приложения, также стоит отметить, что разработка ведется на .net-платформе с использованием языка c#. На рисунке 1 показана архитектура ассистента.

Рисунок 1. архитектура цифрового ассистента

Описание компонентов из приведенной выше архитектуры: Authentication Service отвечает за авторизацию и аутентификацию; Employee Learning Training Service занимается хранением, обработкой и созданием интерактивных обучающих курсов; Currency and other Stock quotes service получает котировки по валютам и другим биржевым инструментам; цифровой ассистент (чат-бот) служит для взаимодействия с чат-ботом; Chat History Storage service хранит и обрабатывает истории чата; Analytics and Monitoring Service предназначен для мониторинга системы.

Далее рассмотри разработанную систему мониторинга подробнее, она разработана на базе стека Prometheus-Grafana и включает следующие компоненты, на рисунке 2 показана схема взаимодействия мониторинга:

1. Prometheus Server – центральный сервер сбора и хранения метрик;

2. Node Exporter – агент сбора инфраструктурных метрик хостовой системы;

3. Grafana – система визуализации и построения дашбордов;

4. Application Services – наблюдаемые микросервисы платформы:

5. Market Data Service (API сервис обработки котировок).

Рисунок 2. Схема мониторинга

Prometheus система сбора и хранения метрик, компоненты системы мониторинга и инструментация

Prometheus представляет собой систему мониторинга с открытым исходным кодом, разработанную в SoundCloud и ставшую вторым проектом в истории, принятым в Cloud Native Computing Foundation[5]. Prometheus характеризуется многомерной моделью данных с метками, языком запросов PromQL, эффективной собственной TSDB со сжатым хранением и разрешением 1 мс, а также автоматическим Service Discovery через различные механизмы. Конфигурация Prometheus осуществляется через YAML-файл prometheus.yml, определяющий параметры сбора метрик, ниже представлен конфигурационные настройки, конфигурацию сервисов показана на рисунке 3.

Рисунок 3. Конфигурация Prometheus

В файле задаётся интервал сбора метрик Prometheus и адреса сервисов-целей. Система мониторинга включает три компонента: Node Exporter [6], open-source daemon для Linux/Unix, экспонирующий на порту 9100 инфраструктурные метрики (загрузка CPU по режимам, память, диск, сеть, uptime и др.) без root-прав через /proc и /sys; Prometheus .NET Client [7], официальную библиотеку для инструментации .NET-приложений через middleware ASP.NET Core, предоставляющую автоматические метрики процесса, HTTP-запросов (количество, длительность, текущие) и Garbage Collector (сборки, размер кучи); Grafana [8], open-source платформу визуализации, подключённую к Prometheus как источнику данных, с интерактивными дашбордами, alerting и Variables/Templating для динамической фильтрации. На рисунке 4 показан интерфейс запущенного Prometheus с настроенными сервисами.

Рисунок 4. Интерфейс Prometheus

Реализация и настройка системы мониторинга

Все компоненты системы мониторинга развёрнуты в среде Docker с использованием Docker Compose для оркестрации контейнеров. Такой подход обеспечивает воспроизводимость окружения, изоляцию компонентов, упрощение развёртывания и масштабирования, а также автоматическое управление сетевыми подключениями. При необходимости отдельные сервисы могут быть перезапущены или заменены независимо друг от друга. На рисунке 5, показана настройка части сервисов в конфигурационном файле (Docker Compose).

Рисунок 5. Конфигурация Docker Compose

Все контейнеры объединены в единую Docker-сеть “monitoring_net” типа bridge. Такая конфигурация обеспечивает разрешение имён контейнеров через встроенный DNS, изоляцию трафика мониторинга от внешней сети и автоматическую маршрутизацию между сервисами. Для доступа из браузера разработчика проброшены порты 9090 (Prometheus), 3000 (Grafana), 9100 (Node Exporter), 5000 и 5001 (микросервисы приложения). Для подключения метрик в приложении .net используется базовая библиотека promtheus, в дальнейшем количество метрик будет увеличено, ниже показана настройка метрик в самом приложении, также в приложении подключен swagger для того, чтобы можно было отправлять и отлаживать http-запросы.

Анализ результатов мониторинга

На рисунке 6 показаны четыре развёрнутых компонента мониторинга: Prometheus собирает и хранит метрики по HTTP, analytics-platform служит интерфейсом и источником прикладных метрик, market-data-service реализует API котировок, а node-exporter отдаёт инфраструктурные метрики хоста (CPU, память, диски). Каждый сервис изолирован в отдельном контейнере и взаимодействует во внутренней Docker-сети monitoring_net по именам контейнеров, а доступен по своим адресам и портам для отладки и сбора метрик. Дашборд Node Exporter Full (ID: 1860), один из самых востребованных в Grafana, наглядно визуализирует ресурсы сервера; показаны секции Quick CPU/Mem/Disk и Basic CPU/Mem/Net/Disk с gauge-индикаторами CPU, RAM и swap и графиками во времени.

Рисунок 6. Метрики Node Exporter: нагрузка на CPU и использование оперативной памяти

Анализ метрик начнём с CPU. Левый gauge-индикатор показывает мгновенную загрузку у пользователя и у системы, а график «CPU Basic» дополнительно отображает среднее за 5 минут и разбивает время по режимам: user, system, idle и iowait, что позволяет понять источник нагрузки и исключить интенсивный дисковый ввод-вывод. Важен и контроль памяти: на дашборде Memory Basic отображаются общий объём, занятая память, кэш и, свободная память и использование подкачки. Наблюдаемые значения и выводы по ним сведены в таблицу 1. Таким образом, дашборд Node Exporter Full позволяет фиксировать текущие значения, анализировать их в динамике и сопоставлять группы показателей, что делает его удобным инструментом как для повседневного мониторинга, так и для диагностики проблем производительности.

Метрики уровня приложения отражают внутреннее состояние сервисов, работу сборщика мусора, потребление памяти и потоков, а также качество обработки HTTP-запросов. Для их сбора в .NET-приложениях применяется библиотека prometheus-net, экспортирующая стандартные runtime-метрики и позволяющая задавать собственные. Дашборд ASP.NET Core агрегирует метрики обоих микросервисов с фильтрацией по переменной instances. На рисунке 7 показан фрагмент дашборда с базовыми .NET-метриками, анализ которого свидетельствует о штатной работе сборщика мусора и стабильном потреблении ресурсов; количественные показатели и выводы по ним приведены в таблице 1.

Рисунок 7. Базовые .net метрики уровня приложения

Таблица 1

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

Заключение

В рамках данной работы была разработана и внедрена комплексная система мониторинга микросервисной платформы трейдинговой аналитики на базе стека Prometheus–Grafana. В состав решения вошли сервер Prometheus, обеспечивающий сбор и хранение метрик, Node Exporter для инфраструктурных показателей, Grafana с готовыми дашбордами для .NET-приложений и состояния сервера, а также инструментаций ASP.NET Core-сервисов с помощью библиотеки prometheus-net.

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

Список литературы:

1. Heinrichs, J. Observability Engineering: Achieving Production Excellence / J. Heinrichs, C. Majors, L. Fong-Jones. С. 40⁠–⁠68. – Sebastopol: O'Reilly Media, 2022.
2. Beyer, B. Site Reliability Engineering: How Google Runs Production Systems / B. Beyer, C. Jones, J. Petoff, N.R. Murphy. 154. – Sebastopol: O'Reilly Media, 2016. – 176 P.
3. Prometheus Documentation. Official Documentation [Электронный ресурс].(Режим доступа: 11.09.2026). – URL: https://prometheus.io/docs/introduction/overview/.
4. Grafana Labs. Metrics types in Prometheus [Электронный ресурс]. – URL: https://prometheus.io/docs/concepts/metric_types/ (дата обращения: 05.09.2026).
5. Julius Volz. Prometheus: Monitoring at SoundCloud / J. Volz [Электронный ресурс]. / Prometheus Blog. – 2015. – URL: https://developers.soundcloud.com/blog/prometheus-monitoring-at-soundcloud (дата обращения: 03.09.2026).
6. Node Exporter GitHub Repository. Prometheus Node Exporter [Электронный ресурс]. – 2026. – URL: https://github.com/prometheus/node_exporter (дата обращения: 12.09.2026).
7. Prometheus.NET Client. prometheus-net GitHub Repository [Электронный ресурс]. – 2026. – URL: https://github.com/prometheus-net/prometheus-net (дата обращения: 01.09.2026).
8. Grafana Documentation. What is Grafana? [Электронный ресурс]. – URL: https://grafana.com/docs/grafana/latest/ (дата обращения: 02.09.2026).