Comment utiliser correctement l'histogramme Prometheus du client Java pour suivre la taille plutôt que la latence?

Question

J'ai une API qui traite les collections. Le temps d'exécution de cette API est lié à la taille de la collection (plus la collection est grande, plus elle prendra de temps).

Je fais des recherches sur comment je peux le faire avec Prometheus mais je ne suis pas sûr de faire les choses correctement (la documentation manque un peu dans ce domaine).

la première chose que j'ai faite est de définir une métrique de résumé pour mesurer le temps d'exécution de l'API. J'utilise le taux canonique (somme)/taux (nombre) comme expliqué here. Maintenant, puisque je sais que la latence peut être affectée par la taille de l'entrée, je veux également superposer la demande taille sur le temps d'exécution moyen. Puisque je ne veux pas mesurer chaque taille possible, j'ai pensé que j'utiliserais un histogramme. Comme si:

Histogram histogram = Histogram.build().buckets(10, 30, 50) 
     .name("BULK_REQUEST_SIZE") 
     .help("histogram of bulk sizes to correlate with duration") 
     .labelNames("method", "entity") 
     .register(); 

Remarque: le terme « taille » ne pas se rapportent à la taille en octets, mais à la longueur de la collection qui doit être traitée. 2 articles, 5 articles, 50 articles ...

et dans l'exécution je (simplifié):

@PUT 
void process(Collection<Entity> entitiesToProcess, string entityName){ 
    Timer t = summary.labels("PUT_BULK", entityName).startTimer() 

     // process... 

    t.observeDuration(); 
    histogram.labels("PUT_BULK", entityName).observe(entitiesToProcess.size()) 
} 

Question:

• Plus tard, quand je regarde la BULK_REQUEST_SIZE_bucket à Grafana , Je vois que tous les seaux ont la même valeur, donc clairement je fais quelque chose de mal.
• Y a-t-il une façon plus canonique de le faire?

Answer 1

Votre code est correct (bien que bulk_request_size_bytes soit un meilleur nom de métrique). Le problème est probablement que vous avez des sous-optimums, 10, 30 et 50 octets étant assez petits pour la plupart des tailles de requêtes. J'essaierais de plus grandes tailles de seau qui couvrent des valeurs plus typiques.