# Анализ производительности системы с помощью дэшборда ELMA365-Overview

> [HTML Version](elma365-overview-dashboard.html)

Вы можете отслеживать ключевые показатели системы в реальном времени, используя дэшборд **ELMA365-Overview**. 

Он состоит из следующих разделов:

- [ELMA365](#elma365-tab);

- [ELMA365 – Telemetry](#elma365-telemetry-tab);

- [Kubernetes Cluster](#kubernetes-cluster);

- [Pods info](#pods-info-tab);

- [Nodes info](#nodes-info-tab);

- [Postgres](#postgres-tab);

- [RabbitMQ](#rabbitmq-tab);

- [MongoDB](#mongodb-tab);

- [Cache](#redis-tab);

- [Ingress](#ingress-tab);

- [Logs](#logs-tab);

- [Linkerd](#linkerd-tab);

- [Kubernetes Events – Stats](#kubernetes-event-stats-tab).

## Предварительные настройки для дэшборда «ELMA365‑Overview»

Для корректной работы предварительно установите:

- Prometheus и Grafana — для хранения и отображения данных. Подробнее читайте в статье [«Установка средств мониторинга»](install-monitoring-tools.md);

- дополнение DBSExporter — чтобы собирать показатели баз данных. Читайте об этом в статье  [«Мониторинг баз данных»](monitoring-databases.md); 

- Kubernetes Event Exporter — для анализа событий Kubernetes-кластера. Подробнее читайте в статье [«Мониторинг событий»](event-monitoring.md);

- [Loki](install-loki.md) — для сбора и хранения логов о работе системы;

- [Linkerd](install-linkerd.md) (опционально) — если вы настраиваете обработку связи между сервисами и хотите отслеживать параметры соединения.

Чтобы активировать сбор метрик бизнес-процессов, в файле \[OBJECT\] включите параметр \[OBJECT\]. Подробнее читайте в статье [«Мониторинг бизнес-процессов»](business_process_monitoring.md).

После этого данные для дэшборда будут аккумулироваться в хранилище Prometheus и визуализироваться с помощью сервиса Grafana. 

Рассмотрим более подробно содержание разделов дэшборда **ELMA365-Overview**.

## Раздел «ELMA365»

В этом разделе представлены графики, которые позволяют оценить стабильность работы системы, скорость обработки запросов и эффективность выполнения скриптов.



Мониторинг системы разделён на два ключевых блока:

1. **Анализ работы API**.  
**(elma365-overview-dashboard-2.png)**

На графиках можно отслеживать, сколько поступает запросов и за какое время они обрабатываются. Если количество запросов не меняется, а длительность их выполнения растёт, проверьте доступность зависимых сервисов и базы данных. Оптимизируйте также запросы к БД.

2. **Статистика выполнения скриптов**.  
**(elma365-overview-dashboard-2-1.png)**

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



## Раздел «ELMA365 – Telemetry»

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

**(elma365-overview-dashboard-3.png)**

- на графике **Script Time** — время выполнения скриптов, которое зависит от их логики и реализуемых операций. Определите базовый уровень для типовых скриптов и анализируйте их работу. Признаками снижения производительности являются:

	- устойчивый рост времени выполнения скрипта на 30‑50% относительно стандартного значения;

	- выполнение более 3‑5 секунд для скриптов с типовым запросом и простой логикой.

Возможные причины неполадок: неоптимальные алгоритмы, рост объёма данных, блокировки;

- на графике **HTTP Req Time** — время выполнения HTTP‑запросов. Если вы наблюдаете устойчивый рост ошибок, изучите логи Loki.



## Раздел «Kubernetes Cluster»

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

## (elma365-overview-dashboard-14.png)

На графиках отображаются следующие данные:

1. **ETCD DB Size** — объём базы данных etcd. Нормой является стабильное значение с плавным ростом, которое соответствует активности в кластере. Для средних кластеров стандартный объём — от сотен МБ до нескольких ГБ.

На возможные проблемы указывают:

- устойчивое приближение к лимиту. По умолчанию он составляет 2 ГБ, но вы можете установить другое значение;

- резкий и необъяснимый рост объёма данных.

**Важно**: если база данных etcd заполняется более чем на 90% от доступного лимита, она может перейти в режим только для чтения. Это блокирует операции записи в кластере — нельзя создавать или обновлять объекты.

2. **apiserver request rate** — количество запросов к API‑серверу Kubernetes. Нормой является рост числа LIST- и GET‑запросов пропорционально увеличению числа подов, сервисов или запросов от инструментов мониторинга, например Prometheus.

На возможные проблемы указывают резкое падение количества запросов или их устойчивый рост.

3. **etcd request latency** — скорость обработки запросов на стороне etcd. В норме задержка запросов должна быть стабильной и низкой. Для операции `wal\_fsync p95` (95-й процентиль) на исправном SSD/NVMe диске задержка составляет обычно меньше 15 мс, а `p50` — меньше 5 мс. 

Отклонением от нормы являются значения: для `p95` — больше 100‑500 мс, а для `p50` — больше 20 мс. Причиной может быть недостаточная скорость диска, что приводит к задержкам во всём кластере.



### Как найти источники нагрузки на etcd

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

1. Если настройки вашего etcd позволяют посмотреть список всех ключей, получите их с помощью команды:

````
etcdctl get --prefix / --keys-only

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

2. Проанализируйте метрики `apiserver\_request\_total`, которые доступны в системе мониторинга Grafana. Высокие показатели количества запросов к определённым компонентам помогают определить потенциальные источники нагрузки. Часто она возникает из-за чрезмерной активности инструмента Prometheus, операторов и контроллеров, повторяющихся перезапусков kubelet.



## Раздел «Pods info»

На этих графиках отслеживайте состояние подов приложения ELMA365:

**(elma365-overview-dashboard-4.png)**

- **CPU и Memory Usage** — показывает, сколько CPU и ОЗУ ресурсов используется для работы подов. Объём потребления зависит от установленных лимитов;

- **Pod Status** — количество перезапусков подов за определённый период. Нормой являются нулевые или единичные перезапуски. Постоянно растущее число перезапусков одного пода указывает на проблему внутри контейнера, например, завершение его работы с ошибкой или неудачная проверка работоспособности (failed liveness probe);

- **Autoscaling** — число реплик сервисов. Резкий рост кривой графика может указывать на недостаток ресурсов или загруженность сервиса. В таком случае увеличьте объём ресурсов и количество реплик, а также лимиты для подов. Затем изучите логи сервисов, чтобы выявить возможные источники неполадок и устранить их.



## Раздел «Nodes info»

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

При устойчивой высокой нагрузке (заполнение CPU больше 70%, использование памяти больше 80%) добавьте дополнительные ноды (8CPU, 16Mem). Рекомендуемая конфигурация — от 8 CPU, 16 ГБ RAM.

Если вы развернули стандартный кластер Kubernetes, [установите систему Linux](preparing-optimized-kernel.md) для работы в условиях высокой нагрузки, чтобы обеспечить оптимальную производительность кластера.

**(elma365-overview-dashboard-5.png)**

В следующих разделах представлена информация о мониторинге состояния баз данных: [Postgres](postgresql.md), [RabbitMQ](rabbitmq.md), [MongoDB](mongodb.md), [Redis](redis.md) или [Valkey](valkey.md).

## Раздел «Postgres»

Наиболее важным графиком в этом разделе является **Stat activity**. Он показывает информацию по текущей активности. Если значение графика приближается к 80‑90% от максимального (**Max Connections**), увеличьте параметр \[OBJECT\] и проанализируйте пулы соединений в приложениях.

В блоке **DB Size** вы можете отслеживать, сколько свободного места доступно в хранилище. Нормой считается заполнение диска не более чем до 85%. Критичным значением является 90%. Для корректной работы базы данных очистите её от ненужных и устаревших записей или увеличьте размер хранилища.

## (elma365-overview-dashboard-6.png)Раздел «RabbitMQ»

Обратите внимание на график **Messages per Queue**. Он показывает сообщения в очереди. С его помощью можно определить, в каком микросервисе накапливаются сообщения. Если количество сообщений монотонно растёт или не уменьшается, перезагрузите соответствующий микросервис и изучите логи сервиса с помощью [Loki](install-loki.md).

**(elma365-overview-dashboard-7.png)**

## Раздел «MongoDB»

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

**(elma365-overview-dashboard-8.png)**

На графике **Query Operations** отображается, сколько операций в секунду выполняется в базе данных [MongoDB](mongodb.md). Эти метрики позволяют отслеживать производительность и эффективность хранилища. В норме скорость отклика на поступающие запросы должна оставаться стабильной. Если уровень нагрузки не меняется, а время выполнения запросов увеличивается, оптимизируйте запросы или добавьте индексы в БД.

В блоке **Connection Count** можно посмотреть количество активных подключений к базе данных. Сравните текущее число соединений с максимальным значением, которое задаётся в параметре `max\_connections`. Если вы видите, что кривая графика приближается к установленному лимиту:

1. Измените значение параметра `max\_connections` на более высокое.

2. Проанализируйте сервисы, которые подключаются к базе данных. Убедитесь, что не создаётся избыточных соединений и вовремя закрываются неиспользуемые. 

## Раздел «Cache»

В этом разделе можно отследить производительность сервера кеширования данных. Отображаются метрики той службы, которая используется в вашей конфигурации: [Valkey](valkey.md) или [Redis](redis.md). На графиках вы увидите:

1. **CPU**, **Memory** — объём потребления памяти. Приближение к значению `maxmemory` приводит к вытеснению ключей — автоматическому удалению части данных для высвобождения ресурсов.

При разовом достижении максимального объёма перезапустите ваш сервер кеширования данных. Если это не помогает и потребление памяти остаётся близким к максимальному, увеличьте объём памяти.

При высоком потреблении ресурсов проанализируйте также пользовательский код на предмет некорректного кеширования. Убедитесь, что кеш не содержит объёмных JSON‑файлов.**(elma365-overview-dashboard-9.png)**

2. **Total Commands / sec** — отображает общее количество команд в секунду, которые обрабатываются в Redis или Valkey. График служит для мониторинга производительности и эффективности кеша. Также позволяет анализировать различные метрики, связанные с исполнением команд в Redis или Valkey.  
**(elma365-overview-dashboard-15.png)**

## Раздел «Ingress»

В этом разделе вы можете узнать:

**(elma365-overview-dashboard-10.png)**

- **Ingress Certificate Expiry** — оставшийся срок действия сертификатов. Критичным является значение меньше 10 дней;

- **HTTP Rate** — количество HTTP‑запросов, проходящих через [Ingress](install-ingress-nginx.md);

- **HTTP Error** — если на этом графике увеличилось количество ошибок, изучите логи Ingress Nginx для выявления причин.

## Раздел «Logs»

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

**(elma365-overview-dashboard-11.png)**

## Раздел «Linkerd»

Если установлен [сервис Linkerd](install-linkerd.md), в этом разделе можно отслеживать состояние mesh-соединений определённого deployment. Важно следить за графиком **SUCCESS RATE**. На нём отображается количество успешных запросов между сервисами. При возникновении проблем число таких подключений будет снижаться. Для большинства сервисов нормой является значение близкое к 100%. Обращайте внимание на падение количества успешных запросов ниже 95% — для ключевых сервисов или ниже 80% — для любого сервиса. В этом случае проанализируйте работу Linkerd, включая проверку внутреннего сертификата и анализ логов сервиса.

На представленном графике зафиксирован момент снижения производительности. При этом возникло предупреждение: \[OBJECT\]. В этом случае проверьте конфигурационный файл Linkerd и исправьте ошибки в параметрах \[OBJECT\] и \[OBJECT\].

**(elma365-overview-dashboard-12.png)**

## Раздел «Kubernetes Events – Stats»

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

**(elma365-overview-dashboard-13.png)**

События, связанные с подами (Containers):

- **Image Pull Failed **— невозможно скачать образ контейнера для запуска пода, например, если недоступен контейнерный регистр или отсутствует запрашиваемый образ;

- **Liveness Probe Failed **— это событие появляется, если нарушена связь между подом и liveness probe, с помощью которого проверяется корректность работы пода;

- **Volume Mount Failed **— не удаётся смонтировать постоянный том (volume) или ресурс хранения. Такое поведение может возникнуть, если неправильно настроено хранилище либо есть проблемы с сетью или разрешениями;

- **Container OOM Killed **— под завершил работу из-за нехватки памяти. Событие появляется, если под потребляет слишком много памяти и узел не может обеспечить требуемые ресурсы;

- **Container Crashed **— аварийная остановка контейнера. Причиной может быть ошибка внутри контейнера или его некорректная работа;

- **Pod Evicted **— под удалён из-за нехватки памяти или CPU. Событие появляется, если перегружается узел или под потребляет большое количество ресурсов.

События, связанные с планированием (Scheduling):

- **Scheduling Failed **— это событие происходит, когда планировщик Kubernetes не может разместить под на узле из-за нехватки ресурсов или других ограничений. 

События, связанные с системой (System):

- **System OOM **— это событие фиксируется, когда не хватает памяти на системном уровне, например из-за высокой нагрузки на узел или недостаточных системных ресурсов.