5 commentaires
yo des fois c'est juste un souci de scrape interval. si ton service met disons 30s à démarrer et prometheus est configuré avec un scrape interval de 15s le temps qu'il se relève il peut rater quelques scrapes et ça donne une impression de vide. aussi check la config consul pour voir si le service est bien enregistré rapidement après le redémarrage
le scrape interval est à 10s et le démarrage des services prend 5-10s. consul est assez réactif pour l'enregistrement. par contre j'ai vu des messages dans les logs de prometheus du genre target stale ou failed to scrape target endpoint. ça correspond au moment du redémarrage
ah ok target stale c'est normal si le target n'est plus là. par contre failed to scrape c'est plus intéressant. est-ce que quand le service redémarre il change d'adresse ip ou de port ? ou ptete le scrape timeout de prometheus est trop court et le service pas encore vraiment prêt à répondre sur son endpoint même s'il est up
non l'ip et le port restent les mêmes. le scrape timeout est à 5s. j'ai essayé de l'augmenter à 15s et là les métriques sont récupérées plus vite après le redémarrage. ptete que le endpoint répondait pas encore assez vite juste après le start même si le service était "up"
Laisser une réponse
Vous devez être connecté pour poster un message !
salut
on a un souci avec prometheus. quand on redémarre nos applications (nos cibles prometheus) on perd les métriques pendant quelques minutes après le redémarrage. le job scrape prometheus met du temps à les récupérer. c'est un microservice java avec spring boot actuator donc il expose bien les métriques des le start. on utilise consul pour la discovery.