observability-stack-configurator_skill

This skill helps you configure a complete observability stack with metrics, logs, tracing, and alerting across platforms for reliable visibility.

Python

5

GitHub Stars

2

Bundled Files

2 months ago

Catalog Refreshed

4 months ago

First Indexed

Readme & install

Copy the install command, review bundled files from the catalogue, and read any extended description pulled from the listing source.

Installation

Preview and clipboard use veilstrat where the catalogue uses aiagentskills.

npx veilstrat add skill williamzujkowski/cognitive-toolworks --skill observability-stack-configurator

CHANGELOG.md967 B
SKILL.md14.0 KB

Overview

This skill configures a complete observability stack across metrics, logs, tracing, dashboards, and alerting using Prometheus, OpenTelemetry, CloudWatch, and Grafana. It generates platform-specific agent artifacts and configuration snippets to deploy consistent telemetry across Kubernetes, cloud providers, and on-premise environments. The goal is actionable visibility that supports SLOs, incident response, and long-term analysis.

How this skill works

The skill validates input (platform, tech stack, SLIs, alerting rules, retention policies) and selects an appropriate stack: Prometheus/Grafana for Kubernetes, CloudWatch/X-Ray for AWS, or OpenTelemetry-based pipelines for multi-cloud and vendor-neutral setups. It produces metrics scrape configs, logging aggregation settings, tracing instrumentation snippets, dashboard definitions, and alerting rules tailored to the specified token budget (T1/T2/T3). It includes decision and abort checks for platform compatibility, instrumentation feasibility, and conflicting requirements.

When to use it

Deploying an application without monitoring or alerting in production
Troubleshooting microservices that require distributed tracing and correlation
Meeting SLO/SLA commitments with SLI/SLO tracking and burn-rate alerts
Centralizing logs for compliance, audit, or forensic purposes
Optimizing performance and capacity planning with long-term metrics

Best practices

Instrument RED (Rate, Errors, Duration) and USE (Utilization, Saturation, Errors) metrics as defaults
Use structured JSON logs and inject trace_id for correlation
Prefer OpenTelemetry for vendor-agnostic instrumentation and collector pipelines
Apply appropriate sampling and retention: high-resolution short-term, downsampled long-term
Avoid high-cardinality metric labels; use recording rules and long-term storage solutions

Example use cases

Kubernetes cluster: Prometheus scrape config + Grafana dashboards + Loki for logs
AWS service: CloudWatch metrics/logs + X-Ray traces + alerting to PagerDuty
Multi-service app: OpenTelemetry auto-instrumentation with Jaeger/Thanos for scale
SLO program: derive SLIs from instrumented metrics and configure burn-rate alerts
Compliance: centralized log retention (immutable audit trail) and SIEM integration

FAQ

Provide platform, tech_stack, requirements.slis, requirements.alerting_rules, and requirements.retention_policies to validate feasibility and produce tailored configs.

How does the skill choose Prometheus vs. CloudWatch?

Selection is based on platform compatibility, operational model, and constraints: Kubernetes favors Prometheus/Grafana; AWS favors CloudWatch; multi-cloud or vendor-neutral use OpenTelemetry.

When should I escalate from basic to extended analysis?

Escalate when you need distributed tracing, SLO tracking, advanced alerting, multi-cluster federation, or long-term aggregated storage.