VictoriaMetrics ने मेट्रिक्स, लॉग, ट्रेस और एआई-सहायता प्राप्त समस्या-निवारण के लिए VictoriaStack लॉन्च किया

VictoriaMetrics ने VictoriaStack पेश किया है। यह एक ओपन-सोर्स ऑब्ज़र्वेबिलिटी स्टैक है, जो उसके मेट्रिक्स, लॉग और वितरित ट्रेसिंग उत्पादों को एक समन्वित परिचालन मॉडल में जोड़ता है। इस लॉन्च का उद्देश्य इंजीनियरिंग टीमों को अपने पूरे निगरानी परिवेश को बदले बिना या हर सिग्नल को एक ही डेटाबेस में डालने के लिए बाध्य किए बिना टेलीमेट्री का दायरा बढ़ाने का तरीका देना है।

VictoriaStack में मेट्रिक्स के लिए VictoriaMetrics, लॉग के लिए VictoriaLogs और ट्रेस के लिए VictoriaTraces शामिल हैं। टीमें अपनी ज़रूरत के सिग्नल अपना सकती हैं और बाद में अन्य सिग्नल जोड़ सकती हैं। साझा डिप्लॉयमेंट टूलिंग और OpenTelemetry का समर्थन इन घटकों को जोड़ने में मदद करता है।

इस घोषणा में एआई-सहायता प्राप्त परिचालन तक भी इस मॉडल का विस्तार किया गया है। आधिकारिक Model Context Protocol सर्वर और एजेंट कौशल सहायकों को पूरे स्टैक में टेलीमेट्री की जाँच करने का तरीका देते हैं, जबकि कौन-से बदलाव लागू किए जाएँ, यह तय करने की ज़िम्मेदारी इंजीनियरों की रहती है।

तीन सिग्नल, तीन विशिष्ट डेटाबेस

मेट्रिक्स, लॉग और ट्रेस अलग-अलग परिचालन संबंधी सवालों के जवाब देते हैं। मेट्रिक्स समय के साथ व्यवहार का सार देते हैं, जैसे अनुरोधों की दर, त्रुटियों की संख्या या मेमोरी की खपत। लॉग घटनाओं और उनसे जुड़ी जानकारी दर्ज करते हैं। वितरित ट्रेस किसी अनुरोध को कई सेवाओं के बीच आगे बढ़ते हुए दिखाते हैं, जिससे पता चलता है कि समय कहाँ लगा और विफलता कहाँ हुई।

किसी घटना के दौरान, इंजीनियर पहले मेट्रिक्स में विलंबता का उछाल देख सकता है, फिर ट्रेस के ज़रिए समस्या को किसी सेवा तक सीमित कर सकता है और उसके बाद मूल त्रुटि जानने के लिए लॉग देख सकता है। इन सिग्नलों को एक सुसंगत कार्यप्रवाह में लाने से जाँच तेज़ हो सकती है, बिना उनकी भंडारण आवश्यकताओं को एक जैसा बनाए।

VictoriaStack के आर्किटेक्चर संबंधी दस्तावेज़ में साझा घटक मॉडल वाले स्वतंत्र डेटाबेसों का वर्णन है। हर डेटाबेस एकल बाइनरी के रूप में या ऐसे क्लस्टर के रूप में चल सकता है जिसमें डेटा ग्रहण, भंडारण और क्वेरी के लिए अलग-अलग हिस्से हों। स्टैक रूटिंग और लोड संतुलन के प्रवेश-बिंदु के रूप में vmauth का उपयोग कर सकता है।

क्वेरी इंटरफ़ेस भी अलग-अलग बने रहते हैं: VictoriaMetrics में PromQL-संगत MetricsQL का उपयोग होता है, VictoriaLogs में LogsQL का और VictoriaTraces में LogsQL के साथ Jaeger तथा Tempo-संगत एपीआई का समर्थन है। इसलिए समन्वित परिचालन का अर्थ एक ही डेटाबेस या एक सार्वभौमिक क्वेरी भाषा नहीं है।

तीनों मुख्य डेटाबेस Apache 2.0 लाइसेंस के तहत उपलब्ध हैं। कंपनी एंटरप्राइज़ क्षमताएँ और व्यावसायिक सहायता भी देती है। इसके अलावा, वह पूरी तरह प्रबंधित VictoriaMetrics Cloud सेवा प्रदान करती है, जिसमें तीनों सिग्नलों का समर्थन है।

OpenTelemetry डेटा संग्रहण परत को जोड़ता है

OpenTelemetry, एप्लिकेशन को इंस्ट्रूमेंट करने और टेलीमेट्री निर्यात करने का एक साझा तरीका उपलब्ध कराता है। इसका OTLP प्रोटोकॉल VictoriaStack के मेट्रिक्स, लॉग और ट्रेस—तीनों में समर्थित है। इससे टीमों को डेटा अलग-अलग बैकएंड में पहुँचने के बावजूद, उसे ग्रहण करने का एक सुसंगत मार्ग मिलता है।

यह अंतर तब मायने रखता है जब कोई एप्लिकेशन कुछ सेवाओं से बढ़कर वितरित सिस्टम बन जाता है। इंस्ट्रूमेंटेशन से एप्लिकेशन के व्यवहार का वर्णन करने में मदद मिलनी चाहिए; टेलीमेट्री का गंतव्य बदलने के लिए हर सेवा के निगरानी कोड को नए सिरे से डिज़ाइन करने की ज़रूरत नहीं होनी चाहिए।

यह स्टैक ज़रूरत के अनुसार डेटा ग्रहण करने के अन्य फ़ॉर्मैट का भी समर्थन करता है। उदाहरण के लिए, Prometheus-आधारित मेट्रिक्स संग्रहण का उपयोग करने वाली टीमें उस व्यवस्था को बनाए रखते हुए उसके साथ लॉग या ट्रेसिंग जोड़ सकती हैं। प्रोटोकॉल की अनुकूलता से स्थानांतरण का काम कम होता है, जबकि डेटा कितने समय तक रखा जाए, क्षमता कितनी हो और किस तरह की क्वेरी की जाएँ—ये इंजीनियरिंग संबंधी निर्णय बने रहते हैं।

Kubernetes डिप्लॉयमेंट के लिए, VictoriaMetrics अपने ऑपरेटर और Helm चार्ट को आम प्रबंधन टूल के रूप में सुझाता है। इसका उद्देश्य डिप्लॉयमेंट और अपग्रेड को अधिक सुसंगत बनाना है, साथ ही हर सिग्नल को उसके अपने कार्यभार के अनुसार बढ़ाने की क्षमता बनाए रखना है।

एआई एजेंट टेलीमेट्री के विभिन्न सिग्नलों में जाँच कर सकते हैं

VictoriaStack एआई को दो दिशाओं से देखता है: ऑब्ज़र्वेबिलिटी सिस्टम को एजेंट-आधारित एप्लिकेशन से बनने वाली टेलीमेट्री सँभालनी चाहिए, और एआई सहायक इंजीनियरों को उस टेलीमेट्री की पड़ताल करने में मदद कर सकते हैं।

कंपनी के एआई टूल संबंधी दस्तावेज़ में मेट्रिक्स, लॉग और ट्रेस के लिए अलग-अलग MCP सर्वरों का वर्णन है। ये समय-श्रृंखलाओं की क्वेरी करने, लॉग फ़ील्ड की पड़ताल करने, सेवाओं और परिचालनों को खोजने तथा ट्रेस प्राप्त करने जैसी संरचित क्षमताएँ उपलब्ध कराते हैं। मेट्रिक्स इंटीग्रेशन में कार्डिनैलिटी, क्वेरी व्यवहार और अलर्टिंग कॉन्फ़िगरेशन की जाँच करने की सुविधा भी है।

इसका एजेंट कौशल रिपॉज़िटरी कई सिग्नलों की जाँच और उससे जुड़े परिचालन कार्यों के लिए दोबारा इस्तेमाल किए जा सकने वाले कार्यप्रवाह जोड़ता है। सहायक किसी एक डैशबोर्ड या कॉपी करके दिए गए त्रुटि संदेश पर निर्भर रहने के बजाय, अलग-अलग सिग्नलों में समस्या-निवारण की प्रक्रिया अपना सकता है।

घोषणा में Claude Code, Codex, Cursor और आंतरिक एजेंटों समेत सहायकों के लिए केवल-पढ़ने की पहुँच का वर्णन है। इससे अपेक्षित कार्यप्रवाह जाँच-केंद्रित रहता है: सबूत जुटाना, लक्षणों के बीच संबंध जोड़ना और संभावित व्याख्या सुझाना, जबकि क्या लागू किया जाए, यह इंजीनियर तय करते हैं। किसी टेलीमेट्री स्रोत को एजेंट से जोड़ने भर से यह साबित नहीं होता कि एजेंट ने मूल कारण की सही पहचान कर ली है।

डेटा ग्रहण और क्वेरी को अलग-अलग स्तर पर बढ़ाना

VictoriaStack की त्वरित शुरुआत में एकल-नोड और क्लस्टर—दोनों तरह के विन्यास दिखाए गए हैं। इसके Docker Compose डेमो में एक OpenTelemetry एप्लिकेशन और कलेक्टर, तीनों डेटाबेस, Grafana, vmalert और vmauth शामिल हैं। दस्तावेज़ स्पष्ट रूप से बताता है कि यह स्थानीय परिवेश प्रदर्शन के लिए है, न कि उत्पादन में तैनाती के लिए।

क्लस्टर मॉडल में डेटा अंतर्ग्रहण और क्वेरी घटक स्टेटलेस होते हैं और इन्हें स्वतंत्र रूप से स्केल किया जा सकता है, जबकि स्टोरेज घटक डेटा को बनाए रखते हैं। इससे अलग-अलग तरह के दबावों का प्रबंधन होता है: आने वाली टेलीमेट्री बढ़ने पर डेटा अंतर्ग्रहण क्षमता बढ़ानी पड़ सकती है, जबकि जाँच करने वाले इंजीनियरों या एजेंटों की संख्या बढ़ने से क्वेरी की माँग बढ़ सकती है।

स्टोरेज की योजना बनाना अब भी महत्वपूर्ण है। दस्तावेज़ के अनुसार, डेटाबेस टेलीमेट्री को स्थानीय फ़ाइल सिस्टम पर रखते हैं; S3 या Google Cloud Storage का इस्तेमाल बैकअप के लिए होता है, न कि ऑब्जेक्ट स्टोरेज पर आधारित क्वेरी स्तर के रूप में। इसमें यह भी बताया गया है कि स्टोरेज शार्ड की संख्या घटाना एक जटिल प्रक्रिया है। टोपोलॉजी चुनते और वृद्धि का अनुमान लगाते समय इन विशेषताओं को ध्यान में रखना महत्वपूर्ण है।

एक समन्वित स्टैक, बिना सब कुछ एक साथ स्थानांतरित किए

VictoriaMetrics, KubeCon + CloudNativeCon North America 2026 में VictoriaStack पेश कर रहा है। इसमें OTLP से इंस्ट्रूमेंट किए गए Kubernetes एप्लिकेशन का प्रदर्शन शामिल है, जो अपने तीनों टेलीमेट्री संकेतों को संबंधित बैकएंड तक भेजता है; इसके बाद विभिन्न संकेतों के बीच समस्या-निवारण की प्रक्रिया दिखाई जाती है।

VictoriaMetrics के सह-संस्थापक और इंजीनियरिंग प्रबंधक Roman Khavronenko ने घोषणा में कहा, “एजेंट-आधारित युग में टेलीमेट्री की मात्रा बढ़ेगी और इसे संसाधित करने के हमारे तरीकों से अपेक्षाएँ भी बढ़ेंगी।” उन्होंने कहा कि इस माँग के बढ़ने के साथ-साथ स्केलेबिलिटी और दक्षता को ध्यान में रखकर VictoriaStack तैयार किया गया है।

इसका व्यावहारिक प्रस्ताव चरणबद्ध रूप से अपनाना है: उपयोगी संग्रह-पारितंत्र को बनाए रखें, छूटे हुए संकेत जोड़ें और उनसे बनी सेवाओं को अधिक सुसंगत मॉडल के ज़रिए प्रबंधित करें। VictoriaStack का महत्व इस बात में है कि टेलीमेट्री की मात्रा और जाँच की माँग बढ़ने पर ये हिस्से कितनी अच्छी तरह साथ काम करते हैं—और साथ ही टीमों को यह नियंत्रण देते हैं कि उनका डेटा कहाँ रखा जाए और हर संकेत को किस तरह स्केल किया जाए।