사용 방법
- 설치 명령을 복사하고 자신의 에이전트 환경에 설치하기 전에 소스 패키지를 확인하세요.
- 필요한 도구, 인증 정보, 지원 환경은 원본 문서에서 확인하세요.
- 입력과 원하는 산출물을 설명하고 출처와 결과를 대조하세요.
npx skills add https://github.com/bagelhole/devops-security-agent-skills --skill sre-dashboards시작 전 확인
- 설치에는 모델 구독, API 한도, 파일 접근 권한이 포함되지 않습니다.
- 별점 수와 설치 수는 활동 지표이며 독립적인 품질·보안 검증이 아닙니다.
원본 Skill 문서
원본 저장소의 제목, 예시, 코드, 표, 링크, 이미지를 유지해 표시합니다.
SRE Dashboards
Build dashboards that help teams detect, triage, and prevent reliability incidents.
When to Use This Skill
Use this skill when:
- Defining service-level dashboards for production systems
- Tracking SLO health and error-budget burn
- Creating incident command-center views
- Standardizing dashboard patterns across teams
Prerequisites
- Metrics pipeline (Prometheus, OpenTelemetry, or vendor equivalent)
- Logs/traces linked to services and environments
- Agreed service taxonomy (team, service, tier, environment)
Dashboard Architecture
Structure dashboards in layers:
- Executive Reliability View: SLO attainment, incident counts, MTTR trends.
- Service Health View: RED/USE metrics, dependency health, release markers.
- Deep-Dive View: Per-endpoint latency, resource saturation, error categories.
Keep each view answer-oriented:
- Are customers impacted?
- What changed?
- Where is the bottleneck?
Core SRE Panels
Golden Signals
- Latency: p50/p95/p99 request duration by endpoint
- Traffic: request throughput and queue depth
- Errors: 5xx rate, failed jobs, timeout ratio
- Saturation: CPU, memory, disk I/O, thread/connection pool exhaustion
SLO Panels
- Current SLI value (rolling windows: 5m, 1h, 24h, 30d)
- Error-budget remaining (%)
- Burn-rate panels (fast and slow windows)
- Multi-window burn alert status
Change Correlation
- Deployment markers and config-change annotations
- Feature flag state overlays
- Upstream/downstream dependency error rates
Example PromQL Snippets
promql
# API error rate (%)
100 * sum(rate(http_requests_total{status=~"5.."}[5m]))
/ sum(rate(http_requests_total[5m]))promql
# p95 latency by route
histogram_quantile(0.95,
sum by (le, route) (rate(http_request_duration_seconds_bucket[5m]))
)promql
# Fast burn rate (5m / 1h)
(
sum(rate(http_requests_total{status=~"5.."}[5m]))
/ sum(rate(http_requests_total[5m]))
)
/
(
sum(rate(http_requests_total{status=~"5.."}[1h]))
/ sum(rate(http_requests_total[1h]))
)Operational Guidelines
- Use consistent color semantics (green=healthy, yellow=degrading, red=breach)
- Label units explicitly (ms, req/s, %, cores)
- Default time windows to incident-friendly ranges (15m, 1h, 6h, 24h)
- Minimize panel count per dashboard to reduce cognitive load
- Add runbook links directly in panel descriptions
Troubleshooting
Panel appears flat or empty
- Verify label cardinality and filters (
service,env,region) - Confirm scrape/ingest latency is within expected range
- Check metric rename regressions after instrumentation updates
High cardinality slows dashboards
- Aggregate by stable dimensions (
service,route_group) instead of raw IDs - Use recording rules for expensive percentile and ratio queries
- Split deep-dive dashboards from NOC summary dashboards
Related Skills
- prometheus-grafana - Dashboard implementation and PromQL
- opentelemetry - Standardized telemetry instrumentation
- alerting-oncall - Reliability alert routing and escalation
- agent-observability - AI workload reliability telemetry
