Prometheus-Grafana-OpenTelemetry Cursor Rules Template for Cursor AI

Overview

Cursor rules configuration for Prometheus, Grafana, and OpenTelemetry tracing helps Cursor AI instrument, collect metrics, and present traces in Grafana dashboards. This is a copyable .cursorrules configuration page designed for a Cursor AI workflow and stack using Prometheus metrics, Grafana dashboards, and OpenTelemetry traces.

Direct answer: Use this Cursor Rules Template to paste a ready-to-run .cursorrules block in your project root to configure Cursor AI for instrumentation, tracing, and observability in this stack.

When to Use These Cursor Rules

• Instrument microservices that expose metrics to Prometheus.
• Correlate traces with metrics across services using OpenTelemetry.
• Build Grafana dashboards that combine traces and metrics.
• Enforce conventions and safety checks for instrumentation in Cursor AI workflows.

Copyable .cursorrules Configuration

# Cursor rules for Prometheus-Grafana-OpenTelemetry tracing
framework: "Prometheus-Grafana-OpenTelemetry tracing stack"
role: "Observability Engineer"
context: "Instrument microservices with OpenTelemetry, export metrics via Prometheus OTLP, and visualize with Grafana. Cursor AI enforces safety and consistency."
codeStyle: "language-agnostic; follow language idioms; avoid heavy instrumentation; keep spans small"
architectureDirectory: "/services//instrumentation, /monitoring/prometheus, /monitoring/grafana, /monitoring/otel"
authenticationSecurity: "Use environment variables; TLS for OTLP; do not commit secrets"
databaseOrm: "Tag traces with db.system and db.statement; avoid exposing sensitive data in traces"
testingLintingWorkflows: "Unit tests for instrumentation helpers; integration tests for OTLP exporter; lint in CI using recommended tools"
prohibitedActions: "Do not export traces to non-TLS endpoints; do not instrument external libraries without caution; do not mix tracing with non-instrumentation code paths"

Recommended Project Structure

// Recommended project structure (Prometheus | Grafana | OpenTelemetry)
root/
├── services/
│   └── orders-service/
│       ├── main.go
│       └── instrumentation/
│           └── otel-instrumentation.go
├── monitoring/
│   ├── prometheus/
│   │   ├── prometheus.yml
│   │   └── rules/
│   ├── grafana/
│   │   └── dashboards/
│   │       └── traces-dashboard.json
│   └── otel/
│       ├── config.yaml
│       └── exporters/
│           └── otlp-exporter.yaml
└── dashboards/

Core Engineering Principles

• Observability-first design with instrumented code and dashboards.
• Consistent naming and tagging across traces and metrics.
• Security by design: protect telemetry data and endpoints.
• Performance-conscious instrumentation with minimal overhead.
• Reproducible environments and IaC for observability stacks.

Code Construction Rules

• Use OpenTelemetry SDKs for instrumentation with service-scoped instrumentation names (service.operation).
• Export traces via OTLP over TLS to a central collector.
• Conform to semantic conventions when naming spans and attributes.
• Expose Prometheus metrics via standard client libraries; use consistent metric names.
• Keep instrumentation code in dedicated instrumentation packages.
• Enable sampling with sane defaults; avoid high sampling in prod unless necessary.

Security and Production Rules

• Store credentials in environment-only secrets; avoid embedding tokens.
• Enable TLS for OTLP and Prometheus endpoints; restrict access with firewall rules and mTLS if possible.
• Mask sensitive attributes in traces, such as personally identifiable information.
• Audit dashboards and export configurations as code in CI.

Testing Checklist

• Unit tests for instrumentation helpers; mock OTLP exporter.
• Integration tests to verify exported traces reach the collector.
• End-to-end tests that emit sample traces and verify Grafana dashboards reflect the data.
• Lint and type checks in CI for instrumentation code.

Common Mistakes to Avoid

• Under-instrumentation or over-instrumentation causing performance issues.
• Exporting telemetry to non-secure endpoints.
• Inconsistent span naming across services.
• Hardcoding credentials in instrumentation code.

FAQ

What is the purpose of this Cursor Rules Template for Prometheus-Grafana-OpenTelemetry?

This Cursor Rules Template provides a ready-to-paste .cursorrules block and a stack-specific project layout to guide instrumentation using OpenTelemetry, Prometheus and Grafana with Cursor AI. It emphasizes safe, scalable instrumentation across a microservices stack.

How do I apply the copyable .cursorrules block?

Copy the block under Copyable .cursorrules Configuration and paste it at the root of your repo as ".cursorrules". Adapt service names and paths to your codebase, then run Cursor AI to validate and apply the rules.

Which OpenTelemetry components are covered?

The template covers OpenTelemetry instrumentation, OTLP exporters to a collector, and TLS-protected transport. It ensures trace attributes follow conventions and integrates with Prometheus metrics where applicable.

How can I verify traces and metrics appear in Grafana?

After instrumenting services and starting the collector, verify OTLP reaches the collector, Prometheus scrapes metrics, and Grafana dashboards reflect the traces and metrics with correct service names and attributes.

Can I adapt this template for other stacks?

Yes. The Cursor Rules Template is stack-specific but modular. Replace the observability components with equivalents in your stack while preserving the rule structure and safety practices.