В предыдущей статье мы развернули связку 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 показан в виде блок-схемы ниже.      Если метод USE больше подходит для мониторинга инфраструктуры, то метод RED больше подходит для выбора метрик приложений и сервисов. Аббревиатура RED расшифровывается как: Rate - запросы в секунду, Errors - ошибки в секунду, Duration - время на каждый запрос. Основные метрики, которые предлагается снимать методом RED это: Rate (количество запросов в секунду) Errors (количество тех запросов, которые завершились неудачей) Duration (количество времени, которое занимают эти запросы) Отличительной особенностью метода RED является возможность мониторить, насколько могут быть довольны ваши клиенты. Если у вашего сайта много ошибок при загрузки, или время загрузки сайта исчисляется десятками секунд, то посетители сайта вряд ли будут этим довольны. Четыре золотых сигнала - принцип выбора метрик, описанный в книге Site Reliability Engineering от Google. Это следующие четыре сигнала: Latency - время ответа Traffic - частота запросов Errors (ошибки) - частота ошибок Saturation (насыщение) - насколько утилизирован (загружен) ресурс Осуществляя мониторинг этих четырех видов сигналов, вы сможете обнаружить большинство проблем и узких мест в системе. Данный метод может использоваться как для мониторинга инфраструктуры, так и для мониторинга приложений.  Зачем на самом деле нужна визуализация? Первый ответ, который может прийти в голову это для красоты. И на самом деле такой вариант не будет совсем уж бредовым. Дело в том, что на красивых графиках, которые в конечном итоге и получаются в результате визуализации можно достаточно эффективно наблюдать за изменениями в тех или иных системах, отслеживать тенденции работы и анализировать результат. Поэтому, совершенно законным этапом развития любой системы мониторинга является визуализация собираемых метрик. В предыдущей статье мы развернули Prometheus и Grafana, теперь в качестве примера подключим и визуализируем метрики от Docker.  Для того, чтобы начать собирать метрик с Docker нам необходимо прежде всего создать файл /etc/docker/daemon.json со следующим содержанием: Где metrics-addr это адрес сервера Prometheus ( в моем случае все располагается на одном хосте) и порт 9323. Для того, чтобы настройки вступили в силу необходимо перезапустить Docker. systemctl restart docker Далее необходимо внести правки в настройки Prometheus. Нам потребуется файл /etc/prometheus/prometheus.yml. В нем находим scrape_configs (в нем уже должен быть блок настроек для сбора метрик самого Prometheus) и добавляем туда следующий блок: Должно получиться примерно следующее: Теперь идем в 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. Зарегистрироваться на бесплатный вебинар