Stop building OpenShift dashboards. We did it for you.
Red Hat OpenShift Logging forwards logs to Splunk and stops there. So does the OpenTelemetry Collector. Collectord ships a complete Splunk app for OpenShift: 50+ dashboards, an Alert Catalog of 117 alert templates, search macros, lookups, and field extractions, built for exactly the data the agent forwards - projects, DeploymentConfigs, BuildConfigs and builds, the control plane, events, security, and the OpenShift audit logs. The dashboards lead you to what needs fixing: the Overview says whether anything is wrong and where, and a click takes you to the cause.
Install in ten minutes. Start investigating in the eleventh.
The gallery follows the app’s own menu. Select a dashboard to see all of it. Dashboards marked OpenShift exist only in the OpenShift app.
Overview
The page the app opens on says whether anything is wrong, where, and who to tell - and every tile and row drills down to the page that shows the cause.
Overview: Workloads
The workloads whose pods need attention right now, then every workload by kind - Deployments, DeploymentConfigs, DaemonSets, StatefulSets, CronJobs, Jobs, ReplicaSets, ReplicationControllers, BuildConfigs and builds - each a click from its Workload page.
Overview: Pods
The pods' current state: pods needing attention, crash loops, restart leaders with their last termination reason, OOM kills, pending pods with the scheduler's own message, and the matching warning events.
Monitoring: nodes, pods, containers, processes
One view per layer of the stack, and the Top pages beside them to find the outliers. A click on a row opens the next layer down with the filters already set.
Node
One node in depth: CPU, memory and pressure, the kernel's view (TCP, connection tracking, open files, clock), the pods and containers on it, and its logs.
Pod
One pod: CPU, throttling, memory, pressure, I/O and network by container, with the pod's conditions, container statuses, events and logs.
Container
One container: CPU, throttling, memory, pressure, I/O and network, next to its processes and its own logs.
Process
One process, in a container or on the node: CPU, threads, memory, I/O, system calls and the files it holds open.
Workload
The pods of one workload side by side, whatever its kind, from a DeploymentConfig to a build: CPU, memory, pressure, I/O and network by pod.
Events
Five views over the OpenShift events. They count how many times a warning fired, not only how many event records there were, and a click on a crash loop, an OOM kill or a probe failure opens that pod’s logs.
Logs
Logs
Container logs with the same cluster, project, node, pod and container filters as the dashboards. Start here, or arrive from a drill-down with the filters already set.
Cluster: capacity, quotas, declarations
Everything about the cluster itself: how much of it is spoken for, what the projects use and declare, and the quotas that cap them.
Resource Quotas
What each project's ResourceQuota allows and how much of it is taken, in every unit Kubernetes writes.
Cluster Resource Quotas OpenShift
ClusterResourceQuotas - one ceiling shared by every project a selector matches - with the projects drawing on each. Collectord watches ClusterResourceQuotas by default on OpenShift.
Cluster › Nodes
GPU Utilization
GPU utilization, memory, power draw and temperature, and the processes using each GPU - for ML and AI workloads. Needs the nvidia-smi DaemonSet on the GPU nodes.
Cluster › System Components
The components that run the cluster, from the metrics Collectord scrapes on the nodes.
Security
What the pods are allowed to do, what they actually hold, who got in, and where the traffic goes.
Access
Who got in: sshd logins and sudo on the nodes, and exec sessions into pods and forbidden requests against the API server.
Audit
Fourteen views over the audit logs of the Kubernetes, OpenShift and OAuth API servers and the OAuth server, grouped the way the menu groups them.
Activity
Who did what: Identities, Service Accounts, Projects, Resource Mutations, and Object Forensics - the full timeline of one object.
Setup and self-monitoring
Configuration
The app's setup page: the events-index or metrics-index dashboards, the switch for the alerts earlier versions shipped, and the macros to tune, each linked to its editor.
Collectord usage
Every Collectord instance with its version and license status, the instances gone silent, and the LicenseID that support asks for.
Collectord metrics
The agent's own health - what it posted, failed requests, retries and delivery lag, its pipelines, and the events it tagged with an error.
Plus an Alert Catalog of 117 alert templates
The app’s alerts come from the Alert Catalog (Setup › Alert Catalog): templates grouped by who acts on them - Splunk admins, the platform team, security, and application teams. Each team picks the ones it needs, scopes them to its own clusters and projects, tunes the thresholds, and creates them, with no SPL to write. Every template that reads stats works on the events index and on a Splunk metrics index.
A sampling of what’s included:
Collectord and data delivery: Collectord stopped reporting, node without a collector, HEC requests failing, delivery lag, license expiring or overused
Control plane: API server, controller manager, scheduler, kubelet or etcd member not reporting, API server 5xx ratio and latency, etcd without a leader, slow WAL fsync, database approaching its quota, CoreDNS panics
Nodes: node not ready or under pressure, CPU and memory above a threshold, memory and I/O stalls, clock not synchronized, conntrack table filling up, kernel OOM killer, a failed systemd unit, runtime disk and persistent volumes filling up
Workloads: pod crash looping, container OOMKilled, image pull failing, pod pending, job failed, CronJob missed its schedule, CPU throttled, resource quota filling up
Security: anonymous API request succeeded, exec into a pod, secret read by a person, RBAC role or binding written by a person, privileged or host-namespace pod created, image from an unapproved registry
Container logs, with no sidecars - one DaemonSet, control-plane nodes included, plus one add-on Deployment
Container, node, process, and network metrics, to a Splunk events index or a metrics index
OpenShift events from the API server
Pods, Nodes, ResourceQuotas and ClusterResourceQuotas watched by default; any other object kind on request
OpenShift API audit logs, read from the control-plane nodes by default; OpenShift writes them out of the box
Control-plane and CoreDNS metrics, scraped by default; optional Prometheus metrics from any pod, via annotations
Optional Nvidia GPU metrics from an nvidia-smi DaemonSet you deploy on the GPU nodes
Install Collectord and the Splunk app once, and every dashboard above lights up with live data, with one exception: GPU Utilization needs the nvidia-smi DaemonSet on the GPU nodes. No per-dashboard configuration, no per-cluster wiring.
Outcold Solutions builds applications for Splunk Enterprise and Splunk Cloud. Our certified monitoring solutions, powered by Collectord, bring logs, metrics and events from Kubernetes, OpenShift and Docker clusters, Linux and macOS hosts, and Windows containers into Splunk, with the dashboards and alerts that help developers watch their applications and operators keep their clusters healthy. Our search apps query Kubernetes and AWS live from the search bar, with nothing to ingest, and OS AI Agent puts the model you choose to work inside Splunk, with each user's own permissions. Since 2017 we have been helping businesses keep what they need to answer complex questions about their infrastructure in one place.
We value your privacy
We use cookies to measure traffic with Google Analytics and to track ad conversions with Google Ads. None of these are required for the site to work. See our Privacy Policy for details.
