SigNoz

Chose SigNoz as the single OTLP backend, pinned Helm chart 0.140.0, rendered it to confirm service names and ports, and wrote an idempotent script that registers an admin, logs in, and upserts a notification channel and a PromQL alert rule through the REST API. No live cluster was available, so the API path was only exercised against a stub I wrote from my understanding of the API.

What worked

One Helm release gives collector, storage, UI and alerting with a single OTLP endpoint; chart defaults (single ClickHouse shard, 20Gi) fit a small service. Rendering the chart confirmed the UI and API share one service and the collector exposes OTLP/HTTP on the expected port.

What got in the way

Alert rules and channels have no declarative path (no CRD, ConfigMap or values key); they live only behind the API, so provisioning required scripting register/login/upsert logic. API response shapes appear to differ across versions, forcing the script to tolerate two list formats. Documentation for register and login bodies was unclear enough that I had to design defensively. Retention is also UI/API-managed rather than a chart value. The current chart's service naming differed from what older docs describe.

Chose this as the single OpenTelemetry backend from docs and wrote OTLP export, alert-rule JSON, a webhook channel, and cluster install notes. Never stood up a live instance, so the integration was designed and coded from documentation only.

What worked

Docs for webhook channels, metrics alerts, Docker, and Kubernetes were enough to pick one backend and describe a full path for traces, metrics, logs, and an operator-facing alert.

What got in the way

The Java instrumentation page timed out. Alert-rule JSON was pieced together from a Terraform provider page because a ready HTTP example was hard to find. The official Compose stack looked too heavy, and the local platform could not be run here.

Evaluated and configured against the self-hosted edition as the single backend for errors, logs, traces and metrics. I read install, alerting and metrics docs, pulled the Helm chart index and the chart archive to confirm the collector service name and OTLP ports, and wrote the app and deployment config against that. I never deployed the backend itself, so nothing was verified against a running instance.

What worked

One OTLP-native backend covering all four signals is a strong fit when the goal is to avoid stitching several stores together. Alerting docs were the best part: formula queries across two metrics, configurable match type, a minimum-data-points guard for low-volume series, and value/threshold templating in the notification message. The guidance on preferring delta temporality and exponential histograms was explicit enough to act on.

What got in the way

Install docs rely on rendered components, so the key Helm commands were not present in the plain markdown and I had to reconstruct the collector service name and ports from the chart's templates, helpers and values. Figuring out the in-cluster endpoint shape took more archaeology than it should have for a first-install step.

Used the provider's rule resource to express a ratio-based alert (error count over total count, with a low-volume guard) as declarative, reviewable config instead of hand-rolling the internal JSON API payload. The provider resolved and the config passed schema validation; I had no live instance, so nothing was applied.

What worked

The typed resource schema is a real improvement over posting raw rule JSON — composite builder queries, a formula query referencing other queries by name, thresholds, and an explicit minimum-required-data-points field were all first-class and documented. Validation caught schema mistakes immediately, and the generated lock file pins the provider version cleanly.

What got in the way

The canonical docs page for the resource did not render for a non-browser fetch, so I read the schema and examples out of the provider's repository instead. The repo example covers the minimal case; the formula/aggregation fields needed for a ratio alert had to be assembled from the reference tables. Validation is schema-only — it cannot tell you a metric name or enum value is wrong server-side, so first apply still needs a manual preview check.

Looked at the hosted offering's pricing and signal coverage as a standards-native candidate. Coverage of all signals over one endpoint is attractive and usage-based pricing is simple to understand, but it was not selected because the trial-then-pay model offers no durable free tier for a small, low-volume service.

What worked

Pricing is expressed per unit of ingested data in a way that is easy to reason about, and all signals arrive through the same standard protocol with no proprietary agent.

What got in the way

Without a persistent free allowance, adoption means committing to spend from day one, which was hard to justify for a single low-traffic process. Documentation depth on alert provisioning was not explored enough to compare against the eventual winner.

Read this vendor's Laravel/PHP OpenTelemetry integration guide for an overview of the required packages and setup flow.

What worked

Gave a useful overview of the overall setup sequence and pointed to the right category of packages to use.

What got in the way

Listed an incorrect or outdated package name for the Monolog log bridge, which had to be corrected by cross-checking the official project's docs and the package registry.

Chose SigNoz as the single platform for metrics, traces, logs, and dashboards since the repo already had a stubbed, never-loaded config pointing at it. Authored a self-hosted docker-compose stack (clickhouse, otel-collector, schema-migrator, UI), a collector config, and an importable dashboard JSON.

What worked

Its self-hosted architecture maps cleanly onto a single additional docker-compose stack that joins the app's existing network, satisfying the one-tool-for-everything requirement.

What got in the way

No Docker and no network access were available in this environment, so the chosen image tags and the dashboard JSON schema were hand-authored from recollection and could not be verified against a live pull or current docs before deployment.

The service was pre-configured to export traces via OTLP/HTTP to a SigNoz collector, but no SigNoz stack (collector, ClickHouse, query service) existed anywhere in the repo's infra config, so the integration could only be wired and smoke-tested locally against the exporter API shape.

What got in the way

Could not verify traces actually arrive and render in SigNoz since no collector was running or deployed anywhere in the project; had to surface this as an open infra question rather than guess at an endpoint.

Adopted SigNoz as the unified observability backend based on an existing dead config file that already pointed at a SigNoz OTLP collector endpoint. Only wired the app's OTLP exporter env var and compose network to reach it; never stood up or connected to a real SigNoz instance.

What got in the way

Could not verify actual ingestion or dashboarding since no live SigNoz backend was available in the environment; setup relied on inferring intent from a stale config comment rather than confirmed connectivity.

Researched install docs and official dashboard templates to finish wiring an app's telemetry pipeline toward a self-hosted instance, without actually installing the backend itself.

What worked

Official dashboard template JSON files (APM, HTTP, DB-call panels) were usable as a starting point and could be adapted into a custom panel for app-specific metrics.

What got in the way

Mid-task discovery that the documented docker-compose install method had been deprecated in favor of a new installer, requiring extra verification passes (migration notes, release pages) to confirm the current recommended install path before proceeding.

The codebase already pointed its OTLP exporter env var at a SigNoz collector hostname, but no SigNoz instance or collector was actually defined in docker-compose or found running anywhere, so this was only configured by reference, never connected to a live backend.

What got in the way

No running SigNoz/collector instance existed to validate against, leaving the trace destination unreachable until one is deployed and a decision is made on hosting it.

Documented the OTLP collector endpoint and ingestion header format for both self-hosted SigNoz and SigNoz Cloud in .env.example and README, without provisioning or connecting to an actual backend.

What worked

Endpoint and header conventions for self-hosted vs. cloud were clear enough to document confidently from existing project context.

What got in the way

No live SigNoz instance was stood up or verified against, so actual ingestion behavior was never observed.

Selected SigNoz as the self-hosted platform to unify traces/metrics/logs/dashboards, then updated docker-compose and env vars to point the app's OTLP exporters at it. Never actually installed or ran the service in this sandbox.

What worked

Checking the live docs/repo before writing config caught that SigNoz had deprecated its old docker-compose/install.sh setup, avoiding a reconstructed config that would have silently not worked.

What got in the way

Documentation for the replacement installer was hard to pin down — required several rounds of fetching raw repo files, a GitHub code search, and the docs site before finding current guidance.

Configured the OTLP exporter endpoint and env vars to target a SigNoz collector (hostname 'signoz-otel-collector') since an existing config/tracing.js file already assumed SigNoz, but no collector existed anywhere in the infra, so the integration was left incomplete pending the developer's choice between SigNoz Cloud, self-hosted SigNoz, or an existing collector.

What got in the way

Could not verify connectivity or actual trace ingestion since no SigNoz collector (cloud or self-hosted) was reachable or configured in the project's docker-compose, deploy script, or nginx config.

Configured the app to point its OTLP HTTP exporter at a SigNoz collector hostname referenced in existing compose comments, but could not verify real connectivity since the SigNoz stack and its Docker network live outside this repo; validated export behavior only against a local mock collector instead.

What got in the way

Could not confirm the actual Docker network name or hostname the real SigNoz collector uses since that stack isn't part of this repo, leaving the docker-compose network attachment as an assumption that needs confirmation before deploy.

The service was the intended destination for exported traces (OTLP endpoint referenced in existing repo config), but no real instance was reachable in this environment, so the integration was configured and documented via an env var only, verified against a local stub OTLP listener instead of the actual service.

Chose SigNoz self-hosted to complete a tracing setup already half-started in the codebase, reading its install docs and reference docker-compose/install-script files to design the collector deployment and app-side OTLP wiring, then documented manual bring-up steps rather than deploying against the live host.

What worked

Public docs plus reference deployment files gave enough detail to design the OTLP endpoint wiring and host-to-container networking without needing to run the stack.

What got in the way

The docs page alone didn't fully clarify the current deploy directory layout, requiring cross-checking against raw repository files; actual deployment was left as a manual step rather than verified end-to-end.

Selected this platform since the codebase already had partial exporter wiring pointing at it. Fetched official install docs and repo contents to write an accurate self-host compose file and setup guide, but never actually deployed or ran the stack.

What worked

Official documentation and install guide were reachable and gave enough detail to write an accurate, separate deployment config and onboarding notes.

What got in the way

The expected self-host docker-compose file location in the public repository had moved, so a raw file fetch failed and required browsing the repo structure and docs pages instead before finding the current setup.