ບໍ່ແມ່ນ New Relic ດຽວ: ​​ເບິ່ງ Datadog ແລະ Atatus

ໃນສະພາບແວດລ້ອມຂອງວິສະວະກອນ SRE / DevOps, ມັນຈະບໍ່ແປກໃຈຜູ້ໃດທີ່ມື້ຫນຶ່ງລູກຄ້າ (ຫຼືລະບົບການຕິດຕາມ) ປາກົດແລະລາຍງານວ່າ "ທຸກສິ່ງທຸກຢ່າງສູນເສຍ": ເວັບໄຊທ໌ບໍ່ເຮັດວຽກ, ການຈ່າຍເງິນບໍ່ຜ່ານ, ຊີວິດຈະເສື່ອມໂຊມ. ... ບໍ່ວ່າເຈົ້າຢາກຊ່ວຍໃນສະຖານະການດັ່ງກ່າວຫຼາຍປານໃດ, ມັນເປັນໄປໄດ້ຍາກຫຼາຍທີ່ຈະເຮັດສິ່ງນີ້ໂດຍບໍ່ມີເຄື່ອງມືທີ່ງ່າຍດາຍແລະເຂົ້າໃຈໄດ້. ເລື້ອຍໆບັນຫາໄດ້ຖືກເຊື່ອງໄວ້ໃນລະຫັດຄໍາຮ້ອງສະຫມັກຕົວມັນເອງ;

ແລະ​ໃນ​ຄວາມ​ໂສກ​ເສົ້າ​ແລະ​ຄວາມ​ສຸກ ...

ມັນ​ໄດ້​ເກີດ​ຂຶ້ນ​ດັ່ງ​ນັ້ນ​ພວກ​ເຮົາ​ໄດ້​ຕົກ​ລົງ​ໃນ​ຄວາມ​ຮັກ​ຍາວ​ແລະ​ເລິກ​ກັບ New Relic​. ມັນແມ່ນແລະຍັງຄົງເປັນເຄື່ອງມືທີ່ດີເລີດສໍາລັບການຕິດຕາມກວດກາການປະຕິບັດຄໍາຮ້ອງສະຫມັກ, ແລະຍັງຊ່ວຍໃຫ້ທ່ານສາມາດເຄື່ອງມືຂອງສະຖາປັດຕະຍະກໍາຈຸລະພາກ (ການນໍາໃຊ້ຕົວແທນຂອງມັນ) ແລະຫຼາຍ, ມີຫຼາຍຫຼາຍ. ແລະທຸກສິ່ງທຸກຢ່າງອາດຈະດີຖ້າມັນບໍ່ແມ່ນສໍາລັບການປ່ຽນແປງນະໂຍບາຍລາຄາຂອງການບໍລິການ: ມັນ ຄ່າ​ໃຊ້​ຈ່າຍ ຈາກປີ 2013 ເພີ່ມຂຶ້ນ 3+ ເທົ່າ. ນອກຈາກນັ້ນ, ນັບຕັ້ງແຕ່ປີທີ່ຜ່ານມາ, ການໄດ້ຮັບບັນຊີທົດລອງຮຽກຮ້ອງໃຫ້ມີການສື່ສານກັບຜູ້ຈັດການສ່ວນບຸກຄົນ, ເຊິ່ງເຮັດໃຫ້ມັນຍາກທີ່ຈະນໍາສະເຫນີຜະລິດຕະພັນໃຫ້ກັບລູກຄ້າທີ່ມີທ່າແຮງ.

ສະຖານະການປົກກະຕິ: New Relic ແມ່ນບໍ່ຈໍາເປັນໃນ "ພື້ນຖານຖາວອນ"; ແຕ່ທ່ານຍັງຕ້ອງຈ່າຍເປັນປະຈໍາ (140 ໂດລາຕໍ່ເຄື່ອງແມ່ຂ່າຍຕໍ່ເດືອນ), ແລະໃນໂຄງສ້າງພື້ນຖານຂອງຄລາວທີ່ຂະຫຍາຍອັດຕະໂນມັດ, ຜົນລວມຈະເພີ່ມຂຶ້ນຢ່າງຫຼວງຫຼາຍ. ເຖິງແມ່ນວ່າມີທາງເລືອກ Pay-As-You-Go, ການເປີດໃຊ້ New Relic ຈະຮຽກຮ້ອງໃຫ້ທ່ານ restart ຄໍາຮ້ອງສະຫມັກ, ເຊິ່ງອາດຈະນໍາໄປສູ່ການສູນເສຍສະຖານະການທີ່ມີບັນຫາສໍາລັບການເລີ່ມຕົ້ນທັງຫມົດ. ບໍ່ດົນມານີ້, New Relic ໄດ້ນໍາສະເຫນີແຜນການອັດຕາພາສີໃຫມ່ - Essentials, - ເຊິ່ງຢູ່ glance ທໍາອິດເບິ່ງຄືວ່າເປັນທາງເລືອກທີ່ສົມເຫດສົມຜົນກັບ Professional ... ແຕ່ເມື່ອການກວດກາຢ່າງໃກ້ຊິດ, ມັນໄດ້ເຫັນວ່າບາງຫນ້າທີ່ທີ່ສໍາຄັນຂາດຫາຍໄປ (ໂດຍສະເພາະ, ມັນບໍ່ມີ. ທຸລະກໍາທີ່ສໍາຄັນ, Cross Application Tracing, ການຕິດຕາມການແຈກຢາຍ).

ດັ່ງນັ້ນ, ພວກເຮົາເລີ່ມຄິດກ່ຽວກັບການຊອກຫາທາງເລືອກທີ່ມີລາຄາຖືກກວ່າ, ແລະທາງເລືອກຂອງພວກເຮົາຫຼຸດລົງໃນສອງບໍລິການ: Datadog ແລະ Atatus. ເປັນຫຍັງເຂົາເຈົ້າ?

ກ່ຽວກັບຄູ່ແຂ່ງ

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

• ສະຫນັບສະຫນູນການກໍ່ສ້າງແລະພັດທະນາສໍາລັບຄໍາຮ້ອງສະຫມັກ PHP ( stack ຂອງລູກຄ້າຂອງພວກເຮົາແມ່ນມີຄວາມຫຼາກຫຼາຍຫຼາຍ, ແຕ່ນີ້ແມ່ນຜູ້ນໍາທີ່ຊັດເຈນໃນແງ່ຂອງການຄົ້ນຫາທາງເລືອກໃຫມ່ສໍາລັບ New Relic);
• ຄ່າໃຊ້ຈ່າຍທີ່ເຫມາະສົມ (ຫນ້ອຍກວ່າ 100 USD ຕໍ່ເດືອນຕໍ່ເຈົ້າພາບ);
• ເຄື່ອງມືອັດຕະໂນມັດ;
• ການປະສົມປະສານກັບ Kubernetes;
• ຄວາມຄ້າຍຄືກັນກັບການໂຕ້ຕອບ New Relic ແມ່ນການບວກທີ່ສັງເກດເຫັນ (ເພາະວ່າວິສະວະກອນຂອງພວກເຮົາຖືກນໍາໃຊ້ກັບມັນ).

ດັ່ງນັ້ນ, ໃນຂັ້ນຕອນການຄັດເລືອກເບື້ອງຕົ້ນ, ພວກເຮົາໄດ້ລົບລ້າງວິທີແກ້ໄຂທີ່ນິຍົມອື່ນໆ, ແລະໂດຍສະເພາະ:

• Tideways, AppDynamics ແລະ Dynatrace - ສໍາລັບຄ່າໃຊ້ຈ່າຍ;
• Stackify ຖືກບລັອກຢູ່ໃນສະຫະພັນລັດເຊຍແລະສະແດງຂໍ້ມູນຫນ້ອຍເກີນໄປ.

ສ່ວນທີ່ເຫຼືອຂອງບົດຄວາມແມ່ນໂຄງສ້າງໃນລັກສະນະທີ່ວິທີແກ້ໄຂໃນຄໍາຖາມທໍາອິດຈະຖືກນໍາສະເຫນີສັ້ນໆ, ຫຼັງຈາກນັ້ນຂ້າພະເຈົ້າຈະເວົ້າກ່ຽວກັບການໂຕ້ຕອບແບບປົກກະຕິຂອງພວກເຮົາກັບ New Relic ແລະປະສົບການ / ຄວາມປະທັບໃຈຈາກການປະຕິບັດທີ່ຄ້າຍຄືກັນໃນການບໍລິການອື່ນໆ.

ການນໍາສະເຫນີຜູ້ແຂ່ງຂັນທີ່ເລືອກ

ກ່ຽວກັບ New Relic, ອາດຈະທຸກຄົນໄດ້ຍິນ? ການບໍລິການນີ້ໄດ້ເລີ່ມຕົ້ນການພັດທະນາຂອງຕົນຫຼາຍກວ່າ 10 ປີກ່ອນຫນ້ານີ້, ໃນປີ 2008. ພວກເຮົາໄດ້ໃຊ້ມັນຢ່າງຫ້າວຫັນຕັ້ງແຕ່ປີ 2012 ແລະບໍ່ມີບັນຫາໃນການລວມເອົາຄໍາຮ້ອງສະຫມັກຈໍານວນຫລາຍໃນ PHP, Ruby ແລະ Python, ແລະພວກເຮົາຍັງມີປະສົບການປະສົມປະສານກັບ C# ແລະ Go. ຜູ້ຂຽນຂອງການບໍລິການມີວິທີແກ້ໄຂສໍາລັບຄໍາຮ້ອງສະຫມັກຕິດຕາມກວດກາ, ໂຄງສ້າງພື້ນຖານ, tracing microservice infrastructures, ສ້າງຄໍາຮ້ອງສະຫມັກສະດວກສໍາລັບອຸປະກອນຜູ້ໃຊ້, ແລະມີຫຼາຍຫຼາຍ.

ຢ່າງໃດກໍ່ຕາມ, ຕົວແທນ New Relic ເຮັດວຽກຢູ່ໃນໂປຣໂຕຄອນທີ່ເປັນເຈົ້າຂອງ ແລະ ບໍ່ຮອງຮັບ OpenTracing. ເຄື່ອງມືຂັ້ນສູງຮຽກຮ້ອງໃຫ້ມີການແກ້ໄຂໂດຍສະເພາະສໍາລັບ New Relic. ສຸດທ້າຍ, ການຊ່ວຍເຫຼືອ Kubernetes ແມ່ນຍັງທົດລອງຢູ່.

ໄດ້​ເລີ່ມ​ຕົ້ນ​ການ​ພັດ​ທະ​ນາ​ຂອງ​ຕົນ​ໃນ​ປີ 2010​ datadog ເບິ່ງຄືວ່າຫນ້າສົນໃຈຫຼາຍກ່ວາ New Relic ຢ່າງແນ່ນອນໃນແງ່ຂອງການນໍາໃຊ້ໃນສະພາບແວດລ້ອມ Kubernetes. ໂດຍສະເພາະ, ມັນສະຫນັບສະຫນູນການເຊື່ອມໂຍງກັບ NGINX Ingress, ການເກັບກໍາຂໍ້ມູນບັນທຶກ, statsd ແລະ OpenTracing protocols, ເຊິ່ງຊ່ວຍໃຫ້ທ່ານສາມາດຕິດຕາມຄໍາຮ້ອງຂໍຂອງຜູ້ໃຊ້ຈາກເວລາທີ່ມັນເຊື່ອມຕໍ່ກັບສໍາເລັດ, ເຊັ່ນດຽວກັນກັບຊອກຫາບັນທຶກສໍາລັບຄໍາຮ້ອງຂໍນີ້ (ທັງຢູ່ໃນເວັບເຊີຟເວີ. ແລະຜູ້ບໍລິໂພກ).

ເມື່ອໃຊ້ Datadog, ພວກເຮົາພົບວ່າບາງຄັ້ງມັນສ້າງແຜນທີ່ microservice ບໍ່ຖືກຕ້ອງ, ແລະບາງຂໍ້ບົກຜ່ອງດ້ານວິຊາການ. ຕົວຢ່າງ, ມັນໄດ້ລະບຸປະເພດການບໍລິການທີ່ບໍ່ຖືກຕ້ອງ (ເຮັດຜິດ Django ສໍາລັບການບໍລິການຖານຄວາມຈໍາ) ແລະເຮັດໃຫ້ເກີດຄວາມຜິດພາດ 500 ໃນຄໍາຮ້ອງສະຫມັກ PHP ໂດຍໃຊ້ຫ້ອງສະຫມຸດ Predis ທີ່ນິຍົມ.

ອາຕາຕັສ — ເຄື່ອງ​ມື​ທີ່​ນ້ອຍ​ທີ່​ສຸດ​; ການ​ບໍ​ລິ​ການ​ໄດ້​ເປີດ​ຕົວ​ໃນ​ປີ 2014​. ງົບປະມານການຕະຫຼາດຂອງຕົນແມ່ນຈະແຈ້ງ inferior ກັບຄູ່ແຂ່ງທີ່ໄດ້ລະບຸໄວ້, ການກ່າວເຖິງແມ່ນມີຫຼາຍຫນ້ອຍທົ່ວໄປ. ຢ່າງໃດກໍ່ຕາມ, ເຄື່ອງມືຂອງມັນເອງແມ່ນຄ້າຍຄືກັນກັບ New Relic, ບໍ່ພຽງແຕ່ໃນຄວາມສາມາດຂອງມັນ (APM, ການກວດສອບຕົວທ່ອງເວັບ, ແລະອື່ນໆ), ແຕ່ຍັງມີລັກສະນະ.

ຂໍ້ບົກຜ່ອງທີ່ສໍາຄັນແມ່ນວ່າມັນສະຫນັບສະຫນູນ Node.js ແລະ PHP ເທົ່ານັ້ນ. ໃນທາງກົງກັນຂ້າມ, ມັນໄດ້ຖືກປະຕິບັດຢ່າງຈະແຈ້ງກ່ວາ Datadog. ບໍ່ເຫມືອນກັບອັນສຸດທ້າຍ, Atatus ບໍ່ຕ້ອງການແອັບພລິເຄຊັນເພື່ອດັດແປງຫຼືເພີ່ມປ້າຍຕື່ມໃສ່ລະຫັດ.

ວິທີການທີ່ພວກເຮົາເຮັດວຽກກັບ New Relic

ຕອນນີ້ໃຫ້ພວກເຮົາຄິດອອກວ່າໂດຍທົ່ວໄປແລ້ວພວກເຮົາໃຊ້ New Relic ແນວໃດ. ໃຫ້ເວົ້າວ່າພວກເຮົາມີບັນຫາທີ່ຕ້ອງການການແກ້ໄຂ:

ມັນງ່າຍທີ່ຈະເຫັນໃນກາຟ splash - ຂໍໃຫ້ວິເຄາະມັນ. ໃນ New Relic, ການເຮັດທຸລະກໍາເວັບຖືກເລືອກທັນທີສໍາລັບຄໍາຮ້ອງສະຫມັກເວັບໄຊຕ໌, ອົງປະກອບທັງຫມົດແມ່ນສະແດງຢູ່ໃນເສັ້ນສະແດງຜົນ, ມີຂໍ້ຜິດພາດ, ອັດຕາຄໍາຮ້ອງຂໍ, ກະດານອັດຕາ ... ສິ່ງທີ່ສໍາຄັນທີ່ສຸດແມ່ນໂດຍກົງຈາກແຜງເຫຼົ່ານີ້ທ່ານສາມາດຍ້າຍລະຫວ່າງທີ່ແຕກຕ່າງກັນ. ພາກສ່ວນຂອງແອັບພລິເຄຊັນ (ຕົວຢ່າງ, ການຄລິກໃສ່ MySQL ຈະນໍາໄປສູ່ສ່ວນຖານຂໍ້ມູນ).

ເນື່ອງຈາກວ່າຢູ່ໃນຕົວຢ່າງພາຍໃຕ້ການພິຈາລະນາພວກເຮົາເຫັນວ່າກິດຈະກໍາເພີ່ມຂຶ້ນ PHP, ໃຫ້ຄລິກໃສ່ຕາຕະລາງນີ້ແລະອັດຕະໂນມັດໄປ Transactions:

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

• ຕົວຄວບຄຸມຄໍາຮ້ອງສະຫມັກທີ່ໂຫລດຫຼາຍທີ່ສຸດ;
• ຕົວຄວບຄຸມທີ່ຮ້ອງຂໍເລື້ອຍໆທີ່ສຸດ;
• ຊ້າທີ່ສຸດຂອງຕົວຄວບຄຸມ.

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

ສຸດທ້າຍ, ແອັບພລິເຄຊັນເກັບຕົວຢ່າງຂອງຮ່ອງຮອຍຂອງຄໍາຮ້ອງຂໍຍາວ (ຜູ້ທີ່ໃຊ້ເວລາຫຼາຍກວ່າ 2 ວິນາທີ). ນີ້ແມ່ນກະດານສໍາລັບການເຮັດທຸລະກໍາທີ່ຍາວນານ:

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

ແລະໃນ ການສອບຖາມຖານຂໍ້ມູນ — ການ​ປະ​ເມີນ​ການ​ສອບ​ຖາມ​ກັບ​ຖານ​ຂໍ້​ມູນ​ທີ່​ໄດ້​ຮັບ​ການ​ປະ​ຕິ​ບັດ​ໃນ​ຂະ​ນະ​ທີ່​ຄໍາ​ຮ້ອງ​ສະ​ຫມັກ​ກໍາ​ລັງ​ແລ່ນ​:

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

• ຍາວ PDO::Construct ໄດ້ນໍາພາພວກເຮົາໄປສູ່ການເຮັດວຽກທີ່ແປກປະຫຼາດຂອງ pgpoll;
• ຄວາມບໍ່ສະຖຽນລະພາບໃນໄລຍະເວລາ Memcache::Get ແນະນໍາວ່າເຄື່ອງ virtual ໄດ້ຖືກຕັ້ງຄ່າບໍ່ຖືກຕ້ອງ;
• ເວລາທີ່ເພີ່ມຂຶ້ນຢ່າງໜ້າສົງໄສສຳລັບການປະມວນຜົນແມ່ແບບໄດ້ນຳໄປສູ່ການຕິດພັນກັນເພື່ອກວດສອບການມີ 500 ຮູບແທນຕົວຢູ່ໃນບ່ອນເກັບມ້ຽນວັດຖຸ;
• ແລະອື່ນໆ…

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

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

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

ຄູ່ແຂ່ງ: ໂອກາດແລະຄວາມປະທັບໃຈ

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

1.Datadog

Datadog ທັກທາຍພວກເຮົາດ້ວຍກະດານທີ່ມີຝາບໍລິການ:

ມັນພະຍາຍາມທໍາລາຍຄໍາຮ້ອງສະຫມັກເຂົ້າໄປໃນອົງປະກອບ / ການບໍລິການຈຸລະພາກ, ດັ່ງນັ້ນໃນຕົວຢ່າງຂອງຄໍາຮ້ອງສະຫມັກ Django ພວກເຮົາຈະເຫັນ 2 ການເຊື່ອມຕໍ່ກັບ PostgreSQL (defaultdb и postgres), ເຊັ່ນດຽວກັນກັບ Celery, Redis. ການເຮັດວຽກກັບ Datadog ຮຽກຮ້ອງໃຫ້ທ່ານມີຄວາມຮູ້ຫນ້ອຍກ່ຽວກັບຫຼັກການ MVC: ທ່ານຈໍາເປັນຕ້ອງເຂົ້າໃຈວ່າຄໍາຮ້ອງຂໍຂອງຜູ້ໃຊ້ໂດຍທົ່ວໄປແມ່ນມາຈາກໃສ. ນີ້ປົກກະຕິແລ້ວຈະຊ່ວຍໄດ້ ແຜນ​ທີ່​ການ​ບໍ​ລິ​ການ​:

ໂດຍວິທີທາງການ, ມີບາງສິ່ງບາງຢ່າງທີ່ຄ້າຍຄືກັນໃນ New Relic:

... ແລະແຜນທີ່ຂອງພວກເຂົາ, ໃນຄວາມຄິດເຫັນຂອງຂ້ອຍ, ແມ່ນເຮັດໃຫ້ງ່າຍດາຍແລະຊັດເຈນກວ່າ: ມັນບໍ່ໄດ້ສະແດງອົງປະກອບຂອງຄໍາຮ້ອງສະຫມັກຫນຶ່ງ (ເຊິ່ງຈະເຮັດໃຫ້ລາຍລະອຽດເກີນໄປ, ເຊັ່ນດຽວກັບກໍລະນີຂອງ Datadog), ແຕ່ວ່າການບໍລິການສະເພາະຫຼື microservices ເທົ່ານັ້ນ.

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

ແຕ່ຫນ້າເສຍດາຍ, ບໍ່ມີກາຟຢູ່ທີ່ນີ້ໂດຍຄ່າເລີ່ມຕົ້ນ ເວ​ລາ​ການ​ເຮັດ​ທຸ​ລະ​ກໍາ​ເວັບ​, ຄ້າຍຄືກັນກັບສິ່ງທີ່ພວກເຮົາເຫັນຢູ່ໃນກະດານ New Relic ຕົ້ນຕໍ. ຢ່າງໃດກໍຕາມ, ມັນສາມາດຖືກຕັ້ງຄ່າໃນສະຖານທີ່ຂອງຕາຕະລາງ % ຂອງເວລາທີ່ໃຊ້. ມັນພຽງພໍທີ່ຈະປ່ຽນເປັນ ເວລາສະເລ່ຍຕໍ່ການຮ້ອງຂໍໂດຍປະເພດ... ແລະໃນປັດຈຸບັນເສັ້ນສະແດງທີ່ຄຸ້ນເຄີຍກໍາລັງຊອກຫາຢູ່ໃນພວກເຮົາ!

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

ແຕ່ຂ້ອຍພໍໃຈກັບຄວາມສາມາດໃນ Datadog ເພື່ອປ່ຽນຈາກກາຟເຫຼົ່ານີ້ໄປຫາ metrics ຂອງເຄື່ອງແມ່ຂ່າຍທີ່ກ່ຽວຂ້ອງ, ອ່ານບັນທຶກແລະປະເມີນການໂຫຼດໃນ web server handlers (Gunicorn). ທຸກສິ່ງທຸກຢ່າງແມ່ນເກືອບຄືກັນກັບໃນ New Relic ... ແລະເຖິງແມ່ນວ່າເລັກນ້ອຍ (ບັນທຶກ)!

ຂ້າງລຸ່ມນີ້ກຣາຟແມ່ນການເຮັດທຸລະກໍາທີ່ຄ້າຍຄືກັບ New Relic:

ໃນ Datadog, ການເຮັດທຸລະກໍາແມ່ນເອີ້ນວ່າ ຊັບ​ພະ​ຍາ​ກອນ. ທ່ານ​ສາ​ມາດ​ຈັດ​ລຽງ​ລໍາ​ດັບ​ການ​ຄວບ​ຄຸມ​ໂດຍ​ຈ​ໍ​າ​ນວນ​ຂອງ​ການ​ຮ້ອງ​ຂໍ​, ໂດຍ​ການ​ຕອບ​ສະ​ຫນອງ​ໂດຍ​ສະ​ເລ່ຍ​, ແລະ​ໂດຍ​ການ​ໃຊ້​ເວ​ລາ​ສູງ​ສຸດ​ສໍາ​ລັບ​ໄລ​ຍະ​ເວ​ລາ​ທີ່​ເລືອກ​.

ທ່ານສາມາດຂະຫຍາຍຊັບພະຍາກອນແລະເບິ່ງທຸກສິ່ງທຸກຢ່າງທີ່ພວກເຮົາໄດ້ສັງເກດເຫັນແລ້ວໃນ New Relic:

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

ຊັບພະຍາກອນຕົວຢ່າງໃດນຶ່ງໃນ Datadog ສາມາດເປີດ ແລະສຶກສາໄດ້:

ຕົວກໍານົດການຮ້ອງຂໍ, ຕາຕະລາງສະຫຼຸບຂອງເວລາທີ່ໃຊ້ໃນແຕ່ລະອົງປະກອບ, ແລະຕາຕະລາງນ້ໍາຕົກສະແດງໃຫ້ເຫັນລໍາດັບຂອງການໂທໄດ້ຖືກນໍາສະເຫນີ. ນອກນັ້ນທ່ານຍັງສາມາດປ່ຽນໄປເບິ່ງຕົ້ນໄມ້ຂອງຕາຕະລາງນ້ໍາຕົກ:

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

ການປະສົມປະສານທີ່ຍິ່ງໃຫຍ່!

ເຈົ້າອາດຈະສົງໄສວ່າແຖບຢູ່ໃສ ຖານຂໍ້ມູນ и ບໍລິການພາຍນອກ, ໃນ New Relic. ບໍ່ມີຢູ່ທີ່ນີ້: ນັບຕັ້ງແຕ່ Datadog decomposes ຄໍາຮ້ອງສະຫມັກເຂົ້າໄປໃນອົງປະກອບ, PostgreSQL ຈະຖືກພິຈາລະນາ ການບໍລິການແຍກຕ່າງຫາກ, ແລະແທນທີ່ຈະເປັນການບໍລິການພາຍນອກ, ມັນຄຸ້ມຄ່າທີ່ຈະຊອກຫາ aws.storage (ມັນຈະຄ້າຍຄືກັນກັບທຸກໆບໍລິການພາຍນອກອື່ນໆທີ່ແອັບພລິເຄຊັນສາມາດເຂົ້າເຖິງໄດ້).

ນີ້ແມ່ນຕົວຢ່າງທີ່ມີ postgres:

ໂດຍພື້ນຖານແລ້ວ, ມີທຸກສິ່ງທຸກຢ່າງທີ່ພວກເຮົາຕ້ອງການ:

ທ່ານ​ສາ​ມາດ​ເບິ່ງ​ວ່າ "ການ​ບໍ​ລິ​ການ​" ການ​ຮ້ອງ​ຂໍ​ໄດ້​ມາ​ຈາກ​.

ມັນຈະບໍ່ພາດທີ່ຈະເຕືອນທ່ານວ່າ Datadog ປະສົມປະສານຢ່າງສົມບູນແບບກັບ NGINX Ingress ແລະຊ່ວຍໃຫ້ທ່ານສາມາດປະຕິບັດການຕິດຕາມແບບສິ້ນສຸດຈາກເວລາທີ່ຄໍາຮ້ອງຂໍເຂົ້າມາໃນກຸ່ມ, ແລະຍັງຊ່ວຍໃຫ້ທ່ານໄດ້ຮັບ statsd metrics, ເກັບກໍາຂໍ້ມູນບັນທຶກແລະ host metrics. .

ບວກໃຫຍ່ຂອງ Datadog ແມ່ນວ່າລາຄາຂອງມັນ ພັດທະນາ ຈາກການຕິດຕາມໂຄງສ້າງພື້ນຖານ, APM, ການຄຸ້ມຄອງບັນທຶກແລະການທົດສອບສັງເຄາະ, i.e. ທ່ານສາມາດເລືອກແຜນຂອງທ່ານແບບຍືດຫຍຸ່ນ.

2.Atatus

ທີມງານ Atatus ອ້າງວ່າການບໍລິການຂອງພວກເຂົາແມ່ນ "ຄືກັນກັບ New Relic, ແຕ່ດີກວ່າ." ໃຫ້​ເຮົາ​ເບິ່ງ​ວ່າ​ນີ້​ແມ່ນ​ແທ້​.

ແຜງຕົ້ນຕໍມີລັກສະນະຄ້າຍຄືກັນ, ແຕ່ວ່າມັນບໍ່ສາມາດກໍານົດ Redis ແລະ memcached ທີ່ໃຊ້ໃນແອັບພລິເຄຊັນ.

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

ໃນການເຮັດທຸລະກໍາ Atatus, ທຸກສິ່ງທຸກຢ່າງແມ່ນຄ້າຍຄືກັນເທົ່າທີ່ເປັນໄປໄດ້ກັບ New Relic. ການຫຼຸດລົງແມ່ນວ່ານະໂຍບາຍດ້ານສໍາລັບແຕ່ລະຕົວຄວບຄຸມແມ່ນບໍ່ເຫັນທັນທີທັນໃດ. ທ່ານຕ້ອງຊອກຫາມັນຢູ່ໃນຕາຕະລາງຄວບຄຸມ, ຈັດຮຽງຕາມ ໃຊ້ເວລາຫຼາຍທີ່ສຸດ:

ບັນຊີລາຍຊື່ປົກກະຕິຂອງຕົວຄວບຄຸມແມ່ນມີຢູ່ໃນແຖບ ໂຄງການຂຸດຄົ້ນ:

ໃນບາງວິທີ, ຕາຕະລາງນີ້ແມ່ນ reminiscent ຂອງ Datadog ແລະຂ້າພະເຈົ້າມັກມັນດີກວ່າຫນຶ່ງທີ່ຄ້າຍຄືກັນໃນ New Relic.

ທ່ານສາມາດຂະຫຍາຍແຕ່ລະທຸລະກໍາແລະເບິ່ງວ່າແອັບພລິເຄຊັນກໍາລັງເຮັດຫຍັງ:

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

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

ໂດຍທົ່ວໄປ, Atatus ພໍໃຈກັບຮ່ອງຮອຍລະອຽດ - ໂດຍບໍ່ມີການປົກກະຕິຂອງ New Relic gluing ຂອງການໂທເຂົ້າໄປໃນຕັນເຕືອນ:

ຢ່າງໃດກໍ່ຕາມ, ມັນຂາດຕົວກອງທີ່ (ເຊັ່ນ New Relic) ຈະຕັດການຮ້ອງຂໍທີ່ໄວທີ່ສຸດ (<5ms). ໃນທາງກົງກັນຂ້າມ, ຂ້ອຍມັກການສະແດງຜົນຕອບໂຕ້ການເຮັດທຸລະກໍາສຸດທ້າຍ (ຄວາມສໍາເລັດຫຼືຄວາມຜິດພາດ).

ກະດານ ຖານຂໍ້ມູນ ຈະຊ່ວຍໃຫ້ທ່ານສຶກສາການຮ້ອງຂໍກັບຖານຂໍ້ມູນພາຍນອກທີ່ແອັບພລິເຄຊັນເຮັດ. ຂ້າພະເຈົ້າຂໍເຕືອນທ່ານວ່າ Atatus ພົບເຫັນພຽງແຕ່ PostgreSQL ແລະ MySQL, ເຖິງແມ່ນວ່າ Redis ແລະ memcached ຍັງມີສ່ວນຮ່ວມໃນໂຄງການ.

ການຮ້ອງຂໍຖືກຈັດຮຽງຕາມເງື່ອນໄຂປົກກະຕິ: ຄວາມຖີ່ຂອງການຕອບສະຫນອງ, ເວລາຕອບສະຫນອງສະເລ່ຍ, ແລະອື່ນໆ. ຂ້າພະເຈົ້າຍັງຢາກກ່າວເຖິງແຖບທີ່ມີການສອບຖາມທີ່ຊ້າທີ່ສຸດ - ມັນສະດວກຫຼາຍ. ຍິ່ງໄປກວ່ານັ້ນ, ຂໍ້ມູນໃນແຖບນີ້ສໍາລັບ PostgreSQL coincided ກັບຂໍ້ມູນຈາກການຂະຫຍາຍ pg_stat_statements - ຜົນ​ໄດ້​ຮັບ​ທີ່​ດີ​ເລີດ​!

ແຖບ ການຮ້ອງຂໍພາຍນອກ ຄືກັນກັບຖານຂໍ້ມູນ.

ການຄົ້ນພົບ

ທັງສອງເຄື່ອງມືທີ່ນໍາສະເຫນີປະຕິບັດໄດ້ດີໃນບົດບາດຂອງ APM. ໃດໆຂອງພວກເຂົາສາມາດສະເຫນີຕໍາ່ສຸດທີ່ທີ່ກໍານົດໄວ້. ຄວາມປະທັບໃຈຂອງພວກເຮົາສາມາດສະຫຼຸບສັ້ນໆໄດ້ດັ່ງນີ້:

datadog

Pros:

• ຕາຕະລາງອັດຕາພາສີສະດວກ (APM ຄ່າໃຊ້ຈ່າຍ 31 USD ຕໍ່ເຈົ້າພາບ);
• ເຮັດວຽກໄດ້ດີກັບ Python;
• ຄວາມເປັນໄປໄດ້ຂອງການເຊື່ອມໂຍງກັບ OpenTracing
• ການປະສົມປະສານກັບ Kubernetes;
• ການປະສົມປະສານກັບ NGINX Ingress.

Cons:

• APM ອັນດຽວທີ່ເຮັດໃຫ້ແອັບພລິເຄຊັນບໍ່ສາມາດໃຊ້ໄດ້ເນື່ອງຈາກຄວາມຜິດພາດຂອງໂມດູນ (predis);
• PHP ເຄື່ອງມືອັດຕະໂນມັດທີ່ອ່ອນແອ;
• ຄໍານິຍາມທີ່ແປກປະຫລາດບາງສ່ວນຂອງການບໍລິການແລະຈຸດປະສົງຂອງພວກເຂົາ.

ອາຕາຕັສ

Pros:

• ເຄື່ອງມື PHP ເລິກ;
• ການໂຕ້ຕອບຜູ້ໃຊ້ຄ້າຍຄືກັນກັບ New Relic.

Cons:

• ບໍ່ເຮັດວຽກໃນລະບົບປະຕິບັດການເກົ່າ (Ubuntu 12.05, CentOS 5);
• ເຄື່ອງ​ມື​ອັດ​ຕະ​ໂນ​ມັດ​ອ່ອນ​ແອ​;
• ສະຫນັບສະຫນູນພຽງແຕ່ສອງພາສາ (Node.js ແລະ PHP);
• ການໂຕ້ຕອບຊ້າ.

ພິຈາລະນາລາຄາຂອງ Atatus ຂອງ 69 USD ຕໍ່ເດືອນຕໍ່ເຄື່ອງແມ່ຂ່າຍ, ພວກເຮົາແທນທີ່ຈະໃຊ້ Datadog, ເຊິ່ງປະສົມປະສານກັບຄວາມຕ້ອງການຂອງພວກເຮົາ (ຄໍາຮ້ອງສະຫມັກເວັບໃນ K8s) ແລະມີຄຸນສົມບັດທີ່ເປັນປະໂຫຍດຫຼາຍ.

PS

ອ່ານຍັງຢູ່ໃນ blog ຂອງພວກເຮົາ:

• «ເຄື່ອງມືສໍາລັບນັກພັດທະນາແອັບພລິເຄຊັນທີ່ເຮັດວຽກຢູ່ໃນ Kubernetes"
• «ປັ໊ກອິນ kubectl-debug ສຳລັບການດີບັກໃນພອດ Kubernetes"
• «Microservices: ຂະຫນາດເປັນເລື່ອງສໍາຄັນ, ເຖິງແມ່ນວ່າທ່ານມີ Kubernetes".

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