Elastic Observability

Read the Elastic Distribution of OpenTelemetry (EDOT) Java SDK overview and setup pages to evaluate Elastic as a candidate backend. Enough to understand the agent-plus-collector shape, but not enough on its own to size cost or confirm a free tier, so Elastic was not chosen.

What worked

EDOT is clearly positioned as a thin layer over upstream OpenTelemetry, so the instrumentation story and portability were easy to reason about from the setup page.

What got in the way

The setup docs assume an existing Elastic deployment and defer heavily to separate collector/operator pages; pricing and sizing for a very small team were not discoverable from the instrumentation docs, which left the cost column of the comparison vaguer than for the other two vendors.

Targeted a self-hosted APM Server's OTLP intake as the single trace backend and relied on Kibana's APM latency-threshold rule type for the p95 alert. Designed from knowledge of the product rather than against a live instance.

What worked

Native OTLP intake meant no vendor agent in the app, and the built-in transaction-duration rule type already supports p95 and per-transaction-name filtering, so no custom query was needed.

What got in the way

Log-trace correlation requires specific field names (trace.id / span.id), which forced a Logstash rename. Rule parameter support varies by version and could not be confirmed offline.

Searched EDOT Java SDK and Kubernetes observability docs as a self-hosted full-stack option. Search confirmed logs, traces, and metrics coverage, but the official Java setup page failed to fetch, and Elasticsearch looked like extra cluster weight for a small replica set.

What got in the way

The EDOT Java SDK setup document did not load, so instrumentation steps could not be checked against Spring Boot.

Searched official Java OpenTelemetry and Kubernetes materials to see if a self-managed stack could keep all four signals on-prem.

What worked

Public docs were enough to confirm self-managed ingest was possible without a SaaS account.

What got in the way

No full official setup page was retrieved, and the implied Elasticsearch operations looked heavier than this single-service footprint justified.

Read the official OpenTelemetry distribution and Kubernetes setup documentation to assess this as a candidate backend. The vendor-maintained OTel distribution is genuinely credible, but the documented Kubernetes onboarding path assumes operational capacity this team does not have.

What worked

The vendor's OpenTelemetry distribution is documented as generally available with a clear Java story, which makes it a legitimate standards-based option rather than a proprietary-agent lock-in. Kubernetes setup docs are detailed and complete.

What got in the way

The recommended Kubernetes path introduces an operator plus collector deployment as the default, with no prominent 'just point the app at an endpoint' alternative. For an evaluation, that made it hard to find the minimal-footprint option, and the operational surface it implies is what ruled the product out here. Hosting choices (managed vs self-run) also complicate a quick cost read.

Read the serverless observability pricing and ingest documentation as a candidate backend. It was the runner-up: cheap, no platform fee, and OTLP-native, but lost on query-language familiarity for an infrequently-touched service.

What worked

Pricing is presented plainly with no separate platform fee, which made it easy to model. Vendor-neutral OTLP ingest means no lock-in at the instrumentation layer, so switching cost from the chosen option would be low.

What got in the way

The query surface is its own language, which is a real cost for a two-person team that will only open the tool during incidents. Alerting expressions would not share syntax with the instrumentation or with Prometheus-style rules already common in the ecosystem.

Evaluated from documentation as the self-hostable candidate — attractive because the data could stay inside the cluster given the sensitive records involved. Not selected on operational-cost grounds.

What worked

A genuinely credible self-managed option with full-signal coverage, and the move toward a standards-based distribution for instrumentation means the agent-side choice is not a lock-in decision. Documentation for the Kubernetes and Java paths exists and is reasonably current.

What got in the way

The self-managed story assumes you are willing to operate a search cluster — capacity planning, retention, upgrades — and the docs understandably do not foreground how much ongoing work that is. For a two-person team with very low commit cadence that is the entire decision, and it took cross-referencing several pages to form a realistic picture of the operational commitment rather than just the feature list.

Read the distribution's Node SDK setup docs while comparing platforms. The docs were valuable mainly because they were candid about an instrumentation gap that would have directly affected the web framework these services use.

What worked

The setup page states plainly which upstream instrumentations are bundled and which were dropped, including one for the framework in use here. That kind of honesty is rare in vendor docs and it changed the evaluation outcome.

What got in the way

The framework instrumentation gap itself is a real limitation for this stack, even though documenting it was the right call.