ការតាមដានដែលបានចែកចាយ៖ យើងបានធ្វើខុសទាំងអស់។

ចំណាំ។ បកប្រែ៖ អ្នកនិពន្ធនៃសម្ភារៈនេះគឺ Cindy Sridharan ដែលជាវិស្វករនៅ imgix ដែលមានជំនាញក្នុងការអភិវឌ្ឍន៍ API និងជាពិសេស ការធ្វើតេស្តមីក្រូសេវា។ នៅក្នុងសម្ភារៈនេះ នាងចែករំលែកនូវចក្ខុវិស័យលម្អិតរបស់នាងអំពីបញ្ហាបច្ចុប្បន្នក្នុងវិស័យតាមដានការចែកចាយ ដែលតាមគំនិតរបស់នាង មានការខ្វះខាតឧបករណ៍ដែលមានប្រសិទ្ធភាពពិតប្រាកដសម្រាប់ដោះស្រាយបញ្ហាចុច។

[រូបភាពដកស្រង់ពី សម្ភារៈផ្សេងទៀត។ អំពីការតាមដានចែកចាយ។]

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

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

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

ដានខុសគ្នាបែបនេះ

ការតាមដានដែលបានចែកចាយរួមមានសមាសធាតុផ្សេងគ្នាជាច្រើន៖

• បំពាក់កម្មវិធី និងឧបករណ៍កណ្តាលជាមួយឧបករណ៍បញ្ជា។
• ការផ្ទេរបរិបទចែកចាយ;
• ការប្រមូលដាន;
• ការផ្ទុកដាន;
• ការទាញយកនិងការមើលឃើញរបស់ពួកគេ។

ការពិភាក្សាជាច្រើនអំពីការតាមដានការចែកចាយមាននិន្នាការចាត់ទុកវាជាប្រភេទនៃប្រតិបត្តិការ unary ដែលគោលបំណងតែមួយគត់គឺដើម្បីជួយធ្វើរោគវិនិច្ឆ័យពេញលេញនៃប្រព័ន្ធ។ នេះភាគច្រើនដោយសារតែគំនិតអំពីការតាមដានការចែកចាយត្រូវបានបង្កើតឡើងជាប្រវត្តិសាស្ត្រ។ IN ធាតុប្លុកដែលធ្វើឡើងនៅពេលដែលប្រភព Zipkin ត្រូវបានបើក វាត្រូវបានលើកឡើងនោះ។ វា [Zipkin] ធ្វើឱ្យ Twitter លឿនជាងមុន. ការផ្តល់ជូនពាណិជ្ជកម្មដំបូងសម្រាប់ការតាមដានក៏ត្រូវបានផ្សព្វផ្សាយផងដែរ។ ឧបករណ៍ APM.

ចំណាំ។ បកប្រែ៖ ដើម្បីធ្វើឱ្យអត្ថបទកាន់តែងាយស្រួលយល់ អនុញ្ញាតឱ្យយើងកំណត់ពាក្យមូលដ្ឋានពីរដោយយោងតាម ឯកសារគម្រោង OpenTracing:

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

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

• ឧទាហរណ៍ Uber ការប្រើប្រាស់ លទ្ធផលតាមដានដើម្បីកំណត់ភាពខុសគ្នារវាងចរាចរណ៍សាកល្បង និងចរាចរណ៍ផលិតកម្ម។
• Facebook ការប្រើប្រាស់ ទិន្នន័យតាមដានសម្រាប់ការវិភាគផ្លូវសំខាន់ និងសម្រាប់ការប្តូរចរាចរណ៍ក្នុងអំឡុងពេលការធ្វើតេស្តសង្គ្រោះគ្រោះមហន្តរាយជាទៀងទាត់។
• បណ្តាញសង្គមផងដែរ។ អនុវត្ត សៀវភៅកត់ត្រា Jupyter ដែលអនុញ្ញាតឱ្យអ្នកអភិវឌ្ឍន៍ដំណើរការសំណួរតាមអំពើចិត្តលើលទ្ធផលដាន។
• អ្នកដើរតាម LDFI (ការ​ចាក់​បញ្ចូល​ការ​បរាជ័យ​ដែល​ជំរុញ​ដោយ​ត្រកូល) ប្រើ ដានចែកចាយសម្រាប់ការធ្វើតេស្តជាមួយនឹងការចាក់កំហុស។

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

ពេល​ដែល​វា​មក នៅឡើយទេ ឈានដល់ស្គ្រីបបំបាត់កំហុស ចំណុចប្រទាក់ចម្បងនៅតែជាដ្យាក្រាម ដាន (ទោះបីជាអ្នកខ្លះហៅវាក៏ដោយ។ "គំនូសតាង Gantt" ឬ "ដ្យាក្រាមទឹកជ្រោះ") នៅក្រោម ដាន я ខ្ញុំ​មាន​ន័យ​ថា វិសាលភាពទាំងអស់ និងទិន្នន័យមេតាដែលភ្ជាប់មកជាមួយ ដែលរួមគ្នាបង្កើតដាន។ រាល់ប្រព័ន្ធតាមដានប្រភពបើកចំហ ក៏ដូចជារាល់ដំណោះស្រាយតាមដានពាណិជ្ជកម្ម ផ្តល់ជូនក ដាន ចំណុចប្រទាក់អ្នកប្រើសម្រាប់ការមើលឃើញ លម្អិត និងត្រងដាន។

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

កាលពីមុន I បានត្អូញត្អែរ ថា "ការច្នៃប្រឌិត" ភាគច្រើននៅក្នុងការតាមដាន UI/UX ហាក់ដូចជាត្រូវបានកំណត់ចំពោះ បើក ទិន្នន័យមេតាបន្ថែមនៅក្នុងដាន ការវិនិយោគលើព័ត៌មានទាំងនោះជាមួយនឹងភាពរឹងមាំខ្ពស់។ (ភាព​ខ្ពស់​) ឬការផ្តល់នូវសមត្ថភាពក្នុងការខួងចូលទៅក្នុងវិសាលភាពជាក់លាក់ ឬដំណើរការសំណួរ អន្តរ និង ដាន... ម្ល៉ោះហើយ ដាន នៅតែជាឧបករណ៍មើលឃើញចម្បង។ ដរាបណាស្ថានភាពនេះនៅតែបន្ត ការតាមដានដែលបានចែកចាយនឹង (ល្អបំផុត) យកកន្លែងទី 4 ជាឧបករណ៍បំបាត់កំហុស បន្ទាប់ពីម៉ែត្រ កំណត់ហេតុ និងដានជង់ ហើយអ្វីដែលអាក្រក់បំផុត វានឹងក្លាយទៅជាការខ្ជះខ្ជាយលុយ និងពេលវេលា។

បញ្ហាជាមួយ traceview

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

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

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

ទោះយ៉ាងណាក៏ដោយ traceview គឺ ឈ្មោះ នេះ។ បាទ / ចាស ប្រព័ន្ធតាមដានមួយចំនួនផ្តល់នូវការមើលដានដែលបានបង្ហាប់នៅពេលដែលចំនួននៃវិសាលភាពក្នុងដានមានទំហំធំដែលពួកវាមិនអាចបង្ហាញនៅក្នុងការមើលឃើញតែមួយ។ ទោះបីជាយ៉ាងណាក៏ដោយ ដោយសារតែចំនួនដ៏ច្រើននៃព័ត៌មានដែលមាន សូម្បីតែនៅក្នុងរូបភាពដែលមើលឃើញបែបនោះក៏ដោយ ក៏វិស្វករនៅតែមាន បង្ខំ "រុះរើ" វាដោយបង្រួមជម្រើសដោយដៃទៅជាសំណុំនៃសេវាកម្មដែលជាប្រភពនៃបញ្ហា។ ជាអកុសល នៅក្នុងវិស័យនេះ ម៉ាស៊ីនគឺលឿនជាងមនុស្ស មិនសូវងាយនឹងមានកំហុស ហើយលទ្ធផលរបស់ពួកគេគឺអាចធ្វើម្តងទៀតបាន។

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

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

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

វិសាលភាពមានកម្រិតទាបពេក

បញ្ហាជាមូលដ្ឋានជាមួយ traceview គឺថា វិសាលភាព គឺជាបុព្វហេតុកម្រិតទាបពេកសម្រាប់ទាំងការវិភាគភាពយឺតយ៉ាវ និងការវិភាគមូលហេតុឫសគល់។ វាដូចជាការញែកពាក្យបញ្ជារបស់ខួរក្បាលនីមួយៗ ដើម្បីព្យាយាមដោះស្រាយករណីលើកលែង ដោយដឹងថាមានឧបករណ៍កម្រិតខ្ពស់ជាច្រើនដូចជា backtrace ដែលងាយស្រួលជាងក្នុងការធ្វើការជាមួយ។

លើស​ពី​នេះ​ទៅ​ទៀត ខ្ញុំ​នឹង​ទទួល​យក​សេរីភាព​នៃ​ការ​អះអាង​ដូច​ខាង​ក្រោម៖ តាម​ឧត្ដមគតិ យើង​មិន​ត្រូវ​ការ​ទេ។ រូបភាពពេញ បានកើតឡើងក្នុងអំឡុងពេលវដ្តជីវិតសំណើ ដែលត្រូវបានតំណាងដោយឧបករណ៍តាមដានទំនើប។ ផ្ទុយទៅវិញ ទម្រង់នៃការអរូបីកម្រិតខ្ពស់មួយចំនួនត្រូវបានទាមទារដែលមានព័ត៌មានអំពីអ្វី ខុស (ស្រដៀងទៅនឹង backtrace) រួមជាមួយនឹងបរិបទមួយចំនួន។ ជំនួសឱ្យការមើលដានទាំងមូល ខ្ញុំចូលចិត្តមើលវា។ ជាផ្នែកមួយនៃដែលជាកន្លែងដែលមានអ្វីគួរឱ្យចាប់អារម្មណ៍ឬមិនធម្មតាកើតឡើង។ បច្ចុប្បន្ននេះ ការស្វែងរកត្រូវបានអនុវត្តដោយដៃ៖ វិស្វករទទួលបានដាន និងវិភាគដោយឯករាជ្យនូវវិសាលភាពក្នុងការស្វែងរកអ្វីមួយដែលគួរឱ្យចាប់អារម្មណ៍។ វិធីសាស្រ្តរបស់មនុស្សដែលសម្លឹងមើលវិសាលភាពក្នុងដាននីមួយៗដោយសង្ឃឹមថាអាចរកឃើញសកម្មភាពគួរឱ្យសង្ស័យមិនមានទំហំទាល់តែសោះ (ជាពិសេសនៅពេលដែលពួកគេត្រូវតែធ្វើឱ្យយល់អំពីទិន្នន័យមេតាទាំងអស់ដែលបានអ៊ិនកូដក្នុងវិសាលភាពផ្សេងៗគ្នាដូចជា លេខសម្គាល់វិសាលភាព ឈ្មោះវិធីសាស្ត្រ RPC រយៈពេលវិសាលភាព។ 'a, logs, tags ។ល។)។

ជម្មើសជំនួសសម្រាប់ traceview

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

ខ្ញុំមិនមែនជាអ្នករចនារូបភាព ឬអ្នកជំនាញ UX ទេ ប៉ុន្តែនៅក្នុងផ្នែកបន្ទាប់ ខ្ញុំចង់ចែករំលែកគំនិតមួយចំនួនអំពីអ្វីដែលការមើលឃើញទាំងនេះអាចមើលទៅដូចអ្វី។

ផ្តោតលើសេវាកម្មជាក់លាក់

នៅ​ពេល​ដែល​ឧស្សាហកម្ម​នេះ​កំពុង​បង្រួប​បង្រួម​គំនិត SLO (គោលបំណងកម្រិតសេវាកម្ម) និង SLI (សូចនាករកម្រិតសេវាកម្ម)វាហាក់បីដូចជាសមហេតុផលដែលក្រុមនីមួយៗគួរតែកំណត់អាទិភាពដើម្បីធានាថាសេវាកម្មរបស់ពួកគេត្រូវនឹងគោលដៅទាំងនេះ។ វាធ្វើតាមនោះ។ តម្រង់ទិសសេវាកម្ម ការមើលឃើញគឺសមបំផុតសម្រាប់ក្រុមបែបនេះ។

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

1. ដ្យាក្រាមចែកចាយភាពយឺតយ៉ាវសម្រាប់តែសំណើដែលលេចធ្លោខ្លាំងប៉ុណ្ណោះ។ (សំណើលើស);
2. ដ្យាក្រាមនៃការបែងចែកការពន្យាពេលសម្រាប់ករណីនៅពេលដែលគោលដៅសេវាកម្ម SLO មិនត្រូវបានសម្រេច។
3. ស្លាក "ទូទៅ", "គួរឱ្យចាប់អារម្មណ៍" និង "ចំលែក" បំផុតនៅក្នុងសំណួរដែលជាញឹកញាប់បំផុត។ ត្រូវបានធ្វើម្តងទៀត;
4. ការបំបែកភាពយឺតយ៉ាវសម្រាប់ករណីដែល ផ្កាយរណប សេវាកម្មមិនសម្រេចបាននូវគោលដៅ SLO របស់ពួកគេ;
5. ការបំបែកភាពយឺតយ៉ាវសម្រាប់សេវាកម្មចុះក្រោមផ្សេងៗ។

សំណួរទាំងនេះមួយចំនួនមិនត្រូវបានឆ្លើយដោយម៉ាទ្រីសដែលភ្ជាប់មកជាមួយទេ ដោយបង្ខំឱ្យអ្នកប្រើប្រាស់ពិនិត្យមើលវិសាលភាព។ ជាលទ្ធផល យើងមានយន្តការអរិភាពអ្នកប្រើប្រាស់យ៉ាងខ្លាំង។

នេះបង្កើតជាសំណួរ៖ ចុះទំនាក់ទំនងស្មុគ្រស្មាញរវាងសេវាកម្មចម្រុះដែលគ្រប់គ្រងដោយក្រុមផ្សេងៗគ្នា? មែនទេ? ដាន មិន​ត្រូវ​បាន​គេ​ចាត់​ទុក​ថា​ជា​ឧបករណ៍​ដ៏​ស័ក្តិសម​បំផុត​ដើម្បី​រំលេច​ស្ថានភាព​បែប​នេះ​ឬ?

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

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

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

ការកសាង topology

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

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

សូមលើកឧទាហរណ៍មួយ។ តោះស្រមៃមើលគេហទំព័រព័ត៌មានសម្មតិកម្ម។ សេវាកម្មទំព័រដើម (ទំព័រ​មុខ) ផ្លាស់ប្តូរទិន្នន័យជាមួយ Redis ជាមួយនឹងសេវាកម្មណែនាំ ជាមួយនឹងសេវាកម្មផ្សាយពាណិជ្ជកម្ម និងសេវាកម្មវីដេអូ។ សេវាកម្មវីដេអូយកវីដេអូពី S3 និងទិន្នន័យមេតាពី DynamoDB ។ សេវាកម្មណែនាំទទួលបានទិន្នន័យមេតាពី DynamoDB ផ្ទុកទិន្នន័យពី Redis និង MySQL និងសរសេរសារទៅ Kafka ។ សេវាកម្មផ្សាយពាណិជ្ជកម្មទទួលបានទិន្នន័យពី MySQL និងសរសេរសារទៅ Kafka ។

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

ដ្យាក្រាមសេវានៃគេហទំព័រព័ត៌មានសម្មតិកម្ម

ដ្យាក្រាមខាងក្រោមនឹងសមជាង។ មានបញ្ហាជាមួយសេវាកម្ម (វីដេអូ) បង្ហាញនៅកណ្តាល។ អ្នកប្រើប្រាស់កត់សម្គាល់វាភ្លាមៗ។ ពីការមើលឃើញនេះ វាច្បាស់ណាស់ថាសេវាកម្មវីដេអូកំពុងដំណើរការខុសប្រក្រតី ដោយសារការកើនឡើងនៃពេលវេលាឆ្លើយតប S3 ដែលប៉ះពាល់ដល់ល្បឿនផ្ទុកនៃផ្នែកនៃទំព័រមេ។

តូប៉ូឡូញថាមវន្តបង្ហាញតែសេវាកម្ម "គួរឱ្យចាប់អារម្មណ៍" ប៉ុណ្ណោះ។

topologies ដែលបង្កើតដោយថាមវន្តអាចមានប្រសិទ្ធភាពជាងផែនទីសេវាកម្មឋិតិវន្ត ជាពិសេសនៅក្នុងហេដ្ឋារចនាសម្ព័ន្ធដែលធ្វើមាត្រដ្ឋានដោយស្វ័យប្រវត្តិ។ សមត្ថភាពក្នុងការប្រៀបធៀប និងកម្រិតពណ៌នៃសេវាកម្ម topologies អនុញ្ញាតឱ្យអ្នកប្រើប្រាស់សួរសំណួរពាក់ព័ន្ធបន្ថែមទៀត។ សំណួរច្បាស់លាស់បន្ថែមទៀតអំពីប្រព័ន្ធទំនងជានាំឱ្យយល់កាន់តែច្បាស់អំពីរបៀបដែលប្រព័ន្ធដំណើរការ។

ការបង្ហាញប្រៀបធៀប

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

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

សេចក្តីសន្និដ្ឋាន

ខ្ញុំ​មិន​ចោទ​សួរ​ពី​ប្រយោជន៍​នៃ​ការ​តាមដាន​ខ្លួន​ឯង​ទេ។ ខ្ញុំជឿដោយស្មោះថាមិនមានវិធីសាស្រ្តផ្សេងទៀតសម្រាប់ការប្រមូលទិន្នន័យដែលសម្បូរបែប មូលហេតុ និងបរិបទដូចដែលមាននៅក្នុងដាននោះទេ។ ទោះយ៉ាងណាក៏ដោយ ខ្ញុំក៏ជឿថាដំណោះស្រាយតាមដានទាំងអស់ប្រើប្រាស់ទិន្នន័យនេះយ៉ាងអសមត្ថភាព។ ដរាបណាឧបករណ៍តាមដាននៅតែជាប់គាំងនៅលើការបង្ហាញ traceview ពួកគេនឹងត្រូវបានកំណត់ក្នុងសមត្ថភាពរបស់ពួកគេក្នុងការធ្វើឱ្យព័ត៌មានដ៏មានតម្លៃបំផុតដែលអាចទាញយកចេញពីទិន្នន័យដែលមាននៅក្នុងដាន។ លើសពីនេះ វាមានហានិភ័យនៃការអភិវឌ្ឍន៍បន្ថែមទៀតនូវចំណុចប្រទាក់ដែលមើលឃើញដែលមិនងាយស្រួល និងគ្មានការចាប់អារម្មណ៍ ដែលនឹងកម្រិតយ៉ាងខ្លាំងដល់សមត្ថភាពរបស់អ្នកប្រើប្រាស់ក្នុងការដោះស្រាយបញ្ហានៅក្នុងកម្មវិធី។

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

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

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

PS ពីអ្នកបកប្រែ

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

• «កម្មវិធីជំនួយ kubectl-debug សម្រាប់បំបាត់កំហុសនៅក្នុងផត Kubernetes»
• «Microservices៖ ទំហំមានសារៈសំខាន់ ទោះបីជាអ្នកមាន Kubernetes ក៏ដោយ។»
• «ការត្រួតពិនិត្យ និង Kubernetes (ការពិនិត្យឡើងវិញ និងរបាយការណ៍វីដេអូ)"។

ប្រភព: www.habr.com