Hacktoberfest 2026：メンテナが10月に向けて印を付けた、オープンで初心者向けの issue。 Hacktoberfest の issue を見る

Requests and latency by endpoint, split by client

クローズ
  • 何か問題がありますか？
#2,149 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 2 日以内に返信

関連するプルリクエストがすでにマージされています。

  • #2156 @alanpeixinho による — マージ済み

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
58/100
issue の種類
機能追加
明瞭さ
明確に書かれている
活発さ
活発
技術スタック
django, python
領域
backend, data-visualization, observability

調査の方向性

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.

索引モデルが issue の本文から書いたものです。

説明

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.
主要言語
Python
スター
10
フォーク
32
平均マージ
3日 7時間
マージ済み PR（30日）
27

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

kernelci/dashboard のほかの issue

kernelci/dashboard の issue をすべて見る

似ている issue

Python の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。