របៀបដែលយើងនៅ CIAN បាន tamed terabytes នៃកំណត់ហេតុ

ជំរាបសួរអ្នកទាំងអស់គ្នា ខ្ញុំឈ្មោះ Alexander ខ្ញុំធ្វើការនៅ CIAN ជាវិស្វករ ហើយខ្ញុំចូលរួមក្នុងការគ្រប់គ្រងប្រព័ន្ធ និងស្វ័យប្រវត្តិកម្មនៃដំណើរការហេដ្ឋារចនាសម្ព័ន្ធ។ នៅក្នុងមតិយោបល់ចំពោះអត្ថបទមុនមួយ យើងត្រូវបានគេសួរឱ្យប្រាប់កន្លែងដែលយើងទទួលបាន 4 TB នៃកំណត់ហេតុក្នុងមួយថ្ងៃ និងអ្វីដែលយើងធ្វើជាមួយពួកគេ។ បាទ យើងមានកំណត់ហេតុជាច្រើន ហើយចង្កោមហេដ្ឋារចនាសម្ព័ន្ធដាច់ដោយឡែកត្រូវបានបង្កើតឡើង ដើម្បីដំណើរការពួកវា ដែលអនុញ្ញាតឱ្យយើងដោះស្រាយបញ្ហាបានយ៉ាងឆាប់រហ័ស។ នៅក្នុងអត្ថបទនេះ ខ្ញុំនឹងនិយាយអំពីរបៀបដែលយើងសម្របខ្លួនវាក្នុងរយៈពេលមួយឆ្នាំ ដើម្បីធ្វើការជាមួយលំហូរនៃទិន្នន័យដែលមិនធ្លាប់មាន។

តើយើងចាប់ផ្តើមនៅឯណា?

ក្នុងរយៈពេលប៉ុន្មានឆ្នាំចុងក្រោយនេះ ការផ្ទុកនៅលើ cian.ru បានកើនឡើងយ៉ាងឆាប់រហ័ស ហើយនៅត្រីមាសទី 2018 នៃឆ្នាំ 11.2 ចរាចរណ៍ធនធានបានឈានដល់អ្នកប្រើប្រាស់ 40 លាននាក់ក្នុងមួយខែ។ នៅពេលនោះ នៅគ្រាដ៏សំខាន់ យើងបានបាត់បង់រហូតដល់ XNUMX% នៃកំណត់ហេតុ ដែលនេះជាមូលហេតុដែលយើងមិនអាចដោះស្រាយឧប្បត្តិហេតុបានឆាប់រហ័ស ហើយបានចំណាយពេលវេលា និងកិច្ចខិតខំប្រឹងប្រែងជាច្រើនដើម្បីដោះស្រាយវា។ ជារឿយៗយើងក៏មិនអាចរកឃើញមូលហេតុនៃបញ្ហាដែរ ហើយវានឹងកើតឡើងវិញបន្ទាប់ពីពេលខ្លះ។ វាជាឋាននរក ហើយមានអ្វីមួយដែលត្រូវធ្វើអំពីវា។

នៅពេលនោះ យើងបានប្រើចង្កោមនៃថ្នាំងទិន្នន័យ 10 ជាមួយ ElasticSearch កំណែ 5.5.2 ជាមួយនឹងការកំណត់សន្ទស្សន៍ស្តង់ដារដើម្បីរក្សាទុកកំណត់ហេតុ។ វាត្រូវបានណែនាំកាលពីជាងមួយឆ្នាំមុនថាជាដំណោះស្រាយដ៏ពេញនិយមនិងមានតម្លៃសមរម្យ៖ បន្ទាប់មកលំហូរនៃកំណត់ហេតុមិនមានទំហំធំទេ វាគ្មានចំណុចណាមួយក្នុងការមកជាមួយការកំណត់ដែលមិនមែនជាស្តង់ដារនោះទេ។ 

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

បញ្ហាប្រឈមនៃកំណើនយ៉ាងឆាប់រហ័ស

បរិមាណនៃកំណត់ហេតុដែលបានបង្កើតបានកើនឡើងយ៉ាងឆាប់រហ័ស ដោយសារដំណើរការពីរជាន់គ្នាជាមួយគ្នា។ ម៉្យាងវិញទៀត ចំនួនអ្នកប្រើប្រាស់សេវាបានកើនឡើង។ ម៉្យាងវិញទៀត យើងបានចាប់ផ្តើមប្តូរយ៉ាងសកម្មទៅស្ថាបត្យកម្មមីក្រូសេវាកម្ម ដោយឃើញមាន monoliths ចាស់ៗរបស់យើងនៅក្នុង C# និង Python ។ សេវាមីក្រូថ្មីជាច្រើនដែលជំនួសផ្នែកនៃ monolith បានបង្កើតកំណត់ហេតុបន្ថែមទៀតសម្រាប់ចង្កោមហេដ្ឋារចនាសម្ព័ន្ធ។ 

វាត្រូវបានធ្វើមាត្រដ្ឋានដែលនាំយើងទៅដល់ចំណុចដែលចង្កោមមិនអាចគ្រប់គ្រងបាន។ នៅពេលដែលកំណត់ហេតុចាប់ផ្តើមមកដល់ក្នុងអត្រា 20 ពាន់សារក្នុងមួយវិនាទី ការបង្វិលឥតប្រយោជន៍ញឹកញាប់បានបង្កើនចំនួន shards ដល់ 6 ពាន់ ហើយមានច្រើនជាង 600 shards ក្នុងមួយ node ។ 

នេះនាំឱ្យមានបញ្ហាជាមួយការបែងចែក RAM ហើយនៅពេលដែលថ្នាំងមួយគាំង បន្ទះទាំងអស់ចាប់ផ្តើមផ្លាស់ទីក្នុងពេលដំណាលគ្នា គុណនឹងចរាចរណ៍ និងការផ្ទុកថ្នាំងផ្សេងទៀត ដែលធ្វើឱ្យវាស្ទើរតែមិនអាចសរសេរទិន្នន័យទៅចង្កោមបាន។ ហើយក្នុងអំឡុងពេលនេះយើងត្រូវបានទុកចោលដោយគ្មានកំណត់ហេតុ។ ហើយប្រសិនបើមានបញ្ហាជាមួយម៉ាស៊ីនមេ យើងបាត់បង់ 1/10 នៃចង្កោមជាមូលដ្ឋាន។ សន្ទស្សន៍តូចៗមួយចំនួនធំបានបន្ថែមភាពស្មុគស្មាញ។

បើគ្មានកំណត់ហេតុ យើងមិនយល់ពីមូលហេតុនៃឧបទ្ទវហេតុនេះទេ ហើយមិនយូរមិនឆាប់អាចឈានជើងលើតុងទីនដដែលម្តងទៀត ហើយនៅក្នុងមនោគមវិជ្ជានៃក្រុមរបស់យើង នេះគឺមិនអាចទទួលយកបានទេ ដោយសារយន្តការការងាររបស់យើងទាំងអស់ត្រូវបានរចនាឡើងដើម្បីធ្វើផ្ទុយពីនេះ - កុំធ្វើម្តងទៀត។ បញ្ហាដូចគ្នា។ ដើម្បីធ្វើដូច្នេះ យើងត្រូវការបរិមាណពេញលេញនៃកំណត់ហេតុ និងការចែកចាយរបស់វាស្ទើរតែក្នុងពេលវេលាជាក់ស្តែង ដោយសារក្រុមវិស្វករដែលបំពេញកាតព្វកិច្ចបានត្រួតពិនិត្យការជូនដំណឹងមិនត្រឹមតែពីម៉ែត្រប៉ុណ្ណោះទេប៉ុន្តែក៏មកពីកំណត់ហេតុផងដែរ។ ដើម្បីយល់ពីមាត្រដ្ឋាននៃបញ្ហា នៅពេលនោះបរិមាណសរុបនៃកំណត់ហេតុគឺប្រហែល 2 TB ក្នុងមួយថ្ងៃ។ 

យើងបានកំណត់គោលដៅដើម្បីលុបបំបាត់ការបាត់បង់កំណត់ហេតុទាំងស្រុង និងកាត់បន្ថយពេលវេលានៃការចែកចាយរបស់ពួកគេទៅកាន់ចង្កោម ELK ដល់អតិបរមា 15 នាទីក្នុងអំឡុងពេលមហាអស្ចារ្យ (ក្រោយមកយើងពឹងផ្អែកលើតួលេខនេះជា KPI ផ្ទៃក្នុង) ។

យន្តការបង្វិលថ្មី និងថ្នាំងក្តៅ-ក្តៅ

យើងបានចាប់ផ្តើមការបំប្លែងចង្កោមដោយធ្វើបច្ចុប្បន្នភាពកំណែ ElasticSearch ពី 5.5.2 ទៅ 6.4.3 ។ ជាថ្មីម្តងទៀតចង្កោមកំណែ 5 របស់យើងបានស្លាប់ ហើយយើងបានសម្រេចចិត្តបិទវា ហើយធ្វើបច្ចុប្បន្នភាពវាទាំងស្រុង - នៅតែមិនមានកំណត់ហេតុ។ ដូច្នេះ យើង​បាន​ធ្វើ​ការ​ផ្លាស់​ប្តូរ​នេះ​ក្នុង​ពេល​តែ​ពីរ​បី​ម៉ោង​ប៉ុណ្ណោះ។

ការផ្លាស់ប្តូរទ្រង់ទ្រាយធំបំផុតនៅដំណាក់កាលនេះគឺការអនុវត្តកម្មវិធី Apache Kafka លើថ្នាំងបីដែលមានអ្នកសម្របសម្រួលជាសតិបណ្ដោះអាសន្នកម្រិតមធ្យម។ ឈ្មួញកណ្តាលសារបានជួយសង្គ្រោះយើងពីការបាត់បង់កំណត់ហេតុអំឡុងពេលមានបញ្ហាជាមួយ ElasticSearch ។ ក្នុងពេលជាមួយគ្នានេះ យើងបានបន្ថែមថ្នាំង 2 ទៅក្នុងចង្កោម ហើយប្តូរទៅស្ថាបត្យកម្មក្តៅ - ក្តៅ ជាមួយនឹងថ្នាំង "ក្តៅ" ចំនួន 24 ដែលមានទីតាំងនៅក្នុងរ៉ាកែតផ្សេងៗគ្នានៅក្នុងមជ្ឈមណ្ឌលទិន្នន័យ។ យើងបានប្តូរទិសកំណត់ហេតុទៅពួកគេដោយប្រើរបាំងដែលមិនគួរបាត់បង់ក្នុងកាលៈទេសៈណាក៏ដោយ - nginx ក៏ដូចជាកំណត់ហេតុកំហុសកម្មវិធី។ កំណត់ហេតុតូចតាចត្រូវបានបញ្ជូនទៅថ្នាំងដែលនៅសល់ - បំបាត់កំហុស ការព្រមាន។ល។ ហើយបន្ទាប់ពី XNUMX ម៉ោង កំណត់ហេតុ "សំខាន់ៗ" ពីថ្នាំង "ក្តៅ" ត្រូវបានផ្ទេរ។

ដើម្បីមិនបង្កើនចំនួនសន្ទស្សន៍តូចៗ យើងបានប្តូរពីការបង្វិលពេលវេលាទៅយន្តការវិលជុំ។ មានព័ត៌មានជាច្រើននៅលើវេទិកាដែលការបង្វិលតាមទំហំលិបិក្រមគឺមិនគួរឱ្យទុកចិត្តបានឡើយ ដូច្នេះហើយយើងបានសម្រេចចិត្តប្រើការបង្វិលតាមចំនួនឯកសារនៅក្នុងលិបិក្រម។ យើងបានវិភាគលិបិក្រមនីមួយៗ និងកត់ត្រាចំនួនឯកសារដែលបន្ទាប់ពីការបង្វិលគួរតែដំណើរការ។ ដូច្នេះយើងបានឈានដល់ទំហំ shard ល្អបំផុត - មិនលើសពី 50 GB ។ 

ការបង្កើនប្រសិទ្ធភាពចង្កោម

ទោះ​ជា​យ៉ាង​ណា យើង​មិន​បាន​លុប​បំបាត់​បញ្ហា​ទាំង​ស្រុង​នោះ​ទេ។ ជាអកុសល លិបិក្រមតូចៗនៅតែលេចឡើង៖ វាមិនឈានដល់កម្រិតសំឡេងដែលបានបញ្ជាក់ មិនត្រូវបានបង្វិល ហើយត្រូវបានលុបដោយការសម្អាតជាសកលនៃលិបិក្រមចាស់ជាងបីថ្ងៃ ចាប់តាំងពីយើងដកចេញការបង្វិលតាមកាលបរិច្ឆេទ។ នេះនាំឱ្យបាត់បង់ទិន្នន័យដោយសារតែការពិតដែលថាលិបិក្រមពីចង្កោមបានបាត់ទាំងស្រុង ហើយការប៉ុនប៉ងសរសេរទៅលិបិក្រមដែលមិនមានស្រាប់បានបំបែកតក្កវិជ្ជារបស់អ្នកគ្រប់គ្រងដែលយើងប្រើសម្រាប់ការគ្រប់គ្រង។ ឈ្មោះក្លែងក្លាយសម្រាប់ការសរសេរត្រូវបានបំប្លែងទៅជាលិបិក្រម និងបំបែកតក្កវិជ្ជាវិលជុំ ដែលបណ្តាលឱ្យមានការកើនឡើងដែលមិនអាចគ្រប់គ្រងបាននៃសន្ទស្សន៍មួយចំនួនរហូតដល់ 600 ជីកាបៃ។ 

ឧទាហរណ៍សម្រាប់ការកំណត់ការបង្វិល៖

сurator-elk-rollover.yaml

---
actions:
  1:
    action: rollover
    options:
      name: "nginx_write"
      conditions:
        max_docs: 100000000
  2:
    action: rollover
    options:
      name: "python_error_write"
      conditions:
        max_docs: 10000000

ប្រសិនបើ​គ្មាន​ឈ្មោះ​ក្លែងក្លាយ​វិល​ជុំ នោះ​មាន​បញ្ហា​កើតឡើង៖

ERROR     alias "nginx_write" not found.
ERROR     Failed to complete action: rollover.  <type 'exceptions.ValueError'>: Unable to perform index rollover with alias "nginx_write".

យើងបានចាកចេញពីដំណោះស្រាយចំពោះបញ្ហានេះសម្រាប់ការធ្វើម្តងទៀតបន្ទាប់ ហើយបានលើកយកបញ្ហាមួយទៀត៖ យើងបានប្តូរទៅប្រើតក្កវិជ្ជាទាញនៃ Logstash ដែលដំណើរការកំណត់ហេតុចូល (ដកចេញនូវព័ត៌មានដែលមិនចាំបាច់ និងការពង្រឹង)។ យើងបានដាក់វានៅក្នុង docker ដែលយើងបើកដំណើរការតាមរយៈ docker-compose ហើយយើងក៏បានដាក់ logstash-exporter នៅទីនោះផងដែរ ដែលផ្ញើម៉ែត្រទៅ Prometheus សម្រាប់ការត្រួតពិនិត្យប្រតិបត្តិការនៃ log stream។ វិធីនេះ យើងបានផ្ដល់ឱ្យខ្លួនយើងនូវឱកាសដើម្បីផ្លាស់ប្តូរយ៉ាងរលូននូវចំនួននៃ logstash instances ដែលទទួលខុសត្រូវក្នុងការដំណើរការប្រភេទនៃកំណត់ហេតុនីមួយៗ។

ខណៈពេលដែលយើងកំពុងកែលម្អចង្កោម ចរាចរណ៍របស់ cian.ru បានកើនឡើងដល់ 12,8 លាននាក់ អ្នកប្រើប្រាស់តែមួយគត់ក្នុងមួយខែ។ ជាលទ្ធផល វាបានប្រែក្លាយថាការបំប្លែងរបស់យើងគឺនៅពីក្រោយការផ្លាស់ប្តូរផលិតកម្មបន្តិច ហើយយើងប្រឈមមុខនឹងការពិតដែលថាថ្នាំង "កក់ក្តៅ" មិនអាចទប់ទល់នឹងបន្ទុកបាន និងបន្ថយល្បឿននៃការដឹកជញ្ជូនកំណត់ហេតុទាំងមូល។ យើងបានទទួលទិន្នន័យ "ក្តៅ" ដោយមិនមានការបរាជ័យ ប៉ុន្តែយើងត្រូវតែធ្វើអន្តរាគមន៍ក្នុងការចែកចាយនៅសល់ និងធ្វើការវិលជុំដោយដៃ ដើម្បីចែកចាយលិបិក្រមឱ្យស្មើគ្នា។ 

ក្នុងពេលជាមួយគ្នានេះ ការធ្វើមាត្រដ្ឋាន និងការផ្លាស់ប្តូរការកំណត់នៃ logstash instances នៅក្នុង cluster មានភាពស្មុគស្មាញដោយការពិតដែលថាវាគឺជា docker-compose ក្នុងតំបន់ ហើយសកម្មភាពទាំងអស់ត្រូវបានអនុវត្តដោយដៃ (ដើម្បីបន្ថែមចុងបញ្ចប់ថ្មី វាចាំបាច់ក្នុងការឆ្លងកាត់ទាំងអស់ដោយដៃ។ servers និងធ្វើ docker-compose up -d គ្រប់ទីកន្លែង)។

ការចែកចាយឡើងវិញនៃកំណត់ហេតុ

នៅក្នុងខែកញ្ញានៃឆ្នាំនេះ យើងនៅតែកំពុងកាត់បន្ថយ monolith បន្ទុកនៅលើចង្កោមកំពុងកើនឡើង ហើយលំហូរនៃកំណត់ហេតុកំពុងខិតជិត 30 ពាន់សារក្នុងមួយវិនាទី។ 

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

• សម្រាប់ថ្នាំង "ក្តៅ"៖ E3-1270 v6 / 960Gb SSD / 32 Gb x 3 x 2 (3 សម្រាប់ Hot1 និង 3 សម្រាប់ Hot2) ។
• សម្រាប់ថ្នាំង "កក់ក្តៅ"៖ E3-1230 v6 / 4Tb SSD / 32 Gb x 4 ។

នៅក្នុងការធ្វើឡើងវិញនេះ យើងបានផ្លាស់ប្តូរលិបិក្រមជាមួយនឹងកំណត់ហេតុចូលដំណើរការនៃ microservices ដែលមានទំហំដូចគ្នាទៅនឹង nginx logs ជួរមុខទៅកាន់ក្រុមទីពីរនៃ nodes "hot" បី។ ឥឡូវនេះយើងរក្សាទុកទិន្នន័យនៅលើថ្នាំង "ក្តៅ" រយៈពេល 20 ម៉ោង ហើយបន្ទាប់មកផ្ទេរពួកវាទៅថ្នាំង "កក់ក្តៅ" ទៅផ្នែកដែលនៅសល់នៃកំណត់ហេតុ។ 

យើងបានដោះស្រាយបញ្ហានៃលិបិក្រមតូចៗដែលបាត់ដោយកំណត់រចនាសម្ព័ន្ធការបង្វិលរបស់វា។ ឥឡូវនេះសន្ទស្សន៍ត្រូវបានបង្វិលរៀងរាល់ 23 ម៉ោងក្នុងករណីណាក៏ដោយ ទោះបីជាមានទិន្នន័យតិចតួចនៅទីនោះក៏ដោយ។ នេះបានបង្កើនចំនួន shards បន្តិច (មានប្រហែល 800 ក្នុងចំណោមពួកគេ) ប៉ុន្តែតាមទស្សនៈនៃការអនុវត្តចង្កោមវាគឺអាចអត់ឱនបាន។ 

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

ការធ្វើមាត្រដ្ឋាននេះក៏បានដោះស្រាយបញ្ហានៃការខ្វះខាតការធ្វើមាត្រដ្ឋានពាក់កណ្តាលស្វ័យប្រវត្តិផងដែរ។ ដើម្បីធ្វើដូច្នេះ យើងបានដាក់ពង្រាយហេដ្ឋារចនាសម្ព័ន្ធ Nomad cluster ដែលស្រដៀងទៅនឹងអ្វីដែលយើងបានដាក់ពង្រាយរួចហើយនៅក្នុងផលិតកម្ម។ សម្រាប់ពេលនេះបរិមាណ Logstash មិនផ្លាស់ប្តូរដោយស្វ័យប្រវត្តិអាស្រ័យលើបន្ទុកនោះទេប៉ុន្តែយើងនឹងមកនេះ។

ផែនការសម្រាប់អនាគត

មាត្រដ្ឋានការកំណត់រចនាសម្ព័ន្ធដែលបានអនុវត្តបានធ្វើឱ្យល្អឥតខ្ចោះ ហើយឥឡូវនេះយើងរក្សាទុកទិន្នន័យ 13,3 TB - កំណត់ហេតុទាំងអស់សម្រាប់រយៈពេល 4 ថ្ងៃ ដែលចាំបាច់សម្រាប់ការវិភាគពេលមានអាសន្ននៃការជូនដំណឹង។ យើងបំប្លែងកំណត់ហេតុមួយចំនួនទៅជាម៉ែត្រ ដែលយើងបន្ថែមទៅក្រាហ្វិត។ ដើម្បីធ្វើឱ្យការងាររបស់វិស្វករកាន់តែងាយស្រួល យើងមានម៉ែត្រសម្រាប់ចង្កោមហេដ្ឋារចនាសម្ព័ន្ធ និងស្គ្រីបសម្រាប់ការជួសជុលពាក់កណ្តាលស្វ័យប្រវត្តិនៃបញ្ហាទូទៅ។ បន្ទាប់ពីបង្កើនចំនួនថ្នាំងទិន្នន័យដែលត្រូវបានគ្រោងទុកសម្រាប់ឆ្នាំក្រោយ យើងនឹងប្តូរទៅការផ្ទុកទិន្នន័យពី 4 ទៅ 7 ថ្ងៃ។ នេះនឹងគ្រប់គ្រាន់សម្រាប់ការងារប្រតិបត្តិការ ដោយសារយើងតែងតែព្យាយាមស៊ើបអង្កេតឧប្បត្តិហេតុឱ្យបានឆាប់តាមដែលអាចធ្វើទៅបាន ហើយសម្រាប់ការស៊ើបអង្កេតរយៈពេលវែងមានទិន្នន័យតេឡេម៉ែត្រ។ 

នៅខែតុលា ឆ្នាំ 2019 ចរាចរណ៍ទៅកាន់ cian.ru បានកើនឡើងដល់ 15,3 លាននាក់ អ្នកប្រើប្រាស់តែមួយគត់ក្នុងមួយខែ។ នេះបានក្លាយជាការសាកល្បងដ៏ធ្ងន់ធ្ងរនៃដំណោះស្រាយស្ថាបត្យកម្មសម្រាប់ការចែកចាយកំណត់ហេតុ។ 

ឥឡូវនេះ យើងកំពុងរៀបចំធ្វើបច្ចុប្បន្នភាព ElasticSearch ទៅកំណែ 7។ ទោះជាយ៉ាងណាក៏ដោយ សម្រាប់បញ្ហានេះ យើងនឹងត្រូវធ្វើបច្ចុប្បន្នភាពការគូសវាសនៃសន្ទស្សន៍ជាច្រើននៅក្នុង ElasticSearch ចាប់តាំងពីពួកគេបានផ្លាស់ប្តូរពីកំណែ 5.5 ហើយត្រូវបានប្រកាសថាត្រូវបានបដិសេធនៅក្នុងកំណែ 6 (ពួកវាជាធម្មតាមិនមាននៅក្នុងកំណែទេ ៧). នេះមានន័យថា ក្នុងអំឡុងពេលដំណើរការអាប់ដេត ប្រាកដជាមានឧប្បត្តិហេតុមួយប្រភេទ ដែលនឹងធ្វើឱ្យយើងគ្មានកំណត់ហេតុ ខណៈពេលដែលបញ្ហាត្រូវបានដោះស្រាយ។ នៃកំណែទី 7 យើងកំពុងទន្ទឹងរង់ចាំ Kibana ជាមួយនឹងចំណុចប្រទាក់ដែលប្រសើរឡើង និងតម្រងថ្មី។ 

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

ប្រភព: www.habr.com