Shromažďování diagnostiky v kontejnerech Linuxu

Stejné diagnostické nástroje, které jsou užitečné pro diagnostiku problémů .NET v jiných scénářích, fungují také v kontejnerech. Nástroje se dají spustit ve stejném kontejneru jako cílový proces, z hostitelského systému nebo z sidecarového kontejneru.

Použití nástrojů .NET CLI v kontejneru

Tyto nástroje platí pro: ✔️ .NET Core 3.1 SDK a novější verze.

Všechny diagnostické nástroje rozhraní příkazového řádku dotnet-* můžou fungovat při spuštění ve stejném kontejneru jako aplikace, kterou kontrolují, ale pozor na tyto potenciální problémy:

• Nástroje spuštěné uvnitř kontejneru musí respektovat omezení prostředků kontejneru. Pokud jsou limity prostředků příliš nízké, nástroje můžou běžet pomalu nebo selžou. Většina nástrojů má skromné požadavky, ale dotnet-dump a dotnet-gcdump mohou využít značné množství paměti a diskového prostoru při zpracování procesu s vysokými nároky na paměť. dotnet-trace a dotnet-counters mohou také vytvářet velké soubory, pokud jsou nastaveny k zaznamenávání velkého množství trasovacích událostí nebo časově řazených dat metrik.
• dotnet-dump způsobí spuštění pomocného procesu, který potřebuje oprávnění ptrace. Linux má řadu možností konfigurace zabezpečení, které můžou ovlivnit, jestli je to úspěšné, takže v některých případech možná budete muset upravit konfiguraci zabezpečení kontejneru. Další pokyny k diagnostice oprávnění zabezpečení najdete v nejčastějších dotazech k výpisu.
• Při spouštění nástrojů v kontejneru je můžete nainstalovat předem při sestavování kontejneru nebo je stáhnout na vyžádání. Jejich instalace předem usnadňuje, když je potřebujete, ale zvětší velikost kontejneru a vytvoří větší prostor pro útok, který by se aktéři se zlými úmysly mohli pokusit zneužít.

Použijte nástroje .NET CLI v sidecar kontejneru nebo z hostu

Diagnostické nástroje rozhraní příkazového řádku dotnet-* podporují také spouštění z hostitele nebo v postranním kontejneru. Tím se do značné míry vyhýbá omezením velikosti, zabezpečení a prostředků spuštěných ve stejném kontejneru, ale jsou zapotřebí některé další požadavky pro úspěšnou komunikaci mezi nástroji.

Při identifikaci cílového procesu pro kontrolu pomocí argumentů příkazového --process-id řádku nebo --name nástroje to vyžaduje:

1. Kontejnery musí sdílet obor názvů procesu, aby nástroje ve vedlejším kontejneru mohly přistupovat k procesům v cílovém kontejneru.
2. Nástroje potřebují přístup k diagnostickému portu Unix Domain Socket, který modul runtime .NET zapisuje do adresáře /tmp , takže adresář /tmp musí být sdílen mezi cílovým kontejnerem a kontejnerem sidecar prostřednictvím připojení svazku. Můžete to udělat například tak, že kontejnery sdílejí společný svazek nebo svazek Kubernetes typu emptyDir. Pokud se pokusíte použít diagnostické nástroje z kontejneru sajdkára bez sdílení adresáře /tmp, zobrazí se chyba, že proces „neběží s kompatibilním modulem runtime .NET“.

Pokud nechcete sdílet obor názvů procesů a adresář /tmp , mnoho nástrojů také podporuje pokročilejší --diagnostic-port možnost příkazového řádku. To vám umožní přímo zadat cestu k diagnostickému portu cílového procesu v rámci souborového systému hostitele nebo vedlejšího kontejneru. Adresář /tmp cílového kontejneru bude potřeba namapovat na nějaké místo, aby tato cesta existovala, ale nemusí se sdílet s hostitelem ani sidecar kontejnerem /tmp.

Poznámka:

I když spustíte diagnostické nástroje z hostitele nebo pomocného kontejneru, může být po cílovém procesu stále požadováno, aby vykonával činnost, což zvyšuje využití prostředků uvnitř cílového kontejneru. Zjistili jsme, že dotnet-dump může způsobit, že cílový proces při shromažďování výpisu paměti načte do paměti značné množství virtuální paměti. Jiné nástroje mohou mít menší vliv, ale neviděli jsme, že by v praxi způsobovaly problémy. Například dotnet-trace požaduje, aby cílový proces přidělil pufr pro události a dotnet-counters požaduje malou oblast paměti, kde jsou agregována data metrik. Doporučujeme otestovat, abyste zajistili, že limity paměti nejsou tak těsné, že spuštění nástrojů způsobí ukončení kontejnerů operačním systémem.

Poznámka:

Při dotnet-dump zápisu souboru s výpisem na disk se výstupní cesta interpretuje v kontextu pohledu cílového procesu na systém souborů. To se může lišit od hostitelského kontejneru nebo od sidecar kontejneru.

Použití PerfCollect v kontejneru

Tento nástroj se vztahuje na: ✔️ .NET Core 2.1 a novější verze

Skript PerfCollect je užitečný pro shromažďování trasování výkonu, které obsahují události jádra, jako jsou vzorky procesoru nebo kontextové přepínače. Při použití PerfCollect v kontejneru mějte na paměti následující požadavky:

• PerfCollect vyžaduje další možnosti pro spuštění perf nástroje. Minimální požadovaná sada funkcí je PERFMON a SYS_PTRACE. Některá prostředí vyžadují SYS_ADMIN. Nezapomeňte kontejner spustit s potřebnými možnostmi. Pokud minimální sada nefunguje, zkuste použít úplnou sadu.

• PerfCollect vyžaduje, aby se před spuštěním aplikace, kterou profiluje, nastavily některé proměnné prostředí. Můžete je nastavit buď v souboru Dockerfile , nebo při spuštění kontejneru. Vzhledem k tomu, že tyto proměnné by neměly být nastavené v normálních produkčních prostředích, je běžné je při spuštění kontejneru, který bude profilovaný, jednoduše přidat. Mezi dvě proměnné, které perfCollect vyžaduje, patří:

  • DOTNET_PerfMapEnabled=1
  • DOTNET_EnableEventLog=1

Poznámka:

Při spouštění aplikace s .NET 7 musíte také nastavit DOTNET_EnableWriteXorExecute=0 kromě předchozích proměnných prostředí.

Použití PerfCollect v kontejneru sajdkáře

Pokud chcete spustit PerfCollect v jednom kontejneru a profilovat proces .NET v jiném kontejneru, prostředí je téměř stejné. Rozdíly jsou:

• Proměnné prostředí uvedené dříve (DOTNET_PerfMapEnabled a DOTNET_EnableEventLog) musí být nastaveny pro cílový kontejner (ne pro ten spuštěný PerfCollect).
• Spuštěný kontejner PerfCollect musí mít SYS_ADMIN schopnost (nikoli cílový kontejner).
• Dva kontejnery musí sdílet obor názvů procesu.