របៀបដែលអាទិភាពរបស់ pod នៅក្នុង Kubernetes បណ្តាលឱ្យមានការខកខាននៅ Grafana Labs

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

នៅថ្ងៃសុក្រ ទី 19 ខែកក្កដា សេវាកម្ម Hosted Prometheus នៅក្នុង Grafana Cloud បានឈប់ដំណើរការប្រហែល 30 នាទី។ ខ្ញុំសូមអភ័យទោសដល់អតិថិជនទាំងអស់ដែលរងផលប៉ះពាល់ដោយការដាច់ភ្លើង។ ការងាររបស់យើងគឺផ្តល់ឧបករណ៍ត្រួតពិនិត្យដែលអ្នកត្រូវការ ហើយយើងយល់ថាការមិនមានឧបករណ៍ទាំងនោះអាចធ្វើឲ្យជីវិតរបស់អ្នកកាន់តែលំបាក។ យើង​ចាត់​ទុក​ហេតុការណ៍​នេះ​យ៉ាង​ធ្ងន់ធ្ងរ។ កំណត់សម្គាល់នេះពន្យល់ពីអ្វីដែលបានកើតឡើង របៀបដែលយើងឆ្លើយតប និងអ្វីដែលយើងកំពុងធ្វើ ដើម្បីធានាថាវាមិនកើតឡើងម្តងទៀត។

សម័យបុរេប្រវត្តិសាស្ត្រ

សេវាកម្ម Grafana Cloud Hosted Prometheus គឺផ្អែកលើ Cortex - គម្រោង CNCF ដើម្បីបង្កើតសេវាកម្ម Prometheus ដែលមានអ្នកជួលច្រើន ដែលអាចធ្វើមាត្រដ្ឋានផ្តេក។ ស្ថាបត្យកម្ម Cortex មានសំណុំនៃសេវាកម្មមីក្រូនីមួយៗ ដែលនីមួយៗដំណើរការមុខងារផ្ទាល់ខ្លួនរបស់វា៖ ការចម្លង ការផ្ទុក សំណួរ។ល។ Cortex ស្ថិតក្រោមការអភិវឌ្ឍន៍យ៉ាងសកម្ម ហើយកំពុងបន្ថែមមុខងារថ្មីៗ និងកែលម្អការអនុវត្តជាបន្តបន្ទាប់។ យើងដាក់ពង្រាយការចេញផ្សាយ Cortex ថ្មីជាទៀងទាត់ទៅក្រុមដើម្បីឱ្យអតិថិជនអាចទាញយកអត្ថប្រយោជន៍ពីលក្ខណៈពិសេសទាំងនេះ - ជាសំណាងល្អ Cortex អាចត្រូវបានអាប់ដេតដោយគ្មានពេលវេលារងចាំ។

សម្រាប់ការអាប់ដេតដោយគ្មានថ្នេរ សេវាកម្ម Ingester Cortex ទាមទារការចម្លង Ingester បន្ថែមក្នុងអំឡុងពេលដំណើរការអាប់ដេត។ (ចំណាំ។ បកប្រែ: អ៊ីនស្ទ័រ - សមាសធាតុមូលដ្ឋាននៃ Cortex ។ ការងាររបស់វាគឺដើម្បីប្រមូលសំណាកជាបន្តបន្ទាប់ ដាក់ជាក្រុមចូលទៅក្នុងកំណាត់ Prometheus ហើយរក្សាទុកវានៅក្នុងមូលដ្ឋានទិន្នន័យដូចជា DynamoDB, BigTable ឬ Cassandra ។ ) នេះអនុញ្ញាតឱ្យ Ingesters ចាស់បញ្ជូនទិន្នន័យបច្ចុប្បន្នទៅ Ingesters ថ្មី។ គួរកត់សម្គាល់ថា Ingesters គឺជាតម្រូវការធនធាន។ ដើម្បីឱ្យពួកវាដំណើរការ អ្នកត្រូវមាន 4 cores និង 15 GB នៃអង្គចងចាំក្នុងមួយ pod ពោលគឺឧ។ 25% នៃថាមពលដំណើរការ និងអង្គចងចាំរបស់ម៉ាស៊ីនមូលដ្ឋាននៅក្នុងករណីនៃចង្កោម Kubernetes របស់យើង។ ជាទូទៅ ជាធម្មតាយើងមានធនធានដែលមិនប្រើប្រាស់ច្រើននៅក្នុងចង្កោមជាង 4 cores និង 15 GB នៃអង្គចងចាំ ដូច្នេះយើងអាចបង្កើនការបញ្ចូលបន្ថែមទាំងនេះបានយ៉ាងងាយស្រួលអំឡុងពេលធ្វើបច្ចុប្បន្នភាព។

ទោះយ៉ាងណាក៏ដោយ ជារឿយៗវាកើតមានឡើងថា ក្នុងអំឡុងពេលប្រតិបត្តិការធម្មតា គ្មានម៉ាស៊ីនណាមាន 25% នៃធនធានដែលមិនប្រើនោះទេ។ បាទ/ចាស យើង​មិន​ខំ​ទេ៖ ស៊ីភីយូ និង​អង្គចងចាំ​នឹង​តែងតែ​មាន​ប្រយោជន៍​សម្រាប់​ដំណើរការ​ផ្សេងៗ។ ដើម្បីដោះស្រាយបញ្ហានេះ យើងបានសម្រេចចិត្តប្រើ Kubernetes Pod អាទិភាព. គំនិតនេះគឺផ្តល់ឱ្យ Ingesters នូវអាទិភាពខ្ពស់ជាងសេវាកម្មមីក្រូ (គ្មានរដ្ឋ) ផ្សេងទៀត។ នៅពេលដែលយើងត្រូវការដំណើរការ Ingester បន្ថែម (N+1) នោះ យើងផ្លាស់ប្តូរទីតាំងតូចៗផ្សេងទៀតជាបណ្ដោះអាសន្ន។ ផតទាំងនេះត្រូវបានផ្ទេរទៅធនធានដោយឥតគិតថ្លៃនៅលើម៉ាស៊ីនផ្សេងទៀត ដោយបន្សល់ទុក "រន្ធ" ធំល្មមដើម្បីដំណើរការ Ingester បន្ថែម។

នៅថ្ងៃព្រហស្បតិ៍ ទី 18 ខែកក្កដា យើងបានដាក់ចេញកម្រិតអាទិភាពថ្មីចំនួន XNUMX ដល់ក្រុមរបស់យើង៖ សំខាន់, ខ្ពស់, មធ្យម и ទាប. ពួកគេត្រូវបានសាកល្បងនៅលើចង្កោមខាងក្នុងដោយគ្មានចរាចរណ៍អតិថិជនប្រហែលមួយសប្តាហ៍។ តាមលំនាំដើម ផតឃែរដោយគ្មានអាទិភាពជាក់លាក់ដែលបានទទួល មធ្យម អាទិភាព ថ្នាក់ត្រូវបានកំណត់សម្រាប់ Ingesters ជាមួយ ខ្ពស់។ អាទិភាព។ រិះគន់ ត្រូវបានបម្រុងទុកសម្រាប់ការត្រួតពិនិត្យ (Prometheus, Alertmanager, node-exporter, kube-state-metrics ជាដើម)។ ការកំណត់របស់យើងគឺបើកចំហ ហើយអ្នកអាចមើល PR នៅទីនេះ.

គ្រោះថ្នាក់

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

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

ReplicaSet សម្រាប់ Ingester ដែលត្រូវបានបណ្តេញចេញនៅក្នុងចង្កោមផលិតកម្មបានរកឃើញ pod ដែលត្រូវបានបណ្តេញចេញ ហើយបានបង្កើតថ្មីមួយដើម្បីរក្សាចំនួនច្បាប់ចម្លងដែលបានបញ្ជាក់។ ផតថ្មីត្រូវបានកំណត់តាមលំនាំដើម មធ្យម អាទិភាព ហើយ Ingester "ចាស់" ផ្សេងទៀតនៅក្នុងផលិតកម្មបានបាត់បង់ធនធានរបស់វា។ លទ្ធផលគឺ ដំណើរការ avalancheដែលនាំទៅដល់ការផ្លាស់ទីលំនៅរបស់ផតទាំងអស់ពី Ingester សម្រាប់ចង្កោមផលិតកម្ម Cortex ។

Ingesters មានលក្ខណៈរដ្ឋ និងរក្សាទុកទិន្នន័យសម្រាប់រយៈពេល 12 ម៉ោងមុន។ នេះអនុញ្ញាតឱ្យយើងបង្រួមពួកវាឱ្យកាន់តែមានប្រសិទ្ធភាព មុនពេលសរសេរពួកវាទៅកន្លែងផ្ទុករយៈពេលវែង។ ដើម្បីសម្រេចបាននូវចំណុចនេះ Cortex បំបែកទិន្នន័យតាមស៊េរីដោយប្រើ Distributed Hash Table (DHT) ហើយចម្លងស៊េរីនីមួយៗឆ្លងកាត់ XNUMX Ingesters ដោយប្រើភាពស៊ីសង្វាក់នៃកូរ៉ុមរចនាប័ទ្មឌីណាម៉ូ។ Cortex មិនសរសេរទិន្នន័យទៅ Ingesters ដែលត្រូវបានបិទ។ ដូច្នេះនៅពេលដែល Ingesters មួយចំនួនធំចាកចេញពី DHT Cortex មិនអាចផ្តល់នូវការចម្លងគ្រប់គ្រាន់នៃធាតុទេ ហើយពួកវាគាំង។

ការរកឃើញ និងការដោះស្រាយ

ការជូនដំណឹង Prometheus ថ្មីដោយផ្អែកលើ "ថវិកាកំហុស" (កំហុស-ថវិកាផ្អែកលើ — ព័ត៌មានលម្អិតនឹងបង្ហាញនៅក្នុងអត្ថបទនាពេលអនាគត) បានចាប់ផ្តើមបន្លឺសំឡេងរោទិ៍ 4 នាទីបន្ទាប់ពីការចាប់ផ្តើមនៃការបិទ។ ក្នុងរយៈពេល XNUMX នាទីបន្ទាប់ យើងបានដំណើរការការវិនិច្ឆ័យមួយចំនួន និងពង្រីកក្រុម Kubernetes មូលដ្ឋាន ដើម្បីរៀបចំទាំងក្រុមផលិតកម្មថ្មី និងដែលមានស្រាប់។

បន្ទាប់ពីប្រាំនាទីផ្សេងទៀត Ingesters ចាស់បានសរសេរទិន្នន័យរបស់ពួកគេដោយជោគជ័យ ទិន្នន័យថ្មីបានចាប់ផ្តើមឡើង ហើយចង្កោម Cortex អាចប្រើបានម្តងទៀត។

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

ផលវិបាក

ការឈប់សម្រាកសរុបគឺ 26 នាទី។ គ្មានទិន្នន័យត្រូវបានបាត់បង់ទេ។ Ingesters បានផ្ទុកទិន្នន័យក្នុងអង្គចងចាំទាំងអស់ដោយជោគជ័យទៅក្នុងការផ្ទុករយៈពេលវែង។ កំឡុងពេលបិទម៉ាស៊ីនភ្ញៀវ Prometheus servers buffer ត្រូវបានលុប (ពីចម្ងាយ) ការថតដោយប្រើ API remote_write ថ្មី។ ផ្អែកលើ WAL (អ្នកនិពន្ធ Callum Styan ពី Grafana Labs) ហើយសរសេរឡើងវិញនូវការបរាជ័យបន្ទាប់ពីការគាំង។

ប្រតិបត្តិការសរសេរចង្កោមផលិតកម្ម

ការរកឃើញ

វាមានសារៈសំខាន់ណាស់ក្នុងការរៀនពីឧប្បត្តិហេតុនេះហើយចាត់វិធានការចាំបាច់ដើម្បីជៀសវាងការកើតឡើងវិញ។

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

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

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

ការបរាជ័យក៏មានផលវិបាកវិជ្ជមានមួយចំនួនផងដែរ៖ ដោយបានទទួលធនធានចាំបាច់ Cortex បានជាសះស្បើយដោយស្វ័យប្រវត្តិដោយគ្មានអន្តរាគមន៍បន្ថែម។ យើងក៏ទទួលបានបទពិសោធន៍ដ៏មានតម្លៃក្នុងការធ្វើការជាមួយផងដែរ។ Grafana Loki - ប្រព័ន្ធប្រមូលផ្តុំកំណត់ហេតុថ្មីរបស់យើង - ដែលបានជួយធានាថា Ingesters ទាំងអស់មានអាកប្បកិរិយាត្រឹមត្រូវក្នុងអំឡុងពេល និងបន្ទាប់ពីការបរាជ័យ។

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

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

• «ការធ្វើមាត្រដ្ឋានដោយស្វ័យប្រវត្តិ និងការគ្រប់គ្រងធនធាននៅក្នុង Kubernetes (ការពិនិត្យឡើងវិញ និងរបាយការណ៍វីដេអូ)»
• «ដំណើរផ្សងព្រេង Kubernetes Dailymotion៖ បង្កើតហេដ្ឋារចនាសម្ព័ន្ធនៅក្នុងពពក + បរិវេណ»
• «ការផ្លាស់ប្តូរ Tinder ទៅ Kubernetes»
• «Kubernetes រឿងជោគជ័យក្នុងផលិតកម្ម។ ផ្នែកទី 10: Reddit"។

ប្រភព: www.habr.com