Наблюдавайте услугата и потребителите ѝ

Започнете с въпроса

Мониторингът проверява известни условия. Observability помага да проучите поведението на системата, включително неуспехи, които не сте предвидили. Повече табла не дават автоматично по-добри отговори.

За измислена услуга за експорт започнете с потребителски въпрос: може ли потребител с право на достъп да получи правилния експорт в договореното време? После изберете сигнали, които подкрепят този въпрос и помагат да се обяснят неуспехите.

OpenTelemetry предоставя инструментация и стандарти за телеметрия. Може да изпраща сигнали към съвместими системи за обработка. Все още се нуждаете от съхранение, заявки, контроли за достъп, срокове за съхранение и хора, които действат според доказателствата. Въведение в observability.

Свържете различни форми на доказателства

Показател измерва количество във времето. Лог записва събитие. Trace свързва относими операции при преминаване на заявка през система. Span представлява една операция в trace.

За асинхронна работа запазвайте безопасна връзка между подадената задача и изпълнението от worker. Отговор HTTP 202 може да означава, че работата е приета. Не доказва, че експортът е завършил.

Известявайте, когато е нужно действие

Определете SLI и знаменателя му, преди да зададете SLO. За примера броете допустимите експорти, завършени правилно в договорената продължителност. Определете как дълго изпълняващите се и изоставените задачи влизат в измерването.

Бюджет за грешки описва разрешените неуспехи в прозореца на SLO. Скоростта на изчерпване описва колко бързо неуспехите изразходват този бюджет. Указанията на Google използват няколко времеви прозореца, за да балансират навременното откриване и шума от известия. Известяване по SLO.

Повикайте дежурен човек, когато условието изисква навременно действие. Изпратете по-малко спешната работа в опашка. Всяко известие се нуждае от отговорник, описание на ефекта, връзка за проучване и инструкция за реакция. Преглеждайте известията, които многократно не водят до действие.

Не използвайте един общ праг за всяка услуга. Ефектът върху потребителите, трафикът, работното време и капацитетът за реакция влияят на решението.

Защитете pipeline-а за телеметрия

Телеметрията може да съдържа лични данни, токени, параметри на заявки и поверителни документи. Определете разрешените полета преди събиране. Ограничете достъпа и срока за съхранение. Премахнете тайните стойности преди експорт към външна система за обработка. Чувствителна телеметрия.

Не използвайте клиентски имейл или уникален идентификатор на задача като етикет на показател. Неограничени етикети увеличават броя времеви серии и могат да разкрият идентификатори. Използвайте контролирани измерения за показателите. Поставяйте одобрени идентификатори за свързване в логове или traces с контролиран достъп.

Измервайте самия pipeline. Проверявайте неуспехи при приемане, отпаднали данни и възрастта на последното наблюдение. Равна графика на грешките може да означава липса на грешки или липса на входяща телеметрия. Показвайте тази разлика.

Проучете конкретен неуспех

Измислената услуга отчита HTTP 202 за всяка заявка. Възрастта на чакащите ѝ задачи нараства от секунди до 15 минути. Логовете на worker-а показват многократно изтичане на времето за изчакване на базата данни. Извадка от traces показва, че повечето време на worker-а се изразходва в извиквания към базата данни.

Тези доказателства подкрепят целево проучване. Не установяват дали причината е промяна в заявка, изчерпани връзки или капацитет на базата данни. Сравнете тези хипотези с метода за отстраняване на дефекти.

Taiga Monitoring предоставя изглед за състоянието на продукта със сигнали за наличност и браузърно преживяване. Допълва observability на инфраструктурата и приложението; не заменя тези системи. Monitoring.