
Dalam lingkungan SRE- / DevOps-engineer, Anda tidak akan terkejut bahwa suatu hari seorang klien (atau sistem pemantauan) muncul dan mengatakan bahwa "semuanya hilang": situs tidak berfungsi, pembayaran tidak lulus, kehidupan membusuk ... kehidupan membusuk ... Tidak peduli bagaimana saya ingin membantu dalam situasi ini Ini bisa sangat sulit untuk dilakukan tanpa alat yang sederhana dan mudah dimengerti. Seringkali masalah disembunyikan dalam kode aplikasi itu sendiri - Anda hanya perlu melokalkannya.
Dan dalam kesedihan, dan dalam sukacita ...
Kebetulan kami sudah lama sangat menyukai New Relic. Telah dan tetap menjadi alat yang sangat baik untuk memantau kinerja aplikasi, dan juga memungkinkan Anda untuk instrumen arsitektur layanan mikro (menggunakan agen Anda) dan banyak lagi. Dan semuanya bisa menjadi luar biasa, jika bukan karena perubahan dalam kebijakan penetapan harga layanan:
biayanya telah meningkat 3+ kali sejak 2013 . Selain itu, sejak tahun lalu, mendapatkan akun percobaan memerlukan komunikasi dengan manajer pribadi, yang membuatnya sulit untuk menghadirkan produk ke pelanggan potensial.
Situasi yang biasa: Relik Baru tidak diperlukan secara βberkelanjutanβ, ia hanya diingat pada saat masalah dimulai. Tetapi Anda masih perlu membayar secara teratur (140 USD per server per bulan), dan dalam infrastruktur cloud yang dapat disesuaikan secara otomatis, jumlahnya agak besar. Meskipun ada kemungkinan "Pay-As-You-Go," tetapi untuk mengaktifkan New Relic Anda harus me-restart aplikasi, yang dapat menyebabkan hilangnya situasi masalah di mana semuanya dimulai. Belum lama ini, New Relic memperkenalkan rencana tarif baru -
Essentials , yang sekilas tampak seperti alternatif yang masuk akal untuk Profesional ... tetapi setelah diteliti lebih dekat ternyata beberapa fungsi penting hilang (khususnya, tidak memiliki
Transaksi Utama ,
Penelusuran Aplikasi Silang, Pelacakan Terdistribusi ) .
Akibatnya, kami berpikir untuk menemukan alternatif yang lebih murah, dan pilihan kami jatuh pada dua layanan Datadog dan Atatus. Kenapa tepatnya pada mereka?
Tentang pesaing
Saya harus segera mengatakan bahwa ada solusi lain di pasar. Kami bahkan mempertimbangkan opsi Open Source, tetapi tidak setiap klien memiliki kapasitas gratis untuk meng-host solusi yang di-host-sendiri ... - selain itu, mereka akan membutuhkan perawatan tambahan. Pasangan yang kami pilih ternyata paling dekat dengan
kebutuhan kami :
- dukungan built-in dan dikembangkan untuk aplikasi PHP (tumpukan klien kami sangat beragam, tetapi merupakan pemimpin yang jelas dalam konteks menemukan alternatif untuk Relik Baru);
- biaya terjangkau (kurang dari 100 USD per bulan per host);
- instrumentasi otomatis;
- Integrasi kubernet
- kesamaan dengan antarmuka New Relic adalah nilai tambah yang nyata (karena teknisi kami terbiasa dengan hal itu).
Karena itu, pada tahap seleksi awal, kami menghilangkan beberapa solusi populer lainnya, dan khususnya:
- Tideways, AppDynamics, dan Dynatrace - untuk harganya;
- Stackify - diblokir di Federasi Rusia dan menunjukkan terlalu sedikit data.
Artikel selanjutnya disusun sedemikian rupa sehingga solusi yang dipertimbangkan akan disajikan secara singkat terlebih dahulu, setelah itu saya akan berbicara tentang interaksi khas kami dengan Relik Baru dan pengalaman / kesan melakukan operasi serupa di layanan lain.
Presentasi pesaing terpilih

Mungkin semua orang mendengar tentang
Relik Baru ? Layanan ini mulai dikembangkan lebih dari 10 tahun yang lalu, pada tahun 2008. Kami telah menggunakannya secara aktif sejak 2012 dan tidak mengalami masalah integrasi dengan sejumlah besar aplikasi di PHP, Ruby dan Python, dan kami juga memiliki pengalaman berintegrasi dengan C # dan Go. Para penulis layanan memiliki solusi untuk memantau aplikasi, infrastruktur, menelusuri infrastruktur layanan mikro, aplikasi yang mudah digunakan untuk perangkat pengguna telah dibuat, dan banyak lagi.
Namun, agen New Relic bekerja pada protokol milik, ia tidak memiliki dukungan OpenTracing. Instrumentasi tingkat lanjut memerlukan pengeditan khusus untuk Relik Baru. Akhirnya, dukungan untuk Kubernetes memiliki status eksperimental sejauh ini.
Datadog ,
yang memulai pengembangannya pada 2010, terlihat jauh lebih menarik daripada New Relic dalam hal penggunaannya di lingkungan Kubernetes. Secara khusus, ini mendukung integrasi dengan NGINX Ingress, pengumpulan log, statsd dan protokol OpenTracing, yang memungkinkan Anda untuk melacak permintaan pengguna dari saat terhubung ke akhir pekerjaan, serta menemukan log untuk permintaan ini (baik di sisi server web dan di samping) konsumen).
Saat menggunakan Datadog, kami dihadapkan dengan fakta bahwa terkadang ada kesalahan dalam membangun peta layanan mikro, dan beberapa kelemahan teknis. Misalnya, dia salah menentukan jenis layanan (dia mengambil Django untuk layanan caching) dan menyebabkan kesalahan ke-500 dalam aplikasi PHP menggunakan perpustakaan Predis yang populer.
Atatus adalah instrumen termuda; layanan diluncurkan pada 2014. Anggaran pemasarannya jelas lebih rendah daripada pesaing yang terdaftar, yang menyebutkan lebih jarang. Namun demikian, alat itu sendiri sangat mirip dengan New Relic, dan tidak hanya dalam fitur (APM, pemantauan Browser, dll.), Tetapi juga dalam penampilan.
Kelemahan signifikan hanya mendukung untuk Node.js dan PHP. Di sisi lain, ini diterapkan jauh lebih baik daripada Datadog. Berbeda dengan yang terakhir, Atatus tidak memerlukan aplikasi untuk mengubah atau mengatur tag tambahan dalam kode.
Bagaimana kami bekerja dengan Relik Baru
Sekarang mari kita cari tahu bagaimana kita biasanya menggunakan Relik Baru. Misalkan kita memiliki masalah yang perlu diselesaikan:

Sangat mudah untuk melihat
lonjakan pada grafik - kami menganalisisnya. Di New Relic, transaksi web langsung dipilih untuk aplikasi web, semua komponen ditunjukkan dalam grafik kinerja, ada panel tingkat kesalahan, tingkat permintaan ... Yang terpenting, langsung dari panel ini Anda dapat berpindah antar bagian aplikasi yang berbeda (misalnya, mengklik pada MySQL akan ke bagian basis data).
Karena dalam contoh ini kita melihat lonjakan aktivitas
PHP , klik pada bagan ini dan secara otomatis pergi ke
Transaksi :

Daftar transaksi, yang pada dasarnya adalah pengendali dari model MVC, sudah disortir berdasarkan
Kebanyakan memakan waktu , yang sangat nyaman: kita segera melihat apa yang dilakukan aplikasi. Berikut adalah contoh permintaan panjang yang dikumpulkan secara otomatis oleh New Relic. Switching sorting mudah ditemukan:
- pengontrol aplikasi yang paling banyak dimuat;
- Pengontrol yang paling sering diminta
- yang paling lambat dari pengendali.
Selain itu, Anda dapat memperluas setiap transaksi dan melihat apa yang dilakukan aplikasi pada saat eksekusi kode:

Akhirnya, contoh jejak kueri panjang (yang bekerja lebih dari 2 detik) disimpan dalam aplikasi. Inilah panel untuk transaksi panjang:

Dapat dilihat bahwa dua metode membutuhkan banyak waktu, dan dengan itu waktu ketika permintaan dieksekusi, URI dan domainnya juga ditampilkan. Sangat sering ini membantu untuk menemukan kueri di log. Pergi ke
detail Trace , Anda dapat melihat dari mana metode ini dipanggil:

Dan dalam
Kueri basis data - mengevaluasi kueri basis data yang dieksekusi pada saat aplikasi:

Berbekal pengetahuan ini, kita dapat menilai penyebab perlambatan aplikasi dan, bersama dengan pengembang, mengembangkan strategi untuk memecahkan masalah. Pada kenyataannya, New Relic tidak selalu memberikan gambaran yang jelas, tetapi membantu memilih vektor investigasi:
PDO::Construct
panjang menuntun kami ke fungsi pgpoll yang aneh;- ketidakstabilan dalam waktu
Memcache::Get
konfigurasi yang disarankan dari mesin virtual; - peningkatan waktu yang mencurigakan untuk memproses templat menyebabkan loop bersarang dengan tanda centang untuk keberadaan 500 avatar dalam penyimpanan objek;
- dan seterusnya ...
Itu juga terjadi bahwa alih-alih mengeksekusi kode pada layar utama, sesuatu yang berkaitan dengan penyimpanan data eksternal tumbuh - dan tidak masalah apa yang akan terjadi: Redis atau PostgreSQL - semuanya tersembunyi di tab
Databases .

Anda dapat memilih basis spesifik untuk penelitian dan mengurutkan kueri - mirip dengan bagaimana hal itu dilakukan dalam Transaksi. Dan dengan masuk ke tab permintaan, Anda dapat melihat seberapa banyak permintaan ini ditemukan di masing-masing pengontrol aplikasi, serta mengevaluasi seberapa sering itu disebut. Ini sangat nyaman:

Tab
Layanan Eksternal berisi data serupa, yang menyembunyikan permintaan untuk layanan HTTP eksternal, seperti mengakses penyimpanan objek, mengirim acara ke penjaga, atau sejenisnya. Menurut kontennya, tab ini benar-benar mirip dengan Basis Data:

Pesaing: peluang dan kesan
Sekarang hal yang paling menarik adalah membandingkan kemampuan New Relic dengan apa yang ditawarkan pesaing. Sayangnya, kami tidak dapat menguji ketiga alat pada versi yang sama dari satu aplikasi yang berjalan dalam produksi. Namun demikian, kami mencoba membandingkan situasi / konfigurasi yang paling identik.
1. Datadog
Datadog menyambut kami dengan panel dengan dinding layanan:

Dia mencoba memecah aplikasi menjadi komponen / layanan mikro, jadi dalam contoh aplikasi Django kita melihat 2 koneksi ke PostgreSQL (
defaultdb
dan
postgres
), serta Celery, Redis. Bekerja dengan Datadog mengharuskan Anda memiliki pengetahuan minimum tentang prinsip-prinsip MVC: Anda harus memahami dari mana permintaan pengguna berasal. Biasanya
peta layanan membantu dengan ini:

Ngomong-ngomong, ada sesuatu yang serupa di New Relic:

... selain itu, peta mereka, menurut pendapat saya, dibuat lebih sederhana dan lebih mudah dipahami: ini menampilkan bukan komponen dari satu aplikasi (yang akan membuatnya tidak perlu dirinci, seperti dalam kasus Datadog), tetapi hanya layanan atau layanan mikro tertentu.
Kembali ke Datadog: jelas dari peta layanan bahwa permintaan pengguna datang ke Django. Mari kita pergi ke layanan Django dan akhirnya melihat apa yang kita harapkan:

Sayangnya, secara default tidak ada grafik
waktu transaksi Web yang mirip dengan yang kita lihat di panel utama New Relic. Namun, ini dapat dikonfigurasikan sebagai ganti dari
% dari waktu yang dihabiskan grafik. Cukup untuk mengubahnya ke
waktu rata -
rata per permintaan berdasarkan Jenis ... dan sekarang bagan yang sudah familier melihat kita!

Mengapa Datadog memilih jadwal yang berbeda adalah misteri bagi kami. Itu juga membuat frustasi bahwa sistem tidak mengingat pilihan pengguna (tidak seperti kedua pesaing), dan karena itu hanya pembuatan panel kustom yang menyelamatkan.
Tetapi saya senang dengan kesempatan di Datadog untuk beralih dari grafik ini ke metrik server terkait, membaca log dan mengevaluasi beban penangan server web (Gunicorn). Semuanya hampir sama seperti di New Relic ... dan bahkan beberapa lagi (log)!
Di bawah grafik adalah transaksi yang sepenuhnya mirip dengan Relik Baru:

Dalam Datadog, transaksi disebut
sumber daya . Anda dapat mengurutkan pengontrol berdasarkan jumlah permintaan, berdasarkan waktu respons rata-rata, dengan waktu berlalu maksimum untuk periode waktu yang dipilih.
Anda dapat memperluas sumber daya dan melihat semua yang telah kami amati di Relik Baru:

Ada statistik pada sumber daya, dan daftar panggilan internal umum, dan contoh permintaan yang dapat diurutkan berdasarkan kode respons ... Omong-omong, teknisi kami sangat menyukai penyortiran ini.
Sumber daya contoh apa pun di Datadog dapat diperluas dan dieksplorasi:

Parameter kueri, diagram ringkasan waktu yang telah berlalu untuk masing-masing komponen, dan diagram air terjun, di mana urutan panggilan terlihat, disajikan. Juga, beralih ke tampilan pohon diagram air terjun juga tersedia:

Dan hal yang paling menarik adalah melihat beban host tempat permintaan dieksekusi, dan melihat log permintaan.

Integrasi hebat!
Anda mungkin bertanya-tanya di mana tab
Databases dan
Layanan Eksternal berada, seperti di New Relic. Mereka tidak ada di sini: karena Datadog mem-parsing aplikasi ke dalam komponen-komponen, PostgreSQL akan dianggap sebagai
layanan yang terpisah , dan alih-alih Layanan Eksternal, layak untuk mencari
aws.storage
(itu akan sama untuk setiap layanan eksternal lain yang dapat diakses oleh aplikasi).

Dan berikut ini adalah contoh dengan
postgres
:

Sebenarnya, ada semua yang kami inginkan:

Itu bisa dilihat dari mana "layanan" permintaan datang.
Tidak akan berlebihan untuk mengingat bahwa Datadog terintegrasi sempurna dengan NGINX Ingress dan memungkinkan penelusuran ujung-ke-ujung dari saat permintaan masuk dalam kluster, dan juga memungkinkan Anda untuk menerima metrik statsd, mengumpulkan log, dan metrik host.
Nilai tambah yang besar dari Datadog adalah harganya
terdiri dari infrastruktur pemantauan, APM, uji Log Management dan Synthetics, yaitu Anda dapat secara fleksibel memilih rencana.
2. Atatus
Tim Atatus mengklaim bahwa layanan mereka "sama dengan Relik Baru, tetapi lebih baik." Mari kita lihat apakah ini benar-benar demikian.
Bilah judul benar-benar terlihat sama, tetapi tidak mungkin untuk menentukan Redis dan memcached yang digunakan dalam aplikasi.

APM memilih semua transaksi secara default, meskipun biasanya hanya Web yang diperlukan. Seperti pada Datadog, tidak ada cara untuk pergi ke layanan yang diinginkan dari panel utama. Selain itu, transaksi terdaftar setelah kesalahan, yang untuk APM tidak terlihat sangat logis.
Dalam transaksi Atatus, semuanya sama dengan New Relic mungkin. Minus - Anda tidak dapat langsung melihat dinamika untuk masing-masing pengontrol. Anda harus mencarinya di tabel controller, mengurutkan berdasarkan
Most Time Consumed :

Daftar pengendali yang biasa tersedia di tab
Jelajahi :

Dalam beberapa hal, tabel ini menyerupai Datadog dan lebih mirip dengan yang ada di New Relic.
Setiap transaksi dapat dikerahkan dan lihat apa yang dilakukan aplikasi:

Panel ini juga lebih menyerupai Datadog: ada sejumlah permintaan, gambaran panggilan secara keseluruhan. Panel atas menyediakan tab dengan kesalahan
HTTP Failures dan contoh permintaan
Session Traces yang lambat:

Jika Anda melakukan transaksi, Anda bisa melihat contoh jejak, Anda bisa mendapatkan daftar permintaan ke database dan melihat header permintaan. Semuanya mirip dengan Relik Baru:

Secara umum, Atatus senang dengan jejak terperinci - tanpa menempelkan panggilan Relik Baru ke dalam blok pengingat:


Namun, tidak ada cukup filter yang akan (seperti di New Relic) memotong permintaan ultrafast (<5ms). Di sisi lain, menampilkan respons transaksi akhir (berhasil atau salah) menyenangkan.
Panel
Databases akan membantu Anda memeriksa permintaan ke database eksternal yang dibuat aplikasi. Biarkan saya mengingatkan Anda bahwa Atatus hanya menemukan PostgreSQL dan MySQL, meskipun Redis dan memcached juga terlibat dalam proyek ini.

Permintaan diurutkan berdasarkan kriteria yang biasa: frekuensi respons, waktu respons rata-rata, dan sebagainya. Saya juga ingin mencatat tab dengan pertanyaan paling lambat - ini sangat nyaman. Selain itu, data pada tab ini untuk PostgreSQL bertepatan dengan data dari ekstensi
pg_stat_statements - hasil yang sangat baik!

Tab
Permintaan Eksternal identik dengan Database.
Kesimpulan
Kedua alat yang disajikan berkinerja baik dalam peran APM. Salah satu dari mereka dapat menawarkan minimum yang diperlukan. Ringkaslah kesan kami sebagai berikut:
Datadog
Pro:
- jadwal tarif yang nyaman (APM biaya 31 USD per host);
- tampil baik dengan Python;
- kemampuan untuk berintegrasi dengan OpenTracing
- Integrasi kubernet
- Integrasi dengan NGINX Ingress.
Cons:
- Satu-satunya APM yang menyebabkan tidak dapat diaksesnya aplikasi karena kesalahan modul (predis)
- alat bantu PHP yang lemah;
- sebagian definisi layanan yang aneh dan tujuannya.
Atatus
Pro:
- instrumentasi mendalam dari PHP;
- Antarmuka pengguna baru seperti Relic.
Cons:
- tidak bekerja pada sistem operasi yang lebih lama (Ubuntu 12.05, CentOS 5);
- alat-alat otomatis yang lemah;
- dukungan hanya untuk dua bahasa (Node.js dan PHP);
- pengoperasian antarmuka yang lambat.
Dengan harga Atatus sebesar 69 USD per bulan per server, kami lebih suka menggunakan Datadog, yang terintegrasi sempurna untuk kebutuhan kami (aplikasi web dalam K8) dan memiliki banyak fitur yang bermanfaat.
PS
Baca juga di blog kami: