MongoDB İzleme: SolarWinds New Relic ve Datadog ile karşılaştırma
Test etmek amacıyla, MongoDB 7.0 sürümünü ç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 sorunu 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ı) | Düşük (90MB) | Temel sağlık kontrolleri |
Veri Köpeği | 20+ dakika | ❌ | Belirsiz | Orta Boy (330 MB) | Çoklu teknoloji izleme |
MongoDB performans özetini izleme
- SolarWinds, otomatik algılama ile kurulumu 5 dakika içinde 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ı ö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üler.
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 içinde çalıştırdık ve "Veritabanını Gözlemle"ye tıkladık.
Solarwinds'in bizi etkilediği nokta burasıydı. İ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 izleme ve sorgu profilleme ile MongoDB Gözlemlenebilirliği keşfedin. SolarWinds'yi 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 aradık ve MongoDB ile ilgili birden fazla entegrasyon bulduk.
MongoDB'u seçtikten sonra, New Relic bizden bir ölçüm 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 biliyor, 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ünün 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 MongoDB numaralı bir komut dosyası 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" araması yaptık. MongoDB üzerine tıkladık ve bir açılır pencere belirdi.
Genel bakış, MongoDB izleme hizmetinin neleri içerdiğini gösteriyordu, ancak "Entegrasyonu Yükle"ye tıklamak, yoğun talimatlar içeren başka bir ekranı açtı.
İşte bu noktada Datadog bizi hayrete düşürdü. Ekranda, olası her senaryoyu kapsayan eksiksiz bir referans kılavuzu gösteriliyordu: bağımsız örnekler, çoğaltma kümeleri, 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 kadar uzun metin aşırı geldi.
Temel adımları bulmak için sayfayı aşağı doğru kaydırdık:
- MongoDB içinde 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 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 söyleniyordu.
Tecrübemizden bunun /etc/datadog-agent/conf.d/mongo.d/ dizininde olması gerektiğini biliyorduk, ancak talimatlar bu detayı dokümantasyonun derinliklerine gizlemişti.
MongoDB kullanıcısını oluşturduk, YAML yapılandırmasını yazdık, doğru dizine yerleştirdik ve aracıyı 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 Gösterge Panelleri bölümüne gittik ve MongoDB adet ölçümün 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ı anda yük altında aynı MongoDB örneğinden veri toplamasıyla gerçekleştirildi.
Rastgele veri üreten bir komut dosyası kullanarak MongoDB adlı veritabanına 2 milyon kayıt ekleyerek sistemi zorladık. Bu işlem, gerçek dünya veritabanı etkinliğini simüle ederken, 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, SolarWinds'nin sorgu profilleme özellikleri nedeniyle yerel olarak depolanan verilere daha sık eriştiğini düşündürmektedir.
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ık durumu, ortalama yanıt süresi, verimlilik (saniyede sorgu sayısı) ve hata sayısı gösteriliyordu. "En İyi 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 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'a özel uyarılar oluşturmamızı sağladı. 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 ana bilgisayar düzeyindeki ölçümleri, CPU, bellek, disk ve ağ verilerini 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 yoktu, ancak önceki testimizde MySQL için öneriler sunmuştu. Daha fazla veri topladıkça optimizasyon önerileri sunmasını bekliyoruz.
Yapay Zeka Güncellemeleri : Ekim 2025'te, SolarWinds yapay zeka sorgulama desteği özelliğine sahip Yapay Zeka Aracısını (şu anda teknik önizleme aşamasında) kullanıma sundu. Yapay Zeka Sorgulama 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. SolarWinds portföyü genelinde Yapay Zeka Aracısının 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 MongoDB kontrol paneli otomatik olarak görünmedi.
Kontrol paneli kataloğunda "mongo" kelimesini aradık ve iki adet 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'u kurduğumuzu biliyordu, o halde neden bizi tekrar kurulum sayfasına gönderdi? "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 iki MongoDB seçeneği gösterdi, bunlardan biri Prometheus sürümüydü. 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 doğrudan MongoDB sorgusuyla ("Kaç belgeniz var?") alıyor. 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 komutunu ç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 Topluluk Sürümü
- 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 sunucu sürümlerinin 8.0.17, 7.0.28, 6.0.27 ve daha önceki sürümlerini etkileyen “MongoBleed” adlı ciddi bir güvenlik açığı tespit edildi. 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 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 çoğaltma 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ı kesin bir şekilde 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 işlemini durdurduğumuzda, SolarWinds işlemi 40 saniye içinde hatayı 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 11.670 kez eklendiğini 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 parçalama ve çoğaltma kümeleri özelliklerine ayrılmış bölümler içeriyordu. 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 eder ve testlerimiz sırasında eksik olan birçok sorgu düzeyinde analiz özelliğini 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 açılır pencereyle açıldı. "Veritabanı performansı"nı seçip MongoDB'u 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'da ç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.
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 çalıştırı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 1.400 saydı. Tamamen doğru. New Relic 11.670 bildirdi, bu da belirgin bir açıklama olmaksızın büyüklük mertebesinde bir yanlışlık ve test sırasında bellek kullanımındaki ani artışı tamamen gözden kaçırdı. MongoDB hizmetini durdurduğumuzda, SolarWinds otuz ila kırk saniye içinde hatayı tespit etti.
Kaynak tüketimi konusunda: New Relic 16 GB'lık sunucumuzda 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 değil, 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.