🥇Ora Relik Anyar mung: deleng Datadog lan Atatus

Ing lingkungan insinyur SRE / DevOps, ora bakal kaget sapa wae yen ing sawijining dina klien (utawa sistem ngawasi) katon lan laporan yen "kabeh wis ilang": situs kasebut ora bisa digunakake, pembayaran ora ditindakake, urip rusak. ... Ora ketompo carane sampeyan pengin mbantu ing kahanan kaya mengkono, bisa dadi angel banget kanggo nindakake iki tanpa alat sing prasaja lan bisa dingerteni. Asring masalah kasebut didhelikake ing kode aplikasi kasebut dhewe; sampeyan mung kudu nggawe lokalisasi.

Lan ing susah lan bungah ...

Iku kedadeyan yen kita wis suwe lan tresna banget karo New Relic. Iki lan tetep dadi alat sing apik kanggo ngawasi kinerja aplikasi, lan uga ngidini sampeyan nggunakake arsitektur microservice (nggunakake agen kasebut) lan liya-liyane. Lan kabeh bisa uga apik yen ora ana owah-owahan ing kabijakan rega layanan: iku biaya saka taun 2013 tansaya 3+ kaping. Kajaba iku, wiwit taun kepungkur, entuk akun uji coba mbutuhake komunikasi karo manajer pribadi, sing nggawe angel menehi produk kasebut menyang pelanggan potensial.

Kahanan sing biasa: Relik Anyar ora dibutuhake kanthi "permanen"; dheweke mung ngelingi nalika ana masalah. Nanging sampeyan isih kudu mbayar kanthi reguler (140 USD saben server saben wulan), lan ing infrastruktur maya kanthi otomatis jumlahe tambah akeh. Sanajan ana pilihan Pay-As-You-Go, mbisakake New Relic mbutuhake sampeyan miwiti maneh aplikasi kasebut, sing bisa nyebabake kahanan masalah sing diwiwiti. Ora suwe, New Relic ngenalake rencana tarif anyar - Essentials, - sing sepisanan katon minangka alternatif sing cukup kanggo Profesional ... nanging nalika dipriksa kanthi cetha, ternyata sawetara fungsi penting ilang (utamane, ora duwe Transaksi Kunci, Lintas Aplikasi Tracing, Tracing sing disebarake).

Akibaté, kita wiwit mikir babagan golek alternatif sing luwih murah, lan pilihan kita ana ing rong layanan: Datadog lan Atatus. Apa ing wong?

Babagan pesaing

Ayo kula langsung ngomong yen ana solusi liyane ing pasar. Kita malah nganggep opsi Open Source, nanging ora saben klien duwe kapasitas gratis kanggo dadi tuan rumah solusi sing dadi tuan rumah ... - Kajaba iku, mbutuhake pangopènan tambahan. Pasangan sing dipilih dadi sing paling cedhak kabutuhan kita:

dhukungan dibangun lan dikembangake kanggo aplikasi PHP (tumpukan klien kita maneka warna, nanging iki minangka pimpinan sing jelas ing konteks nggoleki alternatif kanggo New Relic);
biaya terjangkau (kurang saka 100 USD saben sasi saben inang);
instrumentasi otomatis;
integrasi karo Kubernetes;
Persamaan karo antarmuka New Relic minangka tambahan sing katon (amarga insinyur kita wis biasa).

Mulane, ing tahap pemilihan awal, kita ngilangi sawetara solusi populer liyane, lan utamane:

Tideways, AppDynamics lan Dynatrace - kanggo biaya;
Stackify diblokir ing Federasi Rusia lan nuduhake data sing sithik banget.

Liyane saka artikel wis kabentuk ing cara sing solusi ing pitakonan pisanan bakal presented sedhela, sawise kang aku bakal pirembagan bab interaksi khas kita karo New Relic lan pengalaman / tayangan saka nindakake operasi padha ing layanan liyane.

Presentasi saka pesaing sing dipilih

ing New Relic, mbokmenawa kabeh wis krungu? Layanan iki diwiwiti luwih saka 10 taun kepungkur, ing taun 2008. Kita wis aktif nggunakake wiwit 2012 lan wis ora masalah nggabungake nomer tenan akeh aplikasi ing PHP, Ruby lan Python, lan kita uga wis pengalaman nggabungake karo C # lan Go. Penulis layanan kasebut duwe solusi kanggo ngawasi aplikasi, infrastruktur, nelusuri infrastruktur layanan mikro, nggawe aplikasi sing trep kanggo piranti pangguna, lan liya-liyane.

Nanging, agen New Relic mlaku nganggo protokol proprietary lan ora ndhukung OpenTracing. Instrumentasi lanjut mbutuhake suntingan khusus kanggo New Relic. Pungkasan, dhukungan Kubernetes isih eksperimen.

Miwiti pembangunan ing 2010 datadog katon luwih menarik tinimbang New Relic ing babagan panggunaan ing lingkungan Kubernetes. Utamane, ndhukung integrasi karo NGINX Ingress, koleksi log, statsd lan protokol OpenTracing, sing ngidini sampeyan nglacak panjaluk pangguna wiwit disambungake nganti rampung, uga nemokake log kanggo panyuwunan iki (loro ing sisih server web. lan ing konsumen).

Nalika nggunakake Datadog, kita ketemu sing kadhangkala salah mbangun peta microservice, lan sawetara shortcomings technical. Contone, misidentified jinis layanan (mistaking Django kanggo layanan caching) lan nyebabake 500 kasalahan ing aplikasi PHP nggunakake perpustakaan Predis populer.

Atatus - instrumen paling enom; layanan iki dibukak ing 2014. Anggaran pemasaran kasebut jelas luwih murah tinimbang pesaing sing kadhaptar, sebutan kasebut kurang umum. Nanging, alat kasebut meh padha karo New Relic, ora mung ing kemampuane (APM, ngawasi Browser, lan liya-liyane), nanging uga katon.

A drawback pinunjul iku mung ndhukung Node.js lan PHP. Ing tangan liyane, iku dipun ginakaken noticeably luwih saka Datadog. Ora kaya sing terakhir, Atatus ora mbutuhake aplikasi kanggo nggawe modifikasi utawa nambah label tambahan ing kode kasebut.

Carane kita bisa karo New Relic

Saiki ayo goleki carane umume nggunakake New Relic. Ayo kita duwe masalah sing mbutuhake solusi:

Iku gampang kanggo ndeleng ing grafik cipratan - Ayo analisa. Ing New Relic, transaksi web langsung dipilih kanggo aplikasi web, kabeh komponen dituduhake ing grafik kinerja, ana panel tingkat kesalahan, tingkat permintaan ... Sing paling penting yaiku langsung saka panel kasebut sampeyan bisa ngalih ing antarane macem-macem. bagean saka aplikasi (contone, ngeklik ing MySQL bakal mimpin kanggo bagean database).

Wiwit ing conto sing dipikirake, kita ndeleng mundhak kegiatan PHP, klik ing grafik iki lan kanthi otomatis pindhah menyang Transaksi:

Dhaptar transaksi, sing ateges pengontrol saka model MVC, wis diurutake miturut Paling akeh wektu, sing trep banget: kita langsung ndeleng apa sing ditindakake aplikasi kasebut. Ing ngisor iki conto pitakon dawa sing diklumpukake kanthi otomatis dening New Relic. Kanthi ngoper ngurutake, gampang ditemokake:

controller aplikasi paling dimuat;
controller sing paling kerep dijaluk;
sing paling alon saka pengontrol.

Kajaba iku, sampeyan bisa nggedhekake saben transaksi lan ndeleng apa sing ditindakake aplikasi nalika kode dieksekusi:

Pungkasan, aplikasi nyimpen conto jejak panjaluk sing dawa (sing njupuk luwih saka 2 detik). Punika panel kanggo transaksi dawa:

Bisa dideleng yen rong cara mbutuhake wektu akeh, lan ing wektu sing padha nalika panyuwunan dieksekusi, URI lan domain uga ditampilake. Asring iki mbantu nemokake panjalukan ing log. Arep Rincian tilak, sampeyan bisa ndeleng saka ngendi cara kasebut diarani:

Lan ing pitakon database - ngevaluasi pitakon menyang database sing dieksekusi nalika aplikasi lagi mlaku:

Bersenjata karo kawruh iki, kita bisa ngira-ngira kenapa aplikasi saya kalem lan kerja sama karo pangembang kanggo nggawe strategi kanggo ngatasi masalah kasebut. Kasunyatane, New Relic ora mesthi menehi gambaran sing jelas, nanging mbantu milih vektor investigasi:

dawa PDO::Construct mimpin kita kanggo fungsi aneh pgpoll;
kahanan kang ora tetep liwat wektu Memcache::Get disaranake yen mesin virtual dikonfigurasi kanthi ora bener;
wektu suspiciously tambah kanggo Processing cithakan mimpin menyang daur ulang nested mriksa ngarsane 500 avatar ing panyimpenan obyek;
lsp…

Uga kedadeyan tinimbang ngeksekusi kode, ana sing ana gandhengane karo panyimpenan data eksternal tuwuh ing layar utama - lan ora preduli apa sing bakal ditindakake: Redis utawa PostgreSQL - kabeh didhelikake ing tab. data.

Sampeyan bisa milih basis tartamtu kanggo riset lan ngurutake pitakon - padha karo cara sing ditindakake ing Transaksi. Lan kanthi pindhah menyang tab panyuwunan, sampeyan bisa ndeleng kaping pirang-pirang panjaluk iki kedadeyan ing saben pengontrol aplikasi, lan uga ngira sepira kerepe diarani. Iku banget nyaman:

Tab kasebut ngemot data sing padha Layanan njaba, sing ndhelikake panjalukan menyang layanan HTTP eksternal, kayata ngakses panyimpenan obyek, ngirim acara menyang penjaga, utawa liya-liyane. Isi tab kasebut meh padha karo Database:

Saingan: kesempatan lan kesan

Saiki sing paling menarik yaiku mbandhingake kemampuan New Relic karo apa sing ditawakake pesaing. Sayange, kita ora bisa nyoba kabeh telung alat ing siji versi aplikasi sing mlaku ing produksi. Nanging, kita nyoba mbandhingake kahanan / konfigurasi sing padha kaya bisa.

1. Datadog

Datadog menehi salam karo panel kanthi tembok layanan:

Iku nyoba kanggo break aplikasi menyang komponen / microservices, supaya ing conto aplikasi Django kita bakal weruh 2 sambungan kanggo PostgreSQL (defaultdb и postgres), uga Celery, Redis. Nggarap Datadog mbutuhake sampeyan duwe kawruh minimal babagan prinsip MVC: sampeyan kudu ngerti saka ngendi panjaluk pangguna umume teka. Iki biasane mbantu peta layanan:

Miturut cara, ana sing padha ing New Relic:

... lan peta, miturut pendapatku, digawe luwih gampang lan luwih jelas: ora nampilake komponen siji aplikasi (sing bakal nggawe rinci banget, kaya ing kasus Datadog), nanging mung layanan utawa layanan mikro tartamtu.

Ayo bali menyang Datadog: saka peta layanan kita bisa ndeleng manawa panjaluk pangguna teka ing Django. Ayo menyang layanan Django lan pungkasane ndeleng apa sing dikarepake:

Sayange, ora ana grafik ing kene kanthi standar Wektu transaksi web, padha karo sing kita deleng ing panel New Relic utama. Nanging, bisa diatur ing panggonan jadwal % saka Wektu ngginakaken. Iku cukup kanggo ngalih menyang Wektu rata-rata saben panyuwunan miturut Jinis... lan saiki grafik sing akrab ndeleng kita!

Napa Datadog milih grafik sing beda dadi misteri kanggo kita. Bab liyane sing mumetake yaiku sistem ora ngelingi pilihan pangguna (ora kaya pesaing loro), lan mulane mung solusi yaiku nggawe panel khusus.

Nanging aku seneng karo kemampuan ing Datadog kanggo ngalih saka grafik kasebut menyang metrik server sing gegandhengan, maca log lan ngevaluasi beban ing pawang server web (Gunicorn). Kabeh meh padha karo New Relic ... lan malah sethitik liyane (log)!

Ing ngisor grafik kasebut ana transaksi sing meh padha karo New Relic:

Ing Datadog, transaksi diarani sumber daya. Sampeyan bisa ngurutake pengontrol miturut jumlah panjalukan, wektu nanggepi rata-rata, lan wektu maksimal kanggo wektu sing dipilih.

Sampeyan bisa nggedhekake sumber daya lan ndeleng kabeh sing wis diamati ing New Relic:

Ana statistik babagan sumber daya, dhaptar panggilan internal sing umum, lan conto panjaluk sing bisa diurutake miturut kode respon ... Miturut cara, para insinyur kita seneng banget ngurutake iki.

Sembarang conto sumber ing Datadog bisa dibukak lan sinau:

Paramèter panjalukan, bagan ringkesan wektu sing ditindakake ing saben komponen, lan grafik grojogan sing nuduhake urutan panggilan ditampilake. Sampeyan uga bisa ngalih menyang tampilan wit ing grafik grojogan:

Lan sing paling menarik yaiku ndeleng beban host sing panjaluk kasebut ditindakake lan ndeleng log panyuwunan.

Integrasi gedhe!

Sampeyan bisa uga wonder ngendi tab data и Layanan njaba, kaya ing New Relic. Ora ana ing kene: amarga Datadog ngrusak aplikasi dadi komponen, PostgreSQL bakal dianggep layanan kapisah, lan tinimbang Layanan njaba iku worth looking for aws.storage (bakal padha kanggo saben layanan eksternal liyane sing bisa diakses aplikasi).

Punika conto karo postgres:

Intine ana kabeh sing dikarepake:

Sampeyan bisa ndeleng saka "layanan" panyuwunan kasebut.

Ora bakal salah kanggo ngelingake yen Datadog nggabungake kanthi sampurna karo NGINX Ingress lan ngidini sampeyan nindakake tracing end-to-end wiwit ana panjaluk teka ing kluster, lan uga ngidini sampeyan nampa metrik statsd, ngumpulake log lan metrik host. .

A plus ageng saka Datadog iku sawijining rega berkembang saka ngawasi infrastruktur, APM, Manajemen Log lan test Synthetics, i.e. Sampeyan bisa milih rencana kanthi fleksibel.

2.Atatus

Tim Atatus ujar manawa layanan kasebut "padha karo New Relic, nanging luwih apik." Ayo ndeleng apa iki pancene.

Panel utama katon padha, nanging ora bisa nemtokake Redis lan memcached sing digunakake ing aplikasi kasebut.

APM milih kabeh transaksi kanthi standar, sanajan biasane mung transaksi Web sing dibutuhake. Kaya Datadog, ora ana cara kanggo navigasi menyang layanan sing dikarepake saka panel utama. Menapa malih, transaksi kadhaptar sawise kasalahan, kang ora koyone banget logis kanggo APM.

Ing transaksi Atatus, kabeh meh padha karo New Relic. Kakurangan iku dinamika kanggo saben controller ora langsung katon. Sampeyan kudu nggoleki ing meja controller, ngurutake Paling akeh wektu:

Dhaptar biasa pengontrol kasedhiya ing tab Explore:

Ing sawetara cara, tabel iki kaya Datadog lan aku luwih seneng tinimbang sing padha ing New Relic.

Sampeyan bisa nggedhekake saben transaksi lan ndeleng apa sing ditindakake aplikasi kasebut:

Panel uga luwih kaya Datadog: ana sawetara panjalukan, gambar umum telpon. Panel ndhuwur nyedhiyakake tab kesalahan Gagal HTTP lan conto pitakon alon Lacak Sesi:

Yen sampeyan pindhah menyang transaksi, sampeyan bisa ndeleng conto tilak, sampeyan bisa njaluk dhaftar panjalukan kanggo database lan katon ing header request. Kabeh padha karo New Relic:

Umumé, Atatus seneng karo jejak sing rinci - tanpa gluing New Relic khas telpon menyang blok pangeling:

Nanging, ora ana panyaring sing (kaya New Relic) bakal ngilangi panjaluk sing cepet banget (<5ms). Ing tangan liyane, aku seneng tampilan respon transaksi final (sukses utawa kesalahan).

Panel data bakal mbantu sampeyan sinau panjaluk menyang database eksternal sing digawe aplikasi kasebut. Ayo kula ngelingake yen Atatus mung nemokake PostgreSQL lan MySQL, sanajan Redis lan memcached uga melu proyek kasebut.

Panyuwunan diurutake miturut kritéria biyasa: frekuensi respon, wektu respon rata-rata, lan liya-liyane. Aku uga pengin nyebutake tab kanthi pitakon paling alon - trep banget. Kajaba iku, data ing tab iki kanggo PostgreSQL pas karo data saka ekstensi pg_stat_statements - asil apik banget!

Tab Panjaluk njaba rampung podho rupo kanggo Databases.

temonan

Loro-lorone alat sing diwenehi kinerja apik ing peran APM. Sembarang bisa menehi minimal sing dibutuhake. Tayangan kita bisa diringkes kanthi ringkes kaya ing ngisor iki:

datadog

Pros:

jadwal tarif trep (APM biaya 31 USD saben inang);
makarya uga karo Python;
Kemungkinan integrasi karo OpenTracing
integrasi karo Kubernetes;
integrasi karo NGINX Ingress.

Cons:

mung APM sing nyebabake aplikasi dadi ora kasedhiya amarga kesalahan modul (predis);
instrumen otomatis PHP sing lemah;
definisi sebagéyan aneh layanan lan tujuane.

Atatus