रस्ट अनुप्रयोगों की निगरानी: उन्नत स्तर पर मीट्रिक और अलर्ट

शुरुआती लोगों के लिए ऑनलाइन Python प्रशिक्षक

Python आसानी से सीखें बिना सिद्धांत के बोझ के। स्वचालित जांच के साथ व्यावहारिक कार्य हल करें और ब्राउज़र में सीधे कोड लिखें।

पाठ्यक्रम शुरू करें

परिचय: रस्ट अनुप्रयोगों की निगरानी क्यों एक चुनौती और अवसर है

\n\n

Rust अपने प्रदर्शन और मेमोरी सुरक्षा के लिए प्रसिद्ध है। हालाँकि, जब आपका एप्लिकेशन हार्डवेयर की क्षमताओं की सीमा पर काम करता है (उदाहरण के लिए, उच्च-लोड WebSocket सर्वर या डेटा पार्सर), तो मानक CPU और RAM मीट्रिक अक्सर अपर्याप्त साबित होते हैं। उन्नत स्तर पर, रस्ट अनुप्रयोगों की निगरानी के लिए केवल डेटा एकत्र करना नहीं, बल्कि अलर्ट की एक सटीक प्रणाली बनाना आवश्यक है जो विफलता होने से पहले ही उसकी भविष्यवाणी कर सके।

\n\n

इस लेख में, हम देखेंगे कि रस्ट के लिए production-ready निगरानी प्रणाली कैसे बनाई जाए: prometheus crate का उपयोग करके कस्टम मीट्रिक से लेकर Alertmanager और Grafana के माध्यम से अलर्ट सेटअप तक।

\n\n

1. उन्नत मीट्रिक: केवल HTTP अनुरोध नहीं

\n\n

बुनियादी निगरानी (अनुरोधों की संख्या, विलंबता) न्यूनतम है। उन्नत स्तर पर, हम ऐसे मीट्रिक एकत्र करते हैं जो एप्लिकेशन की आंतरिक स्थिति को दर्शाते हैं: कतारों का आकार, Tokio में सक्रिय कार्यों की संख्या, कनेक्शन पूल की स्थिति।

\n\n

1.1. Histogram और Gauge प्रकार के साथ कस्टम मीट्रिक

\n\n

हम prometheus crate का उपयोग करते हैं। डेटाबेस कनेक्शन पूल के लिए मीट्रिक संग्रह का एक उदाहरण देखें:

\n\n
use prometheus::{HistogramOpts, HistogramVec, Gauge, register_histogram_vec, register_gauge};\nuse lazy_static::lazy_static;\n\nlazy_static! {\n    static ref DB_CONNECTION_POOL: Gauge = register_gauge!(\n        "db_connection_pool_size",\n        "पूल में सक्रिय कनेक्शनों की वर्तमान संख्या"\n    ).unwrap();\n\n    static ref DB_QUERY_DURATION: HistogramVec = register_histogram_vec!(\n        HistogramOpts::new("db_query_duration_seconds", "DB क्वेरी निष्पादन समय"),\n        &["query_type", "status"]\n    ).unwrap();\n}\n\n// कोड में उपयोग\nfn execute_query(query_type: &str) -> Result<(), String> {\n    DB_CONNECTION_POOL.inc();\n    let start = std::time::Instant::now();\n    // ... क्वेरी निष्पादन ...\n    let duration = start.elapsed().as_secs_f64();\n    DB_QUERY_DURATION.with_label_values(&[query_type, "success"]).observe(duration);\n    DB_CONNECTION_POOL.dec();\n    Ok(())\n}
\n\n

महत्वपूर्ण: प्रकार (SELECT, INSERT) और स्थिति (success, error) के अनुसार क्वेरी को वर्गीकृत करने के लिए HistogramVec का उपयोग करें। यह Grafana में हीट मैप बनाने की अनुमति देगा।

\n\n

1.2. Tokio रनटाइम के अंदर से मीट्रिक

\n\n

एसिंक्रोनस अनुप्रयोगों के लिए, शेड्यूलर लोड को जानना महत्वपूर्ण है। हम tokio-metrics का उपयोग करते हैं:

\n\n
use tokio_metrics::RuntimeMetrics;\nuse std::sync::Arc;\n\nasync fn monitor_runtime(metrics: Arc<RuntimeMetrics>) {\n    loop {\n        tokio::time::sleep(std::time::Duration::from_secs(5)).await;\n        let num_alive_tasks = metrics.num_alive_tasks();\n        let blocking_threads = metrics.num_blocking_threads();\n        // इन मानों को Gauge के माध्यम से Prometheus को भेजें\n        println!("सक्रिय कार्य: {}, ब्लॉकिंग थ्रेड: {}", num_alive_tasks, blocking_threads);\n    }\n}
\n\n

ये मीट्रिक कार्य लीक (जब num_alive_tasks लगातार बढ़ता है) या block_in_place के अत्यधिक उपयोग की पहचान करने में मदद करते हैं।

\n\n

2. मीट्रिक संग्रह की वास्तुकला: Push बनाम Pull

\n\n

Rust पारिस्थितिकी तंत्र में, Pull मॉडल (Prometheus scraper) का अधिक उपयोग किया जाता है, लेकिन अल्पकालिक प्रक्रियाओं (CLI उपयोगिताओं, पार्सर) के लिए, Pushgateway के माध्यम से Push दृष्टिकोण सुविधाजनक है।

\n\n

2.1. Pull मॉडल: HTTP एंडपॉइंट

\n\n

मानक तरीका आपके एप्लिकेशन के अंदर पोर्ट 9090 (या अन्य) पर एक अलग HTTP सर्वर शुरू करना है:

\n\n
use warp::Filter;\nuse prometheus::{Encoder, TextEncoder};\n\nasync fn metrics_handler() -> Result<impl warp::Reply, warp::Rejection> {\n    let metric_families = prometheus::gather();\n    let mut buffer = Vec::new();\n    let encoder = TextEncoder::new();\n    encoder.encode(&metric_families, &mut buffer).unwrap();\n    Ok(warp::reply::with_header(bu                

ब्लॉग

पुस्तक अनुशंसाएँ