agentsclimarketplace

Observability

Skill Amey-Thakur/AI-SKILLS/skills/debugging/observability

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

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

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

Instrument software so production questions get answered from signals, not guesses. Use when adding logging, metrics, tracing, or alerts, or when a system is hard to debug in production.

SKILL.md

2.6 KB, as published. Nobody here has run it

Observability

The test of instrumentation is a question: when this misbehaves at 3 a.m., can the person on call find out what and why without adding new code? Build toward answering that, not toward volume.

Method

  1. Log events, with context, structured. Each log line is a fact with the fields needed to act on it: timestamp, level, event name, the ids that connect it to a request, user, or job, and the specifics ("import failed", file, page, cause). Structured key-value beats prose because the reader at 3 a.m. is a query, not a person scrolling.
  2. Choose levels by the reader's need: ERROR means someone should act; WARN means worth noticing on a bad day; INFO narrates state changes worth a timeline (started, migrated, deployed); DEBUG is for development and off by default. An ERROR nobody acts on gets demoted, because alarm fatigue is how real errors get missed.
  3. Propagate one correlation id from the edge through every hop, into every log line and outbound call. The single most valuable observability feature is being able to pull one request's whole story with one query.
  4. Measure the four that matter per service: traffic, error rate, latency as percentiles (p50, p95, p99, because averages hide the pain), and saturation (queue depth, pool usage, memory). Add per-feature counters only where a business question needs them.
  5. Alert on symptoms, with a runbook. Page on what users feel (error rate, latency budget burn), not on causes like CPU, which belong on dashboards. Every alert states what to check first and what usually fixes it; an alert without a next action is noise with a pager.
  6. Never log secrets or personal data. Tokens, passwords, keys, and raw personal content stay out of logs structurally (redaction at the logger), not by hoping call sites remember.

Litmus tests

  • Given one failing request id, can you reconstruct its path and failure cause from signals alone?
  • Does every page in the last month correspond to something a human did?
  • Can you tell the difference between "slow for everyone" and "slow for one huge tenant" from the dashboards?

Boundaries

Instrumentation follows the codebase's existing framework and conventions; a second logging system is a bug, not an improvement. Cost is real: sample high-volume traces, cap cardinality on metric labels, and expire what nobody queries.

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.