Das Standardtool für Monitoring auf AWS ist Cloudwatch. Du hast dir in den AWS Kapiteln Cloudwatch sicherlich schon grundsätzlich angesehen. In diesem Kapitel wirst du es aber konkret kennenlernen. Du wirst Custom Metriken zu Cloudwatch pushen und Alarme erstellen.
Ziele
- Erfülle alle Aufgaben
- Du verstehst was ein Prometheus
Label
ist und warum manrelabel_config
braucht. - Du verstehst den Unterschied zwischen
relabel_configs
undmetric_relabel_configs
.
Inhalte
- Amazon CloudWatch instance-level metrics for Amazon RDS Show archive.org snapshot
- RDS Overview of Enhanced Monitoring Show archive.org snapshot
- Creating metrics from log events using filters Show archive.org snapshot
- Getting Started with the AWS Distro for OpenTelemetry Collector Show archive.org snapshot
- Getting Started with AWS Distro for OpenTelemetry using EKS Add-Ons Show archive.org snapshot
- Using CloudWatch Metrics with AWS Distro for OpenTelemetry Show archive.org snapshot
- Using CloudWatch Container Insights with AWS Distro for OpenTelemetry Show archive.org snapshot
- Prometheus Remote Write Exporter Advanced Configurations for AMP Show archive.org snapshot
- How Amazon Route 53 checks the health of your resources Show archive.org snapshot
Extra Prometheus Wissen
Da auch adot
Prometheus Metriken einsammelt, ist es wichtig zu wissen wie das labeln und relabeln von Prometheus Metriken funktioniert.
- Prometheus Cheat Sheet - Basics (Metrics, Labels, Time Series, Scraping) Show archive.org snapshot
- How relabeling in Prometheus works Show archive.org snapshot
- Life of a Label Show archive.org snapshot
- relabel_configs vs metric_relabel_configs Show archive.org snapshot
- Why doesn't my prometheus relabel_config work?
Aufgaben
Für diese Aufgabe kehren wir wieder zu deine notestar
Applikation, die du mit EKS auf AWS deployed hast, zurück. Wenn nicht anders angegeben, sind die zu erstellenden Ressourcen mit Terraform zu deployen.
-
Erstelle Cloudwatch Alarme für deine RDS Instanz. Folgende Metriken solltest du überwachen:
- CPUUtilization
- BurstBalance
- CPUCreditBalance (wenn das auf deinen Instance Type zutrifft)
- FreeableMemory (der Grenzwert sollte hier vom verfügbaren Speicher des gewählten Instance Types abhängen)
- ReadLatency
- WriteLatency
- DatabaseConnections (https://aws.amazon.com/premiumsupport/knowledge-center/rds-mysql-max-connections/)
- Disk Space
Achte darauf, nicht zu viel code für die Alarme zu duplizieren.
-
Aktiviere storage autoscaling Show archive.org snapshot für deine RDS Instanz. Natürlich möchtest du trotzdem den Disk Space dafür überwachen. Schließlich wird nicht beliebig viel in kurzer Zeit skaliert. Dafür benötigst du eine Metrik, die dir anzeigt wie viel % vom Disk Space verwendet wird. Dafür kannst du
Enhanced Monitoring
undmetric filters
verwenden. Nachdem die Metrik existiert, erstellst du noch einen entsprechenden Alarm dafür. -
Du möchtest k8s Metriken in deinem Cloudwatch haben. Dafür kannst du adot Show archive.org snapshot verwenden. Von makandra gibt es das adot Show archive.org snapshot terraform module. Dieses example Show archive.org snapshot bietet eine gute Basis Konfiguration. Außerdem solltest du dir noch
kube-state-metrics
installieren, damit auch weitere Prometheus Konfigurationen zur Verfügung stehen.resource "helm_release" "kube-state-metrics" { name = "kube-state-metrics" repository = "https://prometheus-community.github.io/helm-charts" chart = "kube-state-metrics" namespace = "kube-system" version = "4.22.3" create_namespace = false atomic = true values = [ yamlencode({ metricAllowlist = [ "kube_deployment_status_replicas_available", "kube_deployment_spec_replicas", "kube_deployment_status_replicas_ready" ] collectors = [ "deployments", ] }) ] }
-
Sprich mit deinem Mentor über die
adot
Konfiguration. -
Erstelle einen Route53 Healthcheck, um zu überprüfen, ob deine Applikation noch erreichbar ist. Es soll auch einen Alarm dafür geben.