VictoriaMetrics និងការត្រួតពិនិត្យពពកឯកជន។ Pavel Kolobaev

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

ឈ្មោះរបស់ខ្ញុំគឺ Kolobaev Pavel ។ DevOps, SRE, LeroyMerlin អ្វីគ្រប់យ៉ាងគឺដូចជាកូដ - វាទាំងអស់អំពីយើង៖ អំពីខ្ញុំ និងអំពីបុគ្គលិក LeroyMerlin ផ្សេងទៀត។

https://bit.ly/3jf1fIK

មានពពកផ្អែកលើ OpenStack ។ មានតំណភ្ជាប់តូចមួយទៅកាន់រ៉ាដាបច្ចេកទេស។

វាត្រូវបានបង្កើតឡើងនៅលើផ្នែករឹង Kubernetes ក៏ដូចជាលើសេវាកម្មដែលពាក់ព័ន្ធទាំងអស់សម្រាប់ OpenStack និងការកត់ត្រា។

នេះគឺជាគ្រោងការណ៍ដែលយើងមានក្នុងការអភិវឌ្ឍន៍។ នៅពេលដែលយើងកំពុងអភិវឌ្ឍទាំងអស់នេះ យើងមានប្រតិបត្តិករ Prometheus ដែលរក្សាទុកទិន្នន័យនៅក្នុងចង្កោម K8s ខ្លួនវាផ្ទាល់។ គាត់​រក​ឃើញ​ដោយ​ស្វ័យ​ប្រវត្តិ​នូវ​អ្វី​ដែល​ត្រូវ​បោស​សម្អាត ហើយ​ដាក់​វា​នៅ​ក្រោម​ជើង​របស់​គាត់ ដោយ​និយាយ​ប្រហែល។

យើងនឹងត្រូវផ្លាស់ទីទិន្នន័យទាំងអស់នៅខាងក្រៅចង្កោម Kubernetes ពីព្រោះប្រសិនបើមានអ្វីកើតឡើង យើងត្រូវយល់ពីអ្វី និងកន្លែងណា។

ដំណោះស្រាយទីមួយគឺថាយើងប្រើសហព័ន្ធនៅពេលដែលយើងមានភាគីទីបី Prometheus នៅពេលដែលយើងចូលទៅកាន់ចង្កោម Kubernetes តាមរយៈយន្តការសហព័ន្ធ។

ប៉ុន្តែមានបញ្ហាតូចតាចខ្លះនៅទីនេះ។ ក្នុងករណីរបស់យើង បញ្ហាបានចាប់ផ្តើមនៅពេលដែលយើងមាន 250 ម៉ែត្រ ហើយនៅពេលដែលមាន 000 ម៉ែត្រ យើងបានដឹងថាយើងមិនអាចធ្វើការដូចនោះទេ។ យើងបានបង្កើន scrape_timeout ដល់ 400 វិនាទី។

ហេតុ​អ្វី​បាន​ជា​យើង​ត្រូវ​ធ្វើ​បែប​នេះ? Prometheus ចាប់ផ្តើមរាប់ម៉ោងអស់ពីដើមរបង។ វាមិនសំខាន់ទេដែលទិន្នន័យនៅតែហូរ។ ប្រសិនបើក្នុងអំឡុងពេលដែលបានបញ្ជាក់នេះ ទិន្នន័យមិនត្រូវបានបញ្ចូលចូលគ្នាទេ ហើយវគ្គមិនត្រូវបានបិទតាមរយៈ http នោះវគ្គត្រូវបានចាត់ទុកថាបានបរាជ័យ ហើយទិន្នន័យមិនចូលទៅក្នុង Prometheus ខ្លួនឯងទេ។

អ្នកគ្រប់គ្នាស្គាល់ក្រាហ្វដែលយើងទទួលបាននៅពេលដែលទិន្នន័យមួយចំនួនត្រូវបានបាត់។ កាលវិភាគត្រូវបានរហែក ហើយយើងមិនសប្បាយចិត្តនឹងរឿងនេះទេ។

ជម្រើសបន្ទាប់គឺ sharding ដោយផ្អែកលើ Prometheus ពីរផ្សេងគ្នាតាមរយៈយន្តការសហព័ន្ធដូចគ្នា។

ជាឧទាហរណ៍ គ្រាន់តែយកពួកវាមកកាត់តាមឈ្មោះ។ វា​ក៏​អាច​ប្រើ​បាន​ដែរ ប៉ុន្តែ​យើង​បាន​សម្រេច​ចិត្ត​បន្ត។

ឥឡូវនេះយើងនឹងត្រូវដំណើរការបំណែកទាំងនេះតាមរបៀបណាមួយ។ អ្នកអាចយក promxy ដែលទៅតំបន់ shard និងគុណទិន្នន័យ។ វាដំណើរការជាមួយ shards ពីរជាចំណុចចូលតែមួយ។ នេះអាចត្រូវបានអនុវត្តតាមរយៈ promxy ប៉ុន្តែវានៅតែពិបាកពេក។

ជម្រើស​ទី​មួយ​គឺ​យើង​ចង់​បោះ​បង់​ចោល​យន្តការ​សហព័ន្ធ ព្រោះ​វា​យឺត​ណាស់។

អ្នកអភិវឌ្ឍន៍ Prometheus បាននិយាយយ៉ាងច្បាស់ថា "បុរសៗ ប្រើ TimescaleDB ផ្សេងគ្នា ពីព្រោះយើងនឹងមិនគាំទ្រការផ្ទុកម៉ែត្ររយៈពេលវែងនោះទេ។" នេះមិនមែនជាភារកិច្ចរបស់ពួកគេទេ។

យើងសរសេរលើក្រដាសមួយសន្លឹកដែលយើងនៅតែត្រូវដកខ្លួនចេញ ដើម្បីកុំឱ្យរក្សាទុកអ្វីៗទាំងអស់នៅកន្លែងតែមួយ។

គុណវិបត្តិទីពីរគឺការប្រើប្រាស់អង្គចងចាំ។ បាទ/ចាស ខ្ញុំយល់ថាមនុស្សជាច្រើននឹងនិយាយថានៅឆ្នាំ 2020 អង្គចងចាំពីរបីជីហ្គាបៃមានតម្លៃមួយកាក់ ប៉ុន្តែនៅតែមាន។

ឥឡូវនេះយើងមានបរិស្ថានអភិវឌ្ឍន៍ និងផលិតផល។ នៅក្នុង dev វាគឺប្រហែល 9 ជីហ្គាបៃសម្រាប់ 350 ម៉ែត្រ។ នៅក្នុងផលិតផលវាមាន 000 ជីហ្គាបៃនិងតូចជាង 14 ម៉ែត្រ។ ក្នុងពេលជាមួយគ្នានេះ ពេលវេលារក្សាទុករបស់យើងគឺត្រឹមតែ 780 នាទីប៉ុណ្ណោះ។ នេះ​ជា​រឿង​អាក្រក់។ ហើយឥឡូវនេះខ្ញុំនឹងពន្យល់ពីមូលហេតុ។

យើងធ្វើការគណនាមួយ ពោលគឺមួយលានកន្លះ ហើយយើងនៅជិតពួកគេរួចហើយ នៅដំណាក់កាលរចនា យើងទទួលបានអង្គចងចាំ 35-37 ជីហ្គាបៃ។ ប៉ុន្តែរួចទៅហើយ 4 លានម៉ែត្រត្រូវការអង្គចងចាំប្រហែល 90 ជីហ្គាបៃ។ នោះគឺវាត្រូវបានគណនាដោយប្រើរូបមន្តដែលផ្តល់ដោយអ្នកអភិវឌ្ឍន៍ Prometheus ។ យើងបានពិនិត្យមើលការជាប់ទាក់ទងគ្នា ហើយដឹងថាយើងមិនចង់ចំណាយប្រាក់ពីរបីលានសម្រាប់ម៉ាស៊ីនមេសម្រាប់តែការត្រួតពិនិត្យ។

យើងនឹងមិនត្រឹមតែបង្កើនចំនួនម៉ាស៊ីនប៉ុណ្ណោះទេ យើងក៏កំពុងត្រួតពិនិត្យម៉ាស៊ីននិម្មិតខ្លួនឯងផងដែរ។ ដូច្នេះ ម៉ាស៊ីននិម្មិតកាន់តែច្រើន មាត្រដ្ឋានច្រើនប្រភេទផ្សេងៗ។ល។ យើងនឹងមានការរីកលូតលាស់ពិសេសនៃចង្កោមរបស់យើងទាក់ទងនឹងម៉ែត្រ។

ជាមួយនឹងទំហំថាស មិនមែនអ្វីៗទាំងអស់សុទ្ធតែអាក្រក់នៅទីនេះទេ ប៉ុន្តែខ្ញុំចង់កែលម្អវា។ យើងបានទទួលចំនួនសរុប 15 ជីហ្គាបៃក្នុងរយៈពេល 120 ថ្ងៃដែលក្នុងនោះ 100 ត្រូវបានបង្ហាប់ទិន្នន័យ 20 គឺជាទិន្នន័យដែលមិនបានបង្ហាប់ ប៉ុន្តែយើងតែងតែចង់បានតិច។

ដូច្នោះហើយ យើងសរសេរចំណុចមួយបន្ថែមទៀត - នេះគឺជាការប្រើប្រាស់ធនធានច្រើន ដែលយើងនៅតែចង់រក្សាទុក ព្រោះយើងមិនចង់ឱ្យចង្កោមត្រួតពិនិត្យរបស់យើងប្រើប្រាស់ធនធានច្រើនជាងចង្កោមរបស់យើង ដែលគ្រប់គ្រង OpenStack ។

មានគុណវិបត្តិមួយទៀតនៃ Prometheus ដែលយើងបានរកឃើញសម្រាប់ខ្លួនយើង នេះយ៉ាងហោចណាស់ប្រភេទនៃការកំណត់ការចងចាំមួយចំនួន។ ជាមួយនឹង Prometheus អ្វីៗគឺកាន់តែអាក្រក់នៅទីនេះ ព្រោះវាមិនមានការប្រែប្រួលបែបនេះទាល់តែសោះ។ ការប្រើដែនកំណត់ក្នុង docker ក៏មិនមែនជាជម្រើសដែរ។ ប្រសិនបើភ្លាមៗ RAF របស់អ្នកបានធ្លាក់ចុះ ហើយមាន 20-30 ជីហ្គាបៃ នោះវានឹងចំណាយពេលយូរដើម្បីកើនឡើង។

នេះជាហេតុផលមួយទៀតដែល Prometheus មិនស័ក្តិសមសម្រាប់យើង ពោលគឺយើងមិនអាចកំណត់ការប្រើប្រាស់អង្គចងចាំបានទេ។

វានឹងអាចកើតឡើងជាមួយនឹងគ្រោងការណ៍បែបនេះ។ យើងត្រូវការគ្រោងការណ៍នេះ ដើម្បីរៀបចំចង្កោម HA ។ យើង​ចង់​ឱ្យ​ម៉ែត្រ​របស់​យើង​អាច​ប្រើ​បាន​គ្រប់​ពេល និង​គ្រប់​ទីកន្លែង ទោះ​ជា​ម៉ាស៊ីន​មេ​ដែល​រក្សា​ទុក​ម៉ែត្រ​ទាំងនេះ​គាំង​ក៏​ដោយ។ ដូច្នេះហើយ យើងនឹងត្រូវបង្កើតគ្រោងការណ៍បែបនេះ។

គ្រោងការណ៍នេះនិយាយថាយើងនឹងមានការចម្លងនៃ shards ហើយតាមនោះ ការចម្លងនៃការចំណាយនៃធនធានប្រើប្រាស់។ វាអាចត្រូវបានធ្វើមាត្រដ្ឋានស្ទើរតែផ្ដេក ប៉ុន្តែយ៉ាងណាក៏ដោយ ការប្រើប្រាស់ធនធាននឹងទៅជានរក។

គុណវិបត្តិតាមលំដាប់លំដោយក្នុងទម្រង់ដែលយើងសរសេរវាចុះសម្រាប់ខ្លួនយើង៖

• តម្រូវ​ឱ្យ​មាន​ការ​ផ្ទុក​ឡើង​ម៉ែត្រ​ពី​ខាង​ក្រៅ។
• ការប្រើប្រាស់ធនធានខ្ពស់។
• មិនមានវិធីកំណត់ការប្រើប្រាស់អង្គចងចាំទេ។
• ការអនុវត្តស្មុគស្មាញ និងពឹងផ្អែកលើធនធាននៃ HA ។

សម្រាប់ខ្លួនយើង យើងបានសម្រេចចិត្តថាយើងកំពុងចាកចេញពី Prometheus ជាកន្លែងផ្ទុក។

យើងបានកំណត់តម្រូវការបន្ថែមសម្រាប់ខ្លួនយើងដែលយើងត្រូវការ។ នេះ៖

• នេះគឺជាការគាំទ្រ promql ពីព្រោះរឿងជាច្រើនត្រូវបានសរសេររួចហើយសម្រាប់ Prometheus: សំណួរ ការជូនដំណឹង។
• ហើយបន្ទាប់មកយើងមាន Grafana ដែលត្រូវបានសរសេររួចហើយតាមរបៀបដូចគ្នាសម្រាប់ Prometheus ជាផ្នែកខាងក្រោយ។ ខ្ញុំមិនចង់សរសេរផ្ទាំងគ្រប់គ្រងឡើងវិញទេ។
• យើងចង់បង្កើតស្ថាបត្យកម្ម HA ធម្មតា។
• យើងចង់កាត់បន្ថយការប្រើប្រាស់ធនធានណាមួយ។
• មាន nuance តូចមួយផ្សេងទៀត។ យើងមិនអាចប្រើប្រភេទផ្សេងៗនៃប្រព័ន្ធប្រមូលម៉ែត្រពពកបានទេ។ យើង​មិន​ទាន់​ដឹង​ថា​អ្វី​នឹង​ធ្លាក់​ចុះ​ក្នុង​ការ​វាស់វែង​នេះ​នៅ​ឡើយ​ទេ។ ហើយ​ដោយសារ​អ្វី​ៗ​អាច​ហោះហើរ​ទៅ​ទីនោះ​បាន យើង​ត្រូវ​ដាក់​កម្រិត​ខ្លួន​យើង​ក្នុង​ការ​ដាក់​ក្នុងស្រុក​។

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

ហេតុអ្វី? ដោយសារតែ៖

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

ចូរយើងធ្វើការប្រៀបធៀបដំបូង។ យើងយក Prometheus ដូចគ្នានៅខាងក្នុងចង្កោម ខាងក្រៅ Prometheus ទៅវា។ បន្ថែមតាមរយៈ remoteWrite VictoriaMetrics ។

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

ក្នុងករណីរបស់យើង ការប្រើប្រាស់អង្គចងចាំរបស់ Prometheus ដែលមានទីតាំងនៅក្នុងចង្កោម Kubernetes មិនបានកើនឡើងគួរឱ្យកត់សម្គាល់នោះទេ។

យើងប្រៀបធៀបប្រភពទិន្នន័យពីរនៃទិន្នន័យដូចគ្នា។ នៅក្នុង Prometheus យើងឃើញទិន្នន័យដែលបាត់ដូចគ្នា។ អ្វីគ្រប់យ៉ាងគឺល្អនៅ VictoriaMetrics ។

លទ្ធផលតេស្តទំហំថាស។ យើងនៅ Prometheus ទទួលបាន 120 ជីហ្គាបៃសរុប។ នៅ VictoriaMetrics យើងទទួលបាន 4 ជីហ្គាបៃក្នុងមួយថ្ងៃរួចហើយ។ មានយន្តការខុសគ្នាបន្តិចបន្តួចជាងអ្វីដែលយើងធ្លាប់ឃើញនៅ Prometheus ។ នោះ​គឺ​ទិន្នន័យ​ត្រូវ​បាន​បង្ហាប់​យ៉ាង​ល្អ​ក្នុង​មួយ​ថ្ងៃ​ក្នុង​រយៈពេល​កន្លះ​ម៉ោង។ ពួកវាត្រូវបានប្រមូលផលបានយ៉ាងល្អក្នុងរយៈពេលមួយថ្ងៃ ក្នុងរយៈពេលកន្លះម៉ោង បើទោះបីជាទិន្នន័យនឹងនៅតែបាត់បង់នៅពេលក្រោយក៏ដោយ។ ជាលទ្ធផលយើងបានសន្សំលើទំហំថាស។

យើងក៏សន្សំសំចៃលើការប្រើប្រាស់ធនធានអង្គចងចាំផងដែរ។ នៅពេលធ្វើតេស្ត យើងមាន Prometheus ដាក់ពង្រាយនៅលើម៉ាស៊ីននិម្មិត - 8 cores, 24 gigabyte ។ Prometheus បរិភោគស្ទើរតែទាំងអស់។ គាត់បានដួលលើ OOM Killer ។ ក្នុងពេលជាមួយគ្នានេះដែរមានតែ 900 រង្វាស់សកម្មប៉ុណ្ណោះដែលត្រូវបានចាក់ចូលទៅក្នុងវា។ នេះគឺប្រហែល 000-25 ម៉ែត្រក្នុងមួយវិនាទី។

យើងបានដំណើរការ VictoriaMetrics នៅលើម៉ាស៊ីននិម្មិត dual-core ដែលមាន RAM 8 ជីហ្គាបៃ។ យើងបានគ្រប់គ្រងដើម្បីអោយ VictoriaMetrics ដំណើរការបានល្អដោយដើរលេងជាមួយរបស់មួយចំនួននៅលើម៉ាស៊ីនទំហំ 8GB ។ នៅទីបញ្ចប់យើងរក្សាវាដល់ 7 ជីហ្គាបៃ។ ក្នុងពេលជាមួយគ្នានេះ ល្បឿននៃការចែកចាយខ្លឹមសារ ពោលគឺម៉ែត្រគឺខ្ពស់ជាង Prometheus ទៅទៀត។

ស៊ីភីយូបានក្លាយទៅជាប្រសើរជាងបើប្រៀបធៀបទៅនឹង Prometheus ។ នៅទីនេះ Prometheus ប្រើប្រាស់ 2,5 cores ហើយ VictoriaMetrics ប្រើប្រាស់តែ 0,25 cores ប៉ុណ្ណោះ។ នៅពេលចាប់ផ្តើម - 0,5 ស្នូល។ នៅពេលដែលវាបញ្ចូលគ្នា វាឈានដល់ស្នូលតែមួយ ប៉ុន្តែនេះគឺកម្រខ្លាំងណាស់។

ក្នុងករណីរបស់យើង ជម្រើសបានធ្លាក់លើ VictoriaMetrics សម្រាប់ហេតុផលជាក់ស្តែង យើងចង់សន្សំប្រាក់ ហើយយើងធ្វើ។

សូមឆ្លងកាត់ចំណុចពីរភ្លាមៗ - ការផ្ទុកឡើងនៃម៉ែត្រ និងការប្រើប្រាស់ធនធានខ្ពស់។ ហើយ​យើង​ត្រូវ​តែ​សម្រេច​ចិត្ត​ពីរ​ចំណុច​ដែល​យើង​នៅ​សល់​សម្រាប់​ខ្លួន​យើង។

នៅទីនេះខ្ញុំនឹងធ្វើការកក់ទុកភ្លាមៗ យើងចាត់ទុក VictoriaMetrics ជាកន្លែងផ្ទុកម៉ែត្រ។ ប៉ុន្តែដោយសារយើងទំនងជានឹងផ្តល់ VictoriaMetrics ជាកន្លែងផ្ទុកសម្រាប់ Leroy ទាំងអស់ យើងត្រូវកំណត់អ្នកដែលនឹងប្រើប្រាស់ចង្កោមនេះ ដើម្បីកុំឱ្យពួកគេផ្តល់ឱ្យយើង។

មានប៉ារ៉ាម៉ែត្រដ៏អស្ចារ្យដែលអនុញ្ញាតឱ្យអ្នកកំណត់តាមពេលវេលាដោយបរិមាណទិន្នន័យនិងតាមពេលវេលាប្រតិបត្តិ។

វាក៏មានជម្រើសដ៏ល្អមួយដែលអនុញ្ញាតឱ្យយើងកំណត់ការប្រើប្រាស់អង្គចងចាំ ដោយហេតុនេះយើងអាចរកឃើញតុល្យភាពដែលនឹងអនុញ្ញាតឱ្យយើងទទួលបានល្បឿនប្រតិបត្តិការធម្មតា និងការប្រើប្រាស់ធនធានគ្រប់គ្រាន់។

ដកចំណុចមួយបន្ថែមទៀត ពោលគឺ ឆ្លងកាត់ចំណុច - អ្នកមិនអាចកំណត់ការប្រើប្រាស់អង្គចងចាំបានទេ។

ក្នុង​ការ​ធ្វើ​ឡើង​វិញ​ជា​លើក​ដំបូង យើង​បាន​សាកល្បង VictoriaMetrics Single Node។ បន្ទាប់យើងបន្តទៅ VictoriaMetrics Cluster Version ។

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

សមាសធាតុសំខាន់នៃ VictoriaMetrics Cluster Version គឺ vmstsorage ។ វាអាចមានចំនួន N នៃពួកគេ។ ក្នុងករណីរបស់យើងមាន 2 ក្នុងចំណោមពួកគេរហូតមកដល់ពេលនេះ។

ហើយមាន vminsert ។ នេះគឺជាម៉ាស៊ីនមេប្រូកស៊ីដែលអនុញ្ញាតឱ្យយើង៖ រៀបចំការបែងចែករវាងការផ្ទុកទាំងអស់ដែលយើងបានប្រាប់វា ហើយវាក៏អនុញ្ញាតឱ្យមានការចម្លងផងដែរ ពោលគឺអ្នកនឹងមានទាំង sharding និងចម្លង។

Vminsert គាំទ្រ OpenTSDB, Graphite, InfluxDB និង remoteWrite protocols ពី Prometheus ។

មាន vmselect ផងដែរ។ ភារកិច្ចចម្បងរបស់វាគឺដើម្បីចូលទៅកាន់ vmstorage ទទួលទិន្នន័យពីពួកគេ ចម្លងទិន្នន័យនេះ ហើយផ្តល់ឱ្យវាទៅអតិថិជន។

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

សេវាកម្មដ៏អស្ចារ្យមួយទៀតគឺ vmalert ដែលអនុញ្ញាតឱ្យអ្នកប្រើ VictoriaMetrics ជាកម្មវិធីខាងក្រោយ ទទួលទិន្នន័យដែលបានដំណើរការពី vminsert ហើយផ្ញើវាទៅ vmselect ។ វាដំណើរការការជូនដំណឹងដោយខ្លួនឯង ក៏ដូចជាច្បាប់ផងដែរ។ ក្នុងករណីមានការជូនដំណឹង យើងទទួលបានការជូនដំណឹងតាមរយៈ alertmanager ។

មានសមាសធាតុ wmauth ។ យើងអាចឬមិនអាច (យើងមិនទាន់សម្រេចចិត្តលើវានៅឡើយទេ) ប្រើវាជាប្រព័ន្ធអនុញ្ញាតសម្រាប់កំណែពហុជួលនៃចង្កោម។ វាគាំទ្រ remoteWrite សម្រាប់ Prometheus ហើយអាចអនុញ្ញាតដោយផ្អែកលើ url ឬជាផ្នែកទីពីររបស់វា ដែលអ្នកអាច ឬមិនអាចសរសេរបាន។

ក៏មាន vmbackup, vmrestore ផងដែរ។ នេះ​ជា​ខ្លឹមសារ​នៃ​ការ​ស្ដារ​និង​ការ​បម្រុង​ទុក​ទិន្នន័យ​ទាំង​អស់។ អាចធ្វើ S3, GCS, ឯកសារ។

ការ​ធ្វើ​ឡើងវិញ​ជា​លើក​ដំបូង​នៃ​ចង្កោម​របស់​យើង​ត្រូវ​បាន​ធ្វើ​ឡើង​អំឡុង​ពេល​ដាក់​ឱ្យ​នៅ​ដាច់​ដោយ​ឡែក។ នៅពេលនោះ មិនមានការចម្លងទេ ដូច្នេះការសរសេរឡើងវិញរបស់យើងមានចង្កោមពីរផ្សេងគ្នា និងឯករាជ្យ ដែលយើងបានទទួលទិន្នន័យតាមរយៈ remoteWrite ។

នៅទីនេះខ្ញុំនឹងធ្វើការកក់ទុកដែលនៅពេលដែលយើងប្តូរពី VictoriaMetrics Single Node ទៅ VictoriaMetrics Cluster Version យើងនៅតែរក្សាធនធានប្រើប្រាស់ដដែល ពោលគឺសំខាន់គឺអង្គចងចាំ។ នេះជារបៀបដែលទិន្នន័យរបស់យើង ពោលគឺការប្រើប្រាស់ធនធានត្រូវបានចែកចាយ។

ការចម្លងត្រូវបានបន្ថែមនៅទីនេះរួចហើយ។ យើង​បាន​រួម​បញ្ចូល​ទាំង​អស់​នេះ​ជា​ចង្កោម​ធំ​មួយ​។ ទិន្នន័យរបស់យើងទាំងអស់ត្រូវបានបំបែក និងចម្លង។

ចង្កោមទាំងមូលមានចំណុចចូល N មានន័យថា Prometheus អាចបន្ថែមទិន្នន័យតាមរយៈ HAPROXY ។ នៅទីនេះយើងមានចំណុចចូលនេះ។ ហើយតាមរយៈចំណុចចូលនេះ អ្នកអាចចូលពី Grafana ។

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

យើង​មាន​ការ​ជូន​ដំណឹង។ យើងប្រើវា។ យើងប្រើ alertmanager ពី Prometheus ។ យើងប្រើ Opsgenie និង Telegram ជាបណ្តាញចែកចាយការជូនដំណឹង។ នៅក្នុង Telegram ពួកគេចាក់ចេញពី dev ប្រហែលជាអ្វីមួយពីផលិតផល ប៉ុន្តែភាគច្រើនជាអ្វីដែលជាស្ថិតិដែលត្រូវការដោយវិស្វករ។ ហើយ Opsgenie គឺសំខាន់។ ទាំងនេះគឺជាការហៅ, ការគ្រប់គ្រងឧប្បត្តិហេតុ។

សំណួរអស់កល្បជានិច្ច៖ "តើនរណាជាអ្នកឃ្លាំមើលការត្រួតពិនិត្យ?" ក្នុងករណីរបស់យើង ការត្រួតពិនិត្យ ម៉ូនីទ័រ ត្រួតពិនិត្យដោយខ្លួនឯង ពីព្រោះយើងប្រើ vmagent នៅលើថ្នាំងនីមួយៗ។ ហើយចាប់តាំងពីថ្នាំងរបស់យើងត្រូវបានចែកចាយនៅទូទាំងមជ្ឈមណ្ឌលទិន្នន័យផ្សេងៗគ្នានៃអ្នកផ្តល់សេវាដូចគ្នា មជ្ឈមណ្ឌលទិន្នន័យនីមួយៗមានឆានែលផ្ទាល់ខ្លួន ពួកវាឯករាជ្យ ហើយទោះបីជាខួរក្បាលបំបែកមកដល់ក៏ដោយ យើងនឹងនៅតែទទួលបានការជូនដំណឹង។ បាទ/ចាស វានឹងមានច្រើនជាងនេះ ប៉ុន្តែវាជាការប្រសើរក្នុងការទទួលបានការជូនដំណឹងច្រើនជាងគ្មាន។

យើងបញ្ចប់បញ្ជីរបស់យើងជាមួយនឹងការអនុវត្ត HA ។

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

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

ការឈឺចាប់ចម្បងសម្រាប់ខ្ញុំអំឡុងពេលធ្វើម្តងទៀតគឺថាប្រសិនបើខ្ញុំបិទថ្នាំង នោះសម្រាប់រយៈពេល 30 វិនាទីដំបូង vminsert មិនអាចយល់ថាមិនមានកម្មវិធីខាងក្រោយទេ។ ឥឡូវ​នេះ​ត្រូវ​បាន​សម្រេច​ហើយ។ ហើយតាមព្យញ្ជនៈក្នុងមួយ ឬពីរវិនាទី ទិន្នន័យត្រូវបានយកចេញពីថ្នាំងដែលនៅសល់ទាំងអស់ ហើយសំណើឈប់រង់ចាំថ្នាំងដែលបាត់នោះ។

នៅចំណុចខ្លះយើងចង់ឱ្យ VictoriaMetrics ក្លាយជាប្រតិបត្តិករ VictoriaMetrics ។ យើងបានរង់ចាំគាត់។ ឥឡូវនេះយើងកំពុងបង្កើតយ៉ាងសកម្មនូវក្របខណ្ឌសម្រាប់ប្រតិបត្តិករ VictoriaMetrics ដើម្បីទទួលយកច្បាប់គណនាជាមុនទាំងអស់។

មានសំណើដើម្បីកែលម្អការអនុវត្តចង្កោម។ ខ្ញុំបានគូសបញ្ជាក់ពួកគេខាងលើ។

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

• យើងធ្លាប់ស្គាល់ការឈឺចាប់ ដូចមិត្តរួមការងារខ្លះដែរ ពេលប្រើ Prometheus។
• យើងជ្រើសរើស VictoriaMetrics សម្រាប់ខ្លួនយើង។
• វាធ្វើមាត្រដ្ឋានបានយ៉ាងល្អទាំងបញ្ឈរ និងផ្ដេក។
• យើង​អាច​ចែកចាយ​សមាសភាគ​ផ្សេងៗ​ទៅ​លេខ​ផ្សេង​គ្នា​នៃ​ថ្នាំង​ក្នុង​ចង្កោម កំណត់​ពួកវា​ដោយ​អង្គចងចាំ បន្ថែម​អង្គចងចាំ​ជាដើម។

យើងនឹងប្រើ VictoriaMetrics នៅផ្ទះ ព្រោះយើងពិតជាចូលចិត្តវា។ នេះគឺជាអ្វីដែលបានក្លាយទៅជា។

https://t.me/VictoriaMetrics_ru1

លេខកូដ QR ពីរបីសម្រាប់ការជជែក VictoriaMetrics ទំនាក់ទំនងរបស់ខ្ញុំ រ៉ាដាបច្ចេកទេស LeroyMerlin ។

ប្រភព: www.habr.com