.NET 容器环境下创建应用 dump 文件
Intro
有时候我们的应用会出现一些异常的情况,比如内存飙升,线程死锁等等,通过一些 metrics 我们可能大概的了解内存是增长了,但是具体是哪里增长了,单单看内存的变化很难看出来哪里导致的内存变化,所以很多时候我们还是需要对应用进行 dump,通过分析应用 dump 文件来进一步分析是哪里出现的问题。
Prepare
在容器中进行 dump 的时候我们需要 Linux 中的 SYS_PTRACE
权限,所以需要在部署或运行容器的时候指定一下(默认是没有的)
如果你是直接用
docker run
执行的话可以在执行docker run
的时候指定docker run --cap-add=SYS_PTRACE
如果你使用 docker compose 来运行,可以在
docker-compose.yml
配置文件中配置cap_add
,下面是一个示例version: '2.1' services:reservation:build:context: .dockerfile: Dockerfilecontainer_name: reservationcap_add:- SYS_PTRACE
如果你在 k8s 中使用,需要在 k8s 的 yaml 文件中配置,示例如下:
apiVersion: apps/v1 kind: Deployment metadata:name: sparktodo-apilabels:app: sparktodo-api spec:replicas: 1revisionHistoryLimit: 0template: spec:containers:- name: sparktodo-apiimage: weihanli/sparktodo-api:latestimagePullPolicy: IfNotPresentresources:requests:memory: "64Mi"cpu: "20m"limits:memory: "128Mi"cpu: "50m"ports:- containerPort: 80 + securityContext: + capabilities: + add: ["SYS_PTRACE"]
我们也可以在容器中检测是否已经开启了 SYS_PTRACE
权限,可以通过命令 capsh --print
来查看已经配置的权限,如果提示命令不存在,则需要安装一个 package,alpine 安装 libcap
,Ubuntu 安装 libcap2-bin
# alpine
apk add libcap# ubuntu
apt-get install libcap2-bin
createdump
createdump
是随着 .NET Core runtime 一起发布的一个创建 dump 的一个工具,createdump
可以收集托管信息和 Native 信息,默认 createdump
会创建一个 mini dump,会创建一个比较小的一个 dump,仅包含一些必要的托管信息和堆栈信息,我们也可以通过参数来控制生成全量的 dump(full dump),全量 dump 生成的 dump 文件会比较大,但是包含的信息会比较多,内存中所有的信息都会包含在内。mini dump 没有 full dump 包含那么多有用的信息,所以大小会比较小,通常你请别人帮忙分析 dump 的时候都是选择 full dump。
createdump
一般位于 /usr/share/dotnet/shared/Microsoft.NETCore.App/<version>/createdump
使用起来直接用 createdump <pid>
就可以了,默认会创建一个 minidump
,如果要创建一个 full dump,需要指定参数,createdump <pid> -u
或者 createdump <pid> --full
-f, --name - dump path and file name. The %p, %e, %h %t format characters are supported. The default is '/tmp/coredump.%p'
-n, --normal - create minidump.
-h, --withheap - create minidump with heap (default).
-t, --triage - create triage minidump.
-u, --full - create full core dump.
-d, --diag - enable diagnostic messages.
我们可以使用下面的格式来作为 dump 文件中的占位符:
%% A single % character.
%d PID of dumped process (for backwards createdump compatibility).
%p PID of dumped process.
%e The process executable filename.
%h Hostname return by gethostname().
%t Time of dump, expressed as seconds since the Epoch, 1970-01-01 00:00:00 +0000 (UTC).
dotnet diagnostics tool
微软提供了一系列的 dotnet 诊断工具可以帮助我们诊断应用程序中的问题,
dotnet-counters
: 一个性能监视工具,用于初级运行状况监视和性能调查dotnet-dump
: 可在不使用本机调试器的情况下收集和分析 Windows 和 Linux 的 Core Dumpdotnet-gcdump
: 可用于为活动 .NET 进程收集 GC dumpdotnet-trace
: 可以使用来自应用的有意思的分析数据,分析数据通过 .NET Core 中的EventPipe
公开,这些数据可帮助你分析应用运行缓慢的根本原因。dotnet-stack
: 可以快速打印正在运行的 .net 进程中的所有线程的托管堆栈
可以使用安装 global tool 的方式安装,在运行时容器中安装 dotnet tool 可以参考之前一篇文章介绍,借助多阶段构建来方便的安装 dotnet tool,示例 dockerfile 如下:
FROM mcr.microsoft.com/dotnet/aspnet:5.0-alpine AS base
# https://www.abhith.net/blog/docker-sql-error-on-aspnet-core-alpine/
RUN apk add icu-libs
ENV DOTNET_SYSTEM_GLOBALIZATION_INVARIANT false
# use forward headers
ENV ASPNETCORE_FORWARDEDHEADERS_ENABLED=true
LABEL Maintainer="WeihanLi"
EXPOSE 80FROM mcr.microsoft.com/dotnet/sdk:5.0-alpine AS build-env
WORKDIR /app# 安装 dotnet tool
RUN dotnet tool install --global dotnet-dump
RUN dotnet tool install --global dotnet-gcdump
RUN dotnet tool install --global dotnet-countersCOPY SparkTodo.Shared/SparkTodo.Shared.csproj SparkTodo.Shared/
COPY SparkTodo.API/SparkTodo.API.csproj SparkTodo.API/
RUN dotnet restore SparkTodo.API/SparkTodo.API.csproj# copy everything and build
COPY . .WORKDIR /app/SparkTodo.API
RUN dotnet publish -c Release -o out# build runtime image
FROM base AS final# 从前面的 SDK 镜像中拷贝 dotnet tools 到 runtime 镜像中
COPY --from=build-env /root/.dotnet/tools /root/.dotnet/tools
# 设置 PATH 以方便使用
ENV PATH="/root/.dotnet/tools:${PATH}"WORKDIR /app
COPY --from=build-env /app/SparkTodo.API/out .
ENTRYPOINT ["dotnet", "SparkTodo.API.dll"]
你也可以按照上面的方式安装自己想要安装的 dotnet tool,按上面安装之后我们就可以直接使用 dotnet-dump
/dotnet-gcdump
/dotnet-counters
命令了
dump 之旅
container for test
了解一些基础知识之后,我们就来开始创建 dump 吧,示例应用在 Github 上 https://github.com/WeihanLi/SparkTodo,你可以下载这个应用来做尝试,或者在自己的应用上来试验
首先我们 build 一个 docker 镜像,在项目根目录执行 docker build -t sparktodo-api .
来构建镜像
镜像构建好之后,运行一个容器来进行测试
docker run -d --name sparktodo-api --cap-add=SYS_PTRACE sparktodo-api
容器运行成功之后,可以使用下面的命令进入到容器中,出现下图提示则成功的进入容器中了
docker exec -it sparktodo-api sh
Createdump
首先我们来使用自带的 createdump
来创建一个应用的 dump,
有两种方式找到我们的 createdump
,
我们可以先切换目录到 /usr/share/dotnet/shared/Microsoft.NETCore.App
,然后 ls
查看当前的 runtime 版本,切换到版本目录下即可找到 createdump
另外一种方式,我们可以通过 dotnet --info
来查看当前 runtime 版本,然后直接切换到对应的 /usr/share/dotnet/shared/Microsoft.NETCore.App/<dotnet-version>
目录下即可
通常情况下,我们的容器中只有一个进程,进程 Id 为 1的进程通常就是我们的应用进程,如果不确定的话也可以使用 ps -ef
命令来查看当前的进程信息
可以看到,PID 为 1 的进程就是我们的应用所在的进程,然后就可以通过下面的命令来创建 dump 了
./createdump 1 -u
看到这样的提示,我们的 dump 就创建成功了,这样我们可以使用 LLDB 或者 dotnet-dump 进行 dump 分析了
dotnet-dump
dotnet-dump
是微软提供的一个很方便的 dump 分析和收集工具,dotnet-dump
只能分析托管代码,但是绝大部分场景下对我们来说已经足够了,而且 dotnet-dump
是一个 dotnet tool,可以在各个平台下提供完全一致的体验,不像 LLDB 每个系统的安装方式可能都不一样,安装的版本也可能不同,不如 dotnet-dump
体验良好
首先我们可以使用 dotnet-dump ps
来查看可以进行 dump 的 dotnet 进程,然后使用 dotnet-dump collect -p <pid>
来创建 dump 文件
dotnet-gcdump
dotnet-gcdump
也是微软提供的一个用来分析应用程序问题的 dotnet tool,dotnet-dump
创建的 dump 会比较大,包含除了 gc 之外的其他信息,比如 lock 情况,线程堆栈信息等,使用 dotnet-gcdump
创建的 dump 仅包含 gc 堆的信息,dump 文件会小很多,并且 gcdump 文件可以直接用 VS 打开,可以比较方便的查看 GC 内存占用信息,dotnet-gcdump
的使用和 dotnet-dump
类似,并且新版本(.NET 5.0)的 dotnet-gcdump
可以通过 dotnet-gcdump report -p <pid>
直接从某一个进程导出 GC 内存使用信息
通过 dotnet-gcdump collect -p <pid>
来创建 GC dump 文件
More
容器中的 dump 生成之后可以通过 docker cp
(k8s 中可以用 kubectl cp
)将 dump 文件拷贝到本地来进行分析,新版本的 dump 文件可以直接使用 VS 打开
微软的官方文档真的是一个宝库,有很多很不错的文档,关于 dotnet 诊断工具也有几篇很有用的介绍,没事的时候看看文档,说不定就能发现宝藏~~
References
https://docs.microsoft.com/en-us/dotnet/core/diagnostics/debug-linux-dumps
https://www.programmersought.com/article/81354675797/#dotnetdotnetdump_45
https://man7.org/linux/man-pages/man7/capabilities.7.html
https://stackoverflow.com/questions/43621959/how-can-i-find-out-which-capabilities-a-container-has-been-given
https://stackoverflow.com/questions/38758627/how-can-we-add-capabilities-to-a-running-docker-container
https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities
https://stackoverflow.com/questions/6903329/minidump-vs-fulldump
https://github.com/dotnet/diagnostics/blob/main/documentation/design-docs/dotnet-tools.md
https://github.com/WeihanLi/SparkTodo