observability-architecture

Designs observability architecture to unify logs, metrics, and traces.

Updated Feb 4, 2026

Search Tags:#logs #metrics #observability #tracing #alerting #health #correlation-id

Ready to run

npx skills add https://github.com/Tirael/cursor-template --skill observability-architecture-tirael

💬 Prompt for ChatGPT / Claude Chat▼

Please help me install this Agent Skill.
Skill: observability-architecture
Source: https://github.com/Tirael/cursor-template/tree/main/.cursor/skills/observability-architecture
Command: npx skills add https://github.com/Tirael/cursor-template --skill observability-architecture-tirael

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Observability architecture guidelines to define consistent logging, metrics, correlations, and alerting for reliable systems.

Core Features & Use Cases

Define required log fields and correlation
Design metrics and SLI for SLO
Configure alerting for degradations

Quick Start

Describe your system's architecture and provide log, metric, and tracing requirements to implement an observability framework.

Frequently Asked Questions about observability-architecture

High-intent search queries and answers about installing and using this skill.

FAQPage Schema

How do I design observability architecture for distributed systems?▼

Observability architecture design unifies logs, metrics, and traces to provide reliable system monitoring. You define log schemas with correlationId, per-service metrics, OpenTelemetry tracing, health endpoints, and alerting rules to ensure proactive degradation detection.

What is the best way to correlate logs, metrics, and traces across services?▼

Correlating logs, metrics, and traces requires a unified observability architecture using a correlationId in JSON log schemas. This links distributed service events to OpenTelemetry traces, enabling precise root cause analysis and service health monitoring.

How do I define SLIs and alerting rules for SLO monitoring?▼

Defining SLIs and alerting rules involves mapping per-service metrics to your Service Level Objectives. The architecture specifies health endpoints and degradation thresholds to trigger proactive alerts before system reliability drops below target levels.

Do I need OpenTelemetry for tracing in my observability architecture?▼

OpenTelemetry is required for tracing in this observability architecture. It standardizes trace propagation across distributed services, linking execution paths with logs and metrics to provide comprehensive system visibility.

What log schema format should I use for observability?▼

The recommended log schema format is JSON, structured with required fields like correlationId and tenantId. This standardized structure ensures logs can be effectively searched, filtered, and correlated with metrics and traces.

Can I use this observability architecture for any distributed system?▼

Yes, this observability architecture applies to any distributed system requiring correlation, SLIs, and proactive alerting across services. You adapt the log schemas, metrics, and tracing rules to match your specific service topology.