ការត្រួតពិនិត្យក្រុម Kubernetes៖ ទិដ្ឋភាពទូទៅ និងការណែនាំអំពី Prometheus

ពិចារណាអំពីគំនិតនៃការត្រួតពិនិត្យ Kubernetes ស្គាល់ឧបករណ៍ Prometheus និងនិយាយអំពីការជូនដំណឹង។

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

សម្ភារៈនៃអត្ថបទគឺជាការច្របាច់ចេញពី បើកការបង្រៀនរបស់សាលា "Slurm". ប្រសិនបើអ្នកចង់រៀនវគ្គសិក្សាពេញលេញ - ចុះឈ្មោះសម្រាប់វគ្គសិក្សានៅលើ ការត្រួតពិនិត្យ និងការកត់ត្រាហេដ្ឋារចនាសម្ព័ន្ធនៅក្នុង Kubernetes.

អ្វីដែលត្រូវបានត្រួតពិនិត្យនៅក្នុងចង្កោម Kubernetes

ម៉ាស៊ីនមេរាងកាយ។ ប្រសិនបើក្រុម Kubernetes ត្រូវបានដាក់ពង្រាយនៅលើម៉ាស៊ីនមេរបស់វា អ្នកត្រូវតាមដានសុខភាពរបស់ពួកគេ។ Zabbix ដោះស្រាយកិច្ចការនេះ; ប្រសិនបើអ្នកធ្វើការជាមួយគាត់នោះអ្នកមិនចាំបាច់បដិសេធទេវានឹងមិនមានជម្លោះទេ។ វាគឺជា Zabbix ដែលត្រួតពិនិត្យស្ថានភាពនៃម៉ាស៊ីនមេរបស់យើង។

ចូរបន្តទៅការត្រួតពិនិត្យនៅកម្រិតចង្កោម។

ធាតុផ្សំនៃយន្តហោះគ្រប់គ្រង៖ API, កម្មវិធីកំណត់ពេល និងផ្សេងៗទៀត។ យ៉ាងហោចណាស់ អ្នកត្រូវប្រាកដថា API នៃម៉ាស៊ីនមេ ឬ etcd ធំជាង 0 ។ Etcd អាចត្រឡប់ម៉ែត្រជាច្រើន៖ ដោយថាសដែលវាកំពុងបង្វិល ដោយសុខភាពនៃក្រុម etcd របស់វា និងផ្សេងទៀត។

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

DNS ។ ប្រសិនបើ DNS ធ្លាក់ក្នុងចង្កោម នោះសេវាកម្ម Discovery ទាំងមូលនឹងធ្លាក់ចុះបន្ទាប់ពីវា ការហៅទូរសព្ទពីផតទៅផតនឹងឈប់ដំណើរការ។ នៅក្នុងការអនុវត្តរបស់ខ្ញុំ មិនមានបញ្ហាបែបនេះទេ ប៉ុន្តែនេះមិនមានន័យថាស្ថានភាព DNS មិនចាំបាច់ត្រូវបានត្រួតពិនិត្យនោះទេ។ ស្នើសុំភាពយឺតយ៉ាវ និងម៉ែត្រមួយចំនួនផ្សេងទៀតអាចត្រូវបានតាមដាននៅលើ CoreDNS ។

ចូល។ វាចាំបាច់ដើម្បីគ្រប់គ្រងភាពអាចរកបាននៃ ingresses (រួមទាំង Ingress Controller) ដែលជាចំណុចចូលទៅក្នុងគម្រោង។

សមាសធាតុសំខាន់ៗនៃចង្កោមត្រូវបានរុះរើ - ឥឡូវនេះសូមចុះទៅកម្រិតនៃការអរូបី។

វានឹងហាក់បីដូចជាកម្មវិធីដំណើរការក្នុង pods ដែលមានន័យថាពួកគេត្រូវការគ្រប់គ្រង ប៉ុន្តែតាមពិតវាមិនមែនទេ។ Pods មានភាពច្របូកច្របល់៖ ថ្ងៃនេះពួកគេដំណើរការនៅលើម៉ាស៊ីនមេមួយ ថ្ងៃស្អែកនៅលើមួយផ្សេងទៀត។ ថ្ងៃ​នេះ​មាន​១០​នាក់ ស្អែក​២។​ ដូច្នេះ​ហើយ​គ្មាន​អ្នក​ណា​ត្រួត​ពិនិត្យ​គ្រាប់​នោះ​ទេ។ នៅក្នុងស្ថាបត្យកម្ម microservice វាមានសារៈសំខាន់ជាងក្នុងការគ្រប់គ្រងភាពអាចរកបាននៃកម្មវិធីទាំងមូល។ ជាពិសេស ពិនិត្យមើលភាពអាចរកបាននៃចំណុចបញ្ចប់នៃសេវាកម្ម៖ តើមានអ្វីដំណើរការទេ? ប្រសិនបើកម្មវិធីអាចប្រើបាន នោះមានអ្វីកើតឡើងនៅពីក្រោយវា តើការចម្លងមានចំនួនប៉ុន្មានឥឡូវនេះ - ទាំងនេះគឺជាសំណួរនៃលំដាប់ទីពីរ។ មិនចាំបាច់ត្រួតពិនិត្យករណីបុគ្គលទេ។

នៅកម្រិតចុងក្រោយ អ្នកត្រូវគ្រប់គ្រងប្រតិបត្តិការរបស់កម្មវិធីខ្លួនឯង យករង្វាស់ធុរកិច្ច៖ ចំនួននៃការបញ្ជាទិញ អាកប្បកិរិយារបស់អ្នកប្រើប្រាស់ និងអ្វីៗផ្សេងទៀត។

Prometheus

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

មានជម្រើសពីរបីសម្រាប់ការចាប់ផ្តើមជាមួយ Prometheus: ដោយប្រើ Helm អ្នកអាចដំឡើង Prometheus ឬ Prometheus Operator ធម្មតា។

1. Prometheus ធម្មតា។ អ្វីគ្រប់យ៉ាងគឺល្អជាមួយគាត់ ប៉ុន្តែអ្នកត្រូវកំណត់រចនាសម្ព័ន្ធ ConfigMap - តាមពិត សរសេរឯកសារកំណត់រចនាសម្ព័ន្ធដែលមានមូលដ្ឋានលើអត្ថបទ ដូចដែលយើងធ្លាប់បានធ្វើពីមុនមក មុនពេលស្ថាបត្យកម្ម microservice ។
2. Prometheus Operator មានការរីករាលដាលបន្តិច ភាពស្មុគស្មាញបន្តិចទាក់ទងនឹងតក្កវិជ្ជាខាងក្នុង ប៉ុន្តែវាកាន់តែងាយស្រួលក្នុងការធ្វើការជាមួយវា៖ មានវត្ថុដាច់ដោយឡែក ការអរូបីត្រូវបានបន្ថែមទៅក្នុងចង្កោម ដូច្នេះពួកគេកាន់តែងាយស្រួលក្នុងការគ្រប់គ្រង និងកំណត់រចនាសម្ព័ន្ធ។

ដើម្បីយល់ពីផលិតផលខ្ញុំសូមណែនាំឱ្យដំឡើង Prometheus ធម្មតាជាមុនសិន។ អ្នកនឹងត្រូវកំណត់រចនាសម្ព័ន្ធអ្វីគ្រប់យ៉ាងតាមរយៈ config ប៉ុន្តែវានឹងមានប្រយោជន៍: អ្នកនឹងស្វែងយល់ពីអ្វីដែលជាកម្មសិទ្ធិរបស់អ្វី និងរបៀបដែលវាត្រូវបានកំណត់រចនាសម្ព័ន្ធ។ នៅក្នុង Prometheus Operator អ្នកឡើងភ្លាមៗទៅ abstraction ខ្ពស់ជាង ទោះបីជាអ្នកក៏អាចស្វែងយល់ពីជម្រៅប្រសិនបើអ្នកចង់បាន។

Prometheus ត្រូវបានរួមបញ្ចូលយ៉ាងល្អជាមួយ Kubernetes៖ វាអាចចូលប្រើ និងធ្វើអន្តរកម្មជាមួយ API Server។

Prometheus មានប្រជាប្រិយភាព ដែលនេះជាមូលហេតុដែលកម្មវិធី និងភាសាសរសេរកម្មវិធីមួយចំនួនធំគាំទ្រវា។ ត្រូវការការគាំទ្រ ដោយសារ Prometheus មានទម្រង់ម៉ែត្រផ្ទាល់របស់វា ហើយដើម្បីផ្ទេរវា អ្នកត្រូវការបណ្ណាល័យមួយនៅខាងក្នុងកម្មវិធី ឬអ្នកនាំចេញដែលត្រៀមរួចជាស្រេច។ ហើយ​មាន​អ្នក​នាំ​ចេញ​បែប​នេះ​មួយ​ចំនួន។ ឧទាហរណ៍ មាន PostgreSQL Exporter៖ វាយកទិន្នន័យពី PostgreSQL ហើយបំប្លែងវាទៅជាទម្រង់ Prometheus ដូច្នេះ Prometheus អាចធ្វើការជាមួយវាបាន។

ស្ថាបត្យកម្ម Prometheus

ម៉ាស៊ីនមេ Prometheus គឺជាផ្នែកខាងក្រោយ ខួរក្បាលរបស់ Prometheus ។ ម៉ែត្រត្រូវបានរក្សាទុក និងដំណើរការនៅទីនេះ។

ម៉ែត្រត្រូវបានរក្សាទុកនៅក្នុងមូលដ្ឋានទិន្នន័យស៊េរីពេលវេលា (TSDB) ។ TSDB មិនមែនជាមូលដ្ឋានទិន្នន័យដាច់ដោយឡែកទេ ប៉ុន្តែជាកញ្ចប់នៅក្នុងភាសា Go ដែលត្រូវបានបង្កប់នៅក្នុង Prometheus ។ និយាយជារួម អ្វីគ្រប់យ៉ាងគឺនៅក្នុងប្រព័ន្ធគោលពីរ។

កុំរក្សាទុកទិន្នន័យនៅក្នុង TSDB រយៈពេលយូរ

ហេដ្ឋារចនាសម្ព័ន្ធ Prometheus មិនស័ក្តិសមសម្រាប់ការរក្សាទុកម៉ែត្ររយៈពេលវែងនោះទេ។ រយៈពេលរក្សាទុកលំនាំដើមគឺ 15 ថ្ងៃ។ អ្នកអាចលើសពីដែនកំណត់នេះ ប៉ុន្តែត្រូវចងចាំថា៖ ទិន្នន័យកាន់តែច្រើនដែលអ្នករក្សាទុកក្នុង TSDB និងយូរជាងនេះ វានឹងប្រើប្រាស់ធនធានកាន់តែច្រើន។ ការរក្សាទុកទិន្នន័យប្រវត្តិសាស្ត្រនៅក្នុង Prometheus ត្រូវបានចាត់ទុកថាជាការអនុវត្តមិនល្អ។

ប្រសិនបើអ្នកមានចរាចរណ៍ដ៏ធំ ចំនួនម៉ែត្រគឺរាប់រយរាប់ពាន់ក្នុងមួយវិនាទី នោះវាជាការប្រសើរក្នុងការកំណត់ទំហំផ្ទុករបស់ពួកគេដោយទំហំថាស ឬតាមកាលកំណត់។ ជាធម្មតា "ទិន្នន័យក្តៅ" ត្រូវបានរក្សាទុកនៅក្នុង TSDB ដែលជាម៉ែត្រក្នុងរយៈពេលតែប៉ុន្មានម៉ោងប៉ុណ្ណោះ។ សម្រាប់ការផ្ទុកយូរជាងនេះ ការផ្ទុកខាងក្រៅត្រូវបានប្រើនៅក្នុងមូលដ្ឋានទិន្នន័យទាំងនោះដែលពិតជាសាកសមសម្រាប់ការនេះ ឧទាហរណ៍ InfluxDB, ClickHouse និងដូច្នេះនៅលើ។ ខ្ញុំបានឃើញការវាយតម្លៃល្អបន្ថែមទៀតអំពី ClickHouse ។

ម៉ាស៊ីនមេ Prometheus ដំណើរការលើគំរូ ទាញ៖ គាត់​ទៅ​រក​ម៉ែត្រ​ទៅ​ចំណុច​ចុង​ទាំង​នោះ​ដែល​យើង​បាន​ឲ្យ​គាត់។ ពួកគេបាននិយាយថា "ចូលទៅកាន់ API Server" ហើយគាត់ទៅទីនោះរាល់វិនាទីទី XNUMX ហើយយកម៉ែត្រ។

សម្រាប់វត្ថុដែលមានអាយុកាលខ្លី (ការងារ ឬការងារ cron) ដែលអាចលេចឡើងនៅចន្លោះពេលសំណល់អេតចាយ មានសមាសធាតុ Pushgateway ។ ម៉ែត្រពីវត្ថុរយៈពេលខ្លីត្រូវបានរុញចូលទៅក្នុងវា៖ ការងារបានកើនឡើង អនុវត្តសកម្មភាព បញ្ជូនម៉ែត្រទៅ Pushgateway និងបានបញ្ចប់។ មួយសន្ទុះក្រោយមក Prometheus នឹងចុះមកតាមល្បឿនរបស់វា ហើយយកម៉ែត្រទាំងនេះពី Pushgateway ។

ដើម្បីកំណត់រចនាសម្ព័ន្ធការជូនដំណឹងនៅក្នុង Prometheus មានសមាសភាគដាច់ដោយឡែកមួយ - អ្នកគ្រប់គ្រងការជូនដំណឹង. និងច្បាប់ជូនដំណឹង។ ឧទាហរណ៍ អ្នកត្រូវបង្កើតការដាស់តឿន ប្រសិនបើ server API គឺ 0។ នៅពេលដែលព្រឹត្តិការណ៍ផ្ទុះ ការជូនដំណឹងត្រូវបានបញ្ជូនទៅអ្នកគ្រប់គ្រងការជូនដំណឹងសម្រាប់ការបញ្ជូនបន្ត។ កម្មវិធីគ្រប់គ្រងការជូនដំណឹងមានការកំណត់ផ្លូវដែលអាចបត់បែនបាន៖ ការជូនដំណឹងមួយក្រុមអាចត្រូវបានផ្ញើទៅកាន់ការជជែកតាមតេឡេក្រាមរបស់អ្នកគ្រប់គ្រង មួយទៀតទៅការជជែករបស់អ្នកអភិវឌ្ឍន៍ និងមួយភាគបីទៅការជជែករបស់បុគ្គលិកផ្នែកហេដ្ឋារចនាសម្ព័ន្ធ។ ការជូនដំណឹងអាចត្រូវបានផ្ញើទៅកាន់ Slack, Telegram, អ៊ីមែល និងបណ្តាញផ្សេងទៀត។

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

វិធីសាស្រ្តនេះសមល្អជាមួយរចនាសម្ព័ន្ធ Kubernetes ដែលអ្វីៗក៏អណ្តែតដែរ៖ ថ្ងៃនេះមាន 10 servers ថ្ងៃស្អែក 3. ដើម្បីមិនបញ្ជាក់អាសយដ្ឋាន IP របស់ server រាល់ពេល ពួកគេបានសរសេរម្តងអំពីរបៀបស្វែងរកវា ហើយការរកឃើញនឹងធ្វើវា .

ភាសា Prometheus ត្រូវបានគេហៅថា PromQL. ដោយប្រើភាសានេះ អ្នកអាចទទួលបានតម្លៃនៃម៉ែត្រជាក់លាក់ ហើយបន្ទាប់មកបម្លែងពួកវា បង្កើតការគណនាវិភាគដោយផ្អែកលើពួកគេ។

https://prometheus.io/docs/prometheus/latest/querying/basics/

Простой запрос

    container_memory_usage_bytes

Математические операции

    container_memory_usage_bytes / 1024 / 1024

Встроенные функции

    sum(container_memory_usage_bytes) / 1024 / 1024

Уточнение запроса

    100 - avg by (instance) (rate(node_cpu_seconds_total{mode="idle"}[5m]) * 100)

ចំណុចប្រទាក់បណ្តាញ Prometheus

Prometheus មានចំណុចប្រទាក់គេហទំព័រផ្ទាល់ខ្លួន តិចតួចបំផុត សមរម្យសម្រាប់តែការបំបាត់កំហុស ឬការបង្ហាញប៉ុណ្ណោះ។

នៅក្នុងបន្ទាត់កន្សោម អ្នកអាចសរសេរសំណួរជាភាសា PromQL ។

ផ្ទាំងការជូនដំណឹងមានច្បាប់ជូនដំណឹង ហើយពួកគេមានស្ថានភាពបី៖

1. អសកម្ម - ប្រសិនបើការដាស់តឿនមិនសកម្មនៅពេលនេះ នោះមានន័យថា អ្វីៗគឺល្អជាមួយវា ហើយវាមិនដំណើរការទេ។
2. រង់ចាំ - នេះគឺប្រសិនបើការដាស់តឿនដំណើរការ ប៉ុន្តែការផ្ញើមិនទាន់ឆ្លងកាត់នៅឡើយ។ ការពន្យារពេលត្រូវបានកំណត់ដើម្បីទូទាត់សងសម្រាប់ការភ្លឹបភ្លែតៗនៃបណ្តាញ៖ ប្រសិនបើសេវាកម្មដែលបានបញ្ជាក់បានកើនឡើងក្នុងរយៈពេលមួយនាទី នោះសំឡេងរោទិ៍មិនគួរត្រូវបានបន្លឺឡើងនៅឡើយទេ។
3. ការបាញ់គឺជាស្ថានភាពទីបី នៅពេលដែលការជូនដំណឹងភ្លឺឡើង និងផ្ញើសារ។

នៅក្នុងម៉ឺនុយស្ថានភាពអ្នកនឹងរកឃើញការចូលប្រើព័ត៌មានអំពីអ្វីដែល Prometheus ។ វាក៏មានការផ្លាស់ប្តូរទៅកាន់គោលដៅ (គោលដៅ) ដែលយើងបាននិយាយខាងលើ។

សម្រាប់ទិដ្ឋភាពទូទៅលម្អិតនៃចំណុចប្រទាក់ Prometheus សូមមើល នៅក្នុងការបង្រៀនរបស់ Slurm ស្តីពីការត្រួតពិនិត្យក្រុម Kubernetes.

ការរួមបញ្ចូលជាមួយ Grafana

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

ការដំឡើងការរួមបញ្ចូល Prometheus និង Grafana មិនពិបាកទាល់តែសោះ អ្នកអាចស្វែងរកការណែនាំនៅក្នុងឯកសារ៖ GRAFANA គាំទ្រសម្រាប់ PROMETHEUSអញ្ចឹងខ្ញុំនឹងបញ្ចប់រឿងនេះ។

នៅក្នុងអត្ថបទខាងក្រោម យើងនឹងបន្តប្រធានបទនៃការត្រួតពិនិត្យ៖ យើងនឹងនិយាយអំពីការប្រមូល និងវិភាគកំណត់ហេតុដោយប្រើ Grafana Loki និងឧបករណ៍ជំនួស។

អ្នកនិពន្ធ៖ Marcel Ibraev, អ្នកគ្រប់គ្រង Kubernetes ដែលមានការបញ្ជាក់, អនុវត្តវិស្វករនៅក្នុងក្រុមហ៊ុន សៅប្រ៊ីតវាគ្មិន និងអ្នកអភិវឌ្ឍន៍វគ្គសិក្សា Slurm ។

ប្រភព: www.habr.com