用 Codex 或 Claude 帮你安装 复制这段 Prompt,粘贴到 Codex、Claude 或其他助手里,让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt;运行前请先检查来源。
npx skills add https://github.com/mikailustuner/OmniRule --skill monitoring-patterns命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地?可下载 SkillsMP 当前能够提供的文件。
Bun runtime: HTTP server, file I/O, SQLite, test runner, package manager, bundler — all-in-one JS toolchain.
Clerk: Drop-in auth UI, Organizations, User management, JWT templates, webhooks, Next.js middleware integration.
Gelişmiş masaüstü, tarayıcı ve işletim sistemi kontrol yeteneği. Görsel (koordinat tabanlı) fare/klavye otomasyonu, DOM manipülasyonu, pencere yönetimi, gelişmiş dosya, ağ ve süreç yönetimini kapsar.
基于 SOC 职业分类
正在显示 SKILL.md
| name | monitoring-patterns |
| description | Monitoring: Metrics collection, alerting strategy, observability, and uptime tracking. |
| triggers | {"keywords":["metrics","Prometheus","Grafana","alert","observability","APM","Sentry","Datadog","uptime"]} |
| auto_load_when | Setting up monitoring or alerting |
| agent | devops-engineer |
| tools | ["Read","Write","Bash"] |
Focus: System health, performance tracking, alerting philosophy
What to monitor (USE method):
├── Utilization
│ ├── CPU, memory, disk usage
│ ├── Network bandwidth
│ └── Queue depths
│
├── Saturation
│ ├── How "full" resources are
│ ├── Request queue length
│ └── Connection pool usage
│
└── Errors
├── Error rate (errors per second)
├── HTTP 5xx ratio
└── Exception count
Alternative approach (RED method):
├── Rate: requests per second
├── Errors: failed requests per second
└── Duration: latency distribution
When to create an alert:
├── Actionable
│ └── Can someone do something about it?
│ └── Alert fatigue comes from non-actionable alerts
│
├── Urgent
│ └── Does it need immediate attention?
│ └── Business impact: revenue, user experience
│
└── Observable
└── Can you debug from the alert data?
└── Include context: service, error, timeline
Alert severity levels:
├── Critical (P1)
│ └── Immediate: phone call, SMS
│ └── Example: service down, data loss
│ └── SLA: respond in 15 minutes
│
├── Warning (P2)
│ └── Prompt: email, Slack
│ └── Example: high error rate, degraded performance
│ └── SLA: respond in 1 hour
│
├── Info (P3)
│ └── Dashboard only
│ └── Example: usage trends, capacity planning
│ └── SLA: respond in 24 hours
Three pillars (when to focus on each):
├── Logs
│ └── Use when: debugging specific requests
│ └── Store: structured, searchable format
│ └── Include: correlation IDs, timestamps
│
├── Metrics
│ └── Use when: trends over time, dashboards
│ └── Store: time-series database
│ └── Include: aggregations, percentiles
│
└── Traces
└── Use when: distributed systems debugging
└── Store: trace storage (Jaeger, Zipkin)
└── Include: spans, timing, service map
Check types:
├── Liveness
│ └── Purpose: is process running?
│ └── Implementation: simple /health endpoint
│ └── Failure: restart container/pod
│
├── Readiness
│ └── Purpose: can handle requests?
│ └── Check: DB connection, downstream APIs
│ └── Failure: remove from load balancer
│
└── Startup
└── Purpose: ready to receive traffic?
└── Check: initialization complete
└── Failure: timeout and restart
❌ Alert on every error — alert fatigue kills response
✅ Alert only on symptoms that affect users (SLO breach)
❌ Logs with no structure (free-text printf)
✅ Structured JSON logs with trace_id, user_id, severity
❌ Single dashboard with 50 panels nobody reads
✅ Service-level dashboards: one golden signals view per service
❌ No runbook linked to alert
✅ Every alert links to a runbook with diagnosis steps
❌ Monitoring added after incidents
✅ Define SLOs and add observability in the same PR as the feature
| Signal | Tool | Alert threshold |
|---|---|---|
| Latency | Histogram p95/p99 | > SLO threshold |
| Error rate | Counter / rate() | > 1% (5xx) |
| Saturation | CPU/memory gauge | > 80% sustained |
| Availability | Synthetic probe | < 99.9% (30d) |
| Business KPI | Custom counter | Domain-defined |
| Traces | Span duration | Outlier detection |