В этой статье мы углубимся в наблюдаемость и ее значение в программном обеспечении. Мы узнали бы о его истории, целях и важности наблюдаемости, а также о проблемах, которые могут возникнуть, если его нет в жизненном цикле программного обеспечения.
Мы также проанализируем ключевые различия между наблюдаемостью и мониторингом. Наконец, мы рассмотрим передовой опыт внедрения наблюдаемости, факторы, которые необходимо учитывать при выборе инструмента наблюдаемости, и то, как принять наилучшую стратегию для вашего бизнеса.
Что такое Наблюдаемость? — История
Термин «наблюдаемость» происходит от слова «наблюдать», которое подразумевает внимательное наблюдение за чем-либо с целью достижения вывода.
Возвращаясь к технической области, наблюдаемость была придумана Рудольфом Э. Кальманом в 1960 году, и ее корни связаны с теорией управления (раздел прикладной математики, занимающийся использованием обратной связи для влияния на поведение системы, чтобы достижения желаемой цели), в механических системах датчики и детекторы измеряют выходные данные, чтобы информировать органы управления, которые находятся на месте.
Наблюдаемость — это просто знание того, что делают ваши пользователи, системы и приложения в любой момент времени (сбор данных), чтобы сообщить вам, что не так и почему это произошло (отслеживание).
Мы не можем исправить то, чего не можем наблюдать
Первое появление Observability. Одно из первых появлений термина произошло в 2013 году, когда инженеры Twitter опубликовали сообщение в блоге под названием Наблюдаемость в Twitter, которое было создано для наблюдения за состоянием и производительностью разнообразие сервисной топологии по мере перехода от монолитной к распределенной ИТ-архитектуре.
Теперь, когда мы рассмотрели предысторию, давайте посмотрим на фундаментальные различия между «наблюдаемостью» и «мониторингом», поскольку в английском языке они означают почти одно и то же.
Мониторинг просто сообщает и показывает вам, что что-то не так, поскольку он основан на сборе предопределенных наборов метрик или журналов в системе, в то время как Наблюдение использует сбор данных, чтобы сообщить вам, что не так. неправильно, и почему так получилось, что SRE (инженеры по надежности системы) или команда DevOps легко отлаживают свою систему, поэтому она основана на изучении метрик и шаблонов, которые, возможно, не были определены заранее.
Так зачем он нам нужен и в чем его важность?
Начнем с проблем, о которых сообщает исследование из отчета State of Observability 2021:
- 53% респондентов заявили, что проблемы с приложениями привели к потере клиентов или прибыли.
- 45% сообщили о снижении удовлетворенности клиентов в результате сбоев в обслуживании.
- 30% сообщили, что в результате потеряли клиентов.
Что затем привело к тому, что значительный процент респондентов жестко расплачивался за последствия сбоев в обслуживании:
- Снижение удовлетворенности клиентов (45%)
- Потеря дохода (37%)
- Потеря репутации (36%)
- Потеря клиентов (30%)
Наблюдение, безусловно, не игнорируется юридическими отделами и отделами соответствия, поскольку оно играет важную роль в обеспечении соблюдения организациями своих юридических обязательств по защите конфиденциальных данных от несанкционированного доступа. Технология наблюдения также может использоваться в сфере безопасности для выявления нарушений и вторжений и предотвращения утечек данных, что позволяет правительствам и регулирующим органам избегать или уменьшать штрафы за несоблюдение требований.
Статистика также продолжает показывать, что организации, практикующие наблюдаемость, добились роста доходов и прибыльности благодаря аналитической информации, которую можно отслеживать на основе поведения клиентов, что помогает маркетологам принимать стратегические решения, а также улучшать взаимодействие с пользователем, что затем повышает репутацию организации.
Ну и что дальше?
Три столпа наблюдаемости
Показатели
Метрики — это числовые представления того, как данные измеряются в течение интервалов времени. Все, от операционных систем до приложений, генерирует метрики, которые включают набор атрибутов, таких как имя, отметка времени и поле для указания некоторого значения, обычно передающего информацию об SLA, SLO и SLI.
Когда дело доходит до мониторинга, метрики являются логичным началом, потому что так много ресурсов готовы предупредить нас о себе. Как правило, инженеры SRE и операционные инженеры используют метрики для запуска предупреждений всякий раз, когда системное значение превышает указанный порог, и эти метрики являются выбранными ключевыми показателями производительности (KPI), такими как время отклика, пиковая нагрузка, количество обслуживаемых запросов, мощность ЦП, использование памяти, частота ошибок. и задержка. примерные KPI:
- Инициировать оповещения, когда система не работает или когда балансировщики нагрузки достигают максимальной мощности
- Количественная оценка производительности
- Мониторинг необычных действий
Ведение журнала
Ведение журнала — очень важный процесс в наборе инструментов мониторинга, потому что практически все регистрирует информацию о том, что они делают в любой момент времени. Кроме того, журналы предоставляют более подробную информацию о ресурсах, чем метрики, и большинство платформ приложений, библиотек и языков поддерживают ведение журналов. Итак, если метрики показали, что ресурс умер, логи помогут вам понять, почему он умер.
Проблема с логами в том, что хорошего может быть слишком много. Когда все в вашей среде отслеживают, что они делают, и стремятся поделиться этой информацией, легко понять, как это может привести к большому объему данных, и вместо того, чтобы упростить процесс мониторинга, вы можете просто создать еще один большой новый централизованный стог сена.
Отслеживание
Журналы и метрики полезны для оценки поведения и производительности отдельных систем, но редко полезны для определения жизненного цикла запроса в распределенной системе. Трассировка — это еще один подход к наблюдению, который позволяет вам увидеть и понять все время жизни действия в нескольких системах.
Можно сказать, что трассировка — это представление серии причинно связанных распределенных событий, которые инкапсулируют сквозной поток запросов через распределенную систему.
Трассировка отражает весь путь запроса или действия, обеспечивая критическое представление о работоспособности системы, поскольку она проходит через все узлы в распределенной системе. Трассировки обеспечивают профилирование и проверку системы, особенно для контейнерных приложений, бессерверных архитектур и архитектур микросервисов.
Анализируя данные трассировки, вы сможете отслеживать общее состояние системы, выявлять потенциальные проблемы, быстрее обнаруживать и устранять проблемы, а также определять важные области для оптимизации и улучшений.
Внедрение инструмента наблюдения
Когда вы думаете о возможности оптимизации для достижения успеха в вашей организации, клиентский опыт чаще всего является первым, что следует учитывать, и является ключом к успеху большинства технологических компаний сегодня. Другим важным критерием является необходимость упреждающего решения таких вопросов, как доступность и производительность приложений в рабочей среде. Здесь в игру вступает наблюдательность. Теперь для бесперебойной работы ваших систем требуется надежная архитектура с возможностью наблюдения.
Я составил список инструментов наблюдения для агрегирования журналов, распределенной трассировки, APM, анализа временных рядов и сбора метрик. Хотя он не основан на углубленном изучении ключевых преимуществ или сравнении инструментов; тем не менее, это отличная отправная точка, чтобы начать свой путь к большей наблюдаемости.
Выбрав правильную платформу наблюдения, получив связанное представление данных о производительности вашей системы в едином представлении и внедрив культуру наблюдения, вы сможете быстрее выявлять проблемы, понимать, что их вызвало, и, в конечном итоге, создавать продукты, ориентированные на клиента. на больших скоростях.
Некоторые из лучших инструментов наблюдения и управления журналами, которые следует учитывать.
Затем вам необходимо определить и отслеживать показатели, связанные с проблемами, с которыми вы уже сталкивались, и теми, с которыми вы, вероятно, столкнетесь в будущем.
После включения наблюдаемости в процесс управления инцидентами вы должны определить и отслеживать показатели, связанные с проблемами, которые уже произошли, и теми, которые, как ожидается, возникнут в будущем. После этого вы должны установить во всей организации культуру, ориентированную на наблюдаемость.
Без реализации этой модели вы, возможно, не сможете получить максимальную отдачу от своей архитектуры наблюдаемости, поскольку никакие инструменты наблюдаемости не могут заменить твердое инженерное чутье и интуицию.
