Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Requests and latency by endpoint, split by client

Cerrado
#2,149 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

Ya se ha fusionado un pull request relacionado.

  • #2156 de @alanpeixinho — fusionado

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
58/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
django, python

Línea de trabajo

Start by reading #2144, get_client_info, and BackendRequestMetricsMiddleware to understand the existing client label and counter. Trace the dashboard panels named in the issue and the existing Django latency histogram. Done means API requests are recorded once with endpoint and client labels, the requested count and p50/p95 panels use the new histogram, and the listed kci-dev, Chrome, curl, and /admin/ cases pass.

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

Descripción

Problem

"Total Calls by Endpoint" and "Average Response Time by Endpoint" both read django_http_requests_latency_seconds_by_view_method, labeled only by view and method. A browser session and a kci-dev call to the same view are one line. The average mixes them, and the board shows no p50 or p95. "Total Calls by Endpoint" is that histogram's _count, not a separate counter.

Ben asked for requests by endpoint, and for p50 and p95, split between the browser and kci-dev. Don asked for webpage use versus API use. Both are the same cut: the dashboard UI and the CLI call the same API.

Almost every view is already under /api/. Outside it, only /admin/ and /health/ exist, and health is already excluded. Timing those API calls again on the Django histogram would duplicate them without a client label.

Proposal

Depends on #2144, which adds client (dashboard, kci-dev, script, bot, unknown) in get_client_info and puts that label on the existing counter dashboard_backend_requests_by_client_total. No new counter.

Record latency once, in BackendRequestMetricsMiddleware, for /api/ only. On that same request, increment the existing counter and observe a histogram labeled by endpoint and client, using the same buckets as the Django latency histogram. The histogram's _count is the latency count. Stop observing django_http_requests_latency_seconds_by_view_method for /api/ requests. Leave that histogram for /admin/. Leave the Django middleware's other counters (status, exceptions) as they are.

Counts. Point "Total Calls by Endpoint" at dashboard_backend_requests_by_client_total, summed by endpoint and client. Filter with client, not a list of browser names. script, bot, and unknown stay on the panel, so the total still matches the counter.

Latency. Point "Average Response Time by Endpoint" and the latency half of "Endpoint Performance Summary" at the new histogram (_sum / _count). Add p50 and p95 from its buckets, split by client.

Tests

  • A kci-dev/<version> request and a Chrome request to the same endpoint land on client="kci-dev" and client="dashboard", on the existing counter and on the new histogram, and are not observed on django_http_requests_latency_seconds_by_view_method.
  • A curl/ request lands on client="script" and stays visible on both.
  • An /admin/ request is still observed on the Django latency histogram.
Lenguaje dominante
Python
Estrellas
10
Forks
32
Merge medio
3 d 7 h
PR fusionados (30 d)
27

Preparar el entorno

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.

Más de kernelci/dashboard

Todos los issues de kernelci/dashboard

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.