Splunk Observability Dashboard Builder
SkillMonitoring & ops"Use when creating, planning, rendering, validating, or applying Splunk Observability Cloud dashboards
Available today. Use it from your connected AI after setup.
No other account needed.
Connect ahel once, and every AI you use reads what you have installed.
Then ask your AI: use the Splunk Observability Dashboard Builder skill
What this skill tells your AI
The instructions your AI receives, as published by chambear2809/splunk-cisco-skills in skills/splunk-observability-dashboard-builder/SKILL.md and read by ahel’s review.
Prerequisites
| Tool or access | Purpose | Verify |
|---|---|---|
| Bash and Python 3 | Run bundled setup and validation helpers | bash --version && python3 --version |
| Required product/platform access | Inspect or configure the selected target | Complete the documented preflight |
| Credential files for live modes | Keep secrets out of chat | Verify paths only |
Workflow Overview
┌───────────┐ ┌───────────────┐ ┌───────────────┐ ┌─────────────────┐
│ Preflight │ → │ Render/review │ → │ Apply/handoff │ → │ Validate evidence │
└───────────┘ └───────────────┘ └───────────────┘ └─────────────────┘
When to Activate
- Creating, planning, rendering, validating, or applying Splunk Observability Cloud dashboards from natural-language dashboard requests, JSON or YAML dashboard specs, SignalFlow chart definitions, or Observability dashboard-as- code.
- Preview and review the splunk observability dashboard builder workflow before any live apply phase.
- Diagnose failed prerequisites, generated assets, configuration, or validation evidence.
Scope
Follow the documented read-only or render-first path whenever it is available. This skill does not imply permission to mutate live systems. Require explicit apply flags, protected credentials, and operator review for state changes.
Examples
Inspect the supported setup modes before selecting one:
bash skills/splunk-observability-dashboard-builder/scripts/setup.sh --help
Expected output: usage, supported modes, and required arguments are displayed without changing the target environment.
Inspect validation modes before running completion checks:
bash skills/splunk-observability-dashboard-builder/scripts/validate.sh --help
Expected output: offline, live, and completion options are displayed when the skill supports them; help exits without mutation.
Troubleshooting
| Issue | Cause | Resolution |
|---|---|---|
| Preflight fails | A required tool or access path is missing | Resolve it before rendering or applying |
| Rendered assets are incomplete | Required non-secret inputs are absent | Complete intake and render again |
| Apply is blocked | Review, credentials, or explicit acceptance is missing | Use the documented handoff |
| Validation is incomplete | Live evidence is unavailable | Record the gap and keep completion open |
Overview
Use this skill to turn a user's natural-language dashboard idea into a reviewed Splunk Observability Cloud dashboard specification, rendered API payloads, and optionally an applied native Observability dashboard.
The default path is classic-api: create custom dashboard groups, charts, and dashboards through the documented /v2/dashboardgroup, /v2/chart, and /v2/dashboard APIs. Modern dashboard features are documented as UI/advisory unless a public API is verified before use.
Safety Rules
- Never ask for Splunk Observability API tokens, org access tokens, session tokens, passwords, or client secrets in conversation.
- Never pass tokens on the command line or as environment-variable prefixes.
- Require
--token-filefor live API operations. - Reject direct token flags such as
--token,--access-token,--api-token,--o11y-token, and--sf-token. - Prefer
SPLUNK_O11Y_REALMandSPLUNK_O11Y_TOKEN_FILEfrom the repocredentialsfile when present; these store only the realm and token-file path, not the token value. - Render and validate before apply. Apply only when the user explicitly requests it.
- Create new custom dashboards by default. Use
--update-existingonly when the user explicitly asks and the spec includes existing dashboard/chart IDs.
Primary Workflow
-
Interpret the request:
- Identify audience, decision workflow, services or infrastructure scope, time range, dashboard group, filters, and desired visuals.
- Ask only for missing non-secret values: realm, dashboard group name or ID, service/environment/cluster names, preferred dimensions, and target time range.
- For vague requests, produce a starter dashboard and mark assumptions in the spec comments or final explanation.
-
Ground the dashboard in live metadata when possible:
- Use
scripts/setup.sh --discover-metrics --realm <realm> --token-file <file> --query <term>to discover metric names. Omit realm/token flags whenSPLUNK_O11Y_REALMandSPLUNK_O11Y_TOKEN_FILEare configured incredentials. Simple bare terms such aslatencyare converted tosf_metric:*latency*. - Use metric and dimension names returned by the API instead of inventing names.
- If live metadata is unavailable, render a reviewable draft and clearly mark metric names as assumptions.
- Use
-
Write or update a JSON or YAML spec:
- Start from
templates/dashboard.example.jsonfor a dependency-free example, ortemplates/dashboard.example.yamlwhen PyYAML is installed. - Keep
mode: classic-apifor renderable native Observability dashboards. - Use
mode: modern-ui-advisoryormode: dashboard-studio-advisoryonly to document UI/manual work.
- Start from
-
Validate and render:
bash skills/splunk-observability-dashboard-builder/scripts/setup.sh \ --render \ --spec skills/splunk-observability-dashboard-builder/templates/dashboard.example.json \ --output-dir splunk-observability-dashboard-rendered -
Review the rendered plan:
metadata.jsonsummarizes coverage, assumptions, and warnings.charts/*.jsoncontains chart API payloads.dashboard.jsoncontains the dashboard API payload with chart placeholders.apply-plan.jsonrecords the creation sequence without secrets.
-
Apply only when explicitly requested:
bash skills/splunk-observability-dashboard-builder/scripts/setup.sh \ --apply \ --spec my-dashboard.json \ --realm us0 \ --token-file /tmp/splunk_o11y_api_tokenBy default,
--applycreates new dashboard groups, charts, and dashboards. Use--update-existingonly with explicit existing object IDs in the spec; the apply client fetches the current objects before PUT so omitted writable fields are preserved where the API returns them.--dry-runis non-destructive and skips both the API calls and the readable-token-file requirement, so CI preview-only jobs do not need a real token path on disk. Live--applyretries 429/502/503/504 automatically with exponential backoff (cap: 4 attempts; honorsRetry-Afterwhen present). -
Clean up validation smoke dashboards when needed:
bash skills/splunk-observability-dashboard-builder/scripts/setup.sh \ --cleanup \ --apply-result splunk-observability-dashboard-rendered/apply-result.jsonCleanup is intentionally guarded to rendered plans whose dashboard group and dashboard names start with
codex_live_validation. Use the Observability UI or API directly for non-validation dashboards.
Coverage Rules
- Fully renderable through classic-api: custom dashboard groups, custom dashboards, TimeSeriesChart, SingleValue, List, TableChart, Heatmap, Text charts, event overlays, dashboard filters/variables, chart time ranges, units, legends, thresholds, and detector links represented by chart properties.
- Documented but not currently API-rendered by this skill: pie/donut charts and event feed charts. Current product docs list them, but this renderer needs a verified classic
/v2/chartschema before applying them. Usemodern-ui-advisoryor Text/link notes for now. - Metric-derived coverage: Infrastructure Monitoring, Kubernetes/cloud infrastructure, Database Monitoring, APM service RED metrics, RUM Browser/Mobile metrics, Synthetic Monitoring metrics, Log Observer Connect metrics/log links, custom business metrics, AI Infrastructure Monitoring, and AI Agent/APM metrics when the required metrics are present.
- Advisory/link-only coverage: trace waterfalls, RUM sessions and session replay, synthetic waterfall detail, database explain plans, alerts/detector management, On-Call workflows, Observability Cloud for Mobile app workflows, product-native navigators, modern dashboard sections/subsections, service maps, and modern logs charts. Do not claim API rendering for these without verifying a public API first.
- Dashboard Studio: keep as a secondary path. It has Splunk platform version, realm, capability, trial, Unified Identity, and import limitations. Do not mix it into the native Observability apply path.
Read references/coverage.md for the full product coverage matrix and references/classic-api.md for API field guidance.
YAML specs require PyYAML in the Python interpreter used by scripts/setup.sh. Install repo dependencies with python3 -m pip install -r requirements-agent.txt, or use JSON specs.
Spec Guidance
- Prefer one dashboard per operational question. Put broad estate overviews and incident drilldowns in separate dashboards.
- Use dashboard variables for common drilldowns such as
sf_environment,service.name,k8s.cluster.name,k8s.namespace.name,host.name,cloud.region, anddeployment.environment. - Choose chart types intentionally:
- TimeSeriesChart for trends, rates, latency, throughput, saturation.
- SingleValue for current health, active alerts, SLO/error-budget snapshots, latest values.
- List or TableChart for top-N entities and inventory/status summaries.
- Heatmap for distributions and dense population comparisons.
- Text for operator notes, runbook links, and assumptions.
- Use
modern-ui-advisoryfor pie/donut, event feed, logs, service map, section/tab, or other modern-only visualizations until the public API schema is verified. - Every non-text chart must include SignalFlow with at least one
publish()output. - Keep layouts within a 12-column grid. The validator rejects collisions and out-of-range chart positions.
Update Existing Objects
For existing charts or dashboards, use --update-existing with fetch-modify-PUT semantics:
- Add
dashboard.idand each chart'schart_idto the spec. - Render and review the plan.
- Apply with
--apply --update-existing.
Do not create partial PUT payloads. The Observability chart API can null or remove writable properties omitted from updates.
Scripts
scripts/setup.sh- shell entrypoint for render, validate, discover, apply, and guarded cleanup.scripts/render_dashboard.py- validates specs and renders classic API payloads.scripts/validate_dashboard.py- static validation for specs or rendered payloads.scripts/o11y_dashboard_api.py- live API client using token files only.
Useful Commands
Validate a draft spec:
bash skills/splunk-observability-dashboard-builder/scripts/setup.sh \
--validate \
--spec skills/splunk-observability-dashboard-builder/templates/dashboard.example.json
Render without applying:
bash skills/splunk-observability-dashboard-builder/scripts/setup.sh \
--render \
--spec skills/splunk-observability-dashboard-builder/templates/dashboard.example.json \
--output-dir splunk-observability-dashboard-rendered
Discover metrics before writing SignalFlow:
bash skills/splunk-observability-dashboard-builder/scripts/setup.sh \
--discover-metrics \
--query latency
Signals
- GitHub stars
- 37
- Forks
- 8
- Last commit
- Sep 2026
Advanced
- Catalog kind
- skill
- Gateway key
splunk-observability-dashboard-builder- Source
- github.com/chambear2809/splunk-cisco-skills