FR: metrics and stats
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Anfängerfreundlichkeit
- 35/100
- Issue-Typ
- Feature
- Klarheit
- Größtenteils klar
- Aktivitätsstatus
- Veraltet
- Tech-Stack
- docker, prometheus
- Bereich
- observability
Rechercherichtung
Use the issue body as the starting specification and separate the operational metrics request from the index metrics request before investigating the project. Identify where component resource usage and repository indexing outcomes are exposed, then verify that Prometheus-format metrics cover the requested file, repository, duration, success, and failure measurements.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
This issue is a request for two things that are related but might end up being implemented very differently.
If you want me to break this up into multiple issues, let me know!
The first ask: basic operational metrics.
Currently, I am running this as a docker container and am using Google's ContainerAdvisor to expose basic metrics around CPU/Memory usage. This works well enough since my primary concern is "did I allocate enough RAM to this or should I add more?!". Since there are multiple processes running inside the container, there's no good way to get insight into the memory/cpu...etc of any one component. Not a concern for my purposes, but I can certainly imagine larger deployments where knowing cpu/disk/memory...etc consumption of node vs zoekt would come in very handy.
For these metrics, standard prometheus format would be ideal / most accessible for everybody.
The second ask: metrics about what's in the index.
- count of files in the index
- number of repos in the index
- how long indexing takes (combined with a counter for number of repos, I can calc average index time per repo...)
- success/fail count per repo (if - suddenly - the number of repos successfully refreshed/indexed inverts with the number of repos that could not be successfully refreshed/indexed, that's an alert that I need to go page somebody to go figure out what's happened to our git server!)
- Vorherrschende Sprache
- TypeScript
- Sterne
- 3.9k
- Forks
- 374
- Ø Merge
- 21 Std. 18 Min.
- Gemergte PRs (30 T.)
- 39
Beitragsleitfaden
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus sourcebot-dev/sourcebot
-
bug triage needed
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 84/100
sourcebot-dev/sourcebot#1681 · 1 Kommentar ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 84/100
sourcebot-dev/sourcebot#1633 ·
-
bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 78/100
sourcebot-dev/sourcebot#1384 · 4 Kommentare ·
-
ask_sb bug
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 76/100
sourcebot-dev/sourcebot#1137 · 4 Kommentare ·
-
bug triage needed
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 48/100
sourcebot-dev/sourcebot#1661 · 1 Kommentar ·
Alle Issues in sourcebot-dev/sourcebot
Ähnliche Issues
-
bug(cli): hapi doctor inline-media prints a fabricated B:\ helper-script path in packaged installs Offen
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 70/100
-
Crush Offen
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 85/100
catppuccin/catppuccin#3125 ·
-
Add a SECURITY.md Offen
Schwierigkeit 1/5 Unter einer Stunde Anfängerfreundlichkeit 90/100
ElementsProject/cln-application#167 · 1 Kommentar · 1 Reaktion ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100
Quantco/pnpm-licenses#17 ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 75/100