How Grafana connects to Loki for log dashboards
If you run or plan a self-hosted Loki and need Grafana to query, chart and alert on logs, you do not need a plugin. Grafana includes built-in Loki support, so the work is configuring a Loki data source that points at your Loki endpoint, then deciding how your teams will query it. The data source covers log queries, LogQL metric queries that derive numbers from logs, alerting and annotations. It does not cover traces, so trace views belong to a separate data source such as Tempo. Confirm the Loki version you run against the Grafana Loki data source documentation before you standardize on a Grafana release, since query features can depend on both sides.
The design choice that shapes every dashboard is how Loki stores data. Loki indexes only metadata about logs as labels, using the same label model Prometheus uses, and it compresses and stores the log content itself. A LogQL query first selects streams by label, then scans the compressed content for matching text. This means label choices made at ingestion, such as application, environment, namespace or tenant, decide how fast and how cheap dashboards and alert rules run. High-cardinality labels, such as user IDs or request IDs, inflate the index and slow queries, so put searchable detail in the log line and keep labels to stable, bounded values.
Before building panels, verify three things with your team: which Grafana data source identity each dashboard and alert will use, whether tenants are separated by the X-Scope-OrgID header that Loki reads when multi-tenancy is enabled, and who can edit the data source configuration. Because Loki has no built-in authentication, access control in front of Grafana and Loki must be designed together with the reverse proxy that protects the Loki endpoint. Agree on a naming convention for labels and a small set of shared dashboards now, since changing labels later means rewriting queries, panels and alert rules across the instance.
What you need before connecting Grafana to Loki
Connecting Grafana to Loki touches four systems: the Grafana instance and its configuration database, the Loki release and its object storage, the access layer in front of Loki, and the network path between them. Confirm each one before you build dashboards, because version and tenant choices made early are harder to change later.
Loki version to confirm
Confirm the Loki release you will run against the current release list before you write any queries. The Loki releases page lists v3.7.8, published September 17, 2026, as the latest release at the time of this writing. Check that your chosen release supports the deployment mode, index store and object storage you plan to use, and record the exact version so that later upgrades and query behavior can be traced to it.
Grafana edition and version
Decide which Grafana edition you run and confirm the Grafana version that will host the Loki data source. The Loki data source is built into Grafana, so no plugin installation is needed. Check the Grafana release notes for data source changes before you pick a version, since a later upgrade can change how Loki queries behave in panels and alerts.
Production configuration database
Grafana stores its configuration in SQLite by default, but the installation docs say SQLite does not scale for production. Plan MySQL 8.0 or later, or PostgreSQL 12 or later, for any instance that serves several teams or runs in high availability. Confirm who owns backups for that database, because dashboards, data source definitions and alert rules all live there.
Object storage for Loki
Loki keeps compressed log chunks and its index in object storage, so the storage backend determines durability, cost and retention behavior. The recommended production stores are Amazon S3, Google Cloud Storage and Azure Blob Storage. S3-compatible stores such as MinIO and the local filesystem are supported but not typically recommended for production. Confirm the bucket, credentials and region before you deploy, and confirm the index store you intend to use.
Authentication and tenant mode
Loki has no built-in authentication layer. Decide whether auth_enabled is true, which makes Loki multi-tenant and requires every request to carry an X-Scope-OrgID header, and whether a single tenant is enough. Place an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium in front of Loki, and map Grafana users or data source configurations to the tenant IDs they may read.
Network path to the query endpoint
Grafana must reach the Loki query endpoint over a path that the reverse proxy allows, and the proxy must pass the tenant header through. Confirm firewall rules, DNS names, TLS certificates and any proxy between Grafana and Loki before testing. Also confirm that Grafana's own outbound and inbound rules match your network policy, because alert notifications and Grafana Live traffic use separate paths.
Why label design decides how fast your log queries run
Label design decides how fast your log queries run because Loki indexes only metadata about each log stream, using the same label model Prometheus uses, while the log content itself is compressed and stored in object storage. Every label pair you attach to a stream, such as namespace, app or env, shapes how many streams Loki must track and how many chunks a query has to open. Labels with few stable values keep the index small and queries narrow. Labels built from request IDs, user IDs, client IPs or other unbounded values create high cardinality, which inflates the index and slows every dashboard that touches those streams. Before you ship a collector configuration, list the labels it will emit, estimate how many distinct values each one can take in your environment, and confirm with your own test data that the stream count stays within what your Loki version and storage backend handle well. Put high-variety values in the log line and extract them at query time instead.
LogQL has two query types that Grafana uses differently. A log query starts with a stream selector in braces, such as {app="checkout", env="prod"}, and then filters or parses the lines that match, returning the log entries themselves. A metric query wraps a log query in a range aggregation, such as count_over_time or rate, and returns numeric time series that can be graphed, thresholded and alerted on. Explore runs both kinds in the Loki data source and shows log lines alongside a histogram, which makes it the right place to test selectors and filters before they become panels. Dashboards and log-based alert rules should rely on metric queries wherever possible, because they aggregate server-side and return compact series rather than raw lines. Because the stream selector is the only part Loki resolves through the index, keep it as specific as your labels allow, and move line filters and field parsing after it. Confirm the label set your team will use with the Loki data source configuration before building shared dashboards.
How to configure the Loki data source in Grafana
This sequence takes a self-hosted Loki endpoint from a reachable, authenticated address to a working data source, log and metric panels, annotations and a log-based alert rule. Each step closes with a check you can run before moving on.
Confirm the Loki endpoint and proxy authentication
Before touching Grafana, confirm the URL that Grafana will call and the authentication layer in front of it. Loki has no built-in authentication, so an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium must sit in front of it. Decide which credential Grafana will send, such as a service account token or a basic auth pair, and confirm that the proxy accepts it. Check with a simple readiness request from the Grafana host using the same credential. Done means the request returns a successful response from the Grafana server itself, not only from your workstation.
Add the built-in Loki data source
In Grafana, open the data source menu and add Loki. No plugin installation is needed because Grafana includes Loki support in the core product. Enter the Loki URL, select the authentication method your proxy expects, and, if Loki runs with auth_enabled set to true, add the X-Scope-OrgID header with the tenant name that owns the logs. Use a read-only identity where possible. Done means the save-and-test action reports that the data source is working. If it fails with an authorization error, check the header name and the tenant value against the Loki configuration.
Provision the data source as code
Move the data source definition into a provisioning file so that the same URL, header and authentication settings are created at every Grafana startup and across environments. Grafana loads data sources from YAML files in its provisioning directory. Keep secrets such as tokens out of the file itself and inject them through environment variables or your secrets manager. Restart Grafana, or reload provisioning if your setup supports it, then confirm the data source appears with the same name and passes its test. Done means the data source exists after a clean restart without anyone creating it by hand.
Build a first log panel
Create a dashboard and add a panel that uses the Loki data source in logs visualization. Start with a stream selector built from a small number of labels that Loki indexes, such as an application or namespace label, and set a narrow time range. Confirm that the query returns streams and that the log lines show the expected timestamps and labels. If the panel is empty, check the label names and values in the Loki label browser and confirm that the time range falls within the retention period. Done means the panel returns the streams you expect from the systems you know are shipping logs.
Build a LogQL metric panel
Add a second panel in time series visualization with a LogQL metric query, such as a rate or count of log lines over a range for the same stream selector. Use label filters and line filters to narrow the result before aggregating. Compare the result with a manual count from the log panel for a short window to confirm the aggregation is correct. Done means the time series shows a sensible value for the window, and the legend labels identify the streams correctly. Keep metric queries focused, because wide selectors over large volumes can be slow on the Loki side.
Add annotations from log queries
Create a dashboard annotation that uses the Loki data source with a query that matches a meaningful event, such as deployment messages or error bursts from a specific service. Set the annotation to display on the time series panels you built earlier. Hover over a marked point to confirm that the annotation text matches the underlying log line. Done means the annotation appears at the expected times on the metric panel and links back to the event that caused it, which makes it easier to correlate spikes with changes.
Create a log-based alert rule
In Grafana Alerting, create a rule that uses the Loki data source with a LogQL metric query and a threshold that represents a condition worth acting on, such as a sustained rise in error lines for one service. Set the evaluation interval and pending period to match how quickly the team needs to respond, and attach a contact point or notification policy you have already tested. Save the rule and check its state in the rule list. Done means the rule evaluates without errors, shows a normal state under current conditions, and reaches the expected state when you test with a known error pattern in a non-production stream. Confirm the rule behavior in your own environment before relying on it for paging.
Single tenant or multi-tenant Loki behind Grafana
A single-tenant Loki runs with auth_enabled set to false, so every request is stored and queried under one implicit tenant and no tenant header is required. This is the simplest layout to build and operate, and it fits one team that owns all of its logs and where everyone with access to Grafana may read everything in Loki. Access control is then a question for the layers around Loki, because Loki itself does not check who is calling. Loki has no built-in authentication layer, so any single-tenant deployment that is reachable from more than one network segment still needs an authenticating reverse proxy in front of it.
- Configuration: Leave
auth_enabledoff and point the Grafana Loki data source at the Loki endpoint without any custom tenant header. - Access boundary: Every Grafana user who can open the data source can query every stream, so Grafana folder and data source permissions are the only fine-grained control.
- Retention: One retention policy applies to all logs, set through the compactor, unless you use stream selectors to vary it.
- Alerting: Log-based alert rules evaluate against the whole store, so one noisy source can affect every rule and annotation that uses the same data source.
- Migration cost: Turning on multi-tenancy later means every writer, reader and rule must start sending a tenant header, so plan that change early.
Before choosing this model, confirm with your security and compliance owners that a shared read scope is acceptable for every log source you plan to ingest.
With auth_enabled set to true, Loki treats each value of the X-Scope-OrgID header as a separate tenant. Writes, queries, alert evaluation and retention each operate within the tenant named on the request, so one team's streams are not returned to another team's queries. The tenant boundary is only as strong as the proxy that sets the header, because Loki trusts whatever value it receives. An authenticating reverse proxy should map each user or service identity to an allowed tenant and overwrite any header the client supplies.
- Tenant header: Each Grafana Loki data source must send the correct X-Scope-OrgID value. Create one data source per tenant, or use a proxy that injects the header from the signed-in user's group, and confirm which approach your Grafana edition supports.
- Write path: Log shippers such as Grafana Alloy must set the tenant for each stream or route, otherwise logs land in an unexpected tenant.
- Retention per tenant: Retention can be set globally, per tenant or per stream selector, so each owner can have its own period.
- Operational overhead: More tenants mean more limits, more data sources and more dashboards to keep in sync.
- Verification: Test that a user in tenant A cannot query tenant B through Grafana, the proxy and direct API calls.
Ask your Loki and Grafana administrators to document which header value each data source sends and who can change it.
Putting unrelated owners in one tenant removes the only technical boundary Loki provides between their logs. Application teams, a security team and an external customer may all have legitimate reasons to see some logs, but they rarely share the same need to see every stream. A shared tenant also means one owner's retention decision, label design or query load affects everyone else's data and dashboards. For customer-facing or regulated data, the separation is often a contractual or audit question as much as a technical one, and a shared tenant is hard to justify when a customer asks who could read their logs.
- Data exposure: Anyone with read access to the tenant can query all of its streams, including fields that contain personal or secret data.
- Shared retention: A single retention rule may keep one owner's logs longer than its policy allows, or delete logs another owner still needs.
- Noisy neighbors: A high-volume source can exhaust ingestion or query limits that other owners depend on.
- Audit trail: It becomes difficult to show which owner's data a given query or alert accessed.
- Separation of duties: Security and compliance teams that need independent read access often need their own tenant.
When owners are related, such as several services run by one platform team, a shared tenant with stream-level retention can be a reasonable choice. Confirm that decision with the data owners in writing.
Log-based alert rules and annotations both query Loki through a Grafana data source, so the tenant header that data source sends determines what each rule and annotation can see. In a single-tenant setup, one rule can match any stream, and one annotation query can read any stream. In a multi-tenant setup, a rule or annotation only sees the tenant it is bound to, so a rule written against one data source will silently miss logs from another tenant. Confirm which data source each rule uses before assuming it covers the intended logs.
- Rule scope: Alert rules in each tenant evaluate only that tenant's streams, so duplicate rules may be needed for each owner's data.
- Ownership of rules: Assign each rule to the team that owns its tenant and data source, so changes do not affect other owners.
- Annotations: Annotation queries show events from the tenant configured on the dashboard's data source, so dashboards shared across tenants can show different events to different viewers.
- Notifications: Route alert notifications to contact points owned by the tenant's team to avoid sending another owner's log data to the wrong people.
- Provisioning: Define data sources and alert rules as code, so each tenant's configuration is reviewable and repeatable.
Before go-live, test one alert and one annotation per tenant with a known log line, and confirm that a tenant without that line does not fire or show it.
How Loki labels, tenants and Grafana objects map
This table compares each Loki element with the Grafana object it becomes, such as stream labels becoming variables and X-Scope-OrgID becoming a data source setting. Read each row as a design decision to confirm against your own label set, tenant layout and retention policy before dashboards are shared.
| Loki element | Grafana object | Design note | What to confirm |
|---|---|---|---|
| Stream labels | Dashboard variables and label filters | Labels are the only indexed metadata, so variables work best on a small set of low-cardinality labels such as app, namespace or environment. | Which labels are indexed and how many distinct values each has in production |
| Log content | Log panels and line filters | Log lines are compressed and not indexed, so text searches scan chunks and filter in LogQL rather than in the label index. | Query time ranges and line filter patterns that dashboards will run by default |
| X-Scope-OrgID header | Loki data source with a per-tenant header | Each tenant needs its own data source or header setting when auth_enabled is true, so folder and team permissions can follow tenant boundaries. | Tenant IDs, whether auth_enabled is set, and how the reverse proxy sets the header |
| Retention scope (global, tenant or stream) | Team ownership of dashboards and data | Retention runs in the compactor and is disabled by default, so each retention rule should map to a named team that owns the data it keeps. | Retention rules in force, the owning team for each rule and whether retention_enabled is set |
| LogQL metric query | Alert rule condition | Metric queries such as rate or count_over_time produce numeric series that Grafana alerting can evaluate against thresholds. | Evaluation interval, threshold values and behavior when no logs match the query |
| LogQL log query with filter | Annotations | Annotations can mark events such as deployments or error bursts on time series panels, using the Loki data source annotation support. | Which queries drive annotations and whether they are limited to a time range to control load |
| Reverse proxy authentication | Data source access and user permissions | Loki has no built-in authentication, so Grafana users reach it only through an authenticating proxy that sets tenant access. | Which identity provider controls proxy access and whether tenant IDs are derived from user groups |
Securing the Loki query path and tenant access
Loki does not authenticate the people or systems that query it, so the query path has to be secured in front of Loki and inside Grafana. The cards below cover the reverse proxy, transport encryption, per-tenant scoping, Grafana role design and how credentials are kept out of provisioning files.
Put an authenticating proxy in front of Loki
Loki has no built-in authentication layer, and its documentation says you must run an authenticating reverse proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium in front of it. The proxy becomes the only path to the query and push endpoints, so direct access to Loki's ports from user networks should be blocked at the network layer. Confirm which identity the proxy checks and how it passes the tenant header through.
Encrypt Grafana to Loki traffic
Log queries carry sensitive content and tenant identifiers, so the connection from Grafana to the proxy and from the proxy to Loki should use TLS. Decide where certificates terminate, who renews them, and whether internal traffic between Loki components also needs encryption in your environment. Confirm the TLS settings supported by your chosen proxy and the Grafana data source configuration before the build starts.
Scope each data source to one tenant
When auth_enabled is true, Loki identifies tenants with the X-Scope-OrgID header on every request. Create one Grafana data source per tenant or team with that header set, so a dashboard cannot switch tenants by editing a query. Check that the proxy overwrites any tenant header a client sends, because a header set by the user would otherwise decide which tenant's logs are returned.
Design Grafana roles around data sources
Editing a data source changes the URL, headers and credentials that every dashboard on it uses, so that permission should be narrower than viewing logs. Limit data source editing to a small platform group, give team members Viewer or Editor rights on dashboards and Explore, and review who holds admin rights. Open source Grafana controls are more limited than Enterprise, so confirm which role model your edition provides for your team layout.
Keep credentials out of provisioning files
Grafana provisioning loads data sources from YAML or JSON at startup, which makes them easy to version, but a plain password or token in those files is readable by anyone with repository or host access. Reference secrets from environment variables or a secrets store supported by your deployment, and keep the provisioning files free of tokens. Check the Grafana provisioning docs for the exact variable syntax in your version.
Apply Grafana security hardening
Grafana's hardening guidance covers secure and SameSite cookies, a Content Security Policy, Trusted Types, hiding the version from unauthenticated users, requiring authentication for the metrics endpoint and domain verification against DNS rebinding. These settings protect the Grafana side of the Loki query path and should be applied and tested in the same change as the proxy. Record which settings you adopted so an auditor or reviewer can trace them.
Why Loki panels return no data or alerts fail
This table lists the failures teams hit most often when Grafana queries Loki or when Loki-based alert rules misbehave, with the likely cause and the fix for each. Work through the rows in order, because a missing tenant header or a blocking proxy hides every other symptom. Confirm each fix against your own Loki and Grafana versions before changing production settings.
| Symptom | Likely cause | Fix |
|---|---|---|
| Panels return no data for a known tenant | Loki has auth_enabled set to true but the Grafana Loki data source does not send the expected X-Scope-OrgID header, or sends a different tenant ID | Set the tenant ID in the data source's custom HTTP headers so each request carries the correct X-Scope-OrgID value, then query the same tenant directly with curl to confirm |
| Queries fail with authorization errors or never reach Loki | Loki has no built-in authentication, so the authenticating reverse proxy in front of it rejects or rewrites Grafana requests, or strips the tenant header | Allow the Grafana server's address through the proxy, pass the tenant header through unchanged, and check proxy access logs for rejected requests |
| Dashboards load slowly or time out | High label cardinality, such as request IDs, user IDs or IPs used as labels, creates very many small streams that each query must scan | Keep labels to low-cardinality values like app, namespace and environment, move high-variety values into log content, and filter with line filters instead |
| Older logs are missing from queries | Retention is either not enabled, so the compactor keeps everything, or set too aggressively, so data is deleted sooner than the dashboards expect | Check the compactor and retention settings and confirm the intended period per tenant or stream selector, remembering each stream rule is at least 24 hours |
| Alert rule fires on the wrong condition or never fires | The rule uses a log query that returns log lines or streams instead of a numeric result, so the alert has no single value to compare against a threshold | Wrap the selector in a LogQL metric function such as count_over_time, then add a reduce or threshold expression so the rule evaluates a number |
| Duplicate alert notifications from two Grafana servers | Each active-active Grafana node evaluates alert rules and sends notifications without coordination, which the high availability docs say needs extra configuration | Enable the alerting high availability settings so nodes share state and only one sends each notification, and test with a non-production contact point first |
| Alert rule works in Explore but not in alerting | The query uses a time range or variable that alerting does not resolve the same way, or the data source is referenced by a name that differs between instances | Use fixed relative ranges in the rule, confirm the data source UID is the same in each environment, and review the rule's evaluation history |
Questions buyers ask before connecting Grafana to Loki
What drives the cost of a Grafana and Loki integration?
The main cost drivers are label design, the number of tenants, the object storage layout and the reverse proxy you have to build, because Loki has no built-in authentication. Label design sets how efficiently queries run and how much index work the cluster does, so it is the first thing to settle. Tenant count multiplies the access rules, retention settings and dashboards you must maintain. Object storage choice and retention decide the recurring infrastructure bill. Ask any partner for a quote built from a written scope that lists log sources, tenants, retention rules, the deployment mode and the proxy design, so you can compare options on the same basis.
How long does a Grafana and Loki integration take?
Duration depends on the number of log sources, the deployment mode, how many tenants need separate access and how much dashboard and alert work is included. Loki documents three deployment modes, from a single monolithic binary to a microservices layout for very large clusters, and the choice changes the amount of infrastructure to build and test. Plan for time to validate label design against real queries before any dashboards are built. Fixed-scope engagements agree timelines in writing before work starts, so ask for the timeline as part of the written scope rather than relying on an estimate in a sales call.
What do we need to provide for the work to go smoothly?
You need to name owners for each part of the system before the work starts. A tenant owner should be named for every tenant, so access requests and retention decisions have a clear approver. A log source owner should confirm which applications, hosts or agents will ship logs and what fields they emit. A storage owner should provide access to the object store, including bucket creation and the credentials or identity the Loki components will use. A network or security owner should approve the reverse proxy design, since Loki has no built-in authentication and must sit behind an authenticating proxy such as nginx, HAProxy, OAuth2 Proxy or Pomerium.
Can our internal team build this without a partner?
Yes, an internal team can build it, provided it has skills in Loki configuration, object storage, reverse proxies and Grafana provisioning. The hardest parts are usually label design, which is hard to change once logs are ingested at volume, and the authentication layer, which you must build yourself. Teams with a small number of tenants and a clear log model often manage this in-house. A partner adds value when the timeline is tight, when several tenants with different access rules must be supported, or when the team needs an independent review of the design. Decide by comparing your team's time and skills with the written scope.
How does label design affect Loki queries and alerts?
Loki indexes only metadata about logs as labels, using the same label model Prometheus uses, and stores the log content compressed in object storage. This means labels should be stable, low in cardinality and chosen for how you filter, not for every field in a log line. Poor label choices make queries slower, make log-based alerts harder to scope and increase index work. High-cardinality values such as user IDs or request IDs belong in the log line, where LogQL can filter them. Test label choices with real LogQL metric queries before you write alert rules that depend on them.
Does Grafana Enterprise add SAML and team sync for Loki dashboards?
Grafana Enterprise adds SAML, team sync, active sync and SCIM provisioning, which the Grafana authentication documentation lists as available only in Grafana Enterprise and Grafana Cloud. The open-source edition still supports LDAP, generic OAuth, Entra ID, Okta, GitHub, GitLab and Google OAuth, auth proxy and JWT. Those features control who signs in to Grafana and which teams see which dashboards. They do not change how Loki itself authenticates tenants, which still needs a reverse proxy in front of Loki. Confirm your identity provider requirements against the license terms, since Grafana Labs relicensed Grafana and Loki to AGPLv3 in 2021 and offers Enterprise as a non-AGPL commercial option.
How do multi-tenant Loki setups affect access and retention?
Loki is multi-tenant when auth_enabled is true, and each request identifies its tenant with the X-Scope-OrgID header. Grafana data sources must send the right tenant header for each dashboard or team, so access design has to be agreed before data sources are created. Retention is disabled by default, so logs are kept indefinitely until retention_enabled is set. Retention can be global, per tenant or per stream selector, and each stream rule must be at least 24 hours. Ask each tenant owner to confirm retention periods in writing, because changing them later affects data that has already been stored.
What should the written scope for a quote include?
A written scope should list the Grafana and Loki versions in use or planned, the deployment mode, the object storage target, the tenant list with owners, the log sources and their label plan, the reverse proxy and identity design, the retention rules, the dashboards and log-based alert rules to deliver, and the handover and support expectations. It should also state what the client provides and what is excluded. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that document. DeployOpen does not publish a price list, so the written scope is what you compare across proposals.
Keeping log dashboards and alerts reliable after go-live
Log dashboards and log alert rules stay useful only if the Loki side keeps up with volume and the Grafana side keeps up with releases. Plan a recurring review that covers ingestion and query health, label growth, retention and version tracking, and assign an owner for each. Start by watching the write path and the query path separately. Rejected or slow ingestion shows up first as gaps in dashboards and silent alert rules, so a missing-data check should be an alert of its own. Track how many active streams each tenant creates, because label growth is the main cost driver in Loki. Labels that carry request IDs, user IDs or other unbounded values inflate the index and slow queries, and they are easiest to fix when caught in a monthly review rather than after a query timeout.
Retention needs the same discipline. Loki keeps logs indefinitely until retention is enabled on the compactor, so confirm the retention settings for each tenant and stream selector, and record which teams own each rule. Retention changes apply to data going forward, so agree on the period with compliance and security owners before the first deletion, and verify that the rule matches what your records policy requires. Loki releases also need tracking. Subscribe to the Loki releases page, note which version runs in each environment, and test each upgrade against a copy of your dashboards and alert rules. Deployment mode affects all of this. The simple scalable mode is being deprecated and will be removed with Loki 4.0, so if you run it, plan a move to another supported mode early and confirm the target mode with your Loki version notes before you schedule the work.
Grafana upgrades can break Loki queries even when Loki itself is unchanged. Before each Grafana upgrade, confirm the Loki data source version, check release notes for changes to the Loki data source and alerting, and test a sample of LogQL panels and alert rules in a staging instance connected to the same Loki version. Keep data source definitions and alert rules in provisioning files or Git so they can be reviewed and rolled back, and record which Grafana and Loki versions were tested together. Finally, schedule a periodic check of tenant headers, reverse proxy authentication and alert notification paths, since a change in any of them can silently stop logs from reaching dashboards or people.
How DeployOpen scopes and delivers a Grafana and Loki integration
DeployOpen plans, implements, hardens, documents and supports self-hosted Grafana and Loki inside your own cloud accounts, data centers or air-gapped networks. Each log dashboard and alert rule set is agreed in writing before the build starts, so your team knows what is delivered and what it must run afterward.
How we scope
- Inventory the log sources, volumes, label conventions and teams that will query Loki from Grafana.
- Choose the Loki deployment mode, object store and retention policy that match your daily log volume.
- Agree in writing which dashboards, LogQL queries, log-based alert rules and tenant layouts are in scope.
How we build
- Connect the built-in Loki data source to Grafana and define the label model shared with Prometheus.
- Write and test LogQL log and metric queries against representative log streams before building dashboards.
- Provision the data source, dashboards and alert rules as code so changes can be reviewed and repeated.
How we hand over
- Deliver documentation for query patterns, label design, retention settings and alert rule ownership.
- Walk your operators through how annotations, alert evaluation and tenant headers behave in practice.
- Record the configuration, access model and verification steps your team needs to rebuild the setup.
How we support
- Offer ongoing support, upgrades and continuous testing for the Grafana and Loki stack as a retainer.
- Review Grafana and Loki release notes with you before planned upgrades and agree the change window.
- Confirm with your team which reverse proxy and authentication layer will protect Loki and who owns it.
