Sentry эсвэл New Relic: нэг нь эвдэрсэн код, нөгөө нь бүх системийг харна

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

Сонголтыг «аль нь APM вэ» гэсэн шошгоор хийхэд энэ ялгаа харагдахгүй. Хоёр бүтээгдэхүүн хоёулаа алдаа болон гүйцэтгэлийн мэдээлэлтэй ажилладаг. Харин хөгжүүлэгчийн асуух «аль өөрчлөлт алдаа үүсгэв?» болон ээлжийн инженерийн асуух «аль үйлчилгээ доголдов?» гэсэн асуултад хэрэгтэй дохио, хариуцах хүн өөр байдаг.

Асуудал гармагц хэн ямар хариу хайх вэ?

Middleware-ийн бүтээгдэхүүний харьцуулалт Sentry-ийн issue grouping, source map, сэжигтэй commit, session replay-ийг кодын алдаа засах урсгалтай; New Relic-ийн APM, үйлчилгээний зураглал, лог, infrastructure agent, Kubernetes-ийн мэдээллийг системийн хяналттай холбож тайлбарласан. Энэ нь нэг хэрэгсэл нөгөөгийн бүх боломжийг огт агуулдаггүй гэсэн үг биш. Ялгаа нь асуудлыг судалж эхлэх цэг болон ямар давхаргын төлөвийг нэг дор харах хэрэгцээнд байна.

Хөгжүүлэгч алдааны stack trace-ээс эх кодын мөр, тухайн release, өөрчлөгдсөн commit рүү шилждэг. SRE баг хүсэлтийн trace-ээс үйлчилгээний хамаарал, лог, хостын ачаалал руу шилждэг. Хэрэв нэг дохио хоёр багт очдог бол мэдэгдлийг хэн авах, хэн засах, үйлчилгээний нөлөөг хэн үнэлэхийг ялгах нь хоёр дахь хэрэгслийг авах эсэхээс ч өмнөх шийдвэр болно.

Frontend алдаанд Sentry-ийн давуу тал юу вэ?

JavaScript-ийн шахсан файлын stack trace дангаараа засах мөрийг заахгүй байж болно. Source map-ийг зөв release-тэй холбосноор алдаа эх кодын аль хэсэгт гарсныг тогтоох боломжтой. Repository болон commit-ийн мэдээллийг тохируулсан үед Sentry сэжигтэй өөрчлөлтийг issue-тэй холбодог; ийм тохиргоогүй баг commit-ийн холбоосыг бэлэн давуу тал гэж тооцож болохгүй.

Session replay нь алдааны өмнөх хэрэглэгчийн үйлдлийг харахад тусалдаг. Breadcrumb, сүлжээний хүсэлт, алдааны цаг хугацааг зэрэгцүүлэх нь зөвхөн «алдаа хэдэн удаа гарсан» гэсэн тооноос илүү тодорхой асуултад хариулна. Гэхдээ replay хадгалах хэмжээ өсөхийн хэрээр Sentry-ийн тухайн ангиллын хэрэглээ ч өснө. Багт бүх сесс хэрэгтэй юу, эсвэл алдаатай холбоотой хэсгийг сонгон авахад хангалттай юу гэдэг нь төлбөр болон шалгах ажлын хэмжээнд нөлөөлнө.

New Relic мөн браузерийн алдаа болон session replay-ийг хянадаг. Хэрэв frontend-ийн удаашралыг backend trace, үйлчилгээний төлөвтэй нэг орчинд холбох нь гол хэрэгцээ бол түүний хамрах хүрээ ашигтай. Харин засварын ажил ихэвчлэн эх код, release, commit дээр төгсдөг багт Sentry-ийн алдаанаас код руу хүрэх урсгал илүү шууд.

Олон үйлчилгээ, Kubernetes дээр юу өөрчлөгдөх вэ?

Microservice орчинд хэрэглэгчийн хүсэлт хэд хэдэн үйлчилгээг дамждаг. Нэг үйлчилгээний кодын алдаа харагдсан ч удаашралын шалтгаан нь дараалал, өгөгдлийн сангийн хүсэлт, контейнер эсвэл хостын нөөцтэй холбоотой байж болно. New Relic-ийн APM ба distributed tracing нь хүсэлтийн замыг, infrastructure agent болон Kubernetes integration нь ажиллаж буй орчны төлөвийг харах зориулалттай. Эдгээрийг холбосон үед SRE баг кодын алдаа нийт үйлчилгээний доголдлын аль хэсэг болохыг үнэлж чадна.

Sentry ч үйлчилгээ дамнасан trace, логтой ажилладаг боловч хост, контейнер, Kubernetes-ийн төлөв цуглуулах зориулалтын infrastructure agent-ийн үүргийг гүйцэтгэхгүй. Sentry-г үндсэн хэрэгслээр сонгосон багт дэд бүтцийн хяналт хэрэгтэй хэвээр байвал тэр ажлыг өөр хэрэгсэл хариуцна. Харин ганц жижиг үйлчилгээний баг хост бүрийн нарийвчилсан дохиог ашигладаггүй бол өргөн хүрээний телеметр цуглуулах нь оношлох мэдээллээс гадна хадгалах өгөгдөл, мэдэгдлийн ачааллыг нэмнэ.

Энд үйлчилгээний зураглалын үнэ цэнэ системийн хэмжээнээс шууд хамаарахгүй. Хүсэлтийн зам олон эзэмшигчийн үйлчилгээ дамжиж, нэг баг нөгөөгийнхөө хариуцсан хэсэгт юу болсныг мэдэх шаардлагатай үед зураглал хэрэгтэй болно. Харин алдааг нэг repository доторх өөрчлөлтөөр шийддэг бол тэр гүн хяналтаас өмнө кодын холбоос илүү чухал байж болно.

Үнэ юугаар өсөх вэ?

New Relic-ийн албан ёсны тариф үнэгүй багцад сард 100 GB ingest, нэг full platform хэрэглэгч багтааж, төлбөртэй Standard багцын Original data-д босгоос хойших GB тутам $0.40, эхний full platform хэрэглэгчид $10, нэмэлт хэрэглэгч бүрд $99 гэж заажээ. Basic эрх үнэгүй боловч full platform эрхтэй ижил боломж олгодоггүй. Үнэгүй багц ingest-ийн хязгаарт хүрээд төлбөртэй багцад шилжээгүй бол дараагийн сар эхлэх хүртэл өгөгдөл авах ажиллагаа болон платформд нэвтрэх эрх зогсоно. Иймээс босгоос давсан GB-ийн үнийг үнэгүй багц дээр автоматаар төлөөд үргэлжлүүлнэ гэж тооцож болохгүй.

Sentry-ийн төлбөрийн тайлбар self-service төлөвлөгөөний тооцоог үнийн хуудас эсвэл бүртгэлийн Manage Plan хэсгээс үзэх, их хэмжээний хэрэглээний үнийг борлуулалтын төлөөлөгчтэй хэлэлцэхийг заадаг. Түүний алдаа, replay, span зэрэг хэрэглээний ангиллыг New Relic-д хадгалах GB-тэй шууд хөрвүүлэх тогтмол харьцаа байхгүй. Нэг алдаа богино бичлэг байж болох бол replay болон trace өөр хэмжээний өгөгдөл үүсгэнэ.

New Relic-д төлбөрийн хоёр тусдаа хөдөлгүүр нь хадгалсан өгөгдлийн хэмжээ ба хэрэглэгчийн эрх юм. Лог их хэмжээгээр илгээхэд ingest өснө; гүн оношилгоо хийх хүний тоо нэмэгдэхэд эрхийн төлбөр өснө. Sentry-д алдаа цөөн байсан ч replay эсвэл span-ийн хэрэглээ өөр ангиллын хязгаарт хүрч болно. Тиймээс хоёр бүтээгдэхүүний «үнэгүй» гэсэн бичгийг бус, багийн цуглуулах дохио болон ажиллах хүмүүсийн эрхийг зэрэг харьцуулах хэрэгтэй.

Гурван багийн нөхцөлт телеметрийн төсөв

Дараах тоонууд нь бодит байгууллагын хэмжилт биш, төлбөрийн ялгааг харуулах нөхцөлт загвар юм. Алдааны event, replay, span болон GB нь өөр нэгж тул нэг багийн Sentry-ийн эцсийн үнийг нөгөөгийн New Relic ingest-ээс гаргах боломжгүй. Харин босго давсан эсэх, хэдэн хүн full platform эрх шаардахыг загвар бүрээр харж болно.

• Frontend төвтэй баг: сард 20 мянган алдааны event, 4 мянган replay, New Relic-д илгээвэл 35 GB өгөгдөл, гүн хяналт хийх нэг инженер байна гэж төсөөлье. New Relic-ийн ingest ба хэрэглэгчийн тоо үнэгүй багцын хүрээнд багтаж болох ч энэ нь source map, release, commit-той холбоотой засварын урсгалыг автоматаар орлохгүй. Sentry-ийн зардлын эрсдэл алдаа болон replay-ийн тус тусын хэрэглээний ангилалд байна. Ийм багт Sentry гол хэрэгсэл байж, дэд бүтцийн хяналт үнэхээр шаардлагатай эсэхийг тусад нь шийдэх нь ойлгомжтой.
• Microservice төвтэй баг: сард 240 GB өгөгдөл хадгалж, гурван инженер full platform эрхтэй байна гэж төсөөлье. Төлбөртэй Standard болон Original data сонговол босгоос давсан 140 GB-ийн ingest $56, хэрэглэгчийн эрх нийлээд $208, эдгээр хоёр хэсгийн жишиг төлбөр $264 болно; нэмэлт боломж болон татвар үүнд ороогүй. Үнэгүй багц дээр үлдвэл ийм хэмжээний ingest тасарна. Энэ багийн өдөр тутмын гол ажил үйлчилгээний хамаарал, лог, Kubernetes-ийн төлөвийг судлах бол New Relic үндсэн сонголт; Sentry-г кодын алдааг тусдаа хөгжүүлэгчийн урсгалаар эзэмших хэрэгцээтэй үед нэмнэ.
• Жижиг full-stack баг: сард 8 мянган алдааны event, 1 мянган replay, New Relic-д 80 GB ingest, гүн оношилгоо хийх хоёр инженер байна гэж төсөөлье. Өгөгдөл үнэгүй босгонд багтсан ч хоёр инженер хоёулаа full platform эрх шаардвал Standard дахь хэрэглэгчийн эрхийн жишиг төлбөр $109 болно. Нэг нь basic эрхээр ажлаа хийж чадвал энэ тооцоо өөрчлөгдөнө. Кодын алдааг засах нь гол ажил бол Sentry, үйлчилгээний олон давхаргыг хянах нь гол ажил бол New Relic-ээс эхлэх сонголт илүү тодорхой.

Хоёуланг зэрэг ашиглах үндэслэл

Хөгжүүлэгчид Sentry-д алдааг release, commit, replay-тай нь холбон засаж, SRE баг New Relic-д үйлчилгээний нөлөө, лог, дэд бүтцийн төлөвийг хянадаг бол хоёр хэрэгсэл өөр өөр эзэмшигчтэй байна. Энэ үед нэг үйл явдлыг давхар илгээх эсэх, мэдэгдлийг аль баг авах, засварын явцыг хаана тэмдэглэхийг тохирох шаардлагатай. Давхар цуглуулсан дохио хоёр талын хэрэглээ болон анхааруулгын ачаалалд нөлөөлнө.

Нэг жижиг баг хоёр ажлыг хоёуланг нь хийдэг бол эхний сонголтыг хамгийн их цаг авдаг оношилгооны асуултаар тодорхойлж болно. Алдааны шалтгаан кодын өөрчлөлт дээр олддог бол Sentry-ийн урсгал, үйлчилгээний аль давхарга доголдсоныг тогтоох шаардлага давамгайлдаг бол New Relic-ийн хамрах хүрээ илүү хэрэгтэй. Нөгөө хэрэгслийг нэмэх шалтгаан нь тусдаа эзэмшигч эсвэл одоогийн хяналтаар хариулж чадахгүй давтагддаг асуулт байх ёстой.

Мөн уншаарай:

• Docker Compose эсвэл Kubernetes: нэг сервер дээр илүү их нь дээр биш
• Cloudflare эсвэл Google DNS: нууцлалын ялгаа хурднаас том байж болно
• n8n-ийг өөрийн серверт байрлуулах нь: нэг encryption key бүх нууцыг аварна