🥇Зөвхөн Шинэ Relic биш: Датадог ба Ататусын харц

SRE/DevOps инженерүүдийн орчинд нэг л өдөр үйлчлүүлэгч (эсвэл хяналтын систем) гарч ирээд "бүх зүйл алдагдсан" гэж мэдээлэх нь хэнийг ч гайхшруулахгүй: сайт ажиллахгүй, төлбөр хийхгүй, амьдрал доройтож байна. ... Ийм нөхцөлд та хичнээн туслахыг хүсч байгаагаас үл хамааран энгийн бөгөөд ойлгомжтой хэрэгсэлгүйгээр үүнийг хийхэд маш хэцүү байх болно. Ихэнхдээ асуудал нь програмын кодонд нуугддаг тул та үүнийг нутагшуулах хэрэгтэй.

Мөн уй гашуу, баяр баясгалан дунд ...

Бид New Relic-д удаан, гүн гүнзгий дурласан юм. Энэ нь програмын гүйцэтгэлийг хянах маш сайн хэрэгсэл байсан бөгөөд одоо ч хэвээр байгаа бөгөөд микро үйлчилгээний архитектурыг (түүний агентыг ашиглан) болон бусад олон зүйлийг хийх боломжийг олгодог. Үйлчилгээний үнийн бодлогод өөрчлөлт ороогүй бол бүх зүйл сайхан байх байсан зардал 2013 жилээс 3+ дахин өссөн. Нэмж дурдахад, өнгөрсөн жилээс туршилтын данс авахын тулд хувийн менежертэй харилцах шаардлагатай байдаг бөгөөд энэ нь бүтээгдэхүүнийг боломжит худалдан авагчдад танилцуулахад хүндрэл учруулдаг.

Ердийн нөхцөл байдал: Шинэ дурсгалыг "байнгын" шаардлагагүй, тэд зөвхөн асуудал эхлэх үед л санаж байна. Гэсэн хэдий ч та тогтмол төлбөр хийх шаардлагатай хэвээр байна (сард нэг серверт 140 доллар), автоматаар масштабтай үүлэн дэд бүтцэд нийлбэр нь нэлээд том болно. Хэдийгээр Pay-As-You-Go сонголт байгаа ч New Relic-г идэвхжүүлснээр програмыг дахин эхлүүлэх шаардлагатай бөгөөд энэ нь бүх эхлүүлсэн асуудалтай нөхцөл байдлыг алдахад хүргэж болзошгүй юм. Тун удалгүй New Relic шинэ тарифын төлөвлөгөөг танилцуулав. Essentials, - энэ нь эхлээд харахад Мэргэжлийнхээс боломжийн хувилбар мэт харагдаж байгаа боловч сайтар судалж үзэхэд зарим чухал функцууд дутуу байгаа нь тодорхой болсон (ялангуяа, энэ нь байхгүй байна. Гол гүйлгээ, Cross Application Tracing, Тархсан мөрдөх).

Үүний үр дүнд бид илүү хямд хувилбар хайх талаар бодож эхэлсэн бөгөөд бидний сонголт Датадог, Ататус гэсэн хоёр үйлчилгээнд унасан. Яагаад тэдэн дээр?

Өрсөлдөгчийн тухай

Зах зээл дээр өөр шийдэл байгаа гэдгийг шууд хэлье. Бид Нээлттэй эхийн хувилбаруудыг ч авч үзсэн ч үйлчлүүлэгч бүр өөрөө өөртөө байршуулсан шийдлүүдийг байршуулах эрх чөлөөтэй байдаггүй... - Нэмж дурдахад тэд нэмэлт засвар үйлчилгээ хийх шаардлагатай болно. Бидний сонгосон хос хамгийн ойр дотно байсан бидний хэрэгцээ:

PHP програмуудад зориулсан суурилуулсан болон боловсруулсан дэмжлэг (манай үйлчлүүлэгчдийн стек нь маш олон янз байдаг, гэхдээ энэ нь New Relic-ээс өөр хувилбар хайх хүрээнд тодорхой удирдагч юм);
боломжийн зардал (нэг хост сард 100 доллараас бага);
автомат төхөөрөмж;
Кубернетестэй нэгтгэх;
New Relic интерфейстэй ижил төстэй байдал нь мэдэгдэхүйц давуу тал юм (манай инженерүүд үүнд дассан учраас).

Тиймээс, эхний сонгон шалгаруулалтын шатанд бид бусад алдартай шийдлүүдийг хассан, ялангуяа:

Tideways, AppDynamics болон Dynatrace - зардлын хувьд;
Stackify нь ОХУ-д хаагдсан бөгөөд хэт бага өгөгдөл харуулдаг.

Өгүүллийн үлдсэн хэсэг нь тухайн шийдлүүдийг эхлээд товч танилцуулах бөгөөд үүний дараа би New Relic-тэй хийсэн ердийн харилцан үйлчлэлийн талаар болон бусад үйлчилгээнд ижил төстэй үйлдлүүдийг гүйцэтгэх туршлага/сэтгэгдэлийн талаар ярих болно.

Сонгогдсон өрсөлдөгчдийн танилцуулга

дээр Шинэ Relic, хүн бүр сонссон байх? Энэхүү үйлчилгээ нь 10 гаруй жилийн өмнө буюу 2008 онд хөгжиж эхэлсэн. Бид 2012 оноос хойш үүнийг идэвхтэй ашиглаж байгаа бөгөөд PHP, Ruby, Python дээр үнэхээр олон тооны програмуудыг нэгтгэхэд ямар ч асуудал гараагүй бөгөөд C# болон Go-тэй нэгтгэсэн туршлагатай. Үйлчилгээний зохиогчид програмууд, дэд бүтцийг хянах, микро үйлчилгээний дэд бүтцийг хянах, хэрэглэгчийн төхөөрөмжүүдэд тохиромжтой програмуудыг бий болгох гэх мэт шийдлүүдтэй байдаг.

Гэсэн хэдий ч New Relic агент нь өмчийн протоколууд дээр ажилладаг бөгөөд OpenTracing-ийг дэмждэггүй. Нарийвчилсан багаж хэрэгсэл нь New Relic-д тусгайлан засвар хийхийг шаарддаг. Эцэст нь Kubernetes-ийн дэмжлэг туршилтын шинж чанартай хэвээр байна.

2010 онд бүтээн байгуулалтаа эхлүүлсэн Мэдээллийн систем Kubernetes орчинд ашиглах талаараа New Relic-ээс илүү сонирхолтой харагдаж байна. Ялангуяа энэ нь NGINX Ingress, бүртгэл цуглуулах, statsd болон OpenTracing протоколуудтай нэгтгэхийг дэмждэг бөгөөд энэ нь хэрэглэгчийн хүсэлтийг дуусгах хүртэл нь хянах, мөн энэ хүсэлтийн бүртгэлийг олох боломжийг олгодог (вэб сервер талаас хоёуланд нь). мөн хэрэглэгчийн дээр).

Datadog-ийг ашиглах үед бид заримдаа микро үйлчилгээний газрын зургийг буруу хийсэн, техникийн зарим дутагдалтай тулгарсан. Жишээлбэл, энэ нь үйлчилгээний төрлийг буруу тодорхойлсон (Django-г кэш үйлчилгээ гэж андуурсан) бөгөөд алдартай Predis номын санг ашиглан PHP програмд 500 алдаа гаргасан.

Ататус - хамгийн залуу хэрэгсэл; үйлчилгээг 2014 онд эхлүүлсэн. Түүний маркетингийн төсөв нь жагсаасан өрсөлдөгчдөөс доогуур байгаа нь илт бага байдаг. Гэсэн хэдий ч уг хэрэгсэл нь зөвхөн чадвараараа (APM, Browser monitoring гэх мэт) төдийгүй гадаад төрхөөрөө New Relic-тэй маш төстэй юм.

Чухал сул тал нь зөвхөн Node.js болон PHP-г дэмждэг. Нөгөөтэйгүүр, энэ нь Datadog-ээс хамаагүй дээр хэрэгждэг. Сүүлийнхээс ялгаатай нь Ататус нь кодонд өөрчлөлт оруулах эсвэл нэмэлт шошго нэмэхийг програмууд шаарддаггүй.

Бид New Relic-тэй хэрхэн ажилладаг

Одоо бид New Relic-ийг ерөнхийд нь хэрхэн ашигладаг болохыг олж мэдье. Бидэнд шийдвэрлэх шаардлагатай асуудал байна гэж бодъё:

Графикаас харахад амархан цацах -Үүнд дүн шинжилгээ хийцгээе. New Relic-д вэб гүйлгээг вэб аппликейшнд нэн даруй сонгож, бүх бүрэлдэхүүн хэсгүүдийг гүйцэтгэлийн график дээр зааж өгсөн, алдааны түвшин, хүсэлтийн түвшний самбарууд байдаг ... Хамгийн чухал нь эдгээр самбараас шууд өөр өөр програм хооронд шилжих боломжтой. програмын хэсгүүд (жишээ нь, MySQL дээр дарснаар мэдээллийн баазын хэсэг рүү шилжих болно).

Харж байгаа жишээн дээр бид үйл ажиллагааны өсөлтийг харж байна PHP, энэ график дээр дарж автоматаар очно уу Ажил гүйлгээ:

Үндсэндээ MVC загварын хянагч болох гүйлгээний жагсаалтыг аль хэдийн ангилсан байна Хамгийн их цаг зарцуулдаг, энэ нь маш тохиромжтой: бид програм юу хийдгийг шууд хардаг. New Relic автоматаар цуглуулсан урт асуулгын жишээ энд байна. Ангилалыг сольсноор дараахь зүйлийг олоход хялбар болно.

хамгийн их ачаалалтай програмын хянагч;
хамгийн их хүсдэг хянагч;
хянагч нарын хамгийн удаан нь.

Үүнээс гадна, та гүйлгээ бүрийг өргөжүүлж, кодыг гүйцэтгэх үед програм юу хийж байсныг харах боломжтой.

Эцэст нь, програм нь урт хүсэлтийн ул мөрийн жишээг хадгалдаг (2 секундээс илүү хугацаа шаардагддаг). Урт хугацааны гүйлгээний самбар энд байна:

Хоёр арга нь маш их цаг хугацаа шаарддаг бөгөөд нэгэн зэрэг хүсэлтийг гүйцэтгэх үед түүний URI болон домэйныг харуулсан болно. Ихэнхдээ энэ нь бүртгэлээс хүсэлтийг олоход тусалдаг. Явж байна Нарийвчилсан ул мөр, та эдгээр аргуудыг хаанаас дуудаж байгааг харж болно:

Тэгээд бас Өгөгдлийн сангийн асуулга - програм ажиллаж байх үед өгөгдлийн сангийн хүсэлтийг үнэлэх:

Энэхүү мэдлэгээр бид программ яагаад удааширч байгааг үнэлж, хөгжүүлэгчидтэй хамтран ажиллаж, асуудлыг шийдэх стратеги гаргаж чадна. Бодит байдал дээр New Relic нь үргэлж тодорхой дүр зургийг өгдөггүй ч мөрдөн байцаалтын векторыг сонгоход тусалдаг.

урт PDO::Construct биднийг pgpoll-ийн хачирхалтай үйл ажиллагаанд хүргэсэн;
цаг хугацааны тогтворгүй байдал Memcache::Get виртуал машиныг буруу тохируулсан гэж санал болгосон;
загвар боловсруулахад сэжигтэй хугацаагаар нэмэгдсэн нь объектын хадгалалтад 500 аватар байгаа эсэхийг шалгах үүрлэсэн гогцоонд хүргэсэн;
гэх мэт ...

Мөн кодыг гүйцэтгэхийн оронд үндсэн дэлгэц дээр гадаад өгөгдөл хадгалахтай холбоотой ямар нэг зүйл ургадаг бөгөөд энэ нь юу байх нь хамаагүй: Redis эсвэл PostgreSQL - тэдгээр нь бүгд таб дээр нуугдсан байдаг. мэдээллийн сан.

Та "Гүйлгээ"-д үүнийг хэрхэн хийдэгтэй адил судалгаа хийх, эрэмбэлэх асуулгад зориулсан тодорхой суурийг сонгож болно. Хүсэлтийн таб руу очсноор та програмын хянагч бүрт энэ хүсэлт хэдэн удаа гарч байгааг харахаас гадна хэр олон удаа дуудагддагийг тооцоолох боломжтой. Энэ нь маш тухтай:

Таб нь ижил төстэй өгөгдлийг агуулдаг Гадаад үйлчилгээ, энэ нь объектын хадгалалтад хандах, харуул руу үйл явдал илгээх гэх мэт гадны HTTP үйлчилгээнүүдийн хүсэлтийг нуудаг. Табын агуулга нь мэдээллийн сантай бүрэн төстэй:

Өрсөлдөгчид: боломж ба сэтгэгдэл

Одоо хамгийн сонирхолтой зүйл бол New Relic-ийн чадварыг өрсөлдөгчдийн санал болгож буй зүйлтэй харьцуулах явдал юм. Харамсалтай нь бид үйлдвэрлэж буй нэг програмын нэг хувилбар дээр бүх гурван хэрэгслийг туршиж чадаагүй. Гэсэн хэдий ч бид аль болох ижил нөхцөл байдал/тохиргоог харьцуулахыг хичээсэн.

1. Дата нохой

Datadog биднийг ханын үйлчилгээтэй самбараар угтаж байна:

Энэ нь програмуудыг бүрэлдэхүүн хэсэг/микросервис болгон задлахыг оролддог тул Django програмын жишээнд PostgreSQL-тэй 2 холболтыг харах болно (defaultdb и postgres), түүнчлэн Селөдерей, Редис. Datadog-тэй ажиллахын тулд та MVC зарчмуудын талаар хамгийн бага мэдлэгтэй байхыг шаарддаг: та хэрэглэгчийн хүсэлт ерөнхийдөө хаанаас ирдэг болохыг ойлгох хэрэгтэй. Энэ нь ихэвчлэн тусалдаг үйлчилгээний газрын зураг:

Дашрамд хэлэхэд, New Relic-д үүнтэй төстэй зүйл байдаг:

... мөн тэдний газрын зургийг миний бодлоор илүү энгийн бөгөөд ойлгомжтой болгосон: энэ нь нэг програмын бүрэлдэхүүн хэсгүүдийг харуулдаггүй (энэ нь Datadog-ийн жишээн дээр үүнийг хэт нарийвчилсан болгодог), гэхдээ зөвхөн тодорхой үйлчилгээ эсвэл микро үйлчилгээг үзүүлдэг.

Датадог руу буцъя: үйлчилгээний газрын зургаас Django-д хэрэглэгчийн хүсэлт ирж байгааг харж болно. Django үйлчилгээ рүү ороод эцэст нь юу хүлээж байсныг харцгаая:

Харамсалтай нь анхдагчаар энд график байхгүй байна Вэб гүйлгээний хугацаа, бидний үндсэн New Relic самбар дээр хардагтай төстэй. Гэхдээ үүнийг хуваарийн оронд тохируулж болно зарцуулсан цагийн %. Үүнийг солиход л хангалттай Нэг хүсэлтийн дундаж хугацаа... тэгээд одоо танил график биднийг харж байна!

Датадог яагаад өөр график сонгосон нь бидний хувьд нууц юм. Өөр нэг бухимдалтай зүйл бол систем нь хэрэглэгчийн сонголтыг санахгүй байгаа (өрсөлдөгчөөс ялгаатай) тул цорын ганц шийдэл бол захиалгат самбар үүсгэх явдал юм.

Гэхдээ Datadog-д эдгээр графикаас холбогдох серверүүдийн хэмжигдэхүүн рүү шилжих, бүртгэлийг уншиж, вэб серверийн зохицуулагч (Gunicorn) дээрх ачааллыг үнэлэх чадварт би сэтгэл хангалуун байсан. Бүх зүйл New Relic-тэй бараг адилхан ..., бүр бага зэрэг (логууд)!

Графикуудын доор New Relic-тэй бүрэн төстэй гүйлгээнүүд байна:

Datadog-д гүйлгээг дууддаг нөөц. Та хянагчдыг хүсэлтийн тоо, хариу өгөх дундаж хугацаа, сонгосон хугацаанд зарцуулсан хамгийн их хугацаагаар нь ангилж болно.

Та нөөцийг өргөжүүлж, New Relic дээр бидний ажигласан бүх зүйлийг харах боломжтой.

Нөөцийн статистик мэдээлэл, дотоод дуудлагын ерөнхий жагсаалт, хариу кодоор эрэмбэлж болох хүсэлтийн жишээнүүд байгаа... Дашрамд хэлэхэд манай инженерүүдэд энэ ангилах нь үнэхээр таалагдсан.

Datadog дээрх аливаа жишээ эх сурвалжийг нээж, судалж болно:

Хүсэлтийн параметрүүд, бүрэлдэхүүн хэсэг тус бүрт зарцуулсан цаг хугацааны хураангуй график, дуудлагын дарааллыг харуулсан хүрхрээний графикийг үзүүлэв. Та мөн хүрхрээний графикийн модны харагдац руу шилжиж болно:

Хамгийн сонирхолтой зүйл бол хүсэлтийг гүйцэтгэсэн хостын ачааллыг үзэх, хүсэлтийн бүртгэлийг үзэх явдал юм.

Гайхалтай интеграци!

Та табууд хаана байгааг гайхаж магадгүй юм мэдээллийн сан и Гадаад үйлчилгээ, New Relic-ийн адил. Энд байхгүй: Datadog програмыг бүрэлдэхүүн хэсгүүдэд задалдаг тул PostgreSQL-ийг авч үзэх болно. тусдаа үйлчилгээ, мөн Гадаад үйлчилгээний оронд үүнийг хайх нь зүйтэй aws.storage (энэ нь програмын хандах боломжтой бусад бүх гадаад үйлчилгээтэй адил байх болно).

Энд жишээ татъя postgres:

Үндсэндээ бидний хүссэн бүх зүйл бий:

Хүсэлт аль "үйлчилгээ"-ээс ирснийг харж болно.

Datadog нь NGINX Ingress-тэй төгс нэгтгэгдэж, кластерт хүсэлт ирсэн цагаас эхлэн төгсгөлөөс төгсгөлд нь хянах боломжийг олгодог бөгөөд статистик үзүүлэлтүүдийг хүлээн авах, лог цуглуулах, хост хэмжигдэхүүнүүдийг авах боломжийг олгодог гэдгийг танд сануулахад буруудахгүй. .

Datadog-ийн маш том давуу тал бол түүний үнэ юм хэлбэржиж байна дэд бүтцийн мониторинг, APM, Бүртгэлийн менежмент ба Синтетик тестээс, i.e. Та төлөвлөгөөгөө уян хатан байдлаар сонгох боломжтой.

2. Ататус

Ататусын багийнхан тэдний үйлчилгээ "Шинэ дурсгалтай адил боловч илүү сайн" гэж мэдэгджээ. Энэ үнэхээр тийм эсэхийг харцгаая.

Үндсэн самбар нь ижил төстэй харагдах боловч програмд ашигласан Redis болон memcached-ийг тодорхойлох боломжгүй байсан.

APM нь бүх гүйлгээг анхдагчаар сонгодог боловч ихэвчлэн зөвхөн вэб гүйлгээ шаардлагатай байдаг. Datadog-ийн нэгэн адил үндсэн самбараас хүссэн үйлчилгээ рүү шилжих арга байхгүй. Түүнчлэн, гүйлгээг алдааны дараа жагсаасан байдаг бөгөөд энэ нь APM-ийн хувьд тийм ч логик биш юм шиг санагддаг.

Ататусын гүйлгээнд бүх зүйл New Relic-тэй аль болох төстэй байдаг. Сул тал нь хянагч бүрийн динамик нь шууд харагдахгүй байх явдал юм. Та үүнийг хянагчийн хүснэгтээс эрэмбэлж хайх хэрэгтэй Хамгийн их цаг зарцуулсан:

Хянагчийн ердийн жагсаалтыг таб дээрээс авах боломжтой Explore:

Зарим талаараа энэ хүснэгт нь Датадог санагдуулдаг бөгөөд надад New Relic дээрх ижил төстэй хүснэгтээс илүү таалагдаж байна.

Та гүйлгээ бүрийг өргөжүүлж, програм юу хийж байгааг харах боломжтой:

Самбар нь Datadog-ийг илүү санагдуулдаг: хэд хэдэн хүсэлт, дуудлагын ерөнхий дүр зураг байдаг. Дээд талын самбар нь алдааны табыг өгдөг HTTP алдаа болон удаан асуулгын жишээнүүд Сешн ул мөр:

Хэрэв та гүйлгээ рүү очвол ул мөрийн жишээг харж, мэдээллийн санд хүсэлтийн жагсаалтыг авч, хүсэлтийн толгой хэсгийг харж болно. Бүх зүйл New Relic-тэй төстэй:

Ерөнхийдөө Ататус нарийвчилсан ул мөрийг олж авсандаа сэтгэл хангалуун байсан - ердийн Шинэ Relic дуудлагыг сануулагч блок руу наалдуулахгүйгээр:

Гэсэн хэдий ч, (New Relic гэх мэт) хэт хурдан хүсэлтийг (<5 мс) таслах шүүлтүүр байхгүй байна. Нөгөөтэйгүүр, гүйлгээний эцсийн хариуг (амжилт эсвэл алдаа) харуулах нь надад таалагдсан.

Самбар мэдээллийн сан Програмын гадаад мэдээллийн баазын хүсэлтийг судлахад тань туслах болно. Ататус зөвхөн PostgreSQL болон MySQL-г олсон хэдий ч Redis болон memcached нь төсөлд хамрагдсан гэдгийг сануулъя.

Хүсэлтийг ердийн шалгуурын дагуу ангилдаг: хариу өгөх давтамж, хариу өгөх дундаж хугацаа гэх мэт. Би бас хамгийн удаан асуулгатай табыг дурдахыг хүсч байна - энэ нь маш тохиромжтой. Түүнчлэн, PostgreSQL-д зориулсан энэ таб дахь өгөгдөл нь өргөтгөлийн өгөгдөлтэй давхцаж байна pg_stat_statements - гайхалтай үр дүн!

Tab Гадаад хүсэлт Өгөгдлийн сантай бүрэн адилхан.

үр дүн нь

Үзүүлсэн хэрэгсэл хоёулаа APM-ийн дүрд сайн ажилласан. Тэдгээрийн аль нэг нь шаардлагатай доод хэмжээг санал болгож чадна. Бидний сэтгэгдлийг дараах байдлаар товчхон дүгнэж болно.

Мэдээллийн систем

Нөхцөл:

тохиромжтой тарифын хуваарь (APM нь хост бүрт 31 ам.долларын үнэтэй);
Python дээр сайн ажилласан;
OpenTracing-тэй нэгтгэх боломж
Кубернетестэй нэгтгэх;
NGINX Ingress-тэй нэгтгэх.

Нөхцөл байдал:

модулийн алдааны улмаас програмыг ашиглах боломжгүй болсон цорын ганц APM (predis);
PHP-ийн автомат хэрэгсэл сул;
үйлчилгээ, тэдгээрийн зорилгын талаар хэсэгчлэн хачирхалтай тодорхойлолт.

Ататус