Monitoreo de aplicaciones Kotlin: métricas y alertas de la A a la Z

Introducción: Por qué el monitoreo es vital para las aplicaciones Kotlin

Las aplicaciones Kotlin modernas, que se ejecutan en la JVM (Java Virtual Machine), a menudo se convierten en nodos críticos de la infraestructura. Sin un monitoreo adecuado, corre el riesgo de enfrentar fallos repentinos, fugas de memoria o degradación del rendimiento que pasarán desapercibidos hasta el momento del incidente. En este artículo, analizaremos cómo construir un sistema completo de monitoreo de aplicaciones Kotlin «de la A a la Z»: desde la recopilación de métricas básicas (CPU, memoria, GC) hasta la configuración de alertas en Grafana y Prometheus.

Analizaremos tres herramientas clave: Micrometer (fachada para métricas), Prometheus (almacenamiento y recolector) y Grafana (visualización y alertas). Todos los ejemplos de código están escritos en Kotlin.

1. Fundamentos de la recopilación de métricas: Micrometer y Prometheus

Micrometer es, de facto, la fachada estándar para el monitoreo en el ecosistema Spring y Kotlin. Proporciona una API unificada para enviar métricas a varios sistemas (Prometheus, Datadog, New Relic, etc.).

1.1. Adición de dependencias (Gradle)

dependencies {\n    implementation("io.micrometer:micrometer-registry-prometheus:1.12.0")\n    implementation("org.springframework.boot:spring-boot-starter-actuator")\n}

Para Ktor o Kotlin puro sin Spring, puede agregar solo micrometer-core y micrometer-registry-prometheus.

1.2. Configuración básica de Micrometer en Spring Boot

En application.yml, simplemente habilite Actuator y el endpoint de Prometheus:

management:\n  endpoints:\n    web:\n      exposure:\n        include: health,info,prometheus\n  metrics:\n    export:\n      prometheus:\n        enabled: true

Después de iniciar la aplicación, las métricas estarán disponibles en /actuator/prometheus.

1.3. Creación de métricas personalizadas (ejemplo en Kotlin)

Supongamos que desea contar la cantidad de pedidos procesados y su tiempo de procesamiento:

import io.micrometer.core.instrument.MeterRegistry\nimport io.micrometer.core.instrument.Timer\nimport org.springframework.stereotype.Service\nimport java.util.concurrent.atomic.AtomicLong\n\n@Service\nclass OrderService(private val registry: MeterRegistry) {\n\n    private val processedOrders: AtomicLong = registry.gauge(\n        "orders.processed.count",\n        AtomicLong(0)\n    )\n    private val orderProcessingTime: Timer = registry.timer("orders.processing.time")\n\n    fun processOrder(orderId: String) {\n        val sample = Timer.start()\n        try {\n            // Lógica de procesamiento del pedido\n            Thread.sleep((50..200).random().toLong())\n            processedOrders.incrementAndGet()\n        } finally {\n            sample.stop(orderProcessingTime)\n        }\n    }\n}

Ahora las métricas orders_processed_count y orders_processing_time_seconds aparecerán en Prometheus.

2. Configuración de Prometheus para la recopilación de métricas

Prometheus es un servidor que «raspa» (solicita) métricas de sus aplicaciones según un cronograma.

2.1. Configuración de prometheus.yml

Agregue su servicio Kotlin como objetivo (target):

scrape_configs:\n  - job_name: 'kotlin-app'\n    metrics_path: '/actuator/prometheus'\n    static_configs:\n      - targets: ['localhost:8080']

Si la aplicación se ejecuta en Docker/Kubernetes, utilice el descubrimiento de servicios.

2.2. Métricas JVM importantes por defecto

Micrometer exporta automáticamente muchas métricas de la JVM:

\n
• jvm_memory_used_bytes — memoria utilizada (heap/no heap)
\n
• jvm_gc_pause_seconds — tiempo de pausas del GC
\n
• jvm_threads_live_threads — número de hilos activos
\n
• process_cpu_usage — uso de CPU por el proceso
\n

Estos datos ya están disponibles en Prome