Виберіть запит із чітким очікуваним результатом
Для ілюстративної кінцевої точки звіту зафіксуйте шаблон маршруту, приблизний розмір даних, контекст автентифікації та чи створює вона фонову роботу.Використовуйте тестовий обліковий запис і репрезентативні анонімізовані дані. Не копіюйте токени, ідентифікатори клієнтів або повні тіла запитів у нотатку про інцидент.
Відокремте витрати на запуск першого запиту від повторюваної усталеної поведінки. Зафіксуйте вікно UTC та ревізію випуску. Визначте, чи всі маршрути повільні, чи зачеплені лише великі звіти, чи затримка слідує за однією зовнішньою залежністю. Ці відмінності роблять наступний вимір кориснішим за широкий набір не пов'язаних метрик.
Побудуйте часову шкалу без подвійного врахування
Трасування OpenTelemetry з'єднують пов'язані спани через поширений контекст між межами сервісів. Лише збіг часових міток недостатній. Вкладені синхронні спани та паралельні виклики можуть перекриватися. Асинхронні нащадки можуть пережити свого батька, тому додавання тривалості всіх сpan-ів може подвоїти врахування часу. Слідкуйте за операціями, які визначають завершення запиту.
Технічна довідка: Трасування OpenTelemetry · Поведінка завершення сpan-ів OpenTelemetry.
| Інтервал | Операція | Питання |
|---|---|---|
| 0–40 мс | Маршрутизація та авторизація | Звичайно для цього тестового облікового запису? |
| 40–640 мс | Межа бази даних | Очікування пулу, очікування блокування чи виконання? |
| 640–940 мс | Зовнішнє збагачення | З'єднання, відповідь чи повторна спроба? |
| 940–1,020 мс | Серіалізація | Який розмір корисного навантаження? |
Найбільший інтервал вказує, де шукати, а не першопричину. Інтервал бази даних, виміряний в API, може включати очікування з'єднання, перш ніж запит досягне бази даних. Відсутність телеметрії також не доводить, що робота не виконувалася; перевірте вибірковість і покриття інструментування.
Співвіднесіть спостереження застосунку та хоста
Зберіть таймінги запитів, помилки, використання з'єднань бази даних, вік черги, навантаження CPU, пам'яті та диска за те саме вікно. Зазначте паралельні резервні копії, міграції або випуски. Один скріншот утилізації може пропустити сплеск, який вплинув на запит.
Використовуйте ідентифікатори кореляції та часові мітки в редагованих журналах з відповідним збереженням і контролем доступу. Уникайте сирих секретів, корисних навантажень клієнтів і необмежених міток метрик. Інструментуйте межу, необхідну для гіпотези, та перевіряйте накладні витрати. Новий агент трасування сам по собі є зміною, яку варто спостерігати.
Дослідіть запит, не спричиняючи ще один інцидент
Спочатку визначте форму запиту, характеристики розміру вхідних даних і очікування з'єднань або блокувань. PostgreSQL EXPLAIN описує план; EXPLAIN ANALYZE фактично виконує оператор і додає накладні витрати на інструментування. Запис може змінити дані, тоді як дороге читання все одно створює навантаження. Використовуйте ізольовану репрезентативну базу даних для початкового дослідження.
Вартість планувальника — це не минулі мілісекунди. Крихітна тестова таблиця може дати інший план, ніж більший набір даних застосунку. Перегляньте статистику, індекси та розподіл, і порівняйте ту саму форму запиту після зміни. Ніколи не вставляйте невідомий запис у команду аналізу на продакшені лише для отримання таймінгу.
Технічна довідка: PostgreSQL EXPLAIN.
Передбачте, що має покращити одна зміна
Якщо очікування пулу домінує, перевірте з'єднання воркерів або запити, які утримують з'єднання без потреби. Якщо домінує виконання запиту, перевірте план і запитані рядки. Якщо домінує зовнішній API, перегляньте тайм-аути, повторні спроби та чи повинна робота бути синхронною. Насичення CPU під час серіалізації вказує на інший експеримент.
Напишіть прогноз: зменшення паралелізму експорту має зменшити очікування пулу API, тоді як експорти триватимуть довше. Це виявляє компроміс. Повторіть той самий набір запитів, порівняйте затримку та помилки й перевірте, що покращення не просто перемістило збій у дедалі більшу чергу.
Збережіть результат та його невизначеність
Зафіксуйте початкове спостереження, перевірену зміну, метод порівняння та залишкову невизначеність. Якщо докази суперечать гіпотезі, скасуйте ізольовану зміну, де це доречно, і дослідіть іншу межу. Уникайте накопичення постійних змін налаштувань без пояснення.
Змінюйте розмір, коли вимірювання виявляють обмеження ресурсу, яке могло б вирішити додаткове виділення. Використовуйте бюджет навантаження та зафіксуйте регресію випуску в брифі інциденту. Результат — обґрунтований діагноз, а не обіцяна затримка чи бенчмарк провайдера.
Офіційні посилання
Документацію переглянуто для цієї статті. Приклади — це планувальні вправи, а не команди, перевірені на сервері PrivacyNodes. Перевірте документацію для вашої встановленої версії.