យើងកំពុងបង្កើតចំណុចប្រទាក់ងាយស្រួលបំផុតក្នុងពិភពលោក* សម្រាប់ការមើលកំណត់ហេតុ

ប្រសិនបើអ្នកធ្លាប់ប្រើចំណុចប្រទាក់បណ្ដាញដើម្បីមើលកំណត់ហេតុ នោះអ្នកប្រហែលជាបានកត់សម្គាល់ពីរបៀបដែល ជាធម្មតា ចំណុចប្រទាក់ទាំងនេះមានភាពលំបាក ហើយ (ជាញឹកញាប់) មិនងាយស្រួល និងឆ្លើយតប។ អ្នក​ខ្លះ​អាច​ប្រើ​បាន ខ្លះ​ពិត​ជា​អាក្រក់​ណាស់ ប៉ុន្តែ​វា​ហាក់​ដូច​ជា​ខ្ញុំ​ថា​ហេតុផល​នៃ​បញ្ហា​ទាំង​អស់​គឺ​ថា​យើង​ខិត​ជិត​កិច្ចការ​នៃ​ការ​មើល​កំណត់​ហេតុ​មិន​ត្រឹមត្រូវ៖ យើង​ព្យាយាម​បង្កើត​ចំណុច​ប្រទាក់​បណ្ដាញ​ដែល CLI (ចំណុច​ប្រទាក់​បន្ទាត់​ពាក្យ​បញ្ជា) ដំណើរការកាន់តែប្រសើរ។ ខ្ញុំផ្ទាល់មានផាសុកភាពណាស់ក្នុងការធ្វើការជាមួយ tail, grep, awk និងផ្សេងទៀត ដូច្នេះហើយសម្រាប់ខ្ញុំ ចំណុចប្រទាក់ដ៏ល្អសម្រាប់ធ្វើការជាមួយកំណត់ហេតុនឹងជាអ្វីមួយដែលស្រដៀងទៅនឹង tail និង grep ប៉ុន្តែវាក៏អាចត្រូវបានប្រើដើម្បីអានកំណត់ហេតុដែលបានមកពីម៉ាស៊ីនមេជាច្រើន។ នោះគឺជាការពិតណាស់ អានពួកវាពី ClickHouse!

* យោងទៅតាមគំនិតផ្ទាល់ខ្លួនរបស់អ្នកប្រើ habra អ្នករ៉ុក

ជួប logscli

ខ្ញុំមិនបានបង្កើតឈ្មោះសម្រាប់ចំណុចប្រទាក់របស់ខ្ញុំទេ ហើយនិយាយឱ្យត្រង់ទៅ វាមានទម្រង់ជាគំរូ ប៉ុន្តែប្រសិនបើអ្នកចង់ឃើញកូដប្រភពភ្លាមៗនោះ អ្នកត្រូវបានស្វាគមន៍៖ https://github.com/YuriyNasretdinov/logscli (350 ជួរនៃលេខកូដ Go ដែលបានជ្រើសរើស) ។

លក្ខណៈពិសេស

គោលដៅរបស់ខ្ញុំគឺដើម្បីបង្កើតចំណុចប្រទាក់មួយដែលហាក់ដូចជាស៊ាំនឹងអ្នកដែលធ្លាប់ប្រើដើម្បីកន្ទុយ / grep ពោលគឺដើម្បីគាំទ្រអ្វីៗដូចខាងក្រោមៈ

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 និងឧបករណ៍ប្រើប្រាស់យូនីកផ្សេងទៀត។

Реализация

ខ្ញុំនឹងសន្មត់ថាអ្នកដឹងពីរបៀបបញ្ជូនកំណត់ហេតុទៅ ClickHouse រួចហើយ។ បើមិនដូច្នោះទេខ្ញុំសូមណែនាំឱ្យសាកល្បងវា។ LSD и ផ្ទះកូនឆ្មា, ក៏ដូចជា អត្ថបទនេះអំពីការចែកចាយកំណត់ហេតុ.

ដំបូងអ្នកត្រូវសម្រេចចិត្តលើគ្រោងការណ៍មូលដ្ឋាន។ ដោយសារជាធម្មតាអ្នកចង់ទទួលកំណត់ហេតុដែលតម្រៀបតាមពេលវេលា វាហាក់ដូចជាសមហេតុផលក្នុងការរក្សាទុកវាតាមរបៀបនោះ។ ប្រសិនបើមានប្រភេទកំណត់ហេតុជាច្រើន ហើយពួកវាសុទ្ធតែជាប្រភេទដូចគ្នា នោះអ្នកអាចបង្កើតប្រភេទកំណត់ហេតុជាជួរទីមួយនៃសោចម្បង - វានឹងអនុញ្ញាតឱ្យអ្នកមានតារាងមួយជំនួសឱ្យចំនួនជាច្រើន ដែលវានឹងជាការបូកធំនៅពេល ការបញ្ចូលទៅក្នុង ClickHouse (នៅលើម៉ាស៊ីនមេដែលមានដ្រាយវ៍រឹង វាត្រូវបានណែនាំឱ្យបញ្ចូលទិន្នន័យមិនលើសពី ~ 1 ដងក្នុងមួយវិនាទី សម្រាប់ម៉ាស៊ីនមេទាំងមូល).

នោះគឺយើងត្រូវការគ្រោងការណ៍តារាងដូចខាងក្រោម:

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

ជាអកុសល ខ្ញុំមិនអាចរកបានភ្លាមៗនូវប្រភពបើកចំហដែលមានកំណត់ហេតុជាក់ស្តែងដែលខ្ញុំអាចទាញយក និងទាញយកបានទេ ដូច្នេះខ្ញុំបានយកវាមកធ្វើជាឧទាហរណ៍ជំនួសវិញ។ ការពិនិត្យឡើងវិញនៃផលិតផលពី Amazon រហូតដល់ឆ្នាំ 2015. ជាការពិតណាស់ រចនាសម្ព័នរបស់ពួកគេមិនដូចគ្នាទៅនឹងកំណត់ហេតុអត្ថបទនោះទេ ប៉ុន្តែសម្រាប់គោលបំណងគំនូរនេះមិនសំខាន់ទេ។

ការណែនាំសម្រាប់ការបង្ហោះការពិនិត្យមើល 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 មានតែកាលបរិច្ឆេទសម្រាប់ការពិនិត្យឡើងវិញ ប៉ុន្តែមិនមានពេលវេលាច្បាស់លាស់ទេ ដូច្នេះសូមបំពេញទិន្នន័យនេះដោយ randon ។

អ្នកមិនចាំបាច់ទាញយកឯកសារ tsv ទាំងអស់ ហើយដាក់កម្រិតខ្លួនឯងត្រឹម ~10-20 ដំបូងឡើយ ដើម្បីទទួលបានសំណុំទិន្នន័យធំល្មមដែលនឹងមិនសមនឹង RAM ទំហំ 16 GB នោះទេ។ ដើម្បីផ្ទុកឡើងឯកសារ 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

នៅលើស្តង់ដារ Persistent Disk (ដែលជា HDD) នៅក្នុង Google Cloud ដែលមានទំហំ 1000 GB (ខ្ញុំបានយកទំហំនេះជាចម្បងដើម្បីឱ្យល្បឿនខ្ពស់ជាងបន្តិច បើទោះបីជា SSD នៃទំហំដែលត្រូវការនឹងមានតម្លៃថោកជាងក៏ដោយ) ការអាប់ឡូត ល្បឿនគឺប្រហែល ~ 75 MB / វិនាទីនៅលើ 4 cores ។

• ខ្ញុំត្រូវតែធ្វើការកក់ទុកដែលខ្ញុំធ្វើការនៅ Google ប៉ុន្តែខ្ញុំបានប្រើគណនីផ្ទាល់ខ្លួន ហើយអត្ថបទនេះមិនមានពាក់ព័ន្ធនឹងការងាររបស់ខ្ញុំនៅក្រុមហ៊ុនទេ

ខ្ញុំនឹងផលិតរូបភាពទាំងអស់ជាមួយនឹងសំណុំទិន្នន័យពិសេសនេះ ព្រោះនេះជាអ្វីដែលខ្ញុំមាននៅក្នុងដៃ។

បង្ហាញដំណើរការស្កេនទិន្នន័យ

ដោយសារនៅក្នុង ClickHouse យើងនឹងប្រើការស្កេនពេញលេញនៅលើតុដែលមានកំណត់ហេតុ ហើយប្រតិបត្តិការនេះអាចចំណាយពេលច្រើន ហើយប្រហែលជាមិនបង្កើតលទ្ធផលណាមួយក្នុងរយៈពេលយូរ ប្រសិនបើការផ្គូផ្គងពីរបីត្រូវបានរកឃើញ វាគួរតែអាចបង្ហាញ ដំណើរការនៃសំណួររហូតដល់ជួរទីមួយដែលមានលទ្ធផលត្រូវបានទទួល។ ដើម្បីធ្វើដូចនេះមានប៉ារ៉ាម៉ែត្រនៅក្នុងចំណុចប្រទាក់ HTTP ដែលអនុញ្ញាតឱ្យអ្នកផ្ញើវឌ្ឍនភាពនៅក្នុងបឋមកថា HTTP៖ send_progress_in_http_headers=1. ជាអកុសល បណ្ណាល័យ Go ស្តង់ដារមិនអាចអានបឋមកថាដូចដែលពួកគេត្រូវបានទទួលទេ ប៉ុន្តែចំណុចប្រទាក់ HTTP 1.0 (មិនត្រូវច្រឡំជាមួយ 1.1!) ត្រូវបានគាំទ្រដោយ ClickHouse ដូច្នេះអ្នកអាចបើកការតភ្ជាប់ TCP ឆៅទៅ ClickHouse ហើយផ្ញើវានៅទីនោះ។ GET /?query=... HTTP/1.0nn ហើយទទួលបានបឋមកថា និងតួនៃការឆ្លើយតបដោយមិនមានការគេចចេញ ឬការអ៊ិនគ្រីបណាមួយឡើយ ដូច្នេះក្នុងករណីនេះ យើងមិនចាំបាច់ប្រើបណ្ណាល័យស្តង់ដារទេ។

ការផ្សាយកំណត់ហេតុពី ClickHouse

ClickHouse មានការបង្កើនប្រសិទ្ធភាពសម្រាប់សំណួរជាមួយ ORDER BY អស់រយៈពេលជាយូរមកហើយ (ចាប់តាំងពីឆ្នាំ 2019?) ដូច្នេះសំណួរដូចជា

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

វានឹងចាប់ផ្តើមត្រឡប់បន្ទាត់ដែលមានខ្សែអក្សររង "អ្វីមួយ" នៅក្នុងសារភ្លាមៗ ដោយមិនចាំបាច់រង់ចាំការស្កេនបញ្ចប់នោះទេ។

ដូចគ្នានេះផងដែរវានឹងមានភាពងាយស្រួលប្រសិនបើ ClickHouse ខ្លួនវាលុបចោលសំណើនៅពេលដែលការតភ្ជាប់ទៅវាត្រូវបានបិទ ប៉ុន្តែនេះមិនមែនជាឥរិយាបថលំនាំដើមនោះទេ។ ការលុបចោលសំណើដោយស្វ័យប្រវត្តិអាចត្រូវបានបើកដោយប្រើជម្រើស cancel_http_readonly_queries_on_client_close=1.

ការគ្រប់គ្រងត្រឹមត្រូវនៃ SIGPIPE នៅក្នុង Go

នៅពេលអ្នកប្រតិបត្តិពាក្យបញ្ជា some_cmd | head -n 10របៀបដែលពាក្យបញ្ជា some_cmd បញ្ឈប់ការប្រតិបត្តិនៅពេលណា head ដក ១០ ជួរ? ចម្លើយគឺសាមញ្ញ៖ ពេលណា head ចុងបញ្ចប់ បំពង់នឹងបិទ ហើយ stdout នៃពាក្យបញ្ជា some_cmd ចាប់ផ្តើមចង្អុលតាមលក្ខខណ្ឌ "ទៅកន្លែងណា"។ ពេលណា​ some_cmd ព្យាយាមសរសេរទៅបំពង់បិទ វាទទួលបានសញ្ញា SIGPIPE ដែលបិទកម្មវិធីដោយស្ងៀមស្ងាត់តាមលំនាំដើម.

នៅក្នុង Go វាកើតឡើងតាមលំនាំដើម ប៉ុន្តែឧបករណ៍ដោះស្រាយសញ្ញា SIGPIPE ក៏បោះពុម្ព "សញ្ញា: SIGPIPE" ឬសារស្រដៀងគ្នានៅចុងបញ្ចប់ ហើយដើម្បីលុបសារនេះ យើងគ្រាន់តែត្រូវការដោះស្រាយ SIGPIPE ខ្លួនយើងតាមវិធីដែលយើងចង់បាន ពោលគឺគ្រាន់តែស្ងាត់ប៉ុណ្ណោះ។ ចេញ៖

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

បង្ហាញបរិបទសារ

ជាញឹកញាប់អ្នកចង់ឃើញបរិបទដែលកំហុសមួយចំនួនបានកើតឡើង (ឧទាហរណ៍ សំណើដែលបណ្តាលឱ្យមានការភ័យស្លន់ស្លោ ឬបញ្ហាដែលពាក់ព័ន្ធត្រូវបានមើលឃើញមុនពេលគាំង) និងនៅក្នុង grep នេះត្រូវបានធ្វើដោយប្រើជម្រើស -A, -B, និង -C ដែលបង្ហាញចំនួនបន្ទាត់ដែលបានបញ្ជាក់បន្ទាប់ពី មុន និងជុំវិញសាររៀងៗខ្លួន។

ជាអកុសល ខ្ញុំមិនបានរកឃើញវិធីងាយស្រួលក្នុងការធ្វើដូចគ្នានេះនៅក្នុង ClickHouse ទេ ដូច្នេះដើម្បីបង្ហាញបរិបទ សំណើបន្ថែមបែបនេះត្រូវបានផ្ញើទៅកាន់បន្ទាត់នីមួយៗនៃលទ្ធផល (ព័ត៌មានលម្អិតអាស្រ័យលើការតម្រៀប និងថាតើបរិបទត្រូវបានបង្ហាញពីមុនឬអត់។ ឬបន្ទាប់ពី):

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

ដោយសារសំណើត្រូវបានផ្ញើស្ទើរតែភ្លាមៗបន្ទាប់ពី ClickHouse ត្រឡប់បន្ទាត់ដែលត្រូវគ្នា វាបញ្ចប់នៅក្នុងឃ្លាំងសម្ងាត់ ហើយជាទូទៅសំណើត្រូវបានប្រតិបត្តិយ៉ាងលឿន ហើយប្រើប្រាស់ស៊ីភីយូតិចតួច (ជាធម្មតាសំណើត្រូវចំណាយពេលប្រហែល ~ 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

សេចក្តីយោង

លេខកូដឧបករណ៍ប្រើប្រាស់ (ដោយគ្មានឯកសារ) មាននៅលើ github នៅ https://github.com/YuriyNasretdinov/logscli. ខ្ញុំនឹងរីករាយក្នុងការស្តាប់គំនិតរបស់អ្នកលើគំនិតរបស់ខ្ញុំសម្រាប់ចំណុចប្រទាក់កុងសូលសម្រាប់ការមើលកំណត់ហេតុដោយផ្អែកលើ ClickHouse ។

ប្រភព: www.habr.com