Produits Entr'ouvert » w.c.s.

(pour info j'ai fait ça sur la recette via le uwsgi-local.ini)

On se donne un peu de temps de vie en recette, puis en prod dans un local.ini identique, avant de patcher ?

Yes. (et en attendant on peut préparer le passage d'autres briques à uwsgi)

A jouer avec ça, je suis pas très à l'aise : un seul processus je ne sais pas comment ça va se comporter par rapport à la gestion harakiri et ce genre de choses dans uwsgi. On perd aussi pas mal de visibilité via uwsgitop.

Ouaip je suis pas chaud bouillant non plus, qu'est-ce qui embête prometheus dans le fait d'avoir des process ?

De base pas de gestion mutliprocess dans https://github.com/prometheus/client_python#multiprocess-mode-gunicorn : les stats ne sont pas agrégées entre les processus.
Une requête de demande de stats aura pas les même résultats si elle est servie par le processus X versus processus Y.

Moi aussi je trouve ça un peu violent de passer à un seul processus, mais contourner le problème comme décrit dans la doc semble un peu pénible aussi.

Lu ailleurs (https://hynek.me/talks/prometheus/), mais je ne sais pas si c'est pertinent pour nous : « Another approach is to expose your metrics per process. In uWSGI you can use uwsgi.worker_id() as a label »

Lu ailleurs (https://hynek.me/talks/prometheus/), mais je ne sais pas si c'est pertinent pour nous : « Another approach is to expose your metrics per process. In uWSGI you can use uwsgi.worker_id() as a label »

Oui c'est une bonne approche, de manière apparentée inclure le pid dans les paramètres de la métrique (pour que ça soit ok aussi avec gunicorn). (et côté graphe ça accumulera les valeurs).