Skip to main content

Notification Monitoring

Summary​

Monitoring rests on three pillars, of which two are implemented. Structured logs and distributed traces exist; metrics do not. Alerting does not exist in the repository.

Audience​

DevOps engineers, engineers, support, architects and QA.

Monitoring flow​

Logging​

Providers are cleared and replaced with a JSON console logger that includes scopes and uses UTC timestamps in a fixed format. Correlation middleware opens a scope carrying the correlation identifier and service name for every HTTP request, so those fields appear on every log line within a request.

Default level is information, with the framework's own ASP.NET Core category raised to warning.

Tracing​

OpenTelemetry is configured with a resource identifying the service by name and assembly version. Three trace sources contribute: ASP.NET Core instrumentation with exception recording enabled, HttpClient instrumentation, and the service's own dispatch activity source.

Two exporters are conditional. An OTLP exporter is added only when a valid absolute endpoint is configured; a console exporter only when a flag is set. When neither is configured — which is the committed default — traces are recorded in-process and exported nowhere.

Metrics — verified absence​

No meter, no counter, no histogram, no gauge and no metrics exporter exists anywhere in the service or the shared observability extension. The OpenTelemetry builder configures tracing only.

There is therefore no time-series signal for delivery rate, failure rate, queue depth, consumer lag, retry counts or processing duration — even though duration is measured per attempt and persisted to the attempts table. That data exists in the database but is not exposed as a metric.

What can be monitored today​

SignalAvailable through
Delivery failuresThe failed-queue endpoint and the dashboard tile
Processing stagesThe audit trail with correlation and trace identifiers
Aggregate countsThe statistics endpoint, platform-wide and untenanted
Per-attempt durationPersisted on attempt rows; readable per message only
Errors and warningsJSON console logs
Request and dispatch tracesTraces, when an exporter is configured

Verified absence​

No alert rule, no threshold, no notification-on-failure, no dashboard definition, no synthetic probe, no service-level objective and no scrape endpoint exists in the repository. Monitoring is entirely read-on-demand: something must ask, because nothing announces.

Notably, the two conditions most worth alerting on — the consumer being disconnected from the broker, and the failed queue growing — are both observable only by polling, and the first is visible only in logs.

Classification​

Partial — logging and tracing are Implemented; metrics and alerting are Not implemented.

Requires confirmation​

Production observability destinations, and whether metrics and alerting are planned, require confirmation.

See Also​

Keywords​

  • Notification database
  • Monitoring
  • Draft database documentation

Source References​

  • microservices/src/shared-kernel/Extensions/ObservabilityExtensions.cs
  • microservices/src/notification-service/Application/NotificationTelemetry.cs
  • microservices/src/notification-service/Api/NotificationEndpoints.cs
  • microservices/src/shared-kernel/Middleware/CorrelationIdMiddleware.cs
  • microservices/src/notification-service/appsettings.json

Revision Information​

  • Status: Draft
  • Last reviewed: 2026-07-21
  • Review cycle: Quarterly