Англійська для Prometheus і Metrics

Метричний словник постійно змішується — «лічильник» і «гауґ» звучать взаємозамінно для когось нового в Prometheus, але вони поводяться зовсім по-іншому, і змішування їх виробляє справді пошкоджені приладочні панелі. Точна мова тут особливо важлива під час інциденту, коли команда повинна правильно інтерпретувати графік під тиском часу, а не вгадати, що насправді представляє метрика.

Ключовий словник

• Скажу Тип метрики, який збільшується лише один раз (або скидається до нуля під час перезапуску), використовується для таких даних, як загальна кількість обслугованих запитів або загальна кількість помилок — зазвичай, ви зображаєте на графіку швидкість зміни цього типу, а не його первинне значення.

• Приклад: “Це лічильник, тому очікується, що сире значення постійно піднімається - те, що нас насправді цікавить, це швидкість зростання за останні п’ять хвилин, а не абсолютний номер.” *

• Датчик Тип метричної величини, який може вільно зростати або зменшуватися, використовується для таких даних, як поточне використання пам’ яті або кількість активних з’ єднань у даний момент. Приклад: «На відміну від лічильника запитів, це індикатор — він призначений для коливань, і раптове падіння до нуля є сигналом, що стосується, а не стабільним підйомом.»

** Гістограма ** Тип метрики, який вибирає спостереження (наприклад, тривалість запиту) у налаштовані контейнери, що надає вам змогу обчислювати квантилі, наприклад, затримку p95 або p99 після фактичного часу. Приклад: “Ми використовуємо гістограму для затримки запиту, щоб ми могли обчислити p99 пізніше, а не тільки знати середнє, що приховує проблеми з затримкою хвоста.”

Скреби Процес, за допомогою якого Prometheus отримує метричні дані з цілі за регулярними інтервалами, замість того, щоб ціль надсилала метричні дані до Prometheus. Приклад: «Метрика цієї служби не показується, оскільки Prometheus не налаштовано для сканування кінцевої точки метрики — ціль ще не в нашому налаштуванні сканування.»

** Мітка (метрична мітка) ** Пара ключ- значення, приєднана до метрики, що дозволяє її розрізати і відфільтрувати за виміром, наприклад, endpoint або status_code, без потреби у окремій метриці для кожного значення. Приклад: “Замість окремої метрики на кінцеву точку, ми використовуємо один лічильник з міткою endpoint, тому ми можемо фільтрувати або агрегувати за цією вимірністю в запитах.”

Кардинальність Кількість різних комбінацій значень міток, які може створити метрика, що безпосередньо впливає на вартість пам’яті і зберігання - мітки високої кардиналізації (наприклад, сирі ідентифікатори користувачів) є поширеним джерелом проблем з продуктивністю.

• Приклад: « Ми випадково додали необроблений ідентифікатор користувача як мітку до цієї метрики, що призвело до різкого збільшення кількості ключів, і саме тому використання пам’ яті на сервері Prometheus зросло до рекордних значень. » *

** Правило попередження ** Умова, виражена у вигляді запиту, яка запускає сповіщення, якщо її оцінка буде істинною протягом визначеного часу, відрізняючи тимчасовий бліп від справжньої тривалої проблеми. *Приклад: “Ми додали клаузулу for: 5m до цього правила попередження, тому короткий пік затримки не буде сторінкою нікому, якщо він не триватиме п’ять хвилин.” *

** ПромQL ** Мова запиту, яку використовують для вибору, фільтрування і об’ єднання показників, збережених у Prometheus, використовується як для панелей інструментів, так і для визначення правил попереджень.

• Приклад: « Цей запит PromQL підсумовує кількість помилок у всіх екземплярах, але ми хочемо, щоб він був розбитий на екземпляри, щоб знайти, який з них не працює. » *

Звичайні фрази

** В обзорах коду: **

• «Ця метрика інструментується як мірник, але вона тільки зростає — чи повинна вона насправді бути лічильником?»
• «Ця мітка включає сирий ID запиту, який створить необмежену кардиналість — чи можемо ми відкинути його або перетворити його в щось грубіше?»
• «Підказка правила не має тривалості for, тому один скретч-пік буде сторінкою когось, навіть якщо він вирішить сам за себе протягом декількох секунд»

В стоячих позах:

• “Вчора я перетворив цей неправильно класифікований лічильник на правильний лічильник з попередженням на основі ставки; сьогодні я перевіряю нову панель управління проти вчорашніх даних про інцидент.”
• «Я заблокований на вибуху кардиналізації — мітка, яку ми додали минулого тижня, генерує набагато більше часових рядів, ніж очікувалося, і сервер Prometheus знаходиться під тиском пам’яті»
• «Я закінчив додавання гістограми для затримки цієї кінцевої точки, тому ми можемо нарешті відстежувати p95 замість того, щоб мати тільки середнє значення»

В ретроспективах про події:

• «Дисплеї показали підйом сирого значення лічильника, що виглядало тривожно, але це просто очікувана поведінка лічильника — фактичним сигналом, який нам потрібен, була ставка, яка була плоскою»
• «Ми не отримали попередження про це, тому що поріг правила попередження був встановлений на середньому, а затримка p99 вже була далеко за тим, що користувачі відчували як повільно»
• «Висока кардиналість на цій мітці спричинила затримку запиту під час інциденту, саме тоді, коли нам найбільше потрібно було подивитися на панель приладів»

Фрази, яких слід уникати

** Сказати « метрика неправильна » для очікуваної поведінки лічильника. ** Замість цього скажіть: «це лічильник, тому сире значення тільки збільшується — ми повинні дивитися на його швидкість, а не на абсолютну кількість» — це одна з найпоширеніших точок плутанини для будь-кого, хто не читає панелі Prometheus.

Сказати “додати більше позначок” без розгляду кардинальності. Замість цього скажіть: « перевірте, чи ця мітка може створювати необмежені значення перед її додаванням — мітки з високою кардиналістю є поширеною причиною проблем з швидкодією Prometheus ». Явно вказана кардиналість свідчить про те, що ви усвідомлюєте цей компроміс, а не просто додаєте виміри вільно.

** Типовим буде « попередження про середню затримку ». ** Замість цього скажіть: «попередження на певному квантиль, як p95 або p99, оскільки середні значення приховують хвостову затримку, яка насправді впливає на реальних користувачів» — це часто зустрічається помилка в дизайні правил попередження.

Краткий справочник

Term	How to use it
counter	”This counter only increases; graph its rate, not the raw value.”
gauge	”The gauge should fluctuate normally; a drop to zero is the concern.”
histogram	”The histogram lets us compute p99 latency, not just an average.”
scrape	”The target isn’t in our scrape config, so its metrics aren’t collected.”
cardinality	”A raw user ID label exploded cardinality on this metric.”
alerting rule	”The for: 5m clause prevents a brief blip from paging anyone.”

Ключеві моменти

• Відрізняти лічильники від індикаторів точно — підйом лічильника є очікуваною поведінкою, а коливання індикатора, яке несподівано знижується, є справжнім сигналом, за яким слід стежити.
• Для визначення показників затримки краще використовувати гістограми, а не прості середні значення, оскільки середні значення приховують затримку хвоста, яка є найважливішою для справжніх користувачів.
• Перед додаванням нової мітки уважно стежте за значенням кардиналізації — необмежене число значень міток є основною причиною проблем з швидкодією і вартістю Prometheus.
• Використовувати тривалість for у правилах попередження, щоб відрізнити перехідний бліп від тривалої, справді дійсної проблеми.
• Якщо панель приладів виглядає тривожно, перевірте, чи пояснює тип метричної форми (стабільне підняття лічильника) перед тим, як розглядати її як сигнал про подію.

Назва походить від англійського слова «метафора»

Оскільки інженери DevOps все більше покладаються на Prometheus і його пов’язані метрики, точне розуміння термінології стає надзвичайно важливим. Це не просто читання чисел; це ефективне повідомлення цих чисел колегам, які переглядають ваш код, пояснюють раптову підйом у затримці або створюють чітке правило попередження. Для не рідних носіїв англійської мови це може бути особливо складним завдяки тонким відмінностям у фразуваннях і високоспеціалізованому словниковому запасі навколо моніторингу. Часто те, що здається простим твердженням, може мати значні наслідки залежно від контексту і рівня деталізації. Розглянемо сценарій: коментар перегляду коду. Уявіть, що ви написали нову службу, яка виявляє метрику затримки запиту на стеження. Під час перегляду, ваша колега, Сара, залишає такий коментар: « Ця request_duration_seconds метрика здається незвичайно високою під час годин пік. Чи можете ви дослідити потенційне вузьке місце? ” Негайна проблема полягає не тільки в розумінні * того, що * вона каже - це інтерпретація невідкладності і очікувань подальших дій. “Незвичайно високий” не просто означає вище порогу; це говорить про відхилення від нормальної поведінки, що заслуговує уваги. Аналогічно, формування правила попередження вимагає ретельного розгляду. Погано сформоване правило може викликати хибні позитивні результати або не вдатися до захоплення критичних проблем. Наприклад, замість « Попередити, якщо використання процесора перевищить 80% », точніше було б написати: « Викликати попередження, якщо тривале використання процесора на всіх вузлах кластера досягне 80% протягом більше ніж п’ яти хвилин ». Різниця незначна, але важлива — останнє слово чітко визначає тривалість і обсяг попередження.

Інша поширена ситуація виникає під час описів PR. При детальному описі змін до системи моніторингу, ясність і точність є життєво важливими. Неясні висловлювання типу “Покращена збірка метрики” не допоможуть. Замість цього, розробники повинні прагнути до детальних пояснень, описуючи * чому * зміна була зроблена і який вплив вона очікується мати. Наприклад: « Впроваджено нові контейнери гістограм для затримки запиту, щоб забезпечити більш деталізоване відображення даних і полегшити аналіз причин під час пікових навантажень ». Це показує розуміння основних показників і цінності, яку вони надають. Крім того, пам’ятайте, що технічні обговорення часто включають кількісне вираження спостережень — «збільшення рівня помилок було приблизно на 15%» набагато ясніше, ніж просто сказати «рівень помилок збільшився».

І, нарешті, не бійтеся просити про пояснення. Якщо ви не впевнені щодо терміну або фрази, яку використовують колеги, ввічливо запитайте про пояснення. Запитання демонструє вашу прихильність до розуміння системи і запобігає нерозумінням, які можуть призвести до неточності інтерпретації або неефективності рішень. Ключовим є зосередитися на комунікації намірів і контексту поряд з технічними деталями.

Ось приклад того, як ви можете використовувати promtool для дослідження метричної величини:

promtool query 'rate(http_requests_total[5m])'

Ця команда запитує частоту запитів HTTP протягом 5- х хвилинного вікна, яким можна скористатися для виявлення раптових підйомів у трафіку. Аналіз цього виводу — і розуміння наслідків функції rate() і вибраного часового вікна — так само важливо, як і виконання самої команди.