Notifications
Clear all
Topic starter
08/06/2026 5:00 pm
TL;DR: Metrics, logs, and traces together improve system visibility, but each pillar breaks down under microservices sprawl, high-cardinality data, and sampling limits, according to StrongDM. For IAM and NHI teams, the real lesson is that observability data is only useful when identity and access events are centralized enough to explain who touched what, when, and through which path.
NHIMG editorial — based on content published by StrongDM: Three Pillars of Observability Explained: Metrics, Logs, Traces
Questions worth separating out
A: Security teams should use metrics to detect anomalies, logs to reconstruct the identity trail, and traces to understand request flow across services.
Q: Why do metrics, logs, and traces still fail to give full visibility?
A: They fail when teams treat them as a checklist instead of a governance layer.
Q: What do organisations get wrong about observability in microservices?
A: They often assume more data automatically means better insight.
Practitioner guidance
- Map identity context into telemetry pipelines Add service account, workload, and operator identifiers to logs and traces so access events can be correlated across microservices without manual reconstruction.
- Centralize log aggregation and normalization Standardize event formats before they enter the SIEM or observability stack, then preserve timestamps, request IDs, and privilege context for investigation.
- Use metrics for detection, not proof Treat metrics as anomaly indicators and require logs or traces to confirm the identity path behind any access or performance issue.
What's in the full article
StrongDM's full article covers the operational detail this post intentionally leaves for the source:
- Side-by-side explanation of how metrics, logs, and traces differ in storage, query patterns, and troubleshooting use cases
- Practical examples of observability dashboards and trace views for microservices-heavy environments
- Detailed discussion of the performance and cost tradeoffs that come with high-cardinality metrics and trace sampling
- Guidance on how StrongDM positions observability alongside access management across databases, servers, and clusters
👉 Read StrongDM’s guide to metrics, logs, and traces in observability →
Metrics, logs, and traces: what IAM teams miss in distributed access?
Explore further
08/06/2026 6:57 pm
Observability is now an identity problem, not just a telemetry problem. In distributed environments, the question is no longer whether systems emit data, but whether that data can explain access and privilege movement across services. Metrics, logs, and traces each illuminate part of the path, yet none of them is a governance model. For IAM and NHI programmes, this means observability should be treated as evidence of control coverage, not as a substitute for it. The practical conclusion is that identity context must be built into telemetry from the start.
A few things that frame the scale:
- 97% of NHIs carry excessive privileges, increasing unauthorised access and broadening the attack surface, according to Ultimate Guide to NHIs.
- Only 5.7% of organisations have full visibility into their service accounts, which means most teams cannot reliably correlate access events with identity ownership.
A question worth separating out:
Q: How can teams tell whether observability is actually working?
A: Observability is working when a team can move from an alert to the exact request path, identity, and service dependency that caused it. If the answer still requires searching multiple tools, manually matching timestamps, or guessing which account acted, the organisation has monitoring data but not usable observability.
👉 Read our full editorial: Observability’s three pillars expose access gaps in distributed systems
