Kurum içi APM: ne zaman doğru seçim, size neye mal olur?

Kararı genelde özellik listesi vermez

Türkiye'de on-premise APM yazılımı arayan kurumların çoğu bu noktaya bir özellik yüzünden gelmiyor. Güvenlik ekibi, hukuk birimi veya ağ mimarisi bir soruya net bir cevap vermiş oluyor. Değerlendirmeye bu dört soruyla başlayın.

Telemetri ağınızdan çıkabilir mi? Trace'lerde URL'ler ve SQL cümleleri, loglarda ise geliştiricinin o gün yazmayı uygun gördüğü her şey bulunur. Bilgi güvenliği biriminiz "hayır" dediyse ya da "evet" demesi bir yıl sürecekse, barındırılan servisin ne kadar iyi olduğu konuyu değiştirmez.

İzlenen sistemlerin dışarıya yolu var mı? Kapalı bir ağda ajanlar dış servise ulaşamaz. Ağ sınırının içinde bir arka uç, istisna kuralı yazmadan çalışan tek tasarımdır.

Dış bağlantı koptuğunda izleme ne olacak? Kesintinin parçası WAN hattınızsa, o hattın ötesindeki izleme sistemi tam da ihtiyaç duyduğunuz anda kör kalır. İçerideki arka uç içerideki sistemleri görmeye devam eder.

Yazılımın ne zaman değişeceğine kim karar veriyor? Üretimdeki her bileşenin test ve onaydan geçmesini isteyen ortamlarda üreticinin kendi takvimiyle değişen bir ürün sürtüşme yaratır. Kendi kurduğunuz yazılım, planladığınız değişiklik penceresinde güncellenir.

Dört soruya da "fark etmez" diyorsanız barındırılan bir servis sizin için daha iyi olabilir. Ayrıntılı karşılaştırma için kurum içi mi bulut mu yazısını okuyun.

Kurum içi kurulumun yanlış tercih olduğu durumlar

• İşletecek kimse yok. Kendi arka ucunuzun güncelleme, depolama, yedek ve kapasite sorumlusu olmalı. Zaten yetişemeyen iki kişilik bir ekibin zamanı başka yere harcanmalı.
• İş yükleriniz genel bulutta ve telemetri kısıtınız yok. Veriyi yakındaki yönetilen bir servise göndermek en basit yol olabilir. Aynı buluta kendi arka ucunuzu kurmanın kazancı azdır.
• Dünyanın farklı yerlerinden dış gözlem gerekiyor. Veri merkezinizdeki bir prob, sitenizin başka bir kıtadan nasıl göründüğünü söyleyemez.
• Hacminiz kısa sürede katlanabilir. Barındırılan servisler ani büyümeyi emer, kendi arka ucunuzda ise kapasite sizin sorununuzdur.
• Ölçeğiniz küçük, veriniz hassas değil. Bu durumda hafif bir araç yeterli olabilir, tam bir APM platformu fazla gelir.

Üstlendiğiniz işler

Bunların hiçbiri bir platform ekibi için olağandışı değildir, ama hepsi gerçek iştir.

Son satır kolayca atlanır. İzleme platformu, izlediği sistemlerle aynı kümede ve aynı depolamada duruyorsa ortak bir arıza ikisini birden götürür. Mümkünse farklı bir arıza alanına yerleştirin. En azından izlemenin kendisi düştüğünde birine haber veren basit, bağımsız bir kontrol bulunsun.

Depolamayı kabaca hesaplamak

Genel boyutlandırma rakamı yayınlamıyoruz, çünkü yanıltıcı olur. Kendi sayılarınızla ilk tahmini şöyle çıkarabilirsiniz. Aşağıdaki girdiler yalnızca örnektir, gerçek ölçümlerinizle değiştirin.

Örnekleme sonrası saniyede 50 trace sakladığınızı, bir trace'in ortalama 40 span içerdiğini ve bir span'in sıkıştırma öncesi 1 KB olduğunu varsayalım.

50 trace/sn × 40 span × 1 KB = 2.000 KB/sn = 2 MB/sn
2 MB/sn × 86.400 sn/gün = 172.800 MB/gün ≈ 173 GB/gün
173 GB/gün × 14 gün saklama ≈ 2,4 TB

Bu hesapta üç şeye dikkat edin. Örnekleme kararı sonucu neredeyse her şeyden fazla etkiler: aynı varsayımlarla saniyede 800 trace'in tamamını saklarsanız günlük hacim yaklaşık 2,76 TB olur. Span boyutu da servise göre çok değişir, uzun SQL cümleleri ekleyen bir servis ortalamanın birkaç katına çıkabilir. Üçüncüsü, örnek logları dışarıda bırakıyor. Loglar çoğu zaman en büyük kalemdir; indeks ve sıkıştırma ise sonucu ters yönlerde etkiler.

Ölçülmüş sayılarla gelirseniz birlikte bakabiliriz: info@wrentrix.com.

Wrentrix nasıl kurulur?

Wrentrix, Red Hat OpenShift, Kubernetes ve Linux sunucular üzerinde çalışır.

Platform varsayılan restricted-v2 SCC altında çalışır: en az yetkili pod'lar, root yok, ek SCC yok. Bunun pratik bir karşılığı var. Özel SCC veya ayrıcalıklı DaemonSet isteyen bir izleme aracı genellikle uzun bir güvenlik incelemesine girer.

Sistem bağlamak hedef başına birkaç dakika sürer. Arayüzden küme veya sunucu eklersiniz, jetonu içinde gelen YAML dosyasını ya da betiği indirirsiniz, uygularsınız. Düğümler, pod'lar ve sunucular yaklaşık iki dakikada görünür. Java ve .NET iş yükleri bir sonraki yeniden başlatmada metot düzeyinde izlenmeye başlar; Wrentrix kendisi hiçbir şeyi yeniden başlatmaz.

Mevcut OpenTelemetry yatırımınız boşa gitmez. Her SDK OTLP gönderebilir, var olan collector'larınız çalışmaya devam eder. Bir gün arka uç değiştirirseniz enstrümantasyonunuz geçerli kalır.

Değerlendirme nasıl yürütülmeli?

Zor soruları satın almadan önce cevaplayın. İki ila dört haftalık bir plan şöyle olabilir:

1. 1. hafta: güvenlik incelemesi ve kurulum. YAML dosyasını ve mimariyi güvenlik ekibine verin. SCC, webhook ayarları, ajanın RBAC yetkileri ve dışarıya çıkış trafiği kontrol edilsin.
2. 1-2. hafta: gerçek bir küme. Kritik olmayan ama gerçekçi bir ortam seçin. İçinde bir Java veya .NET servisi, bir Linux sunucu ve gerçek bir bağımlılık zinciri bulunsun.
3. 2. hafta: arıza senaryoları. Ajanı durdurup pod oluşturun, pod'un başladığını görün. Arka ucu durdurup uygulamaların fark etmediğini doğrulayın. Dışarı çıkışı kapatıp hiçbir şeyin değişmediğine bakın.
4. 2-3. hafta: gerçek bir olayı canlandırın. Kontrollü bir arıza yaratın, kurulumu görmemiş bir mühendise teşhis ettirin ve süreyi tutun.
5. 3-4. hafta: sahip olma maliyetini ölçün. Ekibiniz kaç saat harcadı, depolama ne hızla büyüyor? Temsili bir serviste enstrümantasyonlu ve enstrümantasyonsuz çalışmayı karşılaştırıp ek yükü ölçün.

Canlı demo arka ucu olmayan, örnek veriyle çalışan bir gezintidir. Ekranları tanımak için işe yarar, ama ürünün sizin iş yükünüzde nasıl davranacağı hakkında bir şey söylemez. Kendi ortamınızda denemek için demo talebi bırakabilirsiniz.

Veri denetimi argümanını dikkatli kullanın

Kendi altyapınızda çalıştırmak "bu veri nerede?" sorusuna net cevap verir: sizin donanımınızda, sizin ağınızda, dışarıya 0 bayt telemetri çıkarak. Ancak bu tek başına hiçbir kurumu hiçbir düzenlemeye uyumlu yapmaz. Erişim denetimi, saklama süreleri ve logların içeriği sizde kalır. KVKK veya BDDK düzenlemelerinden doğan yükümlülükler durumunuza göre değişir; genel çerçeve için KVKK ve veri yerelliği sayfasına bakın. Bu metin hukuki görüş değildir.

Sık sorulan sorular

Kurum içi APM nedir?

Arka ucu üreticinin bulutunda değil, sizin denetiminizdeki altyapıda çalışan uygulama performans izlemedir. Ajanlarınız ve SDK'larınız trace, log ve metrikleri ağınızın içindeki sistemlere gönderir. Veri denetimi ve dış bağlantıdan bağımsızlık kazanırsınız, platformu işletme işini de üstlenirsiniz.

Kurum içi APM buluttan daha mı pahalıdır?

Duruma göre değişir ve genel bir rakam vermek doğru olmaz. Kendi altyapınızda maliyet donanıma, depolamaya ve personel zamanına kayar; barındırılan servislerde fiyat çoğunlukla veri hacmi veya sunucu sayısıyla büyür. Karşılaştırmayı gerçek hacimlerinizle ve iki tarafın mühendislik saatlerini dahil ederek yapın.

OpenShift üzerinde kurum içi APM çalışır mı?

Evet. Wrentrix OpenShift'e operatör veya Helm chart ile kurulur ve varsayılan restricted-v2 SCC altında, root ve ek SCC olmadan çalışır. Kubernetes ve Linux sunucularda da çalışır.

Kurulum ne kadar sürer?

Platform kurulduktan sonra bir küme veya sunucu eklemek için YAML dosyası ya da betik indirmeniz yeterlidir; düğümler, pod'lar ve sunucular yaklaşık iki dakikada görünür. Java ve .NET için metot düzeyi veri, iş yükleri bir sonraki yeniden başladığında gelir. Güvenlik incelemesi ve depolama planlaması çoğu zaman teknik kurulumdan uzun sürer.

OpenTelemetry kullanmak beni bir arka uca bağlar mı?

Hayır, zaten temel faydalarından biri budur. Wrentrix standart OTLP kabul eder, dolayısıyla OpenTelemetry SDK'larıyla yazılmış enstrümantasyon başka bir OTLP arka ucuyla da kullanılabilir. Değerlendirme sırasında bir collector aynı veriyi iki arka uca birden gönderebilir.