gauge.set_function() doesn't work in multiprocess mode
Ninguém assumiu esta issue ainda.
Avaliação
- Dificuldade
- 4/5
- Tempo estimado
- 3-5 dias
- Facilidade para iniciantes
- 35/100
- Tipo de issue
- Bug
- Clareza
- Precisa de esclarecimento
- Status de atividade
- Estagnada
- Stack de tecnologia
- python
- Domínio
- observability-sre
Direção de pesquisa
Reproduza a discrepância usando o ponto de entrada collect() de multiprocess.py e o comportamento de set_function() de registry.py, com prometheus_multiproc_dir configurado. Compare os valores reportados entre os modos multiprocess e determine o comportamento esperado para set_function(); considera-se concluído quando o comportamento escolhido estiver documentado e o relato duplicado ou incorreto de 0.0 tiver sido corrigido.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
Multiprocess mode's collect() reads the registry files and aggregates metrics that have been written to prometheus_multiproc_dir.
This doesn't work with gauge.set_function() which does not record its value. The provided function is just called during collection.
That means with the following code:
registry = CollectorRegistry()
Gauge("test", "test", registry=self._registry).set_function(lambda: 100)
multiprocess.MultiProcessCollector(registry)
The output will be:
# HELP test test
# TYPE test gauge
test 100.0
# HELP test Multiprocess metric
# TYPE test gauge
test{pid="10705"} 0.0
Current side effects:
- If any mode other than
allorliveallis used, thepidtag won't be included. This results in duplicate metrics being reported to Prometheus. Prometheus currently only uses the first metric it reads, which is non-deterministic due to iteration over the registry's dictionary. - If
registry=Noneto avoid double reporting, only the default value of0.0is reported. - Current way to work around it is to use the mode
alland to ignore gauges in Prometheus and with the tagpid.
Proposal:
I'm not sure how you could incorporate set_function into the multiprocess registry and I'm not convinced how useful of a feature it would be. Is it reasonable to add a new multiprocess_mode: exclude which would prevent the incorrect 0.0 value being reported? Or would it be better to just add documentation to recommend using two independent registries?
- Linguagem predominante
- Python
- Estrelas
- 4.4k
- Forks
- 876
- Merge médio
- 8d 4h
- PRs com merge (30d)
- 1
Guia de contribuição
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de prometheus/client_python
-
bug
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 70/100
prometheus/client_python#1177 · 1 comentário ·
-
Dificuldade 4/5 3-5 dias Facilidade para iniciantes 45/100
prometheus/client_python#1210 ·
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 58/100
prometheus/client_python#1199 · 1 reação ·
-
Dificuldade 5/5 Mais de uma semana Facilidade para iniciantes 35/100
prometheus/client_python#1176 ·
-
Dificuldade 1/5 1-3 horas Facilidade para iniciantes 52/100
prometheus/client_python#1126 · 2 comentários ·
Todas as issues de prometheus/client_python
Issues semelhantes
-
agent-ready documentation needs-triage
Dificuldade 1/5 1-3 horas Facilidade para iniciantes 88/100
-
documentation
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 91/100
-
workflow-status page template still says reusable workflows are "triggered only by workflow_call:" Aberta
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 92/100
-
instance instance add
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 72/100
searxng/searx-instances#939 · 1 comentário ·
-
area-deployment area-integrations triage:bot-seen
Dificuldade 2/5 Meio dia Facilidade para iniciantes 86/100