MongoDB İzleme: SolarWinds vs New Relic vs Datadog

Test için SolarWinds, Datadog ve New Relic'i MongoDB 7.0 çalışan temiz sistemlere kurduk. Her aracın tüm kurulum sürecini adım adım izledik; her adımı ve engeli belgeledik.

MongoDB performans izleme araçları kıyaslama sonuçları

MongoDB izleme performans özeti

• SolarWinds, otomatik algılama ile kurulumu 5 dakikada tamamladı ve diğerlerinde bulunmayan sorgu düzeyinde profil oluşturma özelliği sağladı.
• New Relic, manuel doğrulama adımlarıyla 15 dakika sürdü ve hatalı metrikler bildirdi.
• Datadog 20+ dakika YAML düzenlemesi gerektirdi ve yalnızca temel görünürlük sundu.

Bu platformların MySQL'i nasıl izlediğini ve test ortamımız ile metodolojimizi de görebilirsiniz.

1. Kurulum ve başlangıç deneyimi

1. SolarWinds

SolarWinds MongoDB entegrasyonunu 5 dakikanın altında tamamladı. Solarwinds basit bir pencereyle açılıyor: “Neyi izlemek istiyorsunuz?” Veritabanı performansını seçtiğinizde platform, desteklenen veritabanlarını en başta gösteriyor.

MongoDB seçtikten sonra Solarwinds mevcut ajanları kontrol ediyor.

Platform, daha önce kurduğumuz ajanı hemen algıladı.

Bir özellik dikkat çekti: arayüz, ajan ayrıntılarını (işletim sistemi, bulut örnek kimliği, sürüm) doğrudan seçim ekranında gösteriyor. Açılır menülerde arama 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ünen ad, sunucu bilgilerimizle otomatik dolduruldu; ancak daha önce belirttiğimiz ajan adı yerine tam dahili ana bilgisayar adını kullandı.

Bir tuhaflık: “Query Capture” açılır menüsü açıklama olmadan göründü. “Log” seçtik ve diğer seçeneklerin ne işe yaradığından emin olmadan ilerledik.

Sonraki ekran çalıştırılacak üç veritabanı komutu gösterdi. Her komutta bir kopyalama düğmesi vardı. Bunları MongoDB içinde çalıştırdık ve “Veritabanını Gözlemle” düğmesine tıkladık.

SolarWinds Observability

Solarwinds'in bizi etkilediği nokta burasıydı. İzinleri kendi başımıza çözmemizi istemek yerine kopyala-yapıştır komutları sağladı:

1. Belirli kimlik bilgilerine sahip bir izleme kullanıcısı oluşturun
2. Gerekli ayrıcalıkları verin (clusterMonitor ve readAnyDatabase rolleri)
3. Profil oluşturma düzeyini ayarlayın

Yapılandırmamızı gösteren bir özet ekran göründü. Eklenti durumu “Eklenti dağıtılıyor” gösterdi.

Saniyeler sonra durum “Eklenti dağıtımı başarılı” olarak değişti ve panoyu görüntülemek için bir bağlantı belirdi. Kurulum tamamlandı.

2. New Relic

New Relic kurulumu yaklaşık 15 dakika sürdü, ancak asıl sorun süre değildi. Sürtünme, platformun zaten bilmesi gereken soruları yanıtlamaktan kaynaklandı.

New Relic, Entegrasyonlar ve Ajanlar sayfasında başlıyor.

“mongo” için arama yaptık ve birden fazla MongoDB ile ilgili entegrasyon bulduk.

MongoDB seçtikten sonra New Relic bizden bir enstrümantasyon yöntemi seçmemizi istedi.

Ajanımız zaten kurulu olduğu için “Bir sunucuda” seçeneğini seçtik. Sonraki ekran işletim sistemini sordu. Linux seçtik. Ajan zaten sunucuda çalıştığından bu gereksiz hissettirdi, ancak devam ettik.

Sonraki ekran MongoDB sunucu ayrıntılarını istedi. “SCRAM” terimi açıklama olmadan göründü. Çoğu kişi bunu kullanıcı adı/parola kimlik doğrulaması olarak bilir, ancak teknik terim kafa karışıklığı yaratıyor.

New Relic

“Devam” düğmesine tıkladıktan sonra New Relic hangi sunucuya kurulacağını sordu. Bu soru, yapılandırma ayrıntılarını girdikten sonra değil, en başta sorulmalıydı. Ajan zaten “aimultiple-benchmark” üzerinde kuruluydu, bu yüzden onu seçip devam ettik.

Sonraki ekran MongoDB sürüm uyumluluğunu doğrulamamızı istedi. New Relic, mongod --version komutunu çalıştırmamızı ve çıktının gereksinimleriyle eşleştiğini onaylamamızı istedi. Komutu kopyalayıp terminalimize geçmemiz, çalıştırmamız, sürüm numarasını kontrol etmemiz ve geri dönüp devam düğmesine tıklamamız gerekti.

Ajan zaten sunucuda kurulu. Bunu otomatik olarak kontrol edebilirdi.

Devam düğmesine 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, uygun rol atamalarıyla (clusterMonitor ve readAnyDatabase) açıktı. Kullanıcının doğru çalıştığını doğrulamak için bir bağlantı testi komutu da çalıştırmamız gerekti.

Bu yaklaşım kök erişimi istemekten daha iyiydi, ancak bu komutları nerede çalıştıracağımızı kendimizin bulacağını varsayıyordu.

Sonraki ekran bizden entegrasyon paketini kurmamızı istedi. Şimdi New Relic yum kullanarak manuel kurulum yapmamızı istiyor. Ajan zaten Ubuntu üzerinde kurulu olmasına rağmen arayüz varsayılan olarak Amazon Linux'u seçiyor ve apt yerine yum kurulum komutları sağlıyor. Platformun, kurulu ajandan doğru işletim sistemini otomatik algılamasını beklerdik.

Ubuntu için doğru apt komutunu çalıştırdık, ardından sonraki ekrana geçtik. New Relic bir YAML yapılandırma dosyası sağladı ve tam olarak nereye koyacağımızı söyledi: /etc/newrelic-infra/integrations.d/. En azından dosya yolu netti.

Dosyayı oluşturduk, yapılandırmayı yapıştırdık ve Devam düğmesine tıkladık. Son ekranda bir “Bağlantıyı test et” düğmesi göründü. Tıkladık ve bekledik.

Test geçti. Kurulum tamamlandı.

New Relic

3. Datadog

Datadog tamamlanması 20 dakikadan fazla sürdü. Entegrasyon sonunda çalıştı, ancak oraya ulaşmak önemli ölçüde manuel çaba gerektirdi.

Oturum açtıktan sonra Entegrasyonlar sayfasına gittik ve “mongo” araması yaptık. MongoDB üzerine tıkladık ve bir pencere açıldı.

Genel bakış, MongoDB izlemenin neler içerdiğini gösterdi, ancak “Entegrasyonu Kur” düğmesine tıklamak yalnızca yoğun talimatlar içeren başka bir ekran açtı.

Datadog bizi burada bunalttı. Ekran, olası her MongoDB senaryosunu kapsayan eksiksiz bir başvuru kılavuzu gösterdi: bağımsız örnekler, replika setleri, parçalı kümeler, kimlik doğrulama yöntemleri, SSL yapılandırması ve daha fazlası.

Yalnızca tek bir MongoDB örneğini izlemeye çalışan biri için bu metin duvarı aşırı göründü.

Datadog

Temel adımları bulmak için kaydırdık:

1. MongoDB içinde bir izleme kullanıcısı oluşturun
2. Yapılandırma YAML dosyasını düzenleyin
3. Datadog ajanını yeniden başlatın

Datadog, kullanıcıyı oluşturmak için MongoDB komutlarını sağladı; bu yararlıydı. Ancak YAML dosyasına gelince dokümantasyon, bu dosyanın nereye gideceğini açıkça belirtmeden conf.yaml dosyasının düzenlenmesini söyledi.

Deneyimlerimizden, bunun /etc/datadog-agent/conf.d/mongo.d/ konumunda olması gerektiğini biliyorduk, ancak talimatlar bu ayrıntıyı dokümantasyonun derinliklerine gömmüştü.

MongoDB kullanıcısını oluşturduk, YAML yapılandırması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 Kur” düğmesine tıkladık.

Düğme kayboldu. Onay mesajı yok, başarı bildirimi yok, bir panoya yönlendirme yok. Hiçbir şey yok.

Bir süre bekledik, ardından Panolar bölümüne manuel olarak gittik ve MongoDB metriklerinin dolmaya başladığını gördük.

2. Ajan kaynak tüketimi

Çalışırken her ajanın ne kadar kaynak tükettiğini izledik. Test, üç ajanın da yük altındaki aynı MongoDB örneğinden eşzamanlı veri topladığı yaklaşık 10 dakika sürdü.

Rastgele veri üreten bir betik kullanarak MongoDB veritabanına 2 milyon kayıt ekleyerek sistemi zorladık. Bu, ajan kaynak kullanımını ölçerken gerçek dünya veritabanı etkinliğini simüle etti.

CPU tüketimi

Test sırasında üç ajan da minimum CPU kaynağı kullandı.

• New Relic en düşük ortalama CPU tüketimini gösterdi ancak %4 değerine ulaşan ara sıra ani yükselmeler yaşadı. Bu ani yükselmeler kısa sürdü ve sistem performansını etkilemedi.
• Solarwinds, önemli bir değişim olmadan %3 civarında kalarak en tutarlı CPU kullanımını sürdürdü.
• Datadog ortada kaldı; test boyunca sabit performansla ortalama %2 değerinin hemen üzerindeydi.

Bellek kullanımı

Bellek kullanımı ajanlar arasında daha belirgin farklar gösterdi.

New Relic, Solarwinds'ten yaklaşık 5-6x daha az bellek tüketti. 16GB test sunucumuzda bu şu anlama geliyordu:

• New Relic: ~90MB
• Datadog: ~330MB
• Solarwinds: ~500MB

Çoğu üretim sunucusu için bu miktarlar önemli olmayacaktır. Ancak ajanları kaynak kısıtlı sistemlerde çalıştırıyorsanız veya yüzlerce veritabanını izliyorsanız fark birikir.

Test boyunca üç ajanın tamamında bellek kullanımı sabit kaldı. Bellek sızıntısı veya beklenmedik büyüme olmadı.

Disk G/Ç

Disk etkinliği ajanlar arasında önemli ölçüde farklılık gösterdi.

SolarWinds, diğer iki ajandan önemli ölçüde daha fazla disk okuması gerçekleştirdi; New Relic'ten yaklaşık 40x, Datadog'dan ise 1.5x daha fazla. Bu, SolarWinds'in olası sorgu profili oluşturma özellikleri nedeniyle yerel olarak depolanan verilere daha sık eriştiğini düşündürüyor.

Datadog diske en az yazdı; bu, buluta göndermeden önce yerel olarak daha az veriyi tamponladığını gösteriyor.

New Relic, ılımlı okuma ve yazmalarla en dengeli G/Ç desenini gösterdi.

Ağ kullanımı

Ağ trafiği, her ajanın arka ucuna ne kadar veri gönderdiğini gösterdi.

Üç ajan da ağ üzerinden benzer miktarda veri gönderdi. Datadog biraz daha az veri iletti; bunun nedeni muhtemelen daha agresif sıkıştırma veya farklı örnekleme oranlarıydı.

Çift yönlü trafik mantıklıdır; ajanlar metrikler gönderir ve platformdan yapılandırma güncellemeleri veya komutlar alır.

Kaynak etkisi özeti

Bu ajanların hiçbiri sisteminizi zorlamaz. Üçü aynı anda çalışırken veritabanı yükü altında bile toplam kaynak tüketimi, %10 değerinin oldukça altında kaldı; bu değer CPU ve bellek toplamı içindi.

New Relic bellek verimliliğinde kazanıyor. Solarwinds daha fazla kaynak kullanıyor ancak daha ayrıntılı sorgu düzeyinde analiz sunuyor. Datadog ortada yer alıyor.

Çoğu kullanım senaryosu için bu kaynak farklılıkları kararınızı etkilemez. Kaynak tüketimine değil, özellikler ve kullanılabilirliğe göre seçim yapın.

3. Pano ve izleme yetenekleri

Kurulumu tamamladıktan sonra her platformun gerçekte ne gösterdiğini görmemiz gerekiyordu. Aynı iş yükünü üçünde de çalıştırdık: 5.000 kayıtlık gruplar halinde 2 milyon kayıt ekledik, ardından 5 milyon kayıt daha ekledik.

Betik, rastgele kullanıcı verileri (adlar, e-postalar, adresler ve telefon numaraları) üretmek için Faker ile Node.js kullandı. Bu bize izlemek için gerçekçi bir dataset sağladı.

Ekleme işlemleri çalışırken arka planda ajan kaynak tüketimini izledik.

İş yükü MongoDB üzerinde gerçek bir stres oluşturdu; bu da her platformun etkinliği nasıl yakalayıp görüntülediğini görmemizi sağladı.

Solarwinds panosu

SolarWinds Observability

SolarWinds MongoDB dashboard

Sol menüdeki “Veritabanları” bölümüne tıkladık ve MongoDB örneğimizi hemen gördük. Tek tıklama ve eksiksiz bir pano açıldı.

Ekranın üst kısmı MongoDB sağlığını, ortalama yanıt süresini, aktarım hızını (saniyedeki sorgu sayısı) ve hata sayısını gösterdi. “En İyi 10 Hizmet Dağılımı” balon grafiği, en sık kullanılan sorgu desenlerini sayıları ve yüzdeleriyle birlikte gösterdi.

Rakamlar bir hikaye anlattı. Verim, ortalama saniyede 3 sorgu gösterdi. Dağılım, 1.400 ekleme işlemi gösterdi. Neden 7 milyon yerine 1.400?

5.000 kayıtlık gruplar halinde 7 milyon kayıt ekledik. Bu, 1.400 grup işlemi demek. Solarwinds her bir grubu hiçbirini kaçırmadan izledi.

Profiler sekmesi, ortalama yürütme süreleriyle birlikte sorgu desenlerini gösterdi.

Ekleme sorgularımız her biri 4-5 saniye sürdü; her sorgunun 5.000 satır yazdığını hatırlayana kadar bu yüksek görünüyor.

Sağlık sekmesi her şeyin sorunsuz çalıştığını gösterdi.

Solarwinds'in 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.

SolarWinds Observability

Health tab

Sorgular sekmesi gelişmiş filtreleme sağladı. Şu sorguları listeleyebiliyordunuz:

• Hata döndüren
• Uygun dizinler olmadan çalışan
• Yavaş yanıt veren
• Uyarı üreten

Her sorgu deseni ilk ne zaman göründüğünü, en son ne zaman çalıştığını, kaç örnek yakalandığını ve yürütme istatistiklerini gösterdi. Sorun giderme için bu ayrıntı düzeyi önemlidir.

Uyarılar sekmesi MongoDB'ye özel uyarılar oluşturmamıza olanak tanıdı. Daha önce sunucu için bir bellek uyarısı oluşturmuştuk, ancak şimdi veritabanına özel bildirimler ayarlayabilirdik.

Kaynaklar sekmesi, MongoDB istatistiklerinin yanı sıra CPU, bellek, disk ve ağ gibi sunucu düzeyinde metrikler gösterdi. Bu bağlam, veritabanı sorunları ile altta yatan altyapı sorunları arasında ayrım yapmaya yardımcı olur.

Danışmanlar sekmesinde henüz öneri yoktu, ancak önceki testimizde MySQL için öneriler sağlamıştı. Daha fazla MongoDB verisi topladıkça optimizasyon önerileri sunmasını bekliyoruz.

AI Güncellemeleri: Ekim 2025'te SolarWinds, AI Query Assist özelliğine sahip AI Agent'ı başlattı (şu anda teknoloji önizlemesinde). AI Query Assist, veritabanı sorgu desenlerini analiz ediyor ve performansı otomatik olarak artırmak için optimize edilmiş yeniden yazımlar öneriyor. Root Cause Assist (artık genel kullanımda), sorun giderme süresini azaltmak için uyarılar ve anomalilere dayalı net kök neden analizleri üretiyor. SolarWinds portföyü genelinde daha geniş AI Agent kullanılabilirliği 2026 için planlanıyor¹².

New Relic panosu

New Relic

Dashboards page

Panolar bölümüne gittik, ancak MongoDB panosu otomatik olarak görünmedi.

Pano kataloğunda “mongo” araması yaptık ve iki MongoDB seçeneği bulduk.

Normal MongoDB panosunu seçtik ve “MongoDB Kurulumu” düğmesine tıkladık.

Bizi yeniden MongoDB entegrasyon kurulumuna yönlendirdi. Platform, MongoDB kurulumu yaptığımızı zaten biliyordu; öyleyse bizi neden kuruluma geri gönderdi? “Bitti” düğmesine tıklayıp panoya geçtik.

Pano tamamen boş açıldı. “mongodb.can_connect hizmet kontrolü için değer bildirilmedi.”

newrelic-infra agent configtest kullanarak yapılandırmamızı kontrol ettik.

New Relic

Yapılandırmamızdaki sorunları kontrol etmek için newrelic-infra agent configtest komutunu çalıştırdığımızda integration_name değerinin nri-prometheus olarak ayarlandığını fark ettik. Pano kurulumu sırasında New Relic iki MongoDB seçeneği gösterdi; bunlardan biri Prometheus sürümüydü. Arayüzde bunun farklı bir entegrasyon olduğunu gösteren hiçbir şey yoktu, bu yüzden Prometheus olanı seçtiğim aklıma asla gelmezdi. Bu bir kullanıcı hatası değildi; arayüzde hiçbir yönlendirme veya ayrım yoktu.

Geri döndük ve “MongoDB (Prometheus)” panosunu kurduk.

Bu kez veriler göründü.

Ancak sorun şu: normal bir kullanıcı bunu nasıl çözebilir? Kurulum süreci kafa karıştırıcıydı ve pano seçimi de başka bir karmaşıklık katmanı ekledi.

Pano düzeni tuhaftı. Üst kısım, yılda bir değişen toplam sunucu ve veritabanı bilgilerini gösteriyordu, ancak ekranın en değerli alanını kaplıyordu.

Bunun altında “Bağlantı Doygunluğu” belirgin şekilde görünüyordu. Bu metrik yalnızca bir sorun olduğunda önem taşır. Neden en üste konmuş?

“Sorgu İşlemleri” bölümü 11.670 ekleme bildirdi. Sayı yanlıştı. 1.400 grup işlemiyle 7 milyon kayıt ekledik. Grafik gerçeklikle eşleşmiyordu.

Veritabanları sekmesi veritabanı boyutunu, nesne sayılarını ve dizin boyutlarını gösterdi. Bu sayılar doğruydu: 7 milyon nesne. New Relic bu verileri doğrudan MongoDB'yi sorgulayarak alıyor (“Kaç dokümanınız var?”). Ancak gerçek zamanlı sorgu sayımı başarısız oldu.

Koleksiyonlar sekmesi, koleksiyon düzeyindeki metrikler için yararlı grafikler içeriyordu: boyut (hem tablo hem grafik görünümleriyle), yüzde değişimli toplam boyut, okuma işlem sayısı, okuma gecikmesi, yazma işlem sayısı, yazma gecikmesi, işlem sayıları, işlem gecikmesi, dizin erişim işlemleri, komut yürütme sayıları, komut gecikmesi, komut sıklığı ve komut süresi.

Belirgin şekilde eksik olanlar: sunucu metrikleri. MongoDB çalıştıran sunucunun CPU, bellek, disk veya ağ kullanımını göremiyorduk. SolarWinds bu bağlamı sunarken, Datadog New Relic gibi sunmadı.

Daha da önemlisi, hiçbir yerde sorgu düzeyinde analiz yoktu. Sorgu desenleri yok, profil oluşturma yok, yavaş sorgu tespiti yok, eksik dizin algılama yok. Veritabanı sorun giderme için bu özellikler önemlidir.

Datadog panosu

Datadog

Sol menüdeki “Panolar” bölümüne tıkladık. “MongoDB – Genel Bakış” panosu otomatik olarak göründü.

Açtık ama boştu.

Sorunu teşhis etmek zaman aldı. Kurulum sırasında Datadog otomatik keşif yapılandırması, bir desen eşleşmesi kullanarak hangi veritabanlarının izleneceğinin belirtilmesini gerektiriyordu. Varsayılan desen veritabanı adımızla eşleşmedi. Datadog kurulum sırasında bundan hiç bahsetmedi.

Tüm desenleri .* (her şeyi eşleştir) olarak değiştirdik ve ajanı yeniden başlattık.

Peki pano neden tamamen boştu? Veritabanına özel metrikler olmadan bile çalışma süresi, bağlantı sayıları ve sunucu istatistikleri görünmeliydi. Görünmediler.

Hata ayıklamak için datadog-agent check mongo komutunu çalıştırdık. Yapılandırma dosyasında girinti hatası vardı. YAML'ın katı biçimlendirme gereksinimi bizi yakaladı. Düzeltip 5 milyon ekleme içeren yük testimizi yeniden çalıştırdıktan sonra veriler nihayet göründü.

Datadog

Panoyla hemen sorun yaşadık. Günlükler bölümü, YAML dosyamızda günlük toplama yapılandırmış olmamıza rağmen “Erişilemez” gösterdi. Datadog kurulum süreci her şeyin yolunda olduğunu bildirdi, ancak günlükler hâlâ çalışmıyordu.

Pano düzeni bizim kullanım durumumuz için pek anlamlı değildi. Üst bölüm parçalama (sharding) istatistiklerine odaklanıyordu. Parçalı bir küme çalıştırmıyorduk. Orta bölüm replika seti metriklerini gösteriyordu. Replika setlerimiz yoktu. Alt bölüm yine parçalamaya dönüyordu. Panonun yaklaşık %60 kadarı, kullanmadığımız özellikler için boş bölümler gösteriyordu.

Yararlı bilgiler ekranın belki %40 kısmı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, dizin önerileri yok.

Bu panodan kaç işlem çalıştığını bile belirleyemedik.

MongoDB izleme kıyaslama test ortamı ve metodolojisi

Adil bir karşılaştırma sağlamak için üç aracı da aynı kurulumlarda çalıştırdık. Her test şunları kullandı:

• Veritabanı: MongoDB 7.0 Community Edition
• Sunucu: AWS m6i.xlarge örneği
• Başlangıç noktası: Ana izleme ajanı zaten kurulmuş temiz kurulum

Üç satıcı da belirli entegrasyonları eklemeden önce kendi temel ajanlarını kurmanızı gerektiriyor; örneğin MongoDB. Bu adımı önceden tamamladık, bu nedenle testimiz yalnızca MongoDB entegrasyon deneyimine odaklandı.

Ölçtüğümüz kriterler:

• Kurulum karmaşıklığı: Manuel adım sayısı, otomatik ve manuel yapılandırma karşılaştırması, talimat netliği ve arayüzün bizi yönlendirip yönlendirmediği veya sonraki adımları aramaya bırakıp bırakmadığı.
• Ajan kaynak tüketimi: Boşta ve yük altında (7 milyon kayıt eklerken) CPU, bellek, disk G/Ç ve ağ kullanımı.
• İzleme yetenekleri: Pano kalitesi, metrik doğruluğu, sorgu düzeyinde analiz ve sorun giderme özellikleri.

Güvenlik hususları

“MongoBleed” adlı ciddi bir güvenlik açığı açıklandı; bu açık, MongoDB Server'ın 8.0.17, 7.0.28, 6.0.27 ve daha eski sürümlerini etkiliyor. Bu kimliği doğrulanmamış sınır dışı okuma açığı, saldırganların hassas bellek verilerine erişmesine olanak tanıyabilir. MongoDB çalıştıran kuruluşlar derhal yamalı sürümlere güncelleme yapmalıdır: 8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32 veya 4.4.30³⁴. İzleme araçlarını seçerken güvenli kimlik doğrulama yöntemlerini desteklediklerinden ve ek güvenlik riskleri getirmediklerinden emin olun.

Her araca normal bir kullanıcının yaklaşacağı gibi yaklaştık; önceden dokümantasyon okumadan ve ön eğitim almadan. Arayüzde açık olmayan bir şey varsa not ettik.

Kıyaslamalarımızı ve veri odaklı içgörülerimizi kaçırmayın. Düğme Google'ı açar; AIMultiple'ı seçmeniz, Google arama sonuçlarında AIMultiple'ı daha sık görmek istediğinizi onaylar.

Tercih edilen kaynak olarak ekle

MongoDB izleme kıyaslaması nihai kararı

Basit bir soruyu yanıtlamak için yola çıktık: Hangi izleme platformu, teknik olmayan ekipler için MongoDB entegrasyonunu en kolay hale getirir?

Üçünü de kurduktan, aynı iş yüklerini çalıştırdıktan ve panoları değerlendirdikten sonra yanıt netleşti. Değerlendirmemiz, Ocak 2025 itibarıyla Datadog temel MongoDB entegrasyonuna dayanıyor. Datadog o zamandan beri MongoDB için Database Monitoring (DBM) ürününü yayımladı (Aralık 2024); bu ürün sorgu profili oluşturma, yavaş işlem analizi, explain planları ve replikasyon izleme dahil önemli ölçüde daha derin yetenekler sunuyor. DBM ürünü, bu kıyaslamada belirlenen sınırlamaların birçoğunu gideriyor⁵.

SolarWinds: Veritabanı izleme için üretilmiş

SolarWinds bu karşılaştırmayı açık ara kazandı. Platform ajanımızı hemen algıladı, kopyala-yapıştır komutlarıyla kimlik bilgisi kurulumunda bize rehberlik etti ve entegrasyonu otomatik olarak dağıttı. Kurulum 5 dakika sürdü.

Pano, ilgili bilgilerle anında göründü. Sorgu profili oluşturma, hangi işlemlerin en fazla kaynağı tükettiğini tam olarak gösterdi. Platform, 1.400 grup işleminin tamamını hiçbirini kaçırmadan yakaladı. MongoDB'yi durdurduğumuzda SolarWinds hatayı 40 saniye içinde algıladı.

Sorgular sekmesi hatalara, eksik dizinlere, yavaş yanıtlara ve uyarılara göre filtreleme yapmamızı sağladı; bu özellikler veritabanı optimizasyonunu doğrudan destekliyor. Danışmanlar özelliğinin öneriler sunması bekleniyordu (ancak testimiz sırasında herhangi birini tetikleyecek kadar veri üretmedik).

Solarwinds, veritabanı yöneticilerinin gerçekten ihtiyaç duyduğu şeylere odaklandı: sorgu analizi, performans profili oluşturma ve uygulanabilir içgörüler.

New Relic: Yapılandırmada kayboldu

New Relic kurulumu 15 dakika sürdü, ancak asıl sorun süre değildi. Platform soruları yanlış sırada sordu, ajanın otomatik olarak kontrol edebileceği şeylerin manuel doğrulamasını gerektirdi ve bizi paketleri manuel olarak kurmaya zorladı.

Pano karışıklığı işleri daha da kötüleştirdi. MongoDB izlemeyi kurduk, ancak varsayılan panoyu seçmek boş bir ekranla sonuçlandı. Ancak yapılandırma dosyalarını inceledikten sonra yanlış entegrasyon türünü seçtiğimizi fark ettik. Normal bir kullanıcı bunu çözemezdi.

Veriler nihayet göründüğünde metrikler yanlıştı. New Relic, toplamda 7 milyon kayıt olan 1.400 grup işlemi gerçekleştirdikten sonra 11.670 ekleme bildirdi. Platform, bir büyüklük mertebesi kadar eksik saydı.

Daha da kritik olarak New Relic sorgu düzeyinde analiz sağlamadı. Profil oluşturma yok, yavaş sorgu tespiti yok, eksik dizin tespiti yok. Veritabanı sorun giderme için bu eksiklikler önemlidir.

Datadog: Manuel çalışma gerekli

Datadog, 20 dakikadan fazla kurulum ve en fazla manuel yapılandırma gerektirdi. YAML dosyalarını düzenledik, nereye yerleştireceğimizi belirledik ve hizmetleri komut satırından yeniden başlattık.

Pano otomatik olarak göründü ancak hiçbir şey göstermedi. Otomatik keşif yapılandırması, veritabanımızla eşleşmeyen bir desen kullandı. Deseni düzeltip YAML girinti hatalarını giderdikten sonra veriler nihayet doldu.

Panonun kendisi, tek örnekli MongoDB için kötü tasarlandığını kanıtladı. Ekranın yüzde altmışı boştu; parçalama ve replika setleri gibi kullanmadığımız özellikler için bölümler vardı. Kalan %40 temel metrikler sunuyordu: çalışma süresi, bellek, ağ G/Ç, saniyedeki sorgu sayısı ve gecikme.

Sorgu analizi yok. Profil oluşturma yok. Optimizasyon önerileri yok. Panodan işlem sayılarını doğru şekilde belirleyemedik.

Sorgu analizi yok. Profil oluşturma yok. Optimizasyon önerileri yok. Panodan işlem sayılarını doğru şekilde belirleyemedik.

Kritik Güncelleme (Aralık 2024): Bu kıyaslama tamamlandıktan sonra Datadog, MongoDB için Database Monitoring (DBM) ürününü başlattı; bu, bu değerlendirmeyi önemli ölçüdeğiştiriyor. MongoDB için DBM artık şunları sağlıyor:

• Ayrıntılı sorgu örnekleriyle yavaş işlem analizi
• Sorgu optimizasyonu için explain planları
• Replikasyon durumu izleme ve küme sağlığı görselleştirme
• İşlem düzeyinde içgörüler ve performans darboğazı tespiti
• Birleşik sorun giderme için uygulama performans izleme ile entegrasyon

DBM, bu kıyaslamada test edilen temel MongoDB entegrasyonuna göre önemli bir yükseltmeyi temsil ediyor ve testlerimiz sırasında bulunmayan sorgu düzeyinde analiz özelliklerinin birçoğunu içeriyor⁵⁶. MongoDB izleme için Datadog değerlendiren kuruluşlar, burada test edilen temel entegrasyon yerine özellikle Database Monitoring ürününü değerlendirmelidir.

DevOps uzmanı olmadığınızda hangi DB izleme aracı gerçekten işe yarar?

Kurulum deneyimi

SolarWinds neyi izlemek istediğinizi soran bir pencereyle açıldı. “Veritabanı performansı”nı seçiyorsunuz, MongoDB seçiyorsunuz ve platform zaten kurduğunuz ajanı hemen buluyor; seçim ekranında işletim sistemini, bulut örnek kimliğini ve sürüm numarasını gösteriyor. Ardından MongoDB içinde çalıştırmanız için üç kopyala-yapıştır komutu veriyor, kimlik bilgilerini yönetiyor ve dağıtımı onaylıyor. Baştan sona beş dakika.

New Relic on beş dakika sürdü ve asıl sorun süre bile değildi. Arayüz, ajan zaten sunucuda olmasına rağmen hangi işletim sistemi ve hangi MongoDB sürümü gibi ajanın kendi kendine yanıtlayabileceği soruları sormaya devam etti. Bir noktada, açıkça Ubuntu çalıştırmamıza rağmen varsayılan olarak Amazon Linux kurulum komutlarını seçti. Deneyimi nihayet bozan adım: pano kataloğunda biri standart, biri Prometheus tabanlı iki MongoDB entegrasyon seçeneği vardı ve arayüzde bunları ayırt eden hiçbir şey yoktu. Yanlış olanı seçtik, boş bir pano aldık ve yalnızca yapılandırma dosyalarını inceleyerek çözebildik.

Datadog yirmi dakikadan fazla YAML düzenleme, dosya yollarını tahmin etme ve hizmetleri komut satırından yeniden başlatma gerektirdi. Kurulum sırasında sunulan dokümantasyon bir rehber değil; yalnızca bir veritabanını izlemek isteyen biri için tek seferde bağımsız örnekleri, replika setlerini, parçalı kümeleri ve SSL yapılandırmasını kapsayan eksiksiz bir başvuru kılavuzu. Veriler nihayet göründüğünde pano parçalama istatistikleri ve replika seti metrikleriyle başlıyordu. İkisi de bizde yoktu. Ekranın yaklaşık yüzde altmışı boştu.

Yük altında metrik doğruluğu

SolarWinds 1.400 saydı. Tam olarak doğru. New Relic 11.670 bildirdi; açık bir açıklama olmaksızın bir büyüklük mertebesi yanlıştı ve test sırasında bir bellek ani yükselmesini tamamen kaçırdı. MongoDB hizmetini durdurduğumuzda SolarWinds hatayı otuz ila kırk saniye içinde algıladı.

Kaynak tüketimine gelince: New Relic yaklaşık 90MB RAM kullandı; Datadog yaklaşık 330MB ve SolarWinds yaklaşık 500MB kullandı; bu, 16GB sunucumuzdaydı. SolarWinds, muhtemelen yerel sorgu profili oluşturma çalışması nedeniyle New Relic'ten yaklaşık kırk kat daha fazla disk okuması gerçekleştirdi. Çoğu ortam için bunların hiçbiri kararınızı yönlendirmeyecektir.

Onları gerçekten ayıran özellik

Her izleme aracı size bir şeyin yavaş olduğunu söyler. Soru, size nedenini söyleyip söylemediğidir.

SolarWinds sorgu düzeyinde profil oluşturma sunar. Profiler sekmesi tam olarak hangi sorgu desenlerinin yürütüldüğünü, her birinin ne kadar sürdüğünü ve kaç örnek yakalandığını gösterdi. Dizin olmadan çalışan, hata döndüren veya uyarı üreten sorgulara göre filtreleme yapabilirsiniz.

New Relic ve Datadog yalnızca gecikme, bağlantı sayıları ve işlem toplamları için toplu metrikler gösterdi. Profil oluşturma yok, yavaş sorgu tespiti yok, eksik dizin algılama yok. Bir veritabanının çalıştığını doğrulamak için kullanılabilir. 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, explain planları ve sorgu düzeyinde görünürlük ekleyen bir Database Monitoring ürünü yayımladı. Biz standart entegrasyonu test ettik; çoğu kullanıcının ilk karşılaştığı şey bu olmaya devam ediyor.

SolarWinds: Asıl endişeniz veritabanı optimizasyonuysa. Doğru metrikler, hızlı kurulum ve burada yalnızca bir sorgunun yavaş olduğunu değil, bu konuda ne yapmanız gerektiğini söyleyen tek platform.

New Relic: APM için zaten kullanıyorsanız ve aynı yerde temel veritabanı sağlığına ihtiyacınız varsa. Tarayıcıdan koda ve veritabanı çağrısına kadar yavaş bir isteği izlemek gerçekten yararlıdır. Kesin işlem sayıları için ona güvenmeyin.

Datadog: Manuel yapılandırma konusunda rahatsanız ve karmaşık bir yığında tek bir platform istiyorsanız. 600 artı entegrasyon, doğru ekip için kurulum sürtünmesini haklı çıkarır.

Bu benchmarkı kaynak gösterin

Yayınlayacağınız yere uygun formatı seçin. Bağlantılı sürümü CMS'inize yapıştırmak, geri bağlantıyı korur.

@misc{dogan2026,
  author = {Dogan, Sedat and Ermut, Sıla},
  title  = {{MongoDB İzleme: SolarWinds vs New Relic vs Datadog}},
  year   = {2026},
  month  = sep,
  howpublished    = {\url{https://aimultiple.com/mongodb-monitoring}},
  note   = {AIMultiple. Erişim tarihi: 16 Eylül 2026}
}

Değişiklik günlüğü

5 güncelleme

Tümü5Genel3Metodoloji2

20262025

1. 16 Mar

   “Temel Fark” bölümü, “DevOps Uzmanı Değilseniz Hangi VT İzleme Aracı Gerçekten Çalışır?” ile değiştirildi.

2. 6 Şub

   SolarWinds bölümüne Yapay Zeka Güncellemeleri eklendi.

3. 6 Şub

   Metodolojiye Güvenlik Hususları eklendi.

Referans Linkleri

1.

SolarWinds Launches AI Agent and Expands AI Capabilities to Advance Autonomous Operational Resilience | SolarWinds

2.

SolarWinds Launches AI Agent and Expanded AI Capabilities - SolarWinds Blog

3.

MongoDB Server | endoflife.date

4.

Database Manual - MongoDB Docs

5.

Track and troubleshoot MongoDB performance with Datadog Database Monitoring | Datadog

Datadog

6.

Setting Up Database Monitoring for MongoDB Atlas

Sedat Dogan

CTO

Takip Et

Sedat, yazılım geliştirme, ağ altyapısı ve siber güvenlik alanlarında 20 yıllık deneyime sahip bir teknoloji ve bilgi güvenliği lideridir. Sedat:
- Programlama dilleri ve sunucu mimarileri konusunda kapsamlı uzmanlığa sahip, 20 yıllık deneyime sahip bir beyaz şapkalı hacker ve geliştirme gurusudur.
- Erken aşama teknoloji şirketlerine yatırım yapan bir VC'de ve 125.000 işletmeye hizmet veren bölgesel bir dijital ödeme platformu olan Ödeal'da yönetim kurulu danışmanıdır.
- Yedi ulusal seçimin teknoloji altyapısını ve siber güvenliğini yönetmiş ve Twitter dahil küresel teknoloji liderleri tarafından siber güvenlik Onur Listesi'nde tanınmıştır.

Tam Profili Görüntüle

Araştıran

Sıla Ermut

Sektör Analisti

Takip Et

Sıla Ermut, AIMultiple'da yapay zeka model'lerini, yapay zeka altyapısını, yapay zeka yönetişimini ve kurumsal yapay zeka uygulamalarını ele alan bir sektör analistidir. Araştırmaları çoğunlukla yapay zekanın pazarlama, sağlık hizmetleri, tedarik zincirleri ve sürdürülebilirlik alanlarındaki kullanımına odaklanmaktadır.
Daha önce proje yönetimi ve danışmanlık firmalarında işe alım uzmanı olarak çalıştı. Sıla, Sosyal Psikoloji alanında yüksek lisans derecesine ve Uluslararası İlişkiler alanında lisans derecesine sahiptir.

Tam Profili Görüntüle

Yorum yapan ilk kişi olun

E-posta adresiniz yayınlanmayacak. Tüm alanlar gereklidir. Yorumlar orijinal dilinde bırakılır.

Ad

E-posta Adresi

Yorum

0/450

Yorumu Gönder