लॉग ट्रायेज
महत्वपूर्ण घटनाएँ पहचानें- !मेमोरी खत्म / OOM घटना — 1 मेल खाती पंक्ति(एँ)।
- △प्रमाणीकरण या पहुँच विफलता — 1 मेल खाती पंक्ति(एँ)।
- △सेवा विफलता या टाइमआउट — 2 मेल खाती पंक्ति(एँ)।
परिचय
लॉग ट्रायेज चिपकाई गई journal या syslog पंक्तियों को स्कैन करता है और चार उच्च-संकेत श्रेणियों में मेल गिनता है: मेमोरी खत्म (OOM), क्रैश और डेटा अखंडता संकेत, प्रमाणीकरण विफलताएँ, और सामान्य सेवा विफलताएँ या टाइमआउट।
लॉग स्वभाव से शोरगुल वाले होते हैं। उपकरण का काम शोर को उन कुछ पंक्तियों तक कम करना है जो आमतौर पर घटना प्रतिक्रिया के योग्य होती हैं, ताकि आप सीधे प्रासंगिक संदर्भ में जा सकें।
उद्देश्य
- OOM-kill और out-of-memory घटनाएँ गिनना, जो मेमोरी दबाव दर्शाती हैं।
- क्रैश, segfault, panic और भ्रष्टाचार संकेत गिनना, जो स्थिरता या अखंडता समस्याएँ दर्शाते हैं।
- प्रमाणीकरण विफलताएँ गिनना, जो brute force या गलत कॉन्फ़िगरेशन का संकेत दे सकती हैं।
- सेवा विफलताएँ और टाइमआउट गिनना, जो खराब सिस्टमों का रोज़मर्रा का कारण हैं।
इनपुट
- journal आउटपुट (journalctl -n 500 --no-pager), syslog पंक्तियाँ या एप्लिकेशन लॉग की चिपकाई गई सामग्री।
- हर चिपकाई गई पंक्ति पर एक लॉग पंक्ति; मेल कीवर्ड-आधारित होने से कोई भी टाइमस्टैम्प प्रारूप स्वीकार्य है।
यह कैसे काम करता है
हर चिपकाई गई पंक्ति का क्रम में चार regex समूहों के विरुद्ध परीक्षण होता है: OOM कीवर्ड (out of memory, oom, killed process), क्रैश कीवर्ड (segfault, panic, corrupt), प्रमाणीकरण कीवर्ड (failed password, authentication failure, denied) और विफलता कीवर्ड (failed, error, timeout)।
हर मेल अपने समूह का काउंटर बढ़ाता है। एक पंक्ति एक से अधिक समूहों में गिन सकती है, जैसे लॉग पढ़ने वाला इंसान उसे चिह्नित करे।
बिना मेल वाले समूह परिणाम से हटा दिए जाते हैं, इसलिए शांत लॉग एक ही साफ़ परिणाम देता है।
परीक्षण योग्य उदाहरण
आज़माएँ — विश्लेषण आपके ब्राउज़र में स्थानीय रूप से चलता है।
उदाहरण
Aug 22 14:06:11 node1 kernel: Out of memory: Killed process 8492 (java) Aug 22 14:06:14 node1 sshd[9201]: Failed password for invalid user admin Aug 22 14:07:02 node1 systemd[1]: backup.service: Failed with result 'exit-code'
अपेक्षित आउटपुट
उच्च: मेमोरी खत्म / OOM घटना — 1 मेल खाती पंक्ति। चेतावनी: प्रमाणीकरण या पहुँच विफलता — 1 मेल खाती पंक्ति। चेतावनी: सेवा विफलता या टाइमआउट — 1 मेल खाती पंक्ति।
आउटपुट पढ़ना
- OOM घटनाएँ मेमोरी दबाव की ओर इशारा करती हैं: cgroup सीमाएँ, swap और मारे गए प्रक्रिया की जाँच करें।
- प्रमाणीकरण विफलताओं में देखें कि कौन कोशिश कर रहा है और कितनी बार; अमान्य उपयोगकर्ताओं के बार-बार प्रयास अक्सर स्कैनिंग या brute force दर्शाते हैं।
- सेवा विफलताओं (Failed with result 'exit-code') की जाँच journalctl -u <unit> -e से करना सबसे अच्छा है ताकि निकास कोड और आसपास की पंक्तियाँ दिखें।
जोखिम
- कीवर्ड मेल झूठे सकारात्मक पैदा करता है और संदर्भ खोता है — "no errors found" कहने वाली पंक्ति में error शब्द होता है और वह गिनी जाएगी।
- गिनती को ट्रायेज मानें, घटना का प्रमाण नहीं।
- उपकरण कभी डिस्क से आपके लॉग नहीं पढ़ता; वह केवल वही देखता है जो आप चिपकाते हैं — यही पूरी साइट का गोपनीयता डिज़ाइन है।
सीमाएँ
- यह टाइमस्टैम्प नहीं समझता, होस्टों के बीच घटनाएँ नहीं जोड़ता और क्रम नहीं पहचानता।
- regex समूह जानबूझकर सरल हैं; कस्टम पैटर्न समर्थित नहीं हैं।
- यह ट्रायेज सहायक है, SIEM नहीं।
आधिकारिक संदर्भ
FAQ
निर्दोष दिखने वाली पंक्ति त्रुटि के रूप में क्यों चिह्नित होती है?
क्योंकि मेल कीवर्ड-आधारित है। "no error found" जैसी पंक्ति में error टोकन होता है। यदि यह परेशान करे, तो चिपकाने को प्रासंगिक पंक्तियों तक सीमित करें।
OOM घटना के बाद क्या करूँ?
मारे गए प्रक्रिया की पहचान करें, उसकी मेमोरी सीमा और होस्ट का मेमोरी दबाव जाँचें, फिर तय करें: सीमाएँ बढ़ाएँ, समवर्ती घटाएँ या मेमोरी जोड़ें।
क्या यह मेरी निगरानी की जगह ले सकता है?
नहीं। यह चिपकाने के लिए मैनुअल ट्रायेज सहायक है। निरंतर निगरानी, अलर्ट और सहसंबंध के लिए उचित logging stack चाहिए।