生产环境(基于docker)故障排除？ 有感于博客园三番五次翻车
https://www.cnblogs.com/JulianHuang/archive/2019/08/19/11365593.html
如题，有感于博客园最近多次翻车，感觉像胡子眉毛一把抓， 定位不了生产环境的问题。
抛开流程问题，思考在生产环境中如何做故障排除， 发现博客园里面这方面的文章比较少。
.
Net 本身是提供了相关工具帮助我们在生产中故障排除： https://docs.microsoft.com/en-us/dotnet/framework/tools/sos-dll-sos-debugging-extension
工具的思路是在生产环境中dump出进程快照文件，通过分析快照堆栈、线程信息、异常信息判断运行状态。
这个工具依赖的文件很多很杂，国外大牛已经针对 .NetCore制作了工具镜像
How to Use#
docker run --rm -it -v /stripe/upload/coredump:/tmp/coredump 6opuc/lldb-netcore
- /stripe/upload/coredump - docker宿主机上崩溃进程的coredump文件路径
Usecases#
Analyze running container#
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
-
b5063ef5787c - 待分析的容器id
-
/tmp - 主机上临时目录，coredump 文件将会在此生成
3. 找到待分析dotnet 进程PID
ps aux
这个例子PID 是“7”
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
example 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
General Practices#
该DockerHub Repo还提供了基于docker 生产故障排除的常见用例：
这个镜像对于基于容器的故障排除相当有用，不敢自称原创镜像；
分享给大家， 希望园友通过经历生产环境的故障排除，进阶为资深研发。
码甲拙见，如有问题请下方留言大胆斧正；码字+Visio制图，均为原创，看官请不吝好评+关注， ~。。~
本文欢迎转载，请转载页面明显位置注明原作者及原文链接。
如题，有感于博客园最近多次翻车，感觉像胡子眉毛一把抓， 定位不了生产环境的问题。
抛开流程问题，思考在生产环境中如何做故障排除， 发现博客园里面这方面的文章比较少。
.
Net 本身是提供了相关工具帮助我们在生产中故障排除： https://docs.microsoft.com/en-us/dotnet/framework/tools/sos-dll-sos-debugging-extension
工具的思路是在生产环境中dump出进程快照文件，通过分析快照堆栈、线程信息、异常信息判断运行状态。
这个工具依赖的文件很多很杂，国外大牛已经针对 .NetCore制作了工具镜像
How to Use#
docker run --rm -it -v /stripe/upload/coredump:/tmp/coredump 6opuc/lldb-netcore
- /stripe/upload/coredump - docker宿主机上崩溃进程的coredump文件路径
Usecases#
Analyze running container#
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
-
b5063ef5787c - 待分析的容器id
-
/tmp - 主机上临时目录，coredump 文件将会在此生成
3. 找到待分析dotnet 进程PID
ps aux
这个例子PID 是“7”
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
example 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
General Practices#
该DockerHub Repo还提供了基于docker 生产故障排除的常见用例：
这个镜像对于基于容器的故障排除相当有用，不敢自称原创镜像；
分享给大家， 希望园友通过经历生产环境的故障排除，进阶为资深研发。