İzlemede kurum içi mi bulut mu?

Bu seçim nadiren özellik seçimidir. Telemetrinin nereye gidebildiği, işletme yükünü kimin taşıdığı ve kurumunuzun değişikliği nasıl yönettiği belirler. Bulutun kazandığı durumlar dahil, dürüstçe tartalım.

Kısa cevap

Aşağıdaki sorularda cevaplarınızın çoğu aynı sütuna düşüyorsa kararınızı büyük ihtimalle vermişsinizdir. Yazının geri kalanı karışık durumlar için, denetimli kurumların çoğu da bu gruptadır.

Soru Buluta işaret eder Kurum içine işaret eder
Telemetri ağınızdan çıkabilir mi? Evet, sözleşme ve aktarım değerlendirmesiyle Hayır veya ancak uzun bir onay süreciyle
Üretim sistemlerinin internet çıkışı var mı? Evet veya vekil yolu kolay açılıyor Hayır veya her çıkış kuralı bir değişiklik talebi
Durum tutan bir platformu kim işletebilir? Boş kapasite yok Kümeleri ve veritabanlarını işleten bir platform ekibi var
İş yükleriniz ne kadar dağınık? Çok bulut ve bölge, az yerel sistem Çoğu kendi veri merkezinizde
Telemetri hacmi ne kadar düzenli? Çok dalgalı, öngörmesi zor Makul ölçüde öngörülebilir
Yeni özelliklere ne kadar hızlı ihtiyacınız var? Çıktığı anda Kendi değişiklik takviminizde

Asıl farklar

İki model de benzer ajanlarla veya OpenTelemetry SDK'larıyla benzer veriyi toplar. Fark, arka ucun nerede durduğunda ve sorumluluğun kimde olduğundadır.

Veri akışı

Barındırılan bir APM'de span'ler, loglar, metrikler ve tarayıcı oturumları ağ sınırınızı geçip üreticinin deposuna gider. Bu veri ilk bakışta sanıldığından hassastır. Span öznitelikleri hesap numaralı URL'ler, SQL metni, iç sunucu adları ve kullanıcı kimlikleri taşıyabilir. Log satırları neredeyse her şeyi içerebilir. Temizleme kuralları yardımcı olur, ama uygulamalar değiştikçe doğru tutmanız gereken bir filtredir ve kaçan tek öznitelik kişisel verinin çıkmış olması demektir.

Kurum içinde aynı veri ağınızda, kendi erişim denetiminiz ve yedek politikanız altında kalır. Risk yok olmaz: APM arka ucu hassas operasyonel verinin toplandığı bir depodur ve diğerleri kadar özen ister. Değişen, kimin sorumlu olduğu ve verinin hangi sınırı geçtiğidir.

İşletme yükü

Bulut modelinde depolama katmanı, güncelleme, ölçekleme ve arka ucun erişilebilirliği üreticiye geçer. Size ajan dağıtımı, enstrümantasyon, maliyet denetimi ve paneller kalır.

Kurum içi model bunların hepsini tutar, üstüne arka ucu işletmeyi ekler. Depolamayı planlamanız, disk büyümesini izlemeniz, önemli olanı yedeklemeniz, güncellemeleri uygulamanız ve diğer sistemler düştüğünde size haber vermesi gereken bir sistem için nöbet tutmanız gerekir. İzleme, izlediği kümede çalışıyorsa o kümenin düştüğünü fark edecek bir yol da gerekir. Küçük bir harici prob veya ikinci bir küme yaygın cevaplardır.

Erişilebilirlik ilişkisi

Bulut arka ucu veri merkezinizden bağımsız arızalanır ve bu değerlidir: siteniz düştüğünde izlemeniz bunu gösterir. Öte yandan internet hattınıza bağlıdır. Hat kesilirse ajanlar kısa süre tamponlar, sonra veriyi düşürür.

Kurum içi arka uç internete hiç bağlı değildir, üst hat kesintisinde çalışmayı sürdüren sistemlere uyar. Ancak izlediği sistemlerle aynı enerjiyi, ağı veya kümeyi paylaşabilir. Arıza alanlarını bilinçli düşünün.

Güncelleme ve değişiklik denetimi

Bulutta özellikler üretici çıkardığında gelir. Birçok ekip için bu fayda, sıkı değişiklik penceresi olan ekipler için onaylanmamış bir davranış değişikliği denetim sorusu olabilir. Kendi altyapınızda takvim sizindir, yükü de: sürekli ertelediğiniz güncelleme, uygulamadığınız bir güvenlik yamasıdır.

Maliyet şekli

Rakam vermeyeceğiz, çünkü liste fiyatları değişir ve her sözleşme farklıdır. Önemli olan yapıdır. Bulut maliyeti genellikle sunucu, alınan veya indekslenen veri hacmi gibi birimlerle büyür, geveze bir dağıtım faturayı değiştirebilir. Kurum içi maliyet donanım, depolama, lisans ve personel zamanıdır. Daha çok basamaklı büyür ve bir kısmı iç bütçelerde gizlidir. Karşılaştırmayı birkaç yıl üzerinden, kendi hacimlerinizle yapın, iki tarafın personel zamanını da katın. Türkiye'de döviz bazlı fiyatlandırılan abonelikler için kur riskini de bütçe tablosuna ekleyin.

Kendi sayılarınızla kapasite taslağı

Herkes tartışmaya başlamadan önce bu hesabı yapın. Aşağıdaki rakamlar kurgu bir örnektir, herhangi bir ürünün kıyas değeri değildir.

200 servisin toplamda saniyede 5.000 istek karşıladığını, istek başına ortalama 10 span üretildiğini ve bir span'in hatta yaklaşık 400 bayt tuttuğunu varsayalım.

Saniyede span: 5.000 × 10 = 50.000
Ham akış: 50.000 × 400 bayt = 20 MB/sn
Günlük: 20 MB/sn × 86.400 sn = 1.728.000 MB ≈ 1,73 TB
Yüzde 10 örnekleme: ≈ 173 GB/gün
30 gün saklama: 173 GB × 30 ≈ 5,2 TB (sıkıştırma ve kopya öncesi)
Dış hat: 20 MB/sn × 8 = 160 Mbit/sn (örneklenmemiş, sıkıştırma öncesi)

Aynı hesap iki modelde de geçerlidir. Bulutta alım ve indeksleme hacmini tahmin eder, kurum içinde diski boyutlandırır. Örneklemenin konuşmaya neden erken girmesi gerektiğini de gösterir: sonucu iki modelde de on kat değiştirir. Son satır ayrıca bulut seçeneğinde dış hat kapasitenizi sorgulatır.

Denetimli ortamlarda kararı veren sorular

Mevzuat nadiren açıkça "bulut olmaz" der. Kişisel veri, dış hizmet alımı, sınır ötesi aktarım ve operasyonel dayanıklılık gereklilikleri ülkeye ve sektöre göre değişir, size uygulananlar kendi durumunuza bağlıdır. KVKK ve BDDK düzenlemeleri, PCI DSS ve benzerleri konuya farklı yönlerden dokunur. Aşağıdakileri uyum ve hukuk ekiplerinize sorulacak sorular olarak görün, bu metin hukuki görüş değildir.

  1. Telemetrinin bir kısmı kişisel veri mi? Kullanıcı kimlikleri, IP adresleri ve serbest metin loglar yüzünden aksini gösteremiyorsanız evet varsayın.
  2. APM üreticisi dış hizmet sağlayıcısı veya alt işleyen sayılır mı? Bu; bildirim, sözleşme ve çıkış planı işi doğurabilir.
  3. Veri nerede duruyor, üreticinin personeli nereden erişiyor? Depolama bölgesi ile destek erişimi ayrı sorulardır.
  4. Silmeyi kanıtlayabilir misiniz? Saklama değişikliğinin veya silme talebinin nasıl yapıldığını ve belgelendiğini sorun.
  5. Yapay zekâ özellikleri veriyi başka yere gönderiyor mu? Asistan dış modele bağlanıyorsa veri akışınızın yeni bir kolu vardır.
  6. Onay ne kadar sürüyor? Bazı kurumlarda yeni bir dış veri akışını onaylatmak bütün kurulumdan uzun sürer. Bu gecikme gerçek bir maliyettir.

Türkiye bağlamında ayrıntı için KVKK ve veri yerelliği sayfasına bakın.

Bulutun daha doğru olduğu durumlar

Bunlardan birkaçı geçerliyse büyük ihtimalle barındırılan bir servisi seçmeli veya orada kalmalısınız:

  • İş yükleriniz zaten genel bulutta, telemetrinin başka bir bulut servisine gitmesi yeni risk eklemiyor.
  • Durum tutan bir platformu üstlenecek ekibiniz yok, işe alım da planlanmıyor.
  • Birçok bölgede hiçbir şey kurmadan küresel kapsama istiyorsunuz.
  • Hukuk ekibiniz veri akışını çoktan onayladı.
  • Bulut servisleri ve yönetilen veritabanlarıyla geniş hazır entegrasyon istiyorsunuz.
  • Telemetri hacminiz küçük, fatura bir platformu işletmenin personel zamanına kıyasla mütevazı.

Ayda bir haftasını kendi izleme sistemini ayakta tutmaya harcayan küçük bir ekip kötü bir takas yapmıştır. Belirli bir gereksinim olmadan "daha güvenli geliyor" diye kurum içine geçmek çoğu zaman böyle biter.

Kurum içinin daha doğru olduğu durumlar

  • Ağ kuralları üretimden dış yolu yasaklıyor veya bir bölüm tamamen kapalı.
  • Uyum duruşunuz telemetrinin kendi veri merkezlerinizde kalmasına dayanıyor.
  • Sistemlerinizin çoğu kendi OpenShift veya Kubernetes kümelerinizde ve Linux sunucularda, onları işleten bir platform ekibiniz var.
  • Yapay zekâ destekli analiz istiyor ama logları ve trace'leri dış modele göndermek istemiyorsunuz.
  • İnternet kesintisinde tam görünürlükle çalışmanız gerekiyor.

Karma model mümkün, ama bir tuzağı var

Bazı kurumlar internete açık dijital kanallar için bulutu, ana sistemler için kurum içini tutar. OpenTelemetry bunu eskisinden daha uygulanabilir yapar: aynı enstrümantasyon iki arka uca da gönderebilir, bir collector ortama göre yönlendirebilir.

Tuzak, sınırı geçen trace'tedir. Bulutta çalışan web katmanından ana sisteme giden istek, bilinçli olarak birleştirmezseniz her sistemde yarım trace üretir. Müdahale eden kişilerin bu istekleri nasıl izleyeceğine önceden karar verin ve traceparent başlığının sınırı geçmesini sağlayın, böylece en azından trace kimliği iki tarafta eşleşir.

Adil bir değerlendirme nasıl yapılır?

Cilalı bir bulut denemesini yarım kurulmuş bir kurum içi kavram kanıtıyla karşılaştırmayın, tersini de. İkisinde aynı servisleri kullanın, aynı işleri puanlayın:

  1. Hiçbir şey yokken gerçek bir serviste ilk işe yarar trace'e kadar geçen süre.
  2. Yakın zamanda yaşanan gerçek bir olayın yakalanan veriyle teşhis edilip edilemeyeceği.
  3. Onay için gerekenler: güvenlik duvarı kuralları, güvenlik incelemesi, SCC veya yetki istisnaları.
  4. Planlı bir arıza: arka ucun bir kısmını durdurun veya hattı kesin, neyin kaybolduğuna ve nasıl toparlandığına bakın.
  5. Gerçekte yapacak kişilerin elinden tek bir güncelleme.

Wrentrix nerede duruyor?

Wrentrix kurum içi bir platformdur. OpenShift, Kubernetes veya Linux sunucularda çalışır, Helm chart, OpenShift operatörü veya Docker Compose ile kurulur. Ağınızdan telemetri çıkmaz, lisans çağrısı ve dış model olmadan tamamen kapalı ağda çalışır. Yukarıda anlatılan işletme yükü sizde kalır. Depolama PostgreSQL olduğundan ekibinizin onu işletmeye alışkın olması gerekir. Taahhüt etmeden önce bakmak için canlı demo tarayıcıda örnek veriyle çalışır, kurulum ayrıntıları kurum içi APM sayfasındadır.

Sık sorulan sorular

Kurum içi APM buluttan daha mı güvenlidir?

Kendiliğinden değil. Dış veri akışını ve üçüncü tarafı risk tablonuzdan çıkarır, ama yama, erişim denetimi, yedek koruması ve platformun izlenmesi size geçer. Kötü işletilen bir iç sistem, iyi işletilen bir servisten zayıf olabilir, cevap ekibinize ve tehdit modelinize bağlıdır.

Kurum içi APM daha mı ucuzdur?

Hacme, saklama süresine ve personel zamanını nasıl saydığınıza bağlıdır, genel bir cevabı yoktur. Yüksek ve düzenli hacimler genellikle sahip olunan kapasiteyi, küçük veya düzensiz ortamlar ise barındırılan servisi öne çıkarır. İkisini birkaç yıl üzerinden kendi rakamlarınızla ve işletecek kişileri katarak modelleyin.

İnternet erişimi olmayan ağda bulut APM kullanılabilir mi?

Doğrudan genellikle kullanılamaz, çünkü ajanların üreticinin adresine bir şekilde ulaşması gerekir. Bazen denetimli bir vekil sunucu veya ağ geçidiyle yönlendirme yapılabilir, ama o zaman ağ gerçekten yalıtılmış olmaktan çıkar. Tamamen kapalı bir bölüm, içinde bir arka uç gerektirir.

Sonradan buluttan kurum içine yeniden enstrümantasyon yapmadan geçebilir miyim?

Uygulamalarınız OpenTelemetry SDK'ları veya operatörü kullanıyorsa genellikle evet, çünkü çoğunlukla dışa aktarım hedefini değiştirirsiniz. Üreticiye özel ajanlar, özel paneller, alarm kuralları ve SLO tanımları yine yeniden yapılır. Enstrümantasyonu baştan üreticiden bağımsız tutmak en ucuz çıkış planıdır.

Telemetriyi kurum içinde tutmak beni KVKK'ya uyumlu yapar mı?

Hayır. Verinin yeri birçok etkenden biridir, kanun hukuki dayanak, saklama, erişim ve güvenlik tedbirlerini de kapsar. Veriyi ağınızda tutmak aktarımla ilgili bazı soruları sadeleştirebilir, ama bütün durumu hukuk ekibiniz değerlendirmelidir. Bu sayfa hukuki görüş değildir.