परिचय: क्यों निगरानी उत्पादन-स्थिरता का आधार है
\n\nआधुनिक विकास में कोड लिखना केवल आधा काम है। Kotlin पर चलने वाले एप्लिकेशन को लोड के तहत स्थिर रूप से काम करने के लिए, इसकी आंतरिक स्थिति को समझना आवश्यक है। बुनियादी लॉग और health checks केवल एक सतही तस्वीर देते हैं। मीट्रिक और अलर्ट के साथ उन्नत निगरानी न केवल विफलताओं को रिकॉर्ड करने की अनुमति देती है, बल्कि उनकी भविष्यवाणी करने, बाधाओं की पहचान करने और विसंगतियों पर तुरंत प्रतिक्रिया करने की भी अनुमति देती है। इस लेख में, हम Micrometer + Prometheus + Alertmanager + Grafana स्टैक पर Kotlin अनुप्रयोगों के लिए production-ready निगरानी प्रणाली बनाने का तरीका समझेंगे।\n
\n\n1. Micrometer और Prometheus के साथ मीट्रिक संग्रह
\n\nMicrometer मीट्रिक संग्रह के लिए एक फ़ेसाड है, जो JVM और Kotlin की दुनिया में वास्तविक मानक बन गया है। यह कई बैकएंड का समर्थन करता है: Prometheus, Datadog, New Relic और अन्य। Kotlin अनुप्रयोगों (Spring Boot, Ktor, http4k) के लिए एकीकरण सरल है।\n
\n\n1.1. कनेक्शन और कॉन्फ़िगरेशन
\nbuild.gradle.kts में आवश्यक निर्भरताएँ जोड़ें:
// Spring Boot के लिए\nimplementation("io.micrometer:micrometer-registry-prometheus")\n\n// Ktor के लिए (मैन्युअल कॉन्फ़िगरेशन)\nimplementation("io.micrometer:micrometer-core:1.12.0")\nimplementation("io.micrometer:micrometer-registry-prometheus:1.12.0")\n\nSpring Boot के लिए स्वचालित रूप से एक MeterRegistry बीन बनाया जाता है। Ktor में, आपको इसे मैन्युअल रूप से इनिशियलाइज़ करना होगा:
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// /metrics एंडपॉइंट निर्यात\nembeddedServer(Netty, port = 8080) {\n routing {\n get("/metrics") {\n call.respondText(registry.scrape())\n }\n }\n}.start(wait = true)\n\n1.2. कस्टम मीट्रिक
\nमानक (JVM, CPU, मेमोरी) के अलावा, व्यावसायिक मीट्रिक जोड़ें। संसाधित ऑर्डर के काउंटर का उदाहरण:
\nval orderCounter = Counter.builder("orders.processed")\n .description("Total processed orders")\n .register(registry)\n\nfun processOrder(order: Order) {\n // व्यावसायिक तर्क\n orderCounter.increment()\n}\n\nया अनुरोध निष्पादन समय के लिए हिस्टोग्राम:
\nval 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}\n\n2. उन्नत अलर्ट: थ्रेशोल्ड मानों से भविष्यवाणियों तक
\n\nसरल थ्रेशोल्ड (जैसे, CPU > 90%) पर आधारित अलर्ट अक्सर गलत अलर्ट देते हैं। उन्नत स्तर पर, हम Alertmanager और एकत्रीकरण और पूर्वानुमान के साथ PromQL नियमों का उपयोग करते हैं।\n
\n\n2.1. Alertmanager कॉन्फ़िगरेशन
\nTelegram और Slack पर सूचनाएँ भेजने के लिए alertmanager.yml कॉन्फ़िगरेशन:
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'\n\n2.2. स्मार्ट अलर्ट के लिए PromQL नियम
\nrules.yml में एक नियम परिभाषित करें जो तब सक्रिय होता है जब प्रतिक्रिया समय का 95वाँ प्रतिशत 5 मिनट के लिए 500 ms से अधिक हो:
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