Foreword

This note is generally about pushgateway pushing , however, I will warn you and admit right away that the text will contain an example - an anti-pattern of pushgateway pushing, since the use of pushgateway is recommended in the case when the service does not work constantly (or for a service / started task in general there is no interface), which means that prometheus is better off constantly knocking on closed doors and not doing unnecessary work.

Introduction

So, pushgateway is a service where you can drop metrics when the standard prometheus pull model is not applicable (in the preface, I generally described how such a situation can arise and look). After the metrics have entered the pushgateway, prometheus already picks them up from there, and this implies several restrictions related to pushing metrics, for example, the absence of the up metric, since it is generated by prometheus itself for the polled instance, and in this case, it is only the pushgateway.

ps Although, if we talk about the up metric, then it is not needed, if you use pushgateway in a practical way.

Preparing prometheus for the pushgateway survey

Let's say we have a compose like this with prometheus and 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.

I decided to write a note, since I encountered a similar one in my work, I will say right away that the method from the example will not go into production, however, like using pushgateway in the absence of service discovery, for testing it can come off.