Есть мнение, что Black Box подход к мониторингу хуже, чем White Box. Мол, мы получаем от него мало информации. Данных действительно немного, но мы можем развить нашу систему Black Box мониторинга и добиться довольно информативной системы контроля, которую мы условно назвали «внешнее observability».
В этой статье расскажем, как это сделать, и дадим несколько советов:
Как поддерживать Black Box в актуальном состоянии;
Black Box мониторинг как аудит безопасности;
Как работать с алертами в Black Box;
Как сделать геораспределённый мониторинг;
Как использовать Black Box с кешированием.
Экспертным мнением поделились спикеры Слёрма Павел Лакосников и Максим Гусев.
Начнём с необходимой базы: что за Black Box и White Box и почему под определённым углом зрения Black Box может превратиться в White Box. Если вы хорошо знакомы с теорией, то пролистывайте дальше.
Два подхода к мониторингу
Есть два разных подхода к мониторингу систем: White Box и Black Box.
Рассмотрим эти два подхода на простом примере. Представим себе очередь в банк.
Исходя из этих данных, у нас может сложиться мнение, что White Box намного круче. На самом деле — нет. Это всего лишь разные аспекты мониторинга и нельзя говорить, что один из них важнее, чем другой.
???? Разница в том, что Black Box рассказывает вам, как пользователь воспринимает вашу систему, а White Box то, как её воспринимаете вы. И тот и другой тип мониторинга должны сочетаться и усиливать друг друга.
Когда Black Box может превратиться в White Box?
Когда мы наблюдаем симптом в Black Box, мы не знаем, как он влияет на систему, и что на самом деле происходит внутри. Пример: стоя снаружи отделения банка, мы не знаем, что происходит внутри него. Аналогично с White Box: когда мы стоим внутри банка, мы не знаем, есть ли очередь на улице.
Этот вывод напоминает один из тезисов теории относительности — всё зависит от точки зрения на объект или процесс. Более того, иногда невозможно определить — это White Box или Black Box в чистом виде.
Пример: у нас есть взгляд на наш сервис с двух точек: 1 — в целом, 2 — на Redis кеш.
Вот что мы видим:
В Redis кеш мы видим рост 500-к — это внешнее проявление работы самого Redis. Но мы не знаем, как Redis работает, видим только 500-ки. Если мы сделаем White Box уже внутри Redis, то увидим, что у нас проблема с dump данных. Redis что-то сейвит.
???? То есть когда мы спускаемся на уровень абстракции повыше или пониже, то Black Box превращается в White Box. White Box снова может стать Black Box, если мы посмотрим на этот компонент относительно чего-то другого.
Что принято мониторить в Black Box
Чаще всего принято мониторить:
доступность сайтов;
время ответа;
SSL-сертификаты;
конкретные проверки: например, header в теле сайта.
Рассмотрим несколько советов, которые могут усилить Black Box мониторинг и дать больше понимания о том, что происходит в системе.
Совет 1. Расширьте проверки тех сервисов, с которыми взаимодействуют пользователи.
Если вы используете Kafka, то помимо простых ответов, о том всё ли хорошо, можно узнавать, что вообще есть в топиках, готовы ли консьюмеры принимать коннекты.
Другими словами, можно мониторить те части сервиса, с которыми взаимодействуют ваши пользователи.
Например, для буровой установки Black Box мониторинг — это:
как часто запускают установку;
как она работает внешне;
как с ней взаимодействуют операторы.
Если сайт по продаже мягких игрушек, то:
доступность этого сайта;
как он открывается;
может ли он работать;
какие-то внешние метрики (например, Яндекс Метрики).
В итоге вы не знаете, что внутри и как именно работает система, но при этом уже получаете общее представление, что с ней происходит.
Совет 2. Настройте мониторинг в разрезе отдельного сервиса и в разрезе целого приложения.
Black Box мониторинг сервиса
Сейчас большие IT-системы состоят из огромного количества разных сервисов. В разрезе сервисов можно мониторить:
Хелсчеки. То, с какой периодичностью происходит хелсчек и является Black Box мониторингом сервиса.
Потребление CPU.
Объем данных, который прокачивается через сервис.
Количество событий на вход, если используется Kafka. Мы не знаем, что происходит внутри, как проецируется, какие задержки идут, но мы можем оценить у систем очередь на вход.
Black Box мониторинг приложения
В разрезе приложения ведётся мониторинг всей IT-системы. Здесь подходы немного другие. Можно:
Пинговать сайт. Для этого подойдет go-pinger. Например, для компании-провайдера можно создать Black Box мониторинг просто через пинговалку основных свичей и коммутаторов: если свич отвечает, значит, внутри свича всё нормально. Но такие методы дают очень мало информации, так как все ещё не дают понимания, что происходит в целом.
Открывать главную страничку вашей IT-системы, если это веб-сервис. Можно проверить curl'ом код 200 на главную. Есть вариант посложнее — проверить наличие основных блоков, которые хотят увидеть на сайте пользователи.
Время ответа. Его тоже надо замерять. Но нужно определить, какую скорость вы будете считать нормальной, а какую — медленной.
Проверять картинки, статику, js, css, если это веб-сервис. Проверяйте, что страница рендерится, ссылки на статику открываются, ничего нигде не ломается. В этом случае стоит еще проверить и CDN (Content Delivery Network).
Сложно ли построить проверку блоков и элементов сайта? Нет, ведь подходы к тому как оформлять внутренне JSON-RPC уже достаточно стандартизированы. Поэтому вычитывайте body и стройте по нему какой-нибудь мониторинг. Но тогда нужно будет поддерживать вашу систему мониторинга в актуальном состоянии и реагировать на изменения.
Как поддерживать Black Box мониторинг в актуальном состоянии
Если проект развивается динамично, то может возникнуть ситуация, когда разработчики перенесут сервис на другой URL, обновят API или поменяют протокол. При каждом таком изменении мониторинг будет рассыпаться. Что делать, чтобы поддерживать его в актуальном состоянии и быстро подстраиваться под изменения системы?
Совет 3. Опирайтесь на надёжные таргеты для Black Box мониторинга
Поддерживать такую систему мониторинга сложнее, чем просто пинговалку. Вот несколько возможных решений:
Опираться на то, что редко меняется.
Сделать конвенцию, чтобы никто не переименовывал нужный URI.
Разработать корпоративный стандарт хелсчеков и URL, по которым сервисы будут отвечать.
С одной стороны создание конвенций — это закручивание гаек, но с другой — удобство: проще разрабатывать, проще деплоить, повышается observability системы.
Black Box мониторинг как аудит безопасности
У Black Box подхода есть кое-что общее с пентестами. Penetration testing — тестирование на проникновение, смысл которого в том, чтобы найти уязвимость и сообщить о ней владельцу сервиса. В его интересах ликвидировать уязвимость до того, как ею воспользуются злоумышленники.
Общее заключается в том, что для этих двух практик система представляет собой черный ящик. Мы не знаем, что там внутри. Начинаем вслепую её ощупывать. Может получиться такой алгоритм:
Задаём себе вопрос: какая у веб-сервиса CMS? Например, Wordpress.
Ищем админку. Находим и выясняем версию Wordpress.
Снова задаём вопрос: какие могут быть у этой версии популярные плагины?
Находим плагины и информацию о том, какие у них могут быть уязвимости.
Сканируем сервис по каждой из них, пока не найдем уязвимость.
Совет 4. Попробуйте найти уязвимости как пентестер.
Это тоже по сути Black Box, но не мониторинг, а анализ системы. Попробуйте поискать уязвимости. Лучше, если проблему обнаружите вы, чем какой-нибудь злодей. Для такого SecOps'а можно использовать, например, Prometheus. Накинуть ему URL и смотреть фидбэк. И если, например, URL авторизации, который не должен торчать наружу, вдруг по какой-то причине стал доступен, — заводим алерт.
Как работать с алертами в Black Box мониторинге?
Здесь стоит признать, что связка Black Box и алертинг — это больно. Возможно она будет полезна только для техлида, который очень хорошо ориентируется во всей системе. Black Box мониторинг не говорит, что именно сломалось, поэтому нужно хорошо разбираться в системе, чтобы решить проблему.
В реальной работе алерт с Black Box мониторинга может выглядеть так:
Прилетает алерт, что на какой-то странице время превысило 1,5 сек. Идём на страницу, а она состоит из 50 компонентов. Получается, что нужно найти:
Что это за страница;
Какой у нее внутренний нейминг;
Какой сервис её обрабатывает;
Из чего она состоит;
Что же там может нагенерить такое большое время.
Кроме того, нужно выяснить, у всех ли страниц это время такое большое, или, может быть, это разовый выброс. Нужно пройти по всей системе сверху вниз, чтобы выяснить причину. Не забыть учестьи другие возможные факторы: проблемы с load balancer, нехватка ресурсов, проблема на стороне провайдера.
Короче, сложно. Что можно предпринять?
Совет 5. Постройте алертинг на основе кворума.
Можно попробовать отсечь некоторые из факторов мониторингом с двух точек. Тогда алерт будет вылетать только в случае, если метрики с двух точек будут идентичны. Допустим, если один из экспортеров говорит, что сайт не отвечает, но второй при этом говорит, что все замечательно, значит проблема там, где не отвечает. Экспортеры могут находиться, например, в разных точках мира. Если оба экспортера говорят, что сайт не отвечает, значит это реально проблема. Привет, алерт!
Эту схему можно реализовать только если у нас есть доступ к сервису с разных точек. Если закрытый контур, то придётся изобретать другой способ получить кворум.
Геораспределённый мониторинг
Геораспределённый мониторинг легче всего реализовать с помощью нескольких облаков, которые расположены в разных регионах. Это поможет сформировать представление о том, как вашу систему видят пользователи из разных уголков страны или мира.
Практика 6. Постройте геораспределённый мониторинг.
Такой мониторинг может быть основан на той же самой пинговалке или на проверке сертификатов. Если нужна более развесистая система, можно мониторить:
пропускную способность;
доступность основных узлов;
CDN;
Latency.
Пример: Есть сайт объявлений, которым пользуются люди со всей страны. У пользователей отдалённого региона работает только 3G, поэтому большая часть запросов оттуда отваливается по таймауту. Большие пакеты просто не пролезают в 2G за нужную дельту времени. Геораспределённый мониторинг позволяет выявить эту закономерность.
Совет 7. Собирайте данные у самого пользователя.
Ещё один подход заключается в том, чтобы реализовать сбор данных максимально близко к пользователю. Если работаете с мобильным приложением, организуйте прямо в нём сбор и отправку метрик. По сути, благодаря этому вы получите геораспределенный мониторинг.
Black Box мониторинг с учётом кеширования
Кеширование усложняет задачу построения системы Black Box мониторинга. Если сайт уже отвалился, то кеширующий сервис будет отдавать нам его, например, ещё целый час. Получится, что Black Box мониторинг прав — пользователь действительно получает сайт, но для нас — это проверка работы кеша, а не сайта. Нас это не устраивает. Как обойти кеширование и мониторить железо, которое отдаёт нам сайт?
Совет 8. Сделайте прозрачный туннель или воспользуйтесь готовым решением от сервиса кеширования.
Здесь нет универсального решения. Можно сделать туннели до сайта, но это непростая задача. Да и результат может быть слишком хрупким. Более простой способ — воспользоваться готовыми решениями, которые предоставляют некоторые кеширующие сервисы. В них можно задать определенный header и ходить напрямую к таргету кеширования, то есть до конечной точки.
Совет 9. Разнообразьте таргет-список.
Ещё одно решение — изначально спроектировать разнообразный список того, что чекаешь. Например, максимально расширить хелсчеки и проверки. Больше данных — больше понимания, что происходит на самом деле.
Итоги: Как развить Black Box мониторинг своих систем
Систему Black Box мониторинга можно развить до уровня, который мы условно назвали «внешнее observability». Это полезно, если простой вашего приложения обходится гораздо дороже, чем стоимость услуг по мониторингу. Однако вы столкнётесь с тем, что по некоторым проблемам нет универсального решения. Вот шаги, которые можно предпринять:
Начните с определения проблемы, которую вы хотите решить мониторингом.
Внедрите простые способы Black Box мониторинга: пинговалки, проверки статусов с разных точек. Настройте загрузку данных и выгрузку статистики. Для этого можно использовать как встроенные сервисы провайдеров, так и Prometheus.
Поддерживайте Black Box мониторинг в актуальном состоянии. Опирайтесь на надёжные метрики, создавайте конвенции.
Попробуйте проверить своё приложение как пентестер. Это поможет выявить уязвимости до того, как ими воспользуется злоумышленник.
Настройте алерты. Продумайте заранее, как вы будете на них реагировать и кто будет ответственный. Поскольку Black Box мониторинг даёт мало информации, удостоверьтесь, достаточно ли компетентен этот человек, чтобы понять, что происходит. Кого он будет будить среди ночи, если не разберётся сам? Здесь может быть полезна SRE-практика с ранбуками, в которых для инженера расписываются все шаги: куда смотреть, что предпринимать, кого будить.
Постройте геораспределённый мониторинг. Посмотрите, как ваше приложение видят пользователи из разных регионов.
Учитывайте кеширование. Проверьте, чтобы ваш мониторинг мониторил ваше приложение или сайт, а не сервис кеша.
Помните основной принцип — найти баланс между сложностью и дороговизной системы мониторинга и профитом от нее.
????️ Статья подготовлена по материалам вебинара Внешнее observability а-ля black-box. Ведущий: Максим Гусев, SRE в Dodo Engineering. Эксперт: Павел Лакосников, Team Lead команды SLA в Авито.
Если у вас не хватает знаний по сбору метрик, настройке визуализаций и алертинга, приходите в Слёрм на курс «Мониторинг в Grafana». Вы научитесь выбирать метрики, работать со связкой Prometheus+Grafana и читать созданные графики. В результате получите контроль над системой и повысите надёжность сервиса.
???? Посмотреть программу курса.
Если вы SRE, то приходите на курс «SRE: Observability». Научитесь агрегировать SLO/SLI в одну или несколько высокоуровневых метрик, работать с алертами и инцидентами, оценивать надёжность, рассчитывать error budget.