Словник для спостережливості і моніторингу в DevOps

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

---

Три точки зору на вивчення мови

Спільнота спостережливості зазвичай відноситься до трьох основних типів даних, які разом надають вам змогу бачити поведінку системи.

Метрика

** Метрики ** — це числові виміри, зібрані протягом певного часу. Вони є основою панелей моніторингу.

• ** Часовий рядок ** — послідовність точок даних, індексованих за часом, наприклад, частота запитів за секунду
• ** Gauge ** — метрика, яка представляє значення у певний момент часу, наприклад, поточне використання пам’ яті
• ** Лічильник ** — метрика, яка лише збільшується, наприклад, загальна кількість обслугованих запитів
• ** Гістограма ** — метрика, яка відстежує розподіл значень, часто використовується для визначення затримки
• ** Перцентиль (P50, P95, P99) ** — значення, нижче якого знаходиться відсоток спостережень; затримка P99 означає, що 99% запитів виконуються швидше за це значення
• ** Кардинальність ** — кількість унікальних комбінацій міток у метриці; висока кардинальність може перевантажити інфраструктуру спостереження
• ** Інтервал сканування ** — частота, з якою система метрики обробляє ціль на наявність нових даних

Журнали

** Журнали ** — це записи з датою і часом дискретних подій у системі.

• ** Структурований журнал ** — запис журналів як машинно- зчитуваних пар ключ- значення (наприклад, JSON), а не як простих текстових рядків
• ** Рівень журналу ** — ступінь тяжкості запису журналу: DEBUG, INFO, WARN, ERROR, FATAL
• ** Агрегація журналів ** — збір журналів з декількох джерел у центральну систему (наприклад, Elasticsearch, Loki)
• ** Збереження журналу ** — тривалість зберігання даних журналу перед їх вилученням або архівуванням
• ** ІД кореляції ** — унікальний ідентифікатор, який додається до запиту під час його передачі за допомогою декількох служб, що надає змогу відновлювати сліди з журналів

3. Сліди

** Розподілене відстеження ** відстежує запит під час його пересування через декілька служб.

• ** Trace ** — повний запис шляху одного запиту через систему
• ** Обсяг ** — одинична одиниця роботи у межах трасування, що представляє одну операцію у одній службі
• ** Батьківський діапазон / дочірній діапазон ** — ієрархічні відносини між операціями у трасі
• ** Розповсюдження контексту трасування ** — передавання ідентифікаторів трасування між службами, щоб можна було зв’ язати діапазони
• ** Вибірка ** — запис лише частини слідів для керування витратами на зберігання, зберігаючи статистичний огляд
• ** Графік полум’ я ** — візуальне представлення сліду, яке показує, які дії тривали найдовше

---

Основні значення: вірність і надійність

• **SLI (Service Level Indicator) ** — специфічна, вимірювана метрика, що використовується для оцінки продуктивності служби, наприклад, рівень успішності запитів
• ** SLO (Service Level Objective) ** — цільове значення для SLI, наприклад, « 99, 9% запитів успішно »
• ** SLA (Service Level Agreement) ** — договірне зобов’ язання до зовнішніх клієнтів, засноване на SLO
• ** Бюджет помилок ** — допустима кількість перерв або помилок у періоді SLO; якщо SLO дорівнює 99, 9%, бюджет помилок становить 0, 1%
• ** Частота запису ** — швидкість, з якою використовується бюджет помилок; висока частота запису свідчить про проблеми зі станом роботи служби
• ** MTTR (середній час відновлення) ** — середній час відновлення роботи після аварії
• ** MTBF (середній час між помилками) ** — середній час між помилками
• ** Доступність ** — відсоток часу, протягом якого служба працює і є доступною

---

Основні мови програмування: C# та C#/CLI

• ** Alert ** — сповіщення, яке буде викликано, якщо метрика перевищить визначений поріг
• ** Поріг** — значення, за якого буде викликано попередження, наприклад, « попередження, якщо рівень помилок перевищить 5% »
• ** Втомлюваність попередженнями ** — десенсибілізація, яка виникає, коли інженери отримують занадто багато попереджень низької якості
• ** Невірно позитивний ** — попередження, яке буде викликано, якщо не існує реальної проблеми
• ** Невірно негативний ** — реальна проблема, яка не викликає попередження
• ** Ротація за викликом** — розклад, за яким відповідальність за відповідь на попередження по черзі передається членам команди
• ** Правила ескалації ** — визначений процес сповіщення додаткових відповідачів, якщо попередження не буде підтверджено за певний проміжок часу
• ** Runbook ** — документована процедура відповіді на певний тип попередження або події
• ** Вимкнення звуку / вимикання звуку ** — тимчасове вимикання попередження під час запланованого обслуговування

---

Розмова про спостережливість в командних розмовах

Дискусія про Dashboard Health

• «Затримка P99 на службі оплати за останні три години мала тенденцію до зростання»
• «Ми бачимо підвищений рівень помилок на платіжному шлюзі — приблизно 2,3%, що вище нашого порогу SLO в 1%»
• «Трактування даних показує, що 80% затримки походить від одного виклику вниз по лінії до інвентарної служби»
• “Наш бюджет на помилку становить 23% від того, що залишилося на цей місяць. Ми повинні бути обережні з тим, що ми відправляємо цього тижня»

Під час інциденту

• “Я бачу пік в 5xx ставки починаючи з 14:32 UTC. Всі три екземпляри в eu-west-1 були вражені»
• «Граф полум’я показує, що повільний розмах знаходиться в шарі запиту бази даних — конкретно в кінцевій точці пошуку продукту»
• «Кореляційний ID-трасування показує, що запит затримується в очікуванні на службу рекомендацій»
• “Ми приглушили вторичні попередження, щоб ми могли зосередитися на основному інциденти. «Активізація»

В пост-інцидентному огляді

• «MTTR для цього інциденту був 47 хвилин — вище нашої 30-хвилинної цілі. Давайте поглянемо на хронологію виявлення і реагування»
• «Попередження було викликано правильно, але Runbook не покривав цей режим невдачі, що додало часу на розв’язання»
• “У нас було два фальшивих позитивних результати цього тижня, що створили шум під час інциденту. Ми підберемо ці пороги»

---

Словник інструментів

Розмови щодо спостережливості часто стосуються певних категорій інструментів:

• ** APM (Application Performance Monitoring) ** — інструменти, такі як Datadog, New Relic, Dynatrace, які забезпечують повний огляд продуктивності
• ** TSDB (Time Series Database) ** — спеціалізовані бази даних для метрик, такі як Prometheus або InfluxDB
• ** Observability platform ** — інтегрований набір, що поєднує метрику, журнали та сліди, наприклад, Grafana Stack, Honeycomb, Datadog
• ** OpenTelemetry (OTel) ** — відкритий стандарт для збору і експорту даних спостережливості між мовами і виробниками

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

На практиці: Навігація нюансів з не-рідними мовами

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

Уявіть Сару, розробника, яка недавно переїхала з Польщі до нашої компанії. Вона ретельно слідувала документації і реалізувала запитану функцію - нову кінцеву точку API для автентифікації користувача. Під час перегляду коду її колега Марк коментує безпосередньо опис PR: «Це потребує більше контексту; нам потрібно зрозуміти * чому * ви обрали цей підхід». Фраза «потрібно більше контексту» звучить обвинувальним, що означає, що її робота якось не має розуміння або виправдання. Рідний мовець може інтерпретувати це як запит на пояснення щодо проектних рішень - можливо, коротке пояснення компромісів, які вона розглядала. Для Сари, це почувається як критика без конструктивного керівництва.

Аналогічно, під час зміни на виклик, ефективне спілкування про попередження є критичним. Припустимо, що система моніторингу зафіксувала незвичайно високу затримку в нашій службі бази даних. Замість простого зауваження «Затримка бази даних висока», більш корисною фразою може бути: «Ми бачимо підвищену затримку в службі бази даних, що потенційно впливає на транзакції користувачів. Чи можете ви дослідити і визначити, чи це пов’ язано з останніми змінами схеми або збільшенням навантаження? “Останній визнає потенційний вплив і запрошує до співпраці - важливо, коли справа доходить до складних систем і проблем, що вимагають часу. Використання точної мови зменшує неоднозначність і уникає припущень. Сфокусування на впливі, а не просто на вказівах, допомагає сформулювати проблему таким чином, щоб її було легше зрозуміти всім, особливо тим, чия перша мова не надає природного пріоритету технічним деталям.

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

# Example: Using Prometheus' `describe` command to investigate latency metrics
prom query -n my_namespace -g "up{job='my-api'}" -- noquery