Core error reporting functions and utilities.

This namespace provides pure functions and higher-level abstractions over
the error reporting protocols, making it easier for feature modules to
report errors without dealing with protocol details directly.

Port definitions for error reporting infrastructure.

This namespace defines the protocols that error reporting adapters must implement,
providing a clean abstraction over different error reporting backends (Sentry,
Rollbar, custom webhooks, etc.).

Core protocols:
- IErrorReporter: Exception and error message reporting
- IErrorContext: Error context management and enrichment

Error Context Structure:
{:correlation-id string - Request correlation ID
 :request-id    string - HTTP request ID  
 :tenant-id     string - Multi-tenant context
 :user-id       string - User context (if authenticated)
 :span-id       string - Distributed tracing span ID
 :trace-id      string - Distributed tracing trace ID
 :tags          map    - Additional structured tags
 :extra         map    - Additional context data
 :breadcrumbs   vector - Sequence of events leading to error}

Configuration schemas for error reporting infrastructure.

This namespace defines Malli schemas for validating error reporting configuration,
ensuring proper structure and constraints for different error reporting providers.

No-op error reporting adapter that safely ignores all error reporting operations.

This adapter implements all error reporting protocols but performs no actual
error reporting, making it safe for feature modules to use error reporting
protocols even when error reporting is disabled or not configured.

Sentry error reporting adapter implementation.

This adapter integrates with Sentry (https://sentry.io) for production error tracking
and monitoring. It implements all error reporting protocols to provide comprehensive
exception tracking, context management, and alerting capabilities.

Features:
- Exception capture with stack traces
- Message-level reporting (debug, info, warning, error, fatal)
- Context management (user, tags, extra data, breadcrumbs)
- Environment and release tracking
- Sampling and filtering capabilities
- Runtime configuration management

Configuration:
The adapter requires a Sentry DSN (Data Source Name) and optionally accepts:
- Environment name (dev, staging, prod)
- Release identifier
- Sample rate (0.0 to 1.0)
- Debug mode flag
- Server name

Example:
(def sentry-reporter
  (create-sentry-error-reporter
    {:dsn "https://your-dsn@sentry.io/project-id"
     :environment "production"
     :release "1.0.0"
     :sample-rate 1.0
     :debug false}))

Core logging functions and utilities.

This namespace provides pure functions and higher-level abstractions over
the logging protocols, making it easier for feature modules to perform
common logging operations without dealing with protocol details directly.

Port definitions for logging infrastructure.

This namespace defines the protocols that logging adapters must implement,
providing a clean abstraction over different logging backends (stdout, JSON,
structured logging systems, etc.).

Core protocols:
- ILogger: Basic application logging with levels and context
- IAuditLogger: Structured audit logging for compliance and monitoring

Context Map Structure:
{:correlation-id string - Request correlation ID
 :request-id    string - HTTP request ID  
 :tenant-id     string - Multi-tenant context
 :user-id       string - User context (if authenticated)
 :span-id       string - Distributed tracing span ID
 :trace-id      string - Distributed tracing trace ID
 :tags          map    - Additional structured tags}

Configuration schemas for logging infrastructure.

This namespace defines Malli schemas for validating logging configuration,
ensuring proper structure and constraints for different logging providers.

Datadog logging adapter implementation.

This adapter integrates with Datadog (https://datadoghq.com) for production logging,
audit tracking, and observability. It implements all logging protocols to provide
comprehensive structured logging capabilities that integrate with Datadog's platform.

Features:
- Structured JSON logging to Datadog HTTP API
- Log levels with proper Datadog level mapping
- Context management (correlation IDs, request metadata)
- Audit event logging for compliance
- Security event tracking
- Batch processing for performance
- Runtime configuration management

Configuration:
The adapter requires a Datadog API key and service name, optionally accepting:
- Source identifier (application/component name)
- Hostname override
- Custom tags
- Custom endpoint (for EU region, etc.)
- Batch size and flush interval settings

Example:
(def datadog-logger
  (create-datadog-logger
    {:api-key "your-32-char-datadog-api-key"
     :service "my-service"
     :source "my-app"
     :environment "production"
     :tags ["team:backend" "version:1.0.0"]
     :batch-size 50
     :flush-interval 5000}))

No-op logging adapter that safely ignores all logging calls.

This adapter implements all logging protocols but performs no actual logging,
making it safe for feature modules to use logging protocols even when logging
is disabled or not configured.

SLF4J logging adapter that delegates to SLF4J backend.

This adapter implements all logging protocols and uses SLF4J as the
underlying logging facade. It supports:
- All log levels (trace, debug, info, warn, error, fatal)
- Structured context via MDC (Mapped Diagnostic Context)
- Audit and security event logging
- Dynamic context management
- Runtime level configuration

The adapter leverages SLF4J's backend (e.g., Logback, Log4j2) for
actual log routing, formatting, and output, eliminating duplication
with clojure.tools.logging infrastructure.

Stdout logging adapter that writes formatted logs to standard output.

This adapter implements all logging protocols and provides configurable
formatting options including plain text and JSON output with optional
colors, timestamps, and structured context.

Core metrics functions and utilities.

This namespace provides pure functions and higher-level abstractions over
the metrics protocols, making it easier for feature modules to collect
metrics without dealing with protocol details directly.

Port definitions for metrics infrastructure.

This namespace defines the protocols that metrics adapters must implement,
providing a clean abstraction over different metrics backends (Prometheus,
Datadog, in-memory registries, etc.).

Core protocols:
- IMetricsRegistry: Metric registration and management
- IMetricsEmitter: Metric value emission and updates
- IMetricsExporter: Metric export and serialization

Metric Types:
- Counter: Monotonically increasing values (requests, errors)
- Gauge: Point-in-time values that can go up/down (active users, memory)
- Histogram: Distribution of values with configurable buckets (latency)
- Summary: Distribution statistics (quantiles, avg, etc.)

Configuration schemas for metrics infrastructure.

This namespace defines Malli schemas for validating metrics configuration,
ensuring proper structure and constraints for different metrics providers.

Datadog metrics adapter implementation using DogStatsD protocol.

This adapter integrates with Datadog (https://datadoghq.com) for production metrics
collection via the DogStatsD UDP protocol. It implements all metrics protocols to
provide comprehensive metrics capabilities that integrate with Datadog's platform.

Features:
- DogStatsD UDP protocol implementation
- Counter, gauge, histogram, and timing metrics
- Tag merging (global, metric default, call-specific)
- Sampling support for performance optimization
- Runtime metric enable/disable for performance tuning
- In-memory metric registry and value tracking
- Injectable send function for testability

Configuration:
The adapter requires a host and service name, optionally accepting:
- Port (default 8125)
- Global tags applied to all metrics
- Sample rate for counters and histograms
- Maximum packet size (UDP MTU considerations)
- Origin detection for container environments

Example:
(def datadog-metrics
  (create-datadog-metrics-components
    {:provider :datadog-statsd
     :host "localhost"
     :port 8125
     :service "my-service"
     :environment "production"
     :global-tags {:team "backend" :version "1.0.0"}
     :sample-rate 0.1
     :max-packet-size 1432}))

No-op metrics adapter that safely ignores all metrics operations.

This adapter implements all metrics protocols but performs no actual metric
collection, making it safe for feature modules to use metrics protocols even
when metrics collection is disabled or not configured.

OpenTelemetry OTLP metrics adapter: bridges the Wagoe metrics ports onto
OpenTelemetry instruments and pushes them over OTLP/HTTP (protobuf) to any
OTel collector (SigNoz, Grafana, Datadog-via-OTel, …). No backend-specific
code — only the endpoint changes.

Metric-type mapping onto OTel instruments:
  counter   -> LongCounter    (.add)
  gauge     -> DoubleGauge    (.set)
  histogram -> DoubleHistogram(.record)
  summary   -> DoubleHistogram(.record)   ; OTel has no summary type

Export is push-based (a PeriodicMetricReader flushes to the collector), so the
`IMetricsExporter` local-render methods are not meaningful here: `export-*`
throw, `flush!` forces an OTLP flush, `get-metric-values`/`reset-metrics!` are
inert. Transport is OTLP/HTTP protobuf via okhttp (gRPC is not bundled).

Pure-Clojure Prometheus metrics adapter.

An in-memory metric registry that renders the Prometheus text exposition
format (https://prometheus.io/docs/instrumenting/exposition_formats/).
It implements all four metrics protocols
(IMetricsRegistry, IMetricsEmitter, IMetricsExporter, IMetricsConfig)
in a single component backed by one Clojure atom, so it is safe for
concurrent use via `swap!`.

No external Prometheus client dependency is used — the exposition text is
produced by this namespace directly.

Sanitization + collisions (BOU-207): metric/label names are sanitized to valid
Prometheus identifiers. Post-sanitization COLLISIONS are handled so the output
stays valid:
- Metric names: if a later registration sanitizes to the same name as an
  already-registered different key (e.g. :http.requests then :http-requests,
  both -> http_requests), the later one is logged and IGNORED — the first
  registration wins (no duplicate `# TYPE` line).
- Label keys within a series: keys that sanitize to the same label name are
  de-duplicated deterministically at render (the lexicographically-first
  [name value] pair wins), so no duplicate label appears in a series.

Series identity
---------------
Each metric value is keyed by (metric-name, label-set), where the label-set
is the merge of the registry default tags, the metric's registration tags,
and any per-call tags. Distinct label-sets are therefore distinct series.

Metric storage
--------------
- counter : {label-set -> numeric total}
- gauge   : {label-set -> numeric value (last write wins)}
- histogram: {label-set -> {:counts {bucket -> n} :inf n :sum s :count c}}
            (per-bucket non-cumulative counts; cumulative counts are computed
             at export time)
- summary : {label-set -> {:sum s :count c}}  — quantiles are NOT tracked;
            only the `_sum`/`_count` pair is emitted (see note below).

Simplifications
---------------
- Summary quantiles are not computed. A summary emits only `_sum` and
  `_count`, which is a valid (if minimal) Prometheus summary exposition.
- Metric names are emitted as-is (assumed already valid Prometheus names).

Pure ergonomics for tracing — the `with-span` macro. Depends only on the
tracing port; the side effects happen in the tracer the macro is handed.

Ports for distributed tracing.

A minimal, backend-agnostic span/tracer abstraction. Feature code depends on
`ITracer` (via the `wagoe.observability.tracing.core/with-span` sugar) and
never on a concrete backend. The default adapter is no-op; a `:logging`
adapter records spans to the log; an OTLP adapter (OpenTelemetry) is wired
behind the same port so any OTel backend (SigNoz, Grafana Tempo, Jaeger, …)
works by pointing at its collector.

A `span` is an opaque handle returned by `start-span!` and passed back to the
other methods. No-op adapters may return a sentinel; real adapters return
whatever they need to correlate + finish the span.

Malli schemas for tracing configuration.

Logging tracer: records spans to the log (start, end + duration, events,
exceptions). Useful for local development and for seeing the trace shape
without standing up an OpenTelemetry collector. Not a sampled/exportable
tracer — for real distributed tracing use the OTLP adapter.

A span carries a generated trace-id/span-id, a start timestamp, and an atom
of accumulated attributes so `set-attributes!` calls made mid-span are folded
in and appear on the final `span.end` line (matching how a real backend
mutates its span object).

No-op tracer: satisfies ITracer but records nothing. The default, so feature
code can use the tracing port even when tracing is disabled.

OpenTelemetry OTLP tracer: real, exportable distributed tracing behind the
`ITracer` port. Spans are exported over OTLP/HTTP (protobuf) to any
OpenTelemetry collector — SigNoz, Grafana Tempo, Jaeger, Honeycomb, or a
Datadog OTel endpoint. Only the endpoint changes; there is no backend-specific
code here (that is the whole point of OTLP).

Transport is OTLP/HTTP protobuf via the okhttp sender bundled with
`opentelemetry-exporter-otlp`. gRPC is intentionally not bundled (it would add
grpc-netty to every app's classpath) — use `:protocol :http/protobuf`.

Context propagation uses W3C `traceparent`, so nested `with-span` calls and
spans started on the current thread become parent/child automatically. The
span handle returned by `start-span!` is the OpenTelemetry `Span`.