jevmetrics
OpenTelemetry Collector processor that asks Jev how useful each metric is from its metadata and applies keep/drop policy.
Overview
jevmetrics is an experimental OpenTelemetry Collector metrics processor. When a new service introduces metrics nobody has classified, their names, descriptions, units, instrumentation scope and attribute keys still say a lot about what they mean. jevmetrics sends that metadata to Jev as typed questions, validates the answers and turns one probability into a keep or drop decision under explicit protection rules and thresholds.
It complements the OTel filter processor, which uses operator-written conditions, and usage-based tools like Grafana Adaptive Metrics. Inference is asynchronous: the incoming metric is kept while an assessment is queued, and cached assessments let later batches reuse the decision without another API call. The README recommends starting in annotate mode, which preserves all metrics and exports assessments for review, before using reduce mode. Status is alpha, and filtering effectiveness and savings must be evaluated on your own telemetry. It is for observability engineers managing metric volume.
What the decision model decides
| Type | Question | Answers |
|---|---|---|
| Yes / no | Is this metric likely useful enough to retain? | — |
How it works
- Metrics arrive at the Collector via OTLP
- Unprotected metrics without a cached assessment are summarised and queued for Jev
- Jev returns probabilities; answers are validated and cached
- annotate mode exports assessments; reduce mode applies protection rules and keep-score threshold
- Remaining metrics go to the configured exporter
Strengths
- Classifies unfamiliar instrumentation before usage history exists
- Asynchronous calls keep the pipeline flowing
- Caching avoids repeated API calls
- Deterministic policy decides the action, not the model
Caveats
- Alpha status
- Savings and accuracy unproven on real telemetry
- Metric metadata is sent to the hosted Jev API
At a glance
- Type
- Service
- Status
- prototype
- Language
- Go
- Runtime
- OpenTelemetry Collector processor
- Has code
- yes
- License
- Apache-2.0
Use cases and integrations
How curated lists describe it
Use it to assess unfamiliar instrumentation, review candidates for reduced retention, and selectively filter metrics before they reach a primary backend. Inference runs asynchronously, and cached assessments let subsequent batches use the same decision without another API call.
logicrw/awesome-jev-projectsOpenTelemetry Collector connector that uses Jev to assess metric metadata and apply retention policies before export.
hellogumbo/awesome-jev
Frequently asked questions
What does Jev decide?
How likely a metric is to be operationally useful, judged from its metadata.
Will it drop metrics immediately?
Not by default; annotate mode keeps everything and exports assessments for review.
How is it different from the filter processor?
The filter processor uses rules you write; jevmetrics infers value from metadata and then applies your policy.
Related projects
OpenTelemetry trace processor that asks Jev whether an operation is diagnostic, business-critical and worth keeping, and annotates spans.
ProjectprototypeGoScores OpenTelemetry logs with Jev for diagnostic value, priority and routing before any expensive LLM analysis.
ProjectbetaTypeScriptRecords the full distribution of every Jev answer by state, question and model, so thresholds can move over history with no new calls.
LibrarybetaPythonChinese-documented LLM gateway with virtual model routing, protocol conversion and a transparent Jev System One proxy.
ServicebetaTypeScriptSplunk search command that asks Jev typed questions about events and adds probabilities, choices and scores as fields.
AppbetaPythonBash-native CLI that filters any stream by meaning with Jev, like grep for semantics, so an agent wakes only for lines that matter.
ProjectbetaTypeScript