Add an option to expose the metric timestamps from the Prometheus format
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 42/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Estancado
- Stack tecnológico
- prometheus, python
- Área
- observability
Línea de trabajo
Empieza por prometheus_client/samples.py y exposition.py para rastrear cómo se representan y formatean las marcas de tiempo de los samples. Después inspecciona metrics.py::_child_samples y multiprocess.py en torno a la lógica de agregación mencionada, incluida la pull request y el issue relacionados. Se considera terminado cuando una opción expone las marcas de tiempo en la salida de Prometheus y las conserva tanto en el modo multiproceso como en el modo sin multiproceso.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Spin off from https://github.com/prometheus/client_python/pull/967 and https://github.com/prometheus/client_python/issues/847
Background
The Prometheus exposition format (https://github.com/prometheus/docs/blob/main/content/docs/instrumenting/exposition_formats.md#comments-help-text-and-type-information) allows exporters to specify an optional timestamp for each sample. If this is unset, the collector uses the timestamp that the sample is collected.
This timestamp is useful in a certain situation. My concrete use case is to expose GitHub API rate limit as a metric. This API rate limit is a value that decreases over time, and periodically it resets to the maximum value. We can get this API rate limit value as a HTTP response header when calling GitHub API.
Imagine a situation where there are two (physical) servers making this GitHub API call, and for the sake of illustration, let's assume that one server issues more requests and the other one does less.
| Server1 (frequently issue requests) | Server2 (somehow less requests) | |
|---|---|---|
| Observed API limit | 100 | 4900 |
| (Last time a server made a GH API call) | 3 minutes ago | 50 minutes ago |
From human's point of view, because server1 made an API call more recently than server2, we can tell that server1's observed API limit is the current value. However, without exposing the sample timestamp, Prometheus cannot distinguish which one is the most recent value. This is because when Prometheus collects sample from these two servers, when there's no timestamp specified, it treats these samples as "the samples collected now".
By exposing the sample timestamp, Prometheus should be able to treat these two samples correctly, and it can tell that server1' s value is the most recent value.
Request
With https://github.com/prometheus/client_python/pull/967, client_python should learn timestamps for Gauge metrics in the multiprocessing mode. This issue is asking for an option to expose those timestamps via Prometheus format.
Code pointers
Sample already can take a timestamp (https://github.com/prometheus/client_python/blob/249490e4ed30d4266182cfce50fe7046a484affd/prometheus_client/samples.py#L49), and so as the Prometheus exposition formatter (https://github.com/prometheus/client_python/blob/249490e4ed30d4266182cfce50fe7046a484affd/prometheus_client/exposition.py#L191-L194).
For the multiprocessing mode, changing the metrics aggregation logic to propagate the timestamps (https://github.com/prometheus/client_python/blob/249490e4ed30d4266182cfce50fe7046a484affd/prometheus_client/multiprocess.py#L146) would suffice (based on a flag or something).
For the non-multiprocessing mode, need to change this _child_samples (https://github.com/prometheus/client_python/blob/249490e4ed30d4266182cfce50fe7046a484affd/prometheus_client/metrics.py#L433-L434) to take a timestamp.
- Lenguaje dominante
- Python
- Estrellas
- 4.4k
- Forks
- 876
- Merge medio
- 8 d 4 h
- PR fusionados (30 d)
- 1
Guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de prometheus/client_python
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
prometheus/client_python#1177 · 1 comentario ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 45/100
prometheus/client_python#1210 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 58/100
prometheus/client_python#1199 · 1 reacción ·
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 35/100
prometheus/client_python#1176 ·
-
WSL and MultiProcessCollector Abierto
Dificultad 1/5 1-3 horas Aptitud para principiantes 52/100
prometheus/client_python#1126 · 2 comentarios ·
Todos los issues de prometheus/client_python
Issues similares
-
essnmx good first issue
Dificultad 1/5 Menos de una hora Aptitud para principiantes 95/100
-
[Feature] 奇物选择添加优先级 Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
syfoud/Simulated_Scepter#174 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
Giskard-AI/giskard-oss#2840 · 1 comentario ·
-
A claim comment carrying the issue number is silently declined while the workflow reports success Abiertoarea: repo bug perceived difficulty: 2
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
yeti-platform/yeti#1380 ·