Skip to main content

Monitoring and Observability

AttributeValue
Project[Project Name]
Version0.1
StatusDraft

Table of Contents​

1. Monitoring Strategy​

Primary Observability Tools​

ConcernToolRationale
Error tracking[e.g. Sentry, Datadog, Bugsnag][Why]
Infrastructure metrics[e.g. CloudWatch, Grafana, Datadog][Why]
Log aggregation[e.g. CloudWatch Logs, Loki, ELK][Why]

Cost Boundary Management​

  • [Set a monthly spend cap or alert threshold.]
  • [Free-tier limits used during MVP.]

2. Log Aggregation Approach​

  • Structured logging: all application logs use JSON with consistent fields (timestamp, level, message, requestId, service, environment).
  • Log levels: ERROR for actionable failures, WARN for degraded states, INFO for business events, DEBUG for development.
  • Retention: [e.g. 14 days for application logs, 30 days for infrastructure logs.]

3. Distributed Tracing​

  • Tracing tool: [same as error tracking or a dedicated APM — link the ADR.]
  • Trace propagation: [how trace IDs flow across services / across frontend and backend.]
  • Sampling strategy: [full in dev/staging, adaptive or head-based in production.]

4. Key Metrics and Dashboards​

Service-Level Indicators (SLIs)​

SLIWhat it measuresTargetSource
Error rate% of 5xx responses out of total requests< 1%[Tool]
p95 latency95th percentile response time< [N]ms[Tool]
AvailabilitySuccessful requests / total requests> 99.5%[Tool]

Dashboard Views​

DashboardAudiencePanels
Application HealthDev teamError rate, p50/p95 latency, request volume by route
InfrastructureDevOps / InfraCPU, memory, connections, disk, network
Business KPIsProduct[Key conversion or usage metrics]

Dashboard Mockups​

ASCII mockups or exported screenshots can be committed here to anchor conversations before dashboards are built.

┌─────────────────────────────────────────────────────────┐
│  Application Health                                      │
│  ┌───────────────┐ ┌───────────────┐ ┌───────────────┐  │
│  │ Error Rate    │ │ p95 Latency   │ │ Request Vol   │  │
│  │   0.3% ✓     │ │   89ms ✓      │ │   1.2k/min ✓  │  │
│  └───────────────┘ └───────────────┘ └───────────────┘  │
└─────────────────────────────────────────────────────────┘

5. Alerting Rules and Escalation​

ConditionSeverityActionNotification
Error rate > 2% for 5 minCriticalPage on-call[Channel]
p95 latency > 500ms for 10 minWarningSlack notification[Channel]
Disk usage > 80%WarningReview + plan[Channel]

Escalation Flow​

  1. Alert fires → notification to [channel]
  2. Acknowledged within [N] minutes → investigation begins
  3. Not acknowledged → escalate to [secondary contact]
  4. Resolved → post-incident review if severity is Critical

6. Performance Monitoring​

  • Frontend: [Core Web Vitals (LCP, INP, CLS), error boundary reports, bundle size tracking.]
  • Backend: [Endpoint latency distributions, slow query logging, connection pool stats.]
  • Database: [Query performance, index usage, connection count.]

7. Observability Integration in Delivery Workflow​

  • Release tagging in the error tracker is triggered by the production deploy pipeline.
  • Every PR includes a link to related Sentry/error-tracker issues when available.
  • Monitoring dashboards are reviewed during sprint planning or release sign-off.

8. Data Privacy and Security in Observability​

  • PII is scrubbed before ingestion (field redaction rules in the error tracker).
  • Log aggregation does not store raw request/response bodies by default.
  • Access to observability dashboards follows the same RBAC model as the application.
  • Audit trails for infrastructure changes are captured separately (IaC plan/apply logs).

9. Cost Management​

  • [Monthly review of observability spend.]
  • [Free-tier limits documented per tool.]
  • [Actions taken when approaching limits: sampling adjustments, retention reduction.]

Source References​

Last Updated: YYYY-MM-DD