SRE Tools

A practical tour of the SRE/observability tool stack: what each tool is best at, where each one falls short, and how responders typically use them during troubleshooting.

2023 vintage session with 2026 tooling updates. Kibana and AppDynamics references have been replaced with Dynatrace guidance in this document. Keep process heuristics and validate current team conventions with SRE.

SRE Tools Recording

TL;DR: Which Tool to Use When

Tool Best For Worst For Login

Kubernetes Dashboard

Kubernetes-level issues (init containers, scaling, nodes, volumes)

Deep log analysis/search

Admin IDP

Spring Boot Admin

Fast service-status wallboard for Spring apps (health, memory, threads)

Non-Spring services

Admin IDP

Kiali

Istio mesh traffic mapping and inter-service flow debugging

Anything outside the mesh

Admin IDP

Grafana

High-resolution metrics dashboards and Prometheus-backed analysis

Teams/services without mature custom dashboards

Grafana login (role-based)

Dynatrace (Logs)

Centralized log search and correlation by service, pod, and trace context

Kubernetes object lifecycle troubleshooting (deployments, volumes, node state)

SSO - MAD (Microsoft Active Directory)

Dynatrace (APM/Traces)

Cross-service dependency tracing, latency/root-cause analysis, and service flow visibility

Deep Kubernetes manifest/config inspection and mesh-specific topology debugging

SSO - MAD (Microsoft Active Directory)

Tool-by-Tool Notes

Kubernetes Dashboard

Most general-purpose infrastructure view and broadly available across environments.

Strong at:

  • deployment/replica/pod state

  • CPU and memory signals

  • health and scaling context

  • node/volume-level questions

Weak at:

  • logs (short window, limited search/filter ergonomics)

Everything visible here is also available via Kubernetes APIs and kubectl.

Spring Boot Admin

Best as a status-at-a-glance board for Spring-based services.

Useful for:

  • high-level service health

  • thread/memory/health endpoint drill-down

  • quick "is this service generally healthy?" checks

Limitations:

  • non-Spring services are not represented

  • gateway/Go/non-standard services may not appear

  • health semantics may differ from Kubernetes readiness/liveness views

Kiali

Istio mesh UI focused on service-to-service traffic understanding.

Typical workflow:

  1. open services view in namespace

  2. inspect service overview

  3. follow traffic graph edge coloring for error hotspots

  4. drill into traffic/metrics/traces tabs

Best when the core question is "which side of this interaction is failing?"

Limitation: visibility is constrained to meshed traffic.

Grafana

High-resolution metric analysis backed by Prometheus.

Key strengths:

  • detailed deployment/pod/container performance timelines

  • flexible filtering by namespace/deployment/pod

  • better temporal precision than many built-in dashboards

Common caveat: custom dashboard coverage can vary by service/team maturity.

Access is role-gated and may require onboarding ticketing.

Dynatrace

Dynatrace is now the primary platform for both logs and APM/tracing workflows previously split across Kibana and AppDynamics.

Strongest for:

  • centralized log search and filtering (service, pod, environment, trace context)

  • distributed tracing and service-flow analysis

  • cross-system dependency and latency investigation (DB, IAM, external services)

  • pivoting between logs, metrics, and traces in one tool during incident triage

Limitations:

  • not a replacement for Kubernetes object/state inspection (use Kubernetes Dashboard / kubectl for that)

  • mesh-specific traffic topology questions are still often clearer in Kiali

  • broad, unscoped log queries can still produce noisy result sets

Practical usage rule:

  • Start with scoped filters (service + environment + time window), then drill down by trace/request context.

Access Model and Login Patterns

At recording time:

  • Most internal tools: Admin IDP

  • Grafana: separate login page but same identity backend with role checks

  • Dynatrace: SSO - MAD (Microsoft Active Directory), with role-based access controls

Access provisioning was ticket-driven and could take time; responders were encouraged to verify access before incidents.

Troubleshooting Heuristics

Highest-leverage guidance from the session:

  • Know the first-choice tool for each problem shape.

  • Practice in lower-risk environments before incident pressure.

  • Use tool strengths deliberately rather than forcing one tool for everything.

  • Escalate to team channels for deep-dive help; these are third-party systems with external docs.

Why This is in the Knowledge Base

This session remains the clearest role-based map of tool selection during troubleshooting: which tool answers which class of question, and how to avoid common dead ends during incident analysis. Even as specific platforms evolve, the troubleshooting heuristics remain durable and useful for onboarding and incident readiness.