С тех пор как я начал заниматься технологией в 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. И наш срок перехода в облако был фиксирован. Мы соревновались с датой обесценения браузера. Это означало перезапись услуг в облачный дизайн, координацию с командами клиентов и доставку под давлением. Это было нормально вначале, мы просто вставили необходимые записи во время работы над каждым методом. 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, но только если данные, которые вы вводите, являются действительными. Если ваши журналы не отвечают на эти вопросы, ваш MTTR не о скорости команды - это о ясности сигнала. Как модель Sumo Logic могла спасти день Так что могло пойти по-другому — и лучше — во время моего проекта облачной модернизации? Во-первых, я действительно хотел бы, чтобы у нас был лучший анализ журналов и мониторинг производительности приложений (APM).И вместе с этим APM, управление журналами, мониторинг сервисов, оповещения и определенные метрики, тесно связанные с функциональным успехом или неудачей.Я хочу (на каждом проекте), чтобы для каждой новой функции у меня была связанная метрика, связанная с ее успехом. И я хочу, чтобы мои журналы вернулись! в моей предыдущей публикации, " «Я исследовал, как Логи могут быть поглощены непрерывно, но вы платите только тогда, когда вам нужно запросить или проанализировать их. DevSecOps: пора платить за ваш спрос, а не за потребление, Сумма логики Вы команда без полного покрытия испытаний единиц? страдаете от отсутствия оповещений в режиме реального времени или гранулярных показателей? На узком бюджете? Отсутствие журналов? С нулевой ценой полного потребления, команды могут регистрировать столько, сколько им нужно, без беспокойства.И когда этот инцидент наконец-то произойдет (и это произойдет), анализ может быть задействован по запросу, по обоснованной стоимости, непосредственно связанной с воздействием на клиентов или непрерывностью бизнеса. Такой подход восстанавливает контроль и снижает беспокойство, потому что команды имеют право тщательно исследовать, когда это самое важное. Но подождите: вам также нужен машинный триаж, чтобы прояснить ваши запросы Современная наблюдательность не только о том, чтобы иметь все эти красивые данные журнала — это также о том, чтобы знать, где искать эти данные. . high-fidelity signals Когда у вас есть неограниченное потребление, у вас есть тонны данных.И когда вы начинаете искать информацию, вам нужно место, чтобы начать. автоматически группирует аномальное поведение, обнаруживает отклонения и поверхностно коррелирует сигналы по всем службам, прежде чем вы напишете один запрос. machine-assisted triage tools За кулисами Sumo Logic использовала статистические алгоритмы и машинное обучение для: 
 
 
 
 
 Записи кластеров по схожести (даже если они выражены по-разному по узлам). Обнаружение отклонений в показателях и журналах (например, пики ошибок по сервису, региону или когорте пользователей). Обогащение аномалий метаданными (например, тегами 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

Раскрытие силы ИИ. Систематический обзор передовых методов: Краткое содержание и введение

Цифровые кочевники слушают: что нужно знать о новой визе DTV в Таиланде

От форумов до лент новостей: как алгоритмы социальных сетей формируют цифровое взаимодействие

Telegram: мост Крипто-острова на материк

Раскрытие силы ИИ. Систематический обзор передовых методов: Краткое содержание и введение

Цифровые кочевники слушают: что нужно знать о новой визе DTV в Таиланде

От форумов до лент новостей: как алгоритмы социальных сетей формируют цифровое взаимодействие

Telegram: мост Крипто-острова на материк

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps