MongoDB İzleme: SolarWinds vs New Relic vs Datadog

Test etmek için MongoDB 7.0 çalıştıran temiz sistemlere SolarWinds, Datadog ve New Relic kurduk. Her aracın eksiksiz kurulum sürecini gerçekleştirdik, her adımı ve engeli belgeledik.

MongoDB Performans İzleme Araçları Benchmark Sonuçları

MongoDB izleme performans özeti

• SolarWinds, otomatik algılama ile kurulumu 5 dakikada tamamladı ve diğerlerinde eksik olan sorgu düzeyinde profilleme sağladı.
• New Relic, manuel doğrulama adımlarıyla 15 dakika sürdü ve hatalı metrikler raporladı.
• Datadog, 20 dakikadan fazla 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 da görebilirsiniz

1. Kurulum ve Alıştırma Deneyimi

1. Solarwinds

SolarWinds, MongoDB entegrasyonunu 5 dakikanın altında tamamladı. Solarwinds basit bir modal ile açılır: “Neyi izlemek istiyorsunuz?” veritabanı performansını seçtiğinizde, platform desteklenen veritabanlarını hemen görüntüler.

MongoDB seçildikten sonra, Solarwinds mevcut agent'ları kontrol eder.

Platform, daha önce kurduğumuz agent'ı anında tespit etti.

Bir özellik öne çıktı: arayüz, agent detaylarını (işletim sistemi, bulut örneği ID'si, sürüm) doğrudan seçim ekranında görüntülüyor. Açılır menülerde arama yapmaya gerek kalmıyor.

Şimdi SolarWinds, MongoDB kimlik bilgilerini istiyor. Bağlantı detaylarını girdik: localhost, kimlik doğrulama yöntemi (şifre tabanlı), kullanıcı adı ve şifre. Görüntüleme adı, daha önce belirttiğimiz agent adı yerine tam dahili ana bilgisayar adını kullansa da sunucu bilgilerimizle auto-dolduruldu.

Bir tuhaflık: “Sorgu Yakalama” (Query Capture) açılır menüsü herhangi bir açıklama olmadan belirdi. Diğer seçeneklerin ne işe yaradığından emin olmadan “Log”u seçtik ve ilerledik.

Bir sonraki ekran, çalıştırılacak üç veritabanı komutu sundu. Her komutun bir kopyalama düğmesi vardı. Bunları MongoDB'de çalıştırdık ve “Veritabanını Gözlemle”ye tıkladık.

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

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

Yapılandırmamızı gösteren bir özet ekranı belirdi. Eklenti durumu “Eklenti dağıtılıyor” şeklinde görünüyordu.

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

2. New Relic

New Relic'in kurulumu yaklaşık 15 dakika sürdü, ancak asıl sorun süre değildi. Sürtünme, platformun zaten biliyor olması gereken soruları yanıtlamaktan kaynaklanıyordu.

New Relic, Entegrasyonlar ve Agent'lar sayfasında başlar.

“mongo” diye arattık ve MongoDB ile ilgili birden fazla entegrasyon bulduk.

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

Agent'ımız zaten kurulu olduğu için “Bir ana bilgisayarda” (On a host) seçeneğini seçtik. Bir sonraki ekran işletim sistemini sordu. Linux'u seçtik. Agent zaten sunucuda çalıştığı için bu gereksiz geldi ancak devam ettik.

Bir sonraki ekran MongoDB ana bilgisayar detaylarını sordu. “SCRAM” terimi herhangi bir açıklama olmadan belirdi. Çoğu insan bunu kullanıcı adı/şifre kimlik doğrulaması olarak bilir, ancak teknik terim kafa karışıklığına yol açıyor.

Devam et'e tıkladıktan sonra, New Relic kurulumun hangi sunucuya yapılacağını sordu. Bu soru, yapılandırma detaylarını girdikten sonra değil, en başta gelmeliydi. Agent zaten “aimultiple-benchmark” üzerinde kurulu olduğu için onu seçtik ve devam ettik.

Bir sonraki ekran bizden 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 kopyalamak, terminale geçmek, çalıştırmak, sürüm numarasını kontrol etmek ve devam etmek için geri dönmek zorunda kaldık.

Agent zaten sunucuda kurulu. Bunu otomatik olarak kontrol edebilirdi.

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, uygun rol atamalarıyla (clusterMonitor ve readAnyDatabase) netti. Ayrıca kullanıcının doğru çalışıp çalışmadığı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ı bizim bulacağımızı varsayıyordu.

Bir sonraki ekran bizden entegrasyon paketini kurmamızı istedi. Şimdi New Relic, yum kullanarak manuel kurulum yapmamızı istiyor. Agent Ubuntu'ya 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 agent'tan doğru işletim sistemini otomatik olarak algılamasını beklerdik.

Ubuntu için doğru apt komutunu çalıştırdık ve ardından bir sonraki ekrana geçtik. New Relic bir YAML yapılandırma dosyası sağladı ve onu 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 Et'e tıkladık. Son ekran bir “Bağlantıyı test et” düğmesi gösterdi. Tıkladık ve bekledik.

Test başarılı oldu. Kurulum tamamlandı.

3. Datadog

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

Giriş yaptıktan sonra Entegrasyonlar'a gittik ve “mongo” diye arattık. MongoDB'ye tıkladık ve bir modal belirdi.

Genel bakış, MongoDB izlemenin neleri içerdiğini gösteriyordu, ancak “Entegrasyonu Kur”a tıklamak sadece yoğun talimatlar içeren başka bir ekran açtı.

Datadog'un bizi bunalttığı nokta burasıydı. Ekran, mümkün olan her MongoDB senaryosunu kapsayan eksiksiz bir referans kılavuzu gösteriyordu: tekil örnekler, replika setleri, parçalı kümeler, kimlik doğrulama yöntemleri, SSL yapılandırması ve daha fazlası.

Sadece tek bir MongoDB örneğini izlemeye çalışan biri için bu metin duvarı aşırı geldi.

Temel adımları arayarak aşağı kaydırdık:

1. MongoDB'de bir izleme kullanıcısı oluşturun
2. Yapılandırma YAML dosyasını düzenleyin
3. Datadog agent'ını yeniden başlatın

Datadog, kullanıcıyı oluşturmak için MongoDB komutlarını sağladı, bu yardımcı oldu. Ancak YAML dosyasına gelince, dokümantasyon bu dosyanın nereye gitmesi gerektiğini açıkça belirtmeden conf.yaml dosyasını düzenlememizi söyledi.

Deneyimlerimizden bunun /etc/datadog-agent/conf.d/mongo.d/ içinde olması gerektiğini biliyorduk, ancak talimatlar bu detayı 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 agent'ı yeniden başlattık.

Ardından Datadog arayüzüne geri döndük ve “Entegrasyonu Kur”a tıkladık.

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

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

2. Agent Kaynak Tüketimi

Her agent'ın çalışırken ne kadar kaynak tükettiğini izledik. Test, üç agent'ın da aynı MongoDB örneğinden aynı anda veri topladığı yük altında yaklaşık 10 dakika sürdü.

Rastgele veri üreten bir betik kullanarak MongoDB'ye 2 milyon kayıt ekleyerek sistemi zorladık. Bu, biz agent kaynak kullanımını ölçerken gerçek dünya veritabanı aktivitesini simüle etti.

CPU Tüketimi

Üç agent da test sırasında minimum CPU kaynağı kullandı.

• New Relic en düşük ortalama CPU tüketimini gösterdi ancak ara sıra %4'e ulaşan sıçramalar yaşadı. Bu sıçramalar kısa süreliydi ve sistem performansını etkilemedi.
• Solarwinds, belirgin bir varyasyon olmadan %3 civarında kalarak en tutarlı CPU kullanımını sürdürdü.
• Datadog, test boyunca stabil performansla ortalama %2'nin biraz üzerinde kalarak ortada yer aldı.

Bellek Kullanımı

Bellek kullanımı, agent'lar arasında daha belirgin farklar gösterdi.

New Relic, Solarwinds'ten yaklaşık 5-6 kat daha az bellek tüketti. 16GB'lık 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 kaynakları kısıtlı sistemlerde agent çalıştırıyorsanız veya yüzlerce veritabanını izliyorsanız, fark birikir.

Bellek kullanımı, test boyunca her üç agent'ta da stabil kaldı. Bellek sızıntısı veya beklenmedik bir büyüme meydana gelmedi.

Disk I/O

Disk aktivitesi agent'lar arasında önemli ölçüde farklılık gösterdi.

SolarWinds, diğer iki agent'tan önemli ölçüde daha fazla disk okuması gerçekleştirdi; New Relic'ten yaklaşık 40 kat, Datadog'dan ise 1.5 kat daha fazla. Bu, SolarWinds'in, muhtemelen sorgu profilleme özellikleri için yerel olarak saklanan verilere daha sık eriştiğini göstermektedir.

Datadog diske en az yazan oldu, bu da verileri buluta göndermeden önce yerel olarak daha az tamponladığını gösteriyor.

New Relic, orta düzeyde okuma ve yazma ile en dengeli I/O modelini sergiledi.

Ağ Kullanımı

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

Üç agent da ağ üzerinden benzer miktarlarda veri gönderdi. Datadog, muhtemelen daha agresif sıkıştırma veya farklı örnekleme oranları nedeniyle biraz daha az veri iletti.

Çift yönlü trafik mantıklı, çünkü agent'lar metrikleri gönderir ve platformdan yapılandırma güncellemeleri veya komutlar alır.

Kaynak Etkisi Özeti

Bu agent'ların hiçbiri sisteminizi zorlamayacaktır. Üçü aynı anda çalışırken veritabanı yükü altında bile, toplam kaynak tüketimi CPU ve bellek toplamında %10'un çok altında kaldı.

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

Çoğu kullanım durumu için bu kaynak farkları kararınızı etkilemeyecektir. Kaynak tüketimine göre değil, özelliklere ve kullanılabilirliğe göre seçim yapın.

Google Arama'da daha fazla kıyaslamamızı ve veri odaklı içgörülerimizi görün.

Tercih edilen kaynak olarak ekle

3. Pano ve İzleme Yetenekleri

Kurulumu tamamladıktan sonra, her platformun gerçekte ne gösterdiğini görmemiz gerekiyordu. Üçünde de aynı iş yükünü çalıştırdık: 5.000'lik paketler halinde 2 milyon kayıt, ardından başka 5 milyon kayıt ekledik.

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

Ekleme işlemleri sürerken, arka planda agent kaynak tüketimini izledik.

İş yükü MongoDB'ye gerçek bir stres uyguladı, bu da her platformun aktiviteyi nasıl yakaladığını ve görüntülediğini görmemizi sağladı.

Solarwinds Panosu

Sol menüdeki “Veritabanları”na tıkladık ve anında MongoDB örneğimizi gördük. Tek bir tıklama ile eksiksiz bir pano belirdi.

Ekranın üst kısmı MongoDB sağlığını, ortalama yanıt süresini, işlem hacmini (saniye başına sorgu) ve hata sayısını gösteriyordu. “En İyi 10 Hizmet Dağılımı” balon grafiği, en sık kullanılan sorgu desenlerini sayıları ve yüzdeleriyle birlikte görüntüledi.

Sayılar bir hikaye anlatıyordu. İşlem hacmi ortalama saniyede 3 sorgu gösterdi. Dağılım 1.400 ekleme işlemi gösterdi. Neden 7 milyon yerine 1.400?

7 milyon kaydı 5.000'lik paketler halinde ekledik. Bu, 1.400 paket işlemi demektir. Solarwinds, tek bir tanesini bile kaçırmadan her bir paketi takip etti.

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

Ekleme sorgularımızın her biri 4-5 saniye sürdü, ki her sorgunun 5.000 satır yazdığını hatırladığınızda bu yüksek görünmez.

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

Solarwinds'in ne kadar hızlı fark edeceğini görmek için MongoDB servisini durdurduk. 30-40 saniye içinde sağlık durumu “Kötü” olarak değişti.

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

• Hata döndürenler
• Uygun indeksler olmadan çalışanlar
• Yavaş yanıt verenler
• Uyarılar oluşturanlar

Her sorgu deseni, ilk ne zaman göründüğünü, en son ne zaman çalıştığını, kaç örneğin yakalandığını ve yürütme istatistiklerini gösteriyordu. Sorun giderme için bu düzeydeki detaylar önemlidir.

Uyarılar sekmesi, MongoDB'ye özel uyarılar oluşturmamıza izin verdi. Daha önce ana bilgisayar için bir bellek uyarısı oluşturmuştuk, ancak şimdi veritabanına özel bildirimler ayarlayabiliyorduk.

Kaynaklar sekmesi, MongoDB istatistiklerinin yanı sıra ana bilgisayar düzeyindeki metrikleri, CPU, bellek, disk ve ağı gösterdi. Bu bağlam, veritabanı sorunları ile temel altyapı sorunlarını ayırt etmeye yardımcı olur.

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

Yapay Zeka Güncellemeleri: Ekim 2025'te SolarWinds, AI Query Assist özelliğine sahip AI Agent'ı başlattı (şu an teknik önizlemede). AI Query Assist, veritabanı sorgu desenlerini analiz eder ve performansı otomatik olarak artırmak için optimize edilmiş yeniden yazımlar önerir. Root Cause Assist (artık genel kullanıma açık), sorun giderme süresini azaltmak için uyarılar ve anomalilere dayalı net kök neden analizleri oluşturur. SolarWinds portföyü genelinde daha geniş AI Agent kullanılabilirliği 2026 için planlanmaktadır^{1 2} .

New Relic Panosu

Panolar bölümüne gittik ancak hiçbir MongoDB panosu otomatik olarak belirmedi.

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

Normal MongoDB panosunu seçtik ve “MongoDB Kur”a tıkladık.

Bizi tekrar MongoDB entegrasyon kurulumuna yönlendirdi. Platform zaten MongoDB kurduğumuzu biliyordu, peki neden bizi kuruluma geri gönderdi? “Tamam”a tıkladık ve panoya geçtik.

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

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

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

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

Bu sefer veriler belirdi.

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

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

Onun altında, “Bağlantı Doygunluğu” (Connection Saturation) belirgin bir şekilde görünüyordu. Bu metrik yalnızca bir şeyler yanlış gittiğinde önemlidir. Neden en üste konuldu?

“Sorgu İşlemleri” bölümü 11.670 ekleme raporladı. Sayı yanlıştı. 1.400 paket işleminde 7 milyon kayıt eklemiştik. Grafik gerçekle uyuşmuyordu.

Veritabanları sekmesi veritabanı boyutunu, nesne sayılarını ve indeks boyutlarını gösterdi. Bu sayılar doğruydu: 7 milyon nesne. New Relic bu verileri doğrudan MongoDB'ye sorgu göndererek alır (“Kaç belgeniz 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şimiyle toplam boyut, okuma işlemleri sayısı, okuma gecikmesi, yazma işlemleri sayısı, yazma gecikmesi, işlem sayıları, işlem gecikmesi, indeks erişim işlemleri, komut yürütme sayıları, komut gecikmesi, komut sıklığı ve komut süresi.

Önemli bir eksiklik: ana bilgisayar metrikleri. MongoDB çalıştıran sunucu için CPU, bellek, disk veya ağ kullanımını göremedik. SolarWinds bu bağlamı dahil etmişti, ancak Datadog, New Relic gibi etmedi.

Daha da önemlisi, hiçbir yerde sorgu düzeyinde analiz yoktu. Sorgu desenleri yok, profilleme yok, yavaş sorgu tanımlama yok, eksik indeks tespiti yok. Veritabanı sorun giderme için bu özellikler önemlidir.

Datadog Panosu

Sol menüdeki “Panolar”a tıkladık. Bir “MongoDB – Genel Bakış” panosu otomatik olarak belirdi.

Açtık ama boştu.

Sorunu teşhis etmek zaman aldı. Kurulum sırasında, Datadog'un otomatik keşif yapılandırması, hangi veritabanlarının izleneceğini bir desen eşleşmesi kullanarak belirtmeyi 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 agent'ı yeniden başlattık.

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

Hata ayıklamak için datadog-agent check mongo çalıştırdık. Yapılandırma dosyasında bir girintileme hatası vardı. YAML'ın 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 belirdi.

Pano ile hemen sorunlar yaşadık. YAML dosyamızda log toplamayı yapılandırmış olmamıza rağmen, Loglar bölümü “Erişilemez” olarak görünüyordu. Datadog'un kurulum süreci her şeyin yolunda olduğunu raporlamıştı, ancak loglar hala çalışmıyordu.

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

Yararlı bilgiler ekranın belki %40'ını kaplıyordu: çalışma süresi, bellek kullanımı, ağ I/O, saniye başına sorgu ve okuma/yazma gecikmesi. Sorgu analizi yok, profilleme yok, yavaş sorgu tespiti yok, indeks önerileri yok.

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

Test Ortamı ve Metodolojisi

Adil bir karşılaştırma sağlamak için üç aracı da özdeş 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 agent'ı zaten kurulu olan taze kurulum

Üç sağlayıcı da MongoDB gibi belirli entegrasyonları eklemeden önce temel agent'larını kurmanızı gerektirir. Bu adımı önceden tamamladık, böylece testimiz tamamen MongoDB entegrasyon deneyimine odaklandı.

Neleri ölçtük:

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

Güvenlik Hususları

8.0.17, 7.0.28, 6.0.27 ve önceki MongoDB Sunucu sürümlerini etkileyen “MongoBleed” adlı ciddi bir güvenlik açığı açıklandı. Bu kimlik doğrulaması gerektirmeyen sınır dışı okuma açığı, saldırganların hassas bellek verilerine erişmesine izin verebilir. MongoDB çalıştıran kuruluşlar derhal yamalanmış sürümlere güncellenmelidir: 8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32 veya 4.4.30^{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 araca, önceden dokümantasyon okumadan ve ön eğitim almadan, normal bir kullanıcının yapacağı gibi yaklaştık. Arayüzde belirgin olmayan her şeyi not ettik.

Final Kararı

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

Üçünü de kurup, özdeş iş yüklerini çalıştırıp panoları 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) (Aralık 2024) yayınladı; bu ürün sorgu profilleme, yavaş işlem analizi, açıklama planları ve replikasyon izleme dahil olmak üzere önemli ölçüde daha derin yetenekler sunmaktadır. DBM ürünü, bu benchmark'ta belirlenen sınırlamaların çoğunu gidermektedir⁵ .

Solarwinds: Veritabanı İzleme İçin Üretilmiş

SolarWinds bu karşılaştırmayı kesin bir şekilde kazandı. Platform agent'ımızı anında tespit etti, kopyala-yapıştır komutları aracılığıyla kimlik bilgileri kurulumunda bize rehberlik etti ve entegrasyonu otomatik olarak dağıttı. Kurulum 5 dakika sürdü.

Pano, ilgili bilgilerle anında belirdi. Sorgu profilleme, hangi işlemlerin en çok kaynağı tükettiğini tam olarak gösterdi. Platform, tek bir tanesini bile kaçırmadan tüm 1.400 paket işlemini yakaladı. MongoDB'yi durdurduğumuzda, SolarWinds hatayı 40 saniye içinde tespit etti.

Sorgular sekmesi; hatalar, eksik indeksler, yavaş yanıtlar ve uyarılar üzerinden filtreleme yapmamıza izin veriyor; bu özellikler doğrudan veritabanı optimizasyonunu 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 profilleme ve uygulanabilir içgörüler.

New Relic: Yapılandırmada Kaybolmuş

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

Pano kafa karışıklığı durumu 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 belirdiğinde, metrikler yanlıştı. New Relic, toplam 7 milyon kayıt içeren 1.400 paket işlemi gerçekleştirmemize rağmen 11.670 ekleme raporladı. Platform, sayıları bir basamak düşük hesapladı.

Daha kritik olanı, New Relic hiçbir sorgu düzeyinde analiz sunmadı. Profilleme yok, yavaş sorgu tespiti yok, eksik indeks tanımlama yok. Veritabanı sorun giderme için bu eksiklikler önemlidir.

Datadog: Manuel Çalışma Gerektiriyor

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

Pano otomatik olarak belirdi ancak hiçbir şey göstermedi. Otomatik keşif yapılandırması, veritabanımızla eşleşmeyen bir desen kullanıyordu. Deseni düzelttikten ve YAML girintileme hatalarını giderdikten sonra veriler nihayet doldu.

Panonun kendisi, tekil örnek MongoDB için kötü tasarlanmış olduğunu kanıtladı. Ekranın yüzde altmışı, kullanmadığımız parçalama ve replika seti özellikleri için boş bölümlerle doluydu. Kalan yüzde kırk ise temel metrikleri sunuyordu: çalışma süresi, bellek, ağ I/O, saniye başına sorgu ve gecikme.

Sorgu analizi yok. Profilleme yok. Optimizasyon önerileri yok. Panoda işlem sayılarını doğru bir şekilde belirleyemedik.

Sorgu analizi yok. Profilleme yok. Optimizasyon önerileri yok. Panoda işlem sayılarını doğru bir şekilde belirleyemedik.

Kritik Güncelleme (Aralık 2024): Bu benchmark tamamlandıktan sonra Datadog, bu değerlendirmeyi önemli ölçüde değiştiren MongoDB için Veritabanı İzleme (DBM) özelliğini başlattı. MongoDB için DBM artık şunları sağlar:

• Detaylı sorgu örnekleri ile yavaş işlem analizi
• Sorgu optimizasyonu için açıklama planları
• Replikasyon durumu izleme ve küme sağlığı görselleştirme
• İşlem düzeyinde içgörüler ve performans darboğazlarının belirlenmesi
• Birleşik sorun giderme için uygulama performans izleme ile entegrasyon

DBM, bu benchmark'ta test edilen temel MongoDB entegrasyonuna göre önemli bir yükseltmeyi temsil eder ve testimiz sırasında eksik olan sorgu düzeyindeki analiz özelliklerinin çoğunu içerir^{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 modal ile açıldı. “Veritabanı performansı”nı seçersiniz, MongoDB'yi belirlersiniz ve platform zaten kurduğunuz agent'ı anında bulur; işletim sistemini, bulut örneği ID'sini ve sürüm numarasını doğrudan seçim ekranında size gösterir. Ardından MongoDB'de çalıştırmanız için üç kopyala-yapıştır komutu verir, kimlik bilgilerini halleder ve dağıtımı onaylar. Başlangıçtan bitişe beş dakika.

New Relic on beş dakika sürdü ve süre asıl sorun bile değildi. Arayüz, agent zaten sunucuda olmasına rağmen, hangi işletim sistemi ve hangi MongoDB sürümü gibi agent'ın kendisinin yanıtlayabileceği soruları sormaya devam etti. Bir noktada, açıkça Ubuntu çalıştırıyor olmamıza rağmen varsayılan olarak Amazon Linux kurulum komutlarını sundu. Deneyimi nihayet bozan adım şuydu: pano kataloğunda iki MongoDB entegrasyon seçeneği var, biri standart diğeri Prometheus tabanlı ve UI'da bunları ayıran hiçbir şey yok. Yanlış olanı seçtik, boş bir pano aldık ve bunu ancak yapılandırma dosyalarını inceleyerek anladık.

Datadog, yirmi dakikadan fazla YAML düzenleme, dosya yollarını tahmin etme ve servisleri komut satırından yeniden başlatma gerektirdi. Kurulum sırasında sunulan dokümantasyon bir rehber değil; sadece tek bir veritabanını izlemek isteyen biri için tekil örnekleri, replika setlerini, parçalı kümeleri ve SSL yapılandırmasını aynı anda kapsayan tam bir referans kılavuzuydu. Veriler nihayet belirdiğinde, pano parçalama istatistikleri ve replika seti metrikleri ile başladı. Bizde ikisi de 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, belirgin bir açıklama olmaksızın bir basamak yanlışlıkla 11.670 raporladı ve test sırasında bir bellek sıçramasını tamamen kaçırdı. MongoDB servisini durdurduğumuzda, SolarWinds hatayı otuz ila kırk saniye içinde tespit etti.

Kaynak tüketimi konusunda: 16GB'lık sunucumuzda New Relic yaklaşık 90MB RAM, Datadog yaklaşık 330MB ve SolarWinds yaklaşık 500MB kullandı. SolarWinds, muhtemelen yerel sorgu profilleme çalışmaları 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ı etkilemeyecektir.

Onları Gerçekten Ayıran Özellik

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

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

New Relic ve Datadog yalnızca gecikme, bağlantı sayıları ve toplam işlem miktarları için toplu metrikler gösterdi. Profilleme yok, yavaş sorgu tanımlama yok, eksik indeks tespiti yok. Bir veritabanının hayatta olduğunu onaylamak için işe yarar. Neden zorlandığını teşhis etmek için ise çıkmaz sokaktır.

Not: Datadog, testimizden sonra Aralık 2024'te MongoDB için bir Veritabanı İzleme ürünü yayınladı; bu ürün yavaş işlem analizi, açıklama planları ve sorgu düzeyinde görünürlük ekler. Biz ç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 metrikler, hızlı kurulum ve buradaki platformlar arasında size sadece bir sorgunun yavaş olduğunu değil, bunun hakkında ne yapmanız gerektiğini söyleyen tek platform.

New Relic: Eğer zaten APM için kullanıyorsanız ve temel veritabanı sağlığını aynı yerde istiyorsanız. Yavaş bir isteği tarayıcıdan kod üzerinden veritabanı çağrısına kadar izlemek gerçekten yararlıdır. Kesin işlem sayıları için buna güvenmeyin.

Datadog: Manuel yapılandırmada rahatsanız ve karmaşık bir yığın boyunca tek bir platform istiyorsanız. 600'den fazla entegrasyon, doğru ekip için kurulum sürtünmesini haklı çıkarır.

Bu araştırmayı 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 Sezer, Sena},
  title  = {{MongoDB İzleme: SolarWinds vs New Relic vs Datadog}},
  year   = {2026},
  month  = jun,
  howpublished    = {\url{https://aimultiple.com/mongodb-monitoring}},
  note   = {AIMultiple. Erişim tarihi: 12 Haziran 2026}
}

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.

Release Notes for MongoDB 8.0 - Database Manual - MongoDB Docs

5.

Track and troubleshoot MongoDB performance with Datadog Database Monitoring | Datadog

Datadog

6.

Track and troubleshoot MongoDB performance with Datadog Database Monitoring | Datadog

Datadog

7.

Setting Up Database Monitoring for MongoDB Atlas

Sedat Dogan

CTO

Takip Et

Sedat, yazılım geliştirme, web veri toplama ve siber güvenlik alanlarında deneyime sahip bir teknoloji ve bilgi güvenliği lideridir. Sedat: - Programlama dilleri ve sunucu mimarileri konusunda geniş uzmanlığa sahip, 20 yıllık beyaz şapkalı hacker ve geliştirme uzmanı deneyimine sahiptir. - Ödeme altyapısı gibi yüksek trafikli ve kritik öneme sahip teknoloji operasyonlarına sahip şirketlerin üst düzey yöneticilerine ve yönetim kurulu üyelerine danışmanlık yapmaktadır. - Teknik uzmanlığının yanı sıra kapsamlı iş zekasına da sahiptir.

Tam Profili Görüntüle

Araştıran

Sena Sezer

Sektör Analisti

Takip Et

Sena, AIMultiple'da sektör analisti olarak çalışmaktadır. Boğaziçi Üniversitesi'nden lisans derecesini almıştır.

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