Моніторинг, APM і спостережуваність

Зміст

Прогін завершився: p95 виріс удвічі, зʼявилися помилки. Це симптом без адреси. бачить систему ззовні, як з одним числом на виході, тож звіт, який закінчується фразою «щось повільно», розробка не може ні відтворити, ні полагодити.

Другу половину картини дає моніторинг системи під тестом: які метрики просити, як їх читати під навантаженням і яким маршрутом іти від «повільно» до конкретної функції. Логи як щоденний інструмент, діагностика падінь і (observability) очима QA поза навантаженням — окрема глава розділу про Git і CI/CD: Логи, моніторинг і спостережуваність для QA.

Застосунок і залізо на одному графіку

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

Величина	Що це	У чому міряють
Утилізація ресурсу (resource utilization)	Середній час, протягом якого ресурс був зайнятий обслуговуванням роботи	Відсотки за інтервал: «диск працює на 90%»
Насичення (saturation)	Ступінь, до якого ресурс має додаткову роботу, якої не може обслужити — зазвичай черга	Довжина черги: «середня черга виконання чотири»
Помилки	Кількість подій-помилок	Скалярні лічильники: «пʼятдесят пізніх колізій»

Читають ці три числа не за принципом «зелене-червоне»:

100% утилізації — зазвичай ознака вузького місця, але проблемою може бути вже понад ~70%. Причина перша: вимір за довгий період ховає короткі сплески до 100%. Причина друга: деякі ресурси, як-от диски, не можна перервати посеред операції, тож після 70% в черзі стають частішими.
Будь-яке ненульове насичення варте уваги. Черга завдовжки один — це вже робота, якої ресурс не встиг зробити.
Негативний результат теж корисний: низька утилізація, немає черги, немає помилок — обсяг розслідування звузився.

Ресурс тут не лише залізо: метод прямо поширюється на мʼютекси (утилізація — час, поки лок утримувався; насичення — потоки в черзі на лок), пули потоків і ємність файлових дескрипторів. Це рівно ті місця, які канон перф-тестування називає причинами — недостатні пули ресурсів, пули потоків, зʼєднання з базою даних; серед технічних метрик прогону він називає процесор, памʼять, мережеву і затримку, дисковий простір, швидкість вводу-виводу, вільні й зайняті потоки. Там же — привʼязка, корисна на захисті звіту: утилізація — турбота системи, — користувача, — бізнесу.

Автор оцінює свій метод прагматично: близько 80% проблем сервера за 5% зусиль. Це перший прохід, після якого видно, куди копати далі — як саме, у главі Аналіз результатів і пошук вузьких місць.

Метод RED: три метрики на кожен сервіс

USE дивиться на ресурси. З боку застосунку той самий трюк робить (RED method) — він задає три метрики, які треба міряти для кожного мікросервісу:

Rate — кількість запитів за секунду, які обслуговують ваші сервіси;
Errors — кількість невдалих запитів за секунду;
Duration — розподіли часу, який займає кожен запит.

Третій пункт варто читати дослівно: автор пише «розподіли», а не «середнє». Це той самий аргумент, що й у главі Метрики: response time, throughput, перцентилі — просити треба . Друге правило автора: частота помилок має бути виражена як частка від частоти запитів; «100 помилок» без знаменника не означає нічого. А міряти всі сервіси однаково він радить з організаційних міркувань: однаковість дає масштабованість операційних команд, бо зменшує кількість особливих випадків, які черговий інженер мусить памʼятати під час інциденту.

USE і RED — не альтернативи, а два погляди на ту саму систему: перший про ресурси, другий про сервіси. Автор RED проговорює це сам: USE — чудовий спосіб думати про моніторинг ресурсів, але абстракція «трохи натягується», коли говоримо про сервіси. Він же називає : філософія перенесена з практики SRE в Google, де той самий набір звуть чотирма золотими сигналами — там до трьох метрик RED додано насичення, яке автор свідомо не включив як складніший випадок.

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

Інструментування: звідки беруться числа

Метрика не зʼявляється сама — її туди хтось поклав. (instrumentation) — це додавання метрик у код сервісу, і канонічна настанова тут максималістська: інструментуйте все, кожна бібліотека, підсистема й сервіс мають мати щонайменше кілька метрик. Джерело чесно називає себе набором думок, а не вимогою, — але для QA це найповніший перелік того, що просити перед прогоном. Набір залежить від типу сервісу:

Тип	Ключові метрики
Онлайн-обслуговування — хтось чекає негайної відповіді	Кількість виконаних запитів, помилки, затримка; корисна ще кількість запитів у роботі
Офлайн-обробка — ніхто активно не чекає	Скільки прийшло, скільки в роботі, коли востаннє щось оброблено, скільки відправлено
Пакетні задачі — не працюють безперервно	Головна метрика: коли задача востаннє відпрацювала успішно

Окремо канон називає підсистеми, які найчастіше й виявляються вузьким місцем. Пул потоків: запити в черзі, зайняті й загальні потоки, скільки задач оброблено і як довго — і окремо скільки речі чекали в черзі. Кеш: запити, влучання, затримка плюс метрики тієї системи, перед якою кеш стоїть. до БД: метрики мають розрізняти бази. Помилки рахують у парі зі спробами — без знаменника частки не буде. І дві настанови з прямим наслідком для тестувальника: системи онлайн-обслуговування моніторять і з боку клієнта, і з боку сервера, а розбіжність між ними — дуже корисна інформація (саме тому час у звіті генератора й час на дашборді законно різняться), а запити рахують на завершенні, інакше вони не зібʼються зі статистикою помилок і затримки.

Далі числа треба зібрати й показати — і це два різні предмети. Prometheus збирає й зберігає метрики як часові ряди — значення з міткою часу й необовʼязковими мітками — через HTTP; візуалізацію зібраних даних дока віддає Grafana або іншим API. Grafana формулює свою роль симетрично: запитувати, візуалізувати, сповіщати й досліджувати ваші метрики, логи й , хоч би де вони зберігалися. Тож «поставимо Prometheus і Grafana» — це не одне рішення, а два.

Вибір між SDK і автоматичним інструментуванням через агента не косметичний: перше вимагає змін у коді й релізу, друге ні. Ціна виміру названа теж: витрата ресурсів на інструментування значно переважується вигодами, а обережність потрібна для коду, критичного до продуктивності або викликаного понад 100 тисяч разів за секунду в межах процесу. Тобто аргумент «моніторинг сповільнить систему» каноном не підтверджується. Виклад APM додає дзеркальну тезу — вимір створює накладні витрати, і їх зменшують кількістю подій, що моніторяться; джерело тут неканонічне (див. наступний розділ), тож це спостереження, а не норма.

Типи метрик: лічильник, датчик, гістограма, зведення

Просити «метрики» — це просити нічого. Бібліотеки інструментування пропонують чотири основні , і споріднений набір ужитий в інструменті навантаження k6 (Counter, Gauge, Rate, Trend), тож словник працює по обидва боки прогону:

Тип	Що це
Лічильник (counter)	Кумулятивна метрика, яка лише зростає або обнуляється при перезапуску
Датчик (gauge)	Єдине числове значення, яке може довільно рости й спадати
Гістограма (histogram)	Записує спостереження в налаштовні бакети й дає суму всіх значень
Зведення (summary)	Так само семплює спостереження, але рахує квантилі в рухомому часовому вікні

Правило вибору між першими двома — одне речення: якщо значення може падати, це датчик. Кількість одночасних запитів — датчик, загальна кількість запитів — лічильник. І два практичні наслідки: сирий лічильник читати марно, для нього беруть функцію rate(), щоб отримати частоту зростання за секунду; дзеркально — брати rate() від датчика не можна ніколи.

Гістограма проти зведення — не питання смаку. Гістограма розкладає спостереження в кумулятивні , і перцентилі з неї рахують уже на боці моніторингу функцією histogram_quantile(). Зведення рахує квантилі на боці застосунку, і такі квантилі між екземплярами не агрегуються; класичні гістограми з різними межами бакетів — теж. Висновок жорсткий: звести перцентилі двох сервісів із різними бакетами не можна, це питання даних, а не запиту.

Тип метрики живе в застосунку, а не в моніторингу: сервер Prometheus інформацію про тип поки не використовує, тож неправильно обраний тип — помилка на боці коду, і дашборд її не виправить. Те саме з мітками: кожен набір міток — це додатковий часовий ряд із витратами памʼяті, процесора, диска й мережі, тож канон радить тримати кардинальність нижче 10, а понад 100 — вважати приводом шукати інше рішення. Заборона названа поіменно: не використовувати мітки для вимірів із високою кардинальністю — ідентифікаторів користувачів, адрес пошти чи інших необмежених множин. Дві дрібниці іменування, які ламають звірку дашборда зі звітом прогону: час подають у секундах, а частку — у долях одиниці, не у відсотках.

APM: назва, під якою немає канону

(application performance management, APM) — термін, з яким треба поводитися обережно, і це не фігура мови. Канонічного джерела під нього немає: абревіатури не вводить ані силабус перф-тестування, ані стандарти телеметрії, а доступне означення дає лише енциклопедія — джерело неканонічне. Тож усе нижче — найкращий доступний виклад, а не норма.

За цим викладом APM — моніторинг і керування продуктивністю та доступністю програмних застосунків, щоб виявляти й діагностувати складні проблеми й утримати очікуваний рівень сервісу. Пильно моніторять два набори метрик: перший описує продуктивність, яку відчувають кінцеві користувачі (навантаження — , запитів чи сторінок за секунду — і час відповіді), другий міряє ресурси, витрачені на це навантаження, показуючи, чи достатньо ємності й де можливі вузькі місця. Виміри встановлюють емпіричний базовий рівень, який далі використовують для виявлення змін, — та сама пара «симптом і причина», з якої почалася глава. Там же — спостереження, що пояснює саме існування перф-тестування: без навантаження компʼютерними вимогами більшість застосунків достатньо швидкі, тому програмісти можуть не зловити проблем продуктивності під час розробки.

Три деталі, корисні на практиці:

Пасивний збір проти активного. Пасивний зазвичай безагентний, через дзеркалювання мережевого порту; активний — синтетичні проби, і вони дають видимість у непікові години, коли обсяг транзакцій малий.
Глибокий рівень вимагає агента, а моніторинг досвіду користувача може включати вставлення JavaScript у сторінку. «Увімкнути APM» — не зовнішня операція: вона зачіпає збірку й розгортання.
Віртуалізація збільшує мінливість вимірів — той самий чинник, що й шум спільного середовища в главі Середовище, генератори навантаження і достовірність, тільки з боку продакшену.

Чому канону немає, пояснює саме джерело: з першої половини 2013 року APM увійшов у період інтенсивної конкуренції постачальників, унаслідок чого термін розмився й перетворився на концепцію, а не на єдиний ринок; «рамку», яку зазвичай цитують, тримає аналітична фірма, і вона вже змінювала означення. Звідси висновок: «у нас APM» і «у нас observability» у двох командах можуть означати різне — уточнювати треба набір сигналів, а не назву.

Логи, метрики й трейси: три сигнали, три різні питання

Стандарт телеметрії називає три види даних прямо: трейси, метрики й логи. Це не синоніми й не рівні деталізації, а відповіді на різні питання: метрика каже скільки й як довго, лог — що саме сталося в конкретний момент, трейс — де в ланцюжку сервісів пішов час. OpenTelemetry позиціонує себе як галузевий стандарт — вендор-нейтральний фреймворк для інструментування, генерації, збору й експорту телеметрії; його Collector робить заміну бекенда питанням конфігурації, а не переінструментування.

Розподілений трейс (distributed tracing) — методологія, яку реалізують інструменти трейсингу, щоб простежити, проаналізувати й задебажити транзакцію крізь кілька програмних компонентів. Формат передачі контексту стандартизований W3C: заголовок traceparent містить чотири поля через дефіс — версію, trace-id (16 байтів, 32 шістнадцяткові символи в малому регістрі — ідентифікатор усього трейсу), parent-id (8 байтів — ідентифікатор цього запиту з погляду викликача) і прапорці. У багатьох системах трейсингу parent-id звуть span-id, а (span) — це виконання одного клієнтського запиту. Значення з усіх нулів невалідне, а невалідний trace-id інструменти зобовʼязані ігнорувати разом із усім заголовком — тож підставити «схоже» значення не вийде:

import { randomBytes } from 'node:crypto';

// 32 і 16 шістнадцяткових символів у малому регістрі; усі нулі — невалідне значення
const traceId = randomBytes(16).toString('hex');
const spanId = randomBytes(8).toString('hex');

// 01 у прапорцях означає «sampled», 00 — «not sampled»
await request.get('/api/orders', {
  headers: { traceparent: `00-${traceId}-${spanId}-01` },
});

Логи мають власну економіку, і вона впливає на те, що ви зможете знайти. Loki індексує лише мітки, а самі дані стискає й тримає чанками в обʼєктному сховищі — звідси дешевизна й наслідок: якщо потрібного розрізу немає в мітках, шукати доведеться повним сканом. Kibana — це UI платформи Elasticsearch, і її Discover, що дає працювати з сирими даними під фільтрами й пошуком, є точкою входу для дослідницького аналізу. Sentry описує себе через ту саму задачу: наскрізний розподілений трейс, щоб знаходити й дебажити проблеми продуктивності та помилки в різних системах і сервісах. Звідси й правило для баг-репорту після перф-прогону: посилання на конкретний запит або трейс корисніше за текстовий дамп логів.

Профілювання: від «повільно» до «де саме»

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

Дані профілювання подають графіками flame graph, таблицями й звичайними графіками. flame graph візуалізує звʼязки викликів і визначає гарячі точки — тобто відповідає на питання «хто кого викликав і де згорів час», якого таблиця метрик не ставить. Профілі корелюють з іншими сигналами в тій самій системі візуалізації, тож дивляться їх у вікні того самого інциденту, що й графік затримки.

Два профілювання плутати не можна. На клієнті ту саму роль виконує панель продуктивності браузера, і її предмет — продуктивність виконання, тобто поведінка сторінки, коли вона вже працює, на відміну від завантаження; там же застереження, що розширення браузера можуть створювати шум у вимірах. Висновки одного профілю на інший не переносять.

Типові помилки

«Середня утилізація процесора 70% — запас є». Виглядає як спокійний графік, а насправді вимір за довгий інтервал ховає короткі сплески до 100%, і саме в них живуть . Питання «яке вікно усереднення?» — обовʼязкове до будь-якого висновку про ресурси, і той самий чекліст — утилізація, черга, помилки — ставлять до кожного з них, включно з пулами.

«Графік лічильника впав — навантаження впало». Виглядає як спад трафіку, а насправді лічильник обнуляється при перезапуску процесу: різке падіння графіка означає рестарт. І дзеркально — сирий лічильник без rate() не показує нічого корисного.

«p95 у звіті генератора не збігається з p95 на дашборді — хтось бреше». Виглядає як дефект вимірювання, а насправді законних причин кілька: міряють із різних боків (і розбіжність клієнта з сервером — корисна інформація), а перцентилі зі зведень різних екземплярів і гістограм із різними бакетами не агрегуються в принципі. Третя причина банальніша: одна сторона рахує в секундах, друга в мілісекундах.

«Алерт на помилки мовчить — значить помилок немає». Виглядає як здоровʼя, а насправді часового ряду може просто не існувати, доки нічого не сталося, і правило поверх нього мовчить саме тоді, коли має спрацювати. Лікується експортом нуля для будь-якого ряду, який може зʼявитися.

«На стейджі рівний процесор — середовище чисте». Виглядає як стабільність, а насправді на спільних ресурсах — надто у віртуалізованих середовищах — є фонове навантаження, яке канон називає окремим чинником достовірності.

Підсумок

Симптом і причина живуть на різних графіках. RED дає три числа на кожен сервіс, USE — три числа на кожен ресурс. Це пара, а не альтернатива.
Тип метрики — частина запиту до розробки. Лічильник, датчик, гістограму чи зведення обирають у коді, і неправильний вибір моніторинг не виправить.
Збір і показ — два різні предмети. Prometheus витягує й зберігає часові ряди, Grafana їх показує.
APM канонічного означення не має. Це ринкова назва набору практик, тож уточнюють набір сигналів — метрики, логи, трейси, профілі, — а не назву.
Профіль не замінює метрик — він наступний крок після них. Канон описує рух від загальносистемної спостережуваності до дієвих висновків на рівні коду, а чекліст ресурсів називає першим проходом, після якого йде заглиблення.

Можливі питання

«Які метрики ви попросите в розробки перед навантажувальним прогоном?» Дивляться, чи є у вас структура замість переліку навмання. Сильна відповідь має дві половини: на кожен сервіс — частота, помилки й розподіл тривалості; на кожен ресурс — утилізація, довжина черги й лічильники помилок. Окремо — пул потоків і пул зʼєднань до БД.

«Чим RED відрізняється від USE?» Класична пара на плутанину. RED — про сервіси, керовані запитами; USE — про ресурси. Плюс межі: для пакетних і потокових сервісів RED не працює, і це каже сам його автор.

«Що таке APM?» Перевіряють не завчене означення, а чесність. Канонічного означення в терміна немає — це ринкова назва набору практик, і «у нас APM» у двох командах може означати різні набори сигналів.

«Чим лог відрізняється від метрики й від трейсу?» Очікують розведення за питанням, а не за форматом: метрика відповідає «скільки й як довго», лог — «що сталося в цей момент», трейс — «де в ланцюжку сервісів згорів час». Плюс бал за згадку, що контекст трейсу переносять стандартним заголовком.

«У звіті генератора p95 дорівнює 800 мс, а на дашборді 500 мс. Хто правий?» Дивляться, чи кинетеся ви шукати винного. Правильна реакція — назвати законні причини розбіжності: вимір із різних боків і неагрегованість квантилів зі зведень та різних бакетів. Далі питання не «хто правий», а «яке число описує користувача».

«Коли ви попросите профіль, а не метрики?» Хочуть почути порядок дій: коли метрики вже показали насичення ресурсу, але не показали причини.

Джерела

Застосунок і залізо на одному графіку

Brendan Gregg — The USE Method — означення методу, утилізації, насичення й помилок, одиниці виміру, правила читання значень і поширення на програмні ресурси.
ISTQB® CT-PT — Foundation Level Specialist Syllabus, Performance Testing v1.0 (2018) — перелік технічних метрик прогону, пули ресурсів і зʼєднання з БД як причини відмов, привʼязка метрик до стейкхолдерів.

Метод RED: три метрики на кожен сервіс

Tom Wilkie — The RED Method: key metrics for microservices architecture (2017) — три метрики методу, від частоти, організаційний аргумент, походження від золотих сигналів SRE і межі методу.
Brendan Gregg — The USE Method — означення методу USE, з яким автор RED розводить свій метод: ресурси проти сервісів.
Prometheus — Instrumentation — той самий поділ із боку доки: різні набори метрик для обслуговування запитів і для офлайн-обробки.

Інструментування: звідки беруться числа

Prometheus — Instrumentation — настанова «інструментуйте все», три типи сервісів і їхні набори метрик, метрики пулів і кешу, вимір з обох боків, облік запитів на завершенні, ціна інструментування.
Prometheus — Overview — часові ряди з мітками, pull-модель через HTTP і передача візуалізації Grafana чи іншим споживачам API.
Grafana — documentation home (OSS and Enterprise) — роль Grafana: запитувати, візуалізувати, сповіщати й досліджувати метрики, логи й трейси.
Grafana Pyroscope — documentation home — два шляхи інструментування: SDK у коді проти автоматичного інструментування агентом.
Wikipedia — Application performance management — накладні витрати вимірювання та їх зменшення кількістю подій, що моніторяться (джерело неканонічне).

Типи метрик: лічильник, датчик, гістограма, зведення

Prometheus — Metric types — чотири типи метрик і їхні означення, кумулятивні бакети гістограми, квантилі зведення в рухомому вікні, неагрегованість різних бакетів, обнулення лічильника при перезапуску.
Prometheus — Instrumentation — правило «якщо значення може падати, це датчик», rate() для лічильників, заборона rate() для датчика, ціна кожного набору міток і орієнтири кардинальності.
Prometheus — Metric and label naming — поіменна заборона міток високої кардинальності, час у секундах і частка в долях одиниці.
Prometheus — Histograms and summaries — механіка обчислення квантиля з бакетів і межі його точності.
Grafana k6 — Metrics — споріднений набір типів метрик на боці інструмента навантаження.

APM: назва, під якою немає канону

Wikipedia — Application performance management — означення й мета APM, два набори метрик і базовий рівень, активний і пасивний збір, вимога агента для глибокого рівня, розмивання терміна конкуренцією вендорів (джерело неканонічне: канонічного під цей термін не існує).

Логи, метрики й трейси: три сигнали, три різні питання

OpenTelemetry — Documentation (головна) — три види телеметрії, позиція галузевого стандарту й роль Collector як вендор-агностичного шару.
OpenTelemetry — Traces — трейси як окремий сигнал спостережуваності.
W3C — Trace Context (Recommendation) — розподілений трейс як методологія, формат traceparent, довжини trace-id і parent-id, span-id як інша назва parent-id, спан як виконання одного клієнтського запиту, обовʼязок ігнорувати невалідне значення.
Grafana Loki — Documentation (огляд) — індексація лише міток, чанки в обʼєктному сховищі й вплив розмітки на швидкість запитів і ціну.
Elastic Docs — Explore and analyze data with Kibana — Kibana як UI Elasticsearch і Discover як точка входу для дослідницького аналізу.
Sentry Docs — головна — самопозиціювання продукту через наскрізний розподілений трейс.

Профілювання: від «повільно» до «де саме»

Grafana Pyroscope — documentation home — означення безперервного профілювання з роздільністю до рядка коду, рух від загальносистемної спостережуваності до коду, форми подачі даних і кореляція з іншими сигналами.
Brendan Gregg — USE Method: Linux Performance Checklist — чекліст ресурсів як перший прохід, після якого переходять до заглиблення й аналізу затримки.
Chrome DevTools — Analyze runtime performance — предмет панелі продуктивності: виконання, а не завантаження; розширення як джерело шуму у вимірах.

Навіщо під час навантажувального прогону дивитися ще й метрики системи, якщо генератор уже дав p95 і відсоток помилок?

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

Що таке метод USE і що саме він вимагає перевірити?

USE — методологія аналізу продуктивності, яка перетворює безсистемне тикання в графіки на короткий чекліст: пройтися всіма ресурсами системи й для кожного зняти три числа — утилізацію, та помилки. Утилізація — частка часу, протягом якої ресурс був зайнятий обслуговуванням роботи, і міряють її у відсотках за інтервал. Насичення — обсяг роботи, яку ресурс не встиг обслужити, тобто зазвичай довжина черги. Помилки — звичайний лічильник збійних подій. Метод не привʼязаний до технології: той самий чекліст однаково лягає на процесор, диск і мережу. Автор оцінює віддачу тверезо — це перший прохід, який ловить більшість серверних проблем малою часткою зусиль, після чого починається справжнє заглиблення. Для QA це готовий шаблон запиту до девопсів ще до старту прогону.

Чим насичення відрізняється від утилізації і чому черга — чутливіший сигнал?

Утилізація каже, наскільки ресурс був зайнятий, насичення — скільки роботи вишикувалося в чергу, бо він не встигав. Це різні величини й різні одиниці: перша у відсотках, друга — довжина черги. Ресурс може бути завантажений під зав'язку й при цьому не мати черги — тоді всі встигають. А от навіть черга завдовжки один означає, що якась робота вже чекає, і це очікування прямо конвертується в користувача. Тому ненульове насичення заслуговує на увагу незалежно від того, як гарно виглядають відсотки. На практиці першими себе показують саме черги в пулах — потоків і зʼєднань до бази.

Чому утилізація 70% може бути проблемою, якщо до 100% ще далеко?

Бо 70% — це майже завжди середнє за якийсь інтервал, а середнє ховає форму навантаження. Рівні 70% протягом хвилини й пилка «повний стоп на 100% пів секунди, потім простій» дають однакове число, але друга картина вже породжує . Друга причина фізична: операцію на деяких ресурсах, наприклад на диску, не можна перервати посеред виконання, тож із наближенням до цієї межі запити частіше змушені чекати в черзі. Звідси практичне правило: до будь-якого висновку про ресурс спершу питають, за яким вікном усереднено графік. І дивляться не на відсоток окремо, а на пару «відсоток плюс черга».

Що таке метод RED і чим він корисний, коли сервісів десятки?

RED — набір із трьох метрик, які знімають з кожного сервісу: rate (скільки запитів за секунду він обслуговує), errors (скільки з них падає за секунду) і duration (розподіл часу, який займає запит). Третій пункт читають дослівно: автор пише про розподіли, а не про середнє, тобто просити треба . Друге правило — помилки подають як частку від частоти запитів: «сто помилок» без знаменника не означає нічого, бо сто на мільйон і сто на двісті — різні всесвіти. Головний аргумент за однаковість не технічний, а організаційний: коли всі сервіси міряють одним набором, черговому інженеру під час інциденту не треба памʼятати десяток особливих випадків. Для QA це означає, що запит «дайте RED по сервісах на час прогону» зрозумілий будь-якій команді без пояснень.

Чим RED відрізняється від USE і де RED перестає працювати?

Це не конкуренти, а дві проєкції однієї системи: USE описує ресурси, RED — сервіси. Автор RED пояснює свій метод саме так: підхід USE чудовий для ресурсів, але абстракція надто розтягується, коли предметом стає сервіс. Практичний наслідок — на дашборді потрібні обидва шари: RED покаже, який сервіс дає зростання тривалості, USE — який ресурс під ним уперся. А межі RED автор називає сам — і саме вони роблять відповідь сильною: метод має сенс тільки там, де сервісом керують запити, а на пакетних чи потокових розсипається. Дока Prometheus проводить межу так само: там, де хтось чекає відповіді, міряють виконані запити, помилки й , а для офлайн-обробки — обсяг, що надійшов, обсяг у роботі, час останньої успішної обробки й обсяг, відданий далі.

Що таке чотири золоті сигнали і як вони співвідносяться з RED?

Чотири золоті сигнали — набір метрик із практики SRE в Google, звідки RED і виріс. Різниця рівно в одному пункті: до частоти, помилок і тривалості там додано насичення. Автор RED свідомо його не взяв — вважав складнішим випадком. Тобто RED — це золоті сигнали мінус насичення, а не інша філософія. На практиці насичення все одно доводиться дивитися, просто воно приходить з боку USE — через черги ресурсів і пулів.

Що конкретно ви попросите в розробки, щоб під час прогону було на що дивитися?

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

Чим лічильник (counter) відрізняється від датчика (gauge) і як не помилитися з вибором?

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

Навіщо для лічильника беруть `rate()` і чому цю ж функцію заборонено брати від датчика?

Сирий лічильник — це монотонна лінія, яка вічно повзе вгору; питання «чи виросло навантаження» вона не відповідає. Тому дивляться не саме значення, а швидкість його зростання за секунду — це й робить rate(), перетворюючи «всього мільйон запитів» на «чотириста запитів за секунду». Датчик і так уже показує поточне значення, і в нього падіння — це нормальний стан, а не перезапуск; узяти від нього швидкість зростання означає отримати число, яке не має фізичного змісту. Практично: побачили rate() навколо метрики черги — на дашборді помилка.

Чим гістограма відрізняється від зведення (summary) і чому це важливо для перцентилів?

Гістограма розкладає спостереження по заздалегідь налаштованих кумулятивних і додатково дає суму всіх значень; сам перцентиль виводять пізніше, вже в моніторингу, спеціальною функцією над цими бакетами. Зведення теж семплює спостереження, але квантилі обчислює на боці застосунку в рухомому часовому вікні й віддає вже готовими числами. Різниця дає прямий наслідок: готові квантилі зі зведень різних екземплярів між собою не складаються, і так само не складаються гістограми, у яких межі бакетів різні. Тобто вибір типу вирішує, чи зможете ви колись отримати чесний загальний p95 по сервісу. Заднім числом це не виправляється: бакети домовляють до прогону, а не після нього.

На дашборді три поди одного сервісу. Чому не можна взяти середнє їхніх p95 і назвати це p95 сервісу?

Тому що перцентиль — не величина, яку можна усереднювати: він рахується з розподілу, а середнє трьох чисел про розподіл нічого не знає. Формально це видно з механіки типів: якщо кожен под віддає готовий квантиль зі зведення, вихідних спостережень уже немає, зводити нема з чого. З гістограмами шанс є, але лише поки в усіх екземплярів однакові межі бакетів — тоді бакети складаються поелементно й перцентиль рахується вже з суми. Якщо межі різні, задача не має розвʼязку на боці запиту: це проблема даних, а не PromQL. Практичний висновок для QA: коли просите перцентилі по сервісу, одразу питайте, чи однаково інструментовані екземпляри.

Чому мітки з високою кардинальністю — це проблема, а не зручність?

Кожна унікальна комбінація міток породжує окремий часовий ряд, а кожен ряд коштує памʼяті, процесора, диска й мережі. Поки значень мітки десяток, це дрібниця; коли мітка — ідентифікатор користувача, адреса пошти чи довільний URL, кількість рядів росте разом із трафіком і збиває моніторинг швидше, ніж це зробить тестований застосунок. Канон дає орієнтири прямо: тримати кардинальність нижче десяти, а понад сотню вважати приводом шукати інший підхід замість мітки. Заборона названа поіменно саме для необмежених множин. Для розслідування конкретного запиту існує інший сигнал — або лог, і саме туди кладуть ідентифікатори.

Що бере на себе Prometheus, а що Grafana?

Це два різні предмети, і плутанина тут дорого коштує в розмові з інфраструктурою. Prometheus накопичує числа у вигляді часових рядів: кожне значення має позначку часу й набір міток, а працює він — сам ходить по HTTP і забирає показники з інструментованих сервісів. Візуалізацію він на себе не бере й віддає її Grafana чи іншим свого API. Grafana ж описує свою роль симетрично: запитувати, показувати, сповіщати й досліджувати метрики, логи та трейси незалежно від того, де вони зберігаються. Тому «у нас є Grafana» ще не означає, що потрібні вам метрики хтось збирає, і навпаки.

Що таке APM і чому тут не варто відповідати завченим означенням?

APM (application performance management) — керування продуктивністю й доступністю застосунків: моніторити систему так, щоб складні проблеми знаходили й розбирали до того, як обіцяний рівень сервісу просяде. Пильно дивляться два набори чисел: те, що відчуває кінцевий користувач (навантаження в чи запитах за секунду й час відповіді), і ресурси, витрачені на це навантаження, — тобто чи є ще ємність і де вона закінчується. Виміри дають емпіричний базовий рівень, відносно якого потім видно зміни. Але сильна відповідь тут не про означення, а про чесність: канонічного джерела під термін немає — його не знає ні силабус перф-тестування, ні стандарти телеметрії, а сам термін розмився під час конкуренції вендорів, коли кожен продавав під цією назвою свій набір. Практичний висновок: почувши «у нас APM», уточнюють не назву, а що саме туди входить: метрики, логи, трейси чи ще й профілі.

Метрика, лог і трейс — на які різні питання вони відповідають?

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

Що таке розподілений трейс і як контекст трейсу переїжджає між сервісами?

Розподілений трейс — методологія, яка дозволяє простежити й задебажити одну транзакцію крізь кілька компонентів системи. Технічно це працює через передачу контексту в заголовку запиту, і формат тут стандартизований W3C: у traceparent через дефіс ідуть чотири поля — версія, далі trace-id, parent-id і прапорці. trace-id завдовжки 16 байтів (32 символи шістнадцяткового запису малими літерами) ідентифікує весь трейс, а parent-id завдовжки 8 байтів — конкретний запит з погляду того, хто його викликав; у багатьох системах трейсингу його називають span-id, а самим звуть виконання одного клієнтського запиту. Дрібниця, на якій ламаються саморобні експерименти: ідентифікатор із самих нулів вважається невалідним, і тоді інструмент мусить відкинути весь заголовок, тож «схоже на правду» не спрацює. Практична вигода для автотестів пряма: якщо тест шле власний traceparent і кладе його в звіт, будь-який червоний прогін одразу має адресу в системі трейсингу.

Генератор показує p95 = 800 мс, дашборд сервісу — 500 мс. Хто бреше?

Питання перевіряє, чи кинетеся ви шукати винного замість пояснення. Законних причин розбіжності щонайменше три. Перша: числа зняті з різних боків — генератор міряє повний шлях разом із мережею та чергою на вході, сервер рахує лише свою частину; ця розбіжність не дефект, а корисна інформація, і канон прямо радить моніторити онлайн-сервіси з обох боків. Друга: перцентилі на дашборді могли зʼїхати при зведенні кількох екземплярів — готові квантилі зі зведень і гістограми з різними бакетами не агрегуються. Третя, найбанальніша: один бік вимірює в секундах, другий — у мілісекундах, бо конвенція іменування метрик вимагає секунд, а генератори звикли до мілісекунд. Далі варто питати не про правоту сторін, а про те, котре з цих чисел описує досвід користувача — саме воно йде у звіт, решта в діагностику.

Графік лічильника різко впав до нуля. Що це найімовірніше означає?

Не падіння трафіку, а перезапуск процесу: лічильник обнуляється при рестарті за визначенням, тому вертикальний обрив — це подія в житті інстансу, а не в поведінці користувачів. Перевіряють це за хвилину: подивитися на графік аптайму або на кількість перезапусків подів у тому самому вікні. До речі, саме тому сирий лічильник на дашборді майже завжди помилка оформлення: на питання про навантаження відповідає не накопичене значення, а швидкість його зростання, тобто rate(). Дзеркальна пастка того ж роду: алерт на помилки мовчить не тому, що помилок немає, а тому, що часового ряду ще не існує, доки жодної помилки не сталося. Лікується це просто: ряд, який колись може зʼявитися, експортують одразу з нулем.

Коли ви попросите профіль, а не метрики?

Коли метрики свою роботу вже зробили: показали, який сервіс дає тривалість і який ресурс під ним насичений, але не сказали, чому саме ресурс так витрачається. — сигнал спостережуваності, який доводить розслідування до номера рядка вихідного коду, і від класичного профайлера відрізняється тим, що збір іде безперервно на бойовій системі, а не в момент, коли інженерові пощастило відтворити проблему. Дивляться профіль у вікні того самого інциденту, що й графік затримки, — інакше він показує середню температуру. Подають дані переважно графіком flame graph: він показує дерево викликів і місце, де витрачено час, — питання, якого таблиця метрик узагалі не ставить. Порядок кроків у сильній відповіді звучить так: сервіс, потім ресурс, потім трейс запиту, і лише потім профіль — профіль метрик не скасовує, він іде наступним поверхом після них. І ще одне: серверний профіль і панель продуктивності браузера — різні предмети, висновки з одного на інший не переносять.

Три ситуації, у яких моніторинг перетворює «щось повільно» на адресу: дашборд під час прогону, де RED і USE читають в одному вікні; суперечка про два різні p95 і таблиця законних причин розбіжності; і Playwright, яка кладе ідентифікатор у звіт, щоб червоний тест приходив у розробку з посиланням, а не з описом відчуттів.

Кейс 1. Дашборд під час прогону: сервіс і ресурси в одному часовому вікні

Прогін на 400 , p95 на боці генератора виріс із 600 мс до 2,4 с. Перш ніж писати баг, знімаємо два шари метрик за одне й те саме пʼятихвилинне вікно на піку. Верхній шар — RED по сервісу, нижній — USE по ресурсах під ним.

Сервіс checkout-api — RED, вікно 5 хв (пік прогону 21:40–21:45)
  rate        412 req/s
  errors       23.7 req/s   → 5.8% від rate
  duration     p50 140 ms | p95 2 400 ms | p99 9 800 ms

Ресурси під ним — USE, те саме вікно
  CPU app-node       utilization 58%        saturation (runq)  0.4    errors 0
  Пул зʼєднань до БД  utilization 20/20 busy saturation (черга) 37     errors 12 (timeout)
  Диск db-node       utilization 94%        saturation (черга) 6.1    errors 0
  Пул потоків app    utilization 78/100      saturation (черга) 0      errors 0

Що дивитися і чому:

Помилки без знаменника нічого не значать, з ним — значать одразу. 23,7 помилки за секунду звучить абстрактно, 5,8% від трафіку — це вже привід не пускати реліз. Саме тому вимагає подавати помилки часткою від частоти запитів, а не абсолютним лічильником: та сама цифра при 40 req/s означала б катастрофу, а при 4 000 — фон.
Процесор 58% — це негативний результат, і він теж корисний. Пошук звузився: верхній шар застосунку не впирається в такт. Але перш ніж викреслювати ресурс остаточно, питають вікно усереднення — рівні 58% за пʼять хвилин і пилка зі сплесками до 100% на секунду дають однакове число, а поводяться по-різному.
до БД — ось де живе проблема. Двадцять із двадцяти зайнято, у черзі 37 запитів, дванадцять . «20 з 20» — це утилізація 100%, і канон читає її як ознаку вузького місця, яку підтверджують : черга завдовжки 37 означає роботу, яка вже чекає, і це очікування напряму сидить у хвості . Пул — рівно той ресурс, який канон перф-тестування називає типовою причиною , і на USE-чекліст він лягає так само, як залізо.
Диск під базою на 94% з чергою 6,1 пояснює, чому пул не звільняється. Ланцюжок читається знизу вгору: повільний диск тримає зʼєднання довше, зʼєднання закінчуються, запити чекають у черзі пулу, користувач бачить двосекундний хвіст. Пул потоків застосунку при цьому чистий (78 зі 100, черги немає) — його з розслідування виводимо.
Обидва шари мають бути з одного вікна. Найпоширеніший спосіб зробити хибний висновок — узяти RED на піку, а USE за годину, коли система вже відпочила. Тоді сервіс виглядає хворим, а ресурси здоровими, і розслідування йде в нікуди.

Далі маршрут стандартний і без стрибків: RED показав сервіс, USE показав ресурс, наступний крок — трейс одного повільного запиту, щоб побачити, який виклик усередині зʼїв ті дві секунди, і лише потім профіль, якщо виявиться, що час згорів у самому коді, а не в очікуванні бази.

Кейс 2. «Звіт каже 800 мс, дашборд — 500 мс» — хто правий

Перф-інженер приносить звіт із p95 у 800 мс, розробник відкриває Grafana й бачить 500 мс, і далі пів години сперечаються, чий інструмент бреше. Насправді жоден: у цієї розбіжності є кілька законних причин, і кожна перевіряється за кілька хвилин.

Що бачимо	Законна причина	Як перевірити
Клієнтське число стабільно більше за серверне	Міряють з різних боків: генератор бачить мережу, чергу на вході й час на балансувальнику, сервіс — лише свою роботу	Знайти на дашборді метрику, зняту з боку клієнта; якщо її немає — попросити, бо розбіжність двох боків сама по собі корисна
Дашборд показує `0.5`, звіт — `500`	Різні одиниці: конвенція іменування метрик вимагає секунд, генератори звикли до мілісекунд	Подивитися суфікс імені метрики й одиницю на осі панелі
«Загальний p95 сервісу» зібраний із кількох подів	Готові квантилі зі зведень не складаються; не складаються й гістограми, у яких межі бакетів різні	Спитати тип метрики; для гістограми звірити, чи однакові бакети в усіх екземплярів
Числа сходяться на графіку, але не в підсумку звіту	Різні вікна усереднення: панель за пʼять хвилин проти зведення за весь прогін	Зафіксувати одне вікно й порівняти в ньому

Що дивитися і чому:

Перше питання не про правоту інструментів, а про те, котре число описує досвід користувача. У звіт іде клієнтське: користувач чекає повний шлях, а не серверну частину. Серверне лишається в діагностиці — воно каже, скільки з цього часу застосунок може виправити сам.
Різниця клієнта й сервера — це вимір, а не дефект. Коли вона стабільна й невелика, це нормальна ціна мережі. Коли вона росте разом із навантаженням, розслідувати треба саме її: черга на вході, балансувальник, вичерпані зʼєднання — усе це живе рівно в цьому проміжку.
Неагреговані не лікуються запитом. Якщо кожен под віддає готовий квантиль, вихідних спостережень уже не існує й зводити нема з чого. Це домовленість на етапі інструментування: або спільні межі у гістограмі, або чесна відповідь «загального p95 у нас немає».
Якщо на дашборді сирий лічильник помилок — звіряти нема з чим. Частота потрібна обом сторонам, бо звіт прогону оперує помилками за секунду й відсотком, а не сумою за весь час.

Кейс 3. Playwright: тест, який приносить у баг-репорт адресу трейсу

Найдорожча частина розслідування — знайти в системі трейсингу саме той запит, який упав. Якщо тест сам генерує контекст трейсу й кладе його в звіт, шукати не доведеться: ідентифікатор уже в артефактах прогону.

import { test as base, expect, type APIRequestContext } from '@playwright/test';
import { randomBytes } from 'node:crypto';

// 32 і 16 шістнадцяткових символів у малому регістрі; значення з самих нулів невалідне
const newTraceId = () => randomBytes(16).toString('hex');
const newSpanId = () => randomBytes(8).toString('hex');

type Fixtures = { traceId: string; tracedRequest: APIRequestContext };

export const test = base.extend<Fixtures>({
  traceId: async ({}, use, testInfo) => {
    const id = newTraceId();
    // анотація потрапляє у звіт незалежно від того, зелений тест чи червоний
    testInfo.annotations.push({ type: 'trace', description: id });
    await use(id);
  },

  tracedRequest: async ({ playwright, traceId }, use) => {
    const ctx = await playwright.request.newContext({
      baseURL: 'https://app.example.com',
      // 01 у прапорцях означає «sampled», 00 — «not sampled»
      extraHTTPHeaders: { traceparent: `00-${traceId}-${newSpanId()}-01` },
    });
    await use(ctx);
    await ctx.dispose();
  },
});

Тепер сам тест: перевіряємо бюджет часу, а в повідомленні одразу лишаємо адресу для розслідування.

test('оформлення замовлення вкладається в бюджет часу', async ({ tracedRequest, traceId }) => {
  const started = Date.now();
  const res = await tracedRequest.post('/api/orders', { data: { sku: 'A-1042', qty: 1 } });
  const elapsed = Date.now() - started;

  expect(res.status()).toBe(201);

  // повернення ідентифікатора трейсу у відповіді — поширена командна домовленість, а не вимога стандарту
  const echoed = res.headers()['x-trace-id'];
  if (echoed) expect(echoed).toBe(traceId);

  expect(elapsed, `бюджет 1500 мс перевищено; трейс ${traceId}`).toBeLessThan(1500);
});

Що дивитися і чому:

Формат заголовка не терпить самодіяльності. Чотири поля через дефіс, trace-id рівно з 32 шістнадцяткових символів у малому регістрі, parent-id — з 16. Невалідне значення інструменти зобовʼязані проігнорувати разом з усім заголовком, тож підставлений «читабельний» ідентифікатор на кшталт імені тесту просто зникне, і трейсу ви не знайдете.
Анотація важливіша за лог у . Ідентифікатор має вижити в артефактах CI: у звіті, в назві прикріпленого файлу, у тілі тікета. Трейс, який бачив лише stdout зниклого , дорівнює відсутньому трейсу.
Порівняння часу в тесті — це не перф-тест. Одне число з одного запуску нічого не доводить про продуктивність: воно ловить грубу (секунди замість мілісекунд) і дає привід відкрити трейс. Висновки про p95 роблять із прогону навантаження, а не з функціонального асерту.
Не кладіть у мітки метрик те, що згенерував тест. Ідентифікатор трейсу чи прогону в мітці — це необмежена множина значень, тобто новий часовий ряд на кожен запуск. Такі речі місце мають у трейсах і логах, а не у вимірах.
Перевірка відлуння заголовка — необовʼязкова частина. Стандарт описує перенесення контексту між сервісами, а не повернення його клієнту; якщо ваша команда так домовилася, асерт дешево ловить сервіси, які загубили контекст по дорозі.

Симптом і причина: USE і RED

Розумію, чому число з генератора описує симптом, а метрика ресурсу — причину, і чому поодинці вони майже нічого не варті.
Знаю метод USE напамʼять: на кожен ресурс — утилізація, , помилки — і можу сказати, у чому міряють кожне з трьох.
Можу пояснити, чому ненульова черга тривожніша за високий відсоток завантаження і чому утилізація близько 70% уже підозріла: усереднення ховає сплески, а неперервні операції додають чекання.
Памʼятаю, що ресурс тут не лише залізо: пули потоків, до БД, ліміти файлових дескрипторів і локи проходять по тому самому чеклисту.
Знаю (rate, errors, duration на кожен сервіс) і розумію, чому duration беруть розподілом, а помилки — часткою від частоти запитів.
Знаю, де RED незастосовний — на пакетних і потокових сервісах, — і що чотири золоті сигнали є той самий набір плюс насичення.

Інструментування: звідки беруться числа

Можу подати запит до розробки списком метрик, а не проханням «дайте графіки», і знаю розгорнутий набір для пулу потоків: зайняті й загальні потоки, довжина черги й час очікування в ній.
Памʼятаю три правила обліку: помилки рахують у парі зі спробами, запити інкрементують на завершенні, а онлайн-сервіси міряють з обох боків — і розбіжність клієнта із сервером тут корисна, а не дефектна.
Не плутаю збір і показ: Prometheus витягує по HTTP і зберігає часові ряди, Grafana їх запитує, малює й алертить.

Типи метрик і мітки

Знаю чотири і правило вибору: якщо значення може падати — датчик, якщо лише накопичується — лічильник.
Розумію, навіщо лічильнику rate() і чому застосовувати ту саму функцію до датчика — завжди помилка.
Можу пояснити різницю гістограми й зведення і чому квантилі зі зведень та гістограми з різними не агрегуються: це проблема даних, а не запиту.
Розумію ціну міток (кожен унікальний набір — окремий часовий ряд), чому ідентифікатори користувачів у мітки не кладуть і чому конвенція «час у секундах» вирішує, чи зійдуться дашборд зі звітом прогону.

APM, сигнали й трейсинг

Можу чесно сказати, що канонічного означення APM не існує, і знаю два набори метрик, які під цією назвою дивляться: досвід користувача й витрачені на нього ресурси.
Розводжу три сигнали за питанням: метрика — скільки й як довго, лог — що сталося в цей момент, — де в ланцюжку згорів час.
Знаю склад заголовка traceparent і що невалідне значення інструменти зобовʼязані відкинути разом з усім заголовком.

Профілювання й маршрут розслідування

Знаю послідовність кроків від скарги на повільність до конкретного рядка коду: сервіс за RED, ресурс за USE, трейс запиту, профіль — і не перестрибую сходинки.
Можу пояснити, чим відрізняється від класичного профайлера, і не плутаю серверний профіль із панеллю продуктивності браузера.

Типові пастки при звірці чисел

Можу назвати три законні причини розбіжності p95 генератора й дашборда: різні боки виміру, неагреговані , різні одиниці часу.
Знаю, що вертикальний обрив лічильника до нуля означає перезапуск процесу, а мовчазний алерт на помилки — часовий ряд, якого ще не існує.

Знайшли помилку?

Моніторинг, APM і спостережуваність

Застосунок і залізо на одному графіку

Метод RED: три метрики на кожен сервіс

Інструментування: звідки беруться числа

Типи метрик: лічильник, датчик, гістограма, зведення

APM: назва, під якою немає канону

Логи, метрики й трейси: три сигнали, три різні питання

Профілювання: від «повільно» до «де саме»

Типові помилки

Підсумок

Можливі питання

Джерела

Навіщо під час навантажувального прогону дивитися ще й метрики системи, якщо генератор уже дав p95 і відсоток помилок?

Що таке метод USE і що саме він вимагає перевірити?

Чим насичення відрізняється від утилізації і чому черга — чутливіший сигнал?

Чому утилізація 70% може бути проблемою, якщо до 100% ще далеко?

Що таке метод RED і чим він корисний, коли сервісів десятки?

Чим RED відрізняється від USE і де RED перестає працювати?

Що таке чотири золоті сигнали і як вони співвідносяться з RED?

Що конкретно ви попросите в розробки, щоб під час прогону було на що дивитися?

Чим лічильник (counter) відрізняється від датчика (gauge) і як не помилитися з вибором?

Навіщо для лічильника беруть rate() і чому цю ж функцію заборонено брати від датчика?

Чим гістограма відрізняється від зведення (summary) і чому це важливо для перцентилів?

На дашборді три поди одного сервісу. Чому не можна взяти середнє їхніх p95 і назвати це p95 сервісу?

Чому мітки з високою кардинальністю — це проблема, а не зручність?

Що бере на себе Prometheus, а що Grafana?

Що таке APM і чому тут не варто відповідати завченим означенням?

Метрика, лог і трейс — на які різні питання вони відповідають?

Що таке розподілений трейс і як контекст трейсу переїжджає між сервісами?

Генератор показує p95 = 800 мс, дашборд сервісу — 500 мс. Хто бреше?

Графік лічильника різко впав до нуля. Що це найімовірніше означає?

Коли ви попросите профіль, а не метрики?

Кейс 1. Дашборд під час прогону: сервіс і ресурси в одному часовому вікні

Кейс 2. «Звіт каже 800 мс, дашборд — 500 мс» — хто правий

Кейс 3. Playwright: тест, який приносить у баг-репорт адресу трейсу

Симптом і причина: USE і RED

Інструментування: звідки беруться числа

Типи метрик і мітки

APM, сигнали й трейсинг

Профілювання й маршрут розслідування

Типові пастки при звірці чисел

Навіщо для лічильника беруть `rate()` і чому цю ж функцію заборонено брати від датчика?