Add metrics for actors and persistence
Maintainers usually reply within 1 day
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
- Issue type
- Feature
- Clarity
- Mostly clear
- Activity status
- Active
- Tech stack
- rust
- Domain
- backend, observability
Research direction
Start by reading the implementation of receive_incoming and the metrics facade documentation linked in the issue. Map the proposed actor and persistence measurements to the candidate events listed here, then benchmark the zero allocation path and settle metric names, labels, and feature gating. Done means metrics cover the agreed events while per actor labels remain opt in.
Written by the indexing model from the issue text.
Description
Part of #151.
tellus should emit metrics through the metrics facade, leaving the recorder and exporter to the application.
Candidates:
- Counters for dead letters, failures and restarts.
- Mailbox depth as a gauge, from the counter proposed in #152.
- Message handling latency, the time
receiveorhandletakes. - Persistence store latency and failures, for appends, reads and snapshot saves.
Labels are per actor type by default, from std::any::type_name, which is static. Per-actor labels are opt-in, because actor IDs are unbounded and would overload most metric backends.
Open questions:
- Feature:
receive_incomingis gated at zero allocations. Ametricsmacro without an installed recorder is cheap but not free, so benchmark it on that path before deciding whether metrics go behind a feature. - Naming: a consistent prefix and naming scheme for metric names and labels.
- Dominant language
- Rust
- Stars
- 37
- Forks
- 1
- Avg merge
- 6h 36m
- Merged PRs (30d)
- 123
Getting set up
- Ships a Dockerfile or Docker Compose file
- No pull request template
- No contributing guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from tellus-rs/tellus
-
fix(cluster): keep a panicking encode of a remote reply from failing the responderPossibly taken @cosmir17 claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
tellus-rs/tellus#312 · 2 comments ·
Maintainers usually reply within 1 day
-
docs: document the PostgreSQL store's schema for applications managing their ownPossibly taken @cosmir17 claimed this today. Open
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
tellus-rs/tellus#310 · 2 comments ·
Maintainers usually reply within 1 day
-
documentation question
Difficulty 2/5 1-3 hours Newbie friendliness 60/100
Maintainers usually reply within 1 day
-
good first issue test
Difficulty 2/5 1-3 hours Newbie friendliness 84/100
Maintainers usually reply within 1 day
-
Difficulty 4/5 3-5 days Newbie friendliness 42/100
tellus-rs/tellus#311 · 2 comments ·
Maintainers usually reply within 1 day
All issues in tellus-rs/tellus
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 82/100
ElectronicWave/Elemental#252 ·
Maintainers usually reply within 1 day
-
Difficulty 1/5 Under an hour Newbie friendliness 82/100
Maintainers usually reply within 1 day
-
area:mcp effort:low P5 source:agent
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
jlcodes99/cockpit-tools#3103 ·
Maintainers usually reply within 2 days
-
Difficulty 2/5 1-3 hours Newbie friendliness 80/100
eliasstravik/herdr-projects#1032 ·