Yuri Bushmelev "ផែនទីតុងរួចនៅលើវាលនៃការប្រមូលនិងចែកចាយកំណត់ហេតុ" - ប្រតិចារិកនៃរបាយការណ៍

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

• របៀបសរសេរកំណត់ហេតុពីកម្មវិធី;
• កន្លែងដែលត្រូវសរសេរកំណត់ហេតុ;
• របៀបចែកចាយកំណត់ហេតុសម្រាប់ការរក្សាទុក និងដំណើរការ;
• របៀបដំណើរការ និងរក្សាទុកកំណត់ហេតុ។

ការប្រើប្រាស់បច្ចេកវិជ្ជាដាក់កុងតឺន័រដ៏ពេញនិយមនាពេលបច្ចុប្បន្ននេះ បន្ថែមខ្សាច់ពីលើតុងរួចទៅក្នុងវិស័យជម្រើសសម្រាប់ដោះស្រាយបញ្ហា។

នេះគឺជាអ្វីដែលប្រតិចារឹកនៃរបាយការណ៍របស់ Yuri Bushmelev "ផែនទីនៃការតុងរួចក្នុងវិស័យប្រមូល និងដឹកជញ្ជូនកំណត់ហេតុ" គឺនិយាយអំពី។

អ្នកណាខ្វល់សូមនៅក្រោមឆ្មា។

ឈ្មោះរបស់ខ្ញុំគឺ Yuri Bushmelev ។ ខ្ញុំធ្វើការនៅ Lazada ។ ថ្ងៃនេះខ្ញុំនឹងនិយាយអំពីរបៀបដែលយើងបង្កើតកំណត់ហេតុរបស់យើង របៀបដែលយើងប្រមូលពួកវា និងអ្វីដែលយើងសរសេរនៅទីនោះ។

តើយើងមកពីណា? តើយើងជានរណា? Lazada គឺជាក្រុមហ៊ុនលក់ទំនិញអនឡាញលំដាប់លេខ 1 នៅក្នុងប្រទេសចំនួន 4 នៅអាស៊ីអាគ្នេយ៍។ ប្រទេសទាំងអស់នេះត្រូវបានចែកចាយក្នុងចំណោមមជ្ឈមណ្ឌលទិន្នន័យរបស់យើង។ បច្ចុប្បន្ន​មាន​មជ្ឈមណ្ឌល​ទិន្នន័យ​សរុប​ចំនួន 80 ហេតុអ្វី​បានជា​វា​សំខាន់? ដោយសារតែការសម្រេចចិត្តមួយចំនួនគឺដោយសារតែការពិតដែលថាមានទំនាក់ទំនងខ្សោយយ៉ាងខ្លាំងរវាងមជ្ឈមណ្ឌល។ យើងមានស្ថាបត្យកម្មមីក្រូសេវាកម្ម។ ខ្ញុំ​ភ្ញាក់​ផ្អើល​ដែល​បាន​រក​ឃើញ​ថា​យើង​មាន​សេវា​មីក្រូ 20 រួច​ហើយ។ នៅពេលខ្ញុំចាប់ផ្តើមកិច្ចការជាមួយកំណត់ហេតុ វាមានត្រឹមតែ 6 ប៉ុណ្ណោះ។ បូកមានកេរ្តិ៍ដំណែល PHP មួយដុំធំ ដែលខ្ញុំក៏ត្រូវរស់នៅជាមួយផងដែរ។ ទាំងអស់នេះបច្ចុប្បន្នបង្កើតបានច្រើនជាង XNUMX លានសារក្នុងមួយនាទីសម្រាប់ប្រព័ន្ធទាំងមូល។ បន្ទាប់ខ្ញុំនឹងបង្ហាញពីរបៀបដែលយើងកំពុងព្យាយាមរស់នៅជាមួយរឿងនេះ ហើយហេតុអ្វីបានជារឿងនេះកើតឡើង។

អ្នកត្រូវតែរស់នៅជាមួយសារ 6 លាននេះ។ តើយើងគួរធ្វើអ្វីជាមួយពួកគេ? 6 លានសារដែលអ្នកត្រូវការ:

• ផ្ញើពីកម្មវិធី
• ទទួលយកសម្រាប់ការដឹកជញ្ជូន
• ចែកចាយសម្រាប់ការវិភាគនិងការផ្ទុក។
• វិភាគ
• ទុកវាតាមរបៀបណាមួយ។

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

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

តើធ្វើដូចម្តេចដើម្បីសរសេរពីកម្មវិធី? វាច្បាស់ណាស់ថាមានវិធីផ្សេងគ្នា។ ជាពិសេស​គឺ​មាន​ការ​អនុវត្ត​ល្អ​បំផុត​ដូច​សមមិត្ត​ម៉ូដ​របស់​យើង​ប្រាប់។ សាលា​ចាស់​មាន​ពីរ​ប្រភេទ ដូច​ជីតា​របស់​យើង​បាន​ប្រាប់​យើង។ មានវិធីផ្សេងទៀត។

ស្ថានភាពជាមួយនឹងការប្រមូលកំណត់ហេតុគឺប្រហាក់ប្រហែល។ មិនមានជម្រើសច្រើនសម្រាប់ដោះស្រាយផ្នែកពិសេសនេះទេ។ មាន​ច្រើន​ទៀត​ហើយ ប៉ុន្តែ​មិន​ទាន់​មាន​ច្រើន​ទេ។

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

ខ្ញុំនឹងបង្ហាញអ្នកពីរបៀបដែលយើងបានធ្វើវានៅ Lazada និងរបៀបដែលវាបានចាប់ផ្តើម។

កាលពីមួយឆ្នាំមុនខ្ញុំបានមក Lazada ហើយត្រូវបានបញ្ជូនទៅគម្រោងអំពីកំណត់ហេតុ។ វាជាអ្វីមួយដូចនេះ។ កំណត់ហេតុកម្មវិធីត្រូវបានសរសេរទៅ stdout និង stderr ។ អ្វីគ្រប់យ៉ាងត្រូវបានធ្វើតាមរបៀបទាន់សម័យ។ ប៉ុន្តែបន្ទាប់មកអ្នកអភិវឌ្ឍន៍បានបោះវាចេញពីលំហូរស្តង់ដារ ហើយបន្ទាប់មក អ្នកជំនាញផ្នែកហេដ្ឋារចនាសម្ព័ន្ធនឹងដោះស្រាយវាចេញ។ រវាងអ្នកឯកទេសផ្នែកហេដ្ឋារចនាសម្ព័ន្ធ និងអ្នកអភិវឌ្ឍន៍ ក៏មានអ្នកចេញផ្សាយដែលបាននិយាយថា៖ "អូ... អញ្ចឹង តោះរុំពួកវាក្នុងឯកសារជាមួយសំបក ហើយនោះហើយជាវា"។ ហើយដោយសារអ្វីៗទាំងអស់នេះស្ថិតនៅក្នុងធុងមួយ ពួកគេបានរុំវានៅក្នុងធុងដោយខ្លួនវាផ្ទាល់ គូសផែនទីកាតាឡុកនៅខាងក្នុង ហើយដាក់វានៅទីនោះ។ ខ្ញុំ​គិត​ថា​វា​ច្បាស់​ណាស់​សម្រាប់​អ្នក​រាល់​គ្នា​អំពី​អ្វី​ដែល​បាន​មក​ពី​វា។

សូមក្រឡេកមើលបន្តិចទៀតសម្រាប់ពេលនេះ។ តើ​យើង​បាន​ប្រគល់​កំណត់​ហេតុ​ទាំង​នេះ​ដោយ​របៀប​ណា? មាននរណាម្នាក់ជ្រើសរើសភ្នាក់ងារ td ដែលពិតជាស្ទាត់ជំនាញ ប៉ុន្តែមិនស្ទាត់ជំនាញទេ។ ខ្ញុំនៅតែមិនយល់អំពីទំនាក់ទំនងរវាងគម្រោងទាំងពីរនេះ ប៉ុន្តែពួកគេហាក់ដូចជាមានរឿងដូចគ្នា។ ហើយស្ទាត់ជំនាញនេះ សរសេរជា Ruby អានឯកសារកំណត់ហេតុ ញែកពួកវាទៅជា JSON ដោយប្រើភាពទៀងទាត់មួយចំនួន។ បន្ទាប់មកខ្ញុំបានបញ្ជូនពួកគេទៅ Kafka ។ លើសពីនេះទៅទៀតនៅក្នុង Kafka យើងមាន 4 ប្រធានបទដាច់ដោយឡែកសម្រាប់ API នីមួយៗ។ ហេតុអ្វី 4? ដោយសារតែមានការផ្សាយបន្តផ្ទាល់, មានឆាក, និងដោយសារតែមានការ stdout និង stderr ។ អ្នកអភិវឌ្ឍន៍បង្កើតវា ហើយអ្នកអភិវឌ្ឍន៍ហេដ្ឋារចនាសម្ព័ន្ធត្រូវតែបង្កើតវានៅក្នុង Kafka ។ លើសពីនេះទៅទៀត Kafka ត្រូវបានគ្រប់គ្រងដោយនាយកដ្ឋានមួយផ្សេងទៀត។ ដូច្នេះ ចាំបាច់ត្រូវបង្កើតសំបុត្រមួយ ដូច្នេះពួកគេនឹងបង្កើតប្រធានបទចំនួន 4 សម្រាប់ api នីមួយៗ។ មនុស្សគ្រប់គ្នាភ្លេចអំពីវា។ ជាទូទៅ​មាន​សំរាម​និង​ការ​ច្របូកច្របល់។

តើ​យើង​បាន​ធ្វើ​អ្វី​បន្ទាប់​ពី​នេះ? យើងបានផ្ញើវាទៅ Kafka ។ បន្ទាប់មកពាក់កណ្តាលនៃកំណត់ហេតុពី Kafka បានហោះទៅ Logstash ។ ចំណែក​ឈើ​ពាក់​កណ្តាល​ទៀត​ត្រូវ​បាន​បែង​ចែក។ អ្នកខ្លះហោះទៅ Graylog មួយ ខ្លះទៅ Graylog ផ្សេងទៀត។ ជាលទ្ធផល ទាំងអស់នេះបានចូលទៅក្នុងចង្កោម Elasticsearch មួយ។ នោះគឺភាពរញ៉េរញ៉ៃទាំងអស់នេះបានបញ្ចប់នៅទីនោះ។ កុំធ្វើអញ្ចឹង!

នេះ​ជា​អ្វី​ដែល​វា​មើល​ទៅ​ដូច​ជា​ប្រសិន​បើ​អ្នក​មើល​វា​ពី​ខាង​លើ​។ កុំធ្វើអញ្ចឹង! នៅទីនេះតំបន់បញ្ហាត្រូវបានសម្គាល់ភ្លាមៗដោយលេខ។ តាមពិតមានច្រើនជាងនេះ ប៉ុន្តែ 6 គឺពិតជាបញ្ហាដែលចាំបាច់ត្រូវធ្វើអ្វីមួយ។ ខ្ញុំនឹងប្រាប់អ្នកអំពីពួកគេដាច់ដោយឡែកឥឡូវនេះ។

នៅទីនេះ (1,2,3) យើងសរសេរឯកសារ ហើយតាមនោះ មានតុងរួចបីនៅទីនេះក្នុងពេលតែមួយ។

ទីមួយ (1) គឺថាយើងត្រូវសរសេរវានៅកន្លែងណាមួយ។ វាមិនតែងតែជាការចង់ផ្តល់ឱ្យ API នូវសមត្ថភាពក្នុងការសរសេរដោយផ្ទាល់ទៅឯកសារនោះទេ។ វាជាការចង់បានដែល API ត្រូវបានញែកដាច់ពីគេក្នុងកុងតឺន័រ ឬប្រសើរជាងនេះ ដែលវាត្រូវបានអានតែប៉ុណ្ណោះ។ ខ្ញុំជាអ្នកគ្រប់គ្រងប្រព័ន្ធ ដូច្នេះខ្ញុំមានទិដ្ឋភាពជំនួសបន្តិចនៃរឿងទាំងនេះ។

ចំណុចទីពីរ (2,3) គឺថាយើងមានសំណើជាច្រើនចូលមក API ។ API សរសេរទិន្នន័យជាច្រើនទៅឯកសារមួយ។ ឯកសារកំពុងកើនឡើង។ យើងត្រូវបង្វិលពួកគេ។ ព្រោះបើមិនដូច្នេះទេ អ្នកនឹងមិនអាចស្តុកទុកនៅលើថាសណាមួយនៅទីនោះបានទេ។ ការបង្វិលពួកវាគឺមិនល្អទេព្រោះវាត្រូវបានធ្វើឡើងដោយការបញ្ជូនបន្តតាមសែលទៅថត។ គ្មាន​វិធី​ដែល​យើង​អាច​កែប្រែ​វា​បាន​ទេ។ អ្នកមិនអាចប្រាប់កម្មវិធីឱ្យបើកចំណុចទាញឡើងវិញបានទេ។ ដោយសារតែអ្នកអភិវឌ្ឍន៍នឹងមើលមកអ្នកដូចជាអ្នកជាមនុស្សល្ងីល្ងើ៖ "តើអ្នកពិពណ៌នាអ្វី? ជាទូទៅ​យើង​សរសេរ​ទៅ​កាន់​មនុស្ស​រឹងរូស»។ អ្នកអភិវឌ្ឍន៍ហេដ្ឋារចនាសម្ព័ន្ធបានធ្វើឱ្យច្បាប់ចម្លងកាត់ចេញដើម្បីចូលដំណើរការ ដែលគ្រាន់តែចម្លងឯកសារ និងចម្លងឯកសារដើម។ ដូច្នោះហើយ រវាងដំណើរការចម្លងទាំងនេះ ទំហំថាសជាធម្មតានឹងអស់។

(4) យើងមានទម្រង់ផ្សេងគ្នានៅក្នុង APIs ផ្សេងគ្នា។ ពួកវាខុសគ្នាបន្តិចបន្តួច ប៉ុន្តែ regexp ត្រូវតែសរសេរខុសគ្នា។ ចាប់តាំងពីអ្វីៗទាំងអស់នេះត្រូវបានគ្រប់គ្រងដោយអាយ៉ង វាមានថ្នាក់រៀនជាច្រើនជាមួយនឹងកន្លាតផ្ទាល់ខ្លួនរបស់ពួកគេ។ លើសពីនេះ ភាគច្រើននៃពេលវេលាភ្នាក់ងារ td អាចស៊ីការចងចាំ ល្ងង់ វាគ្រាន់តែអាចធ្វើពុតថាវាដំណើរការហើយមិនធ្វើអ្វីសោះ។ ពី​ខាង​ក្រៅ​មិន​អាច​យល់​ថា​គាត់​មិន​បាន​ធ្វើ​អ្វី​សោះ។ ល្អបំផុត គាត់នឹងដួល ហើយនរណាម្នាក់នឹងយកគាត់ឡើងនៅពេលក្រោយ។ កាន់តែច្បាស់ ការដាស់តឿននឹងមកដល់ ហើយនរណាម្នាក់នឹងទៅលើកដៃរបស់ពួកគេ។

(6) ហើយសំរាម និងកាកសំណល់ច្រើនបំផុតគឺការស្វែងរកយឺត។ ដោយសារតែវាជាកំណែចាស់។ ដោយសារតែយើងមិនមានចៅហ្វាយនាយឧទ្ទិសនៅពេលនោះ។ យើង​មាន​កំណត់​ហេតុ​ខុស​គ្នា​ដែល​វាល​អាច​ត្រួត​គ្នា។ កំណត់ហេតុផ្សេងគ្នាពីកម្មវិធីផ្សេងគ្នាអាចត្រូវបានសរសេរដោយឈ្មោះវាលដូចគ្នា ប៉ុន្តែអាចមានទិន្នន័យផ្សេងគ្នានៅខាងក្នុង។ នោះគឺ កំណត់ហេតុមួយភ្ជាប់មកជាមួយចំនួនគត់ក្នុងវាល ឧទាហរណ៍ កម្រិត។ កំណត់ហេតុមួយទៀតភ្ជាប់មកជាមួយ String នៅក្នុងវាលកម្រិត។ អវត្ដមាននៃផែនទីឋិតិវន្ត នេះពិតជារឿងអស្ចារ្យណាស់។ ប្រសិនបើបន្ទាប់ពីបង្វិលលិបិក្រមក្នុង elasticsearch សារដែលមានខ្សែមួយមកដល់មុន នោះយើងរស់នៅជាធម្មតា។ ប៉ុន្តែប្រសិនបើសារទីមួយបានមកដល់ពីចំនួនគត់ នោះសារបន្តបន្ទាប់ទាំងអស់ដែលមកដល់ពី String នឹងត្រូវបោះបង់ចោលយ៉ាងសាមញ្ញ។ ដោយសារតែប្រភេទវាលមិនត្រូវគ្នា។

យើងចាប់ផ្តើមសួរសំណួរទាំងនេះ។ យើង​សម្រេច​ចិត្ត​មិន​ស្វែង​រក​អ្នក​ដែល​ត្រូវ​បន្ទោស។

ប៉ុន្តែអ្វីដែលត្រូវធ្វើ! អ្វី​ដែល​ជាក់​ស្តែង​គឺ​យើង​ត្រូវ​បង្កើត​ស្តង់ដារ។ យើងមានស្តង់ដារមួយចំនួនរួចហើយ។ យើងចាប់ផ្តើមបន្តិចក្រោយមក។ ជាសំណាងល្អ ទម្រង់កំណត់ហេតុតែមួយសម្រាប់ APIs ទាំងអស់ត្រូវបានអនុម័តរួចហើយនៅពេលនោះ។ វាត្រូវបានសរសេរដោយផ្ទាល់ទៅក្នុងស្តង់ដារសម្រាប់អន្តរកម្មរវាងសេវាកម្ម។ ដូច្នោះហើយ អ្នកដែលចង់ទទួលកំណត់ហេតុត្រូវតែសរសេរវាក្នុងទម្រង់នេះ។ ប្រសិនបើនរណាម្នាក់មិនសរសេរកំណត់ហេតុក្នុងទម្រង់នេះទេ នោះយើងមិនធានាអ្វីទាំងអស់។

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

ហើយនៅទីនោះ (នៅលើស្លាយ) "SLA សម្រាប់ការដឹកជញ្ជូនកំណត់ហេតុ" ស្ទើរតែចាប់ផ្តើមលេចឡើង។ វាមិនទាន់មាននៅឡើយទេ ប៉ុន្តែយើងកំពុងធ្វើការលើវា។ ព្រោះវាងាយស្រួលណាស់ នៅពេលដែលហេដ្ឋារចនាសម្ព័ន្ធនិយាយថា ប្រសិនបើអ្នកសរសេរក្នុងទម្រង់បែបនេះ និងកន្លែងបែបនេះ ហើយមិនលើសពី N សារក្នុងមួយវិនាទី នោះយើងទំនងជានឹងបញ្ជូនវាទៅកន្លែងបែបនេះ។ នេះបំបាត់ការឈឺក្បាលច្រើន។ ប្រសិនបើមាន SLA នោះពិតជាអស្ចារ្យណាស់!

តើយើងចាប់ផ្តើមដោះស្រាយបញ្ហាដោយរបៀបណា? បញ្ហាចម្បងគឺជាមួយភ្នាក់ងារ td ។ វា​មិន​ច្បាស់​ថា​ឈើ​របស់​យើង​ទៅ​ណា​ទេ។ តើពួកគេត្រូវបានចែកចាយទេ? តើពួកគេទៅទេ? តើពួកគេនៅឯណា? ដូច្នេះចំណុចដំបូងត្រូវបានសម្រេចចិត្តដើម្បីជំនួសភ្នាក់ងារ td ។ ខ្ញុំបានគូសបញ្ជាក់យ៉ាងខ្លីអំពីជម្រើសសម្រាប់អ្វីដែលត្រូវជំនួសវានៅទីនេះ។

ស្ទាត់។ ដំបូង​ឡើយ ខ្ញុំ​បាន​ជួប​គាត់​នៅ​កន្លែង​ការងារ​មុន ហើយ​គាត់​ក៏​ធ្លាក់​ទៅ​ទីនោះ​ជា​ប្រចាំ។ ទីពីរ​នេះ​គឺ​ជា​រឿង​ដដែល​តែ​នៅ​ក្នុង​ប្រវត្តិរូប។

Filebeat ។ តើវាងាយស្រួលសម្រាប់យើងយ៉ាងដូចម្តេច? ដោយសារតែវាមាននៅក្នុង Go ហើយយើងមានជំនាញជាច្រើននៅក្នុង Go ។ ដូច្នោះហើយ ប្រសិនបើមានអ្វីកើតឡើង យើងអាចបន្ថែមវាសម្រាប់ខ្លួនយើង។ នោះហើយជាមូលហេតុដែលយើងមិនយកវា។ ដូច្នេះ​គ្មាន​ការ​ល្បួង​ណា​មួយ​ដើម្បី​ចាប់​ផ្ដើម​សរសេរ​វា​ឡើង​វិញ​សម្រាប់​ខ្លួន​អ្នក​ឡើយ។

ដំណោះស្រាយជាក់ស្តែងសម្រាប់អ្នកគ្រប់គ្រងប្រព័ន្ធគឺគ្រប់ប្រភេទ syslogs ក្នុងបរិមាណនេះ (syslog-ng/rsyslog/nxlog)។

ឬសរសេរអ្វីមួយផ្ទាល់ខ្លួនរបស់អ្នក ប៉ុន្តែយើងបានបោះបង់វាចោល ក៏ដូចជា filebeat ផងដែរ។ ប្រសិនបើអ្នកសរសេរអ្វីមួយ វាជាការប្រសើរក្នុងការសរសេរអ្វីដែលមានប្រយោជន៍សម្រាប់អាជីវកម្ម។ ដើម្បីចែកចាយកំណត់ហេតុ វាជាការល្អប្រសើរជាងមុនដើម្បីយកអ្វីមួយដែលត្រៀមខ្លួនជាស្រេច។

ដូច្នេះជម្រើសពិតជាបានមកលើជម្រើសរវាង syslog-ng និង rsyslog ។ ខ្ញុំបានងាកទៅរក rsyslog ដោយគ្រាន់តែយើងមានថ្នាក់សម្រាប់ rsyslog រួចហើយនៅក្នុង Puppet ហើយខ្ញុំមិនបានរកឃើញភាពខុសគ្នាជាក់ស្តែងរវាងពួកគេទេ។ អ្វី​ទៅ​ជា syslog អ្វី​ទៅ​ជា syslog ។ បាទ ឯកសារខ្លះមានឯកសារកាន់តែអាក្រក់ ខ្លះមានឯកសារប្រសើរជាង។ មួយនេះអាចធ្វើវាបានតាមវិធីនេះ ហើយមួយទៀតអាចធ្វើបានខុសគ្នា។

ហើយបន្តិចអំពី rsyslog ។ ដំបូងបង្អស់វាត្រជាក់ព្រោះវាមានម៉ូឌុលជាច្រើន។ វាមាន RainerScript ដែលមនុស្សអាចអានបាន (ភាសាកំណត់រចនាសម្ព័ន្ធទំនើប)។ វាជាប្រាក់រង្វាន់ដ៏អស្ចារ្យដែលយើងអាចត្រាប់តាមឥរិយាបថរបស់ភ្នាក់ងារ td ដោយប្រើឧបករណ៍ស្តង់ដារ ហើយគ្មានអ្វីផ្លាស់ប្តូរសម្រាប់កម្មវិធីនោះទេ។ នោះគឺយើងផ្លាស់ប្តូរភ្នាក់ងារ td ទៅ rsyslog ហើយទុកអ្វីៗផ្សេងទៀតតែម្នាក់ឯងសម្រាប់ពេលនេះ។ ហើយយើងទទួលបានការដឹកជញ្ជូនការងារភ្លាមៗ។ បន្ទាប់មក mmnormalize គឺជារឿងដ៏អស្ចារ្យមួយនៅក្នុង rsyslog ។ វាអនុញ្ញាតឱ្យអ្នកញែកកំណត់ហេតុ ប៉ុន្តែមិនប្រើ Grok និង regexp ទេ។ វាបង្កើតមែកធាងវាក្យសម្ព័ន្ធអរូបី។ វាញែកកំណត់ហេតុតាមរបៀបដូចគ្នានឹងអ្នកចងក្រងញែកប្រភព។ នេះអនុញ្ញាតឱ្យអ្នកធ្វើការបានយ៉ាងលឿន ប្រើប្រាស់ស៊ីភីយូតិចតួច ហើយជាទូទៅ វាពិតជាល្អណាស់។ មានប្រាក់រង្វាន់ផ្សេងៗទៀត។ ខ្ញុំនឹងមិនរស់នៅលើពួកគេទេ។

rsyslog មានគុណវិបត្តិជាច្រើនទៀត។ ពួកគេគឺដូចគ្នាទៅនឹងប្រាក់រង្វាន់។ បញ្ហាចម្បងគឺថាអ្នកត្រូវដឹងពីរបៀបចំអិនវាហើយអ្នកត្រូវជ្រើសរើសកំណែ។

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

ហេតុអ្វីមិនមែនជាឯកសារ? ព្រោះគ្រប់គ្នាបានអាន អត្ថបទអំពី Badushechkaដែលបានព្យាយាមបញ្ជូនឯកសារទៅ docker ហើយវាត្រូវបានគេរកឃើញថាបន្ទាប់ពីចាប់ផ្តើម rsyslog ឡើងវិញ អ្នកពណ៌នាឯកសារបានផ្លាស់ប្តូរ ហើយ docker បានបាត់បង់ឯកសារនេះ។ វារក្សាអ្វីផ្សេងទៀតបើកចំហ ប៉ុន្តែមិនមែនរន្ធដែលពួកគេកំពុងសរសេរនោះទេ។ យើងបានសម្រេចចិត្តថាយើងនឹងធ្វើការជុំវិញបញ្ហានេះ ហើយក្នុងពេលជាមួយគ្នានេះ យើងនឹងធ្វើការជុំវិញបញ្ហារារាំង។

Rsyslog អនុវត្តសកម្មភាពដែលបានបង្ហាញនៅលើស្លាយ ហើយផ្ញើកំណត់ហេតុទៅកាន់ការបញ្ជូនត ឬ Kafka ។ Kafka ធ្វើតាមវិធីចាស់។ បញ្ជូនត - ខ្ញុំបានព្យាយាមប្រើ rsyslog សុទ្ធដើម្បីចែកចាយកំណត់ហេតុ។ ដោយគ្មានជួរសារ ដោយប្រើឧបករណ៍ rsyslog ស្តង់ដារ។ ជាទូទៅវាដំណើរការ។

ប៉ុន្តែមានភាពខុសប្លែកគ្នាជាមួយនឹងរបៀបរុញពួកវាទៅក្នុងផ្នែកនេះ (Logstash/Graylog/ES)។ ផ្នែកនេះ (rsyslog-rsyslog) ត្រូវបានប្រើរវាងមជ្ឈមណ្ឌលទិន្នន័យ។ នេះគឺជាតំណភ្ជាប់ tcp ដែលបានបង្ហាប់ ដែលអនុញ្ញាតឱ្យយើងរក្សាទុកកម្រិតបញ្ជូន ហើយតាមនោះ បង្កើនលទ្ធភាពដែលយើងនឹងទទួលបានកំណត់ហេតុមួយចំនួនពីមជ្ឈមណ្ឌលទិន្នន័យផ្សេងទៀត នៅពេលដែលឆានែលត្រូវបានស្ទះ។ ព្រោះយើងមានប្រទេសឥណ្ឌូនេស៊ី ដែលអ្វីៗគឺអាក្រក់។ នេះគឺជាកន្លែងដែលបញ្ហាថេរ។

យើងបានគិតអំពីរបៀបដែលយើងអាចត្រួតពិនិត្យយ៉ាងពិតប្រាកដថាតើវាទំនងជាថាកំណត់ហេតុដែលយើងបានកត់ត្រាពីកម្មវិធីនឹងឈានដល់ទីបញ្ចប់ដែរឬទេ? យើងបានសម្រេចចិត្តបង្កើតម៉ែត្រ។ rsyslog មាន​ម៉ូឌុល​ប្រមូល​ស្ថិតិ​ផ្ទាល់​ខ្លួន​ដែល​មាន​ប្រភេទ​បញ្ជរមួយចំនួន។ ឧទាហរណ៍ វាអាចបង្ហាញអ្នកពីទំហំនៃជួរ ឬចំនួនសារដែលបានមកដល់ក្នុងសកម្មភាពបែបនេះ។ អ្នកអាចយកអ្វីមួយពីពួកគេរួចហើយ។ លើសពីនេះ វាមានបញ្ជរផ្ទាល់ខ្លួនដែលអាចកំណត់រចនាសម្ព័ន្ធបាន ហើយវានឹងបង្ហាញអ្នកឧទាហរណ៍ ចំនួនសារដែល API មួយចំនួនបានកត់ត្រា។ បន្ទាប់មកខ្ញុំបានសរសេរ rsyslog_exporter នៅក្នុង Python ហើយយើងបានផ្ញើវាទាំងអស់ទៅ Prometheus និងបង្កើតក្រាហ្វ។ យើងពិតជាចង់បានរង្វាស់ Graylog ប៉ុន្តែយើងមិនទាន់មានពេលកំណត់វានៅឡើយទេ។

តើមានបញ្ហាអ្វីខ្លះ? បញ្ហាបានកើតឡើងនៅពេលដែលយើងបានរកឃើញ (ភ្លាមៗ!) ដែល Live APIs របស់យើងកំពុងសរសេរសារ 50k ក្នុងមួយវិនាទី។ នេះគ្រាន់តែជា Live API ប៉ុណ្ណោះដែលមិនមានដំណាក់កាល។ ហើយ Graylog បង្ហាញយើងត្រឹមតែ 12 ពាន់សារក្នុងមួយវិនាទី។ ហើយសំណួរសមហេតុផលមួយបានកើតឡើង: តើនៅសល់នៅឯណា? ពីអ្វីដែលយើងបានសន្និដ្ឋានថា Graylog មិនអាចដោះស្រាយបានទេ។ យើងមើលទៅ ហើយជាការពិត Graylog និង Elasticsearch មិនអាចដោះស្រាយលំហូរនេះបានទេ។

បន្ទាប់មក ការរកឃើញផ្សេងទៀតដែលយើងបានធ្វើនៅតាមផ្លូវ។

ការសរសេរទៅរន្ធត្រូវបានរារាំង។ តើវាកើតឡើងដោយរបៀបណា? នៅពេលដែលខ្ញុំកំពុងប្រើ rsyslog សម្រាប់ការចែកចាយ នៅចំណុចខ្លះឆានែលរវាងមជ្ឈមណ្ឌលទិន្នន័យបានខូច។ ការដឹកជញ្ជូនឈប់នៅកន្លែងមួយ ការដឹកជញ្ជូនឈប់នៅកន្លែងផ្សេង។ ទាំងអស់នេះបានទៅដល់ម៉ាស៊ីនជាមួយនឹង APIs ដែលសរសេរទៅកាន់ rsyslog socket។ មានជួរមួយនៅទីនោះ។ បន្ទាប់មកជួរសម្រាប់សរសេរទៅរន្ធយូនីក ដែលតាមលំនាំដើមគឺ 128 កញ្ចប់ត្រូវបានបំពេញ។ ហើយការសរសេរបន្ទាប់នៅក្នុងកម្មវិធីត្រូវបានរារាំង។ នៅពេលយើងមើលបណ្ណាល័យដែលយើងប្រើក្នុងកម្មវិធី Go វាត្រូវបានសរសេរនៅទីនោះថាការសរសេរទៅកាន់រន្ធកើតឡើងនៅក្នុងរបៀបមិនទប់ស្កាត់។ យើងប្រាកដថាគ្មានអ្វីត្រូវបានរារាំងទេ។ ដោយសារតែយើងអាន អត្ថបទអំពី Badushechkaដែលបានសរសេរអំពីវា។ ប៉ុន្តែមានពេលមួយ។ វាក៏មានរង្វិលជុំគ្មានកំណត់ជុំវិញការហៅទូរសព្ទនេះ ដែលក្នុងនោះមានការព្យាយាមឥតឈប់ឈរដើម្បីរុញសារចូលទៅក្នុងរន្ធ។ យើងមិនបានកត់សម្គាល់គាត់ទេ។ ខ្ញុំត្រូវសរសេរបណ្ណាល័យឡើងវិញ។ ចាប់តាំងពីពេលនោះមកវាបានផ្លាស់ប្តូរជាច្រើនដង ប៉ុន្តែឥឡូវនេះយើងបានកម្ចាត់ការទប់ស្កាត់នៅក្នុងប្រព័ន្ធរងទាំងអស់។ ដូច្នេះអ្នកអាចបញ្ឈប់ rsyslog ហើយគ្មានអ្វីនឹងគាំងទេ។

វាចាំបាច់ក្នុងការត្រួតពិនិត្យទំហំនៃជួរដែលជួយជៀសវាងការបោះជំហានលើតុងរួចនេះ។ ទីមួយ យើងអាចតាមដាននៅពេលដែលយើងចាប់ផ្តើមបាត់បង់សារ។ ទីពីរ យើងអាចតាមដានថាយើងមានបញ្ហាជាមួយនឹងការចែកចាយ។

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

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

នៅពេលនៃរបាយការណ៍របស់ខ្ញុំ គ្រោងការណ៍បានចាប់ផ្តើមមើលទៅដូចនេះ។ យើង​ឈប់​សរសេរ​ទៅ​ឯកសារ។ ឥឡូវនេះ ភាគច្រើនទំនងជាយើងនឹងបិទអ្វីដែលនៅសល់។ នៅលើម៉ាស៊ីនក្នុងស្រុកដែលដំណើរការ API យើងនឹងឈប់សរសេរទៅឯកសារ។ ទីមួយមានកន្លែងផ្ទុកឯកសារ ដែលដំណើរការល្អណាស់។ ទីពីរ ម៉ាស៊ីនទាំងនេះកំពុងអស់ឥតឈប់ឈរ វាត្រូវតែត្រួតពិនិត្យជានិច្ច។

ផ្នែកនេះជាមួយ Logstash និង Graylog វាពិតជាដំណើរការ។ ដូច្នេះហើយ យើងត្រូវកម្ចាត់វាចោល។ អ្នកត្រូវជ្រើសរើសរឿងមួយ។

យើងបានសម្រេចចិត្តបោះ Logstash និង Kibana ចេញ។ ព្រោះយើងមានផ្នែកសន្តិសុខ។ ទំនាក់ទំនងអ្វី? ការតភ្ជាប់គឺថា Kibana ដោយគ្មាន X-Pack និងដោយគ្មាន Shield មិនអនុញ្ញាតឱ្យអ្នកបែងចែកសិទ្ធិចូលប្រើកំណត់ហេតុ។ នោះហើយជាមូលហេតុដែលយើងយក Graylog ។ វាមានទាំងអស់។ ខ្ញុំមិនចូលចិត្តទេ ប៉ុន្តែវាដំណើរការ។ យើងបានទិញផ្នែករឹងថ្មី ដំឡើង Graylog ថ្មីនៅទីនោះ ហើយផ្ទេរកំណត់ហេតុទាំងអស់ដែលមានទម្រង់តឹងរឹងទៅ Graylog ដាច់ដោយឡែក។ យើងបានដោះស្រាយបញ្ហាជាមួយនឹងប្រភេទផ្សេងគ្នានៃវាលដូចគ្នាបេះបិទដោយអង្គការ។

អ្វីដែលពិតប្រាកដត្រូវបានរួមបញ្ចូលនៅក្នុង Graylog ថ្មី។ យើងគ្រាន់តែសរសេរអ្វីគ្រប់យ៉ាងទៅក្នុង docker ។ យើង​បាន​យក​ម៉ាស៊ីន​មេ​មួយ​ក្រុម​ចេញ​នូវ​ឧទាហរណ៍ Kafka ចំនួន​បី 7 Graylog servers កំណែ 2.3 (ព្រោះ​យើង​ចង់​បាន Elasticsearch កំណែ 5)។ ទាំងអស់នេះត្រូវបានប្រមូលកំឡុងពេលវាយឆ្មក់ពី HDD ។ យើងបានឃើញអត្រាបង្កើតលិបិក្រមរហូតដល់ 100 ពាន់សារក្នុងមួយវិនាទី។ យើងបានឃើញតួលេខថាទិន្នន័យ 140 តេរ៉ាបៃក្នុងមួយសប្តាហ៍។

ហើយម្តងទៀតតុងរួច! យើង​មាន​ការ​លក់​ពីរ​មក​ហើយ។ យើងបានផ្លាស់ប្តូរលើសពី 6 លានសារ។ Graylog មិនមានពេលវេលាដើម្បីទំពាទេ។ ដូចម្ដេចដែលយើងត្រូវរស់ឡើងវិញ។

នេះជារបៀបដែលយើងបានរស់រានមានជីវិត។ យើងបានបន្ថែមម៉ាស៊ីនមេ និង SSDs មួយចំនួនទៀត។ នៅពេលនេះយើងរស់នៅតាមរបៀបនេះ។ ឥឡូវនេះយើងកំពុងទំពារសារ 160k ក្នុងមួយវិនាទីរួចហើយ។ យើងមិនទាន់ឈានដល់កម្រិតកំណត់នៅឡើយ ដូច្នេះវាមិនច្បាស់ទេថា តើយើងអាចរួចផុតពីបញ្ហានេះបានប៉ុន្មាន។

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

ប្រមូលម៉ែត្រពី Graylog ។

កំណត់អត្រាការប្រាក់ដើម្បីឱ្យយើងមាន API ឆ្កួតមួយដែលមិនសម្លាប់កម្រិតបញ្ជូនរបស់យើង និងអ្វីៗផ្សេងទៀត។

ហើយចុងក្រោយ សូមចុះហត្ថលេខាលើប្រភេទ SLA មួយចំនួនជាមួយអ្នកអភិវឌ្ឍន៍ ដូច្នេះយើងអាចបម្រើវាបានច្រើន។ បើសរសេរបន្ថែម សុំទោសផង

និងសរសេរឯកសារ។

ដោយសង្ខេប លទ្ធផលនៃអ្វីគ្រប់យ៉ាងដែលយើងជួបប្រទះ។ ទីមួយស្តង់ដារ។ ទីពីរ syslog គឺជានំខេក។ ទីបី rsyslog ដំណើរការយ៉ាងពិតប្រាកដដូចដែលវាត្រូវបានសរសេរនៅលើស្លាយ។ ហើយសូមបន្តទៅសំណួរ។

សំណួរ.

សំណួររបស់អ្នក៖ ហេតុអ្វីបានជាអ្នកសម្រេចចិត្តមិនយក... (filebeat?)

ឆ្លើយតប៖ យើង​ត្រូវ​សរសេរ​ទៅ​ឯកសារ។ ខ្ញុំពិតជាមិនចង់ទេ។ នៅពេលដែល API របស់អ្នកសរសេរសាររាប់ពាន់ក្នុងមួយវិនាទី ទោះបីជាអ្នកបង្វិលវាម្តងក្នុងមួយម៉ោងក៏ដោយ វានៅតែមិនមែនជាជម្រើសទេ។ អ្នកអាចសរសេរនៅក្នុងបំពង់។ ដែលអ្នកអភិវឌ្ឍន៍បានសួរខ្ញុំថា "តើនឹងមានអ្វីកើតឡើងប្រសិនបើដំណើរការដែលយើងកំពុងសរសេរទៅគាំង?" ខ្ញុំ​រក​មិន​ឃើញ​អ្វី​ដែល​ត្រូវ​ឆ្លើយ​នឹង​ពួក​គេ​ទេ ហើយ​បាន​និយាយ​ថា​៖ ​«​មិន​អី​ទេ យើង​មិន​ធ្វើ​បែប​នោះ​ទេ»។

សំណួររបស់អ្នក៖ ហេតុអ្វីបានជាអ្នកមិនគ្រាន់តែសរសេរកំណត់ហេតុទៅ HDFS?

ឆ្លើយតប៖ នេះជាដំណាក់កាលបន្ទាប់។ យើងបានគិតអំពីវានៅដើមដំបូង ប៉ុន្តែដោយសារនៅពេលនេះមិនមានធនធានដើម្បីធ្វើរឿងនេះទេ វាបានព្យួរនៅក្នុងដំណោះស្រាយរយៈពេលវែងរបស់យើង។

សំណួររបស់អ្នក៖ ទ្រង់ទ្រាយជួរឈរនឹងកាន់តែសមស្រប។

ឆ្លើយតប: ខ្ញុំ​យល់។ យើងសម្រាប់វាដោយដៃទាំងពីរ។

សំណួររបស់អ្នក៖ អ្នកកំពុងសរសេរទៅកាន់ rsyslog ។ នៅទីនោះអ្នកអាចប្រើទាំង TCP និង UDP ។ ប៉ុន្តែប្រសិនបើ UDP តើអ្នកធានាការដឹកជញ្ជូនដោយរបៀបណា?

ឆ្លើយតប៖ មាន​ពីរ​ចំណុច។ ជាដំបូង ខ្ញុំប្រាប់អ្នកគ្រប់គ្នាភ្លាមៗថា យើងមិនធានាការដឹកជញ្ជូនឈើនោះទេ។ ដោយសារតែនៅពេលដែលអ្នកអភិវឌ្ឍន៍មកនិយាយ៖ "តោះចាប់ផ្តើមសរសេរទិន្នន័យហិរញ្ញវត្ថុនៅទីនោះ ហើយអ្នកនឹងដាក់វានៅកន្លែងណាមួយសម្រាប់ពួកយើង ក្នុងករណីមានអ្វីមួយកើតឡើង" យើងឆ្លើយទៅពួកគេថា "ល្អណាស់! ចូរចាប់ផ្តើមបិទការសរសេរទៅកាន់រន្ធ ហើយធ្វើកិច្ចការនេះក្នុងប្រតិបត្តិការ ដូច្នេះអ្នកត្រូវបានធានាថានឹងដាក់វានៅលើរន្ធសម្រាប់យើង ហើយត្រូវប្រាកដថាយើងទទួលបានវាពីភាគីម្ខាងទៀត។” ហើយនៅពេលនេះ មនុស្សគ្រប់គ្នាលែងត្រូវការវាទៀតហើយ។ បើមិនចាំបាច់ តើយើងត្រូវសួរសំណួរអ្វីខ្លះ? ប្រសិនបើអ្នកមិនចង់ធានាការសរសេរទៅកាន់រន្ធទេ ហេតុអ្វីបានជាយើងត្រូវការធានាការដឹកជញ្ជូន? យើងកំពុងខិតខំប្រឹងប្រែងអស់ពីសមត្ថភាពរបស់យើង។ យើងពិតជាព្យាយាមចែកចាយឱ្យបានច្រើនតាមតែអាចធ្វើទៅបាន និងតាមវិធីល្អបំផុត ប៉ុន្តែយើងមិនផ្តល់ការធានា 100% ទេ។ ដូច្នេះមិនចាំបាច់សរសេរទិន្នន័យហិរញ្ញវត្ថុនៅទីនោះទេ។ មានមូលដ្ឋានទិន្នន័យដែលមានប្រតិបត្តិការសម្រាប់ការនេះ។

សំណួររបស់អ្នក៖ នៅពេលដែល API បង្កើតសារមួយចំនួននៅក្នុង log និងផ្ទេរការគ្រប់គ្រងទៅ microservices តើអ្នកបានជួបប្រទះបញ្ហាដែលសារពី microservices ផ្សេងៗមកដល់ក្នុងលំដាប់ខុសទេ? នេះបណ្តាលឱ្យមានការភ័ន្តច្រឡំ។

ឆ្លើយតប៖ វា​ជា​រឿង​ធម្មតា​ទេ​ដែល​ពួកគេ​មក​តាម​លំដាប់​ផ្សេង។ អ្នកត្រូវតែត្រៀមខ្លួនសម្រាប់រឿងនេះ។ ដោយសារតែការដឹកជញ្ជូនតាមបណ្តាញណាមួយមិនធានានូវការបញ្ជាទិញ ឬអ្នកត្រូវចំណាយធនធានពិសេសលើបញ្ហានេះ។ ប្រសិនបើយើងយកកន្លែងផ្ទុកឯកសារ នោះ API នីមួយៗរក្សាទុកកំណត់ហេតុទៅក្នុងឯកសាររបស់វា។ ឬផ្ទុយទៅវិញនៅទីនោះ rsyslog តម្រៀបពួកវាទៅក្នុងថត។ API នីមួយៗមានកំណត់ហេតុផ្ទាល់ខ្លួន ដែលអ្នកអាចចូលទៅមើល ហើយបន្ទាប់មកអ្នកអាចប្រៀបធៀបពួកវាដោយប្រើត្រាពេលវេលានៅក្នុងកំណត់ហេតុនេះ។ ប្រសិនបើពួកគេមើលទៅក្នុង Graylog នោះពួកគេត្រូវបានតម្រៀបនៅទីនោះតាមពេលវេលា។ អ្វីៗនឹងល្អនៅទីនោះ។

សំណួររបស់អ្នក៖ ត្រាពេលវេលាអាចប្រែប្រួលដោយមិល្លីវិនាទី។

ឆ្លើយតប៖ ត្រាពេលវេលាត្រូវបានបង្កើតដោយ API ខ្លួនវាផ្ទាល់។ តាមពិតនេះគឺជាចំណុចទាំងមូល។ យើងមាន NTP ។ API បង្កើតត្រាពេលវេលានៅក្នុងសារខ្លួនវាផ្ទាល់។ rsyslog មិនបន្ថែមវាទេ។

សំណួររបស់អ្នក៖ អន្តរកម្មរវាងមជ្ឈមណ្ឌលទិន្នន័យគឺមិនច្បាស់ទេ។ នៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យ វាច្បាស់ណាស់អំពីរបៀបដែលកំណត់ហេតុត្រូវបានប្រមូល និងដំណើរការ។ តើអន្តរកម្មរវាងមជ្ឈមណ្ឌលទិន្នន័យកើតឡើងយ៉ាងដូចម្តេច? ឬមជ្ឈមណ្ឌលទិន្នន័យនីមួយៗមានជីវិតផ្ទាល់ខ្លួន?

ឆ្លើយតប៖ ស្ទើរតែ។ នៅក្នុងប្រទេសរបស់យើង ប្រទេសនីមួយៗមានទីតាំងនៅមជ្ឈមណ្ឌលទិន្នន័យតែមួយ។ នៅពេលនេះ យើងមិនមានការផ្សព្វផ្សាយទេ ដូច្នេះប្រទេសមួយមានទីតាំងនៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យផ្សេងៗគ្នា។ ដូច្នេះមិនចាំបាច់បញ្ចូលគ្នាទេ។ មជ្ឈមណ្ឌលនីមួយៗមាន Log Relay នៅខាងក្នុង។ នេះគឺជាម៉ាស៊ីនមេ Rsyslog ។ តាមពិតម៉ាស៊ីនគ្រប់គ្រងពីរ។ ពួកគេមានអាកប្បកិរិយាដូចគ្នា។ ប៉ុន្តែ​សម្រាប់​ពេល​នេះ ចរាចរណ៍​គ្រាន់​តែ​ឆ្លងកាត់​មួយ​ក្នុង​ចំណោម​ពួកគេ​ប៉ុណ្ណោះ។ វាប្រមូលផ្តុំកំណត់ហេតុទាំងអស់។ នាងមានជួរឌីសក្នុងករណី។ វាទាញយកកំណត់ហេតុហើយបញ្ជូនវាទៅមជ្ឈមណ្ឌលទិន្នន័យកណ្តាល (សិង្ហបុរី) ដែលជាកន្លែងដែលពួកគេត្រូវបានបញ្ជូនទៅ Graylog ។ ហើយមជ្ឈមណ្ឌលទិន្នន័យនីមួយៗមានកន្លែងផ្ទុកឯកសារផ្ទាល់ខ្លួន។ ក្នុងករណីដែលការតភ្ជាប់របស់យើងត្រូវបានបាត់បង់ យើងមានកំណត់ហេតុទាំងអស់នៅទីនោះ។ ពួកគេនឹងនៅទីនោះ។ ពួកគេនឹងត្រូវបានរក្សាទុកនៅទីនោះ។

សំណួររបស់អ្នក៖ ក្នុង​ករណី​មាន​ស្ថានភាព​មិន​ប្រក្រតី តើ​អ្នក​ទទួល​កំណត់ហេតុ​ពី​ទីនោះ​ទេ?

ឆ្លើយតប៖ អ្នកអាចទៅទីនោះ (ទៅកាន់កន្លែងផ្ទុកឯកសារ) ហើយមើល។

សំណួររបស់អ្នក៖ តើ​អ្នក​ត្រួត​ពិនិត្យ​ដោយ​របៀប​ណា​ថា​អ្នក​មិន​បាត់​បង់​ឈើ?

ឆ្លើយតប៖ យើងពិតជាបាត់បង់ពួកគេ ហើយយើងកំពុងតាមដានវា។ ការត្រួតពិនិត្យត្រូវបានចាប់ផ្តើមកាលពីមួយខែមុន។ បណ្ណាល័យដែល Go APIs ប្រើមានម៉ែត្រ។ នាងអាចរាប់ចំនួនដងដែលនាងមិនអាចសរសេរទៅកាន់រន្ធមួយ។ បច្ចុប្បន្ន​មាន​វោហាសាស្ត្រ​ដ៏​ឆ្លាតវៃ​នៅ​ទីនោះ។ មានទ្រនាប់នៅទីនោះ។ វាព្យាយាមសរសេរសារពីវាទៅរន្ធ។ ប្រសិនបើសតិបណ្ដោះអាសន្នហៀរចេញ វាចាប់ផ្តើមទម្លាក់ពួកគេ។ ហើយ​គាត់​បាន​រាប់​ចំនួន​ដែល​គាត់​បាន​ទម្លាក់។ ប្រសិនបើម៉ែត្រចាប់ផ្តើមហៀរនៅទីនោះយើងនឹងដឹងអំពីវា។ ឥឡូវនេះពួកគេក៏កំពុងមក Prometheus ហើយអ្នកអាចមើលឃើញក្រាហ្វនៅក្នុង Grafana ។ អ្នកអាចកំណត់ការជូនដំណឹង។ ប៉ុន្តែ​គេ​មិន​ទាន់​ដឹង​ថា​ត្រូវ​បញ្ជូន​ទៅ​នរណា​ទេ។

សំណួររបស់អ្នក៖ នៅក្នុង elasticsearch អ្នករក្សាទុកកំណត់ហេតុជាមួយនឹងការប្រើឡើងវិញ។ តើអ្នកមានរូបចម្លងប៉ុន្មាន?

ឆ្លើយតប៖ មួយជួរ។

សំណួររបស់អ្នក៖ តើ​នេះ​គ្រាន់​តែ​មួយ​បន្ទាត់​ទេ?

ឆ្លើយតប៖ នេះជាមេ និងចម្លង។ ទិន្នន័យត្រូវបានរក្សាទុកជាពីរច្បាប់ចម្លង។

សំណួររបស់អ្នក៖ តើអ្នកបានកែតម្រូវទំហំសតិបណ្ដោះអាសន្ន rsyslog ដូចម្ដេច?

ឆ្លើយតប៖ យើងសរសេរ datagrams ទៅរន្ធ unix ផ្ទាល់ខ្លួន។ វាកំណត់ដែនកំណត់ 128 គីឡូបៃភ្លាមៗមកលើយើង។ យើងមិនអាចសរសេរបន្ថែមលើវាបានទេ។ យើងបានសរសេរវាទៅក្នុងស្តង់ដារ។ អ្នកដែលចង់ចូលទៅក្នុងការផ្ទុកសរសេរ 128 គីឡូបៃ។ លើសពីនេះ បណ្ណាល័យត្រូវបានកាត់ផ្តាច់ ហើយទង់មួយត្រូវបានដាក់ថាសារត្រូវបានកាត់ផ្តាច់។ ស្តង់ដាររបស់យើងសម្រាប់សារខ្លួនវាមានវាលពិសេសដែលបង្ហាញថាវាត្រូវបានកាត់ផ្តាច់ក្នុងអំឡុងពេលថតឬអត់។ ដូច្នេះ​យើង​មាន​ឱកាស​តាម​ដាន​ពេល​នេះ​ផង​ដែរ។

សំណួរ៖ តើអ្នកសរសេរ JSON ខូចទេ?

ឆ្លើយតប៖ ខូច JSON នឹងត្រូវបានលុបចោលក្នុងពេលបញ្ជូនបន្ត ពីព្រោះកញ្ចប់ធំពេក។ ឬ Graylog នឹងត្រូវបានលុបចោល ព្រោះវាមិនអាចញែក JSON បានទេ។ ប៉ុន្តែមាន nuances ដែលត្រូវជួសជុល ហើយពួកវាភាគច្រើនត្រូវបានចងភ្ជាប់ទៅនឹង rsyslog ។ ខ្ញុំ​បាន​បំពេញ​បញ្ហា​ជា​ច្រើន​នៅ​ទីនោះ​រួច​ហើយ ដែល​នៅ​តែ​ត្រូវ​ដោះស្រាយ។

សំណួរ៖ ហេតុអ្វី Kafka? តើអ្នកបានសាកល្បង RabbitMQ ហើយឬនៅ? តើ Graylog បរាជ័យក្រោមបន្ទុកបែបនេះទេ?

ឆ្លើយតប៖ វាមិនដំណើរការសម្រាប់យើងជាមួយ Graylog ទេ។ ហើយ Graylog កំពុងបង្កើតរូបរាងសម្រាប់យើង។ គាត់ពិតជាមានបញ្ហា។ គាត់​ជា​រឿង​ប្លែក។ ហើយតាមការពិតវាមិនចាំបាច់ទេ។ ខ្ញុំចង់សរសេរពី rsyslog ដោយផ្ទាល់ទៅ elasticsearch ហើយបន្ទាប់មកមើល Kibana ។ ប៉ុន្តែ​យើង​ត្រូវ​ដោះស្រាយ​បញ្ហា​ជាមួយ​សន្តិសុខ។ នេះគឺជាជម្រើសដែលអាចធ្វើទៅបានសម្រាប់ការអភិវឌ្ឍន៍របស់យើង នៅពេលដែលយើងបោះ Graylog ហើយប្រើ Kibana ។ ការប្រើ Logstash មិនមានចំណុចសំខាន់ទេ។ ដោយសារតែខ្ញុំអាចធ្វើដូចគ្នាជាមួយ rsyslog ។ ហើយវាមានម៉ូឌុលសម្រាប់សរសេរទៅ elasticsearch ។ យើងកំពុងព្យាយាមរស់នៅជាមួយ Graylog ។ យើងថែមទាំងបានកែសម្រួលវាបន្តិច។ ប៉ុន្តែនៅតែមានកន្លែងសម្រាប់កែលម្អ។

អំពី Kafka ។ នេះជារបៀបដែលវាបានកើតឡើងជាប្រវត្តិសាស្ត្រ។ ពេល​ខ្ញុំ​ទៅ​ដល់ វា​បាន​ទៅ​ដល់​ហើយ ហើយ​កំណត់​ហេតុ​ក៏​ត្រូវ​បាន​សរសេរ​ទៅ​វា​ដែរ។ យើងគ្រាន់តែលើកចង្កោមរបស់យើង ហើយផ្លាស់ទីកំណត់ហេតុចូលទៅក្នុងវា។ យើងជាអ្នកគ្រប់គ្រងរបស់គាត់ យើងដឹងពីអារម្មណ៍របស់គាត់ សម្រាប់ RabbitMQ ... វាមិនដំណើរការសម្រាប់យើងជាមួយ RabbitMQ ទេ។ ហើយ RabbitMQ កំពុងរៀបចំសម្រាប់ពួកយើង។ យើងមានវានៅក្នុងផលិតកម្ម ហើយមានបញ្ហាជាមួយវា។ ឥឡូវនេះមុនពេលលក់ ពួកគេនឹងទាក់ទាញគាត់ ហើយគាត់នឹងចាប់ផ្តើមធ្វើការជាធម្មតា។ ប៉ុន្តែ​មុន​នោះ​ខ្ញុំ​មិន​ទាន់​ត្រៀម​ខ្លួន​ចេញ​ចូល​ផលិតកម្ម​ទេ។ មានចំណុចមួយទៀត។ Graylog អាចអានកំណែ AMQP 0.9 ហើយ rsyslog អាចសរសេរកំណែ AMQP 1.0 ។ ហើយមិនមានដំណោះស្រាយតែមួយនៅកណ្តាលដែលអាចធ្វើទាំងពីរនោះទេ។ វាគឺមួយឬផ្សេងទៀត។ ដូច្នេះនៅពេលនេះមានតែ Kafka ប៉ុណ្ណោះ។ ប៉ុន្តែវាក៏មាន nuances ផ្ទាល់ខ្លួនផងដែរ។ ដោយសារតែ omkafka នៃកំណែរបស់ rsyslog ដែលយើងប្រើអាចបាត់បង់សារទាំងមូលដែលវាបានទាញយកចេញពី rsyslog ។ សម្រាប់​ពេលនេះ​យើង​បាន​ដាក់​ជាមួយ​វា​។

សំណួរ: តើអ្នកប្រើ Kafka ទេព្រោះអ្នកមានវារួចហើយ? លែងប្រើសម្រាប់គោលបំណងណាមួយហើយឬនៅ?

ឆ្លើយតប៖ Kafka ដែលត្រូវបានប្រើដោយក្រុមវិទ្យាសាស្ត្រទិន្នន័យ។ នេះគឺជាគម្រោងដាច់ដោយឡែកទាំងស្រុង ដែល ជាអកុសល ខ្ញុំមិនអាចនិយាយអ្វីបានទេ។ ខ្ញុំ​មិនដឹង​ទេ។ វាត្រូវបានគ្រប់គ្រងដោយក្រុមវិទ្យាសាស្ត្រទិន្នន័យ។ នៅពេលដែលកំណត់ហេតុត្រូវបានបង្កើត យើងបានសម្រេចចិត្តប្រើវា ដើម្បីកុំឱ្យដំឡើងវាដោយខ្លួនឯង។ ឥឡូវនេះយើងបានអាប់ដេត Graylog ហើយយើងបានបាត់បង់ភាពឆបគ្នាព្រោះវាមានកំណែចាស់របស់ Kafka ។ យើងត្រូវចាប់ផ្តើមដោយខ្លួនឯង។ ក្នុងពេលជាមួយគ្នានេះ យើងបានកម្ចាត់ប្រធានបទទាំងបួននេះសម្រាប់ API នីមួយៗ។ យើងបានបង្កើតប្រធានបទដ៏ធំទូលាយមួយសម្រាប់ការផ្សាយបន្តផ្ទាល់ទាំងអស់ ប្រធានបទធំទូលាយមួយសម្រាប់គ្រប់ឆាកទាំងអស់ ហើយគ្រាន់តែដាក់អ្វីគ្រប់យ៉ាងនៅទីនោះ។ Graylog បំបែកអ្វីៗទាំងអស់នេះស្របគ្នា។

សំណួរ៖ ហេតុអ្វីបានជាយើងត្រូវការ shamanism នេះជាមួយនឹងរន្ធ? តើអ្នកបានសាកល្បងប្រើកម្មវិធីបញ្ជាកំណត់ហេតុ syslog សម្រាប់កុងតឺន័រហើយឬនៅ?

ឆ្លើយតប៖ នៅពេលយើងសួរសំណួរនេះ ទំនាក់ទំនងរបស់យើងជាមួយ docker មានភាពតានតឹង។ វាជា docker 1.0 ឬ 0.9 ។ Docker ខ្លួនឯងគឺចម្លែក។ ទីពីរ ប្រសិនបើអ្នកក៏រុញកំណត់ហេតុចូលទៅក្នុងវា... ខ្ញុំមានការសង្ស័យដែលមិនអាចផ្ទៀងផ្ទាត់បានថាវាឆ្លងកាត់កំណត់ហេតុទាំងអស់តាមរយៈខ្លួនវា តាមរយៈដេមិន docker ។ ប្រសិនបើ API មួយឆ្កួត នោះ APIs ដែលនៅសល់ត្រូវជាប់គាំងនៅក្នុងការពិតដែលថាពួកគេមិនអាចផ្ញើ stdout និង stderr បានទេ។ ខ្ញុំមិនដឹងថាវានឹងនាំទៅណាទេ។ ខ្ញុំមានការសង្ស័យក្នុងកម្រិតនៃអារម្មណ៍ថាមិនចាំបាច់ប្រើកម្មវិធីបញ្ជា Docker syslog នៅកន្លែងនេះទេ។ នាយកដ្ឋានសាកល្បងមុខងាររបស់យើងមានចង្កោម Graylog ផ្ទាល់ខ្លួនជាមួយនឹងកំណត់ហេតុ។ ពួកគេប្រើកម្មវិធីបញ្ជាកំណត់ហេតុ Docker ហើយអ្វីៗហាក់ដូចជាល្អនៅទីនោះ។ ប៉ុន្តែពួកគេសរសេរ GELF ទៅ Graylog ភ្លាមៗ។ នៅពេលដែលយើងចាប់ផ្តើមអ្វីៗទាំងអស់នេះ យើងគ្រាន់តែត្រូវការវាដើម្បីដំណើរការ។ ប្រហែលជាពេលក្រោយ នៅពេលដែលនរណាម្នាក់មក ហើយនិយាយថាវាដំណើរការល្អមួយរយឆ្នាំ យើងនឹងព្យាយាម។

សំណួរ៖ អ្នកធ្វើការចែកចាយរវាងមជ្ឈមណ្ឌលទិន្នន័យដោយប្រើ rsyslog ។ ហេតុអ្វីមិន Kafka?

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

ប្រភព: www.habr.com