Различия

Показаны различия между двумя версиями страницы.

--- linux:prom [2023/11/26 12:10]
admin
+++ linux:prom [2024/06/28 05:46] (текущий)
admin
@@ Строка 4: / Строка 4: @@
 ==== Установка ====
 ==== Использование ====
+=== Варианты тегов в легенде ===
+{{:linux:label.png?direct&400|}}
+=== Дефотное значение при отсутствии данных ===
+<code>
+sum() OR vector(0)
+или, в случае с VictoriaMetrics
+sum() OR default 0
+</code>
+=== ===
@@ Строка 159: / Строка 175: @@
 Гистограмма - агрегация чего то самим приложением, когда нам интересно знать **распределение величин** по заранее **определенным группам** (buckets). **Качественное распределение**\\
-Например определили 4 бакета с длительностью запроса, (условно по секунде, меньше или равно), пришла очередная метрика с длительностью запроса, он увеличил на единицу все бакеты "меньше или равно" его длительности\\
+Например определили 4 бакета с длительностью запроса, (условно по секунде, меньше или равно), пришла очередная метрика с длительностью запроса, он увеличил на единицу соответствующий бакет и суммарную метрику времени\\
 В метриках добавляется тег "**le**" (less than or equal)\\
-:!: **Гистограмма считает считает кол-во попаданий** в какую то группу т.е. запоминает счетчики а не сами значения. Каждый бакет как бы отдельная метрика\\
+:!: **Гистограмма считает кол-во попаданий** в какую то группу т.е. запоминает счетчики а не сами значения. Каждый бакет как бы отдельная метрика\\
-Удобно агрегировать в т.н. **квантили**. Если вы не знаете какие бакеты нужны, есть другой тип **Summary**
+Агрегируется в т.н. **квантили**. Если вы не знаете какие именно бакеты нужны, есть другой тип **Summary**
 <code bash>
@@ Строка 179: / Строка 195: @@
 Сводка. Это результат **агрегации гистрограммы**, она выдает сразу **квантили**, можно сказать **количественное распределение**\\
+По сути получается что считаются квантили, суть в том что группировка "с другой стороны" как бы, если в гистограмме мы создали бакеты по заданному времени, и считаем столько запросов распределяется по каким группам, то тут мы смотрим в какое время попадает 99%, 95%, 50% и 10% (уровни предопределены) запросов\\
+:!: интерпретация "меньше или равно" указанного времени\\
+:!: Саммари не рекомендуется агрегировать или делать это аккуратно, осмысливая реальные значения, легко получить мусор на выходе\\
+<code bash>
+# Пример метрики: распределение времени обработки HTTP-запросов по 5 квантилям
+http_duration_summary{quantile="1"} 100
+http_duration_summary{quantile="0.99"} 4.300226799 (<= этого времени)
+http_duration_summary{quantile="0.95"} 2.204090024
+http_duration_summary{quantile="0.5"} 0.073790038
+http_duration_summary{quantile="0.1"} 0.018127115
+http_duration_summary_sum 152.7625769  # как у гистограммы, сумма всех значений
+http_duration_summary_count 141  # и количество значений
+</code>
+Сводки хранятся в памяти на стороне приложения, а т.к. для них нужно хранить какую то историю показателей, память растет и необходимо периодически ее чистить, поэтому подсчеты квантилей происходят с некоторыми потерями\\
+Есть разные алгоритмы для очистки старых данных, последнее/случайное и тд, с разной эффективностью\\
 </details>
+=== Перцентили ===
+Перцентили нужны для того чтобы описать массив данных одним числом\\
+Например чтобы понять как ведет себя приложение в целом, отбрасывая единичные выбросы\\
 <details>
-<summary>:!: </summary>
+<summary>:!: Данные</summary>
+Метрика это временной ряд т.е. набор значений во времени, отбросил timestamp'ы остается просто массив чисел\\
+условно [1,3,0,186,14,12,8,17,7]\\
-</details>
+Как обобщить эти данные ? самое популярное это вывести среднее, самое простое среднее арифметическое, это когда сумма элементов делится на их кол-во, **в данном примере 27.5**\\
+В какой то теоретической сфере вполне правильно и удобно, есть ряд чисел, правильным средним будет именно это число\\
+Но в какой то практическое сфере, прикладной, это не совсем подходит, т.к. есть выбросы и реально основная масса чисел тут не превышает 20, а только один элемент сильно отрывается от всех остальных, поэтому портит статистику. В таких случаях применяют "медиану", она устойчива к любым выбросам\\
+**Медиана**\\
+Средний элемент т.е. буквально в середине (упорядоченного) массива, **в данном случае 8**\\
+Ну и даже на вскидку, кажется более справедливая цифра\\
+[0,1,3,7, 8, 12,14,17,186]\\
+Восьмерка взята прямо из массива, он упорядочен, половина элементов меньше (или равна) этому числу, вторая половина больше (или равна) ему, т.о. "50% <= 8"\\
+Так же можно выделить мин и макс в этом числовом ряду т.е. 0% и 100%\\
+<code>
+% < 0
+% <= 8
+% <= 186
+</code>
+Будет полезно посчитать например 90%, 95%, 99% от подобного ряда, чтобы охватить как можно больше  данных, исключая при этом не типичные скачки\\
+Это и будет называться 90ым, 95ым, 99ым перцентилем, т.е. "медиана" это ничто иное как 50ый перцентиль, просто имеет более распространенное название\\
+:!: Перцентили позволяют нарезать слоями наш массив и понять на какие группы делятся элементы, типа "в среднем", "в основном", "в подавляющем большинстве" и тд.\\
+**Пример с мониторингом приложения**\\
+Предположим что этот массив чисел это длительность выполнения запросов в секундах к нашему приложению, как оценить скорость его работы ?\\
+Среднее арифметическое будет 27.5с\\
+Медиана (он же 50% перцентиль) 8с\\
+p90,95 и 99 в данном случае будут 17с т.к. выборка очень небольшая они совпадают\\
+</details>
 <details>
-<summary>:!: </summary>
+<summary>:!: Семплирование</summary>
+Для подсчета такой статистики нужна история данных, со временем она ес-но разрастается, есть несколько вариантов семплирования данных, один из них применение бакетов, о которых уже говорилось выше. т.е. хранить не сами данные а просто счетчики того, сколько раз элемент попал в какой то заранее определенный диапазон\\
+Например в случае с временем запросов к приложению можем выделить несколько бакетов типа "<= 3,5,7 секунд" и наблюдать в какие промежутки укладываются запросы к приложению\\
 </details>
+Возвращаясь к Prometheus, перцентили в нем встречаются в двух случаях, это метрики типа "Histogram" (когда бакеты считаются в приложении, а прометеус потом может посчитать по ним перцентили) и "Summary" (перцентили которые уже посчитаны в приложении а прометеус просто хранит их как числа)\\
+**Процентиль** просто вариант перевода на русский язык т.е. полный синоним слова перцентиль\\
+**Квартиль** - это четверти т.е 25%, 50%, 75% и 100% (первый, второй, третий и четвертый квартили)\\
+**Квантиль** - тоже самое что и перцентиль только в случае если вероятность выражается не в процентах\\
+| {{:linux:etteka5wyaq_lkb.png?direct&400|}} | {{:linux:etteka5xeaqqal3.png?direct&400|}} |
+| {{:linux:ettekatxiaad76a.png?direct&400|}} | {{:linux:ettekayxaaa0kpq.png?direct&400|}} |
 === PromQL ===
+Каждая метрика это временной ряд, отдельная таблица, имя таблицы это уникальный набор всех тегов а значение одно число записанное в разные моменты времени\\
 <details>
-<summary>:!: Примечания</summary>
+<summary>:!: Извлечение данных</summary>
+В самом простом случае, в запросе достаточно указать только имя метрики, извлекутся данные со всеми тегами\\
-В случае с Прометеем, для группировки интервалов следует использовать переменную **$__rate_interval** вместо "$__interval", она поддерживается только в нем\\
+<code>
-Переменная интервала призвана динамически подбирать интервал, для прометея rate_interval оптимизирована гораздо лучше\\
+http_requests_total
+  # Имя метрики тоже является тегом
+{__name__="http_requests_total"}
+  # Теги можно фильтровать
+http_requests_total{job="prometheus",group="canary"}
+</code>
+**Range vector**\\
+Так же можно задать временной диапазон, с помощью которого график будет сглаживается\\
+В таком случае мы получаем т.н. **"range vector"**\\
+<code>
+http_requests_total{job="prometheus",group="canary"}[1m]
+</code>
+Простой запрос возвращает **"instant vector"**, перечень одиночных значений, привязанных ко времени, график спокойно рисуется, ничего сложного\\
+В случае с **range вектором**, каждая точка содержит в себе значение в запрошенный момент времени + массив из предыдущих значений за этот указанный интервал\\
+<code>
+[ 5,   6,   7 ]
+ [2], [3], [4]
+ [3], [4], [5]
+ [4], [5], [6]
+</code>
+Но такие данные на двумерном графике ес-но рисоваться не могут, поэтому их нужно сначала привести к простому виду, к "instant" вектору, делается это с помощью функций агрегации\\
+т.е. если мы применяем диапазон времени для сглаживания графика, необходимо так же применить ф-цию агрегирования, получить instant вектор\\
+:!: На счет интервала, по умолчанию интервал сборка метрик у прометеуса 30 секунд, для в данном случае нужно не меньше двух точек с-но выбирать следует не меньше минуты, иначе данных просто не будет\\
+<code>
+В случае с графаной, для группировки интервалов следует использовать переменную **$__rate_interval**, вместо "$__interval", она поддерживается только в для прометеуса\\
+Переменная интервала призвана динамически подбирать интервал, для прометея rate_interval оптимизирована гораздо лучше
+</code>
+</details>
+<details>
+<summary>:!: Запросы</summary>
+<code>
+  # OR
+http_requests_total{app=~"apache|nginx|iis.*"}
+  # AND (# найдет все tag, начинающиеся на aaa И заканчивающиеся на bbb)
+metric{tag=~"aaa.*", tag=~".*bbb"}
+  # запрос, который умножит значения на 10 и вернет только те, которые больше или равны 50:
+metric{tag="value"} * 10 >= 50
+  # вернет пересечение: значения, у которых полностью совпадающий набор тегов в обоих запросах
+metric1 and metric2{tag="something"}
+  # Запрос, который вернет разницу. Например, посчитаем сколько RAM занято
+total_ram{instance="host"} - free_ram{instance="host"}
+</code>
+**Агрегация**\\
+<code>
+  # Сумма. Например есть метрика с двумя разными тегами
+http_requests_total{app="nginx"}
+http_requests_total{app="apache"}
+    # Просуммируем значения со всеми вариантами (! попавшими под запрос)
+sum(http_requests_total)
+  # Для того чтобы отображать не все теги, их можно группировать, группировка по указанным
+sum (http_requests_total) by (app, instance)
+  # Группировка по всем кроме указанных
+sum (http_requests_total) without (instance)
+</code>
+**Функции**\\
+Популярна ф-я **rate**. Применяется к постоянно возрастающим счетчикам, считает скорость прироста в секунду\\
+Учитывает сбросы метрик приложения (рестарт например), есть ф-я "irate" для резко прыгающих графиков\\
+**deriv** аналог rate() но не для счетчиков а для метрик которые меняются в обе стороны, "gauge"\\
+Обе ф-ии принимают **range vector**\\
+**histogram_quantile**\\
+Принимает **instant vector**, позволяет посчитать нужный перцентиль из гистограммы, при этом сами гистограммы можно агрегировать\\
+<code>
+rate(http_requests_total{app="nginx"}[5m])
+deriv(ram_free{host="postgresql"}[5m])
+histogram_quantile(0.95, rate(http_request_duration_seconds_bucket[5m]))
+histogram_quantile(
+.95,
+    sum by (url, le) (
+        rate(http_request_duration_seconds_bucket[5m])
+    )
+)
+</code>

zxcx

Инструменты пользователя

Инструменты сайта

Различия

Инструменты страницы