MongoDB İzleme: SolarWinds, New Relic ve Datadog Karşılaştırması
Test etmek amacıyla, MongoDB 7.0 çalıştıran temiz sistemlere SolarWinds, Datadog ve New Relic'i kurduk. Her aracın kurulum sürecini eksiksiz bir şekilde gerçekleştirdik ve her adımı ve karşılaşılan engeli belgeledik.
MongoDB Performans İzleme Araçları Karşılaştırma Sonuçları
Platform | Kurulum Süresi | Sorgu Profillendirme | Metrik Doğruluk | RAM Kullanımı | En İyisi İçin |
|---|---|---|---|---|---|
5 dakika | ✅ | ✅ %100 doğru | Orta Boy (500 MB) | Üretim optimizasyonu | |
Yeni Relic | 15 dakika | ❌ | ❌ Düşük (hata oranları %23 ila %800 arasında) | Düşük (90MB) | Temel sağlık kontrolleri |
Veri Köpeği | 20+ dakika | ❌ | ⚠️ Belirsiz | Orta Boy (330 MB) | Çoklu teknoloji izleme |
MongoDB izleme performans özeti
- SolarWinds, otomatik algılama özelliğiyle kurulumu 5 dakika içinde tamamladı ve diğerlerinin sahip olmadığı sorgu düzeyinde profil oluşturma olanağı sağladı.
- New Relic, manuel doğrulama adımlarıyla 15 dakika sürdü ve hatalı ölçümler bildirdi.
- Datadog, YAML dosyasında 20 dakikadan fazla düzenleme gerektiriyordu ve yalnızca temel düzeyde görünürlük sunuyordu.
Bu platformların MySQL'i ve test ortamımızı ve metodolojimizi nasıl izlediğini de görebilirsiniz.
1. Kurulum ve Kullanıma Başlama Deneyimi
1. Solarwinds
SolarWinds, MongoDB entegrasyonunu 5 dakikadan kısa sürede tamamladı. SolarWinds, basit bir açılır pencereyle başlıyor: "Neyi izlemek istiyorsunuz?" Veritabanı performansını seçtiğinizde, platform desteklenen veritabanlarını önceden görüntülüyor.
MongoDB seçildikten sonra, Solarwinds mevcut aracıları kontrol eder.
Platform, önceden kurduğumuz ajanı anında algıladı.
Dikkat çeken bir özellik şuydu: arayüz, aracı ayrıntılarını (işletim sistemi, bulut örneği kimliği, sürüm) doğrudan seçim ekranında gösteriyor. Açılır menülerde arama yapmaya gerek yok.
Şimdi SolarWinds, MongoDB kimlik bilgilerini istiyor. Bağlantı ayrıntılarını girdik: localhost, kimlik doğrulama yöntemi (parola tabanlı), kullanıcı adı ve parola. Görüntülenen ad, sunucu bilgilerimizle otomatik olarak dolduruldu, ancak daha önce belirttiğimiz aracı adı yerine tam dahili ana bilgisayar adını kullandı.
Tuhaf bir durum: "Sorgu Yakalama" açılır menüsü hiçbir açıklama olmadan belirdi. Diğer seçeneklerin ne işe yaradığından emin olmadan "Günlük" seçeneğini seçip devam ettik.
Sonraki ekranda çalıştırılacak üç veritabanı komutu gösterildi. Her komutun bir kopyala düğmesi vardı. Bunları MongoDB'de çalıştırdık ve "Veritabanını Gözlemle"ye tıkladık.
Solarwinds bizi işte burada etkiledi. İzinleri kendimiz ayarlamamızı istemek yerine, kopyala-yapıştır komutları sağladı:
- Belirli kimlik bilgilerine sahip bir izleme kullanıcısı oluşturun.
- Gerekli ayrıcalıkları verin (clusterMonitor ve readAnyDatabase rolleri)
- Profil oluşturma seviyesini ayarlayın.
Yapılandırmamızı gösteren bir özet ekranı belirdi. Eklenti durumu "Eklenti dağıtılıyor" şeklinde görünüyordu.
Birkaç saniye sonra durum "Eklenti dağıtımı başarılı" olarak değişti ve kontrol paneline erişim bağlantısı belirdi. Kurulum tamamlandı.
Derinlemesine MongoDB izleme ve sorgu profilleme ile SolarWinds Observability'yi keşfedin. SolarWinds'i inceleyin.
Web Sitesini Ziyaret Et2. New Relic
New Relic'in kurulumu yaklaşık 15 dakika sürdü, ancak asıl sorun süre değildi. Sorun, platformun zaten bilmesi gereken soruları yanıtlamaktan kaynaklanıyordu.
New Relic, Entegrasyonlar ve Aracılar sayfasından başlar.
"Mongo" kelimesini arattığımızda, MongoDB ile ilgili birçok entegrasyon bulduk.
MongoDB'yi seçtikten sonra, New Relic bizden bir izleme yöntemi seçmemizi istedi.
Ajanımız zaten kurulu olduğu için "Bir sunucuda" seçeneğini seçtik. Sonraki ekranda işletim sistemi soruldu. Linux'u seçtik. Ajan zaten sunucuda çalıştığı için bu gereksiz gibi görünse de devam ettik.
Sonraki ekranda MongoDB sunucu bilgileri istendi. "SCRAM" terimi herhangi bir açıklama yapılmadan göründü. Çoğu kişi bunu kullanıcı adı/şifre kimlik doğrulaması olarak bilir, ancak teknik terim kafa karışıklığına yol açıyor.
Devam'a tıkladıktan sonra, New Relic bize hangi sunucuya kurulum yapacağımızı sordu. Bu soru, yapılandırma ayrıntılarını girdikten sonra değil, ilk önce sorulmalıydı. Aracı zaten "aimultiple-benchmark" sunucusuna kurulmuştu, bu yüzden onu seçip devam ettik.
Sonraki ekranda MongoDB sürüm uyumluluğunu doğrulamamız istendi. New Relic, mongod --version komutunu çalıştırmamızı ve çıktının gereksinimleriyle eşleştiğini onaylamamızı istedi. Komutu kopyalayıp terminale geçmemiz, çalıştırmamız, sürüm numarasını kontrol etmemiz ve devam etmek için geri dönmemiz gerekiyordu.
Ajan zaten sunucuya kurulu. Bunu otomatik olarak kontrol edebilir.
Devam et'e tıkladıktan sonra, kullanıcı oluşturma adımına ulaştık. New Relic, izleme kullanıcısını oluşturmak için bir MongoDB betiği sağladı. Komutlar açık ve doğru rol atamaları (clusterMonitor ve readAnyDatabase) içeriyordu. Ayrıca, kullanıcının doğru çalıştığını doğrulamak için bir bağlantı testi komutu çalıştırmamız gerekti.
Bu yaklaşım, root erişimi istemekten daha iyiydi, ancak bu komutları nerede çalıştıracağımızı kendimizin bulacağını varsayıyordu.
Sonraki ekranda entegrasyon paketini kurmamız istendi. Şimdi New Relic, yum kullanarak manuel olarak kurmamızı istiyor. Aracı zaten Ubuntu'ya kurulu olmasına rağmen, arayüz varsayılan olarak Amazon Linux'u seçiyor ve apt yerine yum kurulum komutları sunuyor. Platformun kurulu aracıdan doğru işletim sistemini otomatik olarak algılamasını bekliyorduk.
Ubuntu için doğru apt komutunu çalıştırdık, ardından bir sonraki ekrana geçtik. New Relic bize bir YAML yapılandırma dosyası sağladı ve tam olarak nereye koymamız gerektiğini söyledi: /etc/newrelic-infra/integrations.d/. En azından dosya yolu açıktı.
Dosyayı oluşturduk, yapılandırmayı yapıştırdık ve Devam'a tıkladık. Son ekranda "Bağlantıyı test et" düğmesi göründü. Ona tıkladık ve bekledik.
Test başarılı geçti. Kurulum tamamlandı.
3. Datadog
Datadog'un kurulumu 20 dakikadan fazla sürdü. Entegrasyon sonunda çalıştı, ancak bu noktaya ulaşmak önemli ölçüde manuel çaba gerektirdi.
Giriş yaptıktan sonra Entegrasyonlar bölümüne gittik ve "mongo" kelimesini aradık. MongoDB'ye tıkladığımızda bir açılır pencere belirdi.
Genel bakış, MongoDB izleme özelliğinin neleri içerdiğini gösteriyordu, ancak "Entegrasyonu Yükle" seçeneğine tıkladığınızda yoğun talimatlar içeren başka bir ekran açıldı.
İşte bu noktada Datadog bizi hayrete düşürdü. Ekranda, olası her MongoDB senaryosunu kapsayan eksiksiz bir referans kılavuzu gösteriliyordu: bağımsız örnekler, çoğaltma kümeleri, parçalanmış kümeler, kimlik doğrulama yöntemleri, SSL yapılandırması ve daha fazlası.
Tek bir MongoDB örneğini izlemeye çalışan biri için bu kadar uzun metin gereksiz geldi.
Temel adımları bulmak için sayfayı aşağı doğru kaydırdık:
- MongoDB'de bir izleme kullanıcısı oluşturun.
- Yapılandırma YAML dosyasını düzenleyin.
- Datadog aracısını yeniden başlatın.
Datadog, kullanıcı oluşturmak için gerekli MongoDB komutlarını sağladı, bu da faydalı oldu. Ancak YAML dosyasına gelince, dokümantasyonda conf.yaml dosyasının nereye yerleştirilmesi gerektiği açıkça belirtilmeden düzenlenmesi gerektiği yazıyordu.
Tecrübemizden bunun /etc/datadog-agent/conf.d/mongo.d/ numaralı koda ait olduğunu biliyorduk, ancak talimatlar bu detayı belgelerin derinliklerine gizlemişti.
MongoDB kullanıcısını oluşturduk, YAML yapılandırma dosyasını yazdık, doğru dizine yerleştirdik ve ajanı yeniden başlattık.
Ardından Datadog arayüzüne geri döndük ve "Entegrasyonu Yükle" seçeneğine tıkladık.
Buton kayboldu. Onay mesajı yok, başarı bildirimi yok, kontrol paneline yönlendirme yok. Hiçbir şey yok.
Bir süre bekledik, ardından manuel olarak Kontrol Panelleri bölümüne gittik ve MongoDB metriklerinin görüntülenmeye başladığını gördük.
2. Ajan Kaynak Tüketimi
Çalışma sırasında her bir ajanın ne kadar kaynak tükettiğini izledik. Test, yaklaşık 10 dakika boyunca, üç ajanın da aynı MongoDB örneğinden eş zamanlı olarak ve yük altında veri toplamasıyla gerçekleştirildi.
Rastgele veri üreten bir komut dosyası kullanarak MongoDB'ye 2 milyon kayıt ekleyerek sistemi zorladık. Bu işlem, gerçek dünya veritabanı etkinliğini simüle ederken, aynı zamanda aracı kaynak kullanımını da ölçtük.
CPU Tüketimi
Test süresince her üç ajan da minimum düzeyde CPU kaynağı kullandı.
- New Relic, ortalama CPU tüketiminde en düşük seviyeyi gösterdi ancak zaman zaman %4'e varan ani yükselişler yaşadı. Bu yükselişler kısa sürdü ve sistem performansını etkilemedi.
- Solarwinds, önemli bir değişiklik olmaksızın %3 civarında kalarak en istikrarlı CPU kullanımını sergiledi.
- Datadog, test boyunca istikrarlı bir performans sergileyerek ortalama %2'nin biraz üzerinde bir sonuçla orta sıralarda yer aldı.
Bellek Kullanımı
Bellek kullanımı, ajanlar arasında daha belirgin farklılıklar gösterdi.
New Relic, Solarwinds'e kıyasla yaklaşık 5-6 kat daha az bellek tüketiyordu. 16 GB'lık test sunucumuzda bu şu anlama geliyordu:
- New Relic: ~90MB
- Datadog: ~330MB
- Solarwinds: ~500MB
Çoğu üretim sunucusu için bu miktarların bir önemi olmayacaktır. Ancak kaynak kısıtlı sistemlerde ajanlar çalıştırıyorsanız veya yüzlerce veritabanını izliyorsanız, fark giderek artar.
Test boyunca her üç ajanda da bellek kullanımı istikrarlı kaldı. Bellek sızıntısı veya beklenmedik bir artış meydana gelmedi.
Disk G/Ç
Disk aktivitesi, ajanlar arasında önemli ölçüde farklılık gösterdi.
SolarWinds, diğer iki ajana kıyasla önemli ölçüde daha fazla disk okuma işlemi gerçekleştirdi; New Relic'in yaklaşık 40 katı ve Datadog'un 1,5 katı kadar. Bu durum, SolarWinds'in muhtemelen sorgu profilleme özellikleri nedeniyle yerel olarak depolanan verilere daha sık eriştiğini göstermektedir.
Datadog, diske en az miktarda veri yazdı; bu da buluta göndermeden önce yerel olarak daha az veri tamponladığını gösteriyor.
New Relic, orta düzeyde okuma ve yazma işlemleriyle en dengeli G/Ç modelini sergiledi.
Ağ Kullanımı
Ağ trafiği, her bir aracının arka uç sunucusuna ne kadar veri gönderdiğini gösterdi.
Üç aracı da ağ üzerinden benzer miktarda veri gönderdi. Datadog biraz daha az veri iletti; bu durum muhtemelen daha agresif sıkıştırma veya farklı örnekleme oranlarından kaynaklanıyor olabilir.
Aracılar platforma ölçümler gönderirken aynı zamanda yapılandırma güncellemeleri veya komutlar aldıkları için çift yönlü trafik mantıklıdır.
Kaynak Etkisi Özeti
Bu ajanların hiçbiri sisteminizi zorlamayacak. Üçü birden aynı anda çalışırken veritabanı yükü altında bile, toplam kaynak tüketimi (CPU ve bellek birlikte) %10'un oldukça altında kaldı.
New Relic bellek verimliliğinde öne çıkıyor. Solarwinds daha fazla kaynak kullanıyor ancak daha detaylı sorgu düzeyinde analiz sunuyor. Datadog ise ikisinin arasında yer alıyor.
Çoğu kullanım senaryosunda, bu kaynak farklılıkları kararınızı etkilemeyecektir. Kaynak tüketimine değil, özelliklere ve kullanılabilirliğe göre seçim yapın.
3. Kontrol Paneli ve İzleme Özellikleri
Kurulumu tamamladıktan sonra, her platformun gerçekte ne gösterdiğini görmemiz gerekiyordu. Üç platformda da aynı iş yükünü çalıştırdık: 5.000'lik gruplar halinde 2 milyon kayıt ekledik, ardından 5 milyon kayıt daha ekledik.
Kullanılan betik, rastgele kullanıcı verileri (adlar, e-postalar, adresler ve telefon numaraları) oluşturmak için Node.js ve Faker'ı kullandı. Bu bize izlemek için gerçekçi bir veri seti sağladı.
Ekleme işlemleri çalışırken, arka planda aracı kaynak tüketimini izledik.
Yoğun iş yükü MongoDB üzerinde ciddi bir baskı oluşturdu ve bu da her platformun etkinliği nasıl yakalayıp gösterdiğini görmemizi sağladı.
Solarwinds Kontrol Paneli
Soldaki menüden "Veritabanları"na tıkladık ve hemen MongoDB örneğimizi gördük. Tek bir tıklamayla eksiksiz bir kontrol paneli belirdi.
Ekranın üst kısmında MongoDB sağlığı, ortalama yanıt süresi, işlem hacmi (saniyede sorgu sayısı) ve hata sayısı gösteriliyordu. "En Çok Kullanılan 10 Hizmet Dağılımı" baloncuk grafiği, en sık kullanılan sorgu kalıplarını sayıları ve yüzdeleriyle birlikte gösteriyordu.
Rakamlar her şeyi anlatıyordu. İşlem hızı ortalama saniyede 3 sorgu gösteriyordu. Detaylı inceleme 1400 ekleme işlemi gösteriyordu. Neden 7 milyon yerine 1400?
7 milyon kaydı 5.000'lik gruplar halinde ekledik. Bu da 1.400 toplu işlem anlamına geliyor. Solarwinds, tek bir grubu bile kaçırmadan her bir grubu takip etti.
Profilleyici sekmesi, ortalama yürütme süreleriyle birlikte sorgu kalıplarını gösterdi.
Ekleme sorgularımızın her biri 4-5 saniye sürdü; bu süre, her sorgunun 5.000 satır yazdığını hatırlayınca kısaldı.
Sağlık sekmesi her şeyin sorunsuz çalıştığını gösteriyordu.
Solarwinds'in bunu ne kadar çabuk fark edeceğini görmek için MongoDB hizmetini durdurduk. 30-40 saniye içinde sağlık durumu "Kötü" olarak değişti.
Sorgular sekmesi gelişmiş filtreleme imkanı sunuyordu. Şu sorguları listeleyebiliyordunuz:
- Döndürülen hatalar
- Uygun indeksler olmadan çalıştırıldı
- Yavaş yanıt verdi
- Oluşturulan uyarılar
Her sorgu modeli, ilk ne zaman ortaya çıktığını, en son ne zaman çalıştırıldığını, kaç örnek yakalandığını ve yürütme istatistiklerini gösteriyordu. Sorun giderme için bu ayrıntı düzeyi önemlidir.
Uyarılar sekmesi, MongoDB'ye özgü uyarılar oluşturmamızı sağladı. Daha önce sunucu için bir bellek uyarısı oluşturmuştuk, ancak şimdi veritabanına özgü bildirimler ayarlayabilirdik.
Kaynaklar sekmesi, MongoDB istatistikleri, CPU, bellek, disk ve ağ ile birlikte sunucu düzeyindeki ölçümleri gösteriyordu. Bu bağlam, veritabanı sorunları ile altta yatan altyapı sorunları arasında ayrım yapmaya yardımcı olur.
Danışmanlar sekmesinde henüz herhangi bir öneri bulunmuyor, ancak önceki testimizde MySQL için öneriler sunmuştu. Daha fazla MongoDB verisi topladıkça optimizasyon önerileri sunmasını bekliyoruz.
Yapay Zeka Güncellemeleri : Ekim 2025'te SolarWinds, Yapay Zeka Sorgu Desteği özelliğine sahip Yapay Zeka Aracısını (şu anda teknik önizleme aşamasında) kullanıma sundu. Yapay Zeka Sorgu Desteği, veritabanı sorgu kalıplarını analiz eder ve performansı otomatik olarak artırmak için optimize edilmiş yeniden yazma önerileri sunar. Kök Neden Desteği (şu anda genel kullanıma açık), sorun giderme süresini azaltmak için uyarılar ve anormalliklere dayalı olarak net kök neden analizleri oluşturur. Yapay Zeka Aracısının SolarWinds portföyü genelinde daha geniş çapta kullanılabilirliği 2026 yılı için planlanmaktadır. 1 2 .
New Relic Kontrol Paneli
Kontrol Panelleri bölümüne gittik, ancak otomatik olarak hiçbir MongoDB kontrol paneli görünmedi.
Kontrol paneli kataloğunda "mongo" kelimesini aradık ve iki MongoDB seçeneği bulduk.
Normal MongoDB kontrol panelini seçtik ve "MongoDB Kurulumu"na tıkladık.
Bizi tekrar MongoDB entegrasyon kurulumuna yönlendirdi. Platform zaten MongoDB'yi kurduğumuzu biliyordu, o yüzden neden bizi tekrar kurulum sayfasına gönderdi ki? "Tamam"ı tıkladık ve kontrol paneline geçtik.
Kontrol paneli tamamen boş açıldı. "mongodb.can_connect hizmet kontrolü için hiçbir değer bildirilmedi."
Yapılandırmamızı newrelic-infra agent configtest kullanarak kontrol ettik.
Yapılandırmamızda sorun olup olmadığını kontrol etmek için newrelic-infra agent configtest komutunu çalıştırdığımızda, integration_name'in nri-prometheus olarak ayarlandığını fark ettik. Kontrol paneli kurulumu sırasında New Relic, biri Prometheus sürümü olmak üzere iki MongoDB seçeneği gösterdi. Kullanıcı arayüzünde bunun farklı bir entegrasyon olduğunu gösteren hiçbir şey yoktu, bu yüzden Prometheus olanı seçtiğim aklıma bile gelmezdi. Bu bir kullanıcı hatası değildi; arayüzde hiçbir yönlendirme veya ayrım yoktu.
Geri dönüp “MongoDB (Prometheus)” kontrol panelini kurduk.
Bu sefer veriler ortaya çıktı.
Ama işte sorun burada: normal bir kullanıcı bunu nasıl anlayacak? Kurulum süreci kafa karıştırıcıydı ve şimdi de kontrol paneli seçimi karmaşıklığı daha da artırdı.
Kontrol panelinin düzeni garip geldi. Üst kısımda yılda bir kez değişen toplam sunucu ve veritabanı bilgileri gösteriliyordu, ancak bu bilgiler ekranın en önemli bölümünü kaplıyordu.
Bunun altında, "Bağlantı Doygunluğu" belirgin bir şekilde yer alıyordu. Bu ölçüt yalnızca bir sorun olduğunda önem taşır. Neden en üste konulmuş?
“Sorgu İşlemleri” bölümünde 11.670 ekleme işlemi rapor edildi. Bu sayı yanlıştı. 1.400 toplu işlemde 7 milyon kayıt ekledik. Grafik gerçekle uyuşmuyordu.
Veritabanları sekmesi veritabanı boyutunu, nesne sayısını ve indeks boyutlarını gösteriyordu. Bu sayılar doğruydu: 7 milyon nesne. New Relic bu verileri MongoDB'ye doğrudan sorgu göndererek alıyor ("Kaç belgeniz var?"). Ancak gerçek zamanlı sorgu sayımı başarısız oldu.
Koleksiyonlar sekmesi, koleksiyon düzeyindeki ölçümler için faydalı grafikler içeriyordu: boyut (hem tablo hem de grafik görünümleriyle), yüzde değişimle birlikte toplam boyut, okuma işlemi sayısı, okuma gecikmesi, yazma işlemi sayısı, yazma gecikmesi, işlem sayısı, işlem gecikmesi, indeks erişim işlemleri, komut yürütme sayısı, komut gecikmesi, komut sıklığı ve komut süresi.
Dikkat çekici bir eksiklik: sunucu metrikleri. MongoDB çalıştıran sunucunun CPU, bellek, disk veya ağ kullanımını göremedik. SolarWinds bu bağlamı içeriyordu, ancak Datadog, New Relic gibi, içermiyordu.
Daha da önemlisi, hiçbir yerde sorgu düzeyinde analiz yoktu. Sorgu kalıpları, profil oluşturma, yavaş sorgu tespiti, eksik indeks algılama gibi özellikler mevcut değildi. Veritabanı sorun giderme açısından bu özellikler önemlidir.
Datadog Kontrol Paneli
Soldaki menüden “Gösterge Panelleri”ne tıkladık. Otomatik olarak “MongoDB – Genel Bakış” gösterge paneli belirdi.
Açtık ama içi boştu.
Sorunun teşhis edilmesi zaman aldı. Kurulum sırasında, Datadog'un otomatik keşif yapılandırması, bir kalıp eşleştirmesi kullanarak hangi veritabanlarının izleneceğini belirtmeyi gerektiriyordu. Varsayılan kalıp, veritabanı adımızla eşleşmiyordu. Datadog kurulum sırasında bundan hiç bahsetmedi.
Tüm kalıpları .* (her şeyi eşleştir) olarak değiştirdik ve ajanı yeniden başlattık.
Peki gösterge paneli neden tamamen boştu? Veritabanına özgü ölçümler olmasa bile, çalışma süresi, bağlantı sayıları ve sunucu istatistikleri görünmeliydi. Görünmediler.
Hata ayıklama için datadog-agent check mongo numaralı komutu çalıştırdık. Yapılandırma dosyasında bir girinti hatası vardı. YAML'nin katı biçimlendirme gereksinimi bizi yakaladı. Hatayı düzelttikten ve 5 milyon ekleme ile yük testimizi yeniden çalıştırdıktan sonra, veriler nihayet göründü.
Kontrol paneliyle ilgili hemen sorunlarla karşılaştık. YAML dosyamızda günlük toplama işlemini yapılandırmış olmamıza rağmen, Günlükler bölümü "Erişilemez" olarak görünüyordu. Datadog'un kurulum süreci her şeyin yolunda olduğunu bildirmesine rağmen, günlükler hala çalışmıyordu.
Kontrol panelinin düzeni, kullanım senaryomuz için pek mantıklı değildi. Üst bölüm, parçalama istatistiklerine odaklanmıştı. Biz parçalanmış bir küme çalıştırmıyorduk. Orta kısım, çoğaltma kümesi metriklerini gösteriyordu. Bizde çoğaltma kümeleri yoktu. Alt kısım tekrar parçalamaya dönüyordu. Kontrol panelinin yaklaşık %60'ı, kullanmadığımız özellikler için boş bölümler gösteriyordu.
Faydalı bilgiler ekranın belki %40'ını kaplıyordu: çalışma süresi, bellek kullanımı, ağ G/Ç, saniyedeki sorgu sayısı ve okuma/yazma gecikmesi. Sorgu analizi yok, profil oluşturma yok, yavaş sorgu tespiti yok, indeks önerisi yok.
Bu kontrol panelinden kaç işlemin yürütüldüğünü bile belirleyemedik.
Test Ortamı ve Metodolojisi
Adil bir karşılaştırma sağlamak için üç aracı da aynı kurulumlarda çalıştırdık. Her testte şunlar kullanıldı:
- Veritabanı: MongoDB 7.0 Community Edition
- Sunucu: AWS m6i.xlarge örneği
- Başlangıç noktası: Ana izleme aracısının zaten kurulu olduğu yeni bir kurulum.
Üç tedarikçinin de MongoDB gibi belirli entegrasyonları eklemeden önce temel aracılarını kurmanızı gerektirdiğini belirtmekte fayda var. Biz bu adımı önceden tamamladığımız için testimiz tamamen MongoDB entegrasyon deneyimine odaklandı.
Ölçtüğümüz şeyler:
- Kurulum karmaşıklığı: Manuel adımların sayısı, otomatik mi yoksa manuel mi yapılandırma olduğu, talimatların netliği ve arayüzün bize yol gösterip göstermediği veya sonraki adımları aramak zorunda bırakıp bırakmadığı.
- Aracının kaynak tüketimi: Boşta ve yük altında (7 milyon kayıt ekleme sırasında) CPU, bellek, disk G/Ç ve ağ kullanımı.
- İzleme yetenekleri: Gösterge paneli kalitesi, ölçüm doğruluğu, sorgu düzeyinde analiz ve sorun giderme özellikleri.
Güvenlik Hususları
MongoDB Server'ın 8.0.17, 7.0.28, 6.0.27 ve önceki sürümlerini etkileyen "MongoBleed" adlı ciddi bir güvenlik açığı ortaya çıktı. Kimlik doğrulaması gerektirmeyen bu sınır dışı okuma güvenlik açığı, saldırganların hassas bellek verilerine erişmesine olanak sağlayabilir. MongoDB kullanan kuruluşlar, derhal yamalı sürümlere (8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32 veya 4.4.30) güncelleme yapmalıdır. 3 4 İzleme araçlarını seçerken, güvenli kimlik doğrulama yöntemlerini desteklediklerinden ve ek güvenlik riskleri oluşturmadıklarından emin olun.
Her bir araca, önceden doküman okumadan ve herhangi bir eğitim almadan, sıradan bir kullanıcı gibi yaklaştık. Arayüzde bir şey açıkça görünmüyorsa, bunu not ettik.
Nihai Karar
Basit bir soruyu yanıtlamak için yola çıktık: Hangi izleme platformu, teknik bilgisi olmayan ekipler için MongoDB entegrasyonunu en kolay hale getiriyor?
Üçünü de kurduktan, aynı iş yüklerini çalıştırdıktan ve gösterge panellerini değerlendirdikten sonra cevap netleşti. Değerlendirmemiz, Ocak 2025 itibarıyla Datadog'un temel MongoDB entegrasyonuna dayanmaktadır. Datadog o zamandan beri MongoDB için Veritabanı İzleme (DBM) ürününü (Aralık 2024) piyasaya sürdü; bu ürün, sorgu profilleme, yavaş işlemler analizi, açıklama planları ve replikasyon izleme dahil olmak üzere önemli ölçüde daha derin özellikler sunmaktadır. DBM ürünü, bu kıyaslamada belirlenen birçok sınırlamayı ele almaktadır. 5 .
Solarwinds: Veritabanı İzleme İçin Tasarlandı
SolarWinds bu karşılaştırmayı açık ara kazandı. Platform, temsilcimizi anında algıladı, kopyala-yapıştır komutlarıyla kimlik bilgilerinin kurulumunda bize rehberlik etti ve entegrasyonu otomatik olarak devreye aldı. Kurulum 5 dakika sürdü.
Kontrol paneli ilgili bilgilerle anında belirdi. Sorgu profillemesi, hangi işlemlerin en çok kaynak tükettiğini tam olarak gösterdi. Platform, 1400 toplu işlemin tamamını hiçbirini kaçırmadan yakaladı. MongoDB'yi durdurduğumuzda, SolarWinds hatayı 40 saniye içinde tespit etti.
Sorgular sekmesi, veritabanı optimizasyonunu doğrudan destekleyen hatalar, eksik indeksler, yavaş yanıtlar ve uyarılar gibi özelliklere göre filtreleme yapmamızı sağlar. Danışmanlar özelliğinin öneriler sunması bekleniyordu (ancak test sırasında herhangi bir öneriyi tetikleyecek kadar veri üretmedik).
Solarwinds, veritabanı yöneticilerinin gerçekten ihtiyaç duyduğu şeylere odaklandı: sorgu analizi, performans profilleme ve uygulanabilir içgörüler.
New Relic: Yapılandırmada Kaybolma
New Relic'in kurulumu 15 dakika sürdü, ancak asıl sorun zaman değildi. Platform soruları yanlış sırayla sordu, ajanın otomatik olarak kontrol edebileceği şeylerin manuel olarak doğrulanmasını gerektirdi ve paketleri manuel olarak yüklememizi zorunlu kıldı.
Kontrol paneli karmaşası işleri daha da kötüleştirdi. MongoDB izleme yazılımını kurduk, ancak varsayılan kontrol panelini seçtiğimizde boş bir ekranla karşılaştık. Yapılandırma dosyalarını inceledikten sonra yanlış entegrasyon türünü seçtiğimizi fark ettik. Sıradan bir kullanıcı bunu anlayamazdı.
Veriler nihayet ortaya çıktığında, ölçümler yanlıştı. New Relic, 1400 toplu işlem gerçekleştirdikten sonra 7 milyon kaydın tamamının eklendiğini ve 11.670 ekleme yapıldığını bildirdi. Platform, gerçek sayıyı bir büyüklük mertebesinde eksik saymıştı.
Daha da önemlisi, New Relic sorgu düzeyinde hiçbir analiz sağlamadı. Profil oluşturma yok, yavaş sorgu tespiti yok, eksik indeks tespiti yok. Veritabanı sorun giderme açısından bu eksiklikler önemlidir.
Datadog: Manuel Çalışma Gereklidir
Datadog'un kurulumu 20 dakikadan fazla sürdü ve oldukça manuel bir yapılandırma gerektirdi. YAML dosyalarını düzenledik, nereye yerleştirileceklerini belirledik ve hizmetleri komut satırından yeniden başlattık.
Kontrol paneli otomatik olarak belirdi ancak hiçbir şey göstermedi. Otomatik keşif yapılandırması, veritabanımızla eşleşmeyen bir kalıp kullandı. Kalıbı düzelttikten ve YAML girinti hatalarını giderdikten sonra, veriler nihayet yüklendi.
Kontrol paneli, tek örnekli MongoDB için oldukça kötü tasarlanmıştı. Ekranın yüzde altmışı boştu ve kullanmadığımız sharding ve replica sets özelliklerine ayrılmış bölümlerden oluşuyordu. Geri kalan yüzde 40'lık kısım ise temel ölçümler sunuyordu: çalışma süresi, bellek, ağ G/Ç, saniyede sorgu sayısı ve gecikme süresi.
Sorgu analizi yok. Profil oluşturma yok. Optimizasyon önerisi yok. Kontrol panelinde işlem sayılarını doğru bir şekilde belirleyemedik.
Sorgu analizi yok. Profil oluşturma yok. Optimizasyon önerisi yok. Kontrol panelinde işlem sayılarını doğru bir şekilde belirleyemedik.
Kritik Güncelleme (Aralık 2024) : Bu kıyaslama tamamlandıktan sonra Datadog, bu değerlendirmeyi önemli ölçüde değiştiren MongoDB için Veritabanı İzleme (DBM) özelliğini kullanıma sundu. MongoDB için DBM artık şunları sağlıyor:
- Ayrıntılı sorgu örnekleriyle yavaş işlemlerin analizi
- Sorgu optimizasyonu planlarını açıklayın.
- Çoğaltma durumu izleme ve küme sağlığı görselleştirme
- Operasyonel düzeyde içgörüler ve performans darboğazlarının belirlenmesi
- Uygulama performans izleme ile entegrasyon, birleşik sorun giderme olanağı sağlar.
DBM, bu kıyaslamada test edilen temel MongoDB entegrasyonuna kıyasla önemli bir yükseltmeyi temsil ediyor ve testlerimiz sırasında eksik olan birçok sorgu düzeyinde analiz özelliğini içeriyor. 6 7 MongoDB izleme için Datadog'u değerlendiren kuruluşlar, burada test edilen temel entegrasyon yerine özellikle Veritabanı İzleme ürününü değerlendirmelidir.
DevOps Uzmanı Olmadığınızda Hangi Veritabanı İzleme Aracı Gerçekten İşe Yarar?
Kurulum Deneyimi
SolarWinds, neyi izlemek istediğinizi soran bir açılır pencereyle açıldı. "Veritabanı performansı"nı seçip MongoDB'yi seçtiğinizde, platform hemen önceden yüklediğiniz ajanı buluyor ve seçim ekranında işletim sistemini, bulut örneği kimliğini ve sürüm numarasını gösteriyor. Ardından, MongoDB'de çalıştırılacak üç kopyala-yapıştır komutu veriyor, kimlik bilgilerini işliyor ve dağıtımı onaylıyor. Baştan sona beş dakika sürüyor.
New Relic kurulumu on beş dakika sürdü ve asıl sorun süre bile değildi. Arayüz, ajan zaten sunucuda kurulu olmasına rağmen, hangi işletim sistemi ve hangi MongoDB sürümü gibi ajanın kendisinin cevaplayabileceği soruları sormaya devam etti. Bir noktada, açıkça Ubuntu kullanıyor olmamıza rağmen, Amazon Linux kurulum komutlarına varsayılan olarak geçti. Sonunda deneyimi bozan adım şuydu: Kontrol paneli kataloğunda iki MongoDB entegrasyon seçeneği var, biri standart, diğeri Prometheus tabanlı ve arayüzde bunları birbirinden ayıran hiçbir şey yok. Yanlış olanı seçtik, boş bir kontrol paneli aldık ve ancak yapılandırma dosyalarına bakarak sorunu anladık.
Datadog'u kurmak için yirmi dakikadan fazla YAML düzenlemesi, dosya yollarını tahmin etme ve komut satırından servisleri yeniden başlatma gerekiyordu. Kurulum sırasında sunulan dokümantasyon bir kılavuz değil; tek başına çalışan örnekleri, çoğaltma kümelerini, parçalı kümeleri ve SSL yapılandırmasını aynı anda kapsayan, sadece tek bir veritabanını izlemek isteyen biri için hazırlanmış tam bir referans kılavuzu. Veriler nihayet göründüğünde, gösterge paneli öncelikle parçalama istatistikleri ve çoğaltma kümesi metrikleriyle başlıyordu. Bizde bunların hiçbiri yoktu. Ekranın yaklaşık yüzde altmışı boştu.
Yük Altında Metrik Doğruluk
SolarWinds 1400 saydı. Tam olarak doğru. New Relic ise 11670 bildirdi; bu, belirgin bir açıklaması olmayan ve test sırasında bellek kullanımındaki ani artışı tamamen gözden kaçıran, büyüklük mertebesinde bir yanlışlıktı. MongoDB hizmetini durdurduğumuzda, SolarWinds hatayı otuz ila kırk saniye içinde tespit etti.
Kaynak tüketimi açısından: 16 GB'lık sunucumuzda New Relic yaklaşık 90 MB RAM, Datadog yaklaşık 330 MB ve SolarWinds yaklaşık 500 MB RAM kullandı. SolarWinds, muhtemelen yerel sorgu profilleme çalışmaları nedeniyle New Relic'ten yaklaşık kırk kat daha fazla disk okuma işlemi gerçekleştirdi. Çoğu ortam için bunların hiçbiri kararınızı etkilemeyecektir.
Onları birbirinden ayıran asıl özellik
Her izleme aracı size bir şeyin yavaş olduğunu söyleyecektir. Soru şu ki, bunun nedenini de söyleyecek mi?
SolarWinds, sorgu düzeyinde profil oluşturma özelliği sunar. Profilleyici sekmesi, hangi sorgu kalıplarının çalıştırıldığını, her birinin ne kadar sürdüğünü ve kaç örnek yakalandığını tam olarak gösterir. İndeks olmadan çalışan, hata döndüren veya uyarı üreten sorgulara göre filtreleme yapabilirsiniz.
New Relic ve Datadog yalnızca gecikme süresi, bağlantı sayısı ve işlem toplamları için toplu ölçümler gösterdi. Profil oluşturma, yavaş sorgu tespiti veya eksik indeks algılama yok. Veritabanının çalışır durumda olduğunu doğrulamak için işe yarar, ancak neden zorlandığını teşhis etmek için çıkmaz sokak.
Not: Datadog, testlerimizin ardından Aralık 2024'te MongoDB için yavaş işlem analizi, açıklama planları ve sorgu düzeyinde görünürlük ekleyen bir Veritabanı İzleme ürünü yayınladı . Çoğu kullanıcının ilk karşılaştığı standart entegrasyonu test ettik.
SolarWinds : Eğer asıl endişeniz veritabanı optimizasyonu ise. Doğru ölçümler, hızlı kurulum ve burada sorgunun yavaş olduğunu söylemekle kalmayıp, bununla ilgili ne yapmanız gerektiğini de söyleyen tek platform.
New Relic : Eğer zaten APM için kullanıyorsanız ve aynı yerde temel veritabanı sağlığına ihtiyacınız varsa, tarayıcıdan kod üzerinden veritabanı çağrısına kadar yavaş bir isteği izlemek gerçekten faydalıdır. Ancak, kesin işlem sayıları için ona güvenmeyin.
Datadog : Eğer manuel yapılandırmaya alışkınsanız ve karmaşık bir sistem genelinde tek bir platform istiyorsanız, doğru ekip için 600'den fazla entegrasyon, kurulum zorluğunu haklı çıkarıyor.
Referans Linkleri
Yorum yapan ilk kişi olun
E-posta adresiniz yayınlanmayacak. Tüm alanlar gereklidir.