Стек-трагата е сметка, а не објаснување. Таа ви кажува каде неуспехот станал видлив, но ретко зошто системот стигнал до таа точка или кое корисничко патување го нарушил. Во модерен бекенд, барањето може да помине низ API-порта, PHP-апликација, работник за редици, база на податоци, кеш и надворешна услуга пред да не успее. Ако тие компоненти не можат заедно да раскажат кохерентна приказна, дебагирањето станува археологија.

Набљудливоста е дисциплина на дизајнирање системи така што нивното внатрешно однесување може да се заклучи од сигналите што ги произведуваат. Таа не е вежба за собирање контролни табли. Таа е архитектонски избор: одлучување што системот мора да открие пред да пристигне инцидентот.

Започнете со прашања, не со библиотеки за логирање

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

• Кое барање или задача не успеа и за кого?
• Која зависност беше бавна или недостапна?
• Дали неуспехот влијаеше на еден закупец, крајна точка, распоредување или регион?
• Што се промени непосредно пред да се појави однесувањето?
• Дали системот безбедно се обидува повторно, или го умножува оптоварувањето?

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

Важната разлика е меѓу настани и контекст. „Барањето до базата на податоци не успеа“ е настан. ID на барањето, име на операцијата, број на повторни обиди, цел на конекцијата со базата на податоци и категорија на грешка се контекст. Контекстот го прави настанот применлив.

Користете корелација како договор за целиот систем

Идентификаторот за корелација треба да патува со работата, а не да исчезне на првата граница. Генерирајте или прифатете еден на работ, валидирајте го, вклучете го во секој структуриран запис во логот и пренесете го до надолните HTTP-повици и асинхрони задачи. Точното име на заглавието е помалку важно од доследноста.

Во PHP, ID на барањето може да се прикачи на споделениот контекст на логерот и експлицитно да се постави на појдовните барања. Задачата во редицата мора да го носи во својот товар или метаподатоци за работникот подоцна да може да го обнови. Без тоа предавање, неуспехот во заднина се одвојува од веб-барањето што го предизвикало.

$requestId = $request->headers->get('X-Request-ID') ?? bin2hex(random_bytes(16));

$logger->info('invoice.create.started', [
    'request_id' => $requestId,
    'invoice_id' => $invoiceId,
    'tenant_id' => $tenantId,
]);

$httpClient->request('POST', $billingUrl, [
    'headers' => ['X-Request-ID' => $requestId],
]);

Не третирајте ги идентификаторите за корелација како авторизација, идентитет или замена за валидација. Тие се дијагностички метаподатоци. Ако клиентите можат да ги достават, наметнете разумни ограничувања за форматот и должината. Во спротивно, невалидните вредности можат да ги загадат логовите и да ги направат пребарувањата ненадежни.

Направете ги логовите структурирани и намерни

Структурираните логови полесно се пребаруваат, агрегираат и поврзуваат со временските линии на инциденти отколку проза составена со конкатенација на низи. Користете стабилни имиња на настани како invoice.create.started, invoice.create.succeeded и invoice.create.failed. Одржувајте ги стабилни и имињата на полињата: менувањето на request_id во requestId на половина пат низ флотата услуги создава непотребно триење.

Логирајте граници и промени на состојбата, не секоја линија на извршување. Корисен лог на услуга вообичаено бележи завршување на барање, одлуки за автентикација или авторизација, настани од животниот циклус на редицата, одлуки за повторен обид, исходи од надворешни зависности и неочекувани исклучоци. Деталите на ниво за дебагирање може привремено да бидат вредни, но не треба да бидат единствениот пат за разбирање на однесувањето во продукција.

Заштитете ги податоците пред да стигнат до потокот на логови

Логовите често се широко достапни и се чуваат подолго од податоците на апликацијата. Никогаш не претпоставувајте дека некоја вредност е безопасна само затоа што е корисна при дебагирање. Избегнувајте лозинки, токени за пристап, колачиња за сесии, целосни податоци за плаќање и необработени лични податоци. По правило редигирајте ги заглавијата и телата на барањата, а потоа дозволувајте само прегледани полиња кога е потребно.

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

Мерете го однесувањето на услугата на границите

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

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

Метриките треба да поддржуваат одлуки. Ако предупредувањето се активира само кога серверот веќе не е достапен, тоа е известување, а не рано предупредување. Предупредувањата се најсилни кога се врзани за симптоми видливи за корисникот, исцрпен капацитет или режим на неуспех што бара дејство.

Следете ги скапите и кревки патеки

Дистрибуираното следење ги поврзува временските мерења преку границите на услугите. Трагата може да покаже дека PHP-контролерот бил брз, но промашувањето на кешот довело до скапо барање, по кое следел бавен повик кон API нагоре по текот. Тоа е многу покорисно отколку да се обвинува контролерот бидејќи случајно бил најгорната рамка во извештајот за грешка.

Користете траги селективно, но доследно на значајни граници: дојдовни барања, операции со базата на податоци, повици до кешот, објавување и консумирање пораки и надворешни HTTP-повици. Именувајте ги операциите според однесувањето, а не според променливи вредности. GET /orders/{id} е корисно; вметнувањето вистински ID на нарачка во секое име на операција создава податоци со висока кардиналност што се тешки и скапи за користење.

Дизајнирајте ги патеките на неуспех за да бидат набљудливи

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

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

Контејнеризираните распоредувања ја бараат истата дисциплина. Апликациите треба да пишуваат структурирани логови на стандардниот излез или стандардната грешка наместо да зависат од датотеки во ефемерни контејнери. Проверките на здравјето треба да тестираат она што тврдат дека го тестираат: проверката на живост одговара дали процесот може да продолжи да работи; проверката на подготвеност одговара дали може да прифати сообраќај. Не претворајте ниту една во широка проверка на зависности што предизвикува отстранување на здрави инстанци за време на прекин на надолна услуга.

Одржувајте ја набљудливоста одржлива

Инструментацијата има оперативна цена. Полињата се умножуваат, контролните табли отстапуваат, а предупредувањата ги надживуваат услугите за кои биле изградени. Третирајте ги шемите на настани, имињата на метриките, контролните табли и прирачниците за работа како одржувани интерфејси. Прегледувајте ги кога се менуваат API-јата, шемите за пристап до базата на податоци или однесувањето на редицата.

Целта не е да се сними сè. Таа е да се зачуваат доволно сигурни докази за развивачот да може да премине од симптом кај корисникот до веројатна причина без нагаѓање низ слоевите. Кога набљудливоста е дел од архитектурата, стек-дампот останува корисен — но конечно има приказна околу себе.