🥇Yalnızca New Relic değil: Datadog ve Atatus'a bir bakış

SRE/DevOps mühendislerinin ortamında, bir gün bir müşterinin (veya bir izleme sisteminin) ortaya çıkıp "her şeyin kaybolduğunu" bildirmesi kimseyi şaşırtmayacaktır: site çalışmıyor, ödemeler yapılmıyor, hayat kötüye gidiyor ... Böyle bir durumda ne kadar yardım etmek isterseniz isteyin, basit ve anlaşılır bir araç olmadan bunu yapmak çok zor olabilir. Çoğu zaman sorun uygulama kodunun kendisinde gizlidir; yalnızca onu yerelleştirmeniz yeterlidir.

Hem acıda hem sevinçte...

Öyle oldu ki New Relic'e uzun süredir ve derinden aşık olduk. Uygulama performansını izlemek için mükemmel bir araçtı ve öyle olmaya da devam ediyor ve aynı zamanda mikro hizmet mimarisini (aracısını kullanarak) ve çok daha fazlasını denetlemenize olanak tanıyor. Hizmetin fiyatlandırma politikasında değişiklik olmasaydı her şey harika olabilirdi: maliyet 2013 yıl 3+ kat büyüdü. Ayrıca geçen yıldan bu yana deneme hesabı almak, kişisel bir yöneticiyle iletişim kurmayı gerektiriyor ve bu da ürünün potansiyel müşteriye sunulmasını zorlaştırıyor.

Olağan durum: New Relic'e "kalıcı olarak" ihtiyaç duyulmaz; bunu yalnızca sorunların başladığı anda hatırlarlar. Ancak yine de düzenli olarak ödeme yapmanız gerekiyor (sunucu başına ayda 140 USD) ve otomatik olarak ölçeklenen bir bulut altyapısında meblağlar oldukça büyük oluyor. Kullandıkça Öde seçeneği olmasına rağmen, New Relic'i etkinleştirmek uygulamayı yeniden başlatmanızı gerektirecektir, bu da her şeyin başlatıldığı sorunlu durumun kaybolmasına yol açabilir. Kısa bir süre önce New Relic yeni bir tarife planı sundu - Temel, - ilk bakışta Professional'a makul bir alternatif gibi görünüyor... ancak daha yakından incelendiğinde bazı önemli işlevlerin eksik olduğu ortaya çıktı (özellikle Anahtar İşlemler, Çapraz Uygulama İzleme, Dağıtılmış İzleme).

Sonuç olarak daha ucuz bir alternatif aramayı düşünmeye başladık ve tercihimiz iki hizmet arasında kaldı: Datadog ve Atatus. Neden onlara?

Rakipler hakkında

Piyasada başka çözümlerin de olduğunu hemen söyleyeyim. Açık Kaynak seçeneklerini bile değerlendirdik, ancak her istemcinin kendi kendine barındırılan çözümleri barındırmak için boş kapasitesi yoktur... - ayrıca ek bakım gerektireceklerdir. Seçtiğimiz çift birbirimize en yakın çift oldu bizim ihtiyaçlarımız:

PHP uygulamaları için yerleşik ve gelişmiş destek (müşterilerimizin yığını çok çeşitlidir, ancak bu, New Relic'e alternatif arama bağlamında açık bir liderdir);
uygun maliyet (ana bilgisayar başına ayda 100 USD'den az);
otomatik enstrümantasyon;
Kubernetes ile entegrasyon;
New Relic arayüzüne olan benzerlik dikkat çekici bir artı (çünkü mühendislerimiz buna alışkın).

Bu nedenle, ilk seçim aşamasında diğer birçok popüler çözümü eledik, özellikle:

Tideways, AppDynamics ve Dynatrace - maliyet açısından;
Stackify Rusya Federasyonu'nda engellendi ve çok az veri gösteriyor.

Yazının geri kalanı öncelikle söz konusu çözümlerin kısaca sunulacağı şekilde yapılandırılmıştır, ardından New Relic ile tipik etkileşimimizden ve diğer servislerde benzer işlemleri gerçekleştirmeden edinilen deneyim/izlenimlerden bahsedeceğim.

Seçilen yarışmacıların sunumu

Hakkında Yeni Relic, muhtemelen herkes duymuştur? Bu hizmet 10 yılı aşkın bir süre önce, 2008 yılında geliştirilmeye başlandı. 2012'den beri aktif olarak kullanıyoruz ve PHP, Ruby ve Python'da gerçekten çok sayıda uygulamayı entegre etmekte hiç sorun yaşamadık, ayrıca C# ve Go ile entegrasyon deneyimimiz de var. Hizmetin yazarları, uygulamaları izleme, altyapı, mikro hizmet altyapılarını izleme, kullanıcı cihazları için uygun uygulamalar oluşturma ve çok daha fazlası için çözümlere sahiptir.

Ancak New Relic aracısı özel protokoller üzerinde çalışır ve OpenTracing'i desteklemez. Gelişmiş enstrümantasyon, New Relic'e özel düzenlemeler gerektirir. Son olarak Kubernetes desteği hâlâ deneyseldir.

Geliştirmeye 2010 yılında başladı veri köpeği Kubernetes ortamlarında kullanım açısından New Relic'ten belirgin şekilde daha ilginç görünüyor. Özellikle NGINX Ingress, log toplama, statsd ve OpenTracing protokolleriyle entegrasyonu destekler; bu, bir kullanıcı isteğini bağlandığı andan tamamlanana kadar izlemenize ve bu isteğe ilişkin günlükleri bulmanıza olanak tanır (her ikisi de web sunucusu tarafında). ve tüketici tarafında).

Datadog'u kullanırken bazen mikroservis haritasını hatalı oluşturduğuyla ve bazı teknik eksikliklerle karşılaştık. Örneğin, hizmet türünü yanlış tanımladı (Django'yu önbellekleme hizmetiyle karıştırdı) ve popüler Predis kitaplığını kullanan bir PHP uygulamasında 500 hataya neden oldu.

Atatürk — en genç enstrüman; hizmet 2014 yılında başlatıldı. Pazarlama bütçesi, listelenen rakiplerden açıkça daha düşüktür, sözlerden çok daha az sıklıkta bahsedilmektedir. Ancak aracın kendisi New Relic'e yalnızca yetenekleri (APM, Tarayıcı izleme vb.) açısından değil, aynı zamanda görünüm açısından da çok benzer.

Önemli bir dezavantajı yalnızca Node.js ve PHP'yi desteklemesidir. Öte yandan Datadog'dan belirgin şekilde daha iyi uygulanıyor. İkincisinin aksine Atatus, uygulamaların kodda değişiklik yapmasını veya ek etiketler eklemesini gerektirmez.

New Relic ile nasıl çalışıyoruz?

Şimdi New Relic'i genel olarak nasıl kullandığımızı bulalım. Diyelim ki çözüm gerektiren bir sorunumuz var:

Grafikte görmek kolaydır всплеск - Hadi analiz edelim. New Relic'te web işlemleri bir web uygulaması için anında seçiliyor, performans grafiğinde tüm bileşenler belirtiliyor, hata oranı, istek oranı panelleri var... En önemlisi bu panellerden doğrudan farklı uygulamalar arasında geçiş yapabiliyorsunuz. uygulamanın bazı bölümleri (örneğin, MySQL'e tıklamak veritabanı bölümüne yönlendirecektir).

İncelenen örnekte aktivitede bir artış gördüğümüz için PHP, bu grafiğe tıklayın ve otomatik olarak şuraya gidin: işlemler:

Temelde MVC modelinin denetleyicileri olan işlemlerin listesi zaten şuna göre sıralanmıştır: Çoğu zaman alıcıBu çok kullanışlı: uygulamanın ne yaptığını hemen görüyoruz. Burada New Relic tarafından otomatik olarak toplanan uzun sorgu örnekleri verilmiştir. Sıralamayı değiştirerek şunları bulmak kolaydır:

en çok yüklenen uygulama denetleyicisi;
en sık talep edilen denetleyici;
denetleyicilerin en yavaşıdır.

Ek olarak, her işlemi genişletebilir ve kodun yürütüldüğü sırada uygulamanın ne yaptığını görebilirsiniz:

Son olarak uygulama, uzun isteklerin (2 saniyeden uzun sürenler) izlerinin örneklerini saklar. İşte uzun bir işlemin paneli:

İki yöntemin çok zaman aldığı ve aynı zamanda isteğin yürütüldüğü zaman, URI'si ve etki alanının da gösterildiği görülebilir. Çoğu zaman bu, günlüklerde isteği bulmaya yardımcı olur. Gidiyor İzleme ayrıntıları, bu yöntemlerin nereden çağrıldığını görebilirsiniz:

Ve içinde Veritabanı sorguları — uygulama çalışırken yürütülen veritabanlarına yönelik sorguları değerlendirin:

Bu bilgiyle donanmış olarak uygulamanın neden yavaşladığını değerlendirebilir ve geliştiriciyle birlikte çalışarak sorunu çözecek bir strateji geliştirebiliriz. Gerçekte New Relic her zaman net bir tablo sunmaz ancak araştırma vektörünün seçilmesine yardımcı olur:

uzun PDO::Construct bizi pgpoll'un tuhaf işleyişine götürdü;
zamanla istikrarsızlık Memcache::Get sanal makinenin yanlış yapılandırıldığını öne sürdü;
Şablon işleme için şüpheli derecede artan süre, nesne deposunda 500 avatarın iç içe geçmiş bir döngü tarafından kontrol edilmesine yol açtı;
vb…

Ayrıca, ana ekranda kod yürütmek yerine harici veri depolamayla ilgili bir şey büyüyor - ve ne olacağı önemli değil: Redis veya PostgreSQL - hepsi sekmede gizli veritabanları.

İşlemler'de yapıldığına benzer şekilde, araştırma için belirli bir temel seçebilir ve sorguları sıralayabilirsiniz. Ve istek sekmesine giderek bu isteğin uygulama denetleyicilerinin her birinde kaç kez oluştuğunu görebilir ve ayrıca ne sıklıkta çağrıldığını da tahmin edebilirsiniz. Çok rahat:

Sekme benzer verileri içeriyor Dış HizmetlerNesne depolamaya erişim, olayları nöbetçiye gönderme veya benzeri gibi harici HTTP hizmetlerine yönelik istekleri gizleyen. Sekmenin içeriği Veritabanlarına tamamen benzer:

Rakipler: fırsatlar ve izlenimler

Şimdi en ilginç şey New Relic'in yeteneklerini rakiplerin sunduklarıyla karşılaştırmak. Ne yazık ki, üretimde çalışan bir uygulamanın tek bir sürümünde üç aracı da test edemedik. Ancak mümkün olduğunca aynı olan durumları/yapılandırmaları karşılaştırmaya çalıştık.

1. Veri köpeği

Datadog bizi hizmet duvarının yer aldığı bir panelle karşılıyor:

Uygulamaları bileşenlere/mikro hizmetlere ayırmaya çalışır, bu nedenle örnek Django uygulamasında PostgreSQL'e 2 bağlantı göreceğiz (defaultdb и postgres) ve Kereviz, Redis. Datadog ile çalışmak, MVC ilkeleri hakkında minimum düzeyde bilgiye sahip olmanızı gerektirir: kullanıcı isteklerinin genellikle nereden geldiğini anlamanız gerekir. Bu genellikle yardımcı olur hizmetler haritası:

Bu arada New Relic'te de buna benzer bir şey var:

... ve bence haritaları daha basit ve daha net hale getirildi: bir uygulamanın bileşenlerini göstermiyor (bu da onu Datadog örneğinde olduğu gibi aşırı ayrıntılı hale getiriyor), yalnızca belirli hizmetleri veya mikro hizmetleri gösteriyor.

Datadog'a dönelim: Servis haritasından kullanıcı isteklerinin Django'ya geldiğini görebiliriz. Django servisine gidelim ve sonunda ne beklediğimizi görelim:

Maalesef burada varsayılan olarak grafik yok Web işlem süresi, ana New Relic panelinde gördüğümüze benzer. Ancak programın yerine yapılandırılabilir Harcanan Zamanın Yüzdesi. onu değiştirmen yeterli Türe göre istek başına ortalama süre... ve şimdi tanıdık grafik bize bakıyor!

Datadog'un neden farklı bir grafik seçtiği bizim için bir sır. Bir diğer sinir bozucu şey ise sistemin kullanıcının seçimini hatırlamamasıdır (her iki rakibin aksine) ve bu nedenle tek çözüm özel paneller oluşturmaktır.

Ancak Datadog'un bu grafiklerden ilgili sunucuların metriklerine geçme, günlükleri okuma ve web sunucusu işleyicileri (Gunicorn) üzerindeki yükü değerlendirme yeteneğinden memnun kaldım. Her şey New Relic'tekiyle hemen hemen aynı... hatta biraz daha fazlası (günlükler)!

Grafiklerin altında New Relic'e tamamen benzeyen işlemler yer alıyor:

Datadog'da işlemler çağrılır Kaynaklar. Denetleyicileri istek sayısına, ortalama yanıt süresine ve seçilen süre için harcanan maksimum süreye göre sıralayabilirsiniz.

Kaynağı genişletebilir ve New Relic'te daha önce gözlemlediğimiz her şeyi görebilirsiniz:

Kaynakta istatistikler, dahili çağrıların genelleştirilmiş bir listesi ve yanıt koduna göre sıralanabilen istek örnekleri var... Bu arada mühendislerimiz bu sıralamayı gerçekten beğendi.

Datadog'daki herhangi bir örnek kaynak açılabilir ve incelenebilir:

İstek parametreleri, her bir bileşen için harcanan zamanın özet tablosu ve çağrıların sırasını gösteren bir şelale grafiği sunulur. Ayrıca şelale grafiğinin ağaç görünümüne de geçebilirsiniz:

Ve en ilginç şey, isteğin yürütüldüğü ana bilgisayarın yükünü görüntülemek ve istek günlüklerini görüntülemektir.

Harika entegrasyon!

Sekmelerin nerede olduğunu merak edebilirsiniz veritabanları и Dış HizmetlerNew Relic'te olduğu gibi. Burada hiçbiri yok: Datadog uygulamayı bileşenlere ayırdığı için PostgreSQL dikkate alınacaktır ayrı bir hizmetve Harici Hizmetler yerine aramaya değer aws.storage (uygulamanın erişebileceği diğer tüm harici hizmetler için benzer olacaktır).

İşte bir örnek postgres:

Aslında istediğimiz her şey var:

Talebin hangi “hizmetten” geldiğini görebilirsiniz.

Datadog'un, NGINX Ingress ile mükemmel bir şekilde entegre olarak, bir isteğin kümeye geldiği andan itibaren uçtan uca izleme yapmanıza olanak sağladığını, ayrıca istatistik metriklerini almanıza, logları ve ana bilgisayar metriklerini toplamanıza olanak sağladığını hatırlatmak yanlış olmaz. .

Datadog'un büyük bir artısı fiyatıdır şekilleniyor altyapı izleme, APM, Günlük Yönetimi ve Sentetik testinden, yani. Planınızı esnek bir şekilde seçebilirsiniz.

2. Durum

Atatus ekibi hizmetlerinin "New Relic ile aynı ama daha iyi" olduğunu iddia ediyor. Bakalım bu gerçekten böyle mi?

Ana panel benzer görünüyor ancak uygulamada kullanılan Redis'i ve memcached'i belirlemek mümkün olmadı.

APM varsayılan olarak tüm işlemleri seçer, ancak genellikle yalnızca Web işlemlerine ihtiyaç duyulur. Datadog'da olduğu gibi ana panelden istenen hizmete gitmenin bir yolu yoktur. Üstelik işlemlerin hatalardan sonra listelenmesi APM için pek mantıklı görünmüyor.

Atatus işlemlerinde her şey mümkün olduğunca New Relic'e benzer. Dezavantajı ise her kontrolörün dinamiklerinin hemen görülememesidir. Bunu denetleyici tablosunda aramanız gerekir, şuna göre sıralayın: En Çok Harcanan Zaman:

Her zamanki denetleyici listesi sekmede mevcuttur Keşfet:

Bu tablo bazı yönlerden Datadog'u andırıyor ve New Relic'teki benzerinden daha çok beğendim.

Her işlemi genişletebilir ve uygulamanın ne yaptığını görebilirsiniz:

Panel aynı zamanda Datadog'u daha çok andırıyor: çok sayıda istek var, çağrıların genel bir resmi var. Üst panelde bir hata sekmesi bulunur HTTP Hataları ve yavaş sorgu örnekleri Oturum İzlemeleri:

Bir işleme gittiğinizde trace örneğini görebilir, veritabanına gelen isteklerin listesini alabilir ve istek başlıklarına bakabilirsiniz. Her şey New Relic'e benzer:

Genel olarak Atatus, çağrıların bir hatırlatma bloğuna tipik New Relic yapıştırılması olmadan ayrıntılı izlerden memnun kaldı:

Ancak, (New Relic gibi) ultra hızlı istekleri (<5 ms) kesecek bir filtreden yoksundur. Öte yandan son işlem yanıtının (başarılı veya hata) görüntülenmesi hoşuma gitti.

Панель veritabanları uygulamanın harici veritabanlarına yaptığı istekleri incelemenize yardımcı olacaktır. Projede Redis ve memcached'in de yer almasına rağmen Atatus'un yalnızca PostgreSQL ve MySQL'i bulduğunu hatırlatayım.

İstekler olağan kriterlere göre sıralanır: yanıt sıklığı, ortalama yanıt süresi vb. Ayrıca en yavaş sorguların olduğu sekmeden de bahsetmek istiyorum - bu çok kullanışlı. Üstelik PostgreSQL için bu sekmedeki veriler uzantıdaki verilerle çakıştı pg_stat_deyimleri - mükemmel sonuç!

Sekme Harici Talepler Veritabanları ile tamamen aynıdır.

Bulgular

Sunulan her iki araç da APM rolünde iyi performans gösterdi. Bunlardan herhangi biri gerekli minimum tutarı sunabilir. İzlenimlerimizi kısaca şöyle özetleyebiliriz:

veri köpeği

Artıları:

uygun tarife programı (APM'nin ana bilgisayar başına maliyeti 31 USD'dir);
Python'la iyi çalıştı;
OpenTracing ile entegrasyon imkanı
Kubernetes ile entegrasyon;
NGINX Girişi ile entegrasyon.

Eksileri:

bir modül hatası (predis) nedeniyle uygulamanın kullanılamaz hale gelmesine neden olan tek APM;
zayıf PHP otomatik enstrümantasyonu;
Hizmetlerin kısmen garip tanımı ve amaçları.

Atatürk