AgentStack
Browse Sign in
Browse Why AgentStack Sell Docs
Sign in
SKILL verified MIT Self-run

Oma Observability

skill-first-fluke-oh-my-agent-oma-observability · by first-fluke

Intent-based observability + traceability router across layers, boundaries, and signals. Routes to vendor-specific skills via category taxonomy; owns transport tuning, meta-observability, incident forensics. Use for observability, traceability, telemetry, APM, RUM, metrics, logs, traces, profiles, SLO, incident forensics, tracing architecture work.

No reviews yet
0 installs
3 views
0.0% view→install

Install

$ agentstack add skill-first-fluke-oh-my-agent-oma-observability

✓ scanned · ✓ verified, works with Claude Code, Cursor, and more.

Security review

✓ Passed

No issues found. Passed automated security review. · v0.1.0 How review works →

  • Prompt-injection patterns
  • Secret / credential exfiltration
  • Dangerous shell & filesystem operations
  • Untrusted network calls
  • Known-malicious package signatures

What it can access

  • Network access No
  • Filesystem access No
  • Shell / process execution No
  • Environment & secrets No
  • Dynamic code execution No

From automated source analysis of v0.1.0. “Used” means the capability is present in the source — more access means more to trust, not that it’s unsafe.

View the full security report →

Verified badge

Passed review? Show it. Paste this badge into your README, it links to the public security report.

AgentStack Verified badge Links to your public security report.
[![AgentStack Verified](https://agentstack.voostack.com/badges/verified.svg)](https://agentstack.voostack.com/security/report/skill-first-fluke-oh-my-agent-oma-observability)

Reliability & compatibility

Security review passed
0 installs to date
no reviews yet
1mo ago

Declared compatibility

Claude CodeClaude Desktop

Compatibility is declared by the source manifest. End-to-end runtime verification is coming, see below.

Preview Execution monitoring

We're building live execution health for every listing: tool-call success rate, median latency, uptime, and last-checked timestamps, measured, not self-reported. It isn't live yet, so we don't show numbers we can't stand behind.

How agent discovery & health will work →
Are you the author of Oma Observability? Claim this listing to set pricing, connect Stripe payouts, and keep 70% of every sale.
Sign up to claim

About

Observability Agent - Intent-based Router

Scheduling

Goal

Route, design, tune, and review observability work across MELT+P signals, layers, boundaries, vendor categories, transport choices, meta-observability, and incident forensics.

Intent signature

  • User asks for observability, telemetry, OTel, metrics, logs, traces, profiles, SLOs, RUM, APM, incident forensics, trace propagation, transport tuning, or observability-as-code.
  • User needs vendor/category routing or observability architecture instead of a single vendor's already-covered setup.

When to use

  • Setting up an observability pipeline (OTel SDK + Collector + vendor backend)
  • Designing traceability across service and domain boundaries (W3C propagators, baggage, multi-tenant, multi-cloud)
  • Tuning transport layer (UDP/MTU, OTLP gRPC vs HTTP, Collector DaemonSet vs sidecar topology)
  • Running incident forensics (6-dimension localization: code / service / layer / host / region / infra)
  • Selecting a vendor category (OSS full-stack vs commercial SaaS vs high-cardinality specialist vs profiling specialist)
  • Implementing observability-as-code (Grafana Jsonnet dashboards, PrometheusRule CRD, OpenSLO YAML, SLO burn-rate alerts)
  • Meta-observability (pipeline self-health, clock skew detection, cardinality guardrails, retention matrix)
  • Covering the MELT+P signal set: metrics, logs, traces, profiles (OTEP 0239), cost (OpenCost), audit (SOC2/ISO), privacy (GDPR/PIPA)
  • Migrating off deprecated tools (Fluentd → Fluent Bit or OTel Collector, per CNCF 2025-10 guide)

When NOT to use

  • LLM ops (prompt versioning, evals, gen_ai span deep dive) — use Langfuse, Arize Phoenix, LangSmith, or Braintrust directly
  • Data pipeline lineage — use OpenLineage + Marquez, dbt test, or Airflow lineage backends
  • IoT / hardware / datacenter physical-layer telemetry (IPMI, BMC, SNMP) — use vendor DCIM tooling (Nlyte, Sunbird, Device42)
  • Chaos engineering orchestration — use Chaos Mesh, Litmus, Gremlin, or ChaosToolkit (this skill consumes their telemetry; it does not orchestrate chaos)
  • GPU / TPU infrastructure observability — use NVIDIA DCGM Exporter + Prometheus
  • Software supply chain (SBOM, attestation) — use sigstore (cosign / rekor), in-toto framework, SLSA level attestations
  • Incident response workflow (on-call rotation, paging, escalation) — use PagerDuty, OpsGenie, or Grafana OnCall
  • Single-vendor setup already fully covered by that vendor's own published skill — invoke the vendor skill directly

Expected inputs

  • Observability intent, target system, architecture boundary, signals, vendor context, and incident symptoms if any
  • Existing OTel/collector/vendor configs, dashboards, SLOs, trace/log/metric examples, or deployment topology

Expected outputs

  • Routed observability guidance, setup/migration/tuning plan, incident-forensics path, alerting/SLO guidance, or observability-as-code recommendations
  • Transport, meta-observability, privacy, audit, and retention checks
  • Vendor delegation target when appropriate

Dependencies

  • OTel/W3C/CNCF references and resources under resources/
  • Vendor categories, matrix, standards, incident forensics, meta-observability, transport, layers, boundaries, and signal guides

Control-flow features

  • Branches by intent, vendor category, layer/boundary/signal matrix, transport topology, privacy/audit risk, and incident localization dimension
  • May read/write observability config and docs; generally delegates vendor-specific implementation
  • Requires live status verification for load-bearing CNCF/vendor currency

Structural Flow

Entry

  1. Classify the intent: setup, migrate, investigate, alert, trace, tune, or route.
  2. Identify layers, boundaries, signals, and vendor category.
  3. Load only the relevant resource guide(s).

Scenes

  1. PREPARE: Classify intent and matrix coverage.
  2. ACQUIRE: Read configs, topology, telemetry examples, or incident signals.
  3. REASON: Route vendor/category, tune transport, assess meta-observability, or localize incident.
  4. ACT: Produce setup/migration/tuning/alert/trace/forensics guidance or config changes.
  5. VERIFY: Check pipeline health, clock skew, cardinality, retention, privacy, and audit concerns.
  6. FINALIZE: Report route, evidence, risks, and handoff references.

Transitions

  • If a vendor-owned skill fully covers setup, delegate instead of duplicating docs.
  • If Fluentd appears, recommend Fluent Bit or OTel Collector migration.
  • If incident investigation is requested, use 6-dimensional localization.
  • If transport tuning appears, load transport-specific resources.

Failure and recovery

  • If live CNCF/vendor status is load-bearing, verify current status.
  • If telemetry samples are missing, provide instrumentation/collection steps before analysis.
  • If scope belongs to out-of-scope domains, route to external authoritative tools.

Exit

  • Success: observability path is routed, evidence-backed, and checks are explicit.
  • Partial success: missing telemetry, stale vendor status, or external-domain handoff is explicit.

Logical Operations

Actions

| Action | SSL primitive | Evidence | |--------|---------------|----------| | Classify observability intent | SELECT | Intent rules | | Read telemetry/config evidence | READ | OTel/vendor configs, dashboards, samples | | Route vendor/category | SELECT | Vendor categories | | Infer coverage gaps | INFER | Matrix and signal/boundary mapping | | Validate meta-observability | VALIDATE | Clock, cardinality, retention, health | | Write guidance/config | WRITE | OaC/config/docs when requested | | Notify result | NOTIFY | Routed recommendation |

Tools and instruments

  • OTel/CNCF/W3C standards references
  • Vendor categories, matrix, incident forensics, meta-observability, transport and signal guides
  • Optional CLI/config tooling from the target stack

Canonical workflow path

1. Classify intent: setup, migrate, investigate, alert, trace, tune, or route.
2. Select layer/boundary/signal coverage from `resources/matrix.md`.
3. Load the specific vendor, transport, incident, or signal guide before producing guidance.

When CNCF/vendor status is load-bearing, verify live state at https://landscape.cncf.io.

Resource scope

| Scope | Resource target | |-------|-----------------| | CODEBASE | Observability config, dashboards, alert rules, instrumentation | | LOCAL_FS | Resource guides and generated docs | | NETWORK | Vendor/CNCF status and telemetry backends when checked | | USER_DATA | Incident symptoms, logs, metrics, traces, profiles |

Preconditions

  • Observability intent and system boundary are identifiable.
  • Relevant telemetry/config evidence is available or missing evidence is stated.

Effects and side effects

  • May recommend or modify observability config, dashboards, alerts, and instrumentation docs.
  • May route to vendor-owned skills or external tools.

Guardrails

  1. Classify intent before routing: every query goes through intent classification — setup | migrate | investigate | alert | trace | tune | route
  2. Category-first, not vendor-registry: delegate to vendor-owned skills via resources/vendor-categories.md; do not duplicate their documentation
  3. Transport tuning is the moat: UDP/MTU thresholds, OTLP protocol selection, Collector topology, and sampling recipes are in-skill depth that other skills do not cover
  4. Meta-observability is non-negotiable: always validate pipeline self-health, clock sync ( Integration status (2026-Q2): rows below describe recommended handoff patterns from the oma-observability side. As of this version, reciprocal cross-references from the other skills' SKILL.md files are not yet in place — this is a v1.1 follow-up item. Users invoking the other skills directly will need to surface this integration manually until the reciprocal links land.

| Skill | Integration point | Reciprocal link status | |-------|------------------|-------| | oma-debug | On failure: pull traces + logs by request_id → trigger resources/incident-forensics.md 6-dim localization playbook | ⏳ pending (v1.1) | | oma-qa | Canary post-deploy loop via chrome-devtools MCP: console errors + Core Web Vitals trend; INP/LCP/CLS from layers/L7-application/web-rum.md | ⏳ pending (v1.1) | | oma-tf-infra | Terraform modules for OTel Collector, Grafana, and Loki stack provisioning | ⏳ pending (v1.1) | | oma-scm | Deployment SHA → service.version OTel attribute + release marker events; see boundaries/release.md | ⏳ pending (v1.1) | | oma-backend | Propagator and baggage rules cross-referenced in backend.md ruleset; DB N+1 + Kafka patterns in signals/traces.md | ⏳ pending (v1.1) | | oma-frontend | layers/L7-application/web-rum.md INP/LCP/CLS checklist cross-referenced in frontend.md ruleset | ⏳ pending (v1.1) | | oma-mobile | layers/L7-application/mobile-rum.md offline-queuing pattern cross-referenced in mobile.md ruleset | ⏳ pending (v1.1) | | oma-db | signals/traces.md DB patterns (N+1, connection pool) cross-referenced in database.md ruleset | ⏳ pending (v1.1) |

Versioning & Deprecation

  • Spec version pinning: otel_spec / otel_semconv keys in each file's frontmatter document the assumed version. If content depends on a specific attribute stability tier, the tier is stated inline.
  • Update triggers (not scheduled):
  • OTel semconv promotion (Development → RC → Stable) affecting attributes cited in this skill → update resources/standards.md and the affected file, bump minor version.
  • Attribute deprecation → replace across all citing files; migration note in resources/standards.md.
  • CNCF status change for a vendor/project named in vendor-categories.md (Graduated / Archived / acquired) → update the vendor table.
  • Authoritative live state: https://landscape.cncf.io for CNCF project status. This skill does not promise to track it on any schedule — verify at use time if the information is load-bearing.
  • No per-file review stamps: earlier drafts carried last_reviewed / next_review frontmatter. Those were removed because no automated enforcement exists; relying on voluntary manual review produces stale stamps that misrepresent currency. Git history (git log path/to/file) is the source of truth for when a file was last changed.

Contribution Protocol

  • Do NOT pre-declare future OMA skill names in user-facing documentation. If OMA-native coverage becomes warranted for an out-of-scope domain, evaluate and name it at that point.
  • File edits follow the ownership matrix in docs/plans/designs/005-oma-observability.md §Ownership. CTO co-signs changes to standards.md, matrix.md, anti-patterns.md.
  • Run resources/checklist.md §1 Setup validation before merging.

References

  • Execution steps: resources/execution-protocol.md
  • Intent classification: resources/intent-rules.md
  • Coverage matrix: resources/matrix.md
  • Standards (OTel spec, W3C, ISO): resources/standards.md
  • Vendor categories: resources/vendor-categories.md
  • Incident forensics: resources/incident-forensics.md
  • Meta-observability: resources/meta-observability.md
  • Observability-as-code: resources/observability-as-code.md
  • Anti-patterns (18 items): resources/anti-patterns.md
  • Checklist: resources/checklist.md
  • Examples: resources/examples.md
  • Transport:
  • resources/transport/udp-statsd-mtu.md
  • resources/transport/otlp-grpc-vs-http.md
  • resources/transport/collector-topology.md
  • resources/transport/sampling-recipes.md
  • Layers:
  • resources/layers/L3-network.md
  • resources/layers/L4-transport.md
  • resources/layers/mesh.md
  • resources/layers/L7-application/web-rum.md
  • resources/layers/L7-application/mobile-rum.md
  • resources/layers/L7-application/crash-analytics.md
  • Boundaries:
  • resources/boundaries/multi-tenant.md
  • resources/boundaries/cross-application.md
  • resources/boundaries/slo.md
  • resources/boundaries/release.md
  • Signals:
  • resources/signals/metrics.md
  • resources/signals/logs.md
  • resources/signals/traces.md
  • resources/signals/profiles.md
  • resources/signals/cost.md
  • resources/signals/audit.md
  • resources/signals/privacy.md

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

Install and usage instructions live in the source repository linked above.

Reviews

No reviews yet, be the first.

Versions

  • v0.1.0 Imported from the upstream source.