ມີບັນຫາໃນການໃຊ້ງານ Apache2 ກັບ HestiaCP ເລື້ອຍໆບໍ? ຕິດຕາມຄູ່ມືການຕິດຕາມກວດກາ ແລະ ການແກ້ໄຂບັນຫາແບບອັດຕະໂນມັດ (ພ້ອມການຕັ້ງຄ່າທີ່ສົມບູນ)

ເລື້ອຍໆ Apache2 ຂັດຂ້ອງ ຫຼື ຄວາມລົ້ມເຫຼວໃນການຣີສະຕາດອັດຕະໂນມັດຂອງ Monit ໃນສະພາບແວດລ້ອມ HestiaCP ບໍ? ບົດຄວາມນີ້ໃຫ້ຄຳແນະນຳທີ່ເປັນປະໂຫຍດເພື່ອຫຼີກລ່ຽງຂໍ້ຜິດພາດທົ່ວໄປເມື່ອຕິດຕາມກວດກາ Apache2 ດ້ວຍ Monit, ວິເຄາະບັນຫາທົ່ວໄປຢ່າງເລິກເຊິ່ງເຊັ່ນ: ເສັ້ນທາງ PID ທີ່ບໍ່ຖືກຕ້ອງ ແລະ ການບລັອກການອະນຸຍາດ, ແລະ ສະເໜີໄຟລ໌ການຕັ້ງຄ່າອັດຕະໂນມັດ Monit ລະດັບການຜະລິດ. ຮຽນຮູ້ເຕັກນິກການບຳລຸງຮັກສາເຊີບເວີທີ່ມີຄວາມພ້ອມສູງດຽວນີ້ ແລະ ບັນລຸການກູ້ຄືນອັດຕະໂນມັດລະດັບສອງຈາກຄວາມລົ້ມເຫຼວ!

ຂໍ້ຜິດພາດທີ່ຂ້ອຍພົບໃນຂະນະທີ່ໃຊ້ Monit ເພື່ອຕິດຕາມ Apache2

ວັນສຸກທີ່ຜ່ານມາ, ເຊີບເວີໄດ້ໃຫ້ການແຈ້ງເຕືອນ Monit ຂ້ອຍໃນຕອນກາງຄືນ.

ຂ້ອຍຫລຽວເບິ່ງແຜງດ້ວຍຄວາມງົງງັນ, ແລະໃນຖັນສະຖານະ apache2, ມີ Timeout ສີແດງ.

ຂ້ອຍຄິດກ່ຽວກັບມັນຢູ່ໄລຍະໜຶ່ງ. ຂ້ອຍຫາກໍ່ເພີ່ມການຕິດຕາມກວດກາ Monit ໃສ່ເຊີບເວີໃນລະຫວ່າງມື້, ແລະຂ້ອຍໄດ້ຄັດລອກແລະວາງການຕັ້ງຄ່າຈາກບົດແນະນຳອອນໄລນ໌. ມັນບໍ່ຄວນມີບັນຫາຫຍັງເລີຍ, ແມ່ນບໍ?

ຕອນເຊົ້າມື້ຕໍ່ມາ, ມັນໝົດເວລາອີກ. ຫຼັງຈາກຄັ້ງທີສາມ, Monitor ກໍ່ຍອມແພ້, ແລະແຜງສະແດງຜົນ "ບໍ່ໄດ້ຕິດຕາມກວດກາ".

ຂ້ອຍ...

ຂ້ອຍຍອມຮັບວ່າ, ໃນຕອນທຳອິດຂ້ອຍບໍ່ໄດ້ເອົາຈິງເອົາຈັງກັບມັນ. ການຕິດຕາມ Apache2 ບໍ? ເຈົ້າສາມາດຊອກຫາການຕັ້ງຄ່າແມ່ແບບຫຼາຍຢ່າງທາງອອນລາຍ, ພຽງແຕ່ຄັດລອກແລະວາງ. ແຕ່ຂະບວນການວາງນັ້ນເຮັດໃຫ້ຂ້ອຍໃຈຮ້າຍຫຼາຍ.

ສາເຫດຕົ້ນຕໍຂອງຄວາມຂັດແຍ້ງລະຫວ່າງສະຖາປັດຕະຍະກຳເລີ່ມຕົ້ນຂອງ HestiaCP ແລະພອດ Monit

ກ່ອນອື່ນໝົດ, ຂໍໃຫ້ຂ້ອຍສະແດງການຕັ້ງຄ່າທີ່ເຮັດໃຫ້ຂ້ອຍມີບັນຫາຫຼາຍ, ເພື່ອໃຫ້ເຈົ້າສາມາດເຫັນໄດ້ວ່າມັນຄືກັນກັບລຸ້ນທີ່ເຈົ້າເຄີຍເຫັນຫຼືບໍ່.

check process apache2 with pidfile /var/run/apache2/apache2.pid
    start program = "/usr/sbin/service apache2 start"
    stop program  = "/usr/sbin/service apache2 stop"
    if failed host 127.0.0.1 port 80 protocol http then restart
    if 5 restarts within 5 cycles then timeout

ມັນເບິ່ງຄືວ່າບໍ່ມີບັນຫາຫຍັງ, ແມ່ນບໍ? ມັນກວດສອບພອດ 80, ແລະຖ້າມັນຂັດຂ້ອງ, ມັນຈະເລີ່ມຕົ້ນໃໝ່. ຖ້າມັນຍັງຂັດຂ້ອງຫຼັງຈາກເລີ່ມຕົ້ນໃໝ່ 5 ເທື່ອ, ມັນຈະໝົດເວລາ.

ບັນຫາແມ່ນວ່າ Apache2 ຂອງທ່ານບໍ່ໄດ້ເຮັດວຽກຢູ່ພອດ 80.

ນີ້ແມ່ນຈຸດອ່ອນຂອງ HestiaCP, ແລະເປັນສາເຫດຫຼັກທີ່ເຮັດໃຫ້ຫຼາຍຄົນຕົກຢູ່ໃນມັນ. ສະຖາປັດຕະຍະກຳເລີ່ມຕົ້ນຂອງ HestiaCP ແມ່ນ reverse proxy ຂອງ Nginx + Apache2, ໂດຍ Nginx ໃຊ້ພອດ 80 ແລະ 443 ຢູ່ທາງໜ້າ, ແລະ Apache2 ແລ່ນຢູ່ໃນພອດທ້ອງຖິ່ນ 8081 ຢູ່ທາງຫຼັງ.

ຖ້າທ່ານຂໍໃຫ້ Monit ກວດສອບຄວາມມີຊີວິດຊີວາຂອງ Apache2 ໃນພອດ 80, ມັນຄ້າຍຄືກັບການໄປຮ້ານ McDonald's ເພື່ອຊອກຫາ KFC. ເຊີບເວີເບິ່ງທ່ານດ້ວຍຄວາມງົງງວຍ, ແລະທ່ານທັງສອງກໍ່ແນມເບິ່ງກັນ. ໃນທີ່ສຸດ, Monit ຕັດສິນໃຈວ່າທ່ານລົ້ມລົງແລະເລີ່ມເລີ່ມຕົ້ນໃໝ່ຢ່າງຮີບຮ້ອນ.

ຫຼັງຈາກເລີ່ມຕົ້ນໃໝ່ແລ້ວ, ພອດຍັງຄົງເປັນ 8081. ຫຼັງຈາກນັ້ນ, Monit ພະຍາຍາມກວດສອບພອດ 80, ເຊິ່ງກໍ່ລົ້ມເຫຼວເຊັ່ນກັນ, ສະນັ້ນມັນຈຶ່ງເລີ່ມຕົ້ນໃໝ່ອີກຄັ້ງ. ວົງຈອນນີ້ຈະເກີດຂຶ້ນຊ້ຳອີກຈົນກວ່າ Monit ຈະຕັດສິນໃຈວ່າມັນບໍ່ສາມາດສ້ອມແປງໄດ້ ແລະ ໝົດເວລາໃຊ້ງານ.

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

ໄຟລ໌ Apache2 PID ທີ່ເສຍຫາຍເຮັດໃຫ້ Monit ລະບຸຂະບວນການຜິດພາດວ່າບໍ່ມີຢູ່ຈິງ.

ຫຼັງຈາກປ່ຽນພອດຈາກ 80 ເປັນ 8081, Monit ຄວນຈະສາມາດກວດຫາມັນໄດ້ໃນທາງທິດສະດີ, ແມ່ນບໍ?

ເຖິງຢ່າງໃດກໍ່ຕາມ, ໃນຄວາມເປັນຈິງແລ້ວ, ບາງຄັ້ງມັນຍັງລາຍງານວ່າ "ການປະຕິບັດ ລົ້ມເຫຼວ ".

ຫຼັງຈາກດີ້ນຮົນມາດົນ, ໃນທີ່ສຸດຂ້ອຍກໍ່ຄົ້ນພົບເຫດຜົນງ່າຍໆຄື: ໄຟລ໌ PID ເສຍຫາຍ.

ລອງຄິດເບິ່ງ, Monit ໄດ້ເລີ່ມ Apache2 ຄືນໃໝ່ຢ່າງຮີບຮ້ອນ, ແຕ່ລະຄັ້ງກໍ່ບັງຄັບປິດ ແລະ ເປີດມັນຄືນໃໝ່, ໄປມາຫຼາຍຄັ້ງ. ໃນລະຫວ່າງຂະບວນການນີ້, ໄຟລ໌ /var/run/apache2/apache2.pid ອາດຈະກາຍເປັນ 0 ໄບຕ໌.

ເວົ້າອີກຢ່າງໜຶ່ງ, ໄຟລ໌ຍັງຢູ່ທີ່ນັ້ນ, ແຕ່ມັນຫວ່າງເປົ່າ.

ເມື່ອ Monit ອ່ານໄຟລ໌ນີ້, ມັນບໍ່ພົບຫຍັງເລີຍ. ມັນບໍ່ຮູ້ຈັກ Apache2 ຂອງເຈົ້າ, ເຖິງແມ່ນວ່າ Apache2 ຂອງເຈົ້າຈະເຮັດວຽກໄດ້ດີໃນພື້ນຫຼັງກໍຕາມ; Monit ບໍ່ຄິດວ່າຂະບວນການດັ່ງກ່າວມີຢູ່.

ເມື່ອຂ້ອຍເຫັນແບບນີ້, ຂ້ອຍກໍ່ເວົ້າບໍ່ອອກໄປຊົ່ວໄລຍະໜຶ່ງ.

ນີ້ແມ່ນການຢຸດຊະງັກ. Monit ລົ້ມເຫລວໃນການກວດຫາ instance Apache 2, ເລີ່ມຕົ້ນ Apache2 ຄືນໃໝ່, ເຮັດໃຫ້ໄຟລ໌ PID ເສຍຫາຍໃນລະຫວ່າງຂະບວນການເລີ່ມຕົ້ນໃໝ່, ການກວດສອບຄັ້ງຕໍ່ໄປລົ້ມເຫຼວ, ແລະເລີ່ມຕົ້ນໃໝ່ອີກຄັ້ງ. ວົງຈອນນີ້ຈະສືບຕໍ່ຈົນກວ່າຈະເກີດການໝົດເວລາ.

ຂັ້ນຕອນການແກ້ໄຂບັນຫາ ແລະ ການສ້ອມແປງສຳລັບການຕິດຕາມ Apache2 ໃນສະພາບແວດລ້ອມ HestiaCP

ເວົ້າແທ້ໆ, ຂະບວນການສືບສວນບໍ່ສັບສົນ, ແຕ່ທ່ານຈຳເປັນຕ້ອງຮູ້ວ່າຈະສືບສວນໄປໃນທິດທາງໃດ.

ຂັ້ນຕອນທຳອິດແມ່ນການກຳນົດວ່າພອດໃດທີ່ Apache2 ຂອງທ່ານກຳລັງຟັງຢູ່. ພຽງແຕ່ພິມຄຳສັ່ງໃນ terminal.

netstat -tulpn | grep apache2

ອີກທາງເລືອກໜຶ່ງ, ທ່ານສາມາດໃຊ້ຄຳສັ່ງ `ss`; ຜົນກະທົບແມ່ນຄືກັນ.

ss -tulpn | grep apache2

ທ່ານຈະເຫັນຜົນຜະລິດທີ່ຄ້າຍຄືກັນກັບນີ້.

tcp  0  0 127.0.0.1:8081       0.0.0.0:*  LISTEN  2942372/apache2

ມັນຖືກຢືນຢັນວ່າເປັນ 8081, ບໍ່ແມ່ນ 80. ນັ້ນແມ່ນຮາກເຫງົ້າຂອງບັນຫາ.

ຂັ້ນຕອນທີສອງແມ່ນການສ້ອມແປງໄຟລ໌ PID ທີ່ເສຍຫາຍ. ວິທີນີ້ງ່າຍກວ່າ.

monit unmonitor apache2
systemctl restart apache2
cat /var/run/apache2/apache2.pid

ກ່ອນອື່ນໝົດ, ໃຫ້ຢຸດການຕິດຕາມ Monit ໄວ້ຊົ່ວຄາວເພື່ອປ້ອງກັນບໍ່ໃຫ້ມັນແຊກແຊງໃນຂະນະທີ່ທ່ານກຳລັງແກ້ໄຂສິ່ງຕ່າງໆ. ຈາກນັ້ນ, ເລີ່ມຕົ້ນ Apache2 ໃໝ່ເພື່ອໃຫ້ມັນຂຽນ PID ທີ່ສະອາດຄືນໃໝ່. ສຸດທ້າຍ, ໃຊ້ `cat` ເພື່ອກວດສອບເນື້ອໃນຂອງໄຟລ໌; ມັນຄວນປະກອບດ້ວຍສະຕຣິງຕົວເລກ, ບໍ່ແມ່ນສະຕຣິງຫວ່າງເປົ່າ.

ເມື່ອຂັ້ນຕອນນີ້ສຳເລັດແລ້ວ, ບັນຫາດັ່ງກ່າວຈະຖືກແກ້ໄຂໂດຍພື້ນຖານແລ້ວ.

ການວິເຄາະປຽບທຽບການຕັ້ງຄ່າການປ້ອງກັນແບບປັບຕົວ ແລະ ຮຸກຮານແບບດັ້ງເດີມຂອງ Monit

ບົດແນະນຳອອນໄລນ໌ກ່ຽວກັບການຕັ້ງຄ່າ Apache2 ດ້ວຍ Monit ໂດຍທົ່ວໄປແລ້ວແບ່ງອອກເປັນສອງປະເພດ.

ປະເພດໜຶ່ງແມ່ນ "ປະເພດການປັບຕົວແບບດັ້ງເດີມ," ເຊິ່ງໃຊ້ຄຳສັ່ງ `service` ເພື່ອຈັດການການບໍລິການ ແລະ ກວດສອບພອດທ້ອງຖິ່ນໂດຍບໍ່ຕ້ອງເພີ່ມຂໍ້ຈຳກັດທີ່ສັບສົນຫຼາຍເກີນໄປ. ການຕັ້ງຄ່ານີ້ສາມາດໃຊ້ໃນ HestiaCP ໂດຍພຽງແຕ່ປ່ຽນພອດ, ແລະ ມັນມີຄວາມໝັ້ນຄົງພໍສົມຄວນ.

ວິທີການອີກອັນໜຶ່ງແມ່ນວິທີການ "ການປົກປ້ອງແບບຮຸກຮານ", ເຊິ່ງໃຊ້ systemctl ເພື່ອຈັດການການບໍລິການ, ເພີ່ມຂໍ້ຈຳກັດຂອງຂະບວນການລູກ, ແລະ ໃຊ້ເຫດຜົນການກວດສອບທີ່ເຂັ້ມງວດກວ່າ. ມັນເບິ່ງດີຫຼາຍ, ແຕ່ມັນມີຂໍ້ບົກຜ່ອງທີ່ຮ້າຍແຮງ: ຄຳສັ່ງຢຸດທີ່ໃຊ້ແມ່ນ `killall -9`.

`killall -9` ໝາຍຄວາມວ່າແນວໃດ? ມັນໝາຍເຖິງການບັງຄັບປິດອຸປະກອນໂດຍບໍ່ຄຳນຶງເຖິງສິ່ງທີ່ມັນກຳລັງເຮັດ. ການດຳເນີນງານແບບ brute-force ນີ້ສາມາດປະໄວ້ໄຟລ໌ PID ທີ່ເສຍຫາຍໄດ້ງ່າຍ, ເຊິ່ງເປັນບັນຫາທີ່ຂ້ອຍຫາກໍ່ກ່າວເຖິງ.

ປະສົບການສ່ວນຕົວຂອງຂ້ອຍແມ່ນວ່າການຈຳກັດຈຳນວນຂະບວນການລູກໃນການຕັ້ງຄ່າທີ່ຮຸກຮານແມ່ນເປັນປະໂຫຍດແທ້ໆ. ເມື່ອ Apache2 ຂອງທ່ານຖືກໂຈມຕີໂດຍ CC, ການຈຳກັດຈຳນວນຂະບວນການລູກສາມາດປ້ອງກັນບໍ່ໃຫ້ເຊີບເວີໝົດໜ່ວຍຄວາມຈຳ. ຢ່າງໃດກໍຕາມ, ວິທີການ `killall -9` ແມ່ນໃຊ້ບໍ່ໄດ້ແທ້ໆ.

ສະນັ້ນໃນທີ່ສຸດຂ້ອຍໄດ້ປະນີປະນອມແລະລວມເອົາຂໍ້ດີຂອງການຕັ້ງຄ່າທັງສອງຢ່າງເຂົ້າກັນ.

ການຕັ້ງຄ່າການປະຕິບັດທີ່ດີທີ່ສຸດຂອງ HestiaCP Apache2 Monit

ໃຫ້ດັດແປງໄຟລ໌ /etc/monit/conf.d/apache2 ດ້ວຍເນື້ອຫາຕໍ່ໄປນີ້.

check process apache2 with pidfile /var/run/apache2/apache2.pid
    start program = "/bin/systemctl start apache2"
    stop program  = "/bin/systemctl stop apache2"
    if children > 120 for 2 cycles then restart
    if failed host 127.0.0.1 port 8081 protocol http for 2 cycles then restart
    if 5 restarts within 10 cycles then timeout

ຂ້າພະເຈົ້າຂໍອະທິບາຍໂດຍຫຍໍ້ກ່ຽວກັບເຫດຜົນທີ່ຢູ່ເບື້ອງຫຼັງການຕັ້ງຄ່າສອງສາມແຖວນີ້.

ຂຽນພອດ 8081 ໃຫ້ກົງກັບສະຖາປັດຕະຍະກຳ reverse proxy ຂອງ HestiaCP ຢ່າງແນ່ນອນ; ຢຸດຂຽນພອດ 80 ຢ່າງໂງ່ໆ.

ໃຊ້ຄຳສັ່ງ `systemctl stop` ແທນ `killall -9` ເພື່ອຢຸດໄຟລ໌ PID, ເພື່ອບໍ່ໃຫ້ມັນເສຍຫາຍ.

ຂໍ້ຈຳກັດຂອງຂະບວນການເດັກໄດ້ຖືກເພີ່ມເຂົ້າມາແລ້ວ: ຖ້າຈຳນວນເດັກເກີນ 120 ຄົນ, ຂະບວນການຈະເລີ່ມຕົ້ນໃໝ່ຫຼັງຈາກສອງຮອບວຽນຕິດຕໍ່ກັນເພື່ອປ້ອງກັນການໂຈມຕີ CC, ແຕ່ມັນບໍ່ຮຸນແຮງເກີນໄປ.

ເຫດຜົນສຳລັບການກວດສອບຄວາມລົ້ມເຫຼວໄດ້ຖືກດັດແປງເພື່ອໃຊ້ວິທີການ "ສຳລັບ 2 ຮອບວຽນ", ຊຶ່ງໝາຍຄວາມວ່າການເລີ່ມຕົ້ນໃໝ່ຈະຖືກກະຕຸ້ນຫຼັງຈາກຄວາມລົ້ມເຫຼວສອງຄັ້ງຕິດຕໍ່ກັນ, ເຊິ່ງຫຼຸດຜ່ອນຜົນບວກທີ່ບໍ່ຖືກຕ້ອງ. ການຕັ້ງຄ່າກ່ອນໜ້ານີ້, ເຊິ່ງເລີ່ມຕົ້ນໃໝ່ຫຼັງຈາກການກວດສອບພຽງຄັ້ງດຽວ, ແມ່ນມີຄວາມອ່ອນໄຫວເກີນໄປເລັກນ້ອຍ.

ຂອບເຂດການໝົດເວລາສຸດທ້າຍຖືກຜ່ອນຄາຍລົງເປັນ 5 ການເລີ່ມຕົ້ນໃໝ່ພາຍໃນ 10 ຮອບວຽນ, ເຊິ່ງເຮັດໃຫ້ມີຄວາມທົນທານຕໍ່ຄວາມຜິດພາດທີ່ພຽງພໍ.

HestiaCP ຕິດ​ຕາມ​ກວດ​ກາ​ສະຫຼຸບການແກ້ໄຂບັນຫາການຕັ້ງຄ່າ ແລະ ການແບ່ງປັນປະສົບການ

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

ຈະອະທິບາຍຄວາມຮູ້ສຶກຂອງຂ້ອຍໃນເວລານັ້ນແນວໃດ? ມັນຄືກັບການໃຊ້ເວລາສອງມື້ຕໍ່ສູ້ກັບຂໍ້ຜິດພາດ, ແຕ່ສຸດທ້າຍກໍ່ຮູ້ວ່າສາເຫດແມ່ນການຕັ້ງຄ່າຜິດພາດພຽງຢ່າງດຽວ. ມັນທັງໜ້າອຸກໃຈ ແລະ ຕະຫຼົກ.

Monit ເປັນສິ່ງທີ່ດີໃນຕົວຂອງມັນເອງ, ແລະການຕິດຕາມ daemons ແມ່ນສິ່ງທີ່ທຸກເຊີບເວີຄວນເຮັດ. ແຕ່ບັນຫາແມ່ນວ່າບົດແນະນຳອອນໄລນ໌ຫຼາຍຢ່າງແມ່ນອີງໃສ່ສົມມຸດຕິຖານທີ່ວ່າ "Apache2 ໃຊ້ພອດ 80 ເທົ່ານັ້ນ," ໃນຂະນະທີ່ HestiaCP ໃຊ້ reverse proxy, ຊຶ່ງໝາຍຄວາມວ່າສົມມຸດຕິຖານນີ້ບໍ່ຖືກຕ້ອງ.

ຖ້າທ່ານປະຕິບັດຕາມຄໍາແນະນໍາ, ບັນຫາບໍ່ແມ່ນທ່ານ; ມັນແມ່ນວ່າການສອນແນະນໍານີ້ສາມາດໃຊ້ໄດ້ກັບສະຖານະການທີ່ແຕກຕ່າງຈາກຂອງທ່ານ.

ສະນັ້ນ, ຖ້າທ່ານກຳລັງໃຊ້ HestiaCP ແລະ ກຳລັງຫຼິ້ນກັບ Monit ເພື່ອຕິດຕາມ Apache2, ພຽງແຕ່ຈື່ສອງຢ່າງຄື: ປ່ຽນພອດເປັນ 8081, ແລະ ໃຊ້ຄຳສັ່ງ `systemctl` ເພື່ອຢຸດມັນ, ບໍ່ແມ່ນ `killall -9`. ຖ້າທ່ານເຮັດສອງຢ່າງນີ້, ທ່ານຄວນຈະສາມາດຫຼີກລ່ຽງບັນຫາໄດ້ອີກຕໍ່ໄປ.

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

ຂອບໃຈທີ່ໄດ້ອ່ານບົດຄວາມຂອງຂ້ອຍ. ພົບກັນໃໝ່ໃນຄັ້ງຕໍ່ໄປ.