Prometheus & PromQL Vocabulary: Monitoring Terms for DevOps Engineers (англійською)
Скребання Prometheus, типи метрики, запити PromQL, Alertmanager і словник спостережуваності для SRE.
Якщо ви працюєте в DevOps або Site Reliability Engineering, ви зустрінете Prometheus майже скрізь. Це стало фактичним стандартом для моніторингу на основі метрик в хмарних середовищах. Але крім вивчення самих інструментів, вам потрібно вільно розмовляти мовою — у стійках, викликах інциденту, перегляді коду і обговоренні архітектури. Цей посібник містить основні слова Prometheus і PromQL, які вам слід знати, щоб впевнено і точно говорити в англомовних групах.
Основні поняття: Prometheus і збір даних
Prometheus — набір інструментів для моніторингу та попередження систем з відкритим кодом, спочатку створений на SoundCloud. Prometheus збирає дані часових рядів за допомогою витягування метрики з налаштованих цілей через регулярні інтервали.
«Ми перейшли з Datadog на Prometheus в минулому кварталі — економія коштів сама по собі це виправдала»
«Prometheus скачає наші послуги кожні п’ятнадцять секунд; це повинно бути достатньо гранулювати для панелей SLO»
** інтервал сканування ** — частота, з якою Prometheus отримує (або « сканує ») метричні дані з цілі. Типовим значенням є 15 або 30 секунд, але цей параметр можна налаштувати залежно від завдання або цілі.
«Ваш інтервал скребка встановлений на одну хвилину — це занадто грубо для попередження про затримку з п’ятисекундним порогом»
«Ми знизили інтервал скребка на платіжній службі до десяти секунд після останнього інциденту»
** target ** — будь- яка кінцева точка, за якою спостерігає Prometheus. Ціль виставляє метрики через HTTP, зазвичай на шляху /metrics. Цілі виявляються статично (за допомогою конфігурації) або динамічно (за допомогою виявлення служб).
«Половина наших цілей показуються як
DOWNв Prometheus UI — виглядає, що правило брандмауера блокує порт 9090»
«Ми використовуємо Kubernetes service discovery, тому нові піди автоматично реєструються як цілі.»
** exporter ** — невелика програма, яка перетворює метричні дані з сторонньої системи (бази даних, черги повідомлень, апаратного забезпечення) у формат Prometheus і використовує їх як ціль для сканування. Поширені приклади включають node_exporter для метрики рівня вузла і postgres_exporter для PostgreSQL.
«Ми додали Redis-експортер до sidecar, щоб Prometheus міг відстежувати використання пам’яті на екземпляр»
«Експортер вузлів дає нам CPU, пам’ять і дисковий вхід/вихід без будь-яких змін коду в самій програмі»
Метричні типи
Зрозуміти типи метрики дуже важливо — тип, який ви виберете, визначатиме, які функції PromQL ви зможете застосувати.
** counter ** — метрика, яка збільшується лише один раз (або скидається до нуля під час перезапуску). Лічильники використовуються для таких значень, як загальна кількість запитів HTTP, помилок або надісланих байтів. Ви майже завжди застосовуєте rate() або increase() до лічильника в запитах.
“Не використовуйте мірник для підрахунку запитів — це лічильник. Вона повинна тільки підніматися»
“Счетчик сбросил после перезапуска, так что на графике есть это падение. Використовуйте
rate()і він буде автоматично обробляти скидання»
** gauge ** — метрика, яка може зростати або зменшуватися. Індикатори показують поточний стан: використання процесора, активні з’ єднання, глибина черги, споживання пам’ яті.
«Температура, вільне місце на диску, запити під час польоту — це всі показники. Вони відображають знімок поточного значення.»
“Наша горутинная шкала поднимается уже три часа. Щось протікає»
** гістограма ** — метрика, яка вибирає спостереження і впорядковує їх у налаштовувані контейнери. Гістограми ідеально підходять для вимірювання затримки запиту і розподілу розмірів відповідей. Вони виставляють _bucket, _sum, і _count часові ряди, що дозволяє обчислення процентилів з histogram_quantile().
«Використовувати гістограму для затримки, щоб ми могли обчислити p99 без зберігання кожної окремої точки даних»
«Гістограма була занадто грубою — ми не мали хвостової затримки вище 500 мс повністю»
** резюме ** — подібно до гістограми, але обчислює квантилі на стороні клієнта. Резюме є менш гнучкими, ніж гістограми, під час агрегування даних у декількох екземплярах, і загалом їх не рекомендується використовувати на користь гістограм у сучасних настройках.
«Ми перейшли від резюме до гістограми, тому що резюме не можуть бути агреговані між репліками»
«Розгортання дає вам квантилі дешево, але ви втрачаєте можливість ре-агрегувати в PromQL.»
ПромQL: Запитування метрик
PromQL (Prometheus Query Language) — функціональна мова запиту для вибору і агрегування даних часових рядів у Prometheus. Його використовують у панелях, правилах попереджень і правилах запису.
“Чи можете ви написати PromQL для показника помилок? Мені це потрібно для панелі Grafana»
«PromQL виглядає загрозливо на початку, але як тільки ви зрозумієте селекторів і агрегації, це стає дуже читабельним.»
** вектор моменту ** — вираз PromQL, який повертає одне значення за часовий рядок у певний момент часу. Більшість простих запитів повертає вектор моменту.
«Місцевий вектор дає вам поточне значення для кожного набору позначок — ідеальний для показу мір в Grafana.»
** range vector ** — вираз PromQL, який повертає діапазон значень за вказаний проміжок часу (наприклад, [5m] ). Вектори діапазону потрібні для таких функцій, як rate() і increase().
«Вам потрібен вектор діапазону для
rate()— щось на зразокhttp_requests_total[5m]»
«Розширити вектор діапазону до
[15m], якщо ваш інтервал скребка становить одну хвилину; інакше обчислення швидкості буде шумним»
** label ** — пара ключ- значення, приєднана до метрики, яка додає контекст розмірності. Мітки нададуть вам змогу фільтрувати, групувати і об’ єднувати показники. Приклади включають job, instance, status_code, і env.
Завжди додавайте позначку
env, щоб ви могли відокремити виробничі метричні дані від стаджування в одному і тому ж екземплярі Prometheus
“Висока значення позначки — як використання ідентифікатора користувача як позначки — призведе до проблем з продуктивністю. Зберігайте позначки низької кардиналізації»
** selector ** — синтаксичний конструкція PromQL, яка фільтрує часові рядки за їх мітками за допомогою позначки {}. Ви можете знайти точні відповідності ( = ), виключити значення ( != ) або використовувати формальні вирази ( =~, !~ ).
Додати
{status_code=~\"5..\"}до вашого селектору для ізоляції помилок сервера
«Цей селектор занадто широкий — він відповідає метриці з кожної служби. Додати
job=\"payments\", щоб зменшити його»
** оператор агрегації ** — оператори PromQL, які об’ єднують декілька часових рядків у менші рядки. Найбільш поширені: sum(), avg(), min(), max(), і count(). Функція rate() також є фундаментальною і використовується для обчислення швидкості зростання лічильника за секунду.
«Загорніть його в
sum by (status_code)— ви хочете один рядок на код стану, а не один на інцидент»
«Використовуйте
rate(http_requests_total[5m])для отримання запитів за секунду, потімsum by (job)для агрегування по репліках»
«
avg()по регіонах приховував той факт, що один регіон мав 40% рівень помилок»
Попередження і правила
** правило запису ** — попередньо обчислений вираз PromQL, який Prometheus оцінює за розкладом і зберігає як новий часовий рядок. Правила запису покращують швидкодію запиту для дорогих виразів, які використовуються неодноразово на панелях інструментів або у сповіщеннях.
“Та панель дуже повільна, тому що вона обчислює велику кількість даних на кожну зарядку. Загорніть його в правило запису»
«Ми маємо правило запису для бюджету помилок SLO — він запускається кожну хвилину і панель Grafana просто читає цю серію»
** правило попередження ** — вираз PromQL, який, якщо його оцінка буде не порожньою протягом вказаного часу (клаузула for), викликає попередження. Правила попереджень визначено у налаштуваннях Prometheus і маршрутизовано за допомогою Alertmanager.
«Правило попередження є правильним, але додайте
for: 5m, щоб ми не сторінку на одному поганому скребку»
«Напишіть правило попередження так, щоб воно запускалося тільки тоді, коли рівень помилок перевищує один відсоток протягом десяти хвилин»
** Alertmanager ** — компонент, який обробляє попередження, викликані Prometheus. Він управляє дедуплікацією, групуванням, маршрутизацією, приглушенням і пригніченням перед надсиланням повідомлень до отримувачів, таких як PagerDuty, Slack або електронна пошта.
«Попередження спалахує в Prometheus, але нічого не прибуло в Slack — перевірте конфігурацію маршрутизації Alertmanager»
«Ми централізували всі попередження через Alertmanager, тому команда на гарячу лінію отримує одне повідомлення за інцидент, а не п’ятдесят»
** приглушувати** — дію приглушення попереджень у Alertmanager на визначений період часу, зазвичай, під час запланованого обслуговування або відомого інциденту. Тиша відповідає попередженням за вибором міток і запобігає надсилання сповіщень.
«Створити тишу для попереджень експортера вузлів перед перезапуском цього вузла, інакше запит буде сторінкований.»
“Мовчазне припинення вогню тривало до півночі, і попередження заповнили весь місто. Нам потрібно розширити його або виправити основну проблему»
** inhibition ** — функція Alertmanager, яка пригнічує певні попередження, якщо вже було викликано попередження з більшим пріоритетом. Наприклад, ви можете приглушити всі попередження на рівні служб, коли активне попередження про аварійне відключення центру обробки даних, зменшивши шум під час великих подій.
«Налаштувати пригнічення, щоб попередження на рівні піду були пригнічені, коли весь кластер позначається як погіршений»
“Без правил пригнічення, одна помилка в мережі генерує сотні попереджень. Це робить триагностику неможливою»
Як використовувати їх у розмові
Сценарий 1 — Вызывание аварийной службы:
«Прометей показує пік в
http_requests_total— рівень за останні п’ять хвилин втричі вище нормального. Гістограма показує, що затримка p99 перевищує дві секунди. Я замовкнув попередження нижнього рівня, поки ми розслідуємо»
** Сценарій 2 — Коментар перегляду коду: **
«Ця метрика повинна бути лічильником, а не мірою — значення тільки зростає. Також, мітка
user_idпризведе до вибуху кардиналізації. Замінити його наtierпозначку»
** Сценарій 3 — Обговорення архітектури: **
«Ми повинні додати правило запису для цього SLO-виразу — він оцінюється в чотирьох різних панелях Grafana і це дорогий діапазон запитів протягом 24 годин. Правило запису буде обчислювати його раз на хвилину і зберігати прилади швидко.”
Сценарий 4 — Передача на дежурство:
“На стадіоні “Експортерс” до 8:00 діє активна тиша. Правило придушення Alertmanager буде пригнічувати перезапуск підсистеми, якщо буде викликано попередження про зниження продуктивності кластера. PromQL для бюджету помилок знаходиться в runbook — просто змініть селектор
env, якщо вам потрібно перевірити стадіювання окремо»
Краткий справочник
| Term | Type | Plain English Summary |
|---|---|---|
| Prometheus | Tool | Open-source monitoring system that scrapes and stores time-series metrics |
| exporter | Component | Adaptor that exposes third-party system metrics in Prometheus format |
| scrape interval | Config | How often Prometheus pulls metrics from a target |
| counter | Metric type | Monotonically increasing value; use rate() to query it |
| gauge | Metric type | Current snapshot value that can go up or down |
| histogram | Metric type | Bucketed observations; enables histogram_quantile() for percentiles |
| label | Data model | Key-value tag that adds dimensions to a metric |
| PromQL | Language | Query language for selecting and aggregating Prometheus metrics |
| recording rule | Config | Pre-computed query stored as a new time series for performance |
| Alertmanager | Tool | Routes, deduplicates, silences, and inhibits alerts before notification |