生產環境(基於docker)故障排除？ 有感於部落格園三番五次翻車
- 2019 年 10 月 3 日
- 筆記
前言
如題，有感於部落格園最近多次翻車，感覺像鬍子眉毛一把抓， 定位不了生產環境的問題。
拋開流程問題，思考在生產環境中如何做故障排除， 發現部落格園裡面這方面的文章比較少。
.Net 本身是提供了sos.dll工具幫助我們在生產中故障排除，通過提供有關內部公共語言運行時（CLR）環境的資訊，幫助您在Visual Studio和Windows調試器（WinDbg.exe）中調試託管程式。
頭腦風暴
故障排除的核心是：調試待分析進程的dump文件
常規思路
① ps aux 找到待分析進程PID
② .netcore runtime自帶createdump工具
③ 執行 ./createdump -f -u {PId} 命令導出coredump文件，默認生成 /tmp/coredump.%d dump文件， 使用Visual Studio 或者Windebug調試dump文件
容器中遇到的障礙
- .netcore app容器中需要有容器特權模式才能執行createdump命令， 否則會如下圖錯誤
ps：可通過在docker run 生成該容器時增加–privileged = true操作特權
-
常規.netcore app容器內不包含ps命令， 難以明確容器內dotnet 進程PID
-
容器內導出的coredump文件，還需要使用 docker cp 命令導出到docker 主機，再行調試。
針對容器內.NetCore app生產調試，國外大牛已經針對 .NetCore特定runtime版本製成了工具鏡像
Analyze running container
以下假設待分析容器使用的.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文件
