47 lines
1.7 KiB
Markdown
47 lines
1.7 KiB
Markdown
# Architecture Decision Record: Monitoring and Alerting
|
|
|
|
Proposed by: Willem Rolleman
|
|
Date: April 28 2025
|
|
|
|
## Status
|
|
|
|
Proposed
|
|
|
|
## Context
|
|
|
|
Currently our monitoring and alerting is done using grafana and prometheus alert manager, deployed via helm in k8s. We need to implement a monitoring and alerting solution that is managed by Harmony. A decision needs to be made as to how this should be implemented within Harmony.
|
|
|
|
## Decision
|
|
|
|
use existing HelmScore and pass the scores for grafana and prometheus for each individual project
|
|
|
|
## Rationale
|
|
|
|
This will allow the end user to choose to use the monitoring and alerting stack if they choose for both local as well as dev/prod projects. Grafana and Prometheus are installed via helm which is consitent with OKD, helm and other design choices. Allows the use of already defined Scores.
|
|
|
|
## Alerternatives considered
|
|
|
|
- ### Implement alerting and monitoring stack using existing HelmScore for each project
|
|
- **Pros**:
|
|
- Each project can choose to use the monitoring and alerting stack that they choose
|
|
- Less overhead in terms of care harmony code
|
|
- can add Box::new(grafana::grafanascore(namespace))
|
|
- **Cons**:
|
|
- No default solution implemented
|
|
- Dev needs to chose what they use
|
|
- Increases complexity of score projects
|
|
|
|
- ### Use OKD grafana and prometheus
|
|
- **Pros**:
|
|
- Minimal config to do in Harmony
|
|
- **Cons**:
|
|
- relies on OKD so will not working for local testing via k3d
|
|
|
|
- ### Create a monitoring and alerting crate similar to harmony tui
|
|
- **Pros**:
|
|
- Creates a default solution that can be implemented or not depending on user choice
|
|
- **Cons**:
|
|
- more complex than using a helm score
|
|
|
|
|