Trent/vigilcare-clinical
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

feature: Observability: Prometheus Metrics and Grafana

Browse Source
This commit is contained in:
voltsrage
2026-06-17 16:25:27 +08:00
parent 101040f9d9
commit df99bf3c91
22 changed files with 1462 additions and 132 deletions
Download Patch File Download Diff File Expand all files Collapse all files
docs/vigilcare-clinical-api-prd.md
+5 -1
View File
@@ -350,7 +350,7 @@ sirs:{encounterId}:WBC_K_UL → "1" (TTL: 30 minutes)
### 8. RabbitMQ Notification Workers and Escalation
**Description:** The notification worker reads `alert.generated` events from Kafka and dispatches paging jobs to RabbitMQ. The RabbitMQ consumer sends the page and waits for acknowledgment. If no acknowledgment arrives within five minutes, the dead-letter queue escalates to the on-call backup.
**Description:** The notification worker reads `alert.generated` events from Kafka and dispatches paging jobs to RabbitMQ. The RabbitMQ consumer sends the page and waits for acknowledgment. If no acknowledgment arrives within five minutes, the dead-letter queue escalates to the on-call backup. If the API host is stopping while a page is in flight, the cancellation path requeues the message rather than escalating it.
**Exchange topology:**
```
@@ -373,6 +373,10 @@ clinical.notifications.exchange (direct)
c. After TTL: message routes back to alerts.escalation.queue
d. Escalation worker pages the on-call backup
e. clinical_alert.status → 'escalated' in PostgreSQL
5. If host shutdown occurs during paging wait:
a. Cancellation is treated as graceful stop, not failure
b. NACK with requeue=true → message returns to alerts.paging.queue
c. No DLQ route, so no false escalation during restart/deploy
```
**Discharge summary job:** When an encounter status changes to `discharged`, the outbox relay publishes to Kafka `encounter.status.changed`. The notification Kafka consumer reads this and publishes to `notifications.discharge.queue`. The worker generates a PDF summary (log the content; no real PDF library required), stores it in MinIO under `/discharge-summaries/{encounterId}/summary.pdf`, and marks the job complete.