Network Monitoring ເບື້ອງຕົ້ນ: ຮູ້ບັນຫາກ່ອນໂທລະສັບຈະດັງ

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

ນີ້ແມ່ນສິ່ງທີ່ເກີດຂຶ້ນເມື່ອບໍ່ມີ Monitoring: ທີມ IT ຮູ້ບັນຫາຫຼັງຈາກຜູ້ໃຊ້. ລະບົບ Monitoring ປີ້ນລຳດັບນັ້ນ. ມັນບອກວ່າສາຍສຳຮອງລົ້ມ, Disk ຂອງ NVR ໃກ້ເຕັມ, ອຸນຫະພູມໃນຕູ້ກຳລັງຂຶ້ນ ຫຼື UPS ກຳລັງແລ່ນດ້ວຍແບັດເຕີຣີ ກ່ອນທີ່ມັນຈະກາຍເປັນບັນຫາຂອງທຸກຄົນ. ແລະ ມັນເກັບຂໍ້ມູນຍ້ອນຫຼັງ ເພື່ອວາງແຜນວ່າເມື່ອໃດຕ້ອງເພີ່ມແບນວິດ ຫຼື Disk.

ຕິດຕາມຫຍັງແດ່

ແຖວສຸດທ້າຍມັກຖືກລືມ. License ຂອງ Firewall ທີ່ໝົດອາຍຸ ອາດເຮັດໃຫ້ IPS ແລະ Web Filter ຢຸດອັບເດດແບບງຽບໆ ໂດຍບໍ່ມີໃຜສັງເກດ.

ເຄື່ອງມືແຕ່ລະອັນເຮັດຫຍັງ

ICMP (Ping) ຕອບຄຳຖາມດຽວ: ອຸປະກອນຍັງຢູ່ບໍ? ງ່າຍທີ່ສຸດ ແລະ ເປັນຈຸດເລີ່ມຕົ້ນທີ່ດີ.

SNMP ອ່ານຄ່າຈາກ Switch, Firewall, UPS ແລະ ເຄື່ອງພິມ: ແບນວິດ, CPU, ສະຖານະແບັດເຕີຣີ. ໃຊ້ SNMPv3 ທີ່ມີການຢືນຢັນຕົວຕົນ ແລະ ເຂົ້າລະຫັດ. SNMP v1/v2c ທີ່ໃຊ້ Community "public" ເປັນຄືການເປີດປະຕູໃຫ້ໃຜກໍ່ໄດ້ອ່ານການຕັ້ງຄ່າ.

Syslog ໃຫ້ອຸປະກອນສົ່ງ Log ເຫດການມາເກັບທີ່ສູນກາງ. ເມື່ອມີເລື່ອງເກີດຂຶ້ນ ທ່ານມີປະຫວັດໃຫ້ສືບ ເຖິງວ່າອຸປະກອນຈະ Reboot ແລະ Log ໃນເຄື່ອງຫາຍໄປແລ້ວ.

NetFlow / sFlow / IPFIX ຕອບຄຳຖາມ "ໃຜກິນແບນວິດ?" ເມື່ອອິນເຕີເນັດຊ້າທຸກບ່າຍ ມັນບອກວ່າແມ່ນ Windows Update, ການສຳຮອງຂໍ້ມູນຂຶ້ນ Cloud ຫຼື ໃຜຜູ້ໜຶ່ງເບິ່ງບານ.

API / Cloud Dashboard ອຸປະກອນ Cloud-managed ມັກມີການຕິດຕາມໃນໂຕ ທີ່ໃຊ້ໄດ້ທັນທີ.

ເລືອກເຄື່ອງມື

ສ່ວນຫຼາຍເຮົາເຫັນອົງກອນໃຊ້ສອງແບບລວມກັນ: Dashboard ຂອງຍີ່ຫໍ້ສຳລັບລາຍລະອຽດ Wi-Fi ແລະ Zabbix ຫຼື ເຄື່ອງມືຄ້າຍກັນສຳລັບທຸກຢ່າງອື່ນ ລວມທັງ UPS ແລະ ເຊັນເຊີອຸນຫະພູມ.

ຕົວຢ່າງທີ່ຄິດໃຫ້ເບິ່ງ: ຕິດຕາມ 60 ອຸປະກອນ ຕ້ອງໃຊ້ຫຍັງແດ່

ສຳນັກງານໃຫຍ່ ພ້ອມສອງສາຂາ: Firewall 2 ເຄື່ອງ, Switch 14 ໂຕ, Access Point 30 ໂຕ, UPS 3 ເຄື່ອງ, NVR 2 ເຄື່ອງ, Server 4 ເຄື່ອງ, ສາຍອິນເຕີເນັດ 3 ສາຍ ແລະ ເຊັນເຊີອຸນຫະພູມ 2 ໂຕ, ປະມານ 60 ອຸປະກອນ.

• ການດຶງຂໍ້ມູນ (Polling). ແຕ່ລະອຸປະກອນມີຄ່າທີ່ຄວນເກັບປະມານ 20–60 ຄ່າ (ພອດ, CPU, ອຸນຫະພູມ, ແບັດ). ດຶງນາທີລະເທື່ອ ແມ່ນປະມານ 3,000 ຄ່າຕໍ່ນາທີ, ຫຼື 50 ຄ່າຕໍ່ວິນາທີ. Virtual Machine ນ້ອຍໆ 2–4 vCPU ແລະ RAM 8 GB ຮັບໄດ້ສະບາຍ.
• ປະຫວັດ. ເກັບຂໍ້ມູນລະອຽດປະມານ 90 ມື້ ແລະ ແນວໂນ້ມລາຍຊົ່ວໂມງ ໜຶ່ງຫາສອງປີ. ສຳລັບຂະໜາດນີ້ ໃຊ້ດິສບໍ່ເຖິງ 100 GB.
• Bandwidth. ການດຶງ SNMP ຈາກ 60 ອຸປະກອນ ໃຊ້ພຽງບໍ່ເທົ່າໃດສິບ kbps. ເຖິງຈະຜ່ານ VPN ຂອງສາຂາ ກໍ່ບໍ່ມີໃຜສັງເກດເຫັນ.
• Wi-Fi. ອ່ານຂໍ້ມູນ AP 30 ໂຕ ຈາກ Controller ຫຼື Cloud Dashboard ຂອງຜູ້ຜະລິດ ແທນທີ່ຈະດຶງເທື່ອລະໂຕ, ແລະ ສົ່ງສະເພາະເຫດການສຳຄັນເຂົ້າເຄື່ອງມືສ່ວນກາງ.

ສ່ວນທີ່ຍາກບໍ່ແມ່ນ Server. ແຕ່ແມ່ນບ່າຍໜຶ່ງ ທີ່ຕ້ອງຈັດຊື່ອຸປະກອນໃຫ້ເປັນລະບຽບ, ເປີດ SNMPv3 ແລະ ຕັດສິນວ່າໃຜຮັບການແຈ້ງເຕືອນອັນໃດ.

ການແຈ້ງເຕືອນ: ໜ້ອຍ ແຕ່ຖືກ

ລະບົບທີ່ສົ່ງ 200 ຂໍ້ຄວາມຕໍ່ມື້ ຈະຖືກປິດສຽງພາຍໃນອາທິດດຽວ. ເຮົາເອີ້ນມັນວ່າ Alert Fatigue, ແລະ ມັນແມ່ນເຫດຜົນອັນດັບໜຶ່ງທີ່ Monitoring ລົ້ມເຫຼວ.

• ແຈ້ງສະເພາະສິ່ງທີ່ຕ້ອງມີຄົນລົງມືແກ້
• ແບ່ງລະດັບ: Warning (ເຊັ່ນ Disk 80%) ແລະ Critical (Disk 95%, Uplink ລົ້ມ)
• ສົ່ງໄປຊ່ອງທາງທີ່ທີມເບິ່ງແທ້: ອີເມວ, LINE, WhatsApp, Telegram
• ໃຊ້ Dependency: ຖ້າ Firewall ສາຂາລົ້ມ ບໍ່ຕ້ອງແຈ້ງອຸປະກອນ 40 ໂຕທີ່ຢູ່ຫຼັງມັນ
• ກຳນົດວ່າໃຜຮັບຜິດຊອບ ແລະ ຕ້ອງຕອບພາຍໃນຈັກນາທີ

ເກນເລີ່ມຕົ້ນທີ່ໃຊ້ໄດ້ຈິງ

ໃຊ້ເປັນຮ່າງທຳອິດ ແລ້ວປັບຫຼັງຈາກມີຂໍ້ມູນແທ້ໜຶ່ງເດືອນ:

ສັງເກດຊ່ວງເວລາ. ການແຈ້ງເຕືອນຈາກຄ່າຜິດປົກກະຕິຄັ້ງດຽວ ແມ່ນສິ່ງທີ່ສ້າງສຽງລົບກວນ; ສະພາບທີ່ຄ້າງຢູ່ຫ້າ ຫຼື ສິບຫ້ານາທີ ມັກເປັນເລື່ອງແທ້.

ເລີ່ມຕົ້ນໃນຫົກຂັ້ນ

1. ເຮັດບັນຊີອຸປະກອນທັງໝົດ ພ້ອມ IP ແລະ ຕຳແໜ່ງ
2. ເປີດ SNMPv3 ແລະ Syslog ໃນອຸປະກອນ, ອະນຸຍາດໃຫ້ສະເພາະເຊີບເວີ Monitoring ເຂົ້າ
3. ຕິດຕັ້ງເຊີບເວີ Monitoring (VM ຫຼື ເຄື່ອງນ້ອຍ) ໃນ VLAN Management
4. ເພີ່ມອຸປະກອນສຳຄັນກ່ອນ: Firewall, Core Switch, ສາຍ WAN, UPS, NVR
5. ຕັ້ງການແຈ້ງເຕືອນ ແລະ ທົດສອບວ່າມັນໄປຮອດແທ້
6. ທົບທວນລາຍງານແນວໂນ້ມທຸກເດືອນ

ຂັ້ນທີ 4 ສຳຄັນ. ຢ່າພະຍາຍາມເພີ່ມທຸກຢ່າງໃນມື້ທຳອິດ. ຫ້າອຸປະກອນທີ່ຖືກຕິດຕາມດີ ມີຄ່າກວ່າ 200 ອຸປະກອນທີ່ບໍ່ມີໃຜເບິ່ງ.

ສິ່ງທີ່ເຮັດໃຫ້ Monitoring ບໍ່ໄດ້ຜົນ

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

ມີອີກສາມຢ່າງທີ່ເຮົາພົບເລື້ອຍ. ກວດແຕ່ຈາກພາຍໃນ: ຖ້າສາຍອິນເຕີເນັດດັບ, Server Monitoring ກໍ່ສົ່ງການແຈ້ງເຕືອນອອກບໍ່ໄດ້, ສະນັ້ນໃຫ້ເພີ່ມການກວດຈາກພາຍນອກ, ບໍລິການ Ping ຈາກ Cloud ຫຼື Modem 4G ສຳລັບສົ່ງແຈ້ງເຕືອນ. ການແຈ້ງເຕືອນໄປຫາໂທລະສັບຄົນດຽວ, ເມື່ອຄົນນັ້ນລາພັກ ກໍ່ບໍ່ມີຫຍັງເກີດຂຶ້ນ. ແລະ ບໍ່ມີ Maintenance Window, ທຸກຄັ້ງທີ່ Reboot ຕາມແຜນ ກໍ່ແຈ້ງທຸກຄົນ ຈົນທຸກຄົນເຄີຍຊີນກັບການບໍ່ສົນໃຈແຈ້ງເຕືອນ.

Dashboard ສຳລັບຜູ້ບໍລິຫານ

ຜູ້ບໍລິຫານບໍ່ຕ້ອງການເຫັນກາຟ 50 ອັນ. ຕົວເລກຫ້າຕົວນີ້ພໍ:

ລາຍງານປະຈຳເດືອນແບບນີ້ ເຮັດໃຫ້ທີມ IT ຂໍງົບໂດຍມີຕົວເລກຮອງຮັບ ແທນທີ່ຈະເປັນຄວາມຮູ້ສຶກ. "UPS ແລ່ນດ້ວຍແບັດ 23 ຄັ້ງເດືອນນີ້" ໃຫ້ນ້ຳໜັກກວ່າ "ໄຟຢູ່ນີ້ບໍ່ດີ" ຫຼາຍ.

ສຳລັບອົງກອນໃນລາວ

ຖ້າມີທີມ IT ພາຍໃນ ເລີ່ມຈາກ Zabbix ຫຼື ເຄື່ອງມື Open source ຄ້າຍກັນ. ຖ້າທີມນ້ອຍ ຫຼື ບໍ່ມີ, ບໍລິການ Managed Monitoring ຄຸ້ມກວ່າການພະຍາຍາມດູແລເອງ.

ໃຫ້ຄວາມສຳຄັນກັບ UPS, ອຸນຫະພູມ ແລະ ສາຍອິນເຕີເນັດກ່ອນ. ສາມຢ່າງນີ້ແມ່ນບ່ອນທີ່ເຮົາເຫັນບັນຫາຫຼາຍທີ່ສຸດໃນລາວ. ສາຂາໃນແຂວງ ໃຫ້ຕິດຕາມຈາກວຽງຈັນຜ່ານ VPN ຫຼື SD-WAN. ແລະ ຂຽນຂໍ້ຄວາມແຈ້ງເຕືອນເປັນພາສາທີ່ທີມອ່ານເຂົ້າໃຈທັນທີ, ສົ່ງຜ່ານແອັບທີ່ເຂົາເປີດທຸກມື້.

ໝາຍເຫດເລື່ອງຊ່ອງທາງແຈ້ງເຕືອນ: LINE Notify ທີ່ລະບົບເກົ່າຫຼາຍແຫ່ງໃຊ້ສົ່ງແຈ້ງເຕືອນເຂົ້າກຸ່ມ LINE ໄດ້ປິດບໍລິການໃນປີ 2025. ຖ້າການແຈ້ງເຕືອນຂອງທ່ານໃຊ້ທາງນັ້ນ, ມັນໄດ້ຢຸດແລ້ວ. ຍ້າຍໄປໃຊ້ Bot ຜ່ານ LINE Messaging API, Telegram, WhatsApp ຫຼື ອີເມວ, ແລ້ວສົ່ງແຈ້ງເຕືອນທົດສອບເພື່ອຢືນຢັນ. ບໍ່ວ່າຈະເລືອກເຄື່ອງມືໃດ, ໃຫ້ໃຊ້ລຸ້ນ LTS (Long-Term Support) ໃນລະບົບຈິງ ແທນລຸ້ນທີ່ Support ສັ້ນທີ່ອອກມາລະຫວ່າງນັ້ນ.

ເລີ່ມຈາກຫ້າອຸປະກອນ

ບອກເຮົາວ່າຫ້າອຸປະກອນໃດທີ່ຖ້າດັບແລ້ວ ທຸລະກິດຂອງທ່ານຢຸດ (ສ່ວນຫຼາຍແມ່ນ Firewall, Core Switch, ສາຍອິນເຕີເນັດ, UPS ແລະ NVR ຫຼື ເຊີບເວີຫຼັກ). ເຮົາຈະສະເໜີວິທີຕິດຕາມ ແລະ ແຈ້ງເຕືອນສະເພາະຫ້າອັນນັ້ນກ່ອນ, ແລ້ວຄ່ອຍຂະຫຍາຍ.