Embedding Grafana Dashboards in Splunk: Complete Integration Guide

Lede

Modern infrastructure monitoring splits observability workloads across multiple specialized tools. Your organization’s Splunk cluster ingests security events, application logs, and compliance audit trails at scale. Meanwhile, Grafana dashboards visualize time-series metrics from Prometheus, InfluxDB, and Loki, providing sub-second query latency and interactive annotation. Yet your operations teams jump between browser tabs—Splunk for context, Grafana for performance baselines, back to Splunk for correlation analysis.

This fragmentation isn’t incidental. Splunk’s strength is log aggregation, indexing, and ad-hoc correlation queries. Grafana’s is metric visualization and real-time dashboard interactivity. They optimize for different data shapes and query patterns. The business pressure is simple: embed Grafana dashboards directly into Splunk’s UI, giving teams a single pane of glass without sacrificing either platform’s core competence.

This post dissects the five patterns for Grafana-Splunk integration—from the simplest (iframe embedding with anonymous authentication) to the most robust (API-driven rendering via Grafana’s service account, stored in Splunk KV Store). We’ll ground every pattern in the authentication model, CORS machinery, proxy architectures, and the security implications of each. By the end, you’ll know not just how to embed Grafana, but when to embed vs. when to migrate entirely to a unified observability platform.

TL;DR: Pattern Selection Matrix

Pattern	Best For	Latency	Complexity	Security	Admin Burden
Iframe + Anonymous Auth	Public dashboards, non-sensitive metrics, POC	200-500ms	Low	Lowest	Minimal
Iframe + Reverse Proxy	Internal network, SSO enforcement, IP-gated access	300-700ms	Medium	Medium	Moderate
API Rendering + KV Store	Audit trail required, dynamic dashboard switching, versioning	800ms-2s	High	High	Significant
SAML/OAuth Bridge	Enterprise SSO (Okta, Entra ID), user attribute sync	400-800ms	High	High	Significant
Full Migration to OpenTelemetry	If you control both log and metric pipelines, want unified queries	N/A	Very High	Highest	Highest

Terminology Primer: Five Essential Concepts

Before we dive into architecture, let’s ground the vocabulary that distinguishes these integration patterns. Think of these as the building blocks you’ll manipulate at each layer.

A browser security mechanism that governs whether JavaScript running on splunk.company.com is allowed to fetch resources (API calls, images, iframes) from grafana.company.com. When you embed a Grafana dashboard into Splunk via <iframe src="https://grafana.company.com/...">, the browser enforces CORS: the Grafana server must explicitly declare “requests from splunk.company.com are allowed.” Without it, the iframe loads, but interactive features (menus, dropdowns, click handlers) fail silently due to postMessage restrictions. CORS is not a firewall—it’s a browser-level sandbox that prevents malicious scripts from exfiltrating data between domains.

2. Anonymous Authentication

A mode where Grafana allows unauthenticated HTTP requests to view specific dashboards without requiring a login token. This is disabled by default in Grafana Enterprise and requires explicit organization-level configuration. The trade-off: any browser that can reach grafana.company.com/d/{dashboard_id} can view those dashboards, without additional identity verification. This is acceptable for operational dashboards (current request latency, disk usage) but dangerous for sensitive metrics (customer counts, financial performance, security alerts).

3. Service Account & API Token

A non-human identity in Grafana (or any observability platform) that holds explicit permissions to perform specific actions: read dashboards, query data sources, create snapshots. Unlike user accounts, service accounts don’t expire passwords or require MFA. They’re long-lived credentials meant for programmatic access. In the Grafana-Splunk context, a service account token is stored securely in Splunk (typically in the KV Store, encrypted), and the Splunk backend uses it to fetch dashboard data on behalf of end users.

4. Grafana Anonymous Dashboard URL

A special URL pattern that Grafana generates when a dashboard is configured for anonymous access. The URL includes an embedded sharing token (e.g., /d/abc123?shareToken=xyz789) that grants view-only access without requiring a Grafana login. This token is distinct from your organization’s authentication system—the Grafana server verifies the token, not your SSO provider.

5. Reverse Proxy (or API Gateway)

A server (Nginx, HAProxy, Cloud Load Balancer) positioned between the client (Splunk UI) and the backend (Grafana) that intercepts HTTP requests, authenticates the user, and forwards the request on behalf of the user. Unlike a forward proxy (which clients explicitly configure), a reverse proxy is transparent to the client. In the Grafana-Splunk context, a reverse proxy sits between them and can inject authentication headers (e.g., Authorization: Bearer <token>, X-WEBAUTH-USER: alice@company.com) that Grafana trusts.

Layer 1: Top-Level Integration Taxonomy

Before diving into implementation, let’s see how the five patterns map onto a decision tree.

What you’re about to see: A decision tree showing the five patterns and the conditions that guide you toward each one. The root question is “Do you control the Grafana instance?” From there, paths diverge based on authentication requirements, data sensitivity, and operational overhead.

Walking through the tree:

Path 1 — Anonymous Embedding: You’ve configured specific Grafana dashboards for anonymous access (no login required). Splunk embeds them via <iframe>. No authentication machinery needed. This is the simplest path—useful for POC (proof of concept) environments or non-sensitive operational dashboards. The risk: anyone with network access to Grafana can view those dashboards.

Path 2 — Reverse Proxy with Header Injection: You run a reverse proxy (Nginx, HAProxy, or a cloud load balancer) in front of Grafana. Splunk’s backend authenticates the user (via its own session), then makes requests to the proxy with a user identity header (e.g., X-WEBAUTH-USER). The proxy forwards the request to Grafana, which trusts the header because it’s coming from an internal, authenticated source.

Path 3 — API Rendering (KV Store Pattern): Splunk’s backend makes authenticated API calls to Grafana (using a service account token), retrieves the dashboard definition and data, renders it server-side as static HTML/PNG, and stores the rendered output in Splunk’s KV Store. The Splunk UI then displays the cached image. This approach decouples the Splunk and Grafana authentication systems entirely.

Path 4 — SAML/OAuth Bridge: You configure Grafana to trust your enterprise SSO provider (Okta, Azure Entra ID, Keycloak). When users access Splunk, they authenticate against the same SSO provider. Grafana recognizes their identity and grants access accordingly. This is the most “enterprise” pattern but requires dual-provisioning: your SSO provider must know about both Splunk and Grafana users.

Path 5 — Full Migration: You abandon the two-tool model and migrate all metrics and logs to a unified observability platform (e.g., Datadog, New Relic, or a self-hosted ELK+Prometheus stack). This eliminates the embedding problem entirely but is a multi-month project with high switching costs.

Why this matters: Each path trades complexity for security and operational overhead. Paths 1-2 are easy but have authentication limitations. Paths 3-4 are robust but require infrastructure (proxy servers, KV Store, SSO). Path 5 is the “right” answer if you have 18+ months and a dedicated platform team.

Layer 2: Pattern 1 — Iframe Embedding with Anonymous Auth

This is the entry-level integration pattern. It requires no backend code and no proxy infrastructure, but it assumes your dashboards contain non-sensitive data.

What you’re about to see: A two-step sequence. First, Grafana generates an anonymous share token for a dashboard. Second, Splunk embeds the dashboard URL (including the token) in an iframe. The iframe loads directly in the user’s browser.

Step 1: Configure Grafana for Anonymous Access

In Grafana’s admin UI (Home → Admin → Settings → “General” → “Security”), enable anonymous authentication:

[auth.anonymous]
enabled = true
org_role = Viewer

This tells Grafana: “If no authentication token is present, treat the request as an anonymous user with Viewer permissions.” Viewer permissions can read dashboards and panels but cannot modify them.

Next, navigate to the dashboard you want to share. Click the “Share” button (top-right), then select the “Link” tab. Ensure “Share publicly with a link” is enabled. Grafana generates a URL like:

https://grafana.company.com/d/abc123def456?orgId=1

This URL is public-facing—anyone with the URL can view the dashboard if they have network access to Grafana.

Step 2: Embed in Splunk via Custom HTML Panel

In Splunk, create a new dashboard. Add a “HTML” panel and paste:

<iframe
  src="https://grafana.company.com/d/abc123def456?orgId=1&kiosk=tv"
  width="100%"
  height="600px"
  frameborder="0"
  allow="self"
  sandbox="allow-same-origin allow-scripts allow-popups"
></iframe>

Key attributes:
– kiosk=tv: Hides Grafana’s sidebar and top bar, maximizing the dashboard area.
– sandbox="allow-same-origin allow-scripts allow-popups": Restricts the iframe’s capabilities (no localStorage access, no cross-origin requests) but allows scripts and same-origin resource requests.
– allow="self": Permits Grafana to use browser APIs if needed.

Authentication Flow:

User logs into Splunk. Splunk sets a session cookie (splunk_session) in the browser.
Splunk renders the HTML panel with the iframe tag.
Browser navigates to https://grafana.company.com/d/abc123def456?orgId=1.
Grafana receives the request. No authentication cookie is present (different domain), so Grafana treats it as an anonymous Viewer.
Grafana renders the dashboard and returns the HTML.
Browser renders the dashboard inside the iframe.

Trade-offs:

Pros: Simple, no backend code, no reverse proxy needed.
Cons: Dashboards are accessible to anyone with the URL; no integration with Splunk’s user identity; changes to Grafana require manual URL updates in Splunk.

When to use: POC, non-sensitive operational metrics, internal networks only.

Layer 3: Pattern 2 — Reverse Proxy with Header Injection

If you want to tie Grafana access to Splunk user identity without proxy overhead, this pattern is your next step. It requires a reverse proxy (Nginx, HAProxy, or cloud load balancer) positioned between Splunk and Grafana.

What you’re about to see: Three-step authentication handshake. (1) User logs into Splunk. (2) Splunk’s backend makes an authenticated request to the Grafana reverse proxy, injecting a user identity header. (3) The proxy verifies the header’s legitimacy, then forwards the request to Grafana, which trusts the header because it comes from an internal, authenticated source.

Step 1: Configure Grafana to Trust Header-Based Auth

In Grafana’s configuration (/etc/grafana/grafana.ini), enable “Auth Proxy” mode:

[auth.proxy]
enabled = true
header_name = X-WEBAUTH-USER
header_property = email
auto_sign_up = true
sync_ttl = 60

This tells Grafana: “If a request includes the X-WEBAUTH-USER header, treat the header value as the user’s email and automatically create a Grafana user if needed.”

Step 2: Deploy a Reverse Proxy (Nginx Example)

upstream grafana {
    server grafana-internal.company.com:3000;
}

server {
    listen 443 ssl;
    server_name grafana.company.com;

    # SSL certificate configuration (omitted for brevity)

    location / {
        # Verify that the request came from authenticated Splunk
        # (This is pseudo-code; real implementation uses custom auth module or script)
        if ($request_headers != "X-SPLUNK-AUTH-TOKEN: <valid-token>") {
            return 401;
        }

        # Extract Splunk session, verify it, get user identity
        set $splunk_user "unknown";
        # (Real implementation queries Splunk's REST API or Redis cache for session)

        # Inject user identity header and forward to Grafana
        proxy_pass http://grafana;
        proxy_set_header X-WEBAUTH-USER $splunk_user;
        proxy_set_header Host grafana-internal.company.com;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

In practice, you’d use an auth module (e.g., nginx-ingress-controller on Kubernetes, or Nginx’s ngx_http_auth_request_module) to validate the Splunk session before injecting the header.

Step 3: Update Splunk to Route Through the Proxy

Modify the iframe URL to point to the reverse proxy:

<iframe
  src="https://grafana.company.com/d/abc123def456?orgId=1&kiosk=tv"
  width="100%"
  height="600px"
  frameborder="0"
  sandbox="allow-same-origin allow-scripts allow-popups"
></iframe>

The difference is subtle: grafana.company.com now resolves to the reverse proxy’s IP, not Grafana’s internal IP. The proxy intercepts the request, validates the user’s Splunk session, and forwards it with the X-WEBAUTH-USER header.

Authentication Flow:

User logs into Splunk. Splunk sets a session cookie.
Splunk renders the HTML panel with the iframe.
Browser navigates to https://grafana.company.com/d/abc123def456.
Reverse proxy intercepts the request, validates the session cookie, and extracts the user’s email (alice@company.com).
Proxy injects X-WEBAUTH-USER: alice@company.com and forwards to Grafana.
Grafana receives the header, creates or authenticates the user as alice@company.com, and renders the dashboard with user-specific permissions.
Browser renders the dashboard inside the iframe.

Trade-offs:

Pros: User identity is tied to Splunk authentication; Grafana knows who is viewing the dashboard; audit logs can track user activity.
Cons: Requires reverse proxy deployment and maintenance; session validation logic must be custom-coded; if the proxy is compromised, attackers can forge user headers.

When to use: Internal networks, trusted infrastructure team, high-value dashboards.

Security implications: The X-WEBAUTH-USER header is only safe if it comes from a trusted, authenticated source (the reverse proxy). If an attacker could inject the header directly, they could impersonate any user. Mitigation: restrict the source IP of requests containing this header to only the reverse proxy.

Layer 4: Pattern 3 — API Rendering with KV Store

If you need audit trails, version control, or the ability to switch dashboards dynamically, this pattern moves the integration to Splunk’s backend. Splunk fetches dashboard data from Grafana’s REST API and stores it in the KV Store.

What you’re about to see: A four-step pipeline. (1) Splunk backend periodically (or on-demand) authenticates to Grafana using a service account token. (2) Grafana returns the dashboard definition and data as JSON. (3) Splunk renders the dashboard server-side (either as static HTML or a PNG image). (4) Splunk stores the rendered output in the KV Store for fast retrieval and caching.

Step 1: Create a Grafana Service Account

In Grafana (Admin → API Keys), create a new API key with Viewer permissions:

Name: Splunk Integration
Role: Viewer
Expiration: 90 days

Grafana generates a token: eyJrIjoiWW91ckdyYWZhbmFUb2tlbkhlcmUiLCJuIjoiU3BsdW5rSW50ZWdyYXRpb24iLCJpZCI6MX0=

This token grants read-only access to all dashboards and data sources in Grafana.

Step 2: Store the Token in Splunk’s KV Store

Create a KV Store collection to hold Grafana credentials:

[grafana_config]
enforce_HWF = 0

Add an entry:

{
  "_key": "default",
  "grafana_url": "https://grafana.company.com",
  "api_token": "<encrypted-token>",
  "dashboard_id": "abc123def456"
}

Encrypt the token using Splunk’s secret storage (don’t store it in plaintext).

Step 3: Splunk Backend Fetches and Renders

Write a Python script (custom Splunk app or a Splunk add-on) that:

Retrieves the Grafana config from KV Store.
Calls Grafana’s REST API:
bash curl -H "Authorization: Bearer <api_token>" \ "https://grafana.company.com/api/dashboards/uid/abc123"
Parses the dashboard JSON and extracts:
– Panel definitions (queries, visualization type, size, position)
– Data source credentials (if needed)
For each panel, calls Grafana’s rendering API to fetch a PNG:
bash curl -H "Authorization: Bearer <api_token>" \ "https://grafana.company.com/render/d-solo/abc123?panelId=1&width=800&height=400"
Stitches the PNGs together into a single composite image.
Stores the composite image (with timestamp, user ID, dashboard ID) in the KV Store:
json { "_key": "dashboard-abc123-2026-04-17-14-30", "user": "alice@company.com", "dashboard_id": "abc123", "rendered_at": "2026-04-17T14:30:00Z", "image_base64": "iVBORw0KGgoAAAANSUhEUgAA..." }

Step 4: Splunk UI Displays the Cached Image

In Splunk’s HTML panel, embed the cached image:

<img src="/api/storage/collections/data/grafana_rendered/dashboard-abc123-2026-04-17-14-30?output_format=json" />

The user sees a static (or lightly interactive) dashboard image, refreshed every N minutes by the backend script.

Authentication Flow:

User logs into Splunk.
Splunk renders the HTML panel.
(Background) A scheduled Splunk search (running as the admin user or a service account) calls Grafana’s REST API with the service account token.
Grafana returns dashboard data and renders PNGs.
Splunk stores the rendered image in KV Store.
Browser displays the cached image.

Trade-offs:

Pros: User identity is decoupled from Grafana access; dashboards are versioned and audited in Splunk; no CORS issues (all communication is server-to-server); flexible rendering (can store PNGs, JSON, or HTML).
Cons: Higher latency (800ms-2s due to API calls and rendering); requires custom Python/SPL code; KV Store must have sufficient disk space; dashboards are static or semi-interactive (refreshed every N minutes, not real-time).

When to use: High-security environments, audit-heavy industries (finance, healthcare), highly dynamic dashboards, or when Splunk needs to control dashboard versioning.

Layer 5: Pattern 4 — SAML/OAuth Bridge (Enterprise SSO)

If your organization uses enterprise SSO (Okta, Azure Entra ID, Keycloak), you can configure both Splunk and Grafana to trust the same identity provider. This makes user synchronization automatic and keeps authentication state in one place.

High-level flow:

User navigates to Splunk and is redirected to your SSO provider (Okta, Entra ID).
User authenticates (username/password + MFA).
SSO provider issues a SAML assertion or OAuth token.
Splunk and Grafana both validate the token against the SSO provider’s signing keys.
Both systems automatically create users (if auto_sign_up is enabled) and grant permissions.

Grafana configuration (Okta example):

[auth.saml]
enabled = true
assertion_attribute_name = uid
assertion_attribute_login = email
allow_sign_up = true
sso_url = https://company.okta.com/app/amazon_aws/exk1234567/sso/saml
idp_cert = -----BEGIN CERTIFICATE-----...-----END CERTIFICATE-----

Splunk configuration: Splunk has built-in SAML support via the authentication.conf and inputs.conf files.

Trade-offs:

Pros: Seamless user experience; no separate credential management; user attributes (groups, email, department) flow automatically from SSO to both systems; audit trail is centralized.
Cons: Requires SSO infrastructure and SAML/OAuth expertise; if your SSO provider goes down, both Splunk and Grafana become inaccessible; initial setup is complex (certificate exchanges, metadata URLs, attribute mappings).

When to use: Enterprise organizations with mature SSO infrastructure, high user turnover (frequent onboarding/offboarding), or compliance requirements (SOC 2, ISO 27001) that mandate centralized identity management.

Layer 6: The CORS Problem and Solutions

One issue lurks beneath all iframe-based patterns: CORS (Cross-Origin Resource Sharing). When an iframe from splunk.company.com tries to access resources from grafana.company.com, the browser blocks cross-origin requests by default.

What breaks without CORS headers:

JavaScript-to-JavaScript communication (postMessage) between Splunk and the iframe
CSS or fonts loaded from Grafana
API calls made from the iframe to Grafana (e.g., refresh a dashboard query)
Iframe-to-parent communication

How Grafana solves it:

In Grafana’s configuration (grafana.ini), add:

[security]
allow_embed_frames = true
content_security_policy = false  # Only if truly necessary; otherwise use permissive CSP

And configure CORS headers:

[cors]
enabled = true
allow_credentials = true
allow_headers = Content-Type,Authorization,X-Requested-With
allow_methods = GET,HEAD,POST,OPTIONS,PUT,DELETE
allow_origin = https://splunk.company.com
max_age = 600

This tells Grafana: “Allow requests from splunk.company.com to include credentials, and respond with CORS headers permitting the request.”

If you can’t modify Grafana:

Use a reverse proxy to add the headers on Grafana’s behalf:

location / {
    proxy_pass http://grafana-backend;
    add_header 'Access-Control-Allow-Origin' 'https://splunk.company.com' always;
    add_header 'Access-Control-Allow-Credentials' 'true' always;
    add_header 'Access-Control-Allow-Headers' 'Content-Type,Authorization' always;
    add_header 'Access-Control-Allow-Methods' 'GET,HEAD,POST,OPTIONS,PUT,DELETE' always;
}

Layer 7: Real-World Failure Modes and Mitigations

Failure Mode 1: Token Expiration

Problem: The Grafana service account token (used in Pattern 3) expires every 90 days. After expiration, all API calls return 401 Unauthorized, and dashboards no longer render.

Mitigation:
– Store the token in Splunk’s encrypted secret store, not plaintext.
– Schedule a Splunk search to check token expiration and alert the admin.
– Automate token rotation: implement an API call to Grafana to generate a new token every 60 days and update KV Store.

Failure Mode 2: CORS Misconfiguration

Problem: An admin misconfigures CORS, allowing all origins (allow_origin = *). An attacker steals authentication cookies from users visiting a malicious website.

Mitigation:
– Whitelist only known Splunk origins in CORS configuration.
– Use allow_credentials = false if cookies are not needed (sacrificing the ability to use browser-stored auth tokens).
– Implement a Content Security Policy (CSP) header on Splunk’s side to restrict iframe sources.

Failure Mode 3: KV Store Grows Unbounded

Problem: Pattern 3 (API Rendering) stores every rendered dashboard image in KV Store. After a few weeks, KV Store consumes all available disk space.

Mitigation:
– Implement a retention policy: delete rendered images older than 7 days.
– Use external storage (S3, Minio) instead of KV Store for large binary data.
– Cache strategically: only render and store dashboards that are actively viewed.

Failure Mode 4: Authentication Header Injection (Pattern 2)

Problem: A compromised Splunk server (or a malicious admin) injects a fake X-WEBAUTH-USER: admin@company.com header, impersonating the administrator.

Mitigation:
– Configure Grafana’s auth proxy to only trust requests from a specific, hardened reverse proxy (IP whitelist).
– Sign headers with a shared secret: add X-WEBAUTH-SIGNATURE: sha256(X-WEBAUTH-USER + secret) and verify the signature in Grafana.
– Use mutual TLS (mTLS) between the reverse proxy and Grafana to ensure the proxy’s identity.

Failure Mode 5: Latency and Performance

Problem: Pattern 1 (iframe embedding) works fine for one dashboard, but a Splunk view with 10 embedded Grafana dashboards takes 30+ seconds to load (each iframe adds 2-5 second load time).

Mitigation:
– Use lazy-loaded iframes (load only when the user scrolls to them).
– Implement dashboard pre-rendering: render dashboards during off-peak hours and store static images.
– Cache Grafana responses aggressively (set long TTLs on KV Store entries).
– Consider a dedicated observability infrastructure: if you need more than 3-4 embedded dashboards, the overhead suggests you should migrate to a unified platform.

Layer 8: When to Abandon Embedding and Migrate

The patterns above work at scales up to 10-20 embedded dashboards and a few hundred users. Beyond that, the overhead (token rotation, cache invalidation, CORS issues, proxy maintenance) begins to outweigh the benefits.

What you’re about to see: A before-and-after diagram comparing fragmented Splunk-Grafana stacks against unified observability platforms. The diagram surfaces the operational overhead (proxy, token management, KV Store cache invalidation) inherent in the bridge pattern, and shows how unified platforms eliminate that overhead.

What this means: Fragmented stacks require continuous infrastructure maintenance. Unified platforms abstract that complexity and let you focus on instrumentation and analysis. The trade-off is lock-in and migration cost, but if your infrastructure team is spending >30% of its time managing the bridge, that cost is worth paying.

Signs you should migrate to a unified observability platform:

Multiple dashboards per view: You’re regularly adding 5+ Grafana dashboards to Splunk pages. Embedding doesn’t scale gracefully.
Real-time requirements: Users expect sub-second metric updates, but your KV Store cache is stale.
Advanced correlations: You need to correlate metrics and logs in a single query language, not jump between two tools.
Headcount: You have a dedicated observability team (2+ people). They’re spending 30% of their time managing the Splunk-Grafana bridge.
Compliance: Regulatory requirements (SOX, HIPAA, ISO 27001) mandate unified audit logs and user provisioning.

Unified platform alternatives:

Datadog: Logs, metrics, APM, RUM, security in one platform. Cloud-hosted, hands-off operational overhead, premium pricing ($20-40/month per user).
New Relic: Similar to Datadog; strong on APM, excellent performance. Slightly cheaper ($15-30/month per user).
Elastic Stack (ELK + Prometheus): Self-hosted, open-source, full control. Requires 2-3 dedicated engineers for production operations. Good fit if you have infrastructure expertise.
Splunk with Splunk Metrics: Extend your existing Splunk deployment to ingest and visualize metrics natively. No external dashboard tool needed. Higher Splunk licensing costs.
OpenTelemetry + Backend: Standardize on OpenTelemetry SDKs (language-agnostic instrumentation) and send data to a backend of choice (Jaeger, Tempo, Loki, etc.). Maximum flexibility, highest complexity.

Cost-benefit analysis example:

Assume you have 100 users, 15 embedded Grafana dashboards, and 50 GB of metrics data.

Current state (Splunk + Grafana embedding):
– Splunk license: 5 GB data/day × $18/GB/year = $32,850/year
– Grafana Cloud: 50 GB metrics storage + active users = ~$500/month = $6,000/year
– Infrastructure (proxy, KV Store, token management): 0.5 FTE = $60,000/year
– Total: ~$98,850/year

If you migrate to Datadog:
– Datadog: 100 active users × $28/month + logs ($0.10/GB) + metrics ($0.05/GB) ≈ $45,000/year
– Infrastructure (shared Datadog account, no proxy needed): 0.1 FTE = $12,000/year
– Total: ~$57,000/year

The break-even is around 18 months, and you save on engineering overhead immediately.

Conclusion: Decision Framework

Your choice of integration pattern depends on three dimensions:

Data sensitivity: Public dashboards → Pattern 1. Internal dashboards → Pattern 2 or 3. Sensitive metrics → Pattern 3 or 4.
Scale: <5 dashboards → Pattern 1. 5-20 dashboards → Patterns 2-3. >20 dashboards → Pattern 5 (migrate).
Operational maturity: Minimal infrastructure → Pattern 1. Mature infrastructure team, SSO deployed → Pattern 4. Highly mature, high compliance → Pattern 5.

For most organizations starting out, Pattern 2 (Reverse Proxy + Header Injection) is the sweet spot: it ties authentication to Splunk user identity, requires minimal backend code, and leverages infrastructure (reverse proxy) that most organizations already operate.

As requirements grow—more dashboards, audit requirements, or real-time needs—evolve toward Pattern 3 (KV Store Rendering) for added control, or Pattern 4 (SSO Bridge) for enterprise identity.

If you find yourself maintaining more infrastructure for the bridge than for the core observability platforms themselves, that’s a signal: it’s time to migrate to a unified platform.

Embedding Grafana Dashboards in Splunk: Complete Integration Guide

Lede

TL;DR: Pattern Selection Matrix

Terminology Primer: Five Essential Concepts

2. Anonymous Authentication

3. Service Account & API Token

4. Grafana Anonymous Dashboard URL

5. Reverse Proxy (or API Gateway)

Layer 1: Top-Level Integration Taxonomy

Layer 2: Pattern 1 — Iframe Embedding with Anonymous Auth

Layer 3: Pattern 2 — Reverse Proxy with Header Injection

Layer 4: Pattern 3 — API Rendering with KV Store

Layer 5: Pattern 4 — SAML/OAuth Bridge (Enterprise SSO)

Layer 6: The CORS Problem and Solutions

Layer 7: Real-World Failure Modes and Mitigations

Failure Mode 1: Token Expiration

Failure Mode 2: CORS Misconfiguration

Failure Mode 3: KV Store Grows Unbounded

Failure Mode 4: Authentication Header Injection (Pattern 2)

Failure Mode 5: Latency and Performance

Layer 8: When to Abandon Embedding and Migrate

Conclusion: Decision Framework

Further Reading

Related

Comments

Leave a Reply Cancel reply

Tag Cloud

Categories

Lede

TL;DR: Pattern Selection Matrix

Terminology Primer: Five Essential Concepts

1. Cross-Origin Resource Sharing (CORS)

2. Anonymous Authentication

3. Service Account & API Token

4. Grafana Anonymous Dashboard URL

5. Reverse Proxy (or API Gateway)

Layer 1: Top-Level Integration Taxonomy

Layer 2: Pattern 1 — Iframe Embedding with Anonymous Auth

Layer 3: Pattern 2 — Reverse Proxy with Header Injection

Layer 4: Pattern 3 — API Rendering with KV Store

Layer 5: Pattern 4 — SAML/OAuth Bridge (Enterprise SSO)

Layer 6: The CORS Problem and Solutions

Layer 7: Real-World Failure Modes and Mitigations

Failure Mode 1: Token Expiration

Failure Mode 2: CORS Misconfiguration

Failure Mode 3: KV Store Grows Unbounded

Failure Mode 4: Authentication Header Injection (Pattern 2)

Failure Mode 5: Latency and Performance

Layer 8: When to Abandon Embedding and Migrate

Conclusion: Decision Framework

Further Reading

Related

Comments

Leave a Reply Cancel reply