រង្វាស់ ការត្រួតពិនិត្យ ការជូនដំណឹង

មាតិកា៖

សង្ខេប
ព័ត៌មានលម្អិត
ពាក់ព័ន្ធ
កំណត់ចំណាំ

សង្ខេប

បញ្ហា

យើងចង់ប្រើរង្វាស់ ការត្រួតពិនិត្យ និងការជូនដំណឹង ព្រោះយើងចង់ដឹងថាកម្មវិធីរបស់យើងដំណើរការបានល្អប៉ុណ្ណា និងដឹងនៅពេលមានបញ្ហា។

ការសម្រេចចិត្ត

កំពុងដំណើរការ (WIP)។

ស្ថានភាព

កំពុងប្រមូលព័ត៌មាន។ យើងកំពុងចាប់ផ្តើមជាមួយចុងទាំងពីរដែលអាចជឿជាក់បាននៃវិសាលគម៖ ឧបករណ៍ឥតគិតថ្លៃចាស់ដែលត្រូវបានណែនាំច្រើនបំផុត (Nagios) និងឧបករណ៍បង់ប្រាក់ថ្មីដែលត្រូវបានណែនាំច្រើនបំផុត (New Relic)។

ព័ត៌មានលម្អិត

ការសន្មត់

យើងចង់បង្កើតកម្មវិធីគេហទំព័រដែលទំនើប លឿន អាចទុកចិត្តបាន ឆ្លើយតបបាន ។ល។

យើងចង់ទិញជាជាងកសាង។

ឧបសគ្គ

យើងចង់បានឧបករណ៍ដែលដំណើរការបានល្អជាមួយបំពង់ devops របស់យើង និងជាមួយពពកដាក់ពង្រាយរបស់យើង។

ជំហរ

យើងកំពុងស្រាវជ្រាវជំហរឥឡូវនេះ។

AlertManager
AppDynamics
AppOptics
Azure Monitor/Analytics/Insights/Dashboards
Bosun
Checkly
Circonus
Cloudwatch
EFK
ELK
Grafana
Grafana
Graphite
Graylog
Healthchecks.io
Heroku
icinga2
InfluxDB
Instana
Kafka
Logagent
Logz.io
Loki
Monitis
Nagios
Nagios
Nagiosgraph
NewRelic
OpsGenie
Outlyer
PagerDuty
Pagerduty
PagerDuty
Papertrail
Prometheus
Rollbar
Scalyr
Sematext Metrics, Logs, Experience, Tracing
Sensu
SignalFX
Slack
Splunk
Stackdriver
Stackstorm
Telegraf
Telegraf
Thanos
VictorOps
Wavefront
Zabbix

អាគុយម៉ង់

រហូតមកដល់ពេលនេះ Nagios និង New Relic គឺជាចុងទាំងពីរនៃវិសាលគម។ Nagios គឺជាឧបករណ៍ចាស់បំផុត សាមញ្ញបំផុត ឥតគិតថ្លៃ និងអាចអនុវត្តបាន។ New Relic គឺជាឧបករណ៍ដែលមានមុខងារថ្មីបំផុត ពេញលេញបំផុត បង់ប្រាក់ និងអាចអនុវត្តបាន។ យើងនឹងចាប់ផ្តើមជាមួយការវាយតម្លៃទាំងនេះ។ តាមតម្រូវការ យើងនឹងផ្លាស់ប្តូរចូលទៅក្នុងវិសាលគម។

រហូតមកដល់ពេលនេះ Zabbix មានអនុសាសន៍ល្អបំផុត ហើយក៏ផ្តល់សមត្ថភាពពេញលេញបំផុតដែរ។

រហូតមកដល់ពេលនេះ ELK មានប្រជាប្រិយភាពកូដចំហ កសាងជាជាងទិញ ល្អបំផុត។

រហូតមកដល់ពេលនេះ Prometheus + Graphana មានប្រជាប្រិយភាពល្អបំផុត។

ផលវិបាក

ត្រូវធ្វើ។

ពាក់ព័ន្ធ

ការសម្រេចចិត្តពាក់ព័ន្ធ

ជម្រើសនឹងប៉ះពាល់ដល់ភាពអាចសាកល្បងបាន ទូរមាត្រ និងទំនងជាប្រព័ន្ធផ្សេងទៀតដូចជាសម្រាប់សេវាអតិថិជន វិស្វកម្មភាពអាចទុកចិត្តបាននៃគេហទំព័រ ។ល។

តម្រូវការពាក់ព័ន្ធ

ត្រូវធ្វើ។

វត្ថុពាក់ព័ន្ធ

ត្រូវធ្វើ។

គោលការណ៍ពាក់ព័ន្ធ

អាចត្រឡប់វិញបានយ៉ាងងាយ។

ត្រូវការល្បឿន។

កំណត់ចំណាំ

ជង់កូដចំហដែលល្អគួរសមគឺ៖

Prometheus សម្រាប់រង្វាស់ និងការជូនដំណឹងដោយផ្អែកលើរង្វាស់
Grafana ដើម្បីបង្ហាញរង្វាស់
Elasticsearch/Logstash/Kibana (ELK) សម្រាប់កំណត់ហេតុ និងព្រឹត្តិការណ៍មានរចនាសម្ព័ន្ធ
Pushover សម្រាប់ការជូនដំណឹងលើទូរស័ព្ទចល័ត

សារអត្ថបទសេរី ប្រៀបធៀបសារព្រឹត្តិការណ៍មានរចនាសម្ព័ន្ធ

សារអត្ថបទសេរី៖ ឧទាហរណ៍ របស់ចៃដន្យដែលអ្នកនឹងរកឃើញក្នុង /var/log/messages និងអ្វីដែលបង្កើតដោយចេតនាដោយកម្មវិធី។ សារទាំងនេះមានប្រយោជន៍សម្រាប់កំណត់អត្តសញ្ញាណរឿងផ្សេងទៀតដែលកំពុងកើតឡើងលើម៉ាស៊ីន ដូចជាអស់អង្គចងចាំ ឬកំហុសផ្នែករឹង ប៉ុន្តែមានសំរាមច្រើន។

សារព្រឹត្តិការណ៍មានរចនាសម្ព័ន្ធ៖ បង្កើតដោយកម្មវិធី ជាមួយសំណុំគុណលក្ខណៈថេរ ឬថាមវន្ត ឧ. កំណត់ហេតុសំណើ HTTP កំណត់ហេតុគណនេយ្យ ការចូលរបស់អ្នកប្រើ។

និយាយជាទូទៅ វាល្អក្នុងការកត់ត្រាព័ត៌មានលម្អិតអំពីរាល់សំណើតាមរបៀបដែលអ្នកអាចស្វែងយល់ស៊ីជម្រៅដោយផ្អែកលើគុណលក្ខណៈ។ ដូច្នេះការបន្ថែមឧ. userid ឬ sessionid ទៅគ្រប់យ៉ាងអនុញ្ញាតឱ្យអ្នកតាមដាន។ ការតាមដានច្បាស់លាស់ក៏ល្អដែរ ជាការពិត។ ការប្រើ ELK សម្រាប់រឿងនេះគឺជាប្រភេទ https://www.honeycomb.io/ របស់មនុស្សក្រីក្រ

Graylog ងាយស្រួលជាង

Graylog ងាយស្រួលជាងក្នុងការដំឡើងតាមបទពិសោធន៍របស់ខ្ញុំ។

Prometheus ត្រូវការកែសម្រួលខ្លះ

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

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

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

សេវាកម្ម AWS មានលាយឡំ

បទពិសោធន៍របស់ខ្ញុំជាមួយសេវាកម្ម AWS មានលាយឡំ។ សេវាកម្ម Elasticsearch របស់ពួកគេមិនស្ថិរភាព ដូច្នេះយើងដំណើរការករណីរបស់យើងផ្ទាល់សម្រាប់រឿងនោះ។ រង្វាស់ CloudWatch ថ្លៃ ដូច្នេះយើងជាទូទៅប្រើវាសម្រាប់តែរង្វាស់កម្រិត “ហេដ្ឋារចនាសម្ព័ន្ធ” ជាជាងកម្មវិធី ពោលគឺរង្វាស់ទាក់ទងនឹងសុខភាពដែល AWS អាចដឹងល្អជាងអ្វីដែលកំពុងកើតឡើង ជាងកម្មវិធីដែលដំណើរការលើករណី។ កំណត់ហេតុ CloudWatch អាចយឺតក្នុងការធ្វើបច្ចុប្បន្នភាព ហើយមិនមានទិន្នន័យមេតាច្រើនទេ។ ការដំណើរការ ELK ជួយក្នុងរឿងនោះ។ ប្រសិនបើខ្ញុំពិតជាចង់បានទិន្នន័យពេលវេលាជាក់ស្តែង នោះការប្រើ Kafka ជាការដឹកជញ្ជូនសម្រាប់កំណត់ហេតុគឺប្រសើរជាង។ នោះត្រូវបានគាំទ្រយ៉ាងល្អដោយ Logstash។ ការគ្រប់គ្រងចង្កោម Kafka មិនមែនសម្រាប់មនុស្សដែលចិត្តខ្សោយទេ មានបំពង់ទុកជាច្រើនដែលបើកចំហ។

Kafka

មតិយោបល់៖ Kafka អាចស្មុគស្មាញខ្លាំងពេលខ្លះ ឬ Kafka អាចរឹងមាំដូចថ្មហើយអ្នកស្ទើរតែភ្លេចថាវានៅទីនោះភ្ជាប់អ្វីៗទាំងអស់ចូលគ្នា។

មតិយោបល់៖ Kafka រឹងមាំ ប៉ុន្តែវាត្រូវការការងារច្រើនគួរឱ្យភ្ញាក់ផ្អើលដើម្បីឱ្យវាដំណើរការ។ ខ្ញុំគិតថាវាដូចជាមូលដ្ឋានទិន្នន័យទំនាក់ទំនង ប៉ុន្តែអ្នកធ្វើការតែនៅស្រទាប់ “រូបវន្ត” ឧ. tablespaces ឯកសារ និងភាគ។ មានពេលខ្លះនៅដំបូងដែលឧបករណ៍គ្រប់គ្រងខ្វះខាត ហើយយើងត្រូវសរសេរកម្មវិធីដើម្បីឧ. កំណត់ក្រុមអ្នកប្រើប្រាស់ឡើងវិញ។ http://howfuckedismydatabase.com/nosql/

មតិយោបល់៖ យើងប្រើ Kafka ជា “ឃ្លាំងបណ្តោះអាសន្ន” សម្រាប់សារកំណត់ហេតុ និងកន្លែងដែលយើងអាចធ្វើដំណើរការស្ទ្រីមពេលវេលាជាក់ស្តែងលើទិន្នន័យដែលមកពីម៉ាស៊ីនមេច្រើន។ ប្រសិនបើយើងទទួលបានការវាយប្រហារ DDOS នោះយើងត្រូវការវិធីវិភាគទិន្នន័យនៅទូទាំងករណីច្រើន។ ប្រសិនបើយើងកត់ត្រាកំណត់ហេតុដោយផ្ទាល់ពីម៉ាស៊ីនមេទៅ ELK បន្ទុកអាចធ្វើឱ្យចង្កោម Elasticsearch ផ្ទុះ។

មតិយោបល់៖ Kafka ល្អសម្រាប់យើង ព្រោះប្រសិនបើយើងទទួលបានការវាយប្រហារ DDOS នោះយើងត្រូវការវិធីវិភាគទិន្នន័យនៅទូទាំងករណីច្រើន។ ប្រសិនបើយើងកត់ត្រាកំណត់ហេតុដោយផ្ទាល់ពីម៉ាស៊ីនមេទៅ ELK បន្ទុកអាចធ្វើឱ្យចង្កោម Elasticsearch ផ្ទុះ។

មតិយោបល់៖ Kafka ធ្វើការតិចជាង និងមានប្រសិទ្ធភាពជាង ដូច្នេះវាអាចដោះស្រាយបន្ទុកបានល្អជាង។ ហើយយើងដាក់ជួរការងារ Kafka ហើយព្យាយាមម្តងទៀត។ ហើយការដែល Kafka ផ្ទុកលើសមិនប៉ះពាល់ដល់អ្នកប្រើដែលកំពុងព្យាយាមធ្វើការអន្តរកម្មជាមួយ Kibana ដូចដែលវានឹងប៉ះពាល់ប្រសិនបើ Elasticsearch កំពុងតស៊ូ។

មតិយោបល់៖ ការដំណើរការស្ទ្រីមភាគច្រើនគឺរកមើលការបំពាន ឧ. ចរាចរណ៍ច្រើនពេកពី IP តែមួយនៅទូទាំងចង្កោមទាំងមូល ហើយបន្ទាប់មកចែករំលែកការរារាំងនៅទូទាំងចង្កោមទាំងមូល។

មតិយោបល់៖ កម្មវិធីជំនួយ logstash-output-kafka មិនអាចទុកចិត្តបានខ្លាំងនៅពេលនេះ។ ខ្ញុំត្រូវបានខាំដោយបញ្ហាជាច្រើននៅលើទំព័របញ្ហា GitHub របស់វា ដែលហាក់ដូចជាមិនដែលត្រូវបានជួសជុលទេ។ ខ្ញុំចង់ងាកចេញពីការប្រើវា ទៅផ្ញើដោយផ្ទាល់ពីកម្មវិធីរបស់យើងទៅ Kafka។

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

Loki

តាមដាន Loki ឱ្យជិត។ វាមិនទាន់រួចរាល់ទេ ប៉ុន្តែនៅពេលវារួចរាល់ ខ្ញុំរំពឹងថាវានឹងសមស្របល្អជាងក្នុងជង់នេះ។ Loki គឺជាកម្មវិធីប្រមូលកំណត់ហេតុដែលបង្កើតដោយ grafana labs វាប្រើវាក្យសម្ព័ន្ធ scraping និងស្លាកស្រដៀងនឹង Prometheus។

Prometheus + alertmanager + Rollbar + Graylog + Grafana

Prometheus + alertmanager សម្រាប់រង្វាស់។ ស្រលាញ់ Prometheus ។

Rollbar/Graylog សម្រាប់ការកត់ត្រាកំណត់ហេតុ/ការរាយការណ៍កំហុស (មានការត្រួតស៊ីគ្នាខ្លះនៅទីនេះ សេវាកម្មតូចប្រហែលជាមិនត្រូវការទាំងពីរទេ)។

បច្ចុប្បន្ន ការជូនដំណឹងគ្រាន់តែទៅកាន់ឆានែល Slack មួយក្នុងចំណោមពីរបីដែលភាគីដែលចាប់អារម្មណ៍បានបើកការជូនដំណឹង។ ប្រសិនបើយើងធ្ងន់ធ្ងរជាងនេះអំពីការទទួលបន្ទុក ពួកវានឹងទៅកាន់ PagerDuty/VictorOps/ជាដើម។

Grafana សម្រាប់ក្រាហ្វ និងផ្ទាំងគ្រប់គ្រង។ ក៏កំពុងរង់ចាំយ៉ាងអន្ទះសារដើម្បីមើលថាតើមុខងារកត់ត្រាកំណត់ហេតុដែលនឹងមកដល់របស់ពួកគេនឹងលុបបំបាត់ Graylog ឬអត់។

Thanos

យើងប្រើ Thanos ជាផ្នែកខាងមុខសម្រាប់ការដំឡើង HA របស់យើង។ វាដឹងពីរបៀបលុបទិន្នន័យស្ទួនចេញពីគូ HA។

បច្ចុប្បន្នយើងកំពុងរក្សាទិន្នន័យ Prometheus ក្នុងស្រុក 6 ខែ។ នេះដំណើរការបានល្អសមហេតុផលសម្រាប់យើង។ ប៉ុន្តែខ្ញុំទើបតែនៅកណ្តាលនៃការដាក់ចេញការផ្ទុកធុង (bucket) ទៅការដំឡើង Thanos របស់យើងសម្រាប់ការផ្ទុកទិន្នន័យរយៈពេលវែង។ តាមទ្រឹស្តី ការផ្ទុក GCS នឹងថោកជាងប្រហែល 30% ធៀបនឹងថាសអចិន្ត្រៃយ៍ស្តង់ដារ GCE ដែលយើងប្រើឥឡូវនេះ។

យើងមិនបម្រុងទុកទិន្នន័យ Prometheus ឥឡូវនេះទេ។ ទិន្នន័យមិនសំខាន់សម្រាប់យើងពិតប្រាកដទេ ក្រៅពីមានគ្រប់គ្រាន់សម្រាប់ការជូនដំណឹង។ ការដាក់ពង្រាយកងនាវាទាំងមូលរបស់យើងផ្លាស់ប្តូរច្រើនពីឆ្នាំមួយទៅឆ្នាំមួយ ដូច្នេះទិន្នន័យប្រវត្តិចាស់ជាងពីរបីខែពិតជាមិនគួរឱ្យចាប់អារម្មណ៍ទេ។ វាប្រហែលជាគួរឱ្យចាប់អារម្មណ៍ក្នុងការមានស្ថិតិស្នូលពីរបីឆ្នាំទល់ឆ្នាំ ខ្ញុំអាចដំឡើងសំណុំច្បាប់កត់ត្រាស្ថិតិស្នូល ហើយផ្ទុកវាជាមួយ Federation ឬគ្រាន់តែឱ្យ Thanos ថែទាំវា។

កែសម្រួល៖ ការបដិសេធតូចមួយ ខ្ញុំជាអ្នកអភិវឌ្ឍន៍ Prometheus។

Prometheus HA

HA ក្នុង Prometheus ធ្វើដោយការស្ទួន អ្នកដំណើរការ poppers ច្រើន មានវិធីដើម្បីស្ទង់មតិច្រើន ហើយលុបទិន្នន័យស្ទួន

ការពង្រីកគឺដោយសម្រេចបណ្តាញ និងមាន Prometheus ផ្សេងគ្នាស្ទង់មតិផ្នែកផ្សេងៗនៃបណ្តាញ

ការផ្ទុករយៈពេលវែងមិនមែនជាចំណុចខ្លាំងរបស់ prom ទេ ប៉ុន្តែត្រូវបានផ្ទេរទៅអ្វីមួយដូចជា influx ឬ timescaledb (ដែលតាមបច្ចេកទេសក៏ធ្វើសញ្ញា HA ដែរ) អត្ថបទដែលខ្ញុំបានអានអំពីវា https://blog.timescale.com/prometheus-ha-postgresql-8de68d19b6f5?gi=7df160f10e07

មិនទាន់បានសាកល្បងរបស់រយៈពេលវែងនៅឡើយទេ ព្រោះខ្ញុំនៅតែកំពុងពិសោធ ហើយប្រើវាសម្រាប់ក្រាហ្វរយៈពេលខ្លី ចំណែក librenms ត្រួតពិនិត្យបណ្តាញរបស់ខ្ញុំសម្រាប់រយៈពេលវែង

Datadog + PagerDuty + Threat Stack

យើងប្រើ Datadog (ជាមួយ PagerDuty) និង Threat Stack ហើយមិនអាចសប្បាយចិត្តជាងនេះទេ។ ការត្អូញត្អែរតែមួយរបស់ខ្ញុំអំពី DD គឺថ្លៃដើមខ្ពស់ប្រៀបធៀបនៃការផ្ទុករង្វាស់។

Zabbix

Zabbix ជាមួយស្គ្រីបផ្ទាល់ខ្លួនដើម្បីត្រួតពិនិត្យស្ទើរតែគ្រប់យ៉ាង។ ដំណើរការដូចមន្តស្នេហ៍។

Outlyer

ខ្ញុំកំពុងប្រើ Outlyer ប៉ុន្តែខ្ញុំត្រូវបដិសេធថាខ្ញុំធ្វើការនៅទីនេះ ហើយ dog fooding ជាការចាំបាច់។

នៅតែត្រូវការ Graylog, Sentry និង Statuscake ដើម្បីបង្កើនប្រសិទ្ធភាព។

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

Nagios + Nagiosgraph

យើងដំណើរការ Nagios សម្រាប់ការត្រួតពិនិត្យ និងការជូនដំណឹងទាំងអស់។ ការជូនដំណឹងកើតឡើងតាមរយៈអ៊ីមែល (ការព្រមាន និងការជូនដំណឹងសំខាន់) និងការជូនដំណឹងកម្មវិធីដែលស្តាប់ឮ (សម្រាប់ការជូនដំណឹងសំខាន់)។

Nagiosgraph ត្រូវបានប្រើសម្រាប់ការបង្ហាញជារូបភាព។

ការដំឡើងនេះមានប្រសិទ្ធភាពខ្លាំងក្នុងការរក្សាយើងឱ្យបានជ្រាបព័ត៌មានទូលំទូលាយអំពីអ្វីដែលកំពុងកើតឡើងក្នុងបរិស្ថានរបស់យើង។ យើងដំណើរការ និងត្រួតពិនិត្យម៉ាស៊ីនមេដែលសំខាន់ចំពោះបេសកកម្មប្រហែល 110 និងចំណុចទិន្នន័យប្រហែល 760 ហើយមានប្រព័ន្ធនេះនៅនឹងកន្លែងអស់រយៈពេលជាង 7 ឆ្នាំ។

ខ្ញុំក៏ចង់ប្រមូលកំណត់ហេតុជាមួយ Graylog ឬ ELk នៅពេលណាមួយដែរ។

Prometheus + Grafana + AlertManager

Prometheus + Grafana + AlertManager តាមរយៈតារាង helm ដ៏អស្ចារ្យ Prometheus Operator។ កំណត់ហេតុនៅតែទៅ LogDNA ផែនការ birch ព្រោះយើងសង្កេតឃើញថា ELK ធ្ងន់ពេកសម្រាប់ថ្នាំងអប្បបរមា 3 អតិបរមា 5 ដ៏រាបទាបរបស់យើងលើ GKE។

DataDog + Sentry + PagerDuty.

ខ្ញុំធ្លាប់ដំណើរការដំណោះស្រាយត្រួតពិនិត្យទាំងអស់របស់ខ្ញុំដោយខ្លួនឯង ដោយប្រើកម្មវិធីគ្រប់ប្រភេទរួមទាំង Nagios, Icinga, Zabbix, ELK, Greylog2, Influx និងឧបករណ៍ជាច្រើនទៀត ប៉ុន្តែការពិតគឺថាមានការខិតខំច្រើនពេកក្នុងការដំណើរការហេដ្ឋារចនាសម្ព័ន្ធត្រួតពិនិត្យផ្ទាល់ខ្លួន ជាពិសេសនៅពេលអ្នកអាចបង់ប្រាក់ឱ្យអ្នកផ្សេងក្នុងអត្រាទាបបែបនេះដើម្បីឱ្យអ្នកផ្សេងធ្វើវាឱ្យអ្នក!

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

Sensu + Graphite + ELK

ក្រុមហ៊ុនរបស់ខ្ញុំពិតជាចូលចិត្តរបស់បង្ហោះដោយខ្លួនឯងខ្លាំង។

Sensu -> PagerDuty

Graphite/Grafana

ELK (Elasticsearch, Logstash, Kibana)

Prometheus + Alertmanager

Prometheus + Alertmanager សម្រាប់ការជូនដំណឹង ក្រុមរបស់ខ្ញុំជឿថាការត្រួតពិនិត្យសាមញ្ញគឺជាការត្រួតពិនិត្យល្អ។

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

Sensu + Grafana + Graylog + Kibana + NewRelic.

Sensu, grafana, graylog, kibana, newrelic។

Prometheus + Circonus

សេវាកម្មដែលបំពាក់ដោយ Prometheus => ការវិភាគ និងការបង្ហាញរបស់ Circonus

icinga2 + VictorOps + NewRelic + Sentry + Slack

យើងកំពុងប្រើសេវាកម្មខាងក្រោម៖

icinga2 សម្រាប់ការត្រួតពិនិត្យ និង VictorOps សម្រាប់ការជូនដំណឹង

NewRelic សម្រាប់ការត្រួតពិនិត្យលម្អិតនៃសេវាកម្ម

Sentry សម្រាប់ការតាមដានកំហុសក្នុងសេវាកម្ម

Slack/អ៊ីមែលជាផ្នែកនៃការជូនដំណឹងដែលបង្កពី NewRelic ឬ icinga2

AppDynamics + Papertrail + PagerDuty + Healthchecks.io + Stackdriver

AppDynamics

Papertrail

PagerDuty

Healthchecks.io

Stackdriver

icinga2 + elasticsearch

icinga2 ជាមួយការរួមបញ្ចូល elasticsearch សម្រាប់ការវិភាគ និងការរួមបញ្ចូល graphite+grafana សម្រាប់ក្រាហ្វ។

សូមអរគុណចំពោះភាពបត់បែននៃច្បាប់អនុវត្ត (apply rules) នៅក្នុង icinga2 អ្នកអភិវឌ្ឍន៍អាចឃើញតែសេវាកម្មដែលពួកគេទទួលបានការជូនដំណឹងប៉ុណ្ណោះ។

ហើយតាមរយៈ icinga2 director អ្នកសរសេរកម្មវិធីអាចកំណត់ការត្រួតពិនិត្យផ្ទាល់ខ្លួនបានយ៉ាងងាយ (ដែលពួកគេធ្វើរៀងរាល់ពីរបីថ្ងៃ - ការត្រួតពិនិត្យ 100 ចេញទៅ ការត្រួតពិនិត្យ 100 ផ្សេងទៀតចូលមក) ក្នុងទំហំធំដោយគ្មានការរំខាន។

DataDog + New Relic + ELK + EFK + Sentry + Alertmanager + VictorOps

អ្វីដែលយើងមានឥឡូវនេះ៖

DataDog សម្រាប់រង្វាស់

New Relic សម្រាប់ការត្រួតពិនិត្យកម្មវិធី

ELK (Elastic Search + Logstash + Kibana) សម្រាប់កំណត់ហេតុ

Sentry (បង្ហោះដោយខ្លួនឯង) សម្រាប់កត់ត្រាករណីលើកលែង

អ៊ីមែល + Slack + VictorOps សម្រាប់ការជូនដំណឹង (ផ្អែកលើភាពធ្ងន់ធ្ងរ)

អ្វីដែលយើងចង់មាន៖

Prometheus សម្រាប់រង្វាស់ (Grafana សម្រាប់ការបង្ហាញ)

New Relic (ប្រហែលជា Elastic Search APM) សម្រាប់ការត្រួតពិនិត្យកម្មវិធី

EFK (elastic search + fluentd + kibana) សម្រាប់ការកត់ត្រាកំណត់ហេតុ។ ប្រហែលជា Loki ដោយ Grafana នឹងរួចរាល់សម្រាប់ផលិតកម្មនៅពេលយើងមកដល់ទីនេះ

Sentry សម្រាប់ករណីលើកលែង

Alertmanager + អ៊ីមែល + VictorOps សម្រាប់ការជូនដំណឹង

Wavefront + Scalyr + PagerDuty + Stackstorm + Slack

Wavefront + Scalyr + PagerDuty + Stackstorm + Slack (ការបដិសេធ៖ ធ្វើការនៅ VMware)

Telegraf + Prometheus + InfluxDB + Grafana

Telegraf សម្រាប់រង្វាស់ម៉ាស៊ីនមេដូចជា CPU ថាស អង្គចងចាំ និងបណ្តាញ។ យើងក៏ប្រើ Telegraf សម្រាប់ការត្រួតពិនិត្យ SNMP នៃឧបករណ៍បណ្តាញរបស់យើង។

Prometheus សម្រាប់រង្វាស់កម្មវិធី។ យើងសរសេរកូដការត្រួតពិនិត្យសុខភាពក្នុងកម្មវិធីរបស់យើង ដែល Prometheus scrape។

InfluxDB សម្រាប់ការផ្ទុកស៊េរីពេលវេលា។ នេះគឺជាកន្លែងដែលទិន្នន័យ Telegraf របស់យើងត្រូវបានផ្ញើទៅ។

Grafana សម្រាប់ផ្ទាំងគ្រប់គ្រង និងការជូនដំណឹង។ ម៉ាស៊ីនជូនដំណឹងមិនរឹងមាំខ្លាំងទេ ប៉ុន្តែវាធ្វើការងារបាន។ យើងក៏បាញ់ការជូនដំណឹងចូល Slack ផងដែរ។

អ្វីដែលខ្ញុំមិនមានឥឡូវនេះគឺដំណោះស្រាយកត់ត្រាកំណត់ហេតុកណ្តាល។ ELK មានអានុភាព ប៉ុន្តែពិបាកដំឡើង និងគ្រប់គ្រង ហើយខ្ញុំមិនដឹងអំពីជម្រើសឥតគិតថ្លៃណាដែលជិតគ្រប់គ្រាន់ដើម្បីពិនិត្យទេ។

Sematext + Logagent + Experience

Sematext សម្រាប់រង្វាស់ សម្រាប់កំណត់ហេតុ សម្រាប់ការតាមដាន ឆាប់ៗនេះសម្រាប់ការត្រួតពិនិត្យអ្នកប្រើពិតប្រាកដផងដែរ។ សាមញ្ញជាង/ថោកជាងការប្រើឧបករណ៍/សេវាកម្មខុសគ្នា N តាមគំនិតរបស់ខ្ញុំ។

សម្រាប់ការដឹកជញ្ជូនកំណត់ហេតុ យើងធ្លាប់ប្រើ rsyslog ហើយបន្ទាប់មកយើងបានប្តូរទៅ Logagent។

សម្រាប់ការរាយការណ៍ការគាំងផ្នែកខាងមុខ យើងប្រើ Sentry ប៉ុន្តែយើងនឹងប្តូរទៅ Experience ក្នុងពេលឆាប់ៗនេះ។

ការបដិសេធ៖ ខ្ញុំជា Sematextan។

Azure Monitor/Analytics + OpsGenie

ខ្ញុំចង់ឱ្យ Log Analytics មានចំណុចប្រទាក់ល្អជាងនេះ។ យើងកំពុងងាកចេញពី splunk ដែលងាយស្រួលរុករកជាងច្រើន។

Prometheus + Alertmanager + Grafana + Splunk + PagerDuty

Prometheus, Alertmanager, Grafana, Splunk, PagerDuty

អ្នកពិតជាមិនចង់ដំណើរការប្រព័ន្ធជូនដំណឹងផ្ទាល់ខ្លួនទេ។ អ្នកអាចជំនួស Splunk ដោយ ELK លុះត្រាតែក្រុមសុវត្ថិភាពរបស់អ្នកចូលចិត្ត Splunk។

Telegraf + Prometheus + Grafana + Alertmanager

Telegraf ជាកម្មវិធីប្រមូល Prometheus + Alertmanager សម្រាប់ការត្រួតពិនិត្យ និងការជូនដំណឹង រួមបញ្ចូលជាមួយឆានែល slack និង pagerduty សម្រាប់ការជូនដំណឹងសំខាន់។ Grafana សម្រាប់ការបង្ហាញរង្វាស់ម៉ាស៊ីនម្ចាស់។

Prometheus + Grafana + Cloudwatch + sentry + kibana + elasticsearch

Prometheus សម្រាប់រង្វាស់ + ការជូនដំណឹង

Grafana សម្រាប់ផ្ទាំងគ្រប់គ្រង Prometheus

Cloudwatch ត្រួតពិនិត្យករណី Prometheus

sentry សម្រាប់ការតាមដានករណីលើកលែង

kibana + elasticsearch

graylog

prometheus Push Gateway សម្រាប់ batch/cronjobs

SOP https://github.com/rapidloop/sop ដើម្បី „push/forward“ រង្វាស់ពីករណី Prometheus មួយទៅមួយទៀត

អតិថិជនប្រើកម្មវិធីអតិថិជន Prometheus។ យើងព្យាយាមប្រើ opencensus.io នៅផ្នែកអតិថិជន

PagerDuty + Monitis

PagerDuty + Monitis។ ព្រមទាំង Azure Functions ផ្ទាល់ខ្លួនមួយចំនួនសម្រាប់សាកល្បងសុខភាពនៃសេវាកម្មមួយចំនួន។

កំពុងរកមើលការណែនាំ Prometheus និង Grafana ឆ្នាំនេះ

Prometheus + Grafana + Bosun

Prometheus សម្រាប់ផ្ទុកទិន្នន័យស៊េរីពេលវេលា។ Grafana សម្រាប់ការបង្ហាញ។ Bosun សម្រាប់ការគ្រប់គ្រងការជូនដំណឹង។

Azure Monitor/Analytics/Insights/Dashboards

ហាងដែលប្រើតែ Azure, Azure Monitor, Log Analytics, App Insights, Azure Dashboards + Pager Duty

Grafana + Monitis + OpsGenie + Slack

Grafana សម្រាប់ត្រួតពិនិត្យសេវាកម្មកុងតឺន័រក្នុង Kubernetes តាមរយៈ Prometheus

Monitis សម្រាប់ការត្រួតពិនិត្យសេវាកម្មពីចុងដល់ចុង ជាចម្បងសម្រាប់ API គេហទំព័រ និងកម្មវិធីគេហទំព័រ

OpsGenie សម្រាប់ការគ្រប់គ្រងការជូនដំណឹង

Slack សម្រាប់ទទួលព័ត៌មានស្ថានភាពពីប្រព័ន្ធរបស់យើង

Checkly + AppOptics + Cloudwatch + Heroku + Pagerduty + Papertrail

វិស្វករ (dev)ops រយៈពេលយូរនៅទីនេះ។ ធំធាត់ជាមួយ Nagios។ ចង់បានមតិអំពី SaaS ដែលខ្ញុំបង្កើតដោយខ្លួនឯង https://checklyhq.com។ យើងធ្វើការត្រួតពិនិត្យ API និងការត្រួតពិនិត្យប្រតិបត្តិការគេហទំព័រ ជាមួយការជូនដំណឹងស៊ីជម្រៅគួរសម។

ខ្ញុំបានចាប់ផ្តើម Checkly ព្រោះការត្រួតពិនិត្យសកម្ម / សំយោគក្នុងលំហ API មានកំណត់បន្តិច (និងថ្លៃ)។ ការត្រួតពិនិត្យផ្អែកលើកម្មវិធីរុករក / ផ្អែកលើស្គ្រីបគឺកម្មសិទ្ធិច្រើនជាង និងថ្លៃជាងទៀត។ យើងប្រើ Puppeteer ហើយរក្សាតម្លៃឱ្យទាបតាមដែលអាចធ្វើបាន។

ជង់ត្រួតពិនិត្យរបស់យើង៖

Checkly (dog fooding...)

AppOptics (ក្រាហ្វផ្ទាល់ខ្លួន)

AWS Cloudwatch និង SNS សម្រាប់សារ SMS។

ការជូនដំណឹង Heroku ភ្ជាប់មកស្រាប់។

Pagerduty

Papertrail

Instana + Logz.io + slack

Instana ជូនដំណឹងយើងក្នុង slack អំពីបញ្ហាហេដ្ឋារចនាសម្ព័ន្ធ ឬការធ្លាក់ចុះប្រសិទ្ធភាព ហើយយើងបានកំណត់រចនាសម្ព័ន្ធ logz.io ឱ្យជូនដំណឹងក្នុង slack លើបរិមាណជាក់លាក់នៃកំណត់ហេតុកម្រិតកំហុសពីស្រទាប់កម្មវិធី។

SignalFX + Splunk + PagerDuty + Slack

បច្ចុប្បន្នកំពុងប្រើ៖ SignalFX, Splunk, PagerDuty និង Slack។ ខ្ញុំមិនមែនជាអ្នកគាំទ្រធំរបស់ SignalFX ទេ ទោះបីក្រុមគាំទ្ររបស់ពួកគេរួសរាយរាក់ទាក់ និងឆ្លើយតបលឿនខ្លាំងក៏ដោយ។ ខ្ញុំចូលចិត្ត Splunk (សមនឹងតម្លៃប្រសិនបើអ្នកអាចបង់បាន) PagerDuty និង Slack។

ខ្ញុំធ្លាប់ប្រើជង់ TICK ដែល C ភាគច្រើនពិតជា G ពោលគឺ Grafana ទោះបីខ្ញុំបានប្រើ Chronograf បន្តិចក៏ដោយ។ នោះអស្ចារ្យ ប៉ុន្តែពិបាកគ្រប់គ្រង។ ភាពចង្អៀតចង្អល់បុរាណរវាង SaaS ប្រឆាំងនឹងការបង្ហោះដោយខ្លួនឯង។

ខ្ញុំធ្លាប់ប្រើ DataDog, New Relic, Graylog, ELK និង BugSnag។ ខ្ញុំចូលចិត្ត DataDog និង New Relic ច្រើន Graylog ល្អគួរសម។ ខ្ញុំមិនមែនជាអ្នកគាំទ្រធំរបស់ ELK ទេ។ BugSnag ល្អ ខ្ញុំពិតជាមានអារម្មណ៍ថាការតាមដានកំហុស/ករណីលើកលែងគឺជាអ្នកជំនួសដ៏ល្អសម្រាប់ការត្រួតពិនិត្យកំណត់ហេតុពេញលេញ ក្នុងករណីជាច្រើន។

ELK + Prometheus + Grafana

ដូចអ្នកដទៃដែរ យើងប្រើ ELK សម្រាប់កំណត់ហេតុ និង Prometheus+Grafana សម្រាប់អ្វីៗផ្សេងទៀតទាំងអស់។

ការថែទាំការដំឡើងនេះងាយស្រួល ប្រសិនបើអ្នកអនុញ្ញាតឱ្យខ្លួនអ្នកបាត់បង់ទិន្នន័យម្តងម្កាល។ ឧទាហរណ៍ ប្រសិនបើមូលដ្ឋានទិន្នន័យ ElasticSearch របស់យើងធ្លាក់ក្នុងស្ថានភាពអាក្រក់ (ដែលសម្រាប់យើងគួរឱ្យស្តាយកើតឡើងរៀងរាល់ 2-3 ខែ) យើងមិនខ្វល់ជាមួយ HA ទេ ហើយជំនួសមកវិញយើងទម្លាក់ទិន្នន័យ ហើយបន្តជីវិតរបស់យើង។ ប្រសិនបើអ្នកត្រូវតែមាន HA ឬការរក្សាទុករយៈពេលវែងជាដាច់ខាត សូមសំណាងល្អ។

Datadog + Prometheus + Grafana

ខ្ញុំបានដំឡើង Datadog លើមូលដ្ឋានខែទៅខែ ព្រោះនៅពេលខ្ញុំមកដល់ទីនេះ គ្មានការត្រួតពិនិត្យ និងគ្មានការជូនដំណឹងទេ។ មានតែគេហទំព័រមួយចំនួនប៉ុណ្ណោះដែលត្រូវបានត្រួតពិនិត្យរៀងរាល់ 5 នាទីសម្រាប់ពេលវេលាដំណើរការ។ Datadog ងាយស្រួលដំឡើងបំផុតដោយគ្មានជម្លោះ។ នៅពេលខ្ញុំបញ្ចប់ការដោះស្រាយបញ្ហាផ្សេងទៀតទាំងអស់ ខ្ញុំនឹងប្តូរទៅ Prometheus+Grafana។ មិនទាន់សម្រេច 100% លើការគ្រប់គ្រងកំណត់ហេតុនៅឡើយទេ។

Nagios + ELK

យើងមានផលិតផលជាង 100+ ដែលយើងគាំទ្រ។

សម្រាប់ on-prem ភាគច្រើនគឺ Nagios និង ELK។ សម្រាប់ពពក យើងកំពុងផ្លាស់ប្តូរពី DataDog ទៅ NewRelic។

Datadog ប្រៀបធៀប Site24x7 + StatusCake + PagerDuty + SumoLogic + Slack

យើងធ្លាប់ប្រើ datadog ប៉ុន្តែបានរកឃើញថាវាថ្លៃពេកសម្រាប់តម្រូវការរបស់យើង។ កុំយល់ខុស វាអស្ចារ្យ ប៉ុន្តែវាមានថ្លៃដើមដ៏ធំ។ យើងអាចដំឡើង site24x7.com ជាមួយការជាវប្រចាំឆ្នាំក្នុងតម្លៃប្រហែល 2-3 ខែនៃថ្លៃដើមពី DD។

ជង់ត្រួតពិនិត្យរបស់យើង៖

Site24x7 - APM ការត្រួតពិនិត្យ URL ខាងក្រៅ ការត្រួតពិនិត្យលំហូរសារ SMTP ការផុតកំណត់ ssl និងការត្រួតពិនិត្យដំណើរការ។

StatusCake - សម្រាប់ការត្រួតពិនិត្យ និងការបញ្ជាក់ URL - វាជាការបម្រុងទុករបស់យើងក្នុងករណីដែល site24x7 ខកខានអ្វីមួយ (វាមិនខកខានទេ) ប៉ុន្តែ SC បត់បែនជាងសម្រាប់ការត្រួតពិនិត្យច្រកខាងក្រៅ និងសេវាកម្មសម្រាប់តម្រូវការរបស់យើង។

ឧបករណ៍ទាំងពីរបញ្ជូនបន្តទៅ PagerDuty ហើយបន្ទាប់មកយើងទទួលបានការបញ្ជូនបន្តរបស់យើងក្នុង slack។

SumoLogic - សម្រាប់ការត្រួតពិនិត្យកំណត់ហេតុ (វាជាឧបករណ៍ដ៏ល្អ ប៉ុន្តែស្មុគស្មាញបន្តិចសម្រាប់តម្រូវការរបស់យើង)

ពី slack យើងអាចទទួលស្គាល់ ឬដោះស្រាយការជូនដំណឹង។

បន្ទាប់មកយើងមានស្វ័យប្រវត្តិកម្ម site24x7 ជាច្រើនដែលភ្ជាប់ទៅ commando.io សម្រាប់ ‘BedOps’ ដូចដែលយើងហៅ - ដែលការជូនដំណឹងត្រូវបានបង្ក យើងចាប់ផ្តើមស្គ្រីប ឬស្វ័យប្រវត្តិកម្មពីរបីជាការព្យាយាមដោះស្រាយស្ថានភាព (99% នៃពេលវេលា ស្វ័យប្រវត្តិកម្ម + ស្គ្រីបរបស់យើងរក្សាយើងឱ្យផុតពីបញ្ហា)

យើងមានសៀវភៅដំណើរការផ្ទៃក្នុងក្នុង KB របស់យើង សម្រាប់ពេលដែលស្វ័យប្រវត្តិកម្មបរាជ័យ ឬប្រសិនបើមានអ្វីមួយក្រៅវិសាលភាពដែលត្រូវជួសជុល។

Prometheus + AlertManager + Grafana + Stackdriver

Prometheus (Operator) / AlertManager / Grafana សម្រាប់រង្វាស់ក្នុងចង្កោម GKE និង VM របស់យើង។

Google Stackdriver សម្រាប់កំណត់ហេតុ (ព្រោះវារួមបញ្ចូល និងសកម្មតាមលំនាំដើម ហើយបច្ចុប្បន្នគ្រប់គ្រាន់សម្រាប់តម្រូវការរបស់យើង)។

Zabbix

Zabbix សម្រាប់គ្រប់យ៉ាង។ មិនត្រូវការកម្មវិធីបន្ថែមទេ។