Что это
Prometheus — система мониторинга, которая собирает числовые метрики с приложений и инфраструктуры, хранит их как временные ряды и помогает понять, что происходит с сервисом во времени.
Prometheus ставят там, где сервисы надо мерить по метрикам, а не ждать жалоб. Он собирает числовые сигналы, считает запросы и запускает оповещения до того, как проблема станет видна пользователю.
Prometheus — система мониторинга и оповещения по числовым метрикам. Она регулярно опрашивает сервисы и инфраструктуру. Данные хранятся как временные ряды, а команда работает с ними через PromQL и правила. Его часто путают с Grafana, но роли у них разные. Prometheus собирает и считает данные, а Grafana показывает их на панелях. Поэтому навык нужно понимать как полный маршрут метрики: экспортер, опрос, временной ряд, PromQL, alert rule и Alertmanager. Именно на этом маршруте виден реальный уровень. Важно не просто поднять сервер. Нужно выбрать полезные метрики, не раздуть число рядов и превратить сигнал в оповещение, после которого дежурный понимает, что делать.
Prometheus — система мониторинга, которая собирает числовые метрики с приложений и инфраструктуры, хранит их как временные ряды и помогает понять, что происходит с сервисом во времени.
Prometheus проще всего понять через путь сигнала. Сервис или экспортер публикует метрики, сервер их опрашивает, PromQL считает нужный срез, а правило решает, пора ли поднимать тревогу. На этом пути легко увидеть, где ломается система наблюдения: в плохой метке, шумном правиле, пропавшей цели или слишком дорогом количестве рядов.
Важно: Prometheus не заменяет логи, трассировку и дашборды. Он отвечает за числовые временные ряды и правила по ним. Для текста ошибок нужны системы журналов, для пути отдельного запроса — трассировка, для удобного экрана команды — Grafana или другой визуальный слой.
У Prometheus есть понятная цепочка: сервис отдаёт метрики, сервер их опрашивает, PromQL выбирает нужные ряды, правила фиксируют агрегаты и отправляют сигналы.
Приложение или экспортер публикует числовые показатели в формате, который понимает Prometheus.
Сервер по расписанию забирает значения, добавляет метки и хранит их как временные ряды.
Запросы считают скорость, долю ошибок, задержку, насыщение ресурса и другие признаки состояния.
Если условие держится дольше заданного времени, сигнал уходит в Alertmanager и дальше в канал дежурства.
Prometheus нужен там, где состояние системы должно быть измеримым. Сервисы меняются часто, узких мест много, а команда отвечает за доступность, скорость реакции и качество сигнала во время дежурства.
Ошибки, задержка, нагрузка и признаки деградации до первой жалобы.
Узлы, Pod, базы, очереди и ресурсные узкие места.
Правила, которые ведут к понятному действию, а не к шуму.
Измеримые цели по доступности, задержке и бюджету ошибок.
Prometheus заметен в 3 направлениях рынка с долей выше 5%.
Рабочий Prometheus строится вокруг метрик, PromQL, правил и понимания цены лишних рядов.
Отделять показатели, которые помогают действовать, от декоративных графиков.
Считать скорость, процент ошибок, перцентили задержки и агрегаты по нужным меткам.
Собирать правила с понятным влиянием на сервис и без лишнего шума.
Понимать, какие метки создают слишком много рядов и замедляют систему.
Если коротко, Prometheus — это измерительный слой: он регулярно снимает числовые показатели и позволяет спросить систему, что с ней происходит во времени. Важно не смешивать его с визуализацией, классическим серверным мониторингом и сбором всей телеметрии подряд.
Prometheus собирает и считает метрики. Grafana читает их и показывает на экране.
Prometheus решает, что горит. Alertmanager группирует и доставляет уведомления.
Метрики показывают числовой сигнал во времени, а логи дают текст событий и детали.
Для дежурства часто хватает локального окна Prometheus, а длинную историю уводят в отдельный внешний слой.
Главный материал Prometheus — числовые метрики, привязанные ко времени и меткам. Мало просто снять число. Нужно ещё понять, как подписаны ряды и кто потом будет реагировать на сигнал. Одна лишняя метка с почти уникальным значением может резко раздуть хранилище и испортить запросы. Поэтому перед добавлением новой метрики обычно проверяют вопрос, источник, метки, интервал опроса и владельца реакции.
Запросы, ошибки, задержки, очереди, время обработки и внутренние счётчики.
Процессор, память, диск, сеть, состояние узлов и контейнеров.
Состояние Kubernetes, баз данных, балансировщиков, очередей и других систем.
Имя задания, экземпляр, сервис, окружение и другие метки, по которым PromQL отделяет один источник сигнала от другого.
Эти инструменты часто встречаются рядом, но отвечают за разные части наблюдаемости.
Сбор, хранение и запросы по временным рядам.
Когда нужно измерять состояние сервисов и инфраструктуры.
Не заменяет логи и трассировку.
Панели, дашборды и единый экран команды.
Когда нужно показать данные Prometheus и других источников.
Не собирает метрики и не проектирует правила.
Классический мониторинг хостов и готовых проверок.
Когда важны серверы, шаблоны и централизованная эксплуатация.
Слабее работает с сервисными метриками и PromQL-подходом.
Инструментация и передача метрик, логов и трасс.
Когда нужен общий способ собирать телеметрию в разных сервисах.
Не заменяет сам Prometheus как хранилище и query-слой.
Prometheus переносится между ролями: DevOps-инженер, Go-разработчик, Java-разработчик. В одном треке этот навык может быть основным рабочим инструментом, а в другом - сильным прикладным усилителем основной специализации.
DevOps-инженер держит 145.8% вакансий по навыку.
Ещё 7 ролей используют Prometheus
Prometheus ценен не абстрактным знанием инструмента, а повторяющимися рабочими задачами: быстро получить ответ, проверить расхождение, подготовить рабочий слой для команды и довести решение до результата.
Настроить цель опроса и проверить, что метрики отражают ошибки, задержки и нагрузку.
Собрать выражение, которое объясняет проблему: где деградация, насколько она сильная и кого затрагивает.
Задать условие и время выдержки так, чтобы команда получала сигнал о проблеме, а не поток случайных уведомлений.
Проверить цель, экспортер, сетевой доступ, метки и то, не устарел ли запрос после изменения сервиса.
Найти метки, которые создают лишние ряды, и оставить только измерения, нужные для диагностики.
Перевести техническую метрику в понятный показатель качества сервиса.
Это разные слои: Prometheus собирает и считает метрики, Grafana помогает их показывать.
Метки с идентификаторами пользователей, заказов или запросов быстро раздувают число рядов и делают систему дорогой.
Хорошее правило учитывает длительность, масштаб, влияние на пользователя и понятный порядок реакции.
Запрос полезен, когда помогает принять решение во время реальной деградации.
Prometheus стал привычным слоем метрик в облачной и контейнерной инфраструктуре. Но рынок ценит не установку сервера, а умение проектировать полезные метрики и тихие оповещения. Навык особенно заметен там, где команда отвечает за сервисы с реальной эксплуатацией: API, кластеры, очереди, базы, фоновые задачи и внутренние платформы. Чем дороже простой, тем важнее качество сигнала. Красивый график без пользы для дежурного уже никого не впечатляет. Сейчас ценят не картинку, а понятный маршрут реакции. И способность быстро отделить реальную тревогу от шума. Это уже часть инженерной зрелости команды. Именно поэтому хороший сигнал ценят выше красивой панели.
Prometheus востребован там, где инструмент реально ускоряет повторяемые задачи команды, а не существует отдельной теорией.
Спрос держится дольше, когда навык нужен не эпизодически, а как часть ежедневного цикла разработки, проверки или доставки.
Prometheus чаще ищут там, где процесс уже стандартизирован и без этого инструмента команда теряет скорость и предсказуемость.
Prometheus стабильно удерживается в активном прикладном слое рынка.
Prometheus сохраняет высокий текущий спрос на рынке: 716 активных вакансий, #21 по рынку, 9.2% IT-вакансий. Ниже показано число открытых вакансий на конец каждого месяца: это исторический ряд по состоянию на конец месяца, а не текущий срез рынка на сегодня.
#21 по рынку • 9.2% IT-вакансий
+7 вакансий и +1% к предыдущему месяцу.
Prometheus усиливает доход в ролях, где человек отвечает за надёжность сервиса, дежурство и эксплуатацию. Сам по себе инструмент редко продаётся отдельно. Ценность появляется вместе с Linux, Kubernetes, сетями, SRE-практикой и умением...
91 активных вакансий с зарплатой • покрытие 12.2% зарплатной выборки
Senior → Senior
Senior - основной уровень рынка (54%)
Сейчас на рынке 23 активных junior-вакансий с Prometheus. Это 4% всех вакансий по навыку, поэтому для старта важнее всего смотреть на реальный объём junior-окна и на стек, который рынок ждёт рядом.
4% всех вакансий по навыку • Senior / Junior 13.5x
Окно входа узкое: рынок чаще нанимает с опытом.
Медианная вакансия с Prometheus ожидает около 20 навыков в стеке. Это широкий стартовый набор: рынок обычно ищет не один изолированный инструмент, а рабочую комбинацию соседних навыков.
навыки из junior-вакансий, где встречается Prometheus
Prometheus редко живёт изолированно: чаще всего рынок видит его рядом с Grafana, Kubernetes, Docker. Самая плотная связка сейчас - Grafana: оба навыка встречаются вместе в 87% вакансий.
Главная связка: Grafana • 87% вакансий. Показываем общерыночные связки Prometheus: не junior-минимум из блока выше, а навыки, которые чаще всего встречаются рядом с ним в одной вакансии.
навыки, которые рынок чаще всего видит рядом в одной вакансии
не базовый минимум, а более сильные комбинации стека
Учить Prometheus лучше на живом сервисе. Сначала поднять цель опроса и увидеть метрики. Потом написать несколько запросов PromQL и собрать одно правило, которое действительно ведёт к действию. Такой путь быстрее показывает главное: метрика должна отвечать на рабочий вопрос, а не просто существовать. Уже после этого полезно разбирать retention, remote write и длинную историю хранения. Иначе документация читается, а сигнал так и не становится рабочим. Хорошо помогает и небольшой учебный сбой с реальной проверкой оповещения. После него проще понять цену плохого правила. И видно, почему команда так много говорит о шуме.
Разобраться с форматом метрик, целями, экспортерами, интервалом опроса и устройством временных рядов.
Научиться писать запросы, правила записи и правила оповещений для конкретных рабочих вопросов.
Контролировать число уникальных рядов, пропавшие цели, ложные сигналы и шум уведомлений.
Связать Prometheus с Grafana, Alertmanager, Kubernetes, OpenTelemetry, логами и процессом дежурств.
Старт должен быстро привести к рабочему сигналу. Поднимите одну цель опроса, проверьте страницу targets, выполните три простых запроса и соберите одно оповещение. Затем намеренно остановите сервис или испортите метку и посмотрите, как меняется поведение системы. Так становится ясно, где Prometheus помогает, а где мониторинг только делает вид, что всё спокойно. Такой учебный сбой даёт намного больше, чем длинный набор готовых дашбордов. Он сразу связывает метрику с реальной реакцией дежурного. И показывает, как быстро может появиться шум. После этого alerting воспринимается уже совсем по-другому.
Возьмите приложение или node exporter и убедитесь, что Prometheus видит метрики.
Проверьте частоту запросов, долю ошибок и задержку за несколько минут.
Настройте условие, которое сообщает о реальной деградации, и проверьте его вручную.
Посмотрите, не создаёт ли сервис лишние ряды и не срабатывает ли правило на краткий всплеск без пользовательского влияния.
Для инструментов вроде Prometheus на одной странице полезно держать и объяснение роли на рынке, и быстрые переходы к официальным ресурсам.
Prometheus — рабочий инструмент или платформа, а не вся инженерная практика целиком.
Лучший вход в Prometheus — один живой рабочий процесс, где видно не интерфейс, а реальное поведение инструмента.
После короткого объяснения переходите к официальной документации, одному туториалу и одному живому примеру по Prometheus.
Перспективы Prometheus завязаны не только на текущем спросе, но и на том, как навык встраивается в новые платформы, инструменты и рабочие контуры.
Пока команды эксплуатируют распределённые сервисы, им нужны временные ряды, запросы и правила.
Рынок быстрее отличает инженера, который понимает качество метрик, от того, кто только ставит готовый стек.
Инструменты могут предложить выражение, но порог, смысл сигнала и порядок реакции остаются инженерным решением.
Prometheus — это система для сбора, хранения и анализа числовых метрик. Она помогает понять, как ведут себя сервисы и инфраструктура во времени, и подать сигнал, когда состояние выходит за норму. Это один из базовых инструментов рабочего мониторинга.
Prometheus собирает и считает метрики, а Grafana показывает их на дашбордах. На практике они чаще работают вместе, а не заменяют друг друга. Спорить, что из них лучше, обычно просто бессмысленно. Это разные роли внутри одного контура.
PromQL — это язык запросов к метрикам Prometheus. Им считают скорость ошибок, задержку, агрегаты по меткам и условия, по которым должно сработать оповещение. Без него система превращается в склад чисел без рабочего смысла. Именно через PromQL метрика начинает отвечать на вопрос команды.
Alertmanager принимает сигналы от Prometheus, группирует похожие уведомления, убирает повторы и отправляет их в нужный канал. Без него дежурство быстро тонет в шуме. Особенно это заметно во время одного большого сбоя с множеством зависимых сервисов.
Каждая новая комбинация меток создаёт отдельный временной ряд. Если в метки попадают почти уникальные значения, хранение дорожает, а запросы и правила начинают работать хуже. Поэтому кардинальность меток — одна из самых частых эксплуатационных ловушек. Ошибку тут обычно замечают уже после роста нагрузки.
С одного живого сервиса. Поднимите цель опроса, проверьте метрики, напишите несколько запросов и соберите одно понятное оповещение. Это даёт больше, чем обзор десятка экранов без практики, потому что сразу связывает цифру с реальной реакцией команды.