OpenTelemetry (Tracing + Metrics) module for Nest framework (node.js) 🔭

AWS Distro for OpenTelemetry Collector (see ADOT Roadmap at https://github.com/orgs/aws-observability/projects/4)

OpenTelemetry command-line tool for sending events from shell scripts & similar environments

OTel Weaver lets you easily develop, validate, document, and deploy semantic conventions

An idiomatic Clojure API for adding telemetry to your libraries and applications using OpenTelemetry.

A collection of token-efficient, agent-friendly OpenTelemetry skills for AI coding agents, installable via skills.sh or Claude Code plugin marketplace.

A modular, scalable Spring Boot microservices framework for managing courses and reviews. It features OAuth 2.0 authentication via Keycloak, API management with Spring Cloud Gateway, and observability using OTel, Grafana, Loki, Tempo, and Prometheus. MongoDB and PostgreSQL handle storage, with deployments via Docker Compose and Kubernetes.

An OpenTelemetry compatible library for instrumenting and exporting traces for Cloudflare Workers

Investigate and reduce SigNoz telemetry ingestion cost and metric cardinality across metrics, logs, and traces. Find what drives SigNoz spend (via the Cost Meter), which metrics have runaway or unbounded label cardinality, and safe, dashboard-, alert-, and Infra-page-aware ways to cut volume. Make sure to use this skill whenever the user asks "why is my SigNoz bill so high", "what's driving my ingestion cost", "reduce telemetry volume", "which metrics cost the most", "cardinality health check", or "what can I safely drop" — or otherwise asks about telemetry spend, ingestion volume, or metric cardinality, even if they don't say "cost" or "optimize" explicitly.

Create a new SigNoz alert rule from a natural-language intent — threshold, anomaly, log-volume, error-rate, latency, or absent-data alerts across metrics, logs, traces, and exceptions. Make sure to use this skill whenever the user says "alert me when…", "notify me if…", "set up monitoring for…", "page me on…", "create an alert for…", or asks for a new alert/notification rule, even if they don't say the word "alert" explicitly. Also use it when someone asks to be notified about error rates, latency spikes, log volume, CPU/memory pressure, or anomalous behavior on a service or host.

Run the full end-to-end observability setup for a service after its telemetry is already flowing into SigNoz — sequence SLI/SLO capture, data exploration (RED/USE), focused dashboards, saved Explorer views, burn-rate and absent-data alerts, and a tuning loop into one opinionated, SLO-aware workflow. Make sure to use this skill whenever the user says "set up observability after ingestion", "now that data is flowing, give me dashboards and alerts", "onboard this service to SigNoz end-to-end", "I want the full monitoring setup for X", or asks to go from raw telemetry to a complete dashboard + alerts + views package — even if they don't say "observability" explicitly. This is the orchestration layer: for a single artifact (just a dashboard, just one alert, just a saved view, or one static threshold alert, or a one-off query) use signoz-creating-dashboards, signoz-creating-alerts, signoz-managing-views, or signoz-generating-queries directly.