Мы всегда хотели, чтобы наше облако было удобным и отвечало потребностям бизнеса клиентов. Поэтому в какой-то момент оно перестало быть просто «тучей» с виртуалками — у нас появились платформенные сервисы, которые широко используются на рынке облачных решений.

Что такое PaaS

PaaS (Platform as a Service) — это промежуточное состояние между услугой IaaS (Infrastructure as a Service), когда вы арендуете CPU, RAM и диски и на этой инфраструктуре развертываете все самостоятельно, и моделью SaaS (Software as a Service), когда за вас уже все развернули и отдали вам конечный пользовательский интерфейс.

Чаще всего PaaS — это базы данных, такие как PostgreSQL, или рантайм, например, Kubernetes. Конечно, мало кому удается пользоваться PaaS в повседневной жизни как почтой или облачным хранилищем фоток, хотя оставлять друг другу сообщения в аннотациях к подам k8s выглядит очень романтично. Но главное преимущество PaaS в том, что вам не нужно деплоить такие сервисы самостоятельно, разбираться в тонкостях настройки и сопровождения, копаться в конфигах и т. д. Провайдер позаботился, чтобы у вас были готовые среды для создания продуктов.

В конце концов, PaaS — это просто красиво: вы нажали несколько кнопок, произошла какая-то магия и вуаля, через 5-10 минут у вас готовый настроенный облачный сервис.

Но совсем оставить работу PaaS без внимания не получится. В этой статье мы с вами разберемся, как следить за состоянием и производительностью PaaS.

Александр Дубский

Руководитель группы архитекторов по облачным решениям K2 Cloud

Главное преимущество PaaS в том, что вам не нужно деплоить такие сервисы самостоятельно, разбираться в тонкостях настройки и сопровождения, копаться в конфигах и т. д. Провайдер позаботился, чтобы у вас были готовые среды для создания продуктов.

Мониторинг PaaS

За чем обычно нужно следить:

здоровье облачного сервиса (он в принципе работает, не упал),
производительность сервиса (как быстро он работает),
надвигающиеся проблемы (не ляжет ли он в ближайшее время).

Сбор анамнеза

В основе PaaS лежат виртуальные машины. В нашем облаке вы видите виртуалки PaaS в общем списке экземпляров виртуальных машин, поэтому, как минимум, вам доступны базовые показатели утилизации на вкладке «Метрики» в карточке экземпляра.

По умолчанию там отображаются графики загрузки процессора, сетевых интерфейсов и дисков. Можно выбрать, за какой интервал времени отображать утилизацию, а также какие значения показывать за этот интервал: средние, минимум, максимум.

Хитрость заключается в том, что усреднение происходит не только за интервал времени, но и по всем процессорам, интерфейсам и дискам. Вы не можете в карточке ВМ увидеть загрузку конкретного процессорного ядра или жесткого диска. Этот нюанс может вводить в заблуждение, например, средняя загрузка CPU может держаться на уровне 30-40% и не вызывать беспокойства, однако внутри ОС может работать однопоточное приложение, которое из всех доступных ядер утилизирует только одно на 100%, из-за чего работа сервиса становится нестабильной. То есть метрики виртуальной машины могут дать первичное представление о состоянии машины в беглом анализе, но для детальной диагностики данной информации будет недостаточно.

Также надо отметить, что по умолчанию на вкладке «Метрики» отсутствует график утилизации оперативной памяти. Дело в том, что эту информацию невозможно получить на уровне гипервизора KVM, поэтому включение мониторинга RAM настраивается отдельно путем установки внутри гостевой ОС специального агента cw-agent. При создании новой ВМ, для которой нужно включить мониторинг RAM, нужно поставить соответствующую галочку и прочитать инструкции по ссылке на документацию.

Инструментальное обследование

Как мы с вами уже поняли, метрики виртуальных машин подходят для быстрой оценки, но не годятся для детального анализа. Посмотрим, что для этого есть в арсенале К2 Облака. Все наши PaaS построены на базе Linux, а для детального мониторинга мы используем решения из экосистемы Prometheus, куда входит сам сервер мониторинга Prometheus, его компонент Alertmanager, ответственный за оповещения о сбоях, а также экспортеры — набор специальных агентов на конечных ВМ. Под каждый тип сервиса существует свой экспортер, который досконально знает свой сервис и может извлекать из него множество детальной информации и статистики. Экспортер работает рядом с сервисом, на той же виртуальной машине, а также он имеет специальный http-эндпойнт, обратившись на который в любой момент времени можно получить набор метрик вида:

# HELP pg_database_connection_limit Connection limit set for the database
# TYPE pg_database_connection_limit gauge
pg_database_connection_limit{datname="db2"} -1
pg_database_connection_limit{datname="db3"} -1
pg_database_connection_limit{datname="postgres"} -1
pg_database_connection_limit{datname="template0"} -1
pg_database_connection_limit{datname="template1"} -1
# HELP pg_database_size_bytes Disk space used by the database
# TYPE pg_database_size_bytes gauge
pg_database_size_bytes{datname="db2"} 1.7805871e+07
pg_database_size_bytes{datname="db3"} 8.614447e+06
pg_database_size_bytes{datname="postgres"} 8.679983e+06
pg_database_size_bytes{datname="template0"} 8.442415e+06
pg_database_size_bytes{datname="template1"} 8.589871e+06

Prometheus с определенной периодичностью (например, раз в 15 сек) опрашивает эндпойнты экспортеров и агрегирует полученную информацию в виде временных рядов в своей TSDB. Отдельно для Prometheus настраиваются правила алертинга, для написания которых используется специальный язык PromQL (Prometheus Query Language).

Каждое правило содержит выражение, значение которого Prometheus рассчитывает и сравнивает с целевым, определенным в данном правиле. Если значение отклоняется от целевого и не возвращается обратно дольше, чем разрешено интервалом правила, возникает алерт, и пользователи получают сообщение в настроенный канал оповещения. Каналы могут быть разные, начиная от простой электронной почты и заканчивая специальными системами и мессенджерами.

Для визуализации метрик в виде графиков традиционно применяется Grafana, которая в этой области является стандартом де-факто. Grafana очень функциональна и удобна, позволяет гибко настраивать графики, например, накладывать несколько метрик на одну шкалу, фильтровать данные, менять представления данных, использовать разные цветовые схемы для наглядности.

Вот, к примеру, дашборд с разнообразными панелями, которые на произвольный момент времени (текущий или в прошлом) отображают состояние и различные показатели сервиса PostgreSQL.

Обладая такой объективной информацией, можно гораздо больше сказать о работоспособности и производительности вашей системы.

О надвигающихся проблемах можно судить по тенденциям на графиках, особенно если выбрать широкий интервал времени, например, в неделю. Так можно отследить утечки памяти (на графике будет виден непрерывный рост ее потребления) либо переполнение дискового пространства. Вот пример утечки памяти у приложения.

Лечение

Такую систему мониторинга для ваших PaaS в нашем облаке тоже можно запустить по кнопке. Для этого существует специальный PaaS с теперь уже очень понятным названием Prometheus, но он также включает в себя и Grafana. И если он у вас развернут наряду с другими сервисами PaaS, то их мониторинг легко подключить в этот Prometheus одной галочкой.

Как и положено в уважающем себя облаке, все уже сделано за вас. Как только вы подключите PaaS к Prometheus, у вас автоматически создадутся преднастроенные правила алертинга для данного сервиса, а также в Grafana добавятся соответствующие дашборды. Вам только останется настроить каналы оповещения, куда К2 Облако будет присылать нотификации.

Сопутствующие диагнозы

А что же делать, если у вас уже есть своя система мониторинга и вы хотите следить за состоянием PaaS-сервисов из нее? Если ваша система мониторинга тоже Prometheus или совместима с ней (например, Victoria Metrics), то вы легко можете настроить протокол remote-write на PaaS Prometheus. Для этого в настройках вам нужно указать эндпойнт вашей системы мониторинга (он должен быть тоже в К2 Облаке или доступен из него по сети), и наш Prometheus будет пересылать все собираемые с экспортеров метрики вам. Если ваша система мониторинга — Zabbix, то это тоже не проблема, Prometheus может через настройку федерации отдавать свои накопленные метрики в Zabbix. Подробно здесь я на этом останавливаться не буду, но если у вас стоит подобная задача, обратитесь к нашим специалистам.

Бывает и обратная ситуация, когда вы хотели бы сделать PaaS Prometheus вашей основной системой мониторинга. Но как в нее собирать информацию с других ваших информационных систем, если они не являются PaaS?

Для этого тоже есть варианты:

можно вручную или с нашей помощью поставить на ваши виртуальные машины нужные экспортеры, а затем в настройках PaaS Prometheus указать их в разделах,
можно активировать в нашем Prometheus функцию remote-write receiver, и тогда он сможет принимать метрики, которые собирают другие ваши Prometheus-like системы.

Заключение

PaaS — это не только про «нажал кнопку и все заработало», но и про то, как сделать так, чтобы оно продолжало работать быстро, стабильно и без сюрпризов. Базовые метрики помогают понять общую картину, а полноценный мониторинг через Prometheus и Grafana — заглянуть сервису под капот: вовремя заметить узкие места, поймать утечки памяти, настроить алерты и не ждать, пока все упадет в самый неподходящий момент. И самое приятное — в К2 Облаке вся эта история уже собрана и автоматизирована, так что вместо бесконечной возни с настройками можно заниматься тем, ради чего PaaS вообще придумали: быстро запускать сервисы и спокойно ими пользоваться.

Если вдруг оказалось по итогу прочтения, что ничего непонятно, но очень интересно — милости просим к нам в профессиональные сервисы, мы сделаем все за вас!