prometheus / prometheus/client_python

Aggregate expired pid db files, control the number of files and improve scrape effectiveness

Abierto
#443 1 comentario 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Lenguaje dominante
Python
Estrellas
4.4k
Forks
876
Merge medio
8 d 4 h
PR fusionados (30 d)
1

Descripción

history related issues: https://github.com/prometheus/client_python/pull/441
https://github.com/prometheus/client_python/pull/430

Can we aggregate all the db files from a period of time ago and non-current pid into a total db file, to control the number of pid files ?

I have realized this idea with golang,here are some details:

Project deploy info:
gunicorn django
128 workers
gunicorn max_requests:10000(create a new pid file almost every minute)

  1. I can't solve the problem that the pid file has been growing, and it can reach 6,000 in four days;
  2. Try to delete the expired pid regularly in the code, but it will cause the figure to drop with grafana;
  3. The time to request metric is getting longer as the program runs.

Improve scrape efficiency:
I used golang to rewrite the logic of python aggregate metrics(generate metric still using python). After rewriting, each scrape time is less than 1 second.

Solve the growing pid files:
Aggregate all the db files from a period of time ago and non-current pid into a total db file. Then delete these files. When calculating metric, history total db + curent pid = current pid db. (i do it every hour)

Now, num of pid files is <200 in my project. if we can do change this, it would be a big strengthen. Just like prometheus will also aggregate historical data

Guía de contribución

Abrir la guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Línea de trabajo

Comienza revisando los pull requests relacionados con el historial #441 y #430; después, sigue el comportamiento de agregación y scrape de Python descrito para el despliegue de Gunicorn con 128 workers. Compara el enfoque propuesto de agregación y eliminación periódicas con los resultados actuales de las métricas en Grafana; se considera terminado cuando los archivos de base de datos pid tienen un tamaño acotado, se conservan los valores históricos y el tiempo de scrape es inferior a un segundo.

Escrito por el modelo de indexación a partir del texto del issue.

Evaluación

Stack tecnológico
django, go, grafana, prometheus, python
Área
backend, observability, performance
Tipo de issue
Nueva funcionalidad
Dificultad
5/5
Tiempo estimado
Más de una semana
Estado de actividad
Estancado
Claridad
Necesita aclaración
Aptitud para principiantes
25/100

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.