Пушим метрики Prometheus с помощью pushgateway

  • Tutorial

Всё тоже, только у pushgateway пламя голубенькое в favicon


Предисловие


Данная заметка в целом о пуше метрик в pushgateway, однако, предупрежу и признаюсь сразу, что в тексте будет пример — анти-паттерна пуша метрик, так как использование pushgateway рекомендуется в случае, когда сервис работает не постоянно (или у сервиса/запускаемого задания вообще нет никакого интерфейса), а значит и prometheus'у лучше в закрытые двери постоянно не стучать и не заниматься лишней работой.


Введение


Итак, pushgateway — это сервис куда можно скидывать метрики, когда стандартная pull-модель prometheus'а не применима (в предисловии, я в общем описал, как такая ситуация может возникнуть и выглядеть). После того, как метрики попали в pushgateway оттуда их уже забирает prometheus и из этого вытекает несколько ограничений, связанных с пушем метрик, например, отсутствие метрики up, так как она формируется самим prometheus для опрашиваемого инстанса, а в данном случае — это только pushgateway.


p.s. Хотя, если говорить о up метрике, то она и не нужна, в случае, если вы используете pushgateway бестпрактайс-способом.


Готовим prometheus к опросу pushgateway


Допустим, у нас есть вот такой compose с prometheus и pushgateway:


# ....(тут какие-нибудь графаны и т.д.)   
prometheus:  
    restart: always  
    image: bitnami/prometheus:latest  
    links:  
        - pushgateway  
    volumes:  
        - ./.prom.yml:/opt/bitnami/prometheus/conf/prometheus.yml  

pushgateway:  
    restart: always  
    image: bitnami/pushgateway:latest  
    ports:  
        - 9091:9091  

В данном случае prom.yml должен выглядеть как-то так, чтобы собирать данные с pushgateway:


global: null
scrape_interval: 5s
scrape_timeout: 2s
evaluation_interval: 15s

scrape_configs:
  - job_name: pushgateway
    honor_labels: true
    static_configs:
      - targets:
          - 'pushgateway:9091'

Тут всё достаточно понятно, добавили только honor_lables, который, если вкратце разрешает конфликты имён лэйблов, то есть например, если у вашего сервиса есть метрика с лэблом "X" и у pushgateway, есть лэйбл "X", то при honor_lables=false у вас будет лэйбл "X" с pushgateway и "exported_X" с вашего сервиса, который запушил метрики в pushgateway, а при значении true будут отображаться только лэйблы вашего сервиса (опять же, если будет конфликт).


p.s. Незабываем о безопасности pushgateway — дока по-умолчанию рекомендует, например, использовать basic_auth.


Пушим метрики


Я бы мог привести красивый пример, соответствующий нормальной практике, однако, я подумал и решил, что давно мне минусов не ставили, потому будет пример пуша метрик из-за того, что настройка service_discovery отсутствует (в прод, понятное дело, это низя).


Итак, допустим, у нас есть воркеры Faust их много и они не в кластере (нет ни swarm, ни куберов), так же нет consul и иных способов в которые умеет prometheus, они просто спокойно запускаются в docker compose и размножаются параметром scale.


Больший ужас и крамолу, помимо пуша метрик, можно сделать рэйджировав порты, например, так:


ports:  
- "9100-9200:6066"  

И загонять в конфиг prometheus таргеты со всем множеством портов.


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


async def push_metrics():  
    def auth_handler(url, method, timeout, headers, data):  
        return basic_auth_handler(url, method, timeout, headers, data, PUSHGATEWAY_USERNAME, PUSHGATEWAY_PASSWORD)  
    push_to_gateway(PUSHGATEWAY_URI, job=f"{WORKERS_APP_NAME}-{ENV}", registry=registry_metrics, handler=auth_handler)  

@app.timer(interval=PUSH_METRICS_INTERVAL)  
async def push_metrics_cron():  
    await push_metrics()  

Как видите тут всё достаточно просто — указываем job name (при пуле метрик — это делается в конфиге prometheus'а), подставляем handler для аутентификации и указываем registry из которого будут пушиться метрики. Ну и собственно всё, запускаем и при открытии pushgateway веб-морды видим, что у нас через интервал загрузились метрики, далее оттуда их заберёт ранее настроенный prometheus.


Послесловие


Заметку я решил написать, так как столкнулся с подобным в работе, сразу скажу, что способ из примера в прод не пойдёт, однако, как применение pushgateway при отсутствии service discovery, для тестирования — это сойти может.

Только зарегистрированные пользователи могут участвовать в опросе. Войдите, пожалуйста.

Вам приходилось пушить prometheus метрики?

  • 45,8%Да11
  • 37,5%Нет9
  • 16,7%Смешной ответ4

Средняя зарплата в IT

120 000 ₽/мес.
Средняя зарплата по всем IT-специализациям на основании 3 502 анкет, за 1-ое пол. 2021 года Узнать свою зарплату
Реклама
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее

Комментарии 5

    +1

    Лучше использовать statsd-exporter

      0

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


      PS. В issue faust-репозитория есть разговор про прометеус монитор из коробки, думаю, что в ближайших версиях такая возможность появится.

      +2
      а как быть с мертвыми метриками
        0

        Под "мертвыми", Вы что ввиду имеете?

        0

        Также метрики можно пушить напрямую в VictoriaMetrics или в vmagent.

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое