Ця серія статей покликана роз’яснити технічні терміни у зрозумілій формі та заглибитись у тему порівняння спостережуваності та моніторингу.
Ви колись намагалися діагностувати несправність автомобіля, просто прислухаючись до дивного стуку? Такий вигляд має традиційний моніторинг у світі сучасного складного програмного забезпечення. Ви знаєте, що щось не так, але з’ясування причини може перетворитися на тривалу та стомлюючу гру на вгадайку. Часто для виявлення першопричини проблеми необхідно знати, що саме потрібно шукати, а ми не завжди маємо таку можливість.
На допомогу приходить спостереження. Це більше, ніж просто моніторинг; це здатність зрозуміти внутрішній стан вашої системи просто подивившись на дані, які вона генерує ззовні. Коли відбувається інцидент, особливо такий, з яким ви ніколи раніше не стикалися (сумно відомі «невідомі невідомі»), спостережуваність надає дані, необхідні для того, щоб поставити будь-яке питання і швидко знайти відповідь. Давайте заглибимося в деякі аспекти, що становлять спостереження.
Паливо для інсайтів: Телеметрія
Вся система спостереження побудована на даних. Ці дані разом називаються телеметрією.
Телеметрія– це автоматичний збір та передача даних із віддалених джерел, у нашому випадку – з ваших програм та інфраструктури. Це «матеріал», який ви збираєте і який часто поділяється на три основні типи, які іноді називають «трьома стовпами спостережуваності»:
- Метрики: Цифрові вимірювання, які збираються протягом певного часу (наприклад, завантаження ЦП, затримка запитів, кількість помилок). Уявіть лінійний графік з падіннями.
- Журнали: Записи з тимчасовими мітками про окремі події (наприклад, «Користувач увійшов до системи», «Запит до бази даних не вдався»). Подайте докладні записи в щоденнику.
- Трасування (розподілене трасування):Записують шлях одного запиту з його проходження через кілька служб. Уявіть маршрут GPS однієї взаємодії.
Після запиту: Розподілене відстеження
У міру мікросервісів (де одна дія користувача може торкнутися 10 різних додатків) виявлення уповільнення роботи – справжній жах.
Розподілене відстеження вирішує цю проблему, привласнюючи унікальний ідентифікатор запиту в момент його надходження до системи та відстежуючи його у всіх сервісах, з якими він взаємодіє.
- Приклад: Користувач натискає “Купити зараз”. Система відстеження простежує запит від фронт-енд служби до служби інвентаризації, потім платіжного шлюзу і, нарешті, до служби підтвердження. Якщо платіжний шлюз запрацював 45 секунд, трасування візуально зазначає цей проміжок часу, миттєво вказуючи вам, де знаходиться вузьке місце.
Управління даними: Кардинальність
При зборі великих обсягів телеметричних даних в повному обсязі дані створюються однаково.
Кардинальність означає кількість унікальних значень у полі даних.
- Низька кардинальність:Поле типу «статус» може мати лише 3 унікальні значення («успіх», «невдача», «очікування»). Цими даними легко керувати.
- Висока кардинальність: Поле типу ID користувача або ID сеансу може мати мільйони унікальних значень. Хоча дані з високою кардинальністю надзвичайно корисні для детального усунення несправностей (наприклад, «Що сталося із замовленням цього конкретного користувача?»), вони можуть збільшити витрати на зберігання та уповільнити виконання запитів, якщо ними не керувати належним чином.
Коли час – гроші: MTTR
Основна мета хорошої спостерігальності – мінімізувати наслідки збою. Найбільш важливим показником для виміру цих наслідків є MTTR.
MTTR означає середній час відновлення (або часом середній час усунення/ремонту). Це середній час, необхідний вашій команді для повного відновлення нормальної роботи системи після виявлення збою.
Нижчий показник MTTR є ознакою високоефективної та стійкої команди. Завдяки високій спостережуваності ви можете швидко діагностувати проблеми, що значно скорочує MTTR і дозволяє заощадити гроші компанії та зберегти лояльність клієнтів.
Кінцева мета: Аналіз першопричин
Після гасіння пожежі та відновлення системи (завдяки вашому низькому MTTR!) робота ще не закінчена. Необхідно з’ясувати, як запобігти повторенню такої ситуації.
Аналіз першопричин (RCA)- Це структурований процес, який дозволяє виявити глибинні, фундаментальні причини проблеми, приховані за поверхневими симптомами. Його мета – знайти постійне рішення, а не тимчасове виправлення.
- Аналогія: У вас прокололася шина. Симптом – прокол. Причина може бути у цвяху на дорозі, виробничому дефекті або поганому підтримці тиску в шинах. RCA гарантує, що ви заміните шину та почнете регулярно перевіряти тиск.
Проактивне мислення: підхідShift Left
Але навіщо чекати, поки проблема торкнеться ваших реальних клієнтів?
Shift Left – це підхід у розробці програмного забезпечення, який передбачає перенесення таких практик, як тестування, доступність, безпека та спостережуваність на більш ранні етапи життєвого циклу розробки.
- Приклад: Замість того, щоб чекати, поки код надійде у виробництво, щоб побачити, чи створює нова функція занадто багато даних журналу, розробник використовує інструменти спостереження для перевірки проблем на етапі тестування. Це здешевлює та прискорює виправлення помилок, запобігаючи дорогим сюрпризам у майбутньому.
Передбачувана проблема: Сезонність
Іноді поведінка вашої системи не є помилкою, а закономірністю.
Сезонність в області спостережуваності відноситься до передбачуваних, повторюваних коливань у телеметричних даних протягом фіксованих періодів (щодня, щотижня, щомісяця, щорічно). Це не аномалії, а очікувані тенденції.
- Приклад: Ваш сайт електронної комерції може відчувати масовий, передбачуваний сплеск запитів щонеділі вранці о 10 годині, коли виходить щотижневий рекламний проспект. Ігнорування цього “сезонного” сплеску може викликати непотрібне попередження, але уважна система знає: “Ні, це просто недільний день розваг”.
Спостережуваність – це перехід від реактивної позиції «Що зламалося?» до проактивної позиції «Чому це зламалося і як ми можемо гарантувати, що це не повториться?». Розуміючи ці ключові терміни та впроваджуючи відповідні практики, ви не просто контролюєте свої системи, а повністю їх освоюєте.
Джерело: What Even Is… Observability?
