Откакто започнах в технологиите през 1992 г. (преди повече от три десетилетия!), срещнах безброй сценарии, в които се очакваше да „направям повече с по-малко“. Един опит се откроява от времето ми като архитект на backend в проект за модернизация на облака. Решението беше задвижвано от високата цена на поглъщането на дневници на нашата платформа за наблюдение. minimize or eliminate service-level logging Това работи – докато не се случи. Наистина ни трябват тези книги! Неизбежно възникна неочакван проблем и ние се нуждаехме от тези липсващи дневници. Те се оказаха единственият начин да се идентифицира основната причина.Без тях, часове минаха без решение, несигурността нарастваше и безпокойството последваше целия екип. // Sample (but not the real) log line removed during our cost-cutting
{
  "timestamp": "2025-03-21T14:05:03Z",
  "service": "preference-engine",
  "level": "ERROR",
  "message": "Worker queue overflow: unable to dispatch to worker pool",
  "requestId": "abc123",
  "userId": "admin_42"
}
 Ако го запазихме, един прост структуриран лог за грешки (като горепосочения) би могъл лесно да бъде филтриран в платформа за регистрация с проста заявка за регистрация (като по-долу) и да ни позволи да разберем, диагностицираме и коригираме проблема. _sourceCategory=prod/preference-engine "Worker queue overflow"
| count by userId, requestId
 Да се каже драстично да се намали нашето отглеждане на дървесина постави целия проект в уязвимо състояние. Lean не означава гладен за ресурси За да бъдем ясни, мисленето „да правим повече с по-малко“ не е по своята същност лошо.Много стартиращи компании процъфтяват, като се фокусират върху ключови приоритети и използват лек, ефективен софтуер. Но това не беше „добрият“ тип lean. И нашият краен срок за преминаване към облака беше фиксиран. Ние се състезавахме срещу датата на обезценяване на браузъра. Това означаваше пренаписване на услугите към облачен дизайн, координиране с екипите на клиентите и доставяне под натиск. Това беше ОК в началото, ние просто вмъкнахме необходимата регистрация, докато работим върху всеки метод. we relied on logs to resolve our issues Но когато дървесината беше отрязана, екипът беше изложен.Нашата основна мрежа за сигурност беше изчезнала. Коренна причина без мрежа Вътрешното тестване вървеше добре.С наближаването на производството се почувствахме уверени в новата ни архитектура, базирана на облак.Решихме известни проблеми в теста и изпълнихме крайния срок. Но скоро осъзнахме, че нашата увереност беше погрешно поставена и нямаше покритие от тестове. След като бяхме в производство и реалните клиенти използваха платформата, се появиха онези неприятни неочаквани случаи на ръба.И разбира се, без подробни дневници или достатъчна наблюдателност, нямахме начин да разследваме проблема.Ограничената налична телеметрия просто не беше достатъчна, за да определи какво се е объркало. Ако имахме дневници както за тестовете на задния край, така и за производствените клиенти на предния край, щяхме да знаем какво се случва и да предупредим екипа (и потребителя). _sourceCategory=prod/preference-engine OR prod/frontend error
| join ( _sourceCategory=prod/tester-feedback “queue error” )
  on requestId
| fields requestId, _sourceCategory, message
 Но без дневниците, възпроизвеждането на инцидентите на местно ниво беше почти невъзможно.В случаите на реална употреба имаше твърде много променливост.Опитахме се да активираме отново частичното отчитане, но това просто доведе до увеличените разходи за поглъщане, които ни помолиха да намалим, без да предоставяме осъществими прозрения. В някои случаи изобщо не можехме да идентифицираме основната причина.Това е трудна позиция: знаейки, че има проблем, който засяга потребителите и не може да го обясни.Това създаде широко разпространено чувство за безпомощност в целия екип. MTTR срещу качеството на сигнала Още един проблем беше, че в нашите инцидентни ретроспективи времето за възстановяване означава време ( Но открихме, че MTTR най-често е симптом, а не коренна причина. МТР Индустриалните референтни показатели обикновено показват, че елитните екипи постигат MTTR за по-малко от час. Сигналите с ниска надеждност, като например общите грешки 500 или забавеното предупреждение от агрегираните показатели, не помагат. high-fidelity signals За разлика от това, подробни, контекстуални сигнали – като структурирани дневници с userId, requestId и услуга – се режат директно към основната причина. Ако вашите дневници не отговарят на тези въпроси, вашият MTTR не е за скоростта на екипа - това е за яснотата на сигнала. Как моделът на Sumo Logic можеше да спаси деня И така, какво би могло да бъде по-различно – и по-добре – по време на моят проект за модернизация на облака? Първо, наистина бих искал да имаме по-добър анализ на дневниците и мониторинг на изпълнението на приложенията (APM). И заедно с този APM, управление на дневниците, монитори на услугите, предупреждения и определени показатели, тясно съобразени с функционалния успех или провал. Искам дневниците ми да се върнат! в предишната ми публикация, " „Проучих как Протоколите могат да бъдат поглъщани непрекъснато, но плащате само когато трябва да ги запитвате или анализирате. DevSecOps: Време е да платите за вашето търсене, а не за поглъщане, Сума логика Имате ли екип без пълно покритие за изпитване на единици? Страдате ли от липса на предупреждения в реално време или гранулирани показатели? На тесен бюджет? Липса на дневници? С нулеви разходи за пълно поглъщане екипите могат да се регистрират толкова, колкото им е необходимо, без да се притесняват.И когато този инцидент най-накрая се случи (и ще се случи), анализът може да бъде задействан при поискване, на оправдана цена, пряко свързана с въздействието на клиентите или с бизнес непрекъснатостта. Този подход възстановява контрола и намалява тревожността, защото екипите са упълномощени да разследват задълбочено, когато е най-важно. Но изчакайте: Вие също се нуждаете от машинно подпомагано триене, за да изчистите запитванията си Съвременната наблюдателност не е само за това да имате всички тези красиви дневници данни – това е и за това къде да погледнете в тези данни. . high-fidelity signals Когато имате неограничен прием, имате тонове данни.И когато започнете да търсите информация, имате нужда от място, от което да започнете. които автоматично групират аномално поведение, откриват отклонения и повърхностно корелиращи сигнали в различни услуги, преди да напишете една заявка. machine-assisted triage tools Зад кулисите Sumo Logic използва статистически алгоритми и машинно обучение, за да: 
 
 
 
 
 Cluster logs by similarity (дори ако се изразява по различен начин между възлите). Откриване на отклонения в метриките и дневниците (напр. пикове на грешките по услуга, регион или потребителска кохорта). Обогатяване на аномалии с метаданни (например AWS тагове, Kubernetes pod info, маркери за внедряване). Кластерите за обработка на естествен език регистрират семантично сходство, а не просто съвпадение на струни. Това е особено полезно в среда с висок обем на неограничен прием.Вместо да преглеждате десетки хиляди линии в дневника, получавате „подписи в дневника“ – кондензирани модели, които представляват групи от свързани събития. Пример за работен поток _sourceCategory=prod/* error
| logreduce
 Тази една команда групира шумните данни от лога в действащи букети като: Error: Worker queue overflow
Error: Auth token expired for user *
Error: Timeout in service *
 След като се групират, екипите могат да се въртят към по-дълбок контекст: | where message matches "Auth token expired*"
| count by userId, region
 Резултатът? по-малко слепи търсения. по-бързи решения. по-малко безпокойство по време на инцидент. Заключението Философията „Направи повече с по-малко“ не трябва да поставя инженерните екипи в неблагоприятно положение, но трябва да бъде придружена от правилните инструменти.Без тях дори най-способните екипи могат да се чувстват така, сякаш се движат безцелно по време на инцидент, което води до разочарование и стрес. Моите читатели могат да си припомнят моето лично изявление за мисията, което според мен може да се приложи към всеки ИТ специалист: 
 
 Фокусирайте времето си върху предоставянето на функции/функционалности, които разширяват стойността на вашата интелектуална собственост. Фокусирайте времето си върху предоставянето на функции/функционалности, които разширяват стойността на вашата интелектуална собственост. В тази статия разгледахме как моделът за нулеви разходи за поглъщане съответства на тази мисия.Това помага на екипите бързо да идентифицират основните причини, да намалят времето за спиране на работа и да намалят нивата на стрес – всичко това без да нарушават бюджета. Имайте наистина страхотен ден!

The code in this story is for educational purposes. The readers are solely responsible for whatever they build with it.

2022 - HackerNoon Contributor of the Year - Cloud Computing

2022 - HackerNoon Contributor of the Year - Design

2022 - HackerNoon Contributor of the Year - Heroku

2022 - HackerNoon Contributor of the Year - Javascript

2022 - HackerNoon Contributor of the Year - Salesforce

2022 - Hackernoons Tech Storyteller of the Year

I ♥ writing code. Find me on GitLab.

Nominated for 2022 - HackerNoon Contributor of the Year - Javascript

Nominated for 2022 - Hackernoons Tech Storyteller of the Year

Nominated for 2022 - HackerNoon Contributor of the Year - Cloud Computing

Nominated for 2022 - HackerNoon Contributor of the Year - Heroku

Nominated for 2022 - HackerNoon Contributor of the Year - Design

Nominated for 2022 - HackerNoon Contributor of the Year - Salesforce

Това аудио е създадено на оригиналния език на историята!

Твърде дълго; Чета

Make resilience your competitive advantage

Направете повече с по-малко? не без по-добри дневници и по-добри инструменти

About Author

КОМЕНТАРИ

ЗАКАЧВАЙТЕ ЕТИКЕТИ

ТАЗИ СТАТИЯ Е ПРЕДСТАВЕНА В

Related Stories

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps