Linux kapsayıcılarında tanı bilgilerini toplama

Diğer senaryolarda .NET sorunlarını tanılamak için yararlı olan tanılama araçları kapsayıcılarda da çalışır. Araçlar, hedef işlemle aynı kapsayıcıda, konaktan veya yan arabası kapsayıcısından çalıştırılabilir.

Kapsayıcıda .NET CLI araçlarını kullanma

Bu araçlar şunlar için geçerlidir: ✔️ .NET Core 3.1 SDK ve sonraki sürümleri

Dotnet-* CLI tanılama araçlarının tümü, inceledikleri uygulamayla aynı kapsayıcı içinde çalıştırıldığında çalışabilir, ancak şu olası sorun noktalarına dikkat edin:

• Kapsayıcı içinde çalıştırılacak araçlar, kapsayıcı kaynak sınırlarına tabi olacaktır. Kaynak sınırları çok düşükse araçlar yavaş çalışabilir veya başarısız olabilir. Araçların çoğu mütevazı gereksinimlere sahiptir, dotnet-dump ancak dotnet-gcdump büyük bir bellek ayak izine sahip bir işlemi hedeflerken önemli miktarda bellek ve disk alanı kullanabilir. dotnet-trace ve dotnet-counters ayrıca büyük miktarda izleme olayı veya ölçüm zaman serisi verisi yakalamak üzere yapılandırılmışsa büyük dosyalar oluşturabilir.
• dotnet-dump , ptrace izinleri gerektiren bir yardımcı işlemin çalıştırılmasına neden olur. Linux'ta bunun başarılı olup olmadığını etkileyebilecek çok sayıda güvenlik yapılandırması seçeneği vardır, bu nedenle bazı durumlarda kapsayıcının güvenlik yapılandırmasını ayarlamanız gerekebilir. Güvenlik ayrıcalıklarının teşhis edilmesi hakkında daha fazla bilgi için dump FAQ bölümüne bakın.
• Araçları kapsayıcı içinde çalıştırırken, kapsayıcıyı oluştururken önceden yükleyebilir veya isteğe bağlı olarak indirebilirsiniz. Bunları önceden yüklemek, ihtiyaç duyduğunuzda daha kolay olmasını sağlar, ancak kapsayıcının boyutunu artırır ve kötü amaçlı aktörlerin yararlanmaya çalışabileceği daha büyük bir saldırı yüzeyi oluşturur.

Yan kapsayıcıda veya konak bilgisayardan .NET CLI araçlarını kullanın.

dotnet-* CLI tanılama araçları, ana makineden veya yan araba kapsayıcısında çalıştırılmayı da destekler. Bu, aynı kapsayıcıda çalıştırmanın boyutu, güvenliği ve kaynak sınırlamalarını büyük ölçüde önler, ancak araçların başarıyla iletişim kurması için bazı ek gereksinimlere sahiptir.

--process-id veya --name aracı komut satırı bağımsız değişkenlerini kullanarak incelemek üzere bir hedef işlem tanımlarken, bunun için:

1. Sepet kapsayıcısı içindeki araçların hedef kapsayıcıdaki işlemlere erişebilmesi için kapsayıcıların bir işlem ad alanını paylaşması gerekir.
2. Araçların ,NET çalışma zamanının /tmp dizinine yazdığı tanılama bağlantı noktası Unix Etki Alanı Yuvasına erişmesi gerekir, bu nedenle /tmp dizini bir birim bağlama aracılığıyla hedef ve sepet kapsayıcısı arasında paylaşılmalıdır. Bu, örneğin kapsayıcıların ortak bir birimi veya Kubernetes emptyDir birimini paylaşmasını sağlayarak yapılabilir. /tmp dizinini paylaşmadan yan araba kapsayıcısından tanılama araçlarını kullanmayı denerseniz, "uyumlu .NET çalışma zamanını çalıştırmayan bir işlem" hakkında bir hata mesajı alırsınız.

İşlem ad alanını ve /tmp dizinini paylaşmak istemiyorsanız, araçların çoğu daha gelişmiş --diagnostic-port bir komut satırı seçeneğini de destekler. Bu, konak veya sepet dosya sistemi içinde hedef işlemin tanılama bağlantı noktasının yolunu doğrudan belirtmenize olanak tanır. Bu yolun var olması için hedef kapsayıcının /tmp dizininin bir yere eşlenmesi gerekir, ancak ana bilgisayar veya sidecar /tmp ile paylaşılması gerekmez.

Not

Ana bilgisayar veya yan arabadan tanılama araçlarını çalıştırırken bile, hedef süreçten, hedef kapsayıcı içindeki kaynak kullanımını artıran bir iş yapması hala istenebilir. Dotnet-dump'ın, döküm toplanırken hedef işlemin büyük miktarda sanal bellek sayfalamasına neden olabileceğini gözlemledik. Diğer araçlar daha küçük etkilere neden olabilir, ancak bunları uygulamada sorunlara neden olduğunu görmedik. Örneğin, dotnet-trace hedef işlemin küçük bir olay arabelleği tahsis etmesini ve dotnet-counters ölçüm verilerinin toplandığı küçük bir bellek bölgesi istemesini istemektedir. Bellek sınırlarınızın, araçları çalıştırmanın işletim sisteminin kapsayıcılarınızı sonlandırmasına neden olacak kadar sıkı olmadığından emin olmak için test yapmanızı öneririz.

Not

dotnet-dump Diske döküm dosyası yazdığında, çıkış yolu hedef işlemin dosya sistemi görünümü bağlamında yorumlanır. Bu, konak veya sidecar konteynerından farklı olabilir.

Kapsayıcıda kullanma PerfCollect

Bu araç şunlar için geçerlidir: ✔️ .NET Core 2.1 ve sonraki sürümler

Betik PerfCollect CPU örnekleri veya bağlam değişiklikleri gibi çekirdek olayları içeren performans izlemelerini toplamak için kullanışlıdır. Kapsayıcıda kullanıyorsanız PerfCollect aşağıdaki gereksinimleri göz önünde bulundurun:

• PerfCollect aracı çalıştırmak perf için ek özellikler gerektirir. Gereken en düşük özellik kümesi PERFMON ve SYS_PTRACE'dir. Bazı ortamlar için bu gerekir SYS_ADMIN. Kapsayıcıyı gerekli özelliklerle başlattığınızdan emin olun. En düşük küme işe yaramazsa tam kümeyi deneyin.

• PerfCollect , profil oluşturma işlemi başlatılmadan önce bazı ortam değişkenlerinin ayarlanmasını gerektirir. Bunlar dockerfile içinde veya kapsayıcıyı başlattığınızda ayarlanabilir. Bu değişkenlerin normal üretim ortamlarında ayarlanmaması gerektiğinden, profili oluşturulacak bir kapsayıcı başlatılırken bunların eklenmesi yaygın bir durum olur. PerfCollect'in gerektirdiği iki değişken şunlardır:

  • DOTNET_PerfMapEnabled=1
  • DOTNET_EnableEventLog=1

Not

Uygulamayı .NET 7 ile yürütürken, önceki ortam değişkenlerine ek olarak da ayarlamanız DOTNET_EnableWriteXorExecute=0 gerekir.

Bir yan araba kapsayıcıda PerfCollect kullanın

Farklı bir kapsayıcıdaki .NET işleminin profilini oluşturmak için bir kapsayıcıda çalıştırmak PerfCollect istiyorsanız, deneyim neredeyse aynıdır. Farklar şunlardır:

• Daha önce bahsedilen ortam değişkenleri (DOTNET_PerfMapEnabled ve DOTNET_EnableEventLog) hedef kapsayıcı için ayarlanmalıdır; PerfCollect kapsayıcısını çalıştıran için ayarlanmamalıdır.
• Çalıştırmakta olan PerfCollect kapsayıcısının SYS_ADMIN yeteneği olmalıdır (hedef kapsayıcı için değil).
• İki kapsayıcının bir işlem ad alanını paylaşması gerekir.