重现崩溃问题并开始进行故障排除 - ASP.NET Core

此实验室的目标

本文是两个实验室部分中的第一个。实验室工作按如下所示进行划分：

第 1 部分：将重现崩溃问题，检查 Nginx 和系统日志以搜索崩溃症状和指示器，然后通过生成故障转储文件进行故障排除。最后，你将从 Ubuntu 管理器（apport）生成的崩溃报表中收集系统生成的核心转储文件。
第 2 部分：安装并配置 lldb，以便与名为 SOS 的 .NET Core 调试器扩展协同工作。你还将在 lldb 中分析转储文件。

重现崩溃问题

浏览到网站 URL 并 http://buggyamb/ 选择 “问题页 ”链接时，会看到一些问题方案的链接。有三种不同的崩溃方案。但是，对于此实验室，你将仅对第三个崩溃方案进行故障排除。

在选择任何链接之前，请选择 “预期结果 ”，并验证应用程序是否按预期工作。应会看到类似于以下内容的输出。

页面应在不到一秒) 内快速加载 (，并显示产品列表。

若要测试第一个“慢页”方案，请选择 “慢 ”链接。该页面最终将显示与“预期结果”页相同的输出，但呈现速度将比预期慢得多。

在重现崩溃问题之前，请记下越野车应用程序的进程 ID。你将使用此信息来验证应用程序是否重启。运行命令 systemctl status buggyamb.service 以获取当前 PID。在以下结果中，运行服务的进程的 PID 为 2255。

选择 “崩溃 3 ”链接。页面加载并显示以下消息：

此消息要求用户考虑以下问题：此页面是否会导致进程崩溃？运行相同的 systemctl status buggyamb.service 命令，应该会看到相同的 PID。这表示未发生崩溃。

选择 “预期结果 ”，然后选择 “慢 ”。尽管在选择 “预期结果 ”后应看到正确的页面，但选择 “慢 ”应会生成以下错误消息。

即使在网页上选择任何其他链接，也会在一段时间内遇到相同的错误。 10-15 秒后，一切将按预期再次开始响应。

若要检查 PID 是否已更改，请再次运行 systemctl status buggyamb.service 。这一次，你应该注意到，由于 PID 已更改，进程似乎已经停止。在前面的示例中，进程 PID 为 2255。在以下示例中，它已更改为 2943。显然，该网站兑现了其承诺，崩溃的过程。

排查重新处理步骤的问题

下面是重新处理步骤的摘要：
选择 “崩溃 3 ”。页面加载正确，但返回一条令人困惑的消息，指示进程将崩溃。
选择 “慢 ”。你会收到“HTTP 502 - 错误网关”错误消息，而不是产品表。
问题启动后，在接下来的 10-15 秒内不会呈现任何页面。
10-15 秒后，应用程序开始正确响应。

“HTTP 502 - 错误网关”错误消息本身并不能说明问题。但是，它应提供第一个线索：这是一个代理错误，如果代理无法与代理后面运行的应用程序通信，则可能会发生该错误。在建议的设置中，Nginx 充当 ASP.NET Core应用程序的反向代理。因此，Nginx 中的此错误指示它在转发传入请求时无法访问后端应用程序。

验证 Nginx 是否正常工作

在继续之前，可能需要检查 Nginx 是否正常工作。此步骤不是必需的，因为你知道应用程序正在崩溃。但是，仍可以通过检查 Nginx 日志来验证 Nginx 的状态。在前面的 “安装和配置 Nginx” 部分中，你也练习了类似的故障排除步骤。

Nginx 有两种类型的日志：访问日志和错误日志。这些存储在文件夹中 /var/log/nginx/ 。

访问日志与 IIS 日志文件类似。打开并检查它们，就像在上一部分中所做的那样。除了在网站页面导航尝试期间遇到的“HTTP 502”响应状态代码之外，日志不会显示任何新信息。

使用 cat /var/log/nginx/error.log 命令检查错误日志。此日志更有用且更清晰。它显示 Nginx 能够处理请求，但在发送最终响应之前，Nginx 与越野应用程序之间的连接已关闭。

此日志清楚地表明你看到的不是 Nginx 问题。

使用 journalctl 命令检查系统日志

如果 ASP.NET Core应用程序崩溃，则症状应出现在某处。

由于越野车应用程序作为系统服务运行，因此其操作将记录在系统日志文件中。系统日志文件类似于 Windows 中的系统事件日志。该 journalctl 命令用于查看和操作系统化日志。

可以运行命令， journalctl 而无需切换即可查看所有日志。但是，输出将是一个大文件。了解如何筛选内容符合你的最佳利益。例如，可以运行以下命令：

journalctl -r --identifier=buggyamb-identifier --since "10 minute ago"
以下开关可用：
-r：按反向顺序打印日志，以便首先列出最新日志。
--identifier：请记住 SyslogIdentifier=buggyamb-identifier 测试应用程序的服务文件中的行。  (可以使用此方法强制日志仅显示适用于有问题的应用程序的条目。) 
--since：显示在指定的上一时期记录的信息。 示例： --since "10 minute ago" 或 --since "2 hour ago".
对于命令，有几个有用的开关 journalctl 可以帮助你筛选日志。 若要熟悉此命令，我们建议你通过运行 man journalctl来查阅帮助页。
运行 journalctl -r --identifier=buggyamb-identifier --since today -o cat。 应注意，会生成一些警告消息。
若要查看详细信息，请使用箭头键向下滚动。 你会发现异常 System.Net.WebException 。
如果仔细检查日志，将看到代码文件名和出现问题的行号。 对于此实验室，我们假设此信息不可用。 这是因为，在现实场景中，你可能无法检索此类信息。 因此，目的是通过分析故障转储来继续了解崩溃的原因。
崩溃后获取核心转储文件
在进程终止时，请回想一些关键系统行为：
默认情况下，会生成核心转储文件。
核心转储命名为 核心 ，在当前工作文件夹或文件夹中 /var/lib/systemd/coredump 创建。
尽管默认行为是系统生成核心转储文件，但可以覆盖 /proc/sys/kernel/core_pattern 此设置，将生成的核心转储文件直接传送到另一个应用程序。 在本系列的上一部分中使用 Ubuntu 时，你了解到 apport 管理 Ubuntu 中的核心转储文件生成。 该 core_pattern 文件被覆盖以通过管道将核心转储传递到 apport。
Apport 使用 /var/crash 文件夹来存储其报表文件。 如果检查此文件夹，应会看到崩溃后已生成的文件。
但是，这不是核心转储文件。 这是一个报表文件，其中包含几条信息以及转储文件。 必须解压缩此文件才能获取核心转储文件。
在主文件夹下创建转储文件夹。 系统会指示你在其中提取报表。 用于解压缩 apport 报表文件的命令是 apport-unpack。 运行以下命令：
sudo apport-unpack /var/crash/_usr_share_dotnet_dotnet.33.crash ~/dumps/dotnet
此命令创建 /dumps 文件夹。 该 apport-unpack 命令将创建 /dumps/dotnet 文件夹。 结果如下。
在 ~/dumps/dotnet 文件夹中，应会看到转储文件。 该文件名为 CoreDump，应约为 191 MB。
提取自动生成的核心转储文件可能是一个繁琐的过程。 在下一个实验室中，你将看到使用 createdump它更容易捕获核心转储文件。
实验室 1.2 在 lldb 调试器中打开和分析系统生成的核心转储文件，你将了解如何在 lldb 调试器中打开此转储文件以执行快速分析。

此实验室的目标

重现崩溃问题

排查重新处理步骤的问题

验证 Nginx 是否正常工作

使用 journalctl 命令检查系统日志

崩溃后获取核心转储文件