Build a tool in Arroyo to parse logs
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 25/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Da chiarire
- Stato di attività
- Ferma
- Stack tecnologico
- google-cloud, kafka, python
- Ambito
- observability, stream-processing, tooling
Direzione di ricerca
Non sono indicati file di implementazione né test. Inizia mappando gli eventi di log dei consumer di Arroyo per l'inizializzazione, i crash, l'assegnazione e la revoca delle partizioni e i commit, quindi definisci l'interfaccia degli eventi estensibile e l'output della timeline; il lavoro sarà completato quando rebalance e stati di elaborazione saranno unificati tra i consumer, con il supporto per eventi personalizzati e per l'output Mermaid richiesto.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
On large consumer clusters (64 consumers or so) during rebalance it is very hard to understand what the whole cluster is doing from the logs. Logs are too verbose and since the consumer are too many it is hard to find causes and effects.
Let's make a tool solve the problem for us. The idea is to write a logs parser that takes GCP logs or any log, and looks for arroyo specific events like initialization, crash, partitions assigned, partition revoked and commits and produces a unified timeline (in whatever format) with higher level events like:
- shows barriers across consumers about when a rebalance starts to when the consumer group is stable. This is so we do not have to match partition assigned and revoked messages across consumers
- shows when each consumer starts processing data and committing data after getting partitions assigned.
- shows processing vs stuck times on a time line across consumers.
Make it extensible for the owner of the consumer so that snuba can add custom events.
Enterprise edition: generate a mermaid sequence diagram out of the log.
- Lingua principale
- Rust
- Stelle
- 63
- Fork
- 6
- Merge medio
- 2g 13h
- PR unite (30g)
- 7
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Nessun modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di getsentry/arroyo
-
bug good first issue Waiting for: Product Owner
Difficoltà 2/5 1-3 ore Idoneità per principianti 91/100
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 42/100
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 25/100
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 45/100
-
The arroyo produce step is potentially slower than sentry metrics indexer's produce step -- merge?Aperta
Difficoltà 5/5 Più di una settimana Idoneità per principianti 20/100
Tutte le issue di getsentry/arroyo
Issue simili
-
bug llm translation
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
I maintainer di solito rispondono entro 1 giorno
-
accounts bug decoding
Difficoltà 2/5 1-3 ore Idoneità per principianti 84/100
wboayue/rust-ibapi#1088 ·
I maintainer di solito rispondono entro 1 giorno
-
chmod -v: missing 'could not be accessed' line for operands that can't be stat'edForse già presa @emirmrkaljevic l’ha presa oggi. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
I maintainer di solito rispondono entro 1 giorno
-
bug
Difficoltà 2/5 1-3 ore Idoneità per principianti 67/100
gtk-rs/gtk-rs-core#2068 ·
I maintainer di solito rispondono entro 6 giorni