Überwachung von Kotlin-Anwendungen: Metriken, Alarme und fortgeschrittene Techniken

Einleitung: Warum Überwachung die Grundlage für Produktionsstabilität ist

\nIn der modernen Softwareentwicklung ist das Schreiben von Code nur die halbe Miete. Damit eine Kotlin-Anwendung unter Last stabil läuft, müssen Sie ihren inneren Zustand verstehen. Einfache Logs und Health Checks liefern nur ein oberflächliches Bild. Fortgeschrittene Überwachung mit Metriken und Alarmen ermöglicht es nicht nur, Ausfälle zu erfassen, sondern sie vorherzusagen, Engpässe zu identifizieren und schnell auf Anomalien zu reagieren. In diesem Artikel zeigen wir, wie Sie ein produktionsreifes Überwachungssystem für Kotlin-Anwendungen mit dem Stack Micrometer + Prometheus + Alertmanager + Grafana aufbauen.\n

1. Metriksammlung mit Micrometer und Prometheus

\nMicrometer ist eine Fassade zur Metriksammlung, die sich de facto zum Standard in der JVM- und Kotlin-Welt entwickelt hat. Es unterstützt zahlreiche Backends: Prometheus, Datadog, New Relic und andere. Für Kotlin-Anwendungen (Spring Boot, Ktor, http4k) ist die Integration trivial.\n

1.1. Einbindung und Konfiguration

Fügen Sie die erforderlichen Abhängigkeiten in build.gradle.kts hinzu:

// Für Spring Boot\nimplementation("io.micrometer:micrometer-registry-prometheus")\n\n// Für Ktor (manuelle Konfiguration)\nimplementation("io.micrometer:micrometer-core:1.12.0")\nimplementation("io.micrometer:micrometer-registry-prometheus:1.12.0")

Für Spring Boot wird automatisch ein MeterRegistry-Bean erstellt. In Ktor müssen Sie es manuell initialisieren:

import io.micrometer.prometheus.PrometheusMeterRegistry\nimport io.micrometer.core.instrument.Clock\nimport io.prometheus.client.CollectorRegistry\n\nval registry = PrometheusMeterRegistry(\n    PrometheusConfig.DEFAULT,\n    CollectorRegistry.defaultRegistry,\n    Clock.SYSTEM\n)\n\n// Export des /metrics-Endpunkts\nembeddedServer(Netty, port = 8080) {\n    routing {\n        get("/metrics") {\n            call.respondText(registry.scrape())\n        }\n    }\n}.start(wait = true)

1.2. Benutzerdefinierte Metriken

Fügen Sie neben den Standardmetriken (JVM, CPU, Speicher) auch Geschäftsmetriken hinzu. Beispiel für einen Zähler für verarbeitete Bestellungen:

val orderCounter = Counter.builder("orders.processed")\n    .description("Total processed orders")\n    .register(registry)\n\nfun processOrder(order: Order) {\n    // Geschäftslogik\n    orderCounter.increment()\n}

Oder ein Histogramm für die Ausführungszeit einer Anfrage:

val requestTimer = Timer.builder("http.requests.duration")\n    .description("Duration of HTTP requests")\n    .publishPercentiles(0.5, 0.95, 0.99)\n    .sla(Duration.ofMillis(100), Duration.ofMillis(500))\n    .register(registry)\n\nfun handleRequest(block: () -> Response): Response {\n    return requestTimer.record(block)\n}

2. Fortgeschrittene Alarme: Von Schwellwerten zu Vorhersagen

\nAlarme auf Basis einfacher Schwellwerte (z. B. CPU > 90%) führen oft zu Fehlalarmen. Auf fortgeschrittener Ebene verwenden wir Alertmanager und PromQL-Regeln mit Aggregation und Prognose.\n

2.1. Alertmanager-Konfiguration

Konfiguration der alertmanager.yml zum Senden von Benachrichtigungen an Telegram und Slack:

route:\n  receiver: 'team-alerts'\n  group_wait: 30s\n  group_interval: 5m\n  repeat_interval: 1h\n\nreceivers:\n- name: 'team-alerts'\n  telegram_configs:\n  - bot_token: 'YOUR_BOT_TOKEN'\n    chat_id: -123456789\n    parse_mode: 'HTML'\n  slack_configs:\n  - api_url: 'https://hooks.slack.com/services/...'\n    channel: '#alerts'

2.2. PromQL-Regeln für intelligente Alarme

In rules.yml beschreiben wir eine Regel, die ausgelöst wird, wenn das 95. Perzentil der Antwortzeit 5 Minuten lang 500 ms überschreitet:

groups:\n- name: http_latency\n  rules:\n  - alert: HighLatencyP95\n    expr: |\n      histogram_quantile(0.95,\n        sum(rate(http_requests_duration_seconds_bucket[5m])) by (le, endpoint)\n      ) > 0.5\n    for: 5m\n    ann