នៅពេលដែលយើងផ្លាស់ប្តូរពីកម្មវិធី monolithic ទៅ microservice ស្ថាបត្យកម្ម យើងប្រឈមមុខនឹងបញ្ហាប្រឈមថ្មី។

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

ខ្ញុំ​បាន​ស្វែង​រក​ជា​យូរ​មក​ហើយ​សម្រាប់​ឧបករណ៍​ដែល​អាច​ជួយ​ដោះ​ស្រាយ​បញ្ហា​បែប​នេះ (ខ្ញុំ​បាន​សរសេរ​អំពី​រឿង​នេះ​នៅ​លើ Habre: 1, 2) ប៉ុន្តែនៅទីបញ្ចប់ខ្ញុំបានបង្កើតដំណោះស្រាយប្រភពបើកចំហផ្ទាល់ខ្លួនរបស់ខ្ញុំ។ នៅក្នុងអត្ថបទនេះខ្ញុំនិយាយអំពីអត្ថប្រយោជន៍នៃវិធីសាស្រ្តសំណាញ់សេវា និងចែករំលែកឧបករណ៍ថ្មីសម្រាប់ការអនុវត្តរបស់វា។

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

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

វិធីសាស្រ្តសំណាញ់សេវាកម្ម

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

ដំណោះស្រាយ

មានការអនុវត្តជាច្រើននៃវិធីសាស្រ្តនេះរួចហើយ៖ អ៊ីស៊ីអូ и linkerd2. ពួកគេផ្តល់នូវលក្ខណៈពិសេសជាច្រើនចេញពីប្រអប់។ ប៉ុន្តែទន្ទឹមនឹងនោះ ធនធានដ៏ច្រើនកើតឡើង។ ជាងនេះទៅទៀត ចង្កោមកាន់តែធំដែលប្រព័ន្ធបែបនេះដំណើរការ ធនធានកាន់តែច្រើននឹងត្រូវការដើម្បីរក្សាហេដ្ឋារចនាសម្ព័ន្ធថ្មី។ នៅ Avito យើងដំណើរការចង្កោម kubernetes ដែលមានសេវាកម្មរាប់ពាន់ (ហើយចំនួនរបស់ពួកគេបន្តកើនឡើងយ៉ាងឆាប់រហ័ស)។ នៅក្នុងការអនុវត្តបច្ចុប្បន្នរបស់វា Istio ប្រើប្រាស់ RAM ~ 300Mb ក្នុងមួយសេវាកម្ម។ ដោយសារតែចំនួនដ៏ច្រើននៃលទ្ធភាព តុល្យភាពតម្លាភាពក៏ប៉ះពាល់ដល់ពេលវេលាឆ្លើយតបទាំងមូលនៃសេវាកម្ម (រហូតដល់ 10ms)។

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

ជាលទ្ធផលយើងបានឈានដល់ការសម្រេចចិត្តរបស់យើង៖  ណេត្រាម៉េស.

ណេត្រាម៉េស

ណេត្រាម៉េស គឺ​ជា​ដំណោះស្រាយ​សំណាញ់​សេវា​ទម្ងន់​ស្រាល​ដែល​មាន​សមត្ថភាព​ធ្វើ​មាត្រដ្ឋាន​គ្មាន​កំណត់​ដោយ​មិន​គិត​ពី​ចំនួន​សេវាកម្ម​ក្នុង​ប្រព័ន្ធ។

គោលដៅចម្បងនៃដំណោះស្រាយថ្មីគឺការចំណាយលើធនធានទាប និងការអនុវត្តខ្ពស់។ ក្នុង​ចំណោម​មុខងារ​សំខាន់ៗ យើង​ចង់​មាន​លទ្ធភាព​បញ្ជូន​ការ​តាមដាន​យ៉ាង​មាន​តម្លាភាព​ទៅ​ប្រព័ន្ធ Jaeger របស់​យើង។

សព្វថ្ងៃនេះដំណោះស្រាយពពកភាគច្រើនត្រូវបានអនុវត្តនៅក្នុង Golang ។ ហើយពិតណាស់មានហេតុផលសម្រាប់រឿងនេះ។ ការសរសេរកម្មវិធីបណ្តាញនៅក្នុង Golang ដែលធ្វើការអសមកាលជាមួយ I/O និងខ្នាតនៅទូទាំងស្នូលតាមតម្រូវការគឺងាយស្រួល និងសាមញ្ញណាស់។ ហើយអ្វីដែលសំខាន់ផងដែរ ការអនុវត្តគឺគ្រប់គ្រាន់ដើម្បីដោះស្រាយបញ្ហានេះ។ នោះហើយជាមូលហេតុដែលយើងជ្រើសរើស Golang ។

ផលិតភាព

យើងបានផ្តោតការខិតខំប្រឹងប្រែងរបស់យើងលើការសម្រេចបាននូវផលិតភាពអតិបរមា។ សម្រាប់ដំណោះស្រាយដែលត្រូវបានដាក់ពង្រាយនៅជាប់នឹងសេវាកម្មនីមួយៗ ការប្រើប្រាស់ RAM និង CPU តិចតួចគឺត្រូវបានទាមទារ។ ហើយជាការពិត ការពន្យាពេលការឆ្លើយតបក៏គួរតែតូចដែរ។

ចាំមើលថាតើយើងទទួលបានលទ្ធផលអ្វីខ្លះ?

អង្គ​ចងចាំ

Netramesh ប្រើប្រាស់ ~ 10Mb ដោយគ្មានចរាចរណ៍ និងអតិបរមា 50Mb ជាមួយនឹងបន្ទុករហូតដល់ 10000 RPS ក្នុងមួយករណី។

ប្រូកស៊ីបេសកជន Istio តែងតែប្រើប្រាស់ ~300Mb នៅក្នុងចង្កោមរបស់យើងជាមួយនឹងឧទាហរណ៍រាប់ពាន់។ នេះមិនអនុញ្ញាតឱ្យវាធ្វើមាត្រដ្ឋានទៅចង្កោមទាំងមូលទេ។

ជាមួយនឹង Netramesh យើងទទួលបានការថយចុះ ~ 10x នៃការប្រើប្រាស់អង្គចងចាំ។

ស៊ីភីយូ

ការប្រើប្រាស់ស៊ីភីយូគឺស្មើគ្នានៅក្រោមបន្ទុក។ វាអាស្រ័យលើចំនួននៃការស្នើសុំក្នុងមួយឯកតានៃពេលវេលាទៅរថយន្តចំហៀង។ តម្លៃនៅ 3000 សំណើក្នុងមួយវិនាទីនៅកំពូល:

មានចំណុចសំខាន់មួយទៀតគឺ Netramesh - ដំណោះស្រាយដោយគ្មានយន្តហោះគ្រប់គ្រង ហើយគ្មានបន្ទុក មិនស៊ីពេលវេលាស៊ីភីយូទេ។ ជាមួយនឹង Istio រថយន្តចំហៀងតែងតែធ្វើបច្ចុប្បន្នភាពចំណុចបញ្ចប់នៃសេវាកម្ម។ ជាលទ្ធផលយើងអាចឃើញរូបភាពនេះដោយមិនផ្ទុក៖

យើងប្រើ HTTP/1 សម្រាប់ទំនាក់ទំនងរវាងសេវាកម្ម។ ការកើនឡើងនៃពេលវេលាឆ្លើយតបសម្រាប់ Istio នៅពេលប្រូកស៊ីតាមរយៈបេសកជនមានដល់ទៅ 5-10ms ដែលច្រើនណាស់សម្រាប់សេវាកម្មដែលត្រៀមឆ្លើយតបក្នុងមួយមីលីវិនាទី។ ជាមួយនឹង Netramesh ពេលវេលានេះបានថយចុះដល់ 0.5-2ms ។

លទ្ធភាពធ្វើមាត្រដ្ឋាន

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

ការរកឃើញសេវាកម្ម

Netramesh មិនបន្ថែមយន្តការបន្ថែមណាមួយសម្រាប់ការរកឃើញសេវាកម្មទេ។ ចរាចរណ៍ទាំងអស់ត្រូវបានបញ្ជូនដោយតម្លាភាពតាមរយៈ netra sidecar ។

Netramesh គាំទ្រពិធីការកម្មវិធី HTTP/1 ។ ដើម្បីកំណត់វា បញ្ជីច្រកដែលអាចកំណត់រចនាសម្ព័ន្ធបានត្រូវបានប្រើ។ ជាធម្មតា ប្រព័ន្ធមានច្រកជាច្រើន តាមរយៈការទំនាក់ទំនង HTTP កើតឡើង។ ឧទាហរណ៍ យើងប្រើ 80, 8890, 8080 សម្រាប់អន្តរកម្មរវាងសេវាកម្ម និងសំណើខាងក្រៅ ក្នុងករណីនេះ ពួកវាអាចត្រូវបានកំណត់ដោយប្រើអថេរបរិស្ថាន NETRA_HTTP_PORTS.

ប្រសិនបើអ្នកប្រើ Kubernetes ជាអ្នករៀបចំ និងយន្តការអង្គភាពសេវាកម្មរបស់វាសម្រាប់ការទំនាក់ទំនងក្នុងក្រុមរវាងសេវាកម្ម នោះយន្តការនៅតែដដែល។ ដំបូង សេវាមីក្រូទទួលបានអាសយដ្ឋាន IP សេវាកម្មដោយប្រើ kube-dns ហើយបើកការតភ្ជាប់ថ្មីទៅវា។ ការតភ្ជាប់នេះត្រូវបានបង្កើតឡើងជាលើកដំបូងជាមួយនឹង netra-sidecar ក្នុងតំបន់ ហើយកញ្ចប់ TCP ទាំងអស់បានមកដល់ netra ដំបូង។ បន្ទាប់មក netra-sidecar បង្កើតការតភ្ជាប់ជាមួយទិសដៅដើម។ NAT នៅលើ pod IP នៅលើ node នៅតែដូចគ្នាបេះបិទដោយគ្មាន netra ។

ការតាមដានដែលបានចែកចាយ និងការបញ្ជូនបន្តបរិបទ

Netramesh ផ្តល់នូវមុខងារដែលត្រូវការដើម្បីផ្ញើការតាមដានអំពីអន្តរកម្ម HTTP ។ Netra-sidecar ញែកពិធីការ HTTP វាស់វែងការពន្យារពេលស្នើសុំ និងស្រង់ព័ត៌មានចាំបាច់ពីបឋមកថា HTTP ។ ទីបំផុត យើងទទួលបានដានទាំងអស់នៅក្នុងប្រព័ន្ធ Jaeger តែមួយ។ សម្រាប់ការកំណត់រចនាសម្ព័ន្ធល្អ អ្នកក៏អាចប្រើអថេរបរិស្ថានដែលផ្តល់ដោយបណ្ណាល័យផ្លូវការផងដែរ។ បណ្ណាល័យ jaeger ទៅ.

ប៉ុន្តែមានបញ្ហា។ រហូតទាល់តែសេវាកម្មបង្កើត និងផ្ញើបឋមកថា uber ពិសេស យើងនឹងមិនឃើញវិសាលភាពតាមដានដែលបានតភ្ជាប់នៅក្នុងប្រព័ន្ធទេ។ ហើយនេះគឺជាអ្វីដែលយើងត្រូវស្វែងរកឱ្យបានឆាប់រហ័សនូវមូលហេតុនៃបញ្ហា។ នៅទីនេះម្តងទៀត Netramesh មានដំណោះស្រាយ។ ប្រូកស៊ីអានបឋមកថា HTTP ហើយប្រសិនបើពួកគេមិនមានលេខសម្គាល់ uber trace បង្កើតមួយ។ Netramesh ក៏រក្សាទុកព័ត៌មានអំពីសំណើចូល និងចេញនៅក្នុងរថយន្តចំហៀង ហើយផ្គូផ្គងពួកវាដោយពង្រឹងពួកវាជាមួយនឹងបឋមកថាសំណើចេញចាំបាច់។ អ្វីទាំងអស់ដែលអ្នកត្រូវធ្វើនៅក្នុងសេវាកម្មគឺផ្ញើតែបឋមកថាមួយ។ X-Request-Idដែលអាចត្រូវបានកំណត់រចនាសម្ព័ន្ធដោយប្រើអថេរបរិស្ថាន NETRA_HTTP_REQUEST_ID_HEADER_NAME. ដើម្បីគ្រប់គ្រងទំហំនៃបរិបទនៅក្នុង Netramesh អ្នកអាចកំណត់អថេរបរិស្ថានខាងក្រោម៖ NETRA_TRACING_CONTEXT_EXPIRATION_MILLISECONDS (ពេលវេលាដែលបរិបទនឹងត្រូវបានរក្សាទុក) និង NETRA_TRACING_CONTEXT_CLEANUP_INTERVAL (ភាពញឹកញាប់នៃការសម្អាតបរិបទ) ។

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

ការកំណត់ប្រភពសំណើ

ដើម្បីកំណត់កន្លែងដែលសំណើបានមកពី អ្នកអាចប្រើមុខងារនៃការបន្ថែមបឋមកថាដោយស្វ័យប្រវត្តិជាមួយប្រភព។ ការប្រើប្រាស់អថេរបរិស្ថាន NETRA_HTTP_X_SOURCE_HEADER_NAME អ្នកអាចបញ្ជាក់ឈ្មោះបឋមកថាដែលនឹងត្រូវបានដំឡើងដោយស្វ័យប្រវត្តិ។ ដោយប្រើ NETRA_HTTP_X_SOURCE_VALUE អ្នកអាចកំណត់តម្លៃដែលបឋមកថា X-Source នឹងត្រូវបានកំណត់សម្រាប់សំណើដែលចេញទាំងអស់។

នេះអនុញ្ញាតឱ្យការចែកចាយបឋមកថាមានប្រយោជន៍នេះត្រូវបានចែកចាយស្មើៗគ្នានៅទូទាំងបណ្តាញ។ បន្ទាប់មកអ្នកអាចប្រើវានៅក្នុងសេវាកម្ម ហើយបន្ថែមវាទៅក្នុងកំណត់ហេតុ និងម៉ែត្រ។

ផ្លូវចរាចរណ៍ និងផ្នែកខាងក្នុងរបស់ Netramesh

Netramesh មានសមាសធាតុសំខាន់ពីរ។ ទីមួយ netra-init កំណត់ច្បាប់បណ្តាញដើម្បីស្ទាក់ចាប់ចរាចរណ៍។ គាត់ប្រើ iptables បង្វែរច្បាប់ ដើម្បីរារាំងចរាចរណ៍ទាំងអស់ ឬមួយផ្នែកនៅលើរថយន្តចំហៀង ដែលជាធាតុផ្សំសំខាន់ទីពីររបស់ Netramesh ។ អ្នកអាចកំណត់រចនាសម្ព័ន្ធច្រកណាមួយដែលត្រូវស្ទាក់ចាប់សម្រាប់វគ្គ TCP ចូល និងចេញ៖ INBOUND_INTERCEPT_PORTS, OUTBOUND_INTERCEPT_PORTS.

ឧបករណ៍នេះក៏មានលក្ខណៈពិសេសគួរឱ្យចាប់អារម្មណ៍ផងដែរ - ការកំណត់ផ្លូវដែលអាចកើតមាន។ ប្រសិនបើអ្នកប្រើ Netramesh ទាំងស្រុងសម្រាប់ការប្រមូលវិសាលភាពតាមដាន នោះនៅក្នុងបរិយាកាសផលិតកម្ម អ្នកអាចរក្សាទុកធនធាន និងបើកដំណើរការផ្លូវដែលអាចទំនងបានដោយប្រើអថេរ។ NETRA_INBOUND_PROBABILITY и NETRA_OUTBOUND_PROBABILITY (ពី ០ ដល់ ១)។ តម្លៃលំនាំដើមគឺ 0 (ចរាចរណ៍ទាំងអស់ត្រូវបានស្ទាក់ចាប់)។

បន្ទាប់ពីការស្ទាក់ចាប់ដោយជោគជ័យ netra sidecar ទទួលយកការតភ្ជាប់ថ្មី និងប្រើប្រាស់ SO_ORIGINAL_DST ជម្រើសរន្ធដើម្បីទទួលបានគោលដៅដើម។ បន្ទាប់មក Netra បើកការភ្ជាប់ថ្មីទៅកាន់អាសយដ្ឋាន IP ដើម ហើយបង្កើតទំនាក់ទំនង TCP ពីរផ្លូវរវាងភាគី ដោយស្តាប់រាល់ចរាចរណ៍ដែលឆ្លងកាត់។ ប្រសិនបើច្រកត្រូវបានកំណត់ជា HTTP នោះ Netra ព្យាយាមញែក និងតាមដានវា។ ប្រសិនបើការវិភាគ HTTP បរាជ័យ Netra នឹងត្រលប់ទៅ TCP ហើយប្រូកស៊ីបៃបៃដោយតម្លាភាព។

ការបង្កើតក្រាហ្វភាពអាស្រ័យ

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

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

របៀបប្រើ Netramesh

Netra អាច​ត្រូវ​បាន​បន្ថែម​យ៉ាង​ងាយ​ស្រួល​ទៅ​ក្នុង​សេវា​ណា​មួយ​ដែល​ដំណើរ​ការ​វង់​តន្ត្រី​ណា​មួយ​។ អ្នកអាចឃើញឧទាហរណ៍មួយ។ នៅទីនេះ.

នៅពេលនេះ Netra មិនមានលទ្ធភាពក្នុងការអនុវត្តដោយស្វ័យប្រវត្តិនូវ sidecars ទៅកាន់សេវាកម្មនោះទេ ប៉ុន្តែមានផែនការសម្រាប់ការអនុវត្ត។

អនាគតរបស់ Netramesh

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

នៅពេលអនាគត Netramesh នឹងគាំទ្រពិធីការស្រទាប់កម្មវិធីផ្សេងទៀត ក្រៅពី HTTP ។ ផ្លូវ L7 នឹងមានក្នុងពេលឆាប់ៗនេះ។

ប្រើ Netramesh ប្រសិនបើអ្នកជួបប្រទះបញ្ហាស្រដៀងគ្នា ហើយសរសេរមកយើងដោយមានសំណួរ និងការផ្ដល់យោបល់។

ប្រភព: www.habr.com