# Диагностика нагрузки: дашборды, логи и Pyroscope

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

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

Сценарий помогает последовательно:

1. определить наличие аномалии по метрикам;
2. найти наиболее нагруженные `pod`'ы;
3. проверить журналы событий;
4. выполнить профилирование потребления CPU и памяти;
5. зафиксировать результаты анализа для передачи разработчикам.

## Общий порядок действий

При выявлении резкого роста утилизации ресурсов анализ рекомендуется выполнять от общего уровня наблюдения к детальному:

1. открыть основные дашборды мониторинга;
2. определить период возникновения аномалии;
3. установить `pod`'ы с наибольшей нагрузкой;
4. проверить журналы проблемного `pod`'а;
5. перейти к профилированию CPU и RAM;
6. найти наиболее затратные участки через `Flame Graph`;
7. подготовить материалы для эскалации разработчикам.

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

## Выявление аномалии по дашбордам мониторинга

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

Если такое поведение не связано с известной нагрузкой, плановыми задачами или интеграциями, существует высокая
вероятность ошибки в коде либо некорректной работы прикладной логики.

Для первичного анализа рекомендуется использовать дашборды:

- `System Overview`;
- `VM Memory`.

![Рисунок 1. Дашборд System Overview](img/figure-01-system-overview.png)

*Рисунок 1. Дашборд System Overview*

![Рисунок 2. Дашборд VM Memory](img/figure-02-vm-memory.png)

*Рисунок 2. Дашборд VM Memory*

При наведении курсора на график можно определить, к какому именно `pod`'у относится нагрузка.

По обоим дашбордам видно, что рост нагрузки затрагивает несколько `pod`'ов, однако наиболее высокая нагрузка наблюдается
на `pod`'е с окончанием `-8r22g`.

## Анализ журналов

После определения наиболее нагруженного `pod`'а необходимо перейти к дашборду `Logs` и настроить фильтрацию.

Рекомендуется указать:

- проблемный `pod`;
- временной интервал, соответствующий периоду роста нагрузки;
- `namespace`, если это необходимо;
- дополнительные параметры поиска, если они помогают сузить выборку.

![Рисунок 3. Анализ журнала проблемного pod'а](img/figure-03-pod-logs.png)

*Рисунок 3. Анализ журнала проблемного `pod`'а*

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

Тем не менее по косвенным признакам можно сделать вывод, что источник повышенной нагрузки связан с работой GlobalServer.

## Анализ проблемы с помощью профилирования

Если анализ журналов не дал достаточного результата, необходимо перейти к инструментам профилирования:

```text
Drilldown -> Profiles
```

В данном разделе доступны различные типы профилей и метрик.

Для первичного анализа рекомендуется открыть вкладку `Labels`, где можно:

- выбрать `Profile Type`;
- переключаться между профилями использования CPU и RAM;
- фильтровать данные по конкретным `pod`'ам.

![Рисунок 4. Анализ профилей на вкладке Labels](img/figure-04-profile-labels.png)

*Рисунок 4. Анализ профилей на вкладке `Labels`*

На данном этапе проблема подтверждается и на уровне профилирования: повышенная нагрузка сохраняется и воспроизводится в
профилях.

## Определение проблемного участка через Flame Graph

Основным инструментом детального анализа является `Flame Graph`.

Для корректного анализа необходимо:

1. выбрать временной диапазон, соответствующий периоду аномальной нагрузки;
2. указать тип профиля: CPU или RAM;
3. выбрать проблемный `pod`;
4. отфильтровать участки с наибольшим потреблением ресурсов.

![Рисунок 5. Выявление проблемного участка на Flame Graph](img/figure-05-flame-graph.png)

*Рисунок 5. Выявление проблемного участка на `Flame Graph`*

В рассматриваемом примере на `Flame Graph` определяется проблемный участок прикладного решения:

```text
ru/bitec/app/btk/telemetry/Btk_PerformanceTestApi$$Lambda_.apply
```

Для получения дополнительной информации необходимо выбрать соответствующий участок `Flame Graph` и открыть раздел
`Function Details`, где отображаются детализированные сведения о выбранной функции.

![Рисунок 6. Просмотр сведений в разделе Function Details](img/figure-06-function-details.png)

*Рисунок 6. Просмотр сведений в разделе `Function Details`*

## Вывод по результатам анализа

В рассматриваемом примере источник проблемы был установлен корректно: в целях тестирования с высокой частотой запускался
тест `Btk_PerformanceTestApi`, что привело к избыточной нагрузке на систему.

В эксплуатационных сценариях по итогам анализа необходимо:

1. зафиксировать временной диапазон возникновения проблемы;
2. сохранить скриншоты дашбордов и результатов профилирования;
3. указать проблемный `pod`;
4. указать выявленный участок кода;
5. передать собранные материалы разработчикам Global для дальнейшего анализа и устранения причины.

## Состав информации для передачи разработчикам

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

| Данные                               | Описание                                                                             |
|--------------------------------------|--------------------------------------------------------------------------------------|
| Среда                                | Наименование стенда, контура или эксплуатационной среды.                             |
| `namespace`                          | Пространство имен, в котором наблюдается проблема.                                   |
| Период аномалии                      | Дата и время начала/окончания повышенной нагрузки.                                   |
| Проблемный `pod`                     | Полное имя `pod`'а с наибольшим потреблением ресурсов.                               |
| Скриншоты мониторинга                | `System Overview`, `VM Memory`, `Logs`, `Profiles`, `Flame Graph`.                   |
| Тип профиля                          | CPU или RAM, в зависимости от того, где проблема проявляется наиболее явно.          |
| Проблемная функция, класс или модуль | Название участка, вызвавшего наибольшую нагрузку.                                    |
| Дополнительное описание              | Краткое описание наблюдаемого поведения и действий, предшествовавших росту нагрузки. |

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