Taming telemetry: simplifying governance for the modern operator using SmartHub, Octant, and Argo CD.
There is nothing simple about modern telemetry. Today's infrastructure forces organizations to manage a tangled web of vendor agents, OpenTelemetry Collectors scattered across Kubernetes clusters, disconnected data pipelines, and multiple observability backends. Telemetry policies rarely scale cleanly from development to production. Platform teams maintain the collectors, FinOps demands cost control, and developers require maximum visibility. The core problem? It almost always falls on the DevOps engineer to force these isolated, competing priorities into a single, functional workflow.
Consider what should be a straightforward policy decision: retain 25% of routine logs and 10% of routine traces, but preserve every error.
Without a unified operating model, a simple request triggers a cascade of manual toil. The operator is forced to hunt down relevant collectors, reconfigure OpenTelemetry processors, update disparate Kubernetes manifests, promote changes across environments, and constantly watch for configuration drift. They are no longer managing telemetry — they are simply playing catch-up across disconnected infrastructure.
MyDecisive unifies these fragmented systems, allowing operators to dictate the outcome instead of wrestling with the underlying plumbing.
One operator, five coordinated planes
Under the hood, the MyDecisive architecture separates distinct responsibilities across several purpose-built planes. But for the operator, this complexity is entirely abstracted away behind a single, unified workflow.
Figure 1 — Control flow across the planes. Solid lines carry intent downward; dashed lines return state to Octant.
- Octant (governance and control) — This is the front door to the platform. Octant is where the operator discovers, configures, deploys, and monitors solutions in terms of outcomes rather than raw infrastructure.
- GitHub (source of truth) — Stores the approved desired state, including which solutions are installed, log and trace ratios, error-persistence settings, and the history of each change.
- Argo CD (deployment plane) — Governs how an approved solution is distributed and maintained across Kubernetes environments, handling deployment, sync, drift detection, and reconciliation.
- MyDecisive SmartHub (stateful stream processing) — Owns the policy controlling how telemetry behaves. It translates operator-level decisions into runtime values that managed collectors consume.
- Agents and Collectors (data plane) — Originate actual logs, metrics, and traces. They apply basic and static rules and power the OpenTelemetry protocol generation and primitives of data movement.
A simple workflow built on a well-defined architecture
The underlying architecture spans multiple technologies, but the operator workflow remains singular. The complexity hasn't disappeared; it is simply abstracted into a reusable, governed solution. You just install Octant, configure your policy, and let Argo CD handle the deployment.
Figure 2 — One policy change, end to end. Fourteen steps the operator never has to sequence by hand.
Deployment health is not telemetry health
The solution also includes a TelemetryValidation resource. This is critical because an Argo CD Application can be synchronized while the actual telemetry path is misconfigured. A green Kubernetes deployment is not enough; the operator needs evidence that telemetry is actually flowing.
A streamlined operator experience
OpenTelemetry would usually require definition and configuration — and subsequent maintenance — of many pipelines and parameters across collectors and teams. If the goal is to deliver a global sampling level for all logs and traces, this is much harder to achieve in practice than in concept. Octant streamlines this iterative process, enabling operators to modify policies dynamically without the overhead of rebuilding the underlying pipeline.
Figure 3 — Tuning toward a target. Four phases, each with something specific to watch.
Centralized governance does not require identical behavior everywhere. The same solution can run with different policy values across environments.
| Environment | Log ratio | Trace ratio | Preserve errors | Typical objective |
|---|---|---|---|---|
| Development | 100% | 100% | Yes | Maximum debugging visibility |
| Staging | 50% | 50% | Yes | Validate behavior and estimate reduction |
| Production | 25% | 10% | Yes | Control routine volume while retaining failures |
Octant gives the operator one interface for the entire lifecycle. It provides one authoritative system for defining, reviewing, distributing, and observing the differences.
Figure 4 — One solution definition, fanned out to three environments by Argo CD.
GitHub records the differences, Argo CD governs where each policy runs, the open-source SmartHub distributes the values, and collectors enforce them locally.
Operator-friendly, organizationally governed
Simplicity should not mean bypassing governance. Octant simplifies the experience while preserving the controls technical organizations depend on. The operator receives a catalog of ready-to-use solutions and guided configuration. Meanwhile, the organization retains Git as the source of truth, pull-request reviews, drift detection, and Kubernetes-native deployments.
| The operator receives | The organization retains |
|---|---|
| A catalog of ready-to-use solutions | Git as the source of truth |
| Guided configuration | Pull-request review |
| Meaningful policy inputs | Version history |
| Environment selection | Argo CD governance |
| Deployment status | Environment boundaries |
| Measured outcomes | Kubernetes-native deployment |
| OpenTelemetry-native processing | |
| Drift detection | |
| Reconciliation | |
| On-premises runtime enforcement |
Owning the installation path comes with a clear product responsibility: we ensure explicit compatibility. Octant delivers this by selecting tested defaults, managing supported upgrades, and surfacing version warnings.
Scale the fleet without the operational burden
As your organization grows, you will add more services, clusters, and telemetry volume. Without a common operating model, every addition creates another configuration surface.
With MyDecisive the number of telemetry pipelines may grow, but the number of ways in which operators manage them should not:
- Octant — provides one management interface
- Solutions — package repeatable telemetry behavior
- GitHub — records approved intent
- Argo CD — governs distribution and drift
- SmartHubs — enforce policy locally
- Collectors — continue to scale with the data plane
- Observers — measure the outcome
- Validation — confirms the path is working
Manage outcomes, not machinery
Managing telemetry should not require manually operating five disconnected systems. The operator uses Octant to manage a solution, GitHub records its desired state, Argo CD governs its deployment, the SmartHub supplies its runtime policy, and distributed collectors enforce it where the telemetry flows.
Try it
Curiosity in this case will lead to enlightenment. Grab the Clarity applet and Octant and let us show you what we can do — you could be sampling logs and traces with total centralized governance and control in minutes.
Join our Slack community, ask questions, and vote for more posts like this one. We can walk you through building your own pipelines and applets in MyDecisive. We are, after all, open source.
