Проекты ломаются, иногда очень коварно. Крупные компании используют различные подходы, чтобы обеспечить наблюдаемость, покупают дорогие сервисы, нанимают SRE-инженеров. Но если проект небольшой, условный телеграм-бот, многие решения по мониторингу могут быть избыточными. А в нашем облаке Amvera, пользователи, преимущественно, хостят такие маленькие проекты. И перед нами стала задача обеспечить для них Observability так, чтобы это было максимально просто, дешево(желательно бесплатно) и обеспечивало лучшие SRE-практики для наших пользователей. Так, чтобы пользователи получили опыт наблюдаемости работы сервисов, близкий опыту крупной компании с SRE-отделом, только без сложности настройки и условно бесплатно.
Три кита, на которых стоит наблюдаемость, и четыре золотых сигнала SRE
Для обеспечения наблюдаемости обычно используют логи, метрики и трассировки (и на них можно еще повесить алерты). И существуют “золотые сигналы” SRE.
1. Задержка(Latency) — показывает скорость отработки запросов и ее изменение.
Так, для себя мы сделали специальное приложение, которое пингует наши сервисы и производит некоторые стандартные операции (сборка проекта и т.д.) и присылает алерты в случае аномалий и ежедневную статистику задержек.
2. Трафик (Traffic) — как влияет количество пользователей/операций на поведение системы. Как пример, мы знаем, что в нашем сервисе в час пик сборки проходят на 20 — 30% дольше тех, которые пользователи запустили ранним утром.
3. Ошибки (Errors) — тут все просто, это ошибки)
4. Насыщенность (Saturations) — насколько близок сервис к своим возможностям по потреблению ресурса. Как пример — при использовании CPU на значение стремящееся к 100% (я бы сказал 90%) вы можете наблюдать фактическую деградацию производительности приложения. За потреблением ресурса полезно следить и не загонять его в “Красную” зону.
Я постараюсь рассказать, как мы реализовали базовую встроенную наблюдаемость для наших пользователей и какие сервисы используем сами.
Мы реализовали самый простой функционал, который закроет основные потребности в наблюдаемости приложений.
Логи и ошибки по ним
Раньше мы просто стримили логи в интерфейс пользователей. Это помогало для развертывания проектов, но об ошибках вы бы узнали только постфактум.
Мы добавили алерты в телеграм бот, если в логе встречается определенная фраза. Теперь пользователи могут задать любое слово или фразу, и если оно встретится в логе, получить уведомление на почту.
Разумеется, просто error вам мало что даст, лучше задавать конкретные предложения, характеризующие те ошибки, которые вы хотите отслеживать.
Превышение лимита по ОЗУ и CPU
В приложениях бывают утечки памяти, да и просто может повышаться нагрузка. Для отслеживания этих моментов мы сделали алерты на превышение ОЗУ и CPU.
Ошибки сборки и запуска
Будет полезно, чтобы понять, развернулась ли новая версия. Для этого можно настроить тригеры на ошибки сборки или запуска.
Поддержка liveness и readines проб
Полезно отслеживать, в каком состоянии находится ваше приложение, готово ли оно взаимодействовать с сетью и т.д. Для этого мы реализовали поддержку liveness и readines проб.
Пробы k8s не предполагают функционала для уведомления по какому-либо критерию, но наша система принимает решение на основе ивентов Kubernetes. Уведомление отправляется в результате получения ивента с информацией о негативной пробе. Например, если readiness probe оказалась негативной, Kubernetes дает ивент с сообщением, которое начинается «Readiness probe failed…».
Падение проекта
Если ваш проект проработал минимум 30 минут, упал в ошибку и не может перезапуститься в течение 7 минут, вы получите сообщение об ошибке.
Метрики
Для отслеживания динамики потребления ресурсов есть встроенные метрики.
Логи
И логи для анализа работы приложения.
Если вы решили организовать наблюдаемость самостоятельно
Вам потребуются инструменты для сбора логов, метрик, трейсов(возможно) и отслеживания uptime работы сервисов.
Для логов хорошо подойдет ELK/OpenSearch (но это сложные и часто избыточные решения) или Grafana Loki.
Для метрик мы сами используем Grafana+Prometheus, но планируем перейти на VictoriaMetrics из-за большей стабильности и необходимости хранить длинную историю.
Пинг сервисов можно выбрать любой, на рынке много как бесплатных, так и платных решений.
Остальные решения относятся скорее к профессиональным решениям для сложных систем.
Пока реализованная нами функциональность покрывает только часть пунктов, которые принято отслеживать в SRE, но зато она бесплатна и встроена из коробки. Cо временем мы добавим и другие алерты, чтобы отслеживать работоспособность приложений, запущенных в Amvera, можно было еще лучше. Если у вас есть идеи, что еще было бы полезно реализовать для обеспечения наблюдаемости, или знаете хорошие решения, буду рад обсудить в комментариях.