របៀបដែលយើងបង្កើតការត្រួតពិនិត្យនៅលើ Prometheus, Clickhouse និង ELK

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

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

អំពីគម្រោង

គម្រោងនេះគឺជាកម្មវិធីភក្ដីភាពដ៏ធំបំផុតមួយនៅក្នុងប្រទេស។ យើងជួយសង្វាក់លក់រាយបង្កើនភាពញឹកញាប់នៃការលក់តាមរយៈឧបករណ៍ទីផ្សារផ្សេងៗដូចជាប័ណ្ណប្រាក់រង្វាន់។ សរុបមក គម្រោងនេះមានកម្មវិធីចំនួន 14 ដែលដំណើរការលើម៉ាស៊ីនមេចំនួន XNUMX ។

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

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

លើសពីនេះទៀតមានការយល់ច្បាស់អំពីភាពឥតប្រយោជន៍នៃការអភិវឌ្ឍន៍បន្ថែមទៀតរបស់វា។ ខ្ញុំគិតថាអ្នកដែលស្គាល់ Icinga នឹងយល់ពីខ្ញុំ។ ដូច្នេះ យើងបានសម្រេចចិត្តរៀបចំឡើងវិញទាំងស្រុងនូវប្រព័ន្ធត្រួតពិនិត្យកម្មវិធីគេហទំព័រសម្រាប់គម្រោង។

Prometheus

យើងបានជ្រើសរើស Prometheus ដោយផ្អែកលើសូចនាករសំខាន់ៗចំនួនបី៖

1. ចំនួនដ៏ធំនៃម៉ែត្រដែលមាន។ ក្នុងករណីរបស់យើងមាន 60 ពាន់នាក់។ ជាការពិតណាស់ វាគួរឱ្យកត់សម្គាល់ថាយើងមិនប្រើភាគច្រើននៃពួកគេ (ប្រហែល 95%) ។ ម្យ៉ាងវិញទៀត ពួកវាទាំងអស់មានតម្លៃថោកសមរម្យ។ សម្រាប់ពួកយើង នេះគឺខ្លាំងជាងគេ បើធៀបនឹង Icinga ដែលធ្លាប់ប្រើពីមុន។ នៅក្នុងវា ការបន្ថែមម៉ែត្រគឺជាការឈឺចាប់ជាក់លាក់មួយ៖ របស់ដែលមានស្រាប់មានតម្លៃថ្លៃ (គ្រាន់តែមើលកូដប្រភពនៃកម្មវិធីជំនួយណាមួយ)។ កម្មវិធីជំនួយណាមួយគឺជាស្គ្រីបនៅក្នុង Bash ឬ Python ដែលជាការបើកដំណើរការដែលមានតម្លៃថ្លៃទាក់ទងនឹងធនធានដែលប្រើប្រាស់។
2. ប្រព័ន្ធនេះប្រើប្រាស់ធនធានតិចតួច។ 600 MB នៃ RAM, 15% នៃស្នូលមួយ និង IOPS ពីរបីដប់គឺគ្រប់គ្រាន់សម្រាប់ម៉ែត្ររបស់យើងទាំងអស់។ ជាការពិតណាស់ អ្នកត្រូវតែដំណើរការអ្នកនាំចេញម៉ែត្រ ប៉ុន្តែពួកវាទាំងអស់ត្រូវបានសរសេរនៅក្នុង Go ហើយក៏មិនឃ្លានខ្លាំងដែរ។ ខ្ញុំ​មិន​គិត​ថា​ក្នុង​ការពិត​ទំនើប​នេះ​ជា​បញ្ហា​ទេ។
3. ផ្តល់លទ្ធភាពធ្វើចំណាកស្រុកទៅ Kubernetes ។ ដោយពិចារណាលើផែនការរបស់អតិថិជន ជម្រើសគឺជាក់ស្តែង។

ELK

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

ផ្ទះស្លីក

ដំបូងជម្រើសបានធ្លាក់លើ InfluxDB ។ យើងបានដឹងពីតម្រូវការក្នុងការប្រមូលកំណត់ហេតុ Nginx ស្ថិតិពី pg_stat_statements និងរក្សាទុកទិន្នន័យប្រវត្តិសាស្ត្រ Prometheus ។ យើងមិនចូលចិត្ត Influx ទេ ព្រោះវាចាប់ផ្តើមប្រើប្រាស់អង្គចងចាំច្រើន និងគាំងជាប្រចាំ។ លើសពីនេះ ខ្ញុំចង់ដាក់ជាក្រុមសំណួរដោយ remote_addr ប៉ុន្តែការដាក់ជាក្រុមនៅក្នុង DBMS នេះគឺគ្រាន់តែដោយស្លាកប៉ុណ្ណោះ។ ស្លាកមានតម្លៃថ្លៃ (អង្គចងចាំ) ចំនួនរបស់ពួកគេត្រូវបានកំណត់តាមលក្ខខណ្ឌ។

យើងបានចាប់ផ្តើមការស្វែងរករបស់យើងម្តងទៀត។ អ្វី​ដែល​ត្រូវ​ការ​គឺ​មូលដ្ឋាន​ទិន្នន័យ​វិភាគ​ដែល​មាន​ការ​ប្រើ​ប្រាស់​ធនធាន​តិច​បំផុត​ ជា​ជម្រើស​ជាមួយ​នឹង​ការ​បង្ហាប់​ទិន្នន័យ​លើ​ថាស។

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

ញូអរលែល

NewRelic បាននៅជាមួយយើងជាប្រវត្តិសាស្ត្រព្រោះវាជាជម្រើសរបស់អតិថិជន។ យើងប្រើវាជា APM ។

Zabbix

យើងប្រើ Zabbix ទាំងស្រុងដើម្បីត្រួតពិនិត្យប្រអប់ខ្មៅនៃ APIs ផ្សេងៗ។

ការកំណត់វិធីសាស្រ្តត្រួតពិនិត្យ

យើងចង់បំបែកកិច្ចការនេះ ហើយដោយហេតុនេះរៀបចំជាប្រព័ន្ធនូវវិធីសាស្រ្តក្នុងការត្រួតពិនិត្យ។

ដើម្បីធ្វើដូចនេះខ្ញុំបានបែងចែកប្រព័ន្ធរបស់យើងទៅជាកម្រិតដូចខាងក្រោម:

• ផ្នែករឹង និង VMS;
• ប្រព័ន្ធ​ប្រតិបត្តិការ;
• សេវាកម្មប្រព័ន្ធ ជង់កម្មវិធី;
• កម្មវិធី;
• តក្កវិជ្ជាអាជីវកម្ម។

ហេតុអ្វីបានជាវិធីសាស្រ្តនេះគឺងាយស្រួល:

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

ដោយសារភារកិច្ចរបស់យើងគឺដើម្បីកំណត់អត្តសញ្ញាណការបំពាននៅក្នុងប្រតិបត្តិការនៃប្រព័ន្ធ យើងត្រូវនៅកម្រិតនីមួយៗបញ្ជាក់ពីសំណុំរង្វាស់ជាក់លាក់ដែលគួរយកចិត្តទុកដាក់នៅពេលសរសេរច្បាប់ជូនដំណឹង។ បន្ទាប់​មក យើង​ចូល​ទៅ​តាម​កម្រិត “VMS” “ប្រព័ន្ធ​ប្រតិបត្តិការ” និង “សេវា​ប្រព័ន្ធ ជង់​កម្មវិធី”។

ម៉ាស៊ីននិម្មិត

Hosting បែងចែកយើងនូវ processor, disk, memory និង network។ ហើយយើងមានបញ្ហាជាមួយពីរដំបូង។ ដូច្នេះម៉ែត្រ៖

ពេលវេលាលួចស៊ីភីយូ - នៅពេលអ្នកទិញម៉ាស៊ីននិម្មិតនៅលើ Amazon (ឧទាហរណ៍ t2.micro) អ្នកគួរតែយល់ថាអ្នកមិនត្រូវបានបែងចែកស្នូលដំណើរការទាំងមូលទេ ប៉ុន្តែមានតែកូតានៃពេលវេលារបស់វាប៉ុណ្ណោះ។ ហើយនៅពេលអ្នកហត់នឿយវា ខួរក្បាលនឹងត្រូវដកចេញពីអ្នក។

ម៉ែត្រនេះអនុញ្ញាតឱ្យអ្នកតាមដានគ្រាបែបនេះ និងធ្វើការសម្រេចចិត្ត។ ឧទាហរណ៍ តើចាំបាច់ត្រូវយកពន្ធដារ ឬចែកចាយដំណើរការនៃកិច្ចការផ្ទៃខាងក្រោយ និងសំណើ API ទៅកាន់ម៉ាស៊ីនមេផ្សេងៗទេ?

IOPS + CPU iowait time - សម្រាប់ហេតុផលមួយចំនួន cloud hosting ជាច្រើនមានបាបដោយការមិនផ្តល់ IOPS គ្រប់គ្រាន់។ លើសពីនេះទៅទៀត កាលវិភាគដែលមាន IOPS ទាបមិនមែនជាអាគុយម៉ង់សម្រាប់ពួកគេទេ។ ដូច្នេះវាមានតម្លៃក្នុងការប្រមូល CPU iowait ។ ជាមួយនឹងក្រាហ្វិកគូនេះ - ជាមួយ IOPS ទាប និងការរង់ចាំ I/O ខ្ពស់ - អ្នកអាចនិយាយជាមួយ hosting និងដោះស្រាយបញ្ហារួចហើយ។

ប្រព័ន្ធប្រតិបត្តិការ

រង្វាស់ប្រព័ន្ធប្រតិបត្តិការ៖

• ចំនួនអង្គចងចាំដែលមានក្នុង %;
• សកម្មភាពប្រើប្រាស់ swap៖ vmstat swapin, swapout;
• ចំនួនអ៊ីណូដដែលមាន និងទំហំទំនេរនៅលើប្រព័ន្ធឯកសារក្នុង %
• បន្ទុកមធ្យម;
• ចំនួននៃការតភ្ជាប់នៅក្នុងរដ្ឋ tw;
• គ្រប់គ្រងភាពពេញលេញនៃតារាង;
• គុណភាពនៃបណ្តាញអាចត្រូវបានត្រួតពិនិត្យដោយប្រើឧបករណ៍ប្រើប្រាស់ ss កញ្ចប់ iproute2 - ទទួលបានសូចនាករនៃការតភ្ជាប់ RTT ពីលទ្ធផលរបស់វា ហើយដាក់ជាក្រុមតាមច្រក dest ។

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

សំណុំរង្វាស់មានដូចខាងក្រោម៖

• ស៊ីភីយូ;
• ការចងចាំមានទីលំនៅជាចម្បង;
• IO - និយមនៅក្នុង IOPS;
• FileFd - បើកនិងកំណត់;
• ការបរាជ័យទំព័រសំខាន់ៗ - វិធីនេះអ្នកអាចយល់ពីដំណើរការដែលកំពុងត្រូវបានផ្លាស់ប្តូរ។

យើងដាក់ពង្រាយការត្រួតពិនិត្យទាំងអស់នៅក្នុង Docker យើងប្រើ Advisor ដើម្បីប្រមូលទិន្នន័យម៉ែត្រ។ នៅលើម៉ាស៊ីនផ្សេងទៀត យើងប្រើ process-exporter។

សេវាកម្មប្រព័ន្ធ ជង់កម្មវិធី

កម្មវិធីនីមួយៗមានភាពជាក់លាក់របស់វា ហើយវាពិបាកក្នុងការដាក់ចេញនូវសំណុំរង្វាស់ជាក់លាក់មួយ។

សំណុំសកលគឺ៖

• អត្រាការស្នើសុំ;
• ចំនួននៃកំហុស;
• ភាពយឺតយ៉ាវ;
• តិត្ថិភាព។

ឧទាហរណ៍ដ៏គួរឱ្យចាប់អារម្មណ៍បំផុតរបស់យើងនៃការត្រួតពិនិត្យនៅកម្រិតនេះគឺ Nginx និង PostgreSQL ។

សេវាផ្ទុកច្រើនបំផុតនៅក្នុងប្រព័ន្ធរបស់យើងគឺ មូលដ្ឋានទិន្នន័យ។ កាលពីមុន យើងច្រើនតែមានបញ្ហាក្នុងការស្វែងរកអ្វីដែលមូលដ្ឋានទិន្នន័យកំពុងធ្វើ។

យើងបានឃើញការផ្ទុកខ្ពស់នៅលើថាស ប៉ុន្តែកំណត់ហេតុយឺតៗពិតជាមិនបង្ហាញអ្វីនោះទេ។ យើងបានដោះស្រាយបញ្ហានេះដោយប្រើ pg_stat_statements ដែលជាទិដ្ឋភាពដែលប្រមូលស្ថិតិសំណួរ។

នោះហើយជាតម្រូវការរបស់ Admin

យើងបង្កើតក្រាហ្វនៃសកម្មភាពនៃការស្នើសុំអាន និងសរសេរ៖

អ្វីគ្រប់យ៉ាងគឺសាមញ្ញនិងច្បាស់លាស់សំណើនីមួយៗមានពណ៌ផ្ទាល់ខ្លួនរបស់វា។

ឧទាហរណ៍គួរឱ្យចាប់អារម្មណ៍ដូចគ្នាគឺកំណត់ហេតុ Nginx ។ វាមិនមែនជារឿងគួរឱ្យភ្ញាក់ផ្អើលទេដែលមានមនុស្សតិចណាស់ដែលញែកពួកវា ឬរៀបរាប់ពួកវានៅក្នុងបញ្ជីដែលត្រូវតែមាន។ ទម្រង់ស្ដង់ដារមិនមានព័ត៌មានច្រើនទេ ហើយត្រូវការពង្រីក។

ដោយផ្ទាល់ ខ្ញុំបានបន្ថែម request_time, upstream_response_time, body_bytes_sent, request_length, request_id។ យើងរៀបចំពេលវេលាឆ្លើយតប និងចំនួននៃកំហុស៖

យើងបង្កើតក្រាហ្វនៃពេលវេលាឆ្លើយតប និងចំនួននៃកំហុស។ ចាំទេ? តើខ្ញុំនិយាយអំពីកិច្ចការជំនួញទេ? លឿននិងគ្មានកំហុស? យើងបានគ្របដណ្តប់បញ្ហាទាំងនេះរួចហើយជាមួយនឹងតារាងពីរ។ ហើយ​អ្នក​អាច​ហៅ​ទៅ​អ្នក​គ្រប់គ្រង​ដែល​មាន​កាតព្វកិច្ច​ដោយ​ប្រើ​វា​រួច​ហើយ។

ប៉ុន្តែបញ្ហាមួយទៀតនៅតែមាន - ដើម្បីធានាបាននូវការលុបបំបាត់យ៉ាងឆាប់រហ័សនៃមូលហេតុនៃឧប្បត្តិហេតុ។

ដំណោះស្រាយឧប្បត្តិហេតុ

ដំណើរការទាំងមូលចាប់ពីការកំណត់អត្តសញ្ញាណរហូតដល់ការដោះស្រាយបញ្ហាអាចបែងចែកជាជំហានមួយចំនួន៖

• កំណត់អត្តសញ្ញាណបញ្ហា;
• ការជូនដំណឹងដល់អ្នកគ្រប់គ្រងកាតព្វកិច្ច;
• ការឆ្លើយតបទៅនឹងឧប្បត្តិហេតុមួយ;
• ការលុបបំបាត់បុព្វហេតុ។

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

សាកស្រមៃទៅមើលថា ទូរស័ព្ទរបស់មន្ត្រីទទួលបន្ទុកបានរោទិ៍ឡើង។ តើគាត់នឹងធ្វើអ្វី? រកមើលចម្លើយចំពោះសំណួរ - តើអ្វីបានបែកបាក់, កន្លែងណាដែលវាបែក, របៀបប្រតិកម្ម? នេះជារបៀបដែលយើងឆ្លើយសំណួរទាំងនេះ៖

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

ខ្ញុំនៅតែមិនទាន់បាននិយាយអ្វីអំពីស្រទាប់កម្មវិធី និងតក្កវិជ្ជាអាជីវកម្មទេ។ ជាអកុសល កម្មវិធីរបស់យើងមិនទាន់អនុវត្តការប្រមូលម៉ែត្រទេ។ ប្រភពតែមួយគត់នៃព័ត៌មានពីកម្រិតទាំងនេះគឺកំណត់ហេតុ។

ពីរបីចំណុច។

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

ទីពីរ ប្រើកម្រិតនៃភាពធ្ងន់ធ្ងរឱ្យបានត្រឹមត្រូវ។ ភាសានីមួយៗមានស្តង់ដារផ្ទាល់ខ្លួន។ ដោយផ្ទាល់ខ្ញុំបែងចែកបួនកម្រិត:

1. គ្មានកំហុស;
2. កំហុសខាងអតិថិជន;
3. កំហុសគឺនៅខាងយើង យើងមិនបាត់បង់លុយ យើងមិនប្រឈមនឹងហានិភ័យ។
4. កំហុសគឺនៅខាងយើង ខាតលុយ។

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

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

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

ការវាស់វែងប្រព័ន្ធប្រតិបត្តិការគឺពិតជាមានសារៈសំខាន់ ប៉ុន្តែអាជីវកម្មមិនចាប់អារម្មណ៍នឹងពួកគេទេ យើងមិនត្រូវបានបង់សម្រាប់ពួកគេទេ។

ប្រភព: www.habr.com