🥇ចូល Kubernetes (មិនត្រឹមតែប៉ុណ្ណោះ) ថ្ងៃនេះ៖ ការរំពឹងទុក និងការពិត

វាជាឆ្នាំ 2019 ហើយយើងនៅតែមិនមានដំណោះស្រាយស្តង់ដារសម្រាប់ការប្រមូលផ្តុំកំណត់ហេតុនៅក្នុង Kubernetes ទេ។ នៅក្នុងអត្ថបទនេះ យើងចង់ប្រើឧទាហរណ៍ពីការអនុវត្តជាក់ស្តែង ដើម្បីចែករំលែកការស្វែងរករបស់យើង បញ្ហាដែលបានជួបប្រទះ និងដំណោះស្រាយរបស់ពួកគេ។

ទោះយ៉ាងណាក៏ដោយ ជាដំបូង ខ្ញុំនឹងធ្វើការកក់ទុក ដែលអតិថិជនផ្សេងគ្នាយល់អំពីរឿងខុសគ្នាខ្លាំង ដោយប្រមូលកំណត់ហេតុ៖

នរណាម្នាក់ចង់ឃើញកំណត់ហេតុសុវត្ថិភាព និងសវនកម្ម;
នរណាម្នាក់ - ការកាប់ឈើកណ្តាលនៃហេដ្ឋារចនាសម្ព័ន្ធទាំងមូល;
ហើយសម្រាប់អ្នកខ្លះ វាគ្រប់គ្រាន់ក្នុងការប្រមូលតែកំណត់ហេតុកម្មវិធីប៉ុណ្ណោះ ដោយមិនរាប់បញ្ចូលឧទាហរណ៍ តុល្យការ។

ខាងក្រោមនេះគឺជាការកាត់ខាងក្រោមអំពីរបៀបដែលយើងអនុវត្ត "បញ្ជីប្រាថ្នា" ផ្សេងៗ និងការលំបាកអ្វីខ្លះដែលយើងជួបប្រទះ។

ទ្រឹស្តី៖ អំពីឧបករណ៍កាប់ឈើ

ផ្ទៃខាងក្រោយនៅលើសមាសធាតុនៃប្រព័ន្ធកំណត់ហេតុ

ការកាប់ឈើបានកើតឡើងជាយូរមកហើយ ដែលជាលទ្ធផលដែលវិធីសាស្ត្រសម្រាប់ប្រមូល និងវិភាគកំណត់ហេតុត្រូវបានបង្កើតឡើង ដែលជាអ្វីដែលយើងប្រើសព្វថ្ងៃ។ ត្រលប់ទៅទសវត្សរ៍ឆ្នាំ 1950 ក្រុមហ៊ុន Fortran បានណែនាំ analogue នៃស្ទ្រីមបញ្ចូល/ទិន្នផលស្តង់ដារ ដែលជួយអ្នកសរសេរកម្មវិធីបំបាត់កំហុសកម្មវិធីរបស់គាត់។ ទាំងនេះគឺជាកំណត់ហេតុកុំព្យូទ័រដំបូងគេដែលធ្វើឲ្យជីវិតកាន់តែងាយស្រួលសម្រាប់អ្នកសរសេរកម្មវិធីនៅសម័យនោះ។ សព្វថ្ងៃនេះយើងឃើញនៅក្នុងពួកគេនូវធាតុផ្សំដំបូងនៃប្រព័ន្ធកាប់ឈើ - ប្រភព ឬ "អ្នកផលិត" នៃកំណត់ហេតុ.

វិទ្យាសាស្ត្រកុំព្យូទ័រមិននៅស្ងៀមទេ៖ បណ្តាញកុំព្យូទ័របានលេចចេញជាចង្កោមដំបូង... ប្រព័ន្ធស្មុគស្មាញដែលមានកុំព្យូទ័រជាច្រើនចាប់ផ្តើមដំណើរការ។ ឥឡូវនេះ អ្នកគ្រប់គ្រងប្រព័ន្ធត្រូវបានបង្ខំឱ្យប្រមូលកំណត់ហេតុពីម៉ាស៊ីនជាច្រើន ហើយក្នុងករណីពិសេស ពួកគេអាចបន្ថែមសារខឺណែល OS ក្នុងករណីដែលពួកគេត្រូវការដើម្បីស៊ើបអង្កេតការបរាជ័យនៃប្រព័ន្ធ។ ដើម្បីពិពណ៌នាអំពីប្រព័ន្ធប្រមូលកំណត់ហេតុកណ្តាល នៅដើមទសវត្សរ៍ឆ្នាំ 2000 វាត្រូវបានបោះពុម្ពផ្សាយ RFC 3164ដែលជាស្តង់ដារ remote_syslog ។ នេះជារបៀបដែលសមាសធាតុសំខាន់មួយទៀតបានបង្ហាញខ្លួន៖ អ្នកប្រមូលឈើ និងការផ្ទុករបស់ពួកគេ។

ជាមួយនឹងការកើនឡើងនៃបរិមាណកំណត់ហេតុ និងការណែនាំយ៉ាងទូលំទូលាយនៃបច្ចេកវិទ្យាគេហទំព័រ សំណួរបានកើតឡើងអំពីអ្វីដែលកំណត់ហេតុត្រូវបង្ហាញយ៉ាងងាយស្រួលដល់អ្នកប្រើប្រាស់។ ឧបករណ៍កុងសូលសាមញ្ញ (awk/sed/grep) ត្រូវបានជំនួសដោយឧបករណ៍ទំនើបជាងមុន អ្នកមើលកំណត់ហេតុ - សមាសភាគទីបី។

ដោយសារតែការកើនឡើងនៃបរិមាណនៃកំណត់ហេតុ អ្វីផ្សេងទៀតបានក្លាយជាច្បាស់លាស់: កំណត់ហេតុគឺចាំបាច់ ប៉ុន្តែមិនមែនទាំងអស់នោះទេ។ ហើយកំណត់ហេតុផ្សេងគ្នាទាមទារកម្រិតផ្សេងគ្នានៃការរក្សាទុក៖ ខ្លះអាចបាត់បង់ក្នុងមួយថ្ងៃ ខណៈខ្លះទៀតត្រូវរក្សាទុករយៈពេល ៥ ឆ្នាំ។ ដូច្នេះ សមាសធាតុសម្រាប់ត្រង និងបញ្ជូនលំហូរទិន្នន័យត្រូវបានបញ្ចូលទៅក្នុងប្រព័ន្ធកត់ត្រា - តោះហៅវាថា ត្រង.

ការផ្ទុកក៏បានធ្វើឱ្យមានការលោតផ្លោះដ៏ធំមួយផងដែរ៖ ពីឯកសារធម្មតាទៅកាន់មូលដ្ឋានទិន្នន័យដែលទាក់ទង ហើយបន្ទាប់មកទៅកាន់ការផ្ទុកឯកសារដែលតម្រង់ទិស (ឧទាហរណ៍ Elasticsearch)។ ដូច្នេះការផ្ទុកត្រូវបានបំបែកចេញពីអ្នកប្រមូល។

នៅទីបំផុត គោលគំនិតនៃកំណត់ហេតុបានពង្រីកទៅជាប្រភេទនៃព្រឹត្តិការណ៍អរូបី ដែលយើងចង់រក្សាទុកសម្រាប់ប្រវត្តិសាស្ត្រ។ ឬផ្ទុយទៅវិញ ក្នុងករណីដែលអ្នកត្រូវការធ្វើការស៊ើបអង្កេត ឬបង្កើតរបាយការណ៍វិភាគ...

ជាលទ្ធផល ក្នុងរយៈពេលដ៏ខ្លីមួយ ការប្រមូលកំណត់ហេតុបានអភិវឌ្ឍទៅជាប្រព័ន្ធរងដ៏សំខាន់ ដែលអាចត្រូវបានគេហៅថាត្រឹមត្រូវមួយផ្នែករងនៅក្នុងទិន្នន័យធំ។

ប្រសិនបើនៅពេលមួយការបោះពុម្ពធម្មតាអាចគ្រប់គ្រាន់សម្រាប់ "ប្រព័ន្ធកំណត់ហេតុ" ឥឡូវនេះស្ថានភាពបានផ្លាស់ប្តូរច្រើន។

Kubernetes និងកំណត់ហេតុ

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

សម្លឹងមើលទៅមុខ ខ្ញុំអាចបញ្ជាក់បានថា ឥឡូវនេះ ជាអកុសល មិនមានជម្រើសការកត់ត្រាតាមស្តង់ដារសម្រាប់ Kubernetes ដែលនឹងប្រៀបធៀបដោយអនុគ្រោះជាមួយអ្នកដទៃទាំងអស់។ គ្រោងការណ៍ពេញនិយមបំផុតនៅក្នុងសហគមន៍មានដូចខាងក្រោម:

នរណាម្នាក់ពន្លាជង់ អេហ្វខេ (Elasticsearch, Fluentd, Kibana);
មាននរណាម្នាក់កំពុងសាកល្បងការចេញផ្សាយថ្មីៗនេះ ឡូកូ или использует ប្រតិបត្តិករកាប់ឈើ;
ពួកយើង (ហើយប្រហែលជាមិនត្រឹមតែយើងទេ? .. ) ខ្ញុំពេញចិត្តនឹងការអភិវឌ្ឍន៍ខ្លួនឯង - ផ្ទះឈើ...

តាមក្បួនមួយ យើងប្រើបណ្តុំខាងក្រោមនៅក្នុងចង្កោម K8s (សម្រាប់ដំណោះស្រាយដែលបង្ហោះដោយខ្លួនឯង)៖

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

អនុវត្តជាមួយកំណត់ហេតុក្នុង K8s

"កំណត់ហេតុប្រចាំថ្ងៃ" តើអ្នកមានប៉ុន្មាននាក់?...

ការប្រមូលឈើជាកណ្តាលពីហេដ្ឋារចនាសម្ព័ន្ធធំគួរសម ទាមទារធនធានយ៉ាងច្រើន ដែលនឹងត្រូវចំណាយលើការប្រមូល រក្សាទុក និងដំណើរការកំណត់ហេតុ។ ក្នុងអំឡុងពេលប្រតិបត្តិការនៃគម្រោងផ្សេងៗ យើងត្រូវប្រឈមមុខនឹងតម្រូវការផ្សេងៗ និងបញ្ហាប្រតិបត្តិការដែលកើតចេញពីពួកគេ។

តោះសាកល្បង ClickHouse

សូមក្រឡេកមើលទំហំផ្ទុកកណ្តាលនៅលើគម្រោងដែលមានកម្មវិធីដែលបង្កើតកំណត់ហេតុយ៉ាងសកម្ម៖ ច្រើនជាង 5000 បន្ទាត់ក្នុងមួយវិនាទី។ ចូរចាប់ផ្តើមធ្វើការជាមួយកំណត់ហេតុរបស់គាត់ ដោយបន្ថែមពួកវាទៅ ClickHouse ។

ដរាបណាពេលវេលាពិតអតិបរមាត្រូវបានទាមទារ នោះម៉ាស៊ីនមេ 4-core ជាមួយ ClickHouse នឹងត្រូវបានផ្ទុកលើសទម្ងន់រួចហើយនៅលើប្រព័ន្ធរងរបស់ថាស៖

ប្រភេទនៃការផ្ទុកនេះគឺដោយសារតែការពិតដែលថាយើងកំពុងព្យាយាមសរសេរនៅក្នុង ClickHouse ឱ្យបានលឿនតាមដែលអាចធ្វើទៅបាន។ ហើយមូលដ្ឋានទិន្នន័យមានប្រតិកម្មនឹងបញ្ហានេះជាមួយនឹងការកើនឡើងនៃការផ្ទុកថាស ដែលអាចបង្កឱ្យមានកំហុសដូចខាងក្រោម៖

DB::Exception: Too many parts (300). Merges are processing significantly slower than inserts

ចំណុចនោះគឺថា តារាង MergeTree នៅក្នុង ClickHouse (ពួកវាផ្ទុកទិន្នន័យកំណត់ហេតុ) មានការលំបាកផ្ទាល់ខ្លួនរបស់ពួកគេក្នុងអំឡុងពេលប្រតិបត្តិការសរសេរ។ ទិន្នន័យដែលបានបញ្ចូលទៅក្នុងពួកវាបង្កើតភាគថាសបណ្តោះអាសន្ន ដែលបន្ទាប់មកត្រូវបានបញ្ចូលគ្នាជាមួយតារាងមេ។ ជាលទ្ធផល ការថតមានតម្រូវការខ្លាំងនៅលើឌីស ហើយវាក៏ជាកម្មវត្ថុនៃការកំណត់ដែលយើងបានទទួលការជូនដំណឹងខាងលើផងដែរ៖ មិនលើសពី 1 ភាគរងអាចត្រូវបានបញ្ចូលគ្នាក្នុងរយៈពេល 300 វិនាទី (តាមពិតទៅ នេះគឺ 300 បញ្ចូល ក្នុងមួយវិនាទី)។

ដើម្បីជៀសវាងទង្វើនេះ គួរតែសរសេរទៅ ClickHouse ជាបំណែកធំតាមដែលអាចធ្វើបាន និងមិនលើសពី 1 ដងរៀងរាល់ 2 វិនាទី។ ទោះជាយ៉ាងណាក៏ដោយ ការសរសេរជាដុំៗ បង្ហាញថា យើងគួរតែសរសេរតិចជាញឹកញាប់នៅក្នុង ClickHouse ។ នេះអាចនាំឱ្យមានការហៀរសំបោរ និងការបាត់បង់កំណត់ហេតុ។ ដំណោះស្រាយគឺដើម្បីបង្កើន Fluentd buffer ប៉ុន្តែបន្ទាប់មកការប្រើប្រាស់អង្គចងចាំក៏នឹងកើនឡើងផងដែរ។

ការកត់សម្គាល់៖ ទិដ្ឋភាពបញ្ហាមួយទៀតនៃដំណោះស្រាយរបស់យើងជាមួយ ClickHouse គឺទាក់ទងទៅនឹងការពិតដែលថាការបែងចែកនៅក្នុងករណីរបស់យើង (loghouse) ត្រូវបានអនុវត្តតាមរយៈតារាងខាងក្រៅដែលបានតភ្ជាប់ តារាងបញ្ចូលគ្នា. នេះនាំឱ្យមានការពិតដែលថានៅពេលយកគំរូចន្លោះពេលធំ ៗ RAM ច្រើនហួសប្រមាណត្រូវបានទាមទារចាប់តាំងពី metatable ម្តងទៀតតាមរយៈភាគថាសទាំងអស់ - សូម្បីតែអ្នកដែលមិនមានទិន្នន័យចាំបាច់ក៏ដោយ។ ទោះជាយ៉ាងណាក៏ដោយ ឥឡូវនេះវិធីសាស្រ្តនេះអាចត្រូវបានគេប្រកាសថាលែងប្រើសម្រាប់កំណែបច្ចុប្បន្នរបស់ ClickHouse (គ 18.16).

ជាលទ្ធផល វាច្បាស់ណាស់ថាមិនមែនគ្រប់គម្រោងទាំងអស់មានធនធានគ្រប់គ្រាន់ដើម្បីប្រមូលកំណត់ហេតុក្នុងពេលវេលាជាក់ស្តែងនៅក្នុង ClickHouse (កាន់តែច្បាស់ ការចែកចាយរបស់ពួកគេនឹងមិនសមស្របទេ)។ លើសពីនេះទៀតអ្នកនឹងត្រូវប្រើ аккумуляторដែលយើងនឹងត្រឡប់មកវិញនៅពេលក្រោយ។ ករណីដែលបានពិពណ៌នាខាងលើគឺពិត។ ហើយនៅពេលនោះ យើងមិនអាចផ្តល់នូវដំណោះស្រាយដែលអាចទុកចិត្តបាន និងមានស្ថេរភាពដែលសាកសមនឹងអតិថិជន និងអនុញ្ញាតឱ្យយើងប្រមូលកំណត់ហេតុជាមួយនឹងការពន្យារពេលតិចតួចបំផុត...

ចុះ Elasticsearch វិញ?

Elasticsearch ត្រូវបានគេស្គាល់ថាអាចគ្រប់គ្រងបន្ទុកការងារធ្ងន់។ តោះសាកល្បងវានៅក្នុងគម្រោងតែមួយ។ ឥឡូវនេះបន្ទុកមើលទៅដូចនេះ៖

Elasticsearch អាចរំលាយស្ទ្រីមទិន្នន័យបាន ទោះជាយ៉ាងណាក៏ដោយ ការសរសេរបរិមាណបែបនេះទៅវាប្រើប្រាស់ស៊ីភីយូយ៉ាងខ្លាំង។ នេះត្រូវបានសម្រេចដោយការរៀបចំចង្កោម។ តាមបច្ចេកទេស នេះមិនមែនជាបញ្ហានោះទេ ប៉ុន្តែវាប្រែថាគ្រាន់តែដើម្បីដំណើរការប្រព័ន្ធប្រមូលកំណត់ហេតុយើងប្រើប្រាស់ប្រហែល 8 cores ហើយមានសមាសធាតុផ្ទុកខ្ពស់បន្ថែមនៅក្នុងប្រព័ន្ធ...

បន្ទាត់ខាងក្រោម៖ ជម្រើសនេះអាចត្រូវបានរាប់ជាសុចរិត ប៉ុន្តែលុះត្រាតែគម្រោងមានទំហំធំ ហើយការគ្រប់គ្រងរបស់វារួចរាល់ក្នុងការចំណាយធនធានសំខាន់ៗលើប្រព័ន្ធកាប់ឈើកណ្តាល។

បន្ទាប់មកសំណួរធម្មជាតិកើតឡើង៖

តើត្រូវការកំណត់ហេតុអ្វីខ្លះ?

ចូរយើងព្យាយាមផ្លាស់ប្តូរវិធីសាស្រ្តដោយខ្លួនឯង៖ កំណត់ហេតុក្នុងពេលដំណាលគ្នាគួរតែផ្តល់ព័ត៌មាន និងមិនគ្របដណ្តប់ រាល់ ព្រឹត្តិការណ៍នៅក្នុងប្រព័ន្ធ។

ចូរនិយាយថាយើងមានហាងអនឡាញជោគជ័យ។ តើកំណត់ហេតុមានសារៈសំខាន់អ្វីខ្លះ? ការប្រមូលព័ត៌មានឱ្យបានច្រើនតាមតែអាចធ្វើទៅបាន ជាឧទាហរណ៍ ពីច្រកផ្លូវបង់ប្រាក់ គឺជាគំនិតដ៏ល្អ។ ប៉ុន្តែមិនមែនរាល់កំណត់ហេតុទាំងអស់ពីសេវាកម្មកាត់រូបភាពនៅក្នុងកាតាឡុកផលិតផលគឺសំខាន់សម្រាប់យើងទេ៖ មានតែកំហុស និងការត្រួតពិនិត្យកម្រិតខ្ពស់គឺគ្រប់គ្រាន់ (ឧទាហរណ៍ កំហុសភាគរយ 500 ដែលសមាសធាតុនេះបង្កើត)។

ដូច្នេះយើងបានឈានដល់ការសន្និដ្ឋាននោះ។ ការកាប់ឈើជាកណ្តាលមិនតែងតែមានភាពត្រឹមត្រូវទេ។. ជាញឹកញាប់អតិថិជនចង់ប្រមូលកំណត់ហេតុទាំងអស់នៅកន្លែងតែមួយ ទោះបីជាការពិតពីកំណត់ហេតុទាំងមូលក៏ដោយ មានតែសារដែលមានលក្ខខណ្ឌចំនួន 5% ប៉ុណ្ណោះដែលត្រូវបានទាមទារ៖

ពេលខ្លះវាគ្រប់គ្រាន់ក្នុងការកំណត់រចនាសម្ព័ន្ធនិយាយថាមានតែទំហំនៃកំណត់ហេតុកុងតឺន័រនិងអ្នកប្រមូលកំហុស (ឧទាហរណ៍ Sentry) ។
ការជូនដំណឹងអំពីកំហុស និងកំណត់ហេតុក្នុងស្រុកដ៏ធំមួយ ជាញឹកញាប់អាចគ្រប់គ្រាន់ដើម្បីស៊ើបអង្កេតឧប្បត្តិហេតុ។
យើងមានគម្រោងដែលធ្វើជាមួយនឹងការធ្វើតេស្តមុខងារផ្តាច់មុខ និងប្រព័ន្ធប្រមូលកំហុស។ អ្នកអភិវឌ្ឍន៍មិនត្រូវការកំណត់ហេតុបែបនេះទេ - ពួកគេបានឃើញអ្វីគ្រប់យ៉ាងពីដានកំហុស។

រូបភាពពីជីវិត

រឿងមួយទៀតអាចធ្វើជាគំរូល្អ។ យើងបានទទួលសំណើពីក្រុមសន្តិសុខនៃអតិថិជនរបស់យើងម្នាក់ ដែលបានប្រើប្រាស់ដំណោះស្រាយពាណិជ្ជកម្មរួចហើយ ដែលត្រូវបានបង្កើតឡើងជាយូរមកហើយ មុនពេលការណែនាំរបស់ Kubernetes ។

វាចាំបាច់ក្នុងការ "បង្កើតមិត្ត" នៃប្រព័ន្ធប្រមូលកំណត់ហេតុកណ្តាលជាមួយនឹងឧបករណ៍ចាប់សញ្ញាបញ្ហាសាជីវកម្ម - QRadar ។ ប្រព័ន្ធនេះអាចទទួលកំណត់ហេតុតាមរយៈពិធីការ syslog និងទាញយកពួកវាពី FTP ។ ទោះយ៉ាងណាក៏ដោយ វាមិនអាចភ្លាមៗក្នុងការរួមបញ្ចូលវាជាមួយកម្មវិធីជំនួយ remote_syslog សម្រាប់ស្ទាត់ជំនាញនោះទេ។ (ដូចដែលវាបានប្រែក្លាយ យើងមិននៅម្នាក់ឯងទេ។). បញ្ហាក្នុងការដំឡើង QRadar បានក្លាយទៅជានៅខាងក្រុមសន្តិសុខរបស់អតិថិជន។

ជាលទ្ធផល ផ្នែកនៃកំណត់ហេតុដែលសំខាន់សម្រាប់អាជីវកម្មត្រូវបានបង្ហោះទៅកាន់ FTP QRadar ហើយផ្នែកផ្សេងទៀតត្រូវបានបញ្ជូនបន្តតាមរយៈ syslog ពីចម្ងាយដោយផ្ទាល់ពីថ្នាំង។ សម្រាប់រឿងនេះយើងថែមទាំងសរសេរទៀតផង។ គំនូសតាងសាមញ្ញ - ប្រហែលជាវានឹងជួយនរណាម្នាក់ដោះស្រាយបញ្ហាស្រដៀងគ្នា... សូមអរគុណចំពោះគ្រោងការណ៍លទ្ធផល អតិថិជនខ្លួនឯងបានទទួល និងវិភាគកំណត់ហេតុសំខាន់ៗ (ដោយប្រើឧបករណ៍ដែលគាត់ចូលចិត្ត) ហើយយើងអាចកាត់បន្ថយថ្លៃដើមនៃប្រព័ន្ធកាប់ឈើ ដោយរក្សាទុកតែ ខែមុន។

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

លក្ខណៈវិនិច្ឆ័យសម្រាប់កំណត់ហេតុ

ឧទាហរណ៍បែបនេះនាំឱ្យមានការសន្និដ្ឋានថាបន្ថែមពីលើការជ្រើសរើសប្រព័ន្ធប្រមូលកំណត់ហេតុអ្នកត្រូវធ្វើ រចនាកំណត់ហេតុដោយខ្លួនឯង។! តើតម្រូវការអ្វីខ្លះនៅទីនេះ?

កំណត់ហេតុត្រូវតែជាទម្រង់ម៉ាស៊ីនដែលអាចអានបាន (ឧទាហរណ៍ JSON)។
កំណត់ហេតុគួរតែបង្រួម និងមានសមត្ថភាពផ្លាស់ប្តូរកម្រិតនៃការកត់ត្រា ដើម្បីបំបាត់បញ្ហាដែលអាចកើតមាន។ ក្នុងពេលជាមួយគ្នានេះនៅក្នុងបរិយាកាសផលិតកម្មអ្នកគួរតែដំណើរការប្រព័ន្ធដែលមានកម្រិតនៃការកាប់ឈើដូចជា ព្រមាន ឬ កំហុសក្នុងការ.
កំណត់ហេតុត្រូវតែមានលក្ខណៈធម្មតា ពោលគឺនៅក្នុងវត្ថុកំណត់ហេតុ បន្ទាត់ទាំងអស់ត្រូវតែមានប្រភេទវាលដូចគ្នា។

កំណត់ហេតុដែលមិនមានរចនាសម្ព័ន្ធអាចនាំឱ្យមានបញ្ហាជាមួយនឹងការផ្ទុកកំណត់ហេតុទៅក្នុងកន្លែងផ្ទុក និងការបញ្ឈប់ទាំងស្រុងនៅក្នុងដំណើរការរបស់វា។ ជាឧទាហរណ៍មួយ ខាងក្រោមនេះជាឧទាហរណ៍ជាមួយ error 400 ដែលមនុស្សជាច្រើនបានជួបប្រទះក្នុងកំណត់ហេតុស្ទាត់ជំនាញ៖

2019-10-29 13:10:43 +0000 [warn]: dump an error event: error_class=Fluent::Plugin::ElasticsearchErrorHandler::ElasticsearchError error="400 - Rejected by Elasticsearch"

កំហុសមានន័យថាអ្នកកំពុងផ្ញើវាលដែលប្រភេទមិនស្ថិតស្ថេរទៅលិបិក្រមជាមួយនឹងផែនទីដែលត្រៀមរួចជាស្រេច។ ឧទាហរណ៍សាមញ្ញបំផុតគឺវាលមួយនៅក្នុងកំណត់ហេតុ nginx ដែលមានអថេរ $upstream_status. វាអាចមានលេខ ឬខ្សែអក្សរ។ ឧទាហរណ៍:

{ "ip": "1.2.3.4", "http_user": "-", "request_id": "17ee8a579e833b5ab9843a0aca10b941", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staffs/265.png", "protocol": "HTTP/1.1", "status": "200", "body_size": "906", "referrer": "https://example.com/staff", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.001", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "127.0.0.1:9000", "upstream_status": "200", "upstream_response_length": "906", "location": "staff"} { "ip": "1.2.3.4", "http_user": "-", "request_id": "47fe42807f2a7d8d5467511d7d553a1b", "time": "29/Oct/2019:16:18:57 +0300", "method": "GET", "uri": "/staff", "protocol": "HTTP/1.1", "status": "200", "body_size": "2984", "referrer": "-", "user_agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.70 Safari/537.36", "request_time": "0.010", "cache_status": "-", "upstream_response_time": "0.001, 0.007", "upstream_addr": "10.100.0.10:9000, 10.100.0.11:9000", "upstream_status": "404, 200", "upstream_response_length": "0, 2984", "location": "staff"}

កំណត់ហេតុបង្ហាញថាម៉ាស៊ីនមេ 10.100.0.10 បានឆ្លើយតបជាមួយនឹងកំហុស 404 ហើយសំណើត្រូវបានផ្ញើទៅកន្លែងផ្ទុកមាតិកាផ្សេងទៀត។ ជាលទ្ធផលតម្លៃនៅក្នុងកំណត់ហេតុបានក្លាយជាដូចនេះ:

"upstream_response_time": "0.001, 0.007"

ស្ថានភាពនេះគឺជារឿងធម្មតាណាស់ដែលវាសមនឹងទទួលបានដាច់ដោយឡែក ឯកសារយោងនៅក្នុងឯកសារ.

ចុះយ៉ាងណាចំពោះភាពជឿជាក់?

មានពេលខ្លះដែលកំណត់ហេតុទាំងអស់ដោយគ្មានករណីលើកលែងមានសារៈសំខាន់ណាស់។ ហើយជាមួយនេះ គ្រោងការណ៍នៃការប្រមូលកំណត់ហេតុធម្មតាសម្រាប់ K8s ដែលបានស្នើ/ពិភាក្សាខាងលើមានបញ្ហា។

ឧទាហរណ៍ fluentd មិនអាចប្រមូលកំណត់ហេតុពីធុងដែលមានអាយុកាលខ្លីបានទេ។ នៅក្នុងគម្រោងមួយរបស់យើង កុងតឺន័រផ្ទេរទិន្នន័យបានរស់នៅតិចជាង 4 វិនាទី ហើយបន្ទាប់មកត្រូវបានលុប - យោងតាមចំណារពន្យល់ដែលត្រូវគ្នា៖

"helm.sh/hook-delete-policy": hook-succeeded

ដោយសារតែហេតុនេះ កំណត់ហេតុប្រតិបត្តិការធ្វើចំណាកស្រុកមិនត្រូវបានរួមបញ្ចូលក្នុងកន្លែងផ្ទុកទេ។ នយោបាយអាចជួយក្នុងករណីនេះ។ before-hook-creation.

ឧទាហរណ៍មួយទៀតគឺការបង្វិលកំណត់ហេតុ Docker ។ ចូរនិយាយថាមានកម្មវិធីមួយដែលសរសេរយ៉ាងសកម្មទៅកំណត់ហេតុ។ នៅក្រោមលក្ខខណ្ឌធម្មតា យើងគ្រប់គ្រងដើម្បីដំណើរការកំណត់ហេតុទាំងអស់ ប៉ុន្តែភ្លាមៗនៅពេលដែលបញ្ហាលេចឡើង - ឧទាហរណ៍ដូចដែលបានពិពណ៌នាខាងលើជាមួយនឹងទម្រង់មិនត្រឹមត្រូវ - ដំណើរការឈប់ដំណើរការ ហើយ Docker បង្វិលឯកសារ។ លទ្ធផលគឺថា កំណត់ហេតុដែលសំខាន់សម្រាប់អាជីវកម្មអាចនឹងត្រូវបាត់បង់។

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

ជាចុងក្រោយ យើងមិនត្រូវភ្លេចរឿងនោះទេ។ វាមានសារៈសំខាន់ណាស់ក្នុងការត្រួតពិនិត្យប្រព័ន្ធរងណាមួយឱ្យបានត្រឹមត្រូវ. បើមិនដូច្នោះទេវាងាយស្រួលក្នុងការរត់ចូលទៅក្នុងស្ថានភាពដែលស្ទាត់ជំនាញស្ថិតក្នុងស្ថានភាពមួយ។ CrashLoopBackOff និងមិនផ្ញើអ្វីទាំងអស់ ហើយនេះសន្យាថានឹងបាត់បង់ព័ត៌មានសំខាន់ៗ។

ការរកឃើញ

នៅក្នុងអត្ថបទនេះ យើងមិនសម្លឹងមើលដំណោះស្រាយ SaaS ដូច Datadog ទេ។ បញ្ហាជាច្រើនដែលបានពិពណ៌នានៅទីនេះត្រូវបានដោះស្រាយតាមមធ្យោបាយមួយឬផ្សេងទៀតដោយក្រុមហ៊ុនពាណិជ្ជកម្មដែលមានឯកទេសក្នុងការប្រមូលកំណត់ហេតុ ប៉ុន្តែមិនមែនគ្រប់គ្នាអាចប្រើ SaaS សម្រាប់ហេតុផលផ្សេងៗនោះទេ។ (កត្តាសំខាន់គឺការចំណាយ និងការអនុលោមតាម 152-FZ).

ការប្រមូលកំណត់ហេតុកណ្តាលដំបូងមើលទៅដូចជាកិច្ចការសាមញ្ញ ប៉ុន្តែវាមិនមែនទាល់តែសោះ។ វាជាការសំខាន់ក្នុងការចងចាំថា:

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

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

PS

សូមអានផងដែរនៅលើប្លក់របស់យើង៖

ប្រភព: www.habr.com

ចូល Kubernetes (មិនត្រឹមតែប៉ុណ្ណោះ) ថ្ងៃនេះ៖ ការរំពឹងទុក និងការពិត