Monitoring Kotlin Applications: Metrics, Alerts, and Advanced Techniques

Introduction: Why Monitoring is the Foundation of Production Stability

\nIn modern development, writing code is only half the battle. For a Kotlin application to run stably under load, it is necessary to understand its internal state. Basic logs and health checks provide only a superficial picture. Advanced monitoring with metrics and alerts allows you not just to record failures, but to predict them, identify bottlenecks, and respond quickly to anomalies. In this article, we will break down how to build a production-ready monitoring system for Kotlin applications using the Micrometer + Prometheus + Alertmanager + Grafana stack.\n

1. Collecting Metrics with Micrometer and Prometheus

\nMicrometer is a facade for metric collection that has become the de facto standard in the JVM and Kotlin world. It supports many backends: Prometheus, Datadog, New Relic, and others. For Kotlin applications (Spring Boot, Ktor, http4k), integration is trivial.\n

1.1. Setup and Configuration

Add the necessary dependencies to build.gradle.kts:

// For Spring Boot\nimplementation("io.micrometer:micrometer-registry-prometheus")\n\n// For Ktor (manual setup)\nimplementation("io.micrometer:micrometer-core:1.12.0")\nimplementation("io.micrometer:micrometer-registry-prometheus:1.12.0")

For Spring Boot, a MeterRegistry bean is created automatically. In Ktor, you need to initialize it manually:

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// Exporting the /metrics endpoint\nembeddedServer(Netty, port = 8080) {\n    routing {\n        get("/metrics") {\n            call.respondText(registry.scrape())\n        }\n    }\n}.start(wait = true)

1.2. Custom Metrics

In addition to standard metrics (JVM, CPU, memory), add business metrics. Example of a counter for processed orders:

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

Or a histogram for request execution time:

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. Advanced Alerts: From Thresholds to Predictions

\nAlerts based on simple thresholds (e.g., CPU > 90%) often produce false positives. At an advanced level, we use Alertmanager and PromQL rules with aggregation and prediction.\n

2.1. Configuring Alertmanager

Configuration for alertmanager.yml to send notifications to Telegram and 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 Rules for Smart Alerts

In rules.yml, let's describe a rule that fires if the 95th percentile of response time exceeds 500 ms for 5 minutes:

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