如題,有感於博客園最近屢次翻車,感受像鬍子眉毛一把抓, 定位不了生產環境的問題。html
拋開流程問題,思考在生產環境中如何作故障排除, 發現博客園裏面這方面的文章比較少。git
.Net 自己是提供了sos.dll工具幫助咱們在生產中故障排除,經過提供有關內部公共語言運行時(CLR)環境的信息,幫助您在Visual Studio和Windows調試器(WinDbg.exe)中調試託管程序。github
故障排除的核心是:調試待分析進程的dump文件 docker
① ps aux 找到待分析進程PIDshell
② .netcore runtime自帶createdump工具bash
③ 執行 ./createdump -f -u {PId} 命令導出coredump文件,默認生成 /tmp/coredump.%d dump文件, 使用Visual Studio 或者Windebug調試dump文件網絡
ps:可經過在docker run 生成該容器時增長--privileged = true操做特權app
常規.netcore app容器內不包含ps命令, 難以明確容器內dotnet 進程PID工具
容器內導出的coredump文件,還須要使用 docker cp 命令導出到docker 主機,再行調試。this
針對容器內.NetCore app生產調試,國外大牛已經針對 .NetCore特定runtime版本製成了工具鏡像
如下假設待分析容器使用的.netcore runtime與6opuc/lldb-netcore 工具鏡像內runtime 相同。
1.找到待分析容器id (docker ps),例如: b5063ef5787c
2.運行包含createdump工具的容器(須要sys_admin,sys_ptrace特權), 若是運行的容器已經包含這個特權,可附加待分析容器並在容器中執行createdump工具
docker run --rm -it --cap-add sys_admin --cap-add sys_ptrace --net=container:b5063ef5787c --pid=container:b5063ef5787c -v /tmp:/tmp 6opuc/lldb-netcore /bin/bash
--net=container:b5063ef5787c 重用待分析容器的網絡堆棧
--pid=container:b5063ef5787c 加入待分析容器的PID命名空間
3. 找到待分析dotnet進程PID: px aux
4. 生成dotnet進程的 coredump文件,並退出容器
createdump -u -f /tmp/coredump 7 # 7是dotnet進程id exit
5. 使用debugger打開coredump文件
docker run --rm -it -v /tmp/coredump:/tmp/coredump 6opuc/lldb-netcore
output:
(lldb) target create "/usr/bin/dotnet" --core "/tmp/coredump" Core file '/tmp/coredump' (x86_64) was loaded. (lldb) plugin load /coreclr/libsosplugin.so (lldb) sos PrintException There is no current managed exception on this thread (lldb)
6. 在lldb shell : help命令繼續探索
lldb使用方式可參考https://docs.microsoft.com/en-us/dotnet/framework/tools/sos-dll-sos-debugging-extension
該DockerHub Repo還提供了基於docker 生產故障排除的常見用例:
這個鏡像對於基於容器的故障排除至關有用,不敢自稱原創鏡像;
分享給你們, 但願園友經過經歷生產環境的故障排除,進階爲資深研發。
+ dotnet core調試docker下生成的dump文件
原文出處:https://www.cnblogs.com/JulianHuang/p/11365593.html