Fluentd: ເປັນຫຍັງມັນຈຶ່ງສໍາຄັນໃນການຕັ້ງຄ່າ buffer ຜົນຜະລິດ

ໃນປັດຈຸບັນ, ມັນເປັນໄປບໍ່ໄດ້ທີ່ຈະຈິນຕະນາການໂຄງການທີ່ອີງໃສ່ Kubernetes ໂດຍບໍ່ມີ stack ELK, ເຊິ່ງຊ່ວຍປະຢັດບັນທຶກຂອງທັງສອງຄໍາຮ້ອງສະຫມັກແລະອົງປະກອບລະບົບຂອງກຸ່ມ. ໃນການປະຕິບັດຂອງພວກເຮົາ, ພວກເຮົາໃຊ້ stack EFK ກັບ Fluentd ແທນ Logstash.

Fluentd ເປັນຕົວເກັບບັນທຶກແບບທັນສະໄຫມ, ທົ່ວໄປທີ່ກໍາລັງໄດ້ຮັບຄວາມນິຍົມຫຼາຍຂຶ້ນແລະໄດ້ເຂົ້າຮ່ວມກັບ Cloud Native Computing Foundation, ເຊິ່ງເປັນເຫດຜົນທີ່ວ່າ vector ການພັດທະນາຂອງມັນແມ່ນສຸມໃສ່ການນໍາໃຊ້ຮ່ວມກັນກັບ Kubernetes.

ຄວາມຈິງຂອງການໃຊ້ Fluentd ແທນ Logstash ບໍ່ໄດ້ປ່ຽນແປງຄວາມສໍາຄັນທົ່ວໄປຂອງຊຸດຊອບແວ, ຢ່າງໃດກໍຕາມ, Fluentd ມີລັກສະນະສະເພາະຂອງຕົນເອງທີ່ເກີດຈາກຄວາມຍືດຫຍຸ່ນຂອງມັນ.

ຕົວຢ່າງ, ເມື່ອພວກເຮົາເລີ່ມໃຊ້ EFK ໃນໂຄງການທີ່ຫຍຸ້ງຢູ່ກັບການຕັດໄມ້ທີ່ມີຄວາມເຂັ້ມຂຸ້ນສູງ, ພວກເຮົາປະເຊີນກັບຄວາມຈິງທີ່ວ່າໃນ Kibana ບາງຂໍ້ຄວາມຖືກສະແດງຊ້ໍາຊ້ອນຫຼາຍຄັ້ງ. ໃນບົດຄວາມນີ້ພວກເຮົາຈະບອກທ່ານວ່າເປັນຫຍັງປະກົດການນີ້ເກີດຂຶ້ນແລະວິທີການແກ້ໄຂບັນຫາ.

ບັນຫາການຊໍ້າຊ້ອນຂອງເອກະສານ

ໃນໂຄງການຂອງພວກເຮົາ, Fluentd ຖືກນໍາໃຊ້ເປັນ DaemonSet (ເປີດຕົວອັດຕະໂນມັດໃນຕົວຢ່າງດຽວໃນແຕ່ລະ node ຂອງກຸ່ມ Kubernetes) ແລະຕິດຕາມ stdout container logs ໃນ /var/log/containers. ຫຼັງຈາກການລວບລວມແລະການປຸງແຕ່ງ, ບັນທຶກໃນຮູບແບບຂອງເອກະສານ JSON ຖືກສົ່ງໄປຫາ ElasticSearch, ຍົກຂຶ້ນມາໃນຮູບແບບກຸ່ມຫຼືແບບຢືນຢູ່, ຂຶ້ນກັບຂະຫນາດຂອງໂຄງການແລະຄວາມຕ້ອງການສໍາລັບການປະຕິບັດແລະຄວາມທົນທານຕໍ່ຄວາມຜິດ. Kibana ຖືກນໍາໃຊ້ເປັນການໂຕ້ຕອບຮູບພາບ.

ເມື່ອໃຊ້ Fluentd ກັບ output buffering plugin, ພວກເຮົາໄດ້ພົບກັບສະຖານະການທີ່ບາງເອກະສານໃນ ElasticSearch ມີເນື້ອຫາດຽວກັນແທ້ໆແລະແຕກຕ່າງກັນພຽງແຕ່ໃນຕົວລະບຸ. ທ່ານສາມາດກວດສອບໄດ້ວ່ານີ້ແມ່ນການຊໍ້າຄືນຂໍ້ຄວາມໂດຍໃຊ້ບັນທຶກ Nginx ເປັນຕົວຢ່າງ. ໃນໄຟລ໌ບັນທຶກ, ຂໍ້ຄວາມນີ້ມີຢູ່ໃນສຳເນົາດຽວ:

127.0.0.1 192.168.0.1 - [28/Feb/2013:12:00:00 +0900] "GET / HTTP/1.1" 200 777 "-" "Opera/12.0" -

ຢ່າງໃດກໍຕາມ, ມີເອກະສານຈໍານວນຫນຶ່ງໃນ ElasticSearch ທີ່ມີຂໍ້ຄວາມນີ້:

{
  "_index": "test-custom-prod-example-2020.01.02",
  "_type": "_doc",
  "_id": "HgGl_nIBR8C-2_33RlQV",
  "_version": 1,
  "_score": 0,
  "_source": {
    "service": "test-custom-prod-example",
    "container_name": "nginx",
    "namespace": "test-prod",
    "@timestamp": "2020-01-14T05:29:47.599052886 00:00",
    "log": "127.0.0.1 192.168.0.1 - [28/Feb/2013:12:00:00  0900] "GET / HTTP/1.1" 200 777 "-" "Opera/12.0" -",
    "tag": "custom-log"
  }
}

{
  "_index": "test-custom-prod-example-2020.01.02",
  "_type": "_doc",
  "_id": "IgGm_nIBR8C-2_33e2ST",
  "_version": 1,
  "_score": 0,
  "_source": {
    "service": "test-custom-prod-example",
    "container_name": "nginx",
    "namespace": "test-prod",
    "@timestamp": "2020-01-14T05:29:47.599052886 00:00",
    "log": "127.0.0.1 192.168.0.1 - [28/Feb/2013:12:00:00  0900] "GET / HTTP/1.1" 200 777 "-" "Opera/12.0" -",
    "tag": "custom-log"
  }
}

ຍິ່ງໄປກວ່ານັ້ນ, ມັນສາມາດມີຫຼາຍກ່ວາສອງຄັ້ງ.

ໃນຂະນະທີ່ແກ້ໄຂບັນຫານີ້ຢູ່ໃນບັນທຶກ Fluentd, ທ່ານສາມາດເບິ່ງການເຕືອນໄພຈໍານວນຫລາຍທີ່ມີເນື້ອຫາຕໍ່ໄປນີ້:

2020-01-16 01:46:46 +0000 [warn]: [test-prod] failed to flush the buffer. retry_time=4 next_retry_seconds=2020-01-16 01:46:53 +0000 chunk="59c37fc3fb320608692c352802b973ce" error_class=Fluent::Plugin::ElasticsearchOutput::RecoverableRequestFailure error="could not push logs to Elasticsearch cluster ({:host=>"elasticsearch", :port=>9200, :scheme=>"http", :user=>"elastic", :password=>"obfuscated"}): read timeout reached"

ການເຕືອນໄພເຫຼົ່ານີ້ເກີດຂື້ນເມື່ອ ElasticSearch ບໍ່ສາມາດສົ່ງຄືນການຕອບສະຫນອງຕໍ່ຄໍາຮ້ອງຂໍພາຍໃນເວລາທີ່ກໍານົດໂດຍພາລາມິເຕີ request_timeout, ຊຶ່ງເປັນເຫດຜົນທີ່ວ່າຊິ້ນສ່ວນ buffer ທີ່ສົ່ງຕໍ່ບໍ່ສາມາດຖືກລຶບລ້າງໄດ້. ຫຼັງຈາກນີ້, Fluentd ພະຍາຍາມສົ່ງຊິ້ນສ່ວນ buffer ໄປຫາ ElasticSearch ອີກຄັ້ງ ແລະຫຼັງຈາກຄວາມພະຍາຍາມຫຼາຍຄັ້ງ, ການປະຕິບັດການສໍາເລັດ:

2020-01-16 01:47:05 +0000 [warn]: [test-prod] retry succeeded. chunk_id="59c37fc3fb320608692c352802b973ce" 
2020-01-16 01:47:05 +0000 [warn]: [test-prod] retry succeeded. chunk_id="59c37fad241ab300518b936e27200747" 
2020-01-16 01:47:05 +0000 [warn]: [test-dev] retry succeeded. chunk_id="59c37fc11f7ab707ca5de72a88321cc2" 
2020-01-16 01:47:05 +0000 [warn]: [test-dev] retry succeeded. chunk_id="59c37fb5adb70c06e649d8c108318c9b" 
2020-01-16 01:47:15 +0000 [warn]: [kube-system] retry succeeded. chunk_id="59c37f63a9046e6dff7e9987729be66f"

ແນວໃດກໍ່ຕາມ, ElasticSearch ປະຕິບັດຕໍ່ແຕ່ລະຊິ້ນສ່ວນ buffer ທີ່ຖືກໂອນເປັນເອກະລັກ ແລະມອບໝາຍຄ່າພາກສະໜາມ _id ທີ່ເປັນເອກະລັກໃນລະຫວ່າງການດັດສະນີ. ນີ້ແມ່ນວິທີທີ່ສໍາເນົາຂໍ້ຄວາມປາກົດ.

ໃນ Kibana ມັນເບິ່ງຄືວ່ານີ້:

ການແກ້ໄຂບັນຫາ

ມີຫຼາຍທາງເລືອກໃນການແກ້ໄຂບັນຫານີ້. ຫນຶ່ງໃນນັ້ນແມ່ນກົນໄກທີ່ສ້າງຂຶ້ນໃນ plugin fluent-plugin-elasticsearch ສໍາລັບການສ້າງ hash ເປັນເອກະລັກສໍາລັບແຕ່ລະເອກະສານ. ຖ້າທ່ານໃຊ້ກົນໄກນີ້, ElasticSearch ຈະຮັບຮູ້ການຊໍ້າຄືນໃນຂັ້ນຕອນການສົ່ງຕໍ່ແລະປ້ອງກັນບໍ່ໃຫ້ເອກະສານຊ້ໍາກັນ. ແຕ່ພວກເຮົາຕ້ອງຄໍານຶງເຖິງວ່າວິທີການແກ້ໄຂບັນຫານີ້ຕໍ່ສູ້ກັບການສືບສວນແລະບໍ່ລົບລ້າງຄວາມຜິດພາດທີ່ຂາດເວລາ, ດັ່ງນັ້ນພວກເຮົາຈຶ່ງປະຖິ້ມການນໍາໃຊ້ຂອງມັນ.

ພວກເຮົາໃຊ້ plugin buffering ໃນຜົນຜະລິດ Fluentd ເພື່ອປ້ອງກັນການສູນເສຍບັນທຶກໃນກໍລະນີຂອງບັນຫາເຄືອຂ່າຍໃນໄລຍະສັ້ນຫຼືຄວາມເຂັ້ມຂົ້ນຂອງການບັນທຶກເພີ່ມຂຶ້ນ. ຖ້າສໍາລັບເຫດຜົນບາງຢ່າງ ElasticSearch ບໍ່ສາມາດຂຽນເອກະສານໃສ່ດັດສະນີໄດ້ທັນທີ, ເອກະສານຈະຖືກຈັດຄິວແລະເກັບໄວ້ໃນແຜ່ນ. ດັ່ງນັ້ນ, ໃນກໍລະນີຂອງພວກເຮົາ, ເພື່ອລົບລ້າງແຫຼ່ງຂອງບັນຫາທີ່ນໍາໄປສູ່ຄວາມຜິດພາດທີ່ໄດ້ກ່າວມາຂ້າງເທິງ, ມັນຈໍາເປັນຕ້ອງໄດ້ກໍານົດຄ່າທີ່ຖືກຕ້ອງສໍາລັບພາລາມິເຕີ buffering, ເຊິ່ງ Fluentd output buffer ຈະມີຂະຫນາດພຽງພໍແລະ. ໃນ ເວ ລາ ດຽວ ກັນ ການ ຄຸ້ມ ຄອງ ທີ່ ຈະ ໄດ້ ຮັບ ການ ເກັບ ກູ້ ໃນ ເວ ລາ ທີ່ ໄດ້ ຮັບ .

ມັນເປັນມູນຄ່າທີ່ສັງເກດວ່າຄ່າຂອງພາລາມິເຕີທີ່ສົນທະນາຂ້າງລຸ່ມນີ້ແມ່ນບຸກຄົນໃນແຕ່ລະກໍລະນີສະເພາະຂອງການນໍາໃຊ້ buffering ໃນ plugins ຜົນຜະລິດ, ຍ້ອນວ່າພວກເຂົາຂຶ້ນກັບປັດໃຈຈໍານວນຫຼາຍ: ຄວາມເຂັ້ມຂົ້ນຂອງການຂຽນຂໍ້ຄວາມໄປຫາບັນທຶກໂດຍການບໍລິການ, ການປະຕິບັດລະບົບຂອງແຜ່ນ, ເຄືອຂ່າຍ. ການໂຫຼດຊ່ອງ ແລະແບນວິດຂອງມັນ. ດັ່ງນັ້ນ, ເພື່ອໃຫ້ໄດ້ຮັບການຕັ້ງຄ່າ buffer ທີ່ເຫມາະສົມສໍາລັບແຕ່ລະກໍລະນີ, ແຕ່ບໍ່ຊ້ໍາກັນ, ຫຼີກເວັ້ນການຊອກຫາຍາວ blindly, ທ່ານສາມາດນໍາໃຊ້ຂໍ້ມູນ debugging ທີ່ Fluentd ຂຽນໃສ່ບັນທຶກຂອງຕົນໃນລະຫວ່າງການປະຕິບັດງານແລະຂ້ອນຂ້າງໄວໄດ້ຮັບຄ່າທີ່ຖືກຕ້ອງ.

ໃນເວລາບັນທຶກບັນຫາ, ການຕັ້ງຄ່າເບິ່ງຄືດັ່ງນີ້:

 <buffer>
        @type file
        path /var/log/fluentd-buffers/kubernetes.test.buffer
        flush_mode interval
        retry_type exponential_backoff
        flush_thread_count 2
        flush_interval 5s
        retry_forever
        retry_max_interval 30
        chunk_limit_size 8M
        queue_limit_length 8
        overflow_action block
      </buffer>

ເມື່ອແກ້ໄຂບັນຫາ, ຄ່າຂອງພາລາມິເຕີຕໍ່ໄປນີ້ຖືກເລືອກດ້ວຍຕົນເອງ:
chunk_limit_size — ຂະ​ຫນາດ​ຂອງ chunks ທີ່​ຂໍ້​ຄວາມ​ໃນ buffer ໄດ້​ຖືກ​ແບ່ງ​ອອກ​.

• flush_interval — ໄລ​ຍະ​ເວ​ລາ​ທີ່​ຫຼັງ​ຈາກ​ນັ້ນ​ການ​ລົບ​ລ້າງ​.
• queue_limit_length — ຈໍາ​ນວນ​ສູງ​ສຸດ​ຂອງ chunks ໃນ​ຄິວ​.
• request_timeout ແມ່ນເວລາທີ່ເຊື່ອມຕໍ່ລະຫວ່າງ Fluentd ແລະ ElasticSearch ຖືກສ້າງຕັ້ງຂຶ້ນ.

ຂະຫນາດ buffer ທັງຫມົດສາມາດຖືກຄິດໄລ່ໂດຍການຄູນພາລາມິເຕີ queue_limit_length ແລະ chunk_limit_size, ເຊິ່ງສາມາດຖືກຕີຄວາມວ່າ "ຈໍານວນສູງສຸດຂອງ chunks ໃນແຖວ, ແຕ່ລະມີຂະຫນາດທີ່ກໍານົດໄວ້." ຖ້າຂະໜາດບັຟເຟີບໍ່ພຽງພໍ, ຄຳເຕືອນຕໍ່ໄປນີ້ຈະປາກົດຢູ່ໃນບັນທຶກ:

2020-01-21 10:22:57 +0000 [warn]: [test-prod] failed to write data into buffer by buffer overflow action=:block

ມັນຫມາຍຄວາມວ່າ buffer ບໍ່ມີເວລາທີ່ຈະລ້າງໃນເວລາທີ່ໄດ້ຮັບແລະຂໍ້ມູນທີ່ເຂົ້າໄປໃນ buffer ເຕັມຈະຖືກສະກັດ, ເຊິ່ງຈະນໍາໄປສູ່ການສູນເສຍສ່ວນຫນຶ່ງຂອງບັນທຶກ.

ທ່ານສາມາດເພີ່ມ buffer ໃນສອງວິທີ: ໂດຍການເພີ່ມຂະຫນາດຂອງແຕ່ລະ chunk ໃນແຖວ, ຫຼືຈໍານວນຂອງ chunks ທີ່ສາມາດຢູ່ໃນແຖວ.

ຖ້າທ່ານຕັ້ງຂະຫນາດ chunk_limit_size ເປັນຫຼາຍກວ່າ 32 megabytes, ຫຼັງຈາກນັ້ນ ElasticSeacrh ຈະບໍ່ຍອມຮັບມັນ, ເພາະວ່າແພັກເກັດທີ່ເຂົ້າມາຈະມີຂະຫນາດໃຫຍ່ເກີນໄປ. ດັ່ງນັ້ນ, ຖ້າທ່ານຕ້ອງການເພີ່ມ buffer ຕື່ມອີກ, ມັນດີກວ່າທີ່ຈະເພີ່ມຄວາມຍາວແຖວສູງສຸດ queue_limit_length.

ເມື່ອ buffer ຢຸດ overflowing ແລະມີພຽງແຕ່ຂໍ້ຄວາມ timeout ທີ່ບໍ່ພຽງພໍ, ທ່ານສາມາດເລີ່ມຕົ້ນການເພີ່ມພາລາມິເຕີ request_timeout. ແນວໃດກໍ່ຕາມ, ຖ້າທ່ານຕັ້ງຄ່າຫຼາຍກວ່າ 20 ວິນາທີ, ການເຕືອນຕໍ່ໄປນີ້ຈະເລີ່ມປາກົດຢູ່ໃນບັນທຶກ Fluentd:

2020-01-21 09:55:33 +0000 [warn]: [test-dev] buffer flush took longer time than slow_flush_log_threshold: elapsed_time=20.85753920301795 slow_flush_log_threshold=20.0 plugin_id="postgresql-dev" 

ຂໍ້ຄວາມນີ້ບໍ່ມີຜົນຕໍ່ການເຮັດວຽກຂອງລະບົບໃນທາງໃດກໍ່ຕາມ ແລະໝາຍຄວາມວ່າ buffer flush ໃຊ້ເວລາດົນກວ່າທີ່ກຳນົດໄວ້ໂດຍພາຣາມິເຕີ slow_flush_log_threshold. ນີ້ແມ່ນຂໍ້ມູນການດີບັກ ແລະພວກເຮົາໃຊ້ມັນໃນເວລາເລືອກຄ່າຂອງພາຣາມິເຕີ request_timeout.

ສູດ​ການ​ຄັດ​ເລືອກ​ໂດຍ​ທົ່ວ​ໄປ​ແມ່ນ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​:

1. ຕັ້ງ request_timeout ເປັນຄ່າທີ່ຮັບປະກັນວ່າໃຫຍ່ກວ່າຄວາມຈຳເປັນ (ຫຼາຍຮ້ອຍວິນາທີ). ໃນ​ລະ​ຫວ່າງ​ການ​ຕັ້ງ​ຄ່າ​, ມາດ​ຕະ​ຖານ​ຕົ້ນ​ຕໍ​ສໍາ​ລັບ​ການ​ຕັ້ງ​ຄ່າ​ທີ່​ຖືກ​ຕ້ອງ​ຂອງ​ຕົວ​ກໍາ​ນົດ​ການ​ນີ້​ຈະ​ເປັນ​ການ​ຫາຍ​ໄປ​ຂອງ​ຄໍາ​ເຕືອນ​ສໍາ​ລັບ​ການ​ຂາດ​ການ​ຫມົດ​ເວ​ລາ​.
2. ລໍຖ້າຂໍ້ຄວາມກ່ຽວກັບການເກີນ slow_flush_log_threshold threshold. ຂໍ້ຄວາມເຕືອນໃນຊ່ອງ elapsed_time ຈະສະແດງເວລາທີ່ແທ້ຈິງທີ່ buffer ໄດ້ຖືກລຶບລ້າງ.
3. ຕັ້ງ request_timeout ເປັນຄ່າທີ່ໃຫຍ່ກວ່າຄ່າສູງສຸດ elapsed_time ທີ່ໄດ້ຮັບໃນລະຫວ່າງໄລຍະເວລາການສັງເກດ. ພວກເຮົາຄິດໄລ່ຄ່າ request_timeout ເປັນ elapsed_time + 50%.
4. ເພື່ອເອົາຄໍາເຕືອນກ່ຽວກັບ buffer flushs ຍາວອອກຈາກບັນທຶກ, ທ່ານສາມາດເພີ່ມມູນຄ່າຂອງ slow_flush_log_threshold. ພວກເຮົາຄິດໄລ່ຄ່ານີ້ເປັນ elapsed_time + 25%.

ຄ່າສຸດທ້າຍຂອງພາລາມິເຕີເຫຼົ່ານີ້, ດັ່ງທີ່ໄດ້ລະບຸໄວ້ກ່ອນຫນ້ານີ້, ແມ່ນໄດ້ຮັບສ່ວນບຸກຄົນສໍາລັບແຕ່ລະກໍລະນີ. ໂດຍປະຕິບັດຕາມສູດການຄິດໄລ່ຂ້າງເທິງ, ພວກເຮົາຮັບປະກັນທີ່ຈະລົບລ້າງຄວາມຜິດພາດທີ່ນໍາໄປສູ່ຂໍ້ຄວາມທີ່ຊ້ໍາກັນ.

ຕາຕະລາງຂ້າງລຸ່ມນີ້ສະແດງໃຫ້ເຫັນວິທີການຈໍານວນຂໍ້ຜິດພາດຕໍ່ມື້, ນໍາໄປສູ່ການຊໍ້າຊ້ອນຂອງຂໍ້ຄວາມ, ການປ່ຽນແປງໃນຂະບວນການເລືອກຄ່າຂອງພາລາມິເຕີທີ່ອະທິບາຍຂ້າງເທິງ:

node-1
node-2
node-3
node-4

ກ່ອນຫຼັງ
ກ່ອນຫຼັງ
ກ່ອນຫຼັງ
ກ່ອນຫຼັງ

ລົ້ມເຫລວໃນການລ້າງ buffer
1749/2
694/2
47/0
1121/2

ພະຍາຍາມອີກຄັ້ງສຳເລັດ
410/2
205/1
24/0
241/2

ມັນເປັນມູນຄ່າທີ່ສັງເກດວ່າການຕັ້ງຄ່າຜົນໄດ້ຮັບອາດຈະສູນເສຍຄວາມກ່ຽວຂ້ອງຍ້ອນວ່າໂຄງການເຕີບໂຕແລະ, ຕາມນັ້ນ, ຈໍານວນໄມ້ທ່ອນເພີ່ມຂຶ້ນ. ສັນຍານຫຼັກຂອງການໝົດເວລາທີ່ບໍ່ພຽງພໍແມ່ນການກັບຄືນຂອງຂໍ້ຄວາມກ່ຽວກັບ buffer flush ຍາວໄປຫາບັນທຶກ Fluentd, ນັ້ນແມ່ນ, ເກີນຂອບເຂດ slow_flush_log_threshold. ຈາກຈຸດນີ້, ຍັງມີຂອບຂະຫນາດນ້ອຍກ່ອນທີ່ຕົວກໍານົດການ request_timeout ຈະເກີນ, ດັ່ງນັ້ນມັນຈໍາເປັນຕ້ອງຕອບສະຫນອງຂໍ້ຄວາມເຫຼົ່ານີ້ຢ່າງທັນເວລາແລະເຮັດຊ້ໍາຂັ້ນຕອນຂອງການເລືອກການຕັ້ງຄ່າທີ່ດີທີ່ສຸດທີ່ໄດ້ອະທິບາຍຂ້າງເທິງ.

ສະຫລຸບ

ການປັບປຸງ Fluentd output buffer ແມ່ນຫນຶ່ງໃນຂັ້ນຕອນຕົ້ນຕໍຂອງການຕັ້ງຄ່າ stack EFK, ກໍານົດຄວາມຫມັ້ນຄົງຂອງການດໍາເນີນງານຂອງມັນແລະການວາງທີ່ຖືກຕ້ອງຂອງເອກະສານໃນດັດສະນີ. ອີງຕາມສູດການຄິດໄລ່ການຕັ້ງຄ່າທີ່ອະທິບາຍໄວ້, ທ່ານສາມາດແນ່ໃຈວ່າບັນທຶກທັງຫມົດຈະຖືກຂຽນໃສ່ດັດສະນີ ElasticSearch ໃນຄໍາສັ່ງທີ່ຖືກຕ້ອງ, ໂດຍບໍ່ມີການຊ້ໍາກັນຫຼືການສູນເສຍ.

ອ່ານບົດຄວາມອື່ນໆໃນ blog ຂອງພວກເຮົາ:

• Go ແລະ Zabbix 5.0 ກາຍເປັນເພື່ອນ
• ການອັບເກຣດກຸ່ມ Kubernetes ໂດຍບໍ່ມີການຢຸດເຮັດວຽກ
• Kubernetes: ເປັນຫຍັງມັນຈຶ່ງສຳຄັນຫຼາຍໃນການຕັ້ງຄ່າການຈັດການຊັບພະຍາກອນຂອງລະບົບ?
• ສາມ tricks ງ່າຍດາຍທີ່ຈະຫຍໍ້ຮູບພາບ Docker
• ການສໍາຮອງຂອງຈໍານວນຂະຫນາດໃຫຍ່ຂອງໂຄງການເວັບໄຊຕ໌ heterogeneous

ແຫຼ່ງຂໍ້ມູນ: www.habr.com