agentsclimarketplace

Infrastructure monitoring

Skill Amey-Thakur/AI-SKILLS/skills/devops/infrastructure-monitoring

Plug-and-play skills and prompts for every AI coding agent

Install
npx -y skills add Amey-Thakur/AI-SKILLS --skill infrastructure-monitoring

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 19 days oldThe repository was created 19 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • 4 stars4 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Monitor systems with the golden signals and USE method, alerts that page only on user impact, and runbook-linked responses. Use when instrumenting infrastructure or fixing alert fatigue.

SKILL.md

3.4 KB, as published. Nobody here has run it

Infrastructure monitoring

Monitoring exists to answer two questions fast: is the user affected, and where is the problem. Instrument for those, alert only on the first, and every page carries a link to what to do next: anything else is dashboards nobody reads and alarms everybody mutes.

Method

  1. Instrument the golden signals per service. Latency (distributions, not averages: p50/p95/p99), traffic (request rate), errors (rate and type), saturation (how full the constrained resource is): these four catch most user-facing problems and localize them (see observability, distributed-tracing for the request-level layer). Complement with the USE method for resources (Utilization, Saturation, Errors per CPU/disk/network: the systems-profiling view at fleet scale).
  2. Separate metrics, logs, and traces by job. Metrics for trends and alerting (cheap, aggregatable); logs for detail and forensics (structured: see structured-logging, log-analysis); traces for request flow across services (see distributed-tracing): correlated by shared IDs so an alert links to the traces links to the logs. Three pillars, one correlation key.
  3. Alert only on symptoms users feel. Page on: SLO breach (error rate, latency past target), not on every CPU spike or single-host blip (see alerting-design's discipline). Cause-based alerts (disk 80% full) are tickets or auto-remediation, not pages; a pager that fires on non-impacting conditions trains responders to ignore it, and the real one arrives muted.
  4. Set thresholds from SLOs and error budgets. Define the service level objective (99.9% of requests under 300ms), derive the alerting from budget burn rate (fast burn pages, slow burn tickets: see error-budget-policy), and review against actual variance and seasonality (weekends are not incidents). Static thresholds copied from a blog rot into noise.
  5. Link every alert to a runbook. The page includes: what broke, the dashboard, and the first diagnostic steps (see runbook-writing); a responder woken at 3am should not also have to remember the architecture. This single practice cuts mean-time-to-resolve more than any dashboard redesign.
  6. Dashboard for the question, not the metric dump. One overview per service answering "is it healthy" (the golden signals), drill-downs for diagnosis; deployment and config-change markers overlaid so "what changed" is visible (most incidents are a recent change: see rollback-strategy); reviewed in operations forums with actions attached (see dashboard-design, product-metrics' decide-don't-decorate rule).

Boundaries

  • Monitoring is knowns-focused; unknown-unknowns need observability's ad-hoc query power (high-cardinality traces and logs you can slice by any dimension after the fact: see observability).
  • Alert coverage has diminishing returns and a fatigue cost; fewer, higher-quality pages beat exhaustive ones (see alerting-design). Prune alerts that never actioned.
  • Business-metric monitoring (conversion, revenue: see product-metrics) is a related but separate system with different owners; infra-green while business-red is a real and dangerous state to design for.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.