Observability, Metrics, and Structured Logging
Observability, Metrics, and Structured Logging
Connexion v26 expands operational visibility for standalone, multi-active, container, and cloud deployments.
Services now produce structured logs, metrics use OpenTelemetry, Prometheus-compatible scraping remains available, and the metric inventory includes queue, partition, cold-storage, database, remote-agent, and process health.
Structured JSON logging
Connexion services dual-write human-readable text logs and machine-parseable JSON logs.
The JSON schema includes consistent context such as:
Timestamp, severity, logger, event ID, process, thread, and machine.
Execution group.
Group, tab, channel, and device names and keys.
Remote Agent key.
Audited user and source endpoint.
Connexion, Gateway, Remote Agent, and Updater use the same NLog-based logging direction.
Plain-text files remain available for local troubleshooting. JSON files can be consumed by SIEM and log platforms such as Splunk, Elastic, Loki, or a cloud logging service.
Non-PHI audit context can be represented structurally. PHI audit records remain on the dedicated PHI audit path rather than being copied into general service logs.
OpenTelemetry metrics
The metrics runtime has moved from prometheus-net to OpenTelemetry .NET.
Existing Prometheus and Grafana deployments can continue scraping the /metrics endpoint. Connexion preserves the established metric names and label behavior needed by existing dashboards.
Version 16 exposed a Prometheus-compatible endpoint for external systems to scrape. Version 26 retains that pull model and adds push delivery through OTLP, AWS Managed Prometheus, and Azure Monitor managed Prometheus.
The primary Connexion metrics programming interfaces remain stable for built-in and custom metrics.
Metrics delivery
v26 supports:
Method | Use |
|---|---|
Prometheus scrape | Existing Prometheus/Grafana environments read |
OTLP | Send metrics to an OpenTelemetry Collector |
AWS Managed Prometheus | Remote write with AWS authentication |
Azure Monitor managed Prometheus | Remote write with Entra authentication |
An OpenTelemetry Collector is a useful cloud-neutral target because it can receive OTLP from Connexion and route data to the organization's chosen backend.
Expanded operational metrics
New or expanded visibility includes:
SQL Server and PostgreSQL repository operations.
Queue and result-update batch sizes and durations.
Pending scheduler work and database connection pressure.
Message and attachment payload sizes.
Partition counts and SQL Server partition distribution.
Database table size, I/O, locks, indexes, waits, vacuum, and related health.
Tier-2 copy queues, copy duration, purge duration, and maintenance activity.
Remote Agent host and disk information.
Process, memory, garbage collection, thread-pool, and disk metrics.
Streaming payload-write duration.
Device-specific metrics and dashboards where provided.
Dynamic inbound routing and route-publication status are also exposed through JSON health metadata. Those routing fields are not currently Prometheus gauges.
Dashboards
Grafana dashboard exports ship with the product source for system, SQL Server, PostgreSQL, and selected device views.
Keeping dashboard JSON with the code means metric and dashboard changes can be reviewed and versioned together.
Operators can import the supplied dashboards and adapt alert thresholds to their own workload. Example thresholds should not be treated as universal production settings.
Logs, metrics, health, and audit serve different purposes
Surface | Best suited for |
|---|---|
Logs | Errors, warnings, detailed execution context, and troubleshooting sequences |
Metrics | Trends, rates, capacity, latency, back-pressure, and alerting |
Health metadata | Current readiness, routing, ownership, and publication state |
Audit | Who performed an administrative or PHI-sensitive operation |
A complete monitoring design should collect all four rather than trying to infer every condition from one source.
Container and multi-active deployments
Structured JSON and OpenTelemetry are especially useful when application-server processes are replaceable and logs are aggregated outside the host.
Recommended practices:
Collect JSON logs from every application server and execution group.
Preserve the application-server, execution-group, channel, device, and audited-user fields.
Scrape every active metrics endpoint or use an appropriate cluster aggregation pattern.
Monitor database and partition health as well as application process health.
Alert on sustained queue backlog, scheduler pressure, archive-copy backlog, route-publication staleness, and disk growth.
Keep audit storage and access controls separate from general log search where policy requires it.
Verify dashboard queries after upgrades instead of assuming every custom metric name is unchanged.