В предыдущей статье мы развернули связку Prometheus+Grafana и теперь самое время подключить источники и настроить визуализацию. Но прежде напомню, с каких элементов ИТ инфраструктуры мы собираемся собирать метрики. Прежде всего это оборудование, операционные системы и дополнительное ПО, то есть все то, без чего нормальное функционирование нашего приложения было бы невозможно. Затем мониторинг самого приложения, например, какие компоненты расходуют больше тех или иных ресурсов. И наконец, мониторинг бизнес-логики приложения. Это может быть например сбор информации об активностях пользователей, поступлениях денежных средств и т.д.
Мало просто собрать метрики, важно их правильно интерпретировать, поэтому для начала мы посмотрим, что именно мы хотим мониторить и затем уже будем визуализировать необходимые метрики. В зависимости от типа ресурса, с которого собираются метрики, нам потребуется различная информация. Если мы собираем метрики с хоста, то нам потребуются: CPU, Memory, Processes, Disk, Network и т.д. Если же у нас Docker-контейнер, то тогда мы будем собирать: CPU, Memory, Network, Block I/O, + Docker Daemon.
С мониторингом приложений все несколько сложнее. Как правило разработчики лучше других знают, чем занимается ваше приложение и могут реализовать более релевантные метрики. Основными целями сбора метрик с приложений является выявление состоянии и производительности (performance) кода. Также, не лишним будет мониторинг использования приложения конечным пользователем. Примерами метрик, собираемых в приложениях является время ответа на запросы, количество неудачных логинов пользователей и т.п.
Отличительной особенностью сбора метрик с приложений является то, что данные метрики практически невозможно собрать внешними средствами, так как это делается, к примеру при мониторинге операционной системы. Сбор метрик всегда описывается в коде самого приложения.
Сбор бизнес метрик может осуществляться как средствами самого приложения, так и с помощью дополнительных средств, там где это возможно.
Рекомендации по сбору метрик
Рассмотрим рекомендации для сбора различных метрик. Для сбора инфраструктурных метрик лучше всего подходит метод USE: Utilization (использование), например загрузка диска, Saturation (насыщение), например очередь диска, Errors (ошибки), например ошибки I/O диска.
Вот типовой список ресурсов, с которых USE рекомендует осуществлять сбор метрик.
CPUs: sockets, cores, hardware threads (virtual CPUs)
Memory: capacity
Network interfaces
Storage devices: I/O, capacity
Controllers: storage, network cards
Interconnects: CPUs, memory, I/O
При этом стоит учитывать, что некоторые компоненты представляют собой ресурсы двух типов: устройства хранения данных - это ресурс запроса на обслуживание (I/O), а также ресурс емкости (capacity). Оба этих типа ресурсов могут стать узким местом в системе. Некоторые физические компоненты были опущены, такие как аппаратные кэши (например, MMU TLB/TSB, CPU). Метод USE наиболее эффективен для ресурсов, производительность которых снижается при высокой загрузке или насыщении, что приводит к возникновению узкого места. Кэши повышают производительность при высокой загрузке.
Принимать решение о том, нужно ли включать тот или иной ресурс в мониторинг необходимо опытным путем. То есть сначала включите мониторинг нужных ресурсов и посмотрите на результат – если он вас не устраивает (например, метрика не информативна, всегда 0 или константа) посмотрите в том же Prometheus другую аналогичную метрику для мониторинга.
Разработчик метода USE Brendan Gregg также предлагает другой метод определения тех ресурсов, метрики которых вам необходимо собирать. Автор предлагает нарисовать функциональную блок-схему системы, которая покажет взаимосвязи, которые могут быть очень полезны при поиске узких мест в потоке данных. Вот пример такой схемы для сервера SunFire:
На основании подобной схемы применительно к оборудованию можно указать пропускную способность шин и интерфейсов, где применимо можно указать объем памяти, частоту, температуру и другие параметры. В результате, благодаря такой “обогащенной” значениями схеме мы можем эффективно собирать метрики и вести мониторинг.
В целом, метод USE показан в виде блок-схемы ниже.
RED-метод
Если метод USE больше подходит для мониторинга инфраструктуры, то метод RED больше подходит для выбора метрик приложений и сервисов. Аббревиатура RED расшифровывается как: Rate - запросы в секунду, Errors - ошибки в секунду, Duration - время на каждый запрос. Основные метрики, которые предлагается снимать методом RED это:
Rate (количество запросов в секунду)
Errors (количество тех запросов, которые завершились неудачей)
Duration (количество времени, которое занимают эти запросы)
Отличительной особенностью метода RED является возможность мониторить, насколько могут быть довольны ваши клиенты. Если у вашего сайта много ошибок при загрузки, или время загрузки сайта исчисляется десятками секунд, то посетители сайта вряд ли будут этим довольны.
Four Golden Signals от Google
Четыре золотых сигнала - принцип выбора метрик, описанный в книге Site Reliability Engineering от Google. Это следующие четыре сигнала:
Latency - время ответа
Traffic - частота запросов
Errors (ошибки) - частота ошибок
Saturation (насыщение) - насколько утилизирован (загружен) ресурс
Осуществляя мониторинг этих четырех видов сигналов, вы сможете обнаружить большинство проблем и узких мест в системе. Данный метод может использоваться как для мониторинга инфраструктуры, так и для мониторинга приложений.
Визуализация
Зачем на самом деле нужна визуализация? Первый ответ, который может прийти в голову это для красоты. И на самом деле такой вариант не будет совсем уж бредовым. Дело в том, что на красивых графиках, которые в конечном итоге и получаются в результате визуализации можно достаточно эффективно наблюдать за изменениями в тех или иных системах, отслеживать тенденции работы и анализировать результат. Поэтому, совершенно законным этапом развития любой системы мониторинга является визуализация собираемых метрик.
В предыдущей статье мы развернули Prometheus и Grafana, теперь в качестве примера подключим и визуализируем метрики от Docker.
Следим за контейнерами
Для того, чтобы начать собирать метрик с Docker нам необходимо прежде всего создать файл /etc/docker/daemon.json со следующим содержанием:
{
"metrics-addr" : "127.0.0.1:9323",
"experimental" : true
}Где metrics-addr это адрес сервера Prometheus ( в моем случае все располагается на одном хосте) и порт 9323. Для того, чтобы настройки вступили в силу необходимо перезапустить Docker.
systemctl restart docker
Далее необходимо внести правки в настройки Prometheus. Нам потребуется файл /etc/prometheus/prometheus.yml. В нем находим scrape_configs (в нем уже должен быть блок настроек для сбора метрик самого Prometheus) и добавляем туда следующий блок:
- job_name: 'docker'
static_configs:
- targets: ['localhost:9323']Должно получиться примерно следующее:
Теперь идем в Prometheus, Status->Targets и убеждаемся в наличии задачи по сбору метрик от Docker.
На этом с Prometheus все. Теперь переходим в интерфейс Grafana и проверяем, что у нас есть источник данных Prometheus по порту 9090 в разделе Data Sources. Переходим к созданию нового дашборда. В моем примере будет четыре панели: engine_daemon_image_actions (график будет показывать общее количество действий с контейнерами), engine_daemon_network_actions (сетевые активности), engine_daemon_events_total (общее количество событий) и engine_daemon_container_states (статистика по состояниям контейнеров).
Для добавления панелей нажимаем New dashboard -> Add query. Далее указываем нужные метрики. Например engine_daemon_container_states_containers.
Введенный запрос выведет статистику по контейнерам. Далее выбираем значок Visualization (слева внизу). И выбираем вид графика. В своем примере для этой метрики я оставлю первый вариант.
На третьем шаге можно ничего не менять. На четвертом вы можете указать условия для создания Alert.
Повторим все эти действия для остальных панелей и получим дашборд следующего вида.
Теперь у нас есть дашборд, отображающий состояние Docker.
Заключение
В этой статье мы рассмотрели основные рекомендации по мониторингу инфраструктуры и приложения и в качестве примера подключили к Prometheus и Grafana сбор метрик от Docker и сделали соответствующий дашборд. Следующая статья будет полностью посвящена сбору трейсов непосредственно из приложений.
В заключении хотелось бы напомнить одну простую истину. Сбор данных дешев, но отсутствие их в случае необходимости может обойтись очень дорого. Поэтому нужно обеспечить сбор всех полезных данных, которые разумно собирать.
Также хочу пригласить вас на бесплатный вебинар, где рассмотрим основные инструменты для работы с сетью в Linux, встречающиеся в таких популярных дистрибутивах как CentOS, Ubuntu, ArchLinux.