आम्ही लॉग पाहण्यासाठी जगातील सर्वात सोयीस्कर इंटरफेस विकसित करत आहोत*

जर तुम्ही कधीही लॉग पाहण्यासाठी वेब इंटरफेस वापरले असतील, तर तुमच्या लक्षात आले असेल की, नियमानुसार, हे इंटरफेस कसे अवजड असतात आणि (बहुतेकदा) फारसे सोयीस्कर आणि प्रतिसाद देत नाहीत. काही तुम्हाला अंगवळणी पडू शकतात, काही अगदी भयंकर आहेत, परंतु मला असे वाटते की सर्व समस्यांचे कारण म्हणजे आम्ही लॉग पाहण्याच्या कामाकडे चुकीच्या पद्धतीने संपर्क साधतो: आम्ही एक वेब इंटरफेस तयार करण्याचा प्रयत्न करतो जेथे CLI (कमांड लाइन इंटरफेस) चांगले कार्य करते. मला वैयक्तिकरित्या टेल, ग्रेप, awk आणि इतरांसह काम करण्यास खूप सोयीस्कर आहे आणि म्हणूनच माझ्यासाठी लॉगसह कार्य करण्यासाठी आदर्श इंटरफेस टेल आणि ग्रेप सारखाच असेल, परंतु ज्याचा वापर अनेक सर्व्हरवरून आलेले लॉग वाचण्यासाठी देखील केला जाऊ शकतो. अर्थात, ते क्लिकहाऊसवरून वाचा!

*हब्रा वापरकर्त्याच्या वैयक्तिक मतानुसार यूरॉक

logscli ला भेटा

मी माझ्या इंटरफेससाठी नाव आणले नाही आणि खरे सांगायचे तर ते प्रोटोटाइपच्या रूपात अस्तित्वात आहे, परंतु जर तुम्हाला स्त्रोत कोड त्वरित पहायचा असेल तर तुमचे स्वागत आहे: https://github.com/YuriyNasretdinov/logscli (निवडलेल्या गो कोडच्या 350 ओळी).

वैशिष्ट्ये

माझे ध्येय एक इंटरफेस बनवणे हे होते जे टेल/ग्रेपसाठी वापरल्या जाणार्‍यांना परिचित वाटेल, म्हणजेच खालील गोष्टींना समर्थन देण्यासाठी:

1. फिल्टर न करता सर्व लॉग पहा.
2. निश्चित सबस्ट्रिंग असलेल्या ओळी सोडा (ध्वज -F у grep).
3. रेग्युलर एक्सप्रेशनशी जुळणार्‍या ओळी सोडा (ध्वज -E у grep).
4. डीफॉल्टनुसार, पाहणे उलट कालक्रमानुसार असते, कारण सर्वात अलीकडील नोंदी सहसा प्रथम स्वारस्यपूर्ण असतात.
5. प्रत्येक ओळीच्या पुढे संदर्भ दर्शवा (पर्याय -A, -B и -C у grep, अनुक्रमे प्रत्येक जुळणार्‍या ओळीच्या आधी, नंतर आणि भोवती N ओळी छापणे).
6. रिअल टाइममध्ये इनकमिंग लॉग पहा, फिल्टरिंगसह किंवा त्याशिवाय (अत्यावश्यकपणे tail -f | grep).
7. इंटरफेस सह सुसंगत असणे आवश्यक आहे less, head, tail आणि इतर - डीफॉल्टनुसार, त्यांच्या संख्येवर निर्बंध न ठेवता परिणाम परत केले जावेत; जोपर्यंत वापरकर्त्याला त्या प्राप्त करण्यात स्वारस्य आहे तोपर्यंत ओळी प्रवाह म्हणून मुद्रित केल्या जातात; सिग्नल SIGPIPE लॉग स्ट्रीमिंगमध्ये शांतपणे व्यत्यय आणला पाहिजे, जसे ते करतात tail, grep आणि इतर UNIX उपयुक्तता.

अंमलबजावणी

मी असे गृहीत धरतो की क्लिकहाऊसवर लॉग कसे वितरित करायचे हे तुम्हाला आधीच माहित आहे. नसल्यास, मी प्रयत्न करण्याची शिफारस करतो LSD и मांजरीचे घरआणि लॉग वितरण बद्दल हा लेख.

प्रथम आपल्याला बेस स्कीमवर निर्णय घेण्याची आवश्यकता आहे. तुम्‍हाला सहसा वेळेनुसार लॉग मिळवायचे असल्‍याने, ते अशा प्रकारे संग्रहित करणे तर्कसंगत वाटते. जर अनेक लॉग श्रेणी असतील आणि त्या सर्व एकाच प्रकारच्या असतील, तर तुम्ही प्राथमिक कीचा पहिला स्तंभ म्हणून लॉग श्रेणी बनवू शकता - हे तुम्हाला अनेक ऐवजी एक टेबल ठेवण्याची परवानगी देईल, जे एक मोठे प्लस असेल क्लिकहाऊसमध्ये घालणे (हार्ड ड्राइव्हसह सर्व्हरवर, प्रति सेकंद ~1 वेळा पेक्षा जास्त डेटा घालण्याची शिफारस केली जाते संपूर्ण सर्व्हरसाठी).

म्हणजेच, आम्हाला अंदाजे खालील सारणी योजनेची आवश्यकता आहे:

CREATE TABLE logs(
    category LowCardinality(String), -- категория логов (опционально)
    time DateTime, -- время события
    millis UInt16, -- миллисекунды (могут быть и микросекунды, и т.д.): рекомендуется хранить, если событий много, чтобы было легче различать события между собой
    ..., -- ваши собственные поля, например имя сервера, уровень логирования, и так далее
    message String -- текст сообщения
) ENGINE=MergeTree()
ORDER BY (category, time, millis)

दुर्दैवाने, मला ताबडतोब वास्तववादी लॉग असलेले कोणतेही खुले स्रोत सापडले नाहीत जे मी मिळवू शकलो आणि डाउनलोड करू शकलो, म्हणून मी हे उदाहरण म्हणून घेतले 2015 पूर्वी Amazon वरील उत्पादनांची पुनरावलोकने. अर्थात, त्यांची रचना मजकूर लॉग सारखीच नाही, परंतु चित्रणाच्या उद्देशाने हे महत्त्वाचे नाही.

Amazon पुनरावलोकने ClickHouse वर अपलोड करण्यासाठी सूचना

चला एक टेबल तयार करूया:

CREATE TABLE amazon(
   review_date Date,
   time DateTime DEFAULT toDateTime(toUInt32(review_date) * 86400 + rand() % 86400),
   millis UInt16 DEFAULT rand() % 1000,
   marketplace LowCardinality(String),
   customer_id Int64,
   review_id String,
   product_id LowCardinality(String),
   product_parent Int64,
   product_title String,
   product_category LowCardinality(String),
   star_rating UInt8,
   helpful_votes UInt32,
   total_votes UInt32,
   vine FixedString(1),
   verified_purchase FixedString(1),
   review_headline String,
   review_body String
)
ENGINE=MergeTree()
ORDER BY (time, millis)
SETTINGS index_granularity=8192

Amazon डेटासेटमध्ये पुनरावलोकनासाठी फक्त एक तारीख आहे, परंतु अचूक वेळ नाही, म्हणून हा डेटा रँडनसह भरूया.

10 GB RAM मध्ये न बसणारा डेटाचा बऱ्यापैकी मोठा संच मिळविण्यासाठी तुम्हाला सर्व tsv फायली डाउनलोड करण्याची आणि प्रथम ~20-16 पर्यंत मर्यादित ठेवण्याची गरज नाही. TSV फायली अपलोड करण्यासाठी मी खालील आदेश वापरला:

for i in *.tsv; do
    echo $i;
    tail -n +2 $i | pv |
    clickhouse-client --input_format_allow_errors_ratio 0.5 --query='INSERT INTO amazon(marketplace,customer_id,review_id,product_id,product_parent,product_title,product_category,star_rating,helpful_votes,total_votes,vine,verified_purchase,review_headline,review_body,review_date) FORMAT TabSeparated'
done

Google क्लाउडमध्ये 1000 GB आकाराच्या मानक पर्सिस्टंट डिस्कवर (जे HDD आहे) (मी हा आकार प्रामुख्याने घेतला आहे जेणेकरून वेग थोडा जास्त असेल, जरी आवश्यक आकाराचा SSD स्वस्त झाला असता) अपलोड 75 कोरवर वेग अंदाजे ~ 4 MB/सेकंद होता.

• मी Google वर काम करत असल्याचे आरक्षण करणे आवश्यक आहे, परंतु मी वैयक्तिक खाते वापरले आहे आणि या लेखाचा कंपनीतील माझ्या कामाशी काहीही संबंध नाही

मी या विशिष्ट डेटासेटसह सर्व चित्रे तयार करेन, कारण माझ्या हातात एवढेच आहे.

डेटा स्कॅनिंग प्रगती दर्शवा

क्लिकहाऊसमध्ये आम्ही लॉगसह टेबलवर संपूर्ण स्कॅन वापरणार आहोत आणि या ऑपरेशनला बराच वेळ लागू शकतो आणि काही जुळण्या आढळल्यास बराच काळ कोणतेही परिणाम येऊ शकत नाहीत, हे दर्शविण्यास सक्षम असणे उचित आहे. निकालासह पहिल्या पंक्ती प्राप्त होईपर्यंत क्वेरीची प्रगती. हे करण्यासाठी, HTTP इंटरफेसमध्ये एक पॅरामीटर आहे जो तुम्हाला HTTP शीर्षलेखांमध्ये प्रगती पाठविण्याची परवानगी देतो: send_progress_in_http_headers=1. दुर्दैवाने, मानक Go लायब्ररी हेडर प्राप्त झाल्यामुळे ते वाचू शकत नाही, परंतु HTTP 1.0 इंटरफेस (1.1 सह गोंधळून जाऊ नये!) क्लिकहाऊसद्वारे समर्थित आहे, त्यामुळे तुम्ही क्लिकहाऊसवर एक कच्चे TCP कनेक्शन उघडू शकता आणि ते तेथे पाठवू शकता. GET /?query=... HTTP/1.0nn आणि प्रतिसाद शीर्षलेख आणि मुख्य भाग कोणत्याही एस्केपिंग किंवा एन्क्रिप्शनशिवाय प्राप्त करा, म्हणून या प्रकरणात आम्हाला मानक लायब्ररी वापरण्याची देखील आवश्यकता नाही.

ClickHouse वरून प्रवाहित लॉग

क्लिकहाऊसमध्ये तुलनेने दीर्घ काळासाठी (2019 पासून?) ORDER BY सह क्वेरीसाठी ऑप्टिमायझेशन आहे, त्यामुळे यासारखी क्वेरी

SELECT time, millis, message
FROM logs
WHERE message LIKE '%something%'
ORDER BY time DESC, millis DESC

स्कॅन पूर्ण होण्याची प्रतीक्षा न करता, त्यांच्या संदेशात "काहीतरी" सबस्ट्रिंग असलेल्या ओळी त्वरित परत करणे सुरू करेल.

तसेच, जेव्हा त्याचे कनेक्शन बंद होते तेव्हा क्लिकहाऊसने स्वतः विनंती रद्द केली तर ते खूप सोयीचे असेल, परंतु हे डीफॉल्ट वर्तन नाही. पर्याय वापरून स्वयंचलित विनंती रद्द करणे सक्षम केले जाऊ शकते cancel_http_readonly_queries_on_client_close=1.

गो मध्ये SIGPIPE ची योग्य हाताळणी

तुम्ही कार्यान्वित केल्यावर, आज्ञा म्हणा some_cmd | head -n 10, नेमके कसे आदेश some_cmd जेव्हा अंमलबजावणी थांबते head 10 ओळी वजा केल्या? उत्तर सोपे आहे: जेव्हा head समाप्त होते, पाईप बंद होते, आणि some_cmd कमांडचा stdout, सशर्त, "कोठेही नाही" असे दर्शवू लागतो. कधी some_cmd बंद पाईपवर लिहिण्याचा प्रयत्न करतो, त्याला एक SIGPIPE सिग्नल प्राप्त होतो, जो डीफॉल्टनुसार प्रोग्राम शांतपणे बंद करतो.

गो मध्ये हे देखील डीफॉल्टनुसार घडते, परंतु SIGPIPE सिग्नल हँडलर शेवटी "signal: SIGPIPE" किंवा तत्सम संदेश देखील मुद्रित करतो आणि हा संदेश साफ करण्यासाठी आम्हाला फक्त SIGPIPE ला आम्हाला हवे तसे हाताळावे लागेल, म्हणजे फक्त शांतपणे बाहेर पडा:

ch := make(chan os.Signal)
signal.Notify(ch, syscall.SIGPIPE)
go func() {
    <-ch
    os.Exit(0)
}()

संदेश संदर्भ दर्शवा

बर्‍याचदा तुम्हाला तो संदर्भ पहायचा असतो ज्यामध्ये काही त्रुटी आली होती (उदाहरणार्थ, कोणत्या विनंतीमुळे भीती निर्माण झाली होती किंवा क्रॅश होण्यापूर्वी कोणत्या संबंधित समस्या दिसत होत्या) आणि grep हे -A, -B, आणि -C पर्याय वापरून केले जाते, जे अनुक्रमे संदेशाच्या नंतर, आधी आणि आसपासच्या ओळींची निर्दिष्ट संख्या दर्शवतात.

दुर्दैवाने, मला क्लिकहाऊसमध्ये असे करण्याचा सोपा मार्ग सापडला नाही, त्यामुळे संदर्भ प्रदर्शित करण्यासाठी, यासारखी अतिरिक्त विनंती निकालाच्या प्रत्येक ओळीवर पाठविली जाते (तपशील वर्गीकरणावर अवलंबून असते आणि संदर्भ आधी दर्शविला जातो की नाही. किंवा नंतर):

SELECT time,millis,review_body FROM amazon
WHERE (time = 'ВРЕМЯ_СОБЫТИЯ' AND millis < МИЛЛИСЕКУНДЫ_СОБЫТИЯ) OR (time < 'ВРЕМЯ_СОБЫТИЯ')
ORDER BY time DESC, millis DESC
LIMIT КОЛИЧЕСТВО_СТРОК_КОНТЕКСТА
SETTINGS max_threads=1

क्लिकहाऊसने संबंधित ओळ परत केल्यावर जवळजवळ लगेच विनंती पाठवली जात असल्याने, ती कॅशेमध्ये संपते आणि सर्वसाधारणपणे विनंती खूप लवकर अंमलात आणली जाते आणि थोडासा CPU वापरतो (सामान्यत: माझ्या व्हर्च्युअल मशीनवर विनंतीला सुमारे ~6 ms लागतात).

रिअल टाइममध्ये नवीन संदेश दर्शवा

येणारे संदेश (जवळजवळ) रिअल टाइममध्ये दर्शविण्यासाठी, आम्ही याआधी आलेल्या शेवटच्या टाइमस्टॅम्पला लक्षात ठेवून दर काही सेकंदांनी एकदा विनंती कार्यान्वित करतो.

आज्ञा उदाहरणे

सराव मध्ये ठराविक logscli कमांड्स कशा दिसतात?

मी लेखाच्या सुरुवातीला नमूद केलेला Amazon डेटासेट तुम्ही डाउनलोड केला असेल, तर तुम्ही खालील आदेश चालवू शकता:

# Показать строки, где встречается слово walmart
$ logscli -F 'walmart' | less

# Показать самые свежие 10 строк, где встречается "terrible"
$ logscli -F terrible -limit 10

# То же самое без -limit:
$ logscli -F terrible | head -n 10

# Показать все строки, подходящие под /times [0-9]/, написанные для vine и у которых высокий рейтинг
$ logscli -E 'times [0-9]' -where="vine='Y' AND star_rating>4" | less

# Показать все строки со словом "panic" и 3 строки контекста вокруг
$ logscli -F 'panic' -C 3 | less

# Непрерывно показывать новые строки со словом "5-star"
$ logscli -F '5-star' -tailf

संदर्भ

युटिलिटी कोड (दस्तऐवजीकरणाशिवाय) गीथहब येथे उपलब्ध आहे https://github.com/YuriyNasretdinov/logscli. क्लिकहाऊसवर आधारित लॉग पाहण्यासाठी कन्सोल इंटरफेससाठी माझ्या कल्पनेबद्दल तुमचे विचार ऐकून मला आनंद होईल.

स्त्रोत: www.habr.com