重新整理 .net core 实践篇 ———— linux上排查问题实用工具 [外篇] _生活百科

前言介绍下面几个工具:
Lldbcreatedumpdotnet-dumpdotnet-gcdumpdotnet-symbolProcdump
该文的前置篇为:
https://www.cnblogs.com/aoximin/p/16839812.html
献给初学者，这篇就只介绍下看下日志和lldb，毕竟东西太多了。
正文我以官网的例子作为演示：https://buggyambfiles.blob.core.windows.net/bin/buggyamb_v1.1.zip
项目地址:https://github.com/ahmetmithat/buggyamb
我这里就已经发布可以访问了，并且用户nginx 作为转发，已经启动起来了。
步骤在前面两篇，如果看需要发布的，可以往前面两篇看看，这里就不多复述了。
[Unit]Description=BuggyAmb[Service]WorkingDirectory=/var/buggyambExecStart=/usr/bin/dotnet /var/buggyamb/BuggyAmb.dllRestart=awaysRestartSec=10SyslogIdentifier=BuggyAmbUser=rootEnvironment=ASPNETCORE_ENVIRONMENT=DevelopmentEnvironment=DOTNET_PRINT_TELEMETRY_MESSAGE=falseEnvironment=ASPNETCORE_URLS=http://0.0.0.0:6000[Install]WantedBy=multi-user.targetservice 的配置如上。
页面测试如下：

文章插图
里面分别是：
慢、处理异常、不处理异常、崩溃、未找到页面、批处理
崩溃情况这种比较好排查的，其实一般看日志就行。
我这里点一下Crash2，让程序崩溃。这里说明一下，上面我用的是官方例子，直接可以看代码怎么崩溃的哈。

public class Crash2Model : PageModel{	public string quote;	~Crash2Model()	{if (quote.ToString() != string.Empty){quote = null;}	}	public void OnGet()	{	}}

这个可以看下。
那么我们进行日志排查一下错误。
journalctl -r --identifier=BuggyAmb --since "10 minute ago"

文章插图

文章插图
告诉我们15行错误。

-r：按反向顺序打印日志，以便首先列出最新日志 。--identifier：请记住 SyslogIdentifier=buggyamb-identifier 测试应用程序的服务文件中的行 。(可以使用此方法强制日志仅显示适用于有问题的应用程序的条目 。)--since：显示在指定的上一时期记录的信息 。示例： --since "10 minute ago" 或 --since "2 hour ago".

journalctl 还有很多其他的功能，这里就不一一举例了。
核心转储centos 默认不开启的:
可以看下这个怎么开启的：
https://blog.csdn.net/ProgramVAE/article/details/105921381

#!/bin/bash#me: coredumpshell.sh### Description: enable coredump and format the name of core file on centos system# enable coredump whith unlimited file-size for all usersecho -e "\n# enable coredump whith unlimited file-size for all users\n* soft core unlimited" >> /etc/security/limits.conf# set the path of core file with permission 777cd /var/buggyamb && mkdir corefile && chmod 777 corefile# format the name of core file.# %% – 符号%# %p – 进程号# %u – 进程用户id# %g – 进程用户组id# %s – 生成core文件时收到的信号# %t – 生成core文件的时间戳(seconds since 0:00h, 1 Jan 1970)# %h – 主机名# %e – 程序文件名echo -e "/var/buggyamb/corefile/core-%e-%s-%u-%g-%p-%t" > /proc/sys/kernel/core_pattern# for centos7 system(update 2017.2.3 21:44)echo -e "/var/buggyamb/corefile/core-%e-%s-%u-%g-%p-%t" > /etc/sysctl.conf# suffix of the core file nameecho -e "1" > /proc/sys/kernel/core_uses_pid

运行之后就开启了。
centos 一般用不上，我也没有去调试过，这里就不演示了，只能说有这种东西。
使用lldb安装：yum install lldb
前文提及到这个要安装lldb 3.9 以上的。
按照这个文档来编译安装也行:
https://github.com/dotnet/diagnostics/blob/main/documentation/lldb/linux-instructions.md
在 lldb 中打开核心转储文件之前，请按照以下必需步骤设置符号路径，下载符号，并在打开 lldb 时自动加载 SOS ：
安装 dotnet 符号工具：
dotnet tool install -g dotnet-symbol
下载目标转储文件的符号：
dotnet-symbol <path_of_dump_file>
安装 SOS：
安装 dotnet-sos 全局工具：
dotnet tool install -g dotnet-sos
安装 SOS：
dotnet-sos install
最后成功的样子:

文章插图
使用createdump:
Createdump 会与每个 .NET Core 运行时一起自动安装。
如创建的ump 配置策略文档中所述，可以设置具有环境变量的配置选项。这些将作为参数传递给创建的ump 命令。下面是支持的环境变量：
COMPlus_DbgEnableMiniDump：如果设置为 1，则在终止时启用自动核心转储生成。默认值为 0。COMPlus_DbgMiniDumpType：这是将要创建的微型转储文件的类型。此值的默认值为 2 (或枚举类型 MiniDumpWithPrivateReadWriteMemory)。这意味着生成的转储文件将包括 GC 堆以及捕获进程中所有现有线程的堆栈跟踪所需的信息。COMPlus_DbgMiniDumpName：如果设置，请用作模板来创建转储文件路径和文件名。可以使用参数将 PID 放入名称中 %d。默认模板为 /tmp/coredump.%d. 通过使用此环境变量，可以配置输出目录。COMPlus_CreateDumpDiagnostics：如果设置为 1，则启用创建的ump 工具诊断消息 (TRACE 宏)。如果 createdump 不能按预期工作并且不生成内存转储文件，则此设置可能很有用。