В предыдущей статье серии мы обсудили важность сбора данных. В этой статье мы изучим роль мониторинга в наблюдаемости, особенно его связь с безопасностью, производительностью и надёжностью. Мониторинг необходим для выявления происходящих в продакшене проблем и выбросов, он позволяет командам DevSecOps выявлять и устранять проблемы до того, как они нанесут серьёзный урон. Мониторинг снижения производительности или подозрительной активности может вызывать алерты и автоматическое реагирование для изоляции потенциальных проблем или атак.
В этой статье мы подробно рассмотрим мониторинг, расскажем о нескольких примерах использования, дадим рекомендации, а также поговорим о том, как конкретно мониторинг способен повысить безопасность, производительность и надёжность при помощи наблюдаемости.
Какова роль мониторинга в наблюдаемости?
В наблюдаемой системе мы собираем данные из логов, метрик и распределённых трассировок. В очень маленьких системах можно вручную искать и просматривать логи, визуализировать метрики в виде графиков, а трассировки в виде диаграмм, показывающих, как движется трафик по системе; однако при больших масштабах системы этого недостаточно. Вам будет необходим мониторинг — автоматизированный процесс, отслеживающий эти данные и отправляющий соответствующие алерты. (Более подробно о различиях между мониторингом и наблюдаемостью можно прочитать в этом ресурсе.)
На корпоративном уровне необходимы автоматизированные способы фильтрации, агрегации, обогащения и анализа всех этих данных. Также корпорациям требуются автоматизированные способы принятия мер в случае выявления необычного поведения. Автоматический ответ может уведомить соответствующую команду специалистов или даже напрямую предпринять действия по устранению проблем.
В медицине отслеживание основных жизненных показателей пациентов — это важнейший процесс, спасающий жизни. Мониторинг программных систем очень похож на него, мы даже используем ту же методологию при выполнении проверок «здоровья» и обсуждении состояния разных компонентов.
Но хватит теории, давайте рассмотрим конкретные примеры мониторинга.
Примеры использования мониторинга для наблюдаемости
Вот несколько типичных примеров использования преимуществ мониторинга:
- Веб-приложения являются основной частью многих крупномасштабных распределённых систем и ключом к успеху цифровых бизнесов. Мониторинг Kubernetes, контейнированных приложений или просто логов веб-сервера на излишнее количество кодов ошибок (например,
4xxили5xx) может помочь команде решать проблемы производительности и надёжности ещё до того, как они станут существенными. - На уровне инфраструктуры важно выполнять мониторинг CPU, памяти и накопителей сервера. Как и большинство компаний, вы, скорее всего, используете автоматическое масштабирование, чтобы система могла наращивать свои возможности. Логи платформ фиксируют изменения в ресурсах, например, когда они предоставляются, отзываются и переконфигурируются. Однако мониторинг этих метрик и логов ресурсов помогает обеспечить работу в пределах квот и ограничений, что поможет организации в планировании и составлении бюджета на ресурсы.
- Хранилища данных являются фундаментом большинства крупномасштабных систем. В случае утери, повреждения или недоступности данных возникает серьёзная ситуация. Чтобы отслеживать данные, необходимо выполнять мониторинг соединений баз данных, метрик длительности запросов, дискового пространства, резервных копий и количества ошибок. Также вам нужно разбираться в своих хранилищах данных и задать алерты на случай, когда значения будут находиться вне ожидаемого диапазона, например, в случае медленных запросов, большой частоты ошибок или нехватки места на дисках. Также можно настроить логирование для баз данных, чтобы фиксировать соединения, запросы и изменения в полях или таблицах. Мониторинг логов баз данных помогает выявлять не только возможные сферы повышения производительности и надёжности, но и увеличивать безопасность в случае возникновения злонамеренных (или непредумышленных) операций.
Стоит заметить, что мониторинг — это гораздо сложнее, чем установка простого условия (например, «больше пяти запросов INSERT в базу данных orders за две минуты») и создание алерта в случае выполнения условия. Могут учитываться сезонные изменения, паттерны использования, вызывающие всплески в определённые временные промежутки в течение дня, недели или года. Эффективный мониторинг, выявляющий неожиданное поведение, учитывает контекст и способен распознавать тренды на основе данных прошлого.
Подобный тип мониторинга, особенно в случае его реализации при помощи инструмента, сочетающего в себе наблюдаемость, мониторинг и обеспечение безопасности, может быть чрезвычайно эффективным, например, как в этом анализе примера Sumo Logic и Infor, когда Infor удалось сэкономить пять тысяч человеко-часов, которые раньше тратились на устранение инцидентов.
Какой вклад вносит мониторинг конкретно в повышение производительности и надёжности?
Мониторинг повышает производительность и надёжность системы, выявляя проблемы на ранних этапах с целью предотвращения снижения качества системы. Проблемы с производительностью часто становятся проблемами доступности и надёжности. Это особенно справедливо в случае наличия таймаутов. Например, предположим, что приложение выполняет таймаут спустя 60 секунд. Из-за недавней проблемы с производительностью обработка многих запросов начала занимать больше 60 секунд. Теперь все эти запросы оказываются сбойными, а приложение перестаёт быть надёжным.
Для решения подобных проблем применяется стандартная рекомендация: выполнять мониторинг четырёх «золотых» показателей любого компонента на критическом пути работы высокоприоритетных сервисов и приложений: задержки, трафик, ошибки и насыщение.
▍ Задержки
Сколько времени занимает обработка запроса? Стоит отметить, что задержка успешных запросов может отличаться от задержки сбойных запросов. Любое существенное увеличение задержек может быть показателем ухудшения производительности системы. С другой стороны, любое существенное снижение может быть признаком того, что какая-то часть обработки пропускается. Как бы то ни было, мониторинг привлечёт внимание к возможной проблеме.
▍ Трафик
Мониторинг трафика даёт понимание суммарной нагрузки на каждый компонент. Для разных компонентов трафик может измеряться разными способами. Например:
- REST API: количество запросов
- Бэкенд-сервис: глубина запроса
- Компонент обработки данных: общее количество обработанных данных в байтах
Рост трафика может быть связан с органическим ростом бизнеса, тогда это хороший признак. Однако он также может стать источником проблем для вышестоящей системы, генерирующей необычно большое количество трафика.
▍ Ошибки
Рост количества ошибок любого компонента непосредственно влияет на надёжность и степень полезности системы. Кроме того, если сбойные компоненты автоматически выводятся из работы, это может привести к повышению трафика, что, в свою очередь, ведёт к проблемам с производительностью.
▍ Насыщение
Какую часть имеющихся ресурсов использует сервис или приложение? Именно на этот вопрос даёт ответ мониторинг насыщения. Например, если диск заполнен, то сервис, записывающий логи на этот диск, будет сбоить при каждом последующем запросе. Пример более высокого уровня: если в узлах кластера Kubernetes недостаточно места, новые поды будут ждать обработки и не использоваться, что может привести к проблемам с задержками.
Как вы могли заметить, четыре «золотых» показателя связаны друг с другом. Проблемы часто проявляются в нескольких показателях.
Какой вклад вносит мониторинг конкретно в повышение безопасности?
Хотя любая проблема состояния системы может напрямую или косвенно влиять на безопасность, существуют непосредственные угрозы, которые мониторинг помогает выявить и устранить.
- Причиной любой аномалии, например, избыточного использования CPU или высокого объёма запросов, может быть нападающий, пытающийся вызвать ошибку сегментации, выполнять нелегальный криптомайнинг или запустить DDoS-атаку системы.
- Необычное количество пакетов, поступающих в необычные порты, может быть атакой port knocking.
- Большое количество ошибок 401 (ошибок аутентификации) с действительными именами пользователя и неверными паролями может быть атакой по словарю.
- Высокое количество ошибок 403 (запрет доступа) может быть попыткой повышения привилегий нападающим при помощи скомпрометированного аккаунта.
- Недопустимые нагрузки на публичные API, приводящие к ошибкам 400, могут быть попытками нападающего осуществить аварийное завершение публично доступных веб-приложений.
- Скачивание больших объёмов данных или любых конфиденциальных данных в нерабочие часы может быть атакой эксфильтрации скомпрометированным сотрудником или внутренним злоумышленником.
Рекомендации по мониторингу для повышения производительности и безопасности
Система состоит из множества компонентов, но она больше, чем сумма всех своих частей. На базовом уровне вам следует выполнять мониторинг четырёх «золотых» показателей каждого компонента системы (по крайней мере, на критически важных путях). Что это значит на практике?
- Отслеживание ключевых метрик
- Определение интервалов значений метрик нормальной работы
- Установка алертов на случай отклонения компонентов от приемлемого интервала
Также необходимо уделять большое внимание внешним зависимостям. Например, если система работает в облаке или интегрирована с сервисом стороннего поставщика, то нужно мониторить публичные конечные точки, от которых вы зависите, и устанавливать алерты для выявления проблем. Если сторонний сервис вышел из строя или его производительность снизилась, это может вызывать каскадные сбои в вашей системе.
Никакие компоненты не могут быть надёжными на 100%. Однако мониторинг поможет помочь создать надёжную систему из ненадёжных компонентов, выявляя проблемы компонентов (как внутренних, так и внешних) и заменять их или справляться с ухудшением качества сервиса. Например, если система работает в многозонной конфигурации и в одной зоне возникла проблема, то мониторинг может обнаружить это и запустить перенаправление (вручную или автоматически) всего трафика в другие зоны.
В сфере безопасности четыре «золотых» показателя также могут быть дополнительными индикаторами компрометации. Особенно это справедливо для случая, когда, например, вы видите всплеск использования CPU устройства в конечной точке или облачной рабочей нагрузки, или увеличение количества неудачных попыток входа. Однако мониторинг безопасности должен быть очень продуманным, ведь вы имеете дело со злоумышленниками. Необходимо определить поверхность атаки каждого компонента и всей системы, а также убедиться, что собираемой вами информации достаточно для выявления проблем. Например, для выявления эксфильтрации данных можно выполнять мониторинг IP-адресов и объёмы данных, передаваемых за пределы внутренней сети различными приложениями и сервисами. Если у вас нет таких данных, то вы слепы против подобной методологии атак.
Внедрение стратегии мониторинга
Настроив сбор данных, можно выполнить представленные ниже шаги для внедрения надёжной и эффективной стратегии мониторинга.
▍ 1. Выявите критически важные ресурсы
В процессе сбора данных вы уже выполнили исчерпывающую инвентаризацию всех своих ресурсов. Теперь ваша задача заключается в том, чтобы выявить критически важные ресурсы, которые нужно тщательно мониторить для предотвращения катастроф и устранения их последствий. Можно просто сказать «давайте мониторить всё», но мониторинг связан с затратами. Мониторинг и алерты в промежуточных окружениях и окружениях разработки, а также в экспериментальных сервисах могут создавать ненужный стресс у инженеров. Частые алерты в три часа утра из-за несущественных проблем могут вызвать усталость от алертов, снижая мотивацию команды к устранению проблем, когда они действительно серьёзны.
▍ 2. Назначьте ответственного за каждый критически важный ресурс
Выявив критически важные ресурсы, нужно чётко определить ответственного за каждый из них. Ответственный может быть человеком или командой. Если это один человек, также назначьте ему заместителя. Также важно регулировать ответственность за ресурсы при найме и увольнении людей, а также при переходе на другие должности и в другие команды.
▍ 3. Задайте алерты для критически важных ресурсов
В конечном итоге, жизнь или смерть вашей стратегии мониторинга зависит от того, как вы зададите алерты для ресурсов, имеющих плохое состояние или имеющие потенциал для компрометации. Вам нужно понять, что нормально для каждого из ресурсов.
Если вы выполняете мониторинг метрик, то под определением «нормального» подразумевается задание атрибуту (например, использованию CPU) интервала значений (например, «50%-80%»). Интервалы нормальности могут динамически меняться с изменениями в бизнесе и могут варьироваться в зависимости от времени и места. В некоторых случаях могут быть только максимальные или минимальные значения. Задавая интервалы нормальных значений, вы создаёте алерты, уведомляющие ответственного за ресурс, что его ресурс работает вне пределов нормального интервала.
Если вы выполняете мониторинг логов, то алерты обычно задаются на основании результата определённых запросов логов (например, «количество ошибок 404, зафиксированных во всех API-сервисах за последние пять минут»), удовлетворяющих или не удовлетворяющих условию (например, «меньше 10»). В этом вам могут помочь инструменты управления логами и их аналитики.
▍ 4. Создайте Runbook для каждого алерта
Что делать, когда сработает критичный алерт? Вы не должны придумывать стратегию на ходу, пока клиенты жалуются в твитах на ненадёжность продуктов вашей компании, а руководство паникует.
Runbook — это рецепт, состоящий из простых шагов; он подготавливается и тестируется заранее, чтобы помочь вам собирать дополнительную информацию (например, инструкции о том, на какие дэшборды нужно смотреть и какие скрипты командной строки выполнять для диагностики первопричин) и устранять проблемы (например, развернуть предыдущую версию приложения). Ваш runbook должен помогать вам быстро выявить конкретную причину проблемы и определить, кто лучше всего справится с её устранением.
▍ 5. Организуйте процесс дежурств
У вас есть ответственные, алерты и runbook-и. Часто алерты бывают недостаточно конкретными, чтобы связать их с конкретным ответственным. Лучше всего назначать дежурных (on-call) инженеров в разных областях бизнеса. Этот дежурный инженер получает алерт, выполняет инструкции runbook-а, смотрит на дэшборд и пытается понять первопричину. Если он не может понять или устранить проблему, то передаёт её ответственному. Помните, что этот процесс может быть сложным; часто проблема возникает из-за цепочки сбоев и для решения требуется совместная работа нескольких руководителей.
▍ 6. Двигайтесь в сторону автоматического устранения проблем
Runbook — это отлично, однако поддержка сложных runbook-ов и обучение пользования ими дежурных инженеров требует много усилий. А в конечном итоге процесс устранения проблем всё равно зависит от медленного и ошибающегося человека. Если ваш runbook неактуален, то выполнение его инструкций может усугубить кризис.
Теоретически, runbook может исполняться программно. Если в runbook-е говорится «при срабатывании алерта X нужно перезапустить процесс Y», то скрипт или программа могут получать уведомление алерта X и перезапускать процесс Y. Та же программа может выполнить мониторинг процесса Y после перезапуска, убедиться, что всё в порядке и сгенерировать отчёт об инциденте. И всё это без необходимости будить дежурного инженера. В случае сбоев действий по автоматическому устранению проблемы можно связаться с дежурным инженером.
▍ 7. Организуйте процесс постмортемов
Автоматическое устранение — отличная система, однако болезнь легче предупредить, чем лечить её, поэтому лучше предотвращать возникновение проблем. Каждый инцидент — это возможность учиться и потенциально предотвращать целый класс проблем. Например, если множество инцидентов произошло из-за того, что код с багами добрался до продакшена, то из постмортемов можно извлечь урок и улучшить тестирование на промежуточном этапе. Если реакция дежурного инженера на алерт была слишком медленной или устарел runbook, это может говорить о том, что команде нужно вложить средства в практики автоматического устранения проблем.
Заключение
Мониторинг — критически важная часть наблюдаемости в целом и конкретно наблюдаемости в целях безопасности. При больших масштабах систем людям не имеет смысла просто постоянно следить за разными дэшбордами и графиками для выявления проблем. Вам нужен целый набор практик реакций на инциденты, включающий в себя назначение ответственных, настройку алертов, написание runbook-ов, автоматизацию runbook-ов и организацию процессов дежурства и постмортемов.
Автор:
ru_vds
