Infrastructure Observability: Hosts, Kubernetes, Cloud and Extensions
Infrastructure Observability tests how hosts, processes, Kubernetes objects, cloud services and remote devices are brought into the same topology, and which component is responsible for each data type.
Host and process coverage
- OneAgent full-stack mode gives deep process and code monitoring; infrastructure-only mode (no code modules) gives host and process metrics without deep tracing. Choosing the wrong mode is a common cause of missing service data.
- Host groups are tags set at install time and reused for configuration scoping, network zones and management zones. Retro-fitting host groups to an existing estate is painful, so questions often probe naming discipline.
- Process availability, CPU, memory, disk and network saturation are monitored; anomaly detectors learn baselines while static thresholds handle signals Davis cannot baseline.
Cloud, Kubernetes and remote sources
- Cloud integrations poll provider APIs (AWS, Azure, GCP) with role-based access to bring service metrics, tags and configuration into topology.
- Kubernetes monitoring uses the Dynatrace Operator in cloud-native full-stack or application-only mode, yielding pods, workloads, Kubernetes events and control-plane metrics alongside OneAgent data.
- Extensions 2.0 collect remote metrics over JMX, SNMP, Prometheus endpoints, SQL and WMI, executed through ActiveGate. Network devices are monitored as SNMP extensions.
- ActiveGate roles include routing and API traffic, private synthetic locations, and data-privacy (local obfuscation) processing, plus network zone control and mainframe coverage.
Worked example
A Kubernetes node reports high CPU while application pods stay within their limits. Check pod requests versus limits and throttling counters: the node is consumed by non-application workloads, so pods are throttled by contention rather than by their own demand. Reasoning: node saturation is not pod saturation; look at scheduling headroom and node-level consumers before resizing application containers.
Traps that cost marks
- Installing a OneAgent per pod instead of using the Operator.
- Assuming cloud API-polled metrics are real-time; polling intervals lag.
- Confusing extension metrics (remote) with OneAgent code-module instrumentation (in-process).
- Leaving network zones misconfigured so ActiveGate routing breaks in segmented networks.