Проекты ломаются, иногда очень коварно. Крупные компании используют различные подходы, чтобы обеспечить наблюдаемость, покупают дорогие сервисы, нанимают 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, можно было еще лучше. Если у вас есть идеи, что еще было бы полезно реализовать для обеспечения наблюдаемости, или знаете хорошие решения, буду рад обсудить в комментариях.