Following up on my earlier thread (Observability support for openHAB based on OpenTelemetry) — I’d like to propose adding OpenTelemetry-based observability to openHAB, structured so the instrumentation itself never knows or cares which backend receives the data. openhabian would own backend choice and default to the Grafana stack it already provisions on Raspberry Pi installs.
Rough shape: openhab-core gains a launch-time hook to attach OTel auto-instrumentation to the JVM (inert unless enabled — no new hard dependency), openhab-distro bundles the artifact needed for that, and openhabian handles setup/activation and backend selection, defaulting to the Grafana stack it already sets up. I’ve worked through the detail below (transport choice, whether to run a local collector, config approach, repo split) so reviewers can dig in as far as they want — but the one thing I’d like an early read on before going further is at the bottom.
Why OpenTelemetry
Vendor-neutral wire format (OTLP) — works with Grafana/Prometheus/Loki, Dynatrace, Jaeger, Honeycomb, etc., without openHAB core ever depending on a specific vendor SDK.
Auto-instrumentation is available for the JVM, meaning we don’t need to hand-instrument every binding/bundle to get useful traces and metrics — attaching a Java agent gets HTTP, database, and thread-level telemetry with no code changes to core.
openhabian already provisions a Grafana stack on Pi installs, so there’s a natural default sink for the data without new infrastructure for the common case.
Proposed architecture
Instrumentation is transport-agnostic and off by default — standard OTel env vars (OTEL_EXPORTER_OTLP_ENDPOINT, OTEL_EXPORTER_OTLP_PROTOCOL, OTEL_EXPORTER_OTLP_HEADERS, OTEL_SERVICE_NAME), only active when explicitly enabled.
OTLP/HTTP, not gRPC, as the transport out of the openHAB process.
A local, minimal OTel Collector as the fixed ingestion point between openHAB and whatever backend is configured (rationale below) — openHAB/openhabian only ever needs to know “send OTLP to localhost:4318.”
Default backend = the openhabian-provisioned Grafana stack (Prometheus for metrics, Loki for logs, Tempo for traces), fed by the collector.
Escape hatch = repoint the collector’s exporter at any vendor OTLP endpoint — no openHAB code change, no re-instrumentation.
Why a collector instead of exporting straight from openHAB
This came up while scoping the design and I think it’s worth settling here rather than in review:
Protocol bridging is the deciding factor. The Java agent emits OTLP. Tempo accepts OTLP natively, but Prometheus is pull/scrape-based and Loki has its own push API — neither is a clean OTLP sink out of the box. A collector receives OTLP once and fans out via the right exporter per backend (OTLP→Prometheus remote-write, OTLP→Loki push, OTLP→Tempo passthrough), so openHAB never needs backend-specific logic.
One stable ingestion contract regardless of backend. Swapping or adding a backend (Grafana stack today, a vendor tomorrow, or both at once) becomes a collector config change, not an openHAB/openhabian code change.
Batching, retry, and back-pressure isolation. Home internet + a remote backend isn’t always reliable; the collector batches and retries independently of the instrumented JVM.
Local filtering/enrichment without touching core. Dropping noisy spans, downsampling for bandwidth, or adding resource attributes becomes processor config, not a core code change.
Trade-off, stated up front: this is one more process on the Pi. To keep the resource cost honest, the proposal is a minimal custom collector build — only the OTLP receiver plus the specific exporters needed (Prometheus remote-write, Loki, OTLP passthrough) — not the full contrib distribution. Happy to benchmark actual RAM/CPU on a Pi 3/4 as part of a proof-of-concept if that’s a blocking concern.
If someone only ever targets a single OTLP-native backend, the collector is technically optional — but making it the fixed default keeps openhabian’s setup logic backend-agnostic and avoids reintroducing per-vendor coupling later.
How collector configuration would actually work
“Point at an HTTP endpoint” is a one-line env var; “configure a collector” doesn’t need to become a general config-management problem if scoped tightly:
Ship a small set of static, templated YAML configs — not a config generator. openhabian already templates service configs elsewhere; this is the same pattern: an otelcol-config.yaml.tmpl with an OTLP receiver fixed, and an exporter block swapped in from a small curated set (Prometheus-remote-write, Loki, OTLP-passthrough-for-vendor) based on the setup prompt answer.
Keep the choice space small at first: (a) local Grafana stack, fully pre-wired, zero extra input, and (b) “custom OTLP endpoint + optional auth header” for anyone pointing at a vendor directly. Expand later based on actual requests.
Validate the generated config (otelcol validate or equivalent) before restarting the service, so a bad substitution doesn’t silently break telemetry.
Own it as a normal openhabian-managed systemd service, with a menu entry to change backend later.
Repos affected and what each PR would contain
Repo
Change
Depends on
openhab-core
Add the capability: launch-time support for attaching the OTel Java agent / minimal resource-attribute wiring (service.name, deployment.environment). No-op unless explicitly enabled.
—
openhab-distro
Bundle the OTel Java agent jar into the shipped distribution.
core
openhabian
Provision the minimal collector as a systemd service; setup/config UI for backend choice; template the collector’s exporter config; write the openHAB systemd unit override (-javaagent: flag) pointing at the local collector.
core, distro
Each PR is designed to be independently mergeable and harmless alone — distro shipping an unused jar, or core supporting an unset flag, changes nothing for existing users. openhabian is the integration point that turns it on and owns the collector’s lifecycle. \
The one thing I’d like an early read on
Is a launch-time hook in openhab-core to attach OTel auto-instrumentation to the JVM — fully inert unless explicitly enabled, no new hard dependency — something maintainers would consider? That’s the piece everything else (distro bundling, openhabian activation) depends on, so I’d rather get a directional answer on that before writing the rest up as PRs.
Happy to also share a proof-of-concept branch demonstrating the launch-flag + a minimal collector config if that helps make it concrete.
While a) I don’t understand the whole point of doing this at all, b) your proposal certainly would not be a proper one because openHAB and openHABian are two independent things, the app and one possible OS. There’ people who use other OS setups than openHABian. There’s people that don’t use Grafana. If you want to fine, configure your setup to do so.
But if you wanted to build something into openHAB (frankly I have not understood what you want to build at all), it must not rely on a specific OS, database or other non-openHAB-core/addon component. OR do you want to build something into openHABian?
Then please provide a PR there, I’ll be happy to review it, too.
Finally c): what’s your point in this message? Do you want someone to build it for you to show up? That’s not how openHAB works. Build it yourself and contribute it. Maintainers will be happy to review a PR of yours.
I too am left with one big question that kind of takes my focus away from all the other details: Why? Who would benefit from this? How would it be beneficial to users? Who would receive the data - and what would be the point?
Telemetry is one of those things that are heavily abused to steal people’s data, so people are naturally skeptical of it. I always disable all telemetry without even studying what it claims to report, because:
I don’t trust the information I’m given about what is collected.
It’s a lot of work for me to try to check what is collected myself, and sometimes it’s not even possible.
Companies often change things over time, so even if you have verified what is collected at one point in time, they could collect something else tomorrow.
I can’t possible see how giving them my data could benefit me in any way, so why should I accept this burden?
I suspect that many others have similar ideas about it, and honestly, I trust a piece of software or hardware much less only by the fact that they “suggest” opt-in telemetry. Because, I know that what is a suggestion one day, becomes the default another, and in the end usually becomes mandated. So, why introduce something like this at all?
Thanks for the pushback — fair points, and I want to address both directly.
On scope: You’re right that baking anything OS- or backend-specific into openHAB core would be wrong, and I’m not proposing that. What I actually want is a self-contained optional add-on to openHAB itself — same model as the MCP server add-on — not a change to core behavior, and not something that assumes openHABian, Grafana, or any specific OS. If someone doesn’t install it, nothing changes for them. If they do, they point it at whatever OTLP endpoint they want (or nowhere).
On “why” and who gets the data — this is the important one. I think there’s a mix-up between two very different things that both get called “telemetry”:
Analytics/usage telemetry — phones home to the vendor by default, reports what you’re doing, is often opaque about what’s collected, and yes, is rightly distrusted.
Observability — the system reporting its own operational health (CPU/thread stalls, rule execution latency, binding errors, GC pauses) to an endpoint you choose, which by default is nowhere and, if configured, is typically your own machine or your own self-hosted stack.
What I’m proposing is entirely #2. There’s no default upstream endpoint, no openHAB or Anthropic-style vendor collecting anything, and no data leaves your network unless you explicitly point the exporter somewhere external — which is your call, same as it is with any tool you self-host. This is for the person running openHAB to answer “why did my system hang at 3am” or “which binding is leaking threads” without grepping logs blind — not for anyone else to learn anything about you or your home.
Given the very reasonable skepticism telemetry gets (deservedly), I think the add-on needs to be unambiguous about that distinction: off by default, no default network destination, and clearly documented as “this data goes where you tell it to and nowhere else.” Happy to make that a hard design constraint from the start rather than an afterthought.
I’ll rework this as a standalone add-on proposal rather than a core-hook + openHABian split, and bring a PR rather than another design doc. Appreciate you taking the time to poke holes in it.
There’s no mix-up, telemetry isn’t “inherently bad”, it’s just that it is so heavily abused that I feel that the word itself has been “tainted”. I would probably opt to call the add-on “monitoring” or similar instead of telemetry, just to avoid association with the word.
The Metrics add-on provides a Prometheus scrape endpoint for metrics, with optional push support for metrics to InfluxDB.
I actually have opened this PR a few day ago (had the code lying around for some time, but not used yet):
This adds a OpenTelemetry add-on that supports sending openHAB logs via OTLP (HTTP Transport).
My Prometheus metrics get scraped by an Grafana Alloy agent, that also receives the logs, and sends everything to my LGTM stack.
Main benefit is that I can easily access logs for an given range, filter by level, logger name, thread, etc. up to 7 days in the past without digging through log files (7 days could be anything, just my setting).
I’ll probably setup an automation to send me a WARN and ERROR logs summary every day.
If your OH system hangs, it’s almost 100 % a machine issue, not of Java or the Java app (= OH).
If you want to monitor machine stats that has nothing to do with openHAB neither should it be retrieved through openHAB. Install some agent on your OS and you’re set.
Seems you want to monitor generic Java (performance) metrics, not OH metrics.
The latter is an entirely different story, it’s logs and error messages and the like and barely of interest to many users to do so with some generic approach like this one as I’d guess you would need to have a couple of OH systems running before it is worth the effort.
Nonetheless @florian-h05 responded how to do that if that’s what you’re after.
But (java) system monitoring does not belong into openHAB.
You should be doing that generically and outside of openHAB then, I guess there’s Java APIs, solutions and enough agents available that can provide this, including OTLP.
If you nonetheless want to proceed, consider building an OTLP extension to the systeminfo binding, that already is retrieving and reporting quite some system performance data.
