OpenTelemetry in self-hosted Grafana: Alloy, Tempo, Loki

How OpenTelemetry data reaches a self-hosted Grafana stack

Instrumented services need one reliable path into self-hosted Grafana for traces, logs and metrics, and the supported route is OTLP into Grafana Alloy. OpenTelemetry itself is a framework and toolkit for generating, exporting and collecting telemetry, and it is not an observability backend. Something has to store each signal and something has to display it. Alloy is a distribution of the OpenTelemetry Collector with built-in Prometheus pipelines, so it can receive OTLP from your applications, process the data and route each signal to its own store: traces to Tempo, logs to Loki and metrics to a Prometheus-compatible store. Grafana then reads from all three and links them, for example moving from a slow span to the logs written during that request.

The design decisions sit in the Alloy configuration and the topology around it. Decide whether Alloy runs as an agent beside each workload, as a gateway that receives from many sources, or as both, and confirm that the signals you need (metrics, logs and traces) have a supported path in your chosen Alloy release. Decide how application identifiers, such as service name and environment, are set as resource attributes, because Grafana's correlation depends on consistent labels across the three stores. Confirm the stability of the OpenTelemetry SDK for each language your teams use, since trace APIs are stable in most languages while log SDK maturity varies. Also check that each Alloy component you rely on is documented as stable for your use case, because stability differs across core Collector components.

DeployOpen plans the topology, implements the Alloy pipelines and the Tempo, Loki and Prometheus-compatible backends, and hardens the path. Hardening covers authentication on receivers and exporters, network boundaries between application hosts and the collectors, and the access controls on each store. Confirm with your security team whether OTLP traffic must be encrypted between hosts and which identity model your receivers will use before the build starts. DeployOpen prepares these designs and controls for your environment, and your own teams keep ownership of the applications they instrument.

What you need in place before sending telemetry

Telemetry only lands where the stores behind it are ready, so confirm the Grafana, Alloy, Tempo, Loki and Prometheus-compatible pieces before any application points at a collector. Each card below is one decision or check that shapes the rest of the build. Confirm current versions against each vendor's release page before you fix a plan.

Production database for Grafana

Grafana keeps its configuration in SQLite 3 by default, but the installation docs say SQLite does not scale for production. Plan for MySQL 8.0 or later or PostgreSQL 12 or later from the start, because high availability also depends on a shared database. Confirm the database version you will run against the minimum listed in the install docs, and decide who owns backups for it before dashboards are built.

Alloy as the OTLP entry point

Grafana Alloy is an OpenTelemetry Collector distribution with built-in Prometheus pipelines, so one agent can receive OTLP from applications and route all three signals. Decide whether Alloy runs as an agent next to workloads, as a central gateway, or both. Confirm which Alloy release your platform supports, and which OpenTelemetry components it bundles, before you write routing rules.

Tempo for traces

Tempo receives the trace stream from Alloy and is queried from Grafana with TraceQL. Confirm the Tempo version and the storage backend you intend to use, and whether trace-to-log and trace-to-metric links will be configured later. Decide retention and sizing early, since trace volume grows quickly with sampling choices. Check that the Grafana instance can reach Tempo's query endpoint from its network segment.

Loki with object storage and auth decisions

Loki stores compressed chunks and its index in object storage, and its recommended production stores are Amazon S3, Google Cloud Storage and Azure Blob Storage. Choose the deployment mode that matches your expected daily volume, and confirm that simple scalable mode is being deprecated before you commit to it. Set auth_enabled deliberately, because it turns on multi-tenancy with the X-Scope-OrgID header. Loki has no built-in authentication, so an authenticating reverse proxy must sit in front of it.

Prometheus-compatible metrics store

Metrics need a Prometheus-compatible store that Grafana can query, and a single Prometheus server keeps its local storage on one node without clustering or replication. Decide whether local retention is enough or whether remote write to long-term storage is required. Confirm the Prometheus release line you will run, since long-term support lines receive bug fixes for one year and standard minor releases stop receiving fixes after about six weeks. Plan Alertmanager placement too, since Prometheus should point at every Alertmanager instance.

Network paths and OTLP certificates

Applications, Alloy, Tempo, Loki, Prometheus and Grafana each need a network path that matches your segmentation rules. Map which hosts send OTLP to which Alloy endpoint, and which ports are open between Alloy and each backend. Issue and rotate TLS certificates for OTLP listeners and backend endpoints, and confirm how clients will trust your internal CA. Recheck these paths after any change to load balancers or cluster networking.

Configuration sequence from OTLP receiver to Grafana correlation

The sequence builds each backend first, then wires Alloy to receive OTLP and route each signal, proves every signal lands in its store with one test service, and only then links the stores together in Grafana. Each step ends with a check so a failure is found before the next layer depends on it.

Deploy the storage backends first
The platform team installs Tempo for traces, Loki for logs and a Prometheus-compatible store for metrics before anything sends data to them. Loki keeps its chunks and index in object storage, so confirm the bucket, credentials and retention settings with your storage team, and note that Loki retention stays disabled until retention_enabled is set. Each backend is done when its readiness endpoint responds and a test write or query succeeds from the host where Alloy will run.
Deploy Grafana Alloy as the OTLP entry point
Install Alloy on the hosts or cluster nodes that applications can reach, since Alloy is an OpenTelemetry Collector distribution and will accept OTLP from your services. Use a single configuration file so the receiver, processors and exporters for each signal are visible in one place. The step is complete when Alloy starts cleanly, its health endpoint responds and the OTLP receiver port is open to the test service's network segment only.
Configure OTLP receivers and per-signal pipelines
Define an otelcol.receiver.otlp block, then one pipeline for each signal: traces go through a batch processor to an OTLP exporter for Tempo, logs go to Loki through its OTLP endpoint, and metrics go to a Prometheus-compatible remote write endpoint. Keep batching in every pipeline so exporters send in fewer, larger requests. Check the Alloy UI or logs for component errors, then confirm each exporter reports successful sends before instrumenting an application.
Add authentication and tenant headers
Decide how clients and Alloy authenticate before a second service connects. Loki has no built-in authentication, so an authenticating reverse proxy must sit in front of it, and when auth_enabled is true every request must carry the X-Scope-OrgID header that identifies the tenant. Alloy can add those headers and credentials on outgoing exporter requests. The step closes when a request without credentials is rejected and a request with the correct tenant header is accepted by each backend.
Instrument one test service
A developer on the owning team adds the OpenTelemetry SDK for the service's language, sets the service name and points the OTLP exporter at Alloy. Keep the test service small and generate known requests, such as a single endpoint called ten times with one deliberate error, so the expected output is easy to recognize. The service emits traces, metrics and logs with a shared service name. The step is done when the service runs without export errors in its own logs and Alloy shows received spans, metrics and log records.
Verify each signal in its own store
Query each backend directly rather than through Grafana. Search Tempo for a trace from a known test request, run a LogQL query in Loki that returns a log line with the test service label, and query the metrics store for a series from the service. A trace visible in Tempo, a log line queryable in Loki and a metric series present in the metrics store together prove the path end to end. If one signal is missing, return to the pipeline for that signal before moving on.
Add data sources and correlation links in Grafana
Add Tempo, Loki and the Prometheus-compatible store as data sources in Grafana, then configure the trace to logs and trace to metrics links so a span opens the matching log lines and metric series. Link the service graph to the Prometheus-compatible source, since the service graph depends on it. The step is complete when opening a span from the test trace shows the related log lines from Loki, and the same trace can open the related metric view for that service.
Confirm correlation survives a restart and a second service
Restart Alloy and the test service, then repeat the trace, log and metric lookups to confirm the data and links still resolve. Add a second service with a different name and confirm its signals are separated correctly in each store and in Grafana filters. Record the exporter endpoints, tenant values and label names in your runbook so the team that adds the next service follows the same pattern. The sequence is complete when both services show correlated data after the restart.

How OTLP resource attributes map to Loki labels and Prometheus series

This table shows where common OpenTelemetry resource attributes end up in Loki, Prometheus and Tempo, and what each destination does with them. Read each row as a decision: keep the attribute as an indexed label only when its value set is small and stable, and keep it as searchable content or span attributes otherwise. The main takeaway is that label design, not the collector, decides how much storage and query cost the stack carries.

Attribute	Loki stream label	Prometheus series label	Tempo and log record handling
service.name	Usually promoted, few values per environment	Usually kept as job or service label	Stored as resource attribute on every span; used for service graph grouping
service.namespace	Promote if teams query by business unit	Keep only if it is stable across releases	Stored as resource attribute; useful for filtering trace searches
deployment.environment	Promote; values such as prod and staging are small and stable	Promote; keeps environments separate in every query	Stored on spans; enables environment filters in TraceQL
Tenant identifier (X-Scope-OrgID)	Not a label; Loki selects the tenant by request header	Use a separate Mimir or Prometheus tenant or external label, not a series label	Map to tenant in the trace backend when multi-tenancy is enabled
k8s.pod.name or instance IDs	Avoid; values change on every restart and inflate stream count	Avoid as a label; use only where per-instance series are required	Keep as span or log attribute, searched on demand rather than indexed
trace_id and span_id in log records	Do not promote; high variance creates one stream per request	Not applicable to metrics	Carry in the log body or structured metadata so Grafana can link logs to traces
user or request identifiers	Never promote; unbounded values make queries and retention unmanageable	Never promote; each value creates a new series	Keep as span attributes for investigation
Metric exemplars	Not applicable to logs	Attach trace IDs to selected histogram samples where the backend supports exemplars	Link metric panels to traces; confirm exemplar support in your Prometheus-compatible store

Choosing tenancy and authentication for each backend

Loki decides tenancy at the request level. With auth_enabled left unset or false, Loki runs as a single tenant and accepts writes and reads without an X-Scope-OrgID header, which suits one team or a lab. Setting auth_enabled: true turns on multi-tenancy, and then every write and query must carry the X-Scope-OrgID header, which names the tenant whose data is read or written. Tenant boundaries exist only as long as every client sends the right header, so the header is a routing key, not an access control.

Single tenant: one shared data space, simplest to run, but every reader sees every stream.
Multi-tenant: separate tenants per team or environment, with per-tenant limits and retention where configured.
Header trust: any client that can reach Loki can set any tenant header unless something in front of Loki checks it.
Grafana data sources: each Loki data source in Grafana is configured with the tenant it should query.
Retention per tenant: retention rules can differ by tenant, so tenant design also shapes data lifetime.

Confirm with your own team which tenants exist, who may read each one, and whether any Alloy pipeline writes into the wrong tenant by default.

Loki has no built-in authentication layer. Its documentation says an authenticating reverse proxy must sit in front of it, such as nginx, HAProxy, OAuth2 Proxy or Pomerium. The proxy is where users, services and certificates are checked, and where the tenant header is either passed through for trusted clients or set by the proxy itself. Without this layer, anyone who can reach the Loki port can push or read logs.

Named options: nginx, HAProxy, OAuth2 Proxy and Pomerium are the examples the Loki docs give.
Header control: have the proxy set X-Scope-OrgID from the authenticated identity so clients cannot choose their own tenant.
Separate paths: treat the write path used by collectors differently from the read path used by people in Grafana.
Network placement: keep Loki's own ports off any network that bypasses the proxy.
TLS: terminate TLS at the proxy with certificates your PKI issues.

Test the proxy by sending a write and a read with a forged tenant header and confirming the request is rejected or rewritten.

Alloy is Grafana's supported log shipper for Loki and an OpenTelemetry Collector distribution, so it needs credentials on both sides of its pipelines. The OpenTelemetry Collector supports authenticator extensions. Extensions on receivers can authenticate incoming connections, for example with OIDC, so only trusted applications can send OTLP data. Extensions on exporters can add credentials to outgoing requests, for example with the oauth2client extension, so the Collector can write to a protected Loki or metrics endpoint.

Receiver side: an OIDC authenticator can require tokens from applications before accepting telemetry.
Exporter side: oauth2client attaches a token to requests sent to the backend proxy.
Secret handling: keep client secrets in a secrets store or environment variables, not in plain configuration files in version control.
Tenant mapping: decide whether the Collector sets the tenant header or whether the proxy derives it from the token.
Component stability: core Collector components have mixed stability levels, so check each authenticator's README before relying on it.

Confirm which authenticator extensions your Collector distribution includes, and test token expiry and renewal on the exporter path.

Hardening the OTLP path and the backends behind it

Telemetry pipelines are only as safe as their weakest entry point. The controls below cover how data gets in over OTLP, how exporters authenticate to the stores behind them, and how the Grafana front end is configured so that dashboards and query endpoints stay protected.

Authenticate Collector receivers

Every OTLP receiver accepts data from whatever can reach it unless you add an authenticator extension. Collector authenticator extensions can check incoming connections on receivers, for example with OIDC, so that only known workloads or gateways can send traces, logs and metrics. Decide which senders need identity checks, such as instrumented services in another network zone, and test that a request without credentials is rejected before you rely on the control.

Encrypt OTLP with TLS

OTLP traffic carries application attributes, identifiers and sometimes request content, so plaintext transport between services, agents, gateways and backends exposes that data on the wire. Enable TLS on each receiver and exporter that crosses a host or network boundary, and decide how certificates are issued, renewed and rotated for the Collector fleet. Confirm the exact TLS keys for your Collector distribution and Alloy version in the component documentation before writing configuration.

Restrict network reach to receivers

Bind OTLP receivers to the interfaces they need rather than to all addresses, and limit inbound access with firewall rules or network policies to the subnets, clusters or gateways that send telemetry. Gateway-style Collectors that accept data from many sources are the most exposed component, so they need the tightest allow list. Review the list whenever a new team or environment starts sending data.

Scope exporter credentials

Collectors hold write credentials for Loki, Tempo and the Prometheus-compatible store, so a leaked configuration file can corrupt or read every signal. Create one service identity per backend and per tenant, grant write rights only, and keep credentials in a secrets store rather than in plain configuration files. For Loki multi-tenant setups, confirm which X-Scope-OrgID values each exporter may set, because the header alone does not authenticate a caller.

Harden Grafana cookies and CSP

The Grafana front end is where engineers query all four signals, so its browser-facing settings matter. The security hardening guidance recommends secure and SameSite cookies, a Content Security Policy, Trusted Types and domain verification against DNS rebinding. Apply these in the Grafana configuration, then confirm that plugins used for trace or log views still load under the policy.

Require authentication on metrics endpoints

Grafana exposes a metrics endpoint for its own monitoring, and the hardening guidance recommends requiring authentication on it and hiding the version from unauthenticated users. Prometheus and Alertmanager endpoints also expose operational detail, so scrape them only from the network paths that need them and check that anonymous access is off. Test each endpoint from outside the trusted network after every change.

How to test the pipeline and keep it running

Verify each signal separately before you trust the pipeline. Send one test trace with a known trace ID from a sample service through the Collector or Alloy into Tempo, then search for that exact ID in Grafana. Repeat the exercise for logs by emitting a log line that carries the same trace ID, then confirm that the Tempo-to-Loki link lands on that line. For metrics, run a PromQL query against the Prometheus-compatible store for a counter your test service increments, and check that the value moves as expected. Record the test IDs, timestamps and queries in your runbook so the next person can repeat the checks after every change. Confirm the exact Tempo and Loki data source settings in your own Grafana version, because link configuration is where correlation most often breaks.

Track versions on a fixed schedule. Subscribe to the release notes for Grafana Alloy and the OpenTelemetry Collector distribution you run, then read them before each upgrade, because contrib components can change stability level between releases and the status of each component is documented in its README. Pin the exact versions in your deployment definitions and test upgrades in a non-production environment first. Do the same for Loki, Tempo and Prometheus, and check the Prometheus release cycle page, since a minor release generally stops receiving bug fixes after six weeks and LTS lines have a fixed support window.

Plan the storage and alerting gaps that the defaults leave open. Loki retention is disabled by default, so logs accumulate indefinitely until retention_enabled is set on the compactor, and you should set a retention period that matches your policy and confirm it removes data as expected. Prometheus local storage is a single node that is not clustered or replicated, with 15-day default retention, so decide whether you need remote write to long-term storage and back up the data directory. For alerting, run Alertmanager as a cluster using its --cluster flags and point Prometheus at every instance rather than a load balancer. Test a firing alert end to end, including a notification that reaches the receiver, after each change to the cluster.

Common failures when OpenTelemetry data does not appear in Grafana

This table maps each common symptom of missing OpenTelemetry data to its usual cause and the first fix to check. Read it by symptom: find the row that matches what you see in Grafana, then work through the checks in the fix column before changing anything else. Most gaps trace back to endpoints, tenant headers, label design, sampling, or storage and retention settings that were never sized for production.

Symptom	Usual cause	First fix to check
No data arrives from applications	OTLP endpoint unreachable, or TLS certificate name does not match the collector host	Confirm the port and hostname the SDK exports to, then verify the certificate chain and SAN against that exact name from the application host
Loki returns errors on every write	Multi-tenant mode is on (auth_enabled true) and requests lack the X-Scope-OrgID header	Add the tenant header in the exporter or Alloy write block, and confirm the same tenant name is used in the Grafana Loki data source
Logs queries are slow or Loki ingestion is throttled	Label cardinality explosion, such as user IDs, request IDs or pod hashes used as stream labels	Move high-variance values into log content or structured metadata, keep stream labels to a small fixed set, and review active series per label
Traces are missing for some requests	Sampling drops spans, or batch processor settings delay or drop exports before they reach the backend	Check the sampler ratio in the SDK and any tail-sampling policy in the Collector, then review batch size and timeout and watch exporter failure counters
Log lines appear in Grafana but cannot link to traces	Logs are emitted without trace_id and span_id fields, so the trace-to-logs correlation has no key	Inject the active trace context into the logging library, map the fields in the log pipeline, and confirm the derived field matches the field name
Prometheus stops accepting data or queries fail	Local TSDB storage is filling, because retention (15 days by default) and disk size were not sized for the sample volume	Compare disk use with the configured time or size retention limit, reduce series or scrape frequency, or send long-term data through remote write to external storage
Old logs never disappear from Loki	Retention is disabled by default, so the compactor keeps chunks indefinitely until retention_enabled is set	Set retention_enabled with a retention period, confirm the compactor runs, and set per-tenant or per-stream rules where they differ (each stream rule at least 24 hours)

Questions teams ask before connecting OpenTelemetry to Grafana

What drives the cost of running OpenTelemetry with self-hosted Grafana?

The software is free to use, so the cost is the infrastructure, storage, implementation and the people who run it. Prometheus has no paid enterprise edition, and Grafana, Loki and Tempo are licensed under AGPLv3, so no license fee applies to the self-hosted core. Costs recur in compute for the Collector, Grafana, Loki, Tempo and Prometheus, object storage for logs and traces, and the staff time to patch, upgrade and watch the pipeline. Retention and data volume are the largest levers: longer retention and more telemetry increase storage and query load. One-time costs cover design, instrumentation and the initial build. Ask any quote to separate implementation from recurring operations and to state which retention periods and daily log volumes it assumes.

How long does an OpenTelemetry to Grafana rollout take?

The timeline depends on how many services need instrumentation, how many signals you collect, and how quickly approvals arrive. Metrics through a Prometheus-compatible store usually come first because they need the fewest moving parts, while logs and traces add object storage, retention and correlation work. Other drivers include the number of languages in use, whether your teams already run a Collector, the state of existing dashboards and alerts, and whether the storage backend is ready. Lead times for network rules and identity setup often set the pace more than the software does. No duration is fixed here; ask for a timeline built from a written scope that lists services, signals and environments.

What does our team need to provide before implementation starts?

Three groups of input shorten the work and prevent rework. First, named service owners who can confirm what each application does, which telemetry matters to them, and who approves changes. Second, access to the source code, build pipelines or deployment configuration where instrumentation will be added, along with a decision on who merges those changes. Third, network approvals for the paths the telemetry takes: application to Collector, Collector to Loki, Tempo and Prometheus, and users to Grafana, plus any firewall or proxy rules for the storage backend. Your team should also name a platform owner for the stack, decide on identity for Grafana access, and confirm where data may be stored.

Can our own team connect OpenTelemetry to Grafana without a partner?

Yes, a capable platform team can do this in-house, and the open-source components are documented well enough to start. The work involves several moving parts: instrumenting applications, running an OpenTelemetry Collector or Grafana Alloy as the router, storing logs in Loki on object storage, storing traces in Tempo, storing metrics in a Prometheus-compatible store, and linking the signals in Grafana. The hard parts are usually label and attribute design, retention rules, multi-tenant setup, high availability and keeping component versions aligned. A partner is worth considering when the team lacks time, when several signals must go live together, or when audit evidence is needed. Assess your team's experience with each component before deciding.

How does Grafana Cloud change the cost picture compared with self-hosting?

Grafana Cloud replaces much of the infrastructure and operations work with a subscription, so the cost shifts from running servers to paying a platform fee plus usage. According to the Grafana pricing page, Grafana Cloud has a free tier, a Pro tier starting with a 19 US dollar monthly platform fee plus usage, and an Enterprise tier with a minimum commitment of 25,000 US dollars per year. Self-hosting avoids those fees but keeps the infrastructure, storage and staffing costs with you, and it lets you keep data inside your own environment. Compare the two using your expected data volume, retention, residency rules and internal operations capacity, and ask for a usage-based estimate from the vendor.

What breaks most often when OpenTelemetry data flows into Loki, Tempo and Prometheus?

The most common failures come from configuration and cardinality rather than from the components themselves. Common issues include high-cardinality labels that overload Prometheus or Loki, missing resource attributes that break correlation between signals, inconsistent service names across traces, logs and metrics, and Collector pipelines that drop data under load without alerts. Storage misconfiguration is another frequent cause, especially retention that was never enabled in Loki, since it is off by default. Engineers should check that trace IDs appear in logs, that service naming follows one convention, and that the Collector exposes its own health metrics. Test each signal path end to end before adding more services.

Does the open-source stack meet our security and access requirements?

The stack gives you control over where data lives, but several controls must be designed rather than assumed. Loki has no built-in authentication layer, so you need an authenticating reverse proxy in front of it, and Loki multi-tenancy depends on the X-Scope-OrgID header being set correctly. The OpenTelemetry Collector supports authenticator extensions, such as OIDC on receivers and OAuth2 client credentials on exporters, so telemetry paths can be authenticated. For Grafana, the open-source edition supports several identity providers, while SAML and team sync require Grafana Enterprise or Grafana Cloud. Confirm which controls your policy requires before choosing an edition.

Which components must be upgraded on a schedule, and who owns that work?

Each component follows its own release cycle, so the upgrade plan must cover all of them. Grafana publishes minor releases every other month and patch releases at least monthly, with each minor supported for 9 months. Prometheus starts a new minor cycle every 6 weeks, and its LTS line receives fixes for one year. The OpenTelemetry Collector and Loki also release frequently. Assign one owner for the stack, keep a versions register, test upgrades in a non-production environment, and decide whether a retainer covers ongoing patching. Ask any partner to state which versions they will support and how they will handle breaking changes.

How DeployOpen scopes an OpenTelemetry rollout in your infrastructure

DeployOpen runs most engagements as fixed-scope work agreed in writing before any build starts. For an OpenTelemetry rollout, the written scope has to name three things: which services and hosts emit telemetry, which signals are in (traces, metrics, logs or all three), and which backends receive each signal. In practice that means listing the applications instrumented with OpenTelemetry SDKs, the Collector or Alloy tiers that receive OTLP, and the destinations, such as Tempo for traces, Loki for logs and a Prometheus-compatible store for metrics. Each backend carries its own storage, retention and access work, so leaving one out of the scope changes the effort and the acceptance tests. The quote follows from that document, so a vague scope produces a vague quote.

Ask for the scope to record the decisions that move cost most. These include the collector topology (agent, gateway or both), whether Grafana Alloy or a plain OpenTelemetry Collector distribution handles each tier, how many environments are covered, and whether authentication on OTLP receivers and exporters is required. The scope should also state who owns the Grafana data source configuration, dashboards and correlation links between signals, and which items are out, such as instrumenting third-party software you do not control. Confirm the current Collector release and component stability with your own team before the scope is signed, because component maturity varies and the supported versions change over time.

Retainers are a separate agreement from the rollout. Once the pipelines run, a retainer can cover ongoing support, Collector and Grafana upgrades, backend maintenance and periodic checks of the pipelines against the agreed scope. Keep the rollout fee and any retainer on separate lines in the quote so you can see which costs are one-time and which recur. DeployOpen does not hold certifications or partner status for the components in this stack, and it does not issue audit reports; if an assessor needs evidence from this telemetry, the scope should list which evidence DeployOpen will produce and which parts your assessor will test.

How DeployOpen works on this

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For OpenTelemetry metrics, logs and traces in self-hosted Grafana, we start from your applications, data volumes and retention needs, then build the collection path and correlation in your environment.

How we scope

Inventory the services, languages and telemetry signals that will send OTLP data into the stack.
Agree in writing which Collector pipelines, Alloy components and backends are in scope.
Record retention, tenancy, sampling and storage decisions before any build work starts.

How we build

Deploy the Collector or Alloy tier, Tempo, Loki, a Prometheus-compatible store and Grafana in your environment.
Configure receivers, processors and exporters, plus authentication on receivers and exporters where your policy requires it.
Wire trace-to-log and trace-to-metric links in Grafana and test each signal end to end.

How we hand over

Provide configuration as code with a documented version of each component and an upgrade record.
Document the data flow, label and attribute conventions, retention settings and access model for your team.
Walk your engineers through verification steps, dashboards and the runbooks they need to operate the stack.

How we support

Offer ongoing support, upgrades and continuous testing as a retainer, scoped in writing.
Plan upgrades against the release cadences of Grafana, Loki, Tempo, Prometheus and the OpenTelemetry Collector.
Review telemetry volume, cardinality and storage growth with your team on an agreed schedule.

OpenTelemetry metrics, logs and traces in self-hosted Grafana