Мониторинг инфраструктуры: как избежать простых и неправильных решений

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

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

Привет, Хабр! Я — Андрей Камардин, SRE-инженер одной из российских облачных компаний, старший преподаватель в МАИ и эксперт Skillbox по DevOps. Веду канал «Записки про IT». Для закрытого комьюнити Skillbox IT Experts рассказал, как мы настраивали мониторинг инфраструктуры для принятия решений.

Какие показатели мониторинга нам нужны

В моей практике задачи, которые решаются с помощью мониторинга  попадают в одну из трёх групп.

1. Предоставление данных разработчикам. Им важно понимать насколько хватает мощности, правильно ли распределены ресурсы и не перерасходуется ли бюджет.

2. Интересы заказчика. Задача любого заказчика  – максимально экономно использовать доступные средства. Обычно заказчик ориентируется на потребности разработчиков и увеличивает или сокращает заказ в зависимости от нагрузки. При этом приоритет отдаётся экономии средств, но без ущерба для работоспособности.

3. Интересы поставщика. Наша задача как поставщика — предоставлять максимально точную оперативную информацию об использовании ресурсов заказчикам и потребителям. А также прогнозировать спрос на услуги. Мы анализируем, насколько активно клиенты используют платформу, чтобы понимать, когда нужно расширять инфраструктуру. Например, не построить ли нам новый дата-центр , смонтировать новое  оборудование, в общем, планировать развитие наших сервисов.

Для сбора и представления данных мы анализируем задачи из этих групп. Так становится понятно какие параметры надо отслеживать. На самом деле, это не так сложно, как может показаться.

Основные показатели в наших дашбордах:

• Предоставленные ресурсы — сколько вычислительных мощностей доступно клиенту.

• Используемые ресурсы — насколько они загружены.

Сложности и интереса задачам добавляет то, что у нас мультивендорная инфраструктура, то есть оборудование разных производителей, мы не ограничены одним. Кроме того, импортозамещенная – в ряде сегментов используется только отечественное оборудование и программное обеспечение, что создаёт нам технические вызовы и подогревает интерес к их решению.

Как мы собираем данные

У нас классическая архитектура сбора данных. Мы используем множество прокси для снижения нагрузки на сервер, так как Zabbix-сервер у нас хоть и отказоустойчивый, но один, и PostgreSQL – для хранения данных – тоже в отказоустойчивом кластере.

Для некоторых прокси база данных развёрнута отдельно, так мы немного выигрываем в производительности и лучше адаптируемся к особенностям нагрузки. Но обычно БД прокси находится с ней на одной машине.

Возвращаясь к нашим задачам: пора выбирать метрики. И вот здесь начинаются первые настоящие сложности.

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

Сначала мы поддались соблазну всё упростить и показали наши инженерные дашборды — те, что с ключевыми показателями состояния платформы. Но оказалось, что оперативные данные мало подходят для принятия бизнес-решений, кроме того, требуются вообще другие показатели.

И здесь требуются некоторые пояснения.

Представьте, например, что вы купили в облаке виртуальную машину для вашего приложения. У неё есть виртуальные CPU, память и диски. И чтобы решить, нужны ли дополнительные ресурсы для этой ВМ или пора покупать дополнительные, вы будете оценивать, как работает ваше приложение: успевает ли читать данные с диска и писать их на него, хватает ли памяти, не загружен ли «в полку» процессор.

И, вроде бы, базовый набор метрик для приложения готов. Но на облачной платформе ваша ВМ не будет выполняться на физическом процессоре в одиночку. У одного крупного розничного облачного провайдера на сайте так и написано: «Гарантированная доля vCPU до 10%», на практике это означает, что если пренебречь накладными расходами на виртуализацию, то на один поток выполнения физического ядра приходится от 10 виртуальных. Тесновато, не так ли? Облачной платформе обычно всё равно, что именно выполняется на виртуальных CPU, но она чутко отслеживает моменты пиковых нагрузок, чтобы не пострадали другие процессы. Кроме того, не стоит размещать высоконагруженные ВМ, например, СУБД, на одном физическом сервере. Этим распределением, как правило, занимается сама облачная платформа.

Может показаться, что с оперативной памятью ситуация проще: есть, например, 64 ГБ и они будут доступны для ВМ, в точности так, как их распределили мы. И ВМ используют только ту память, которая им нужна, а когда память заканчивается, можно добавить ещё. Продолжая аналогию, если память у обычного компьютера заканчивается, то её можно увеличить.

На самом деле, ситуация даже чуть сложнее, чем с vCPU. Во-первых, облачная платформа активно использует механизмы оптимизации, самый популярный и понятный — это memory ballooning, когда часть памяти возвращается хосту, чтобы её могли использовать другие ВМ, процесс динамический и работает в обе стороны. Во-вторых, ОС активно кешируют доступную память для ускорения быстродействия, поэтому действительно свободной памяти меньше, чем доступной.

Причём Windows и ОС семейства Linux по-разному подходят к кешированию доступной памяти. Поэтому учесть, сколько памяти сейчас действительно используется приложением, сколько — в кеше у ОС, а сколько временно отдала платформа соседней ВМ, — довольно непросто.

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

Как видите, учёт любых ресурсов непростая задача, и облачная платформа — не исключение.

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

Правильное представление: на что и куда смотреть, чтобы не перегрузить данными

Так как же инженерам наглядно показать менеджерам, что ресурсов действительно не хватает? Как отличить высокое потребление памяти от кеширования и понять, что на ЦПУ высокая нагрузка, но не вникать при этом в нюансы облачной архитектуры и выполняемых приложений?

Чтобы найти решение для этой задачи, мы обрабатываем большие объёмы данных, причём часть из них отбрасываем сразу после получения, так как далеко не все потом будут нам нужны.

Например, если дисковый массив всё ещё стабилен, все диски доступны, о чем он сообщил нам по SNMP, то новую запись об этом мы хранить не будем, ограничимся старой, которую получили вчера. Вот так получается, что данные мы запрашиваем раз в несколько минут, а записываем и храним только раз в 24 часа. Однако, если произойдёт деградация дискового массива, мы об этом быстро узнаем и зафиксируем момент возникновения проблемы.

Для того чтобы представить показатели используемых ресурсов мы обсуждали два подхода:

• Классическая статистика – использование стандартных статистических функций: такие как перцентиль и среднее арифметическое.

• Синтетические показатели – расчёт  значений на основе метрик.

И выбрали оба.

Перцентиль хорошо подходит для оценки загрузки CPU, памяти и каналов связи. Он помогает сгладить пиковые нагрузки и простои и за счёт этого даёт объективную картину утилизации.

Например: веб-сервер в момент обновления ПО может загрузить CPU на 100%, но это будет кратковременный всплеск. В остальное время загрузка составляет 20-30%. Перцентиль позволяет отбросить пики и оценить реальную утилизацию. А ещё перцентиль широко используется в телекоме: 95-й перцентиль показывает, насколько загружен канал связи в течение 95% времени.

Рисунок: 90-й процентиль (залитая область) на данных нагрузки ЦПУ за 100 секунд.

И хорошо знакомые показатели тоже могут оказаться полезны. Например:

• Среднее арифметическое – сглаживает верхние и нижние значения, на отрезке остаётся всего одно значение. Однако на него влияют фоновые показатели и так можно пропустить моменты пиковой нагрузки.

• Фильтрация по диапазону значений – позволяет анализировать нагрузку в пределах определённого диапазона, например, отбрасывая моменты простоя.

Синтетические показатели помогают лучше определить характер использования ресурсов. Привести их примеры сложнее, так как они подбираются под конкретный тип ресурса, а иногда и задачу. Скажем, чтобы оценить использование кластера в режиме active-stand by, когда резервный узел фактически простаивает, при расчёте статистических показателей мы проверяем, какой узел в кластере был активен в данный момент и используем в расчётах только его данные. А вот если учитывать все данные кластера, то среднее арифметическое было бы всегда ниже 50%.

С помощью корректно подобранных синтетических показателей можно выявить и наглядно представить интересующие заказчика и бизнес особенности потребления ресурсов, а наблюдая за их динамикой, найти закономерности и аномалии:

• Отсечь фоновую нагрузку.

• Убрать единичные пиковые всплески.

• Определить, когда утилизация упирается «в потолок» но не из-за ЦПУ, а из-за памяти или дисковой подсистемы.

Для отсечки фона можно использовать нижние пороговые значения и учёт распределения нагрузки. Единичные пики хорошо сглаживаются с помощью среднего арифметического и перцентиля.

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

При этом надо обязательно учитывать характер ресурсов. Например, CPU можно загружать до 85-90%, при этом система будет работать стабильно. Сеть считается перегруженной при загрузке выше 70%. Некоторые типы дисков могут заполняться до 95%, и при этом продолжать работать без потерь производительности. Нам важно не просто измерить процент использования, а анализировать использование ресурсов, учитывая их тип. Для этого мы используем данные мониторинга.

Простые решения на основе понятных данных

Теперь вы примерно представляете, как выглядит сбор, обработка и представление данных. Поговорим напоследок, как принимаются решения на их основе.

Давайте представим, что вы сделали мега-популярное мобильное приложение, про которое написали на Хабре.

После хабраэффекта нагрузка на вашу облачную инфраструктуру резко выросла и какое-то время вы покупали большой объём ресурсов для того, чтобы удовлетворять запросы пользователей. Однако популярность прошла и теперь вам надо понять, когда можно отказаться от избыточных ресурсов и, главное,  чтобы снижение мощностей прошло безболезненно для вас и ваших пользователей. Конечно, в идеальном мире у вашего приложения правильная архитектура и снижение ресурсов пройдёт безболезненно и гладко, но мы в реальном мире, где всё не так просто.

Оптимизация как с увеличением, так и с уменьшением ресурсов должна проходить вовремя. А пороговые значения как раз помогают понять, что этот момент наступил.

Давно известно, что инженеры и менеджеры смотрят на одни и те же значения с разных точек зрения. Что для инженера – возможный отказ из-за перегрузки, для менеджера – резерв мощности. Кстати, что именно считать простоем системы – мы тоже понимаем по-разному. Поэтому важно заранее договориться с заказчиком, какие значения будут пороговыми для принятия решений по оптимизации.

Например, если дисковое пространство  так и не получилось за определённый период заполнить данными больше, чем на 50% – то нужно уменьшить его в два раза. А если 80-й процентиль нагрузки на процессор больше 95 – то это нормальная ситуация и предпринимать что-то не требуется.

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

Почему Grafana? Это инструмент, который де-факто стал стандартом, имеет обширную базу знаний и активное сообщество, к которому можно обратиться за решением.

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

Как следствие, меньше ручной работы на обработку данных, больше времени на Хабр

Мы не стали пытаться делать онлайн-мониторинг и алертинг в Grafana, так как, во-первых, получаем данные с задержкой, а во-вторых, принимаемые решения не являются оперативными, а нужны для построения планов на будущее. Хотя некоторые алерты всё же настроены, думаю, их назначение очевидно и останавливаться на них не буду.

Благодаря Grafana мы получили единообразный формат представления – так всем заинтересованным лицам сразу понятно, о каких ресурсах речь. А важные показатели выделяем цветами:

• Нагрузка меньше нижнего порога,

• Нагрузка в норме,

• Мы близки к исчерпанию предоставленных ресурсов,

• Используемые ресурсы превышают предоставленные – такие ситуации тоже бывают, нам важно, чтобы информационные системы некоторых потребителей работали без сбоев и непрерывно несмотря ни на что.

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

Вместо заключения

Нас часто просят сделать мониторинг «чтобы всё было видно». Мы, конечно, можем. Но предупреждаем: смотреть на 2000 алертов в 3 часа ночи — удовольствие ниже среднего. Поэтому лучше думать не про всё, а про нужное. Иначе мониторинг будет следить только за вашим выгоранием.

Увы,  одного «идеального метода» мониторинга не существует. Поэтому наш мониторинг учитывает:

• разные типы нагрузки;

• разные категории ресурсов.

И реализует разные методы их учета и представления:

• с помощью статистических функций;

• на основе пороговых значений;

• в виде расчётных показателей.

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

Правильно настроенный мониторинг — это не просто техническая история. Это способ договориться между инженерами и бизнесом на общем языке цифр, графиков и метрик. Чтобы решения принимались на данных, а не на догадках. И чтобы инфраструктура перестала быть «чёрным ящиком», а стала прозрачной системой, управляемой с умом.