How to start Open WebUI monitoring with OpenTelemetry
Start by exporting Open WebUI telemetry over OTLP into an OpenTelemetry Collector, which then forwards traces, metrics and logs to Grafana-compatible backends. In a shared deployment, users, model servers and background work all pass through the same instances, so response times and the database and Redis calls behind them are hard to see without this path. OpenTelemetry is a framework for generating, exporting and collecting telemetry. It is not a storage or query backend, so you must choose and run the stores yourself: Tempo for traces, Loki for logs, and Prometheus or an equivalent for metrics. Each is a separate system with its own sizing, retention, access control and upgrade cycle.
Make the backend decisions before enabling anything. Decide where each signal is stored, how long each is kept, who may query it, and whether the stores sit in the same network zone as Open WebUI. Grafana's installation documentation states that SQLite does not scale for production, so plan MySQL or PostgreSQL for Grafana's own configuration database if more than one person will rely on it. Review licensing as well. Grafana, Loki and Tempo moved from Apache License 2.0 to AGPLv3 in April 2021, so ask your legal team whether that fits your use. The OpenTelemetry Collector repository is Apache-2.0, and its releases ship signed artifacts, SHA256 checksums and SBOM files, which supports a supply chain review.
The exact Open WebUI telemetry settings are not covered by the material this page relies on. That includes which configuration variables enable OTLP export, which signals the application emits, and what those signals are named. Confirm each of these in the Open WebUI documentation for the version you run, and test against a non-production instance before rollout, because names and defaults can change between releases. Also confirm whether the emitted traces include spans for database and Redis operations. That determines whether your latency questions can be answered from traces alone or whether you need separate metrics for those dependencies.
A practical first step is a non-production instance, one Collector running in gateway mode, and traces plus metrics only. Add logs once the first dashboards answer the latency questions. Agree with your privacy and compliance owners what telemetry may leave the application, since prompts, user identifiers and file names can appear in attributes. Configure the Collector to drop or redact those attributes before storage. Collector authenticator extensions can authenticate incoming OTLP connections and add credentials to exporter requests, so decide early who may send data and who may read it. Keep the Collector configuration under version control so each change can be reviewed and reversed.
What you need before you connect Open WebUI to Grafana
Before you connect Open WebUI to Grafana, settle six inputs: the Open WebUI release and install method, the OpenTelemetry Collector release, the Grafana release line, the trace, log and metric backends, the network paths between them, and the shared services that multiple replicas need. Confirm version compatibility in each vendor's documentation before you pin any version.
Open WebUI release and install method
Pin a running Open WebUI release before you add instrumentation. This page uses v0.12.3, which the project published on its GitHub releases page on October 16, 2026, but read the release notes for your target version and any telemetry settings it documents. Choose one install method now: Docker, Docker Compose, Helm on Kubernetes, or pip with open-webui serve. The method decides where environment variables are set and how you restart after changes. Also check the Open WebUI License, because deployments above 50 users in a rolling 30-day period must keep branding unless they hold an enterprise license or written permission.
OpenTelemetry Collector release
Run a Collector release that you can pin and upgrade on your own schedule. The reference release is v0.163.0, published on October 16, 2026. Choose the contrib distribution if your pipeline needs receivers or exporters outside the core set, and check the README of each component you use, since core components have mixed stability levels. Collector releases ship signed artifacts, SHA256 checksums and SBOM files, so verify them against your artifact policy before deployment. Confirm which Collector release your chosen exporter and extension versions were tested against.
Grafana release line
Pick a Grafana release line and plan its upgrade window. This page assumes Grafana 13.2.0, released August 18, 2026, or the 13.1.x and 13.0.x patch lines, with patch releases 13.2.4, 13.1.8 and 13.0.11 published on October 13, 2026. Grafana states that each minor release is supported for 9 months, so the line you choose today will need a planned move later. Confirm that the Tempo, Loki and Prometheus data source configurations work with that line. Production Grafana also needs MySQL or PostgreSQL for its configuration database, because SQLite does not scale for production.
Trace, log and metric backends
Decide where each signal is stored before you configure exports. Traces go to Tempo, logs go to Loki and metrics go to Prometheus or another backend that accepts the metrics you export. Each backend needs its own endpoint, retention setting, storage sizing and access control. Check that the Collector exporter for each backend supports the signal type and the authentication method your organization requires. Plan who can read each store, because Grafana data source permissions and backend tenancy are separate controls.
Network paths to the Collector
Map every network path from Open WebUI to the Collector before deployment. Open WebUI must reach the Collector's OTLP receiver endpoint, and the Collector must reach Tempo, Loki and Prometheus or their gateways. Confirm the protocol, port and TLS setting for each hop, and whether traffic crosses a firewall, proxy or service mesh. Authenticator extensions can check credentials on incoming receiver connections, for example with OIDC, so decide early whether the receiver requires them. Test each path from the Open WebUI host or container, not only from an administrator workstation.
Shared state for multiple replicas
Add shared services before you run more than one Open WebUI replica. The scaling guide requires PostgreSQL instead of SQLite for multi-instance deployments, Redis for sessions, websocket connections and application state, and shared file storage so uploads and knowledge stay reachable from every replica. Without Redis, signing out does not revoke tokens, which stay valid until they expire, by default after 4 weeks. Add a replica identifier to exported telemetry so traces and logs can be filtered by instance. Confirm the vector database choice as well, since the guide warns that the default ChromaDB crashes in multi-process setups.
How OTLP telemetry moves from Open WebUI to Tempo, Loki and Prometheus
The signal path starts with Open WebUI, which emits telemetry and sends it over OTLP to an OpenTelemetry Collector. The Collector receives the data, applies processing such as batching, attribute filtering and removal of fields you do not want stored, then exports each signal type to its own backend: traces to Tempo, logs to Loki and metrics to Prometheus. Grafana reads from those three stores as data sources, so dashboards and cross-signal navigation are built in Grafana itself. Before you commit to this path, confirm which signals your chosen Open WebUI release emits and which endpoint, protocol and export settings it supports, because the Collector can only receive what the application sends.
Placement decides where the Collector runs. In agent placement, a Collector runs beside each Open WebUI instance, usually on the same host or as a sidecar, so each instance has a local receiver and a small failure domain. In gateway placement, one or more central Collectors accept OTLP from many sources and handle the exports to the backends. Shared deployments often choose a gateway. When Open WebUI runs as several replicas, or when other services already send telemetry to the same backends, a gateway gives you one place to set sampling, redaction, retry behavior and backend credentials, and each replica only needs the address of a stable endpoint. Agent placement fits a single instance on one host, where an extra hop adds little.
The gateway is not free. It adds one more component to run, patch, scale and monitor, and it becomes a dependency for every signal. If it is down or misconfigured, telemetry can be lost while Open WebUI keeps serving users, so alert on Collector health and dropped data, not only on application errors. Security is part of the same design. Receivers that accept data from other hosts should require authentication and encryption. Collector authenticator extensions can validate incoming connections, for example with OIDC, and attach credentials to outgoing exporter requests, for example through the oauth2client extension. Before you deploy, pin a specific Collector build and verify the signed artifacts, SHA256 checksums and SBOM that each release publishes.
The Collector is vendor-agnostic, so the pipeline is not tied to Tempo, Loki or Prometheus. Changing a backend means editing the exporter section of the Collector configuration, and Open WebUI keeps sending OTLP unchanged. That flexibility only pays off if someone owns the configuration. Decide who maintains receivers, processors and exporters, where that configuration lives in version control, and how changes are tested before they reach production. Grafana provisioning can define the Tempo, Loki and Prometheus data sources as files loaded at startup, so the read side is reproducible too. Before the build starts, list the signals you need, the retention each backend will hold, and which team responds when a dashboard goes empty.
Configure the Collector, enable Open WebUI export and connect Grafana
This sequence connects Open WebUI to an OpenTelemetry Collector, routes traces, metrics and logs to Tempo, Prometheus and Loki, and makes them visible in Grafana. Each step closes with a check so the team knows the data path works before building views on top of it.
Deploy the Collector with an OTLP receiver
The platform engineer deploys the OpenTelemetry Collector in the same network segment as Open WebUI, either as an agent beside the service or as a gateway, depending on how many sources will send data. Configure an OTLP receiver bound only to the interface Open WebUI can reach, and enable the health check extension. Pin the Collector to a release you have reviewed on the project's releases page. Done when the process starts without configuration errors and the health endpoint reports healthy.
Configure exporters for each signal
Add a pipeline for each signal: traces to Tempo, metrics to Prometheus and logs to Loki, using the endpoints and credentials your Grafana stack provides. Apply the Collector configuration best practices for securing receivers and exporters, including authentication on the receiver, TLS on exporter connections and secrets kept out of the configuration file. Done when each exporter reports successful sends and its endpoint accepts test data, which you confirm in the Collector's own telemetry and the backend logs.
Enable telemetry in Open WebUI
Turn on OpenTelemetry export in Open WebUI using the settings in the documentation for the release you run, because setting names can change between versions. Confirm each name against that release before editing the deployment. Point the export endpoint at the Collector, restart the service, then send a few test chats and API requests. Done when the Collector shows trace, metric and log records that originate from Open WebUI.
Add Tempo, Loki and Prometheus to Grafana
Define Tempo, Loki and Prometheus as Grafana data sources in provisioning files, which Grafana loads at startup, so the configuration lives in version control rather than in manual clicks. Keep credentials in environment variables or a secrets store referenced from the files. Apply the Grafana security hardening recommendations to the instance, including secure cookies and requiring authentication for the metrics endpoint. Done when each data source passes its connection test and you can query recent traces, logs and metrics in Explore.
Confirm span and metric names exist
Before building any dashboard, query Tempo and Prometheus to find the span names and metric names that Open WebUI and its dependencies actually emit for request duration, database queries and Redis calls. Record them in a short inventory alongside the release version, because names can differ between releases and instrumentation libraries. Done when each panel you plan to build has a verified source query that returns data during a test session. If a span or metric is missing, confirm with the release documentation and your instrumentation before concluding it is absent.
Build the first dashboard in code
Build a first dashboard covering response times, database query latency and Redis query latency, using the verified queries from the inventory. Export the dashboard JSON and store it with the provisioning files so it can be reviewed and restored. Generate representative load in a test environment, then check that each panel shows data across the full time range and that values match a manual spot check of a few requests. Done when the dashboard loads from provisioning after a clean Grafana restart.
Which signal answers which operational question
This table maps each telemetry signal from Open WebUI to its backend, the Grafana data source that reads it and the operational question it answers. Use it to decide which signal to query first and which emitted names to confirm before you build dashboards or alerts. The main takeaway is that traces, metrics and logs answer different questions, and they connect only when trace IDs appear in logs and resource labels match across signals.
| Signal | Backend and Grafana source | Operational question | What to confirm |
|---|---|---|---|
| Traces: spans for chat requests | Tempo, read through the Tempo data source | Which route or downstream call accounts for a slow chat response? | Span names for HTTP routes, and whether database and Redis client spans are emitted in the release in use |
| Metrics: request duration histograms | Prometheus, read through the Prometheus data source | How has request latency per route changed over time, and which routes return errors? | Metric names, histogram buckets, and whether route and status code are exposed as labels |
| Metrics: database and Redis query durations | Prometheus, read through the Prometheus data source | Are database or Redis calls slowing down, and does that match the latency spikes on the request panels? | Whether Open WebUI emits query duration metrics itself or whether PostgreSQL and Redis exporters must supply them |
| Logs: errors with trace and span IDs | Loki, read through the Loki data source with a derived field linking to Tempo | Which trace produced this error, and what did the request do before it failed? | The log field names that carry trace and span IDs, and that the Open WebUI logging setup injects them |
| Metrics: replica trends | Prometheus, read through the Prometheus data source | Is load spread evenly across replicas, and did a restart or scale event change latency or error rates? | Resource attributes such as service instance or pod name added by the Collector, and the label names used in dashboards |
How to confirm traces, metrics and logs arrive and correlate
Confirm the pipeline with one known chat request, then follow that request through every backend. Send a request from a test user account with a unique marker in the prompt, and record the time and the conversation identifier that Open WebUI returns. In Tempo, search for the trace from that window and confirm it contains spans for the request path you expect: the inbound HTTP request, the call to the model provider, and the database and Redis operations your deployment performs. In Loki, filter for the trace identifier and confirm that the Open WebUI log lines from the same request appear. In Prometheus, confirm that the request counter or latency series for the chat route changed after the request. Record what you see as the baseline, because span names, attributes and log fields depend on what Open WebUI emits in your version and configuration.
Correlation is the step teams most often skip. An operator should be able to start from a slow trace in Tempo, open the matching log lines in Loki, and return to the same request without manual searching. Check that log lines carry the trace and span identifiers in a form Loki can filter on, and that the Collector passes those identifiers through without dropping them. In Grafana, confirm that the Tempo and Loki data sources are linked, so trace identifiers in log lines produce a navigable link. Keep trace identifiers out of Loki stream labels, since high-cardinality labels degrade query performance. Confirm the exact field names and the link configuration against the Grafana and Loki versions you run.
A multi-replica deployment needs one more check: you must be able to tell which replica produced each signal. Open WebUI requires PostgreSQL, Redis and shared file storage for multiple replicas, so send enough requests through the load balancer to land on every replica. Then confirm that traces, logs and metrics from each replica carry a distinguishing resource attribute, such as a service instance or host identifier. Without one, per-replica latency and error rates merge into a single series, and a failing replica can hide inside healthy averages. Confirm the attribute name in your own emitted telemetry before you build dashboards or alert rules on it, since the name is not something to assume.
Run load tests only in a non-production environment that matches production topology closely enough for the results to matter. Increase traffic in steps, using representative prompts and a fixed set of users, and agree the stop criteria in writing before the first run. During each step, watch the OpenTelemetry Collector's own internal telemetry for queue length, refused or dropped data, and exporter failures, and watch memory use on every Collector instance. Confirm that the memory limiter and queue settings in your Collector configuration keep memory within the limits you set, and record what happens when a queue fills. Also confirm that Grafana and Prometheus stay responsive while the load is applied, because a monitoring stack that fails under load gives no evidence about the system it was meant to watch.
Treat the results as a versioned runbook entry rather than a one-time check. Exact label, attribute and metric names depend on the Open WebUI release, its telemetry settings, the Collector distribution and the Grafana stack versions, so record each of those versions next to the queries and screenshots that passed. Ask the implementation partner, or your own team, to deliver the test script, the pass criteria, the exported queries and the Collector limits used during load testing. Repeat the end-to-end test after every upgrade of Open WebUI or the Collector, because a changed attribute name can silently break dashboards and correlation links without causing any visible error.
Securing the telemetry path and the Grafana side
Telemetry from Open WebUI can carry prompts, user identifiers and log content, so the path from the application to Grafana needs the same care as the application itself. The controls below cover how the Collector authenticates and exports data, what gets redacted and kept, and how the Grafana instance is hardened and signed in.
Authenticate OTLP receivers
Any client that can reach the OTLP receiver can send data into your pipeline, so the receiver should require identity. The OpenTelemetry Collector supports authenticator extensions on receivers, and OIDC is one option where the Collector build and your identity provider support it. Confirm which authenticators your Collector distribution includes, then test that an unauthenticated request is rejected before you rely on the endpoint.
Add credentials to exporter requests
If the tracing, metrics or log backend requires a token, the Collector must send one on every export. The oauth2client extension can attach credentials to outgoing exporter requests where the backend accepts that flow. Check the token lifetime, how the client secret is delivered to the Collector, and whether rotation can happen without restarting the pipeline.
Keep telemetry endpoints private
The OTLP receiver, the Collector health and metrics endpoints and the Prometheus, Tempo and Loki ingest paths should sit on private networks rather than public addresses. Where traffic crosses a network boundary, use TLS with certificates your team issues and rotates. Verify the network policy from the Open WebUI host, and confirm that no telemetry port is reachable from the internet or from user networks.
Redact prompts and identifiers
Traces and logs can capture user prompts, model responses, email addresses, session identifiers and uploaded file names. Define which attributes the Collector drops, hashes or truncates before export, and decide whether prompt content is recorded at all. Review sample exports from a test environment with a privacy and legal reviewer, since the answer depends on your data classification and the users you serve.
Set retention for each signal
Traces, metrics and logs usually need different retention periods, and each backend enforces retention differently. Write down how long each signal is kept, who can query it, and how deletion is verified. Shorter retention for content-bearing logs limits exposure after an incident. Ask Grafana Labs or your storage team to confirm the retention settings for Tempo, Loki and Prometheus in your chosen deployment model.
Harden the Grafana instance
The Grafana security hardening guidance recommends secure and SameSite cookies, a Content Security Policy, Trusted Types, hiding the Grafana version from unauthenticated users, requiring authentication for the metrics endpoint, and domain verification against DNS rebinding. Apply each setting in configuration, then test login, dashboards and the metrics endpoint from an outside client to confirm the change took effect.
Choose an open-source sign-in method
SAML, team sync, active sync and SCIM provisioning are available only in Grafana Enterprise and Grafana Cloud. Open-source Grafana supports LDAP, generic OAuth, Entra ID, Okta, GitHub, GitLab, Google OAuth, auth proxy and JWT. Pick the method that matches your identity provider and confirm, with your identity team, how roles map to Grafana teams and who removes access when someone leaves.
Common failures when exporting Open WebUI telemetry
This table lists the most common failures when Open WebUI telemetry reaches Grafana through an OpenTelemetry Collector, with the likely cause and the first check to run. Work through the rows in order, because a broken endpoint or network path hides every other signal. Confirm each check against the Open WebUI release and the Collector version you actually run.
| Failure | Likely cause | First check or fix |
|---|---|---|
| No data in Grafana | Exporter endpoint or port is wrong, or the network path between Open WebUI and the Collector is blocked | Confirm the endpoint and protocol match the Collector receiver, then test reachability from the Open WebUI container or pod |
| Traces present, no logs | Log export is not enabled in Open WebUI, or the Collector has no logs pipeline to Loki | Check that log export is switched on, then confirm the Collector config includes a logs pipeline with a Loki exporter |
| Missing database or Redis spans | Instrumentation for that client is not enabled, or the running release does not emit those spans | Check the release notes for your running version and confirm which spans it emits before changing the pipeline |
| Collector memory grows under load | No memory_limiter processor, or the batch processor is missing or undersized | Place memory_limiter first in each pipeline, add batch, then watch Collector memory during a load test |
| Duplicate or missing metrics across replicas | Replicas report identical resource attributes, so series overwrite each other | Set a unique service.instance.id or host attribute for each replica and confirm series are separate in Prometheus |
| Authentication errors at receiver or exporter | Token or credential is missing or expired, or the auth extension is not attached to the matching receiver or exporter | Verify the credential on both ends and test it from outside Open WebUI with the same settings |
How the Open WebUI license and release cadence affect your monitoring plan
Before your team changes anything the interface shows, confirm which license governs your Open WebUI build. Since v0.6.6 (April 19, 2025), Open WebUI code is distributed under the Open WebUI License, which adds a branding protection clause. Code through v0.6.5 remains under BSD-3-Clause. The clause forbids altering or removing Open WebUI branding in deployments that exceed 50 users in any rolling 30-day period, unless you hold an enterprise license or written contributor permission. This matters for monitoring work because it is easy to add a status banner, a custom footer or a telemetry panel to the UI without realizing it touches branding. Count active users over a rolling 30-day window now, and record the result with the version you run.
Keep the OpenTelemetry export work separate from any front-end change. Setting the exporter endpoint, service name and sampling in the environment does not, by itself, alter branding. A patched template, a custom theme or an injected script can. If your user count is above the threshold and the monitoring design calls for a branded or modified interface, ask the Open WebUI enterprise team for a quote, and give them your expected seat count, since pricing is not published. If the design can avoid UI changes, have legal or licensing counsel confirm that the Grafana dashboards, which sit outside Open WebUI, fall outside the clause before you rely on that reading.
The release cadence determines how often your telemetry setup must be retested. Open WebUI v0.11.0 shipped in July, v0.12.0 followed on October 10 and v0.12.3 on October 16, 2026. Each release can rename spans, change metric labels, alter log fields or adjust how database and Redis calls are instrumented. After every upgrade, run a fixed checklist: confirm traces arrive in Tempo, confirm the expected metrics appear in Prometheus, confirm logs reach Loki with the labels your dashboards query, and compare panels against a baseline. Pin the image tag in your deployment so an upgrade happens only when someone chooses it, and schedule the retest in the same change window.
Track the Grafana upgrade cadence in the same plan, because the dashboards and data source configuration depend on it. Grafana's upgrade guidance describes minor releases every other month and patch releases at least monthly. Each minor release is supported for 9 months, and the last minor release of a major version for 15 months. The grafana/grafana releases page lists patch releases 13.2.4, 13.1.8 and 13.0.11 on October 13, 2026, which shows how quickly patches arrive. Assign one owner for both the Open WebUI and Grafana calendars, stage upgrades in a non-production environment that receives the same OTLP traffic, and keep dashboards and data sources provisioned as code so a rollback restores a known state.
Questions buyers ask about Open WebUI monitoring with OpenTelemetry and Grafana
What drives the cost of an OpenTelemetry and Grafana setup for Open WebUI?
The main drivers are the number of Open WebUI replicas, the telemetry backends you choose, whether Grafana runs in your infrastructure or as a managed service, the depth of the security review, and the dashboard scope.
- Replicas: each instance is a telemetry source to configure, verify and keep consistent.
- Backends: traces, logs and metrics each need storage sizing, retention and query tuning in Tempo, Loki or Prometheus.
- Grafana model: self-hosting adds high availability, database, upgrade and backup work that recurs after go-live.
Grafana Cloud is a managed alternative with published prices. The Grafana pricing page lists a Pro tier starting with a 19 US dollar monthly platform fee plus usage, and an Enterprise tier with a 25,000 US dollar per year minimum commitment. DeployOpen does not publish prices. A quote follows from the written scope, so ask for the replica count, backends, Grafana model, review depth and dashboard list to be itemized.
Can our own team set up Open WebUI telemetry without outside help?
Yes, if your team already operates the OpenTelemetry Collector and Grafana and has a test environment where changes can be tried before production.
The Collector needs receivers, processors and exporters configured correctly, and Open WebUI needs its OTLP export settings enabled and checked. Grafana needs data sources, dashboards and access controls wired to the right backends. Teams without this experience usually spend most of their time on the first working configuration, and that time grows when a problem appears in production. Ask yourself three questions: Do we have people who can troubleshoot a Collector pipeline? Can we test changes without touching live users? Who will maintain the dashboards after handover? If any answer is no, a fixed-scope engagement with written deliverables may cost less in staff time, and DeployOpen can quote that from your scope.
How long does an Open WebUI observability project take?
Duration depends on the scope and on your environment, and it should be set in the written scope rather than estimated in advance.
The factors that move the timeline are the number of replicas to instrument, whether a Collector and Grafana already exist, how many backends are involved, how many dashboards and alerts are requested, and how long your change approval and security review take. Your change windows also constrain when Open WebUI restarts and Collector rollouts can happen. Most DeployOpen engagements are fixed-scope, so the scope, deliverables and timeline are agreed in writing before work starts. Ask for the phases, the environments used for each phase, and the points where your team must approve, provide access or accept results.
What do we need to provide for an OpenTelemetry Grafana engagement?
Expect to provide access to the environments where Open WebUI, the Collector and Grafana run, plus a decision on the backend for each signal type.
Identity decisions come early. Decide who can view dashboards, whether Grafana uses single sign-on, and whether you need SAML or SCIM provisioning. The Grafana authentication docs list SAML, team sync, active sync and SCIM provisioning as Grafana Enterprise and Grafana Cloud features, so this choice affects edition and cost. Book change windows for Open WebUI restarts and Collector rollouts. Confirm that your network allows OTLP traffic between the components. Finally, name an owner who can approve the dashboard scope and accept verification results.
Should we self-host Grafana or use Grafana Cloud for this?
It depends on your data location rules, your staffing and how much operations work you want to keep in house.
Self-hosted Grafana runs in your infrastructure. The Grafana installation docs say SQLite does not scale for production, so MySQL or PostgreSQL is needed for production and high availability. High availability uses two or more active-active servers behind a load balancer, and alerting needs extra configuration to avoid duplicate notifications. Grafana Cloud removes most of that server work. The Grafana pricing page lists a free tier, a Pro tier starting with a 19 US dollar monthly platform fee plus usage, and an Enterprise tier with a 25,000 US dollar per year minimum commitment. Confirm with Grafana which features each tier includes, and ask your security team whether telemetry may leave your environment.
What typically goes wrong in an OpenTelemetry pipeline for Open WebUI?
The most common problems are wrong exporter endpoints, Collector configurations that accept data but drop it at an exporter, and telemetry that arrives without the attributes needed to filter dashboards by replica or environment.
Authentication settings can also cause silent gaps. The Collector can authenticate incoming connections with extensions such as OIDC and add credentials to outgoing requests with the oauth2client extension, so a mismatch shows up as missing data rather than an error. Check each stage in order: send a test trace, confirm it appears in Tempo, then confirm logs in Loki and metrics in Prometheus. Also check the stability level of each Collector component in its README before relying on it in production.
How do we keep sensitive prompt data out of telemetry?
Start by confirming what Open WebUI exports under your settings, because prompts, user identifiers and file names can appear in spans and logs depending on configuration.
Verify this in the test environment instead of assuming it. Then decide what the Collector should drop, redact or hash before data reaches any backend, and document the rule for each signal type. Restrict who can query traces and logs, since access to raw telemetry can expose the same content. On the Grafana side, the security hardening docs recommend secure and SameSite cookies, a Content Security Policy, hiding the version from unauthenticated users, and requiring authentication for the metrics endpoint. Ask for these checks to appear as named items in the written security review scope.
How DeployOpen scopes, builds and supports this integration
DeployOpen plans, implements, integrates and documents self-hosted open-source platforms inside your own infrastructure, and this integration follows the same arc. The work starts with a written scope that names the Open WebUI instance, the OpenTelemetry Collector pipelines and the Grafana, Tempo, Loki and Prometheus backends your team runs.
How we scope
- The written scope names each Open WebUI replica, its database and the telemetry backends that receive its data.
- Scope fixes which signals are in: traces for response times, metrics for database and Redis query behavior, and logs.
- Fixed-scope engagements are agreed in writing before work starts, and ongoing support can be added as a retainer.
How we build
- Configure Open WebUI's OTLP export and an OpenTelemetry Collector to receive, process and forward data to your backends.
- Build Grafana dashboards and alert rules as code through provisioning files, so the views are reviewed and versioned.
- Test that Collector pipelines handle sensitive attributes as agreed, including any prompt text you choose not to export.
How we hand over
- Handover includes the Collector configuration, provisioning repository, dashboard inventory and an operating runbook for your team.
- Documentation covers which signals are collected, retention settings in each backend and how to add a new service.
- Your team walks through the checks, dashboards and alert routes before the engagement closes.
How we support
- Upgrade planning covers Open WebUI releases, Collector releases and Grafana minor and patch versions on your schedule.
- Retainers can cover version upgrades, dashboard changes, alert tuning and continuous testing of the stack.
- Confirm with your vendor which Grafana, Loki and Tempo versions your support agreement covers before go-live.
