Prometheus — это система мониторинга и сбора метрик, которая используется для наблюдения за серверами, приложениями, контейнерами, базами данных, сетевыми сервисами и облачной инфраструктурой. Она регулярно получает числовые показатели от контролируемых систем, сохраняет их как временные ряды и позволяет анализировать состояние инфраструктуры с помощью специального языка запросов PromQL.
Prometheus особенно распространен в DevOps, SRE, Kubernetes и микросервисных архитектурах. С его помощью можно контролировать загрузку процессоров, использование оперативной памяти, количество HTTP-запросов, время ответа приложений, ошибки, состояние контейнеров и множество других параметров.
Например, Prometheus может каждые 15 секунд получать данные о загрузке веб-сервера. Если доля ошибок резко возрастет или приложение перестанет отвечать, система сможет определить проблему и передать информацию в механизм уведомлений.
Что такое Prometheus простыми словами
Prometheus можно представить как автоматического наблюдателя, который регулярно спрашивает у серверов и приложений, как они работают.
Каждая система публикует набор числовых показателей. Например, веб-приложение сообщает количество обработанных запросов, база данных — число соединений, а сервер — использование процессора и памяти.
Prometheus периодически собирает эти значения и сохраняет их вместе со временем измерения.
Prometheus превращает текущее состояние ИТ-инфраструктуры в набор измеряемых временных рядов, которые можно анализировать, отображать на графиках и использовать для автоматических уведомлений.
Если инженер хочет узнать, насколько выросла нагрузка за последний час или когда началось увеличение количества ошибок, он может выполнить запрос к сохраненным данным.
Для чего нужен Prometheus
Главная задача Prometheus — собирать и анализировать метрики. Это позволяет видеть текущее состояние системы и отслеживать изменения во времени.
- мониторинг серверов;
- контроль приложений и API;
- наблюдение за Kubernetes;
- сбор метрик контейнеров;
- контроль баз данных;
- измерение доступности и производительности;
- расчет SLI и SLO;
- создание алертов;
- поиск аномалий;
- анализ нагрузки и планирование ресурсов.
Prometheus полезен не только системным администраторам. Разработчики могут использовать его для анализа поведения приложений, а SRE-команды — для контроля надежности сервисов.
Как работает Prometheus
В типичной схеме Prometheus сам обращается к контролируемым системам через определенные интервалы времени и забирает у них метрики.
Такой подход называется Pull Model.
- Приложение или exporter публикует метрики.
- Prometheus знает адрес этого источника.
- Через заданный интервал Prometheus выполняет HTTP-запрос.
- Источник возвращает текущие значения метрик.
- Prometheus сохраняет значения в базе временных рядов.
- Пользователь выполняет запросы через PromQL.
- При выполнении условий могут формироваться алерты.
Например, сервер публикует метрики по адресу, который доступен Prometheus. Система каждые 15 секунд получает новые значения загрузки процессора, памяти и дисков.
Что такое метрика в Prometheus
Метрика — числовой показатель, который изменяется во времени.
Например, количество HTTP-запросов может постоянно увеличиваться, температура сервера изменяться, а свободное место на диске постепенно уменьшаться.
Каждая метрика имеет имя и может содержать labels — дополнительные метки, которые помогают разделять значения по серверам, приложениям, методам запросов и другим признакам.
Например, одна метрика HTTP-запросов может отдельно учитывать обращения к разным URL или ответы с разными кодами.
Что такое временной ряд
Time Series, или временной ряд, — последовательность значений одной метрики, привязанных ко времени.
Если Prometheus каждые 15 секунд измеряет использование процессора, за час накопится множество значений. Вместе они образуют временной ряд.
На основе таких данных можно строить графики и анализировать динамику.
| Время | Использование CPU |
|---|---|
| 10:00 | 25 процентов |
| 10:05 | 31 процент |
| 10:10 | 47 процентов |
| 10:15 | 82 процента |
Из таблицы видно, что нагрузка постепенно растет. Prometheus позволяет автоматически анализировать такие изменения.
Что такое Labels
Labels — пары ключ и значение, которые добавляют контекст к метрике.
Например, компания контролирует три веб-сервера. Вместо создания трех отдельных метрик можно использовать одну метрику и label с именем сервера.
Дополнительными метками могут быть название приложения, окружение, регион, HTTP-метод, код ответа или имя контейнера.
Labels делают систему гибкой, но их необходимо использовать осторожно. Если в качестве значения метки применять уникальные идентификаторы пользователей или запросов, количество временных рядов может резко увеличиться.
Что такое Cardinality
Cardinality показывает количество уникальных комбинаций labels у метрик.
Например, если метрика имеет label environment с двумя значениями production и test, кардинальность остается небольшой.
Если добавить label user_id и в системе миллион пользователей, количество временных рядов может вырасти на миллионы.
Высокая cardinality увеличивает потребление оперативной памяти и дискового пространства и может ухудшать производительность Prometheus.
Метрики лучше использовать для агрегированных числовых показателей, а уникальные идентификаторы запросов и пользователей хранить в логах или трассировках.
Типы метрик Prometheus
В клиентских библиотеках Prometheus используются несколько основных типов метрик.
| Тип | Назначение |
|---|---|
| Counter | Счетчик событий, который обычно только увеличивается |
| Gauge | Значение, которое может увеличиваться и уменьшаться |
| Histogram | Распределение наблюдений по диапазонам |
| Summary | Статистика распределения измеряемых значений |
Что такое Counter
Counter — счетчик, который обычно увеличивается при наступлении события.
Например, можно считать общее количество HTTP-запросов, ошибок или обработанных задач.
Если значение было 1000, а через минуту стало 1100, значит за этот период произошло еще 100 событий.
Counter удобно использовать совместно с функциями PromQL, которые рассчитывают скорость роста счетчика.
Что такое Gauge
Gauge используется для показателей, которые могут как увеличиваться, так и уменьшаться.
Например, температура процессора, количество активных соединений, объем свободной памяти или длина очереди.
Если Counter обычно описывает накопительное количество событий, Gauge отражает текущее состояние.
Что такое Histogram
Histogram позволяет анализировать распределение измеряемых значений по диапазонам.
Например, можно измерять время ответа HTTP-запросов и подсчитывать, сколько из них выполнилось быстрее 100 миллисекунд, 500 миллисекунд или одной секунды.
Такие данные помогают анализировать задержки и рассчитывать перцентили.
Что такое Summary
Summary также используется для анализа распределения измерений. Он может рассчитывать статистические характеристики на стороне приложения.
Histogram и Summary решают похожие задачи, но отличаются способом хранения и обработки данных. Выбор зависит от требований к агрегации и архитектуре мониторинга.
Что такое Exporter
Exporter — программа, которая получает данные из системы и преобразует их в формат, понятный Prometheus.
Некоторые приложения изначально умеют публиковать Prometheus-метрики. Для других используют отдельные exporters.
| Exporter | Что обычно контролирует |
|---|---|
| Node Exporter | Linux-серверы и операционную систему |
| Blackbox Exporter | Доступность HTTP, TCP и других сетевых сервисов |
| Database Exporter | Метрики СУБД |
| Custom Exporter | Специализированные приложения и оборудование |
Exporter позволяет подключить к Prometheus систему, которая сама не умеет публиковать нужные метрики.
Что такое Node Exporter
Node Exporter используется для получения метрик Linux-серверов.
Он может публиковать данные о загрузке процессоров, оперативной памяти, файловых системах, сетевых интерфейсах и других ресурсах операционной системы.
Prometheus регулярно обращается к Node Exporter и сохраняет его показатели.
На основе этих данных можно контролировать состояние физических серверов, виртуальных машин и облачных экземпляров.
Что такое Blackbox Exporter
Blackbox Exporter используется для проверки сервисов с внешней точки зрения.
Например, можно проверить, открывается ли веб-сайт по HTTPS, отвечает ли TCP-порт или работает ли определенный сетевой сервис.
Это отличается от мониторинга внутренних метрик приложения. Приложение может считать себя исправным, но пользователь не сможет подключиться к нему из-за сетевой проблемы.
Blackbox-проверки помогают увидеть сервис так, как его видит внешний клиент.
Что такое Scrape
Scrape — операция получения метрик Prometheus у контролируемого источника.
Prometheus отправляет HTTP-запрос на специальный endpoint, получает текущие значения и сохраняет их.
Интервал между такими запросами называется scrape interval.
Например, при интервале 15 секунд Prometheus четыре раза в минуту получает новые значения метрик.
Что такое Scrape Interval
Scrape Interval определяет частоту сбора данных.
Слишком большой интервал может скрыть кратковременные события. Например, нагрузка резко выросла на одну минуту и вернулась к норме до следующего измерения.
Слишком маленький интервал увеличивает объем данных и нагрузку на Prometheus и контролируемые системы.
Поэтому частоту выбирают с учетом характера метрики и требований к мониторингу.
Что такое endpoint metrics
Приложения, совместимые с Prometheus, обычно публикуют метрики через HTTP endpoint.
При обращении к нему возвращается текстовый набор метрик и их текущих значений.
Сам endpoint не предназначен для обычных пользователей сайта. Его должен запрашивать Prometheus или другая система мониторинга.
В корпоративной инфраструктуре доступ к метрикам желательно ограничивать, поскольку они могут содержать техническую информацию о приложении.
Что такое PromQL
PromQL, или Prometheus Query Language, — язык запросов для работы с метриками Prometheus.
С его помощью можно выбирать временные ряды, фильтровать их по labels, рассчитывать скорость изменения, объединять значения и выполнять математические операции.
Например, можно определить среднюю загрузку процессора по группе серверов или рассчитать количество HTTP-запросов в секунду.
PromQL используется в самом Prometheus, в панелях мониторинга и в правилах алертов.
Примеры задач PromQL
С помощью запросов можно отвечать на практические вопросы об инфраструктуре.
- сколько запросов обрабатывает приложение в секунду;
- какова доля ответов с ошибками;
- какой сервер сильнее всего загружен;
- сколько свободного места осталось на диске;
- каков 95-й перцентиль времени ответа;
- какие контейнеры используют больше всего памяти;
- как изменилась нагрузка за последние сутки.
Возможность выполнять вычисления над временными рядами является одной из ключевых особенностей Prometheus.
Prometheus и Grafana
Prometheus и Grafana часто используются вместе, но выполняют разные задачи.
Prometheus собирает, хранит и обрабатывает метрики. Grafana используется преимущественно для визуализации данных в виде графиков, таблиц и дашбордов.
| Prometheus | Grafana |
|---|---|
| Собирает метрики | Визуализирует метрики |
| Хранит временные ряды | Создает панели и дашборды |
| Выполняет PromQL | Использует Prometheus как источник данных |
| Создает правила алертов | Может отображать и дополнительно обрабатывать уведомления |
Например, Prometheus собирает загрузку процессоров, а Grafana показывает ее на удобном графике для администраторов.
Prometheus и Alertmanager
Prometheus может определять, что условие алерта выполнено, но для управления уведомлениями обычно используется Alertmanager.
Он получает события от Prometheus и решает, кому и как отправить сообщение.
Alertmanager помогает группировать похожие уведомления, подавлять некоторые сигналы и маршрутизировать сообщения разным командам.
Например, проблемы базы данных можно отправлять команде DBA, а недоступность сайта — дежурной SRE-команде.
Как работает алерт в Prometheus
Администратор создает правило на основе PromQL.
Например, если доля HTTP-ошибок остается выше допустимого значения в течение нескольких минут, Prometheus переводит правило в состояние срабатывания.
После этого событие может быть передано в Alertmanager.
Важно не создавать алерт на каждое кратковременное изменение. Большое количество незначимых уведомлений приводит к Alert Fatigue.
Recording Rules
Recording Rules позволяют заранее рассчитывать часто используемые выражения PromQL и сохранять результат как новую метрику.
Это полезно для сложных запросов, которые постоянно используются в дашбордах или алертах.
Вместо повторного выполнения тяжелого вычисления система периодически рассчитывает значение и сохраняет готовый временной ряд.
Такой подход может ускорить работу мониторинга в крупных инфраструктурах.
Prometheus и Kubernetes
Prometheus особенно широко используется для мониторинга Kubernetes.
Кластер состоит из множества динамических объектов: узлов, pod, контейнеров и сервисов. Они постоянно создаются, перезапускаются и перемещаются.
Ручное добавление каждого объекта в систему мониторинга было бы неудобным. Поэтому Prometheus может использовать механизмы Service Discovery и автоматически обнаруживать необходимые цели.
В Kubernetes с помощью Prometheus можно контролировать состояние узлов, использование ресурсов контейнерами, количество перезапусков, состояние приложений и показатели самого кластера.
Что такое Service Discovery
Service Discovery позволяет Prometheus автоматически находить системы, с которых нужно получать метрики.
Это особенно важно в динамической инфраструктуре. Например, Kubernetes может создать десять новых pod, а через несколько минут удалить часть из них.
Prometheus получает информацию об актуальных объектах и автоматически обновляет список целей.
В статической инфраструктуре адреса серверов также можно задавать вручную.
Что такое Target
Target — конкретный источник метрик, который опрашивает Prometheus.
Например, экземпляр Node Exporter на одном сервере является отдельным target.
Prometheus хранит информацию о том, доступна ли цель и успешно ли прошел последний сбор метрик.
Если target перестает отвечать, это само по себе может использоваться как сигнал о проблеме.
Метрика up
Prometheus автоматически формирует показатель up для контролируемых целей.
Если очередной scrape был успешным, значение показывает доступность target. Если метрики получить не удалось, это отражается в показателе.
Такой механизм позволяет быстро обнаруживать недоступные exporters и приложения.
Однако успешный scrape еще не означает, что бизнес-функция приложения работает корректно. Поэтому необходимо использовать и пользовательские метрики.
Prometheus и SRE
Prometheus хорошо подходит для практик Site Reliability Engineering, поскольку позволяет измерять SLI и контролировать выполнение SLO.
Например, из счетчиков HTTP-запросов можно рассчитать долю успешных операций, а из histogram — задержку ответа.
Эти показатели можно сравнивать с установленными SLO и использовать для оценки Error Budget.
При приближении к нарушению цели команда получает данные для принятия решений о стабилизации сервиса.
Prometheus и Observability
Prometheus закрывает прежде всего метрическую часть Observability.
Метрики хорошо показывают динамику числовых показателей, но не содержат всех деталей отдельного события. Поэтому Prometheus часто используется вместе с системами хранения логов и распределенной трассировки.
| Тип данных | Пример задачи |
|---|---|
| Метрики Prometheus | Увидеть рост доли ошибок |
| Логи | Узнать текст конкретной ошибки |
| Трассировки | Понять путь медленного запроса между сервисами |
В полноценной Observability-инфраструктуре эти источники данных дополняют друг друга.
Prometheus и OpenTelemetry
OpenTelemetry используется для формирования и передачи телеметрических данных приложений.
Prometheus может быть частью такой архитектуры и использоваться для хранения и анализа метрик.
При этом OpenTelemetry шире по назначению и охватывает не только метрики, но и трассировки и другие виды телеметрии.
Эти технологии могут использоваться совместно.
Prometheus и мониторинг приложений
Наиболее полезные метрики приложение часто должно публиковать самостоятельно.
Например, интернет-магазин может сообщать количество успешно оформленных заказов, число ошибок оплаты и продолжительность обработки операций.
Такие показатели ближе к реальному пользовательскому опыту, чем обычная загрузка процессора.
Если сервер использует только 20 процентов CPU, но все платежи завершаются ошибкой, инфраструктурные показатели не покажут реальное состояние бизнеса.
Prometheus и бизнес-метрики
В Prometheus можно хранить не только технические, но и некоторые оперативные бизнес-метрики.
Например, количество обработанных заказов или задач в минуту может помочь обнаружить техническую проблему.
Если после релиза количество успешных операций резко падает, это может быть важнее обычных показателей CPU и памяти.
При этом Prometheus не является аналитическим хранилищем для полноценной бизнес-отчетности и не должен заменять специализированные BI-системы.
Prometheus и база данных
Для СУБД можно собирать метрики количества соединений, продолжительности запросов, репликации, блокировок, размера баз и использования ресурсов.
Обычно для этого используется специализированный exporter или встроенная поддержка метрик.
Такие данные помогают обнаруживать перегрузку и анализировать влияние базы данных на производительность приложений.
Prometheus и Nginx
Nginx можно включить в инфраструктуру мониторинга и собирать показатели количества соединений, запросов, ошибок и другой доступной статистики.
Эти данные полезны для оценки нагрузки на веб-сервер и обнаружения изменений в трафике.
Например, резкий рост ошибок 5xx может быть связан с проблемами backend-приложения, а Prometheus поможет увидеть момент начала сбоя и его продолжительность.
Хранение данных в Prometheus
Prometheus использует специализированное локальное хранилище временных рядов.
Оно оптимизировано под регулярную запись метрик и выполнение запросов по временным диапазонам.
Период хранения можно настраивать с учетом доступного дискового пространства и требований проекта.
Для небольших и средних инфраструктур локального хранения часто достаточно. Для долгосрочного хранения и распределенной архитектуры могут применяться дополнительные решения.
Долгосрочное хранение метрик
В некоторых проектах метрики необходимо хранить месяцами или годами. Например, для анализа сезонной нагрузки и планирования ресурсов.
Один экземпляр Prometheus не всегда является оптимальным решением для очень большого объема долгосрочных данных.
В таких случаях используются дополнительные системы, способные получать данные из Prometheus и хранить их распределенно.
Архитектура выбирается исходя из объема метрик, требований к отказоустойчивости и срокам хранения.
Масштабирование Prometheus
По мере роста инфраструктуры увеличивается количество targets и временных рядов.
Проблемой может стать не только количество серверов, но и высокая cardinality labels.
Для масштабирования мониторинг можно разделять между несколькими экземплярами Prometheus по кластерам, регионам или группам сервисов.
Также применяются федерация и внешние системы долгосрочного хранения.
Что такое Federation
Federation позволяет одному Prometheus получать часть агрегированных данных из другого Prometheus.
Например, в каждом дата-центре работает собственный экземпляр мониторинга, а центральная система собирает только ключевые показатели.
Это помогает построить иерархическую архитектуру и не передавать все исходные временные ряды в одно место.
Отказоустойчивость Prometheus
Сам Prometheus также является частью критичной инфраструктуры и может выйти из строя.
Для важных систем можно запускать несколько независимых экземпляров, которые собирают одинаковые данные.
Если один сервер мониторинга недоступен, второй продолжает получать метрики.
При проектировании необходимо отдельно учитывать хранение данных, алерты и маршрутизацию уведомлений.
Безопасность Prometheus
Метрики могут раскрывать важную техническую информацию: имена серверов, версии приложений, адреса внутренних сервисов и особенности нагрузки.
Поэтому интерфейс Prometheus и endpoints метрик не следует без необходимости публиковать в открытом интернете.
Доступ можно ограничивать сетевыми правилами, Reverse Proxy, механизмами аутентификации и другими средствами инфраструктуры.
Также не следует помещать пароли, токены, персональные данные и другие секреты в labels или значения метрик.
Преимущества Prometheus
- удобен для мониторинга динамической инфраструктуры;
- поддерживает мощный язык запросов PromQL;
- хранит данные как временные ряды;
- хорошо интегрируется с Kubernetes;
- поддерживает Service Discovery;
- имеет большую экосистему exporters;
- подходит для SRE и расчета SLI;
- может использоваться для алертов;
- хорошо работает совместно с Grafana;
- позволяет создавать собственные метрики приложений.
Ограничения Prometheus
Prometheus не является универсальным хранилищем всей телеметрии. Он предназначен прежде всего для числовых временных рядов.
- не заменяет централизованную систему логов;
- не предназначен для хранения полных трассировок;
- высокая cardinality может существенно увеличить потребление ресурсов;
- очень большое долгосрочное хранение требует дополнительной архитектуры;
- не является полноценной BI-системой;
- не устраняет проблемы автоматически без дополнительных механизмов;
- требует продуманной настройки метрик и алертов.
Типичные ошибки при использовании Prometheus
- Добавлять уникальный user_id или request_id в labels.
- Собирать слишком много метрик без понятной цели.
- Создавать алерт на каждое кратковременное изменение.
- Контролировать только CPU и память, игнорируя пользовательские показатели.
- Открывать интерфейс Prometheus в интернет без ограничения доступа.
- Хранить секреты в labels.
- Использовать слишком маленький scrape interval без необходимости.
- Не контролировать объем собственных временных рядов.
- Не резервировать мониторинг критичной инфраструктуры.
- Не проверять, действительно ли алерты помогают инженерам принимать решения.
Практический пример
Компания развивает интернет-магазин, состоящий из нескольких приложений. Пользователи периодически жалуются на медленное оформление заказов, но определить причину только по системным логам сложно.
На серверы устанавливают exporters, а приложения начинают публиковать собственные метрики. Prometheus собирает загрузку процессоров, память, количество запросов, время ответа и число ошибок.
Через Grafana создается дашборд. Инженеры видят, что в момент замедления резко растет время ответа API и количество активных соединений с базой данных.
Дополнительный анализ показывает, что один из запросов к базе выполняется значительно дольше обычного.
После оптимизации запроса показатели возвращаются к норме. Для повторного появления проблемы создается алерт по времени ответа API.
Таким образом, Prometheus помогает не только обнаруживать сбой, но и предоставляет данные для анализа его динамики.
Когда бизнесу нужен Prometheus
Prometheus особенно полезен компаниям, которые самостоятельно управляют приложениями и инфраструктурой.
- используются десятки или сотни серверов;
- приложения работают в Kubernetes;
- есть микросервисная архитектура;
- необходимо контролировать SLI и SLO;
- требуется автоматическое обнаружение проблем;
- важно видеть нагрузку и производительность во времени;
- используется SRE-подход;
- нужны собственные метрики приложений.
Когда Prometheus может быть избыточным
Для небольшого сайта на управляемом хостинге отдельная инфраструктура Prometheus может оказаться сложнее, чем требуется.
Если компания не управляет серверами и использует только SaaS-приложения, мониторинг инфраструктуры обычно находится в зоне ответственности поставщика.
Однако даже небольшой собственный сервис может получить пользу от Prometheus, если важны технические метрики, автоматические алерты и анализ производительности.
Prometheus в системе Observability
Prometheus следует рассматривать как один из компонентов Observability, а не как всю систему наблюдаемости.
Он особенно силен в работе с метриками. Для полной диагностики сложной системы обычно добавляют централизованные логи и распределенные трассировки.
Например, Prometheus показывает, что доля ошибок выросла с одного до десяти процентов. Трассировка помогает определить проблемный микросервис, а лог содержит текст конкретного исключения.
Такое сочетание значительно ускоряет расследование инцидентов.
Связанные термины
| Термин | Связь с Prometheus |
|---|---|
| Monitoring | Основная задача, для которой используется Prometheus |
| Observability | Более широкий подход, в котором Prometheus отвечает преимущественно за метрики |
| Grafana | Популярный инструмент визуализации данных Prometheus |
| PromQL | Язык запросов к временным рядам Prometheus |
| Exporter | Компонент, публикующий метрики для Prometheus |
| Node Exporter | Exporter для метрик Linux-серверов |
| Alertmanager | Компонент для маршрутизации и группировки уведомлений |
| Kubernetes | Одна из основных сред применения Prometheus |
| SLI | Измеримый показатель качества сервиса, который можно рассчитывать по метрикам |
| SLO | Целевой уровень сервиса, контролируемый на основе метрик |
| SRE | Подход к надежности, активно использующий Prometheus |
| OpenTelemetry | Стандарт и инструменты телеметрии, которые могут использоваться совместно с Prometheus |
Краткий итог
Prometheus — система мониторинга, предназначенная для сбора, хранения и анализа числовых метрик. Она регулярно получает показатели серверов и приложений, сохраняет их как временные ряды и позволяет анализировать данные с помощью языка PromQL.
Prometheus широко используется в Kubernetes, микросервисах, DevOps и SRE. Он помогает отслеживать нагрузку, ошибки, задержки, доступность и другие показатели, а также создавать правила автоматического оповещения.
Особенно эффективно Prometheus работает совместно с Grafana для визуализации, Alertmanager для уведомлений и системами логирования и трассировки для полноценной Observability. При внедрении важно контролировать cardinality, выбирать действительно полезные метрики и строить алерты вокруг проблем, которые требуют действий инженеров.
