Опсервабилноста не е логирање: Што да инструментирате пред нешто да се расипе

Повеќето тимови откриваат дека нивната опсервабилност е несоодветна во најлош можен момент: продукцијата е паднат, клиент прашува што се случува, а единствената достапна алатка е пребарување низ логови кои никогаш не биле структурирани да одговорат на прашањето што се поставува. Тимот испраќа поправка, инцидентот се затвора, и сите тивко се согласуваат да „додадат подобро логирање” — ветување кое ретко преживува до следниот спринт.

Проблемот не е недостаток на логови. Повеќето системи произведуваат многу од нив. Проблемот е што логирањето, следењето (monitoring) и опсервабилноста се три различни способности, и поседувањето на едната не ви ги дава другите две.

Логовите, метриките и траговите одговараат на различни прашања

Логот ви кажува дека нешто се случило: пристигнала барање, задача отказала, се фрлила исклучок. Тоа е запис на дискретни настани, и е алатката до која повеќето тимови прво посегнуваат затоа што е најевтина за додавање — една линија во кодот, без потреба од инфраструктурна одлука.

Метриката ви кажува како нешто се движи низ времето: латенција на барања во последниот час, стапка на грешки по крајна точка, длабочина на редицата низ времето. Метриките се евтини за складирање и брзи за пребарување токму затоа што ги отфрлаат деталите, што ги прави вистинската алатка за контролни табли и предупредувања, а погрешна алатка за да се разбере зошто едно конкретно барање било бавно.

Трагот ви кажува каде отишло времето внатре во едно единствено барање додека поминувало низ граници меѓу сервиси — кој подреден повик, кое барање до база на податоци, кој циклус на повторни обиди всушност предизвикал латенција. Ова е делот кој повеќето тимови го прескокнуваат, бидејќи бара пренесување на ID на трагот низ секој сервис што барањето го допира, а тоа функционира само ако е дизајнирано од самиот почеток. Додавање на следење на трагови по случен инцидент значи инструментирање под притисок, а тоа е моментот кога најверојатно ќе се направи лошо.

Ниту еден од трите не ги заменува другите два. Систем со богати логови без метрики може да ви каже дека се случила грешка, но не и дали состојбата се влошува. Систем со метрики без следење на трагови може да ви каже дека p99 латенцијата скокнала, но не и која подредена зависност го предизвикала тоа. Опсервабилноста е кога сите три се поврзани доволно добро за да одговорат на прашање кое никој не го предвидел, користејќи податоци кои веќе се собрани.

Инструментирајте пред да ви затреба, не потоа

Тестот за добро инструментирање не е дали постои — туку дали одговара на прашање кое никој не помислил однапред да го постави. Тоа е можно само ако податоците биле структурирани за пребарување, не само за читање. Линија на лог која вели "payment failed" е речиси бескорисна за време на инцидент; структуриран лог со event: payment_failed, user_id, provider, error_code и latency_ms ви овозможува да филтрирате, групирате и поврзувате без да редеплојувате нешто.

Затоа инструментирањето мора да биде дизајнерска одлука, не задача за чистење. Тимовите кои го третираат како дизајнерска одлука додаваат структурирани полиња, пренесување на траг и клучни метрики како дел од градењето на функционалност — на ист начин на кој би додале валидација на внес. Тимовите кои го третираат како чистење го додаваат откако прекин ќе открие празнина, што значи дека следниот непредвиден начин на отказ открива нова празнина, бесконечно.

Предупредувањата се данок на вниманието — трошете го внимателно

Повеќе следење не е автоматски подобро. Предупредување кое се активира на шум го обучува дежурниот инженер да ги игнорира предупредувањата, а тоа е полошо отколку да немате предупредување воопшто — значи дека она што навистина важи ќе биде отфрлено заедно со остатокот. Секое предупредување треба да одговара на состојба на која човек може да реагира, не на метрика која случајно го поминала прагот. „Стапка на грешки над 5% во текот на пет минути” е нешто на кое може да се реагира. „CPU е на 80%” обично не е, освен ако веродостојно претходи на нешто што се расипува.

Истата дисциплина важи и за контролните табли. Контролна табла со четириесет панели не се проверува за време на инцидент — се игнорира во корист на трите бројки кои дежурниот инженер веќе ги знае напамет. Неколку контролни табли изградени околу конкретни начини на отказ, одржувани ажурирани како што системот се менува, се подобри од една исцрпна контролна табла на која никој не ѝ верува доволно за да ја чита под притисок.

Деловниот случај кој никој не го буџетира

Работата на опсервабилноста ретко добива приоритет затоа што нејзиниот принос е невидлив сѐ додека не престане да биде. Приносот не се мери на спринт демонстрација — се мери во просечното време до решавање за време на инцидентот кој инаку би барал четворица инженери три часа пребарување низ логови за да се дијагностицира, а наместо тоа му требал на еден инженер дваесет минути затоа што трагот покажал точно кој сервис и кое барање биле одговорни. Таа разлика се акумулира: побрза дијагноза значи пократки прекини, што значи помалку клиенти кои забележуваат, а тоа е вистинската метрика за која раководството се грижи, дури и кога инструментирањето е ставката за која најтешко издвојуваат буџет.

Тимовите кои ова го прават правилно не ја третираат опсервабилноста како алатка за одговор на инциденти. Тие ја третираат како постојан дел од тоа како системот е изграден, преиспитуван секогаш кога се додава нов сервис или зависност — затоа што следниот инцидент никогаш не е во делот на системот кој бил добро инструментиран за претходниот.

PNK WORKS гради и инструментира бекенд системи со опсервабилност дизајнирана од самиот почеток, не додадена по првиот прекин. Започнете проект.