通过

实验室 1.1 重现并排查崩溃问题

适用于： .NET Core 2.1、.NET Core 3.1、.NET 5

本文介绍在 Linux 中重现 .NET Core 崩溃问题的过程。 本文还讨论了如何检查 Nginx 工具和系统日志，了解故障的症状和指示。

先决条件

遵循这些故障排除实验室的最低要求是有一个 ASP.NET 核心应用程序来演示低 CPU 和高 CPU 性能问题。

可以在 Internet 上找到多个示例应用程序来实现此目标。 例如，可以下载并设置 Microsoft的简单 Webapi 示例 ，以演示不良行为。 或者，可以将 BuggyAmb ASP.NET Core 应用程序用作示例项目。

如果已遵循本系列的上一部分，则应准备好进行以下设置：

  • Nginx 配置为托管两个网站：
    • 第一个使用 myfirstwebsite 主机标头 （http://myfirstwebsite） 侦听请求，并将请求路由到在端口 5000 上侦听的演示 ASP.NET Core 应用程序。
    • 第二个使用 buggyamb 主机标头 （http://buggyamb） 侦听请求，并将请求路由到侦听端口 5001 的第二个 ASP.NET 核心示例 buggy 应用程序。
  • ASP.NET Core 应用程序应作为服务运行，这些服务会在服务器重启或应用程序停止响应时自动重启。
  • Linux 本地防火墙已启用并配置为允许 SSH 和 HTTP 流量。

注意

如果设置尚未准备就绪，请转到“第 2 部分创建并运行 ASP.NET Core 应用”。

若要继续此实验室，必须在 Nginx 后面运行至少一个有问题的 ASP.NET Core Web 应用程序。

本实验室的目标

本文是两个实验室部件中的第一部分。 实验室工作分为以下部分：

  • 第 1 部分：你将重现崩溃问题，检查 Nginx 和系统日志以搜索崩溃症状和指示器，然后通过生成故障转储文件进行故障排除。 最后，你将从 Ubuntu 管理器 apport 生成的崩溃报告中收集系统生成的核心转储文件。

  • 第 2 部分：将安装和配置 lldb，以便与名为 SOS 的 .NET Core 调试器扩展协同工作。 你还将分析 lldb 中的转储文件。

重现崩溃问题

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

网站崩溃信息的屏幕截图。

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

输出信息的屏幕截图。

页面应快速加载（不到一秒钟），并显示产品列表。

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

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

服务信息的屏幕截图。

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

崩溃 3 信息的屏幕截图。

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

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

慢速命令的屏幕截图。

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

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

service2943 信息的屏幕截图。

对重现步骤进行故障排除

下面是重现步骤的摘要：

  1. 选择 “崩溃 3”。 页面正确加载，但返回一条令人困惑的消息，表明进程将崩溃。
  2. 选择“ 慢”。 收到“HTTP 502 - 错误的网关”错误消息，而不是产品表。
  3. 问题开始后，所有页面都不会在接下来的 10-15 秒内呈现。
  4. 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 与 buggy 应用程序之间的连接已关闭。

错误信息的屏幕截图。

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

使用 journalctl 命令检查系统日志

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

由于 buggy 应用程序作为系统服务运行，因此其操作将记录在系统日志文件中。 系统日志文件类似于 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。 应注意到会生成一些警告消息。

cat 命令的屏幕截图。

若要查看详细信息，请使用箭头键向下滚动。 你将发现异常 System.Net.WebException 。

Webexception 信息的屏幕截图。

如果仔细检查日志，将看到代码文件名和发生问题的行号。 对于此实验室，我们将假定此信息不可用。 这是因为，在实际方案中，可能无法检索此类信息。 因此，目标是通过分析故障转储来继续学习崩溃的原因。

崩溃后获取核心转储文件

回忆一下进程终止时的一些关键系统行为：

  • 默认情况下，将生成核心转储文件。
  • 核心转储命名为 核心 ，在当前工作文件夹或 /var/lib/systemd/coredump 文件夹中创建。

尽管默认行为是让系统生成核心转储文件，但可以覆盖 /proc/sys/kernel/core_pattern 此设置，以便将生成的核心转储文件直接传递给另一个应用程序。 在本系列的上一部分中使用 Ubuntu 时，你了解了 apport 管理 Ubuntu 中的核心转储文件生成。 文件 core_pattern 将被覆盖，以通过管道将核心转储传递给 apport。

核心信息的屏幕截图。

Apport 使用 /var/crash 文件夹来存储其报表文件。 如果检查此文件夹，应会看到崩溃后已生成的文件。

varcrash 信息的屏幕截图。

但是，这不是核心转储文件。 这是一个报告文件，其中包含多个信息片段以及转储文件。 必须解压缩此文件才能获取核心转储文件。

在主文件夹下创建转储文件夹。 系统会指示你提取报表。 用于解压缩 apport 报表文件的命令为 apport-unpack。 运行下面的命令：

sudo apport-unpack /var/crash/_usr_share_dotnet_dotnet.33.crash ~/dumps/dotnet

此命令创建 /dumps 文件夹。 此命令 apport-unpack 将创建 /dumps/dotnet 文件夹。 下面是结果。

sudo 命令的屏幕截图。

在 ~/dumps/dotnet 文件夹中，应会看到转储文件。 该文件名为 CoreDump，应约为 191 MB。

转储命令的屏幕截图。

提取自动生成的核心转储文件可能是一个繁琐的过程。 在下一个实验室中，你将看到使用核心转储文件 createdump更容易捕获。

后续步骤

实验室 1.2 在 lldb 调试器中打开和分析系统生成的核心转储文件，你将了解如何在 lldb 调试器中打开此转储文件以执行快速分析。

  • Last updated on