故障排查

在容器中调用华为云 OBS 时，请求在 DNS 解析成功后长时间没有响应，最终超时。相同 endpoint 从 Pod 的 host network 访问可以正常返回 403，因此问题集中在容器网络路径，而不是 OBS 服务本身。 先看服务端日志 失败容器的 runtime 日志有一条很重要的时间线： Endpoint=https://obs.cn-north-4.myhuaweicloud.com:443/ internet host address: phoenix-autotest.obs.cn-north-4.myhuaweicloud.com/123.60.240.82, phoenix-autotest.obs.cn-north-4.myhuaweicloud.com/123.60.240.83 这说明 DNS 解析已经完成。之后没有 HTTP 状态码，也没有 OBS 的业务异常。因此，失败点位于 DNS 之后、HTTP 响应之前，更接近 TCP/TLS，而不是 bucket、路径或签名参数。 产品的华为云插件确实直接使用 OBS SDK： this.obsClient = new ObsClient( settings.accessKeyId(), settings.secretAccessKey(), settings.endpoint()); 目录操作会调用 listObjects。在本机使用相同的 OBS 配置和 SDK 3.25.10 重放，接口可以正常返回。因此没有证据表明 AK/SK 或配置错误。 对照不同网络路径 运行服务的 Pod 使用 DinD sidecar： DOCKER_HOST: unix:///var/run/docker/docker.sock Phoenix 容器位于 DinD 的 bridge 网络中。在同一个 Pod 中做只读 HTTPS 探测，结果非常明确： ...

自动化测试使用 Playwright、Testcontainers 和 Docker-in-Docker。测试运行一段时间后，talos2 会从 Kubernetes 中消失，iDRAC 报告 System CPU Resetting，对应的测试分片失败。 这次调查最终拿到了完整的内核 panic 栈。直接原因不是硬件 reset，也不是 pid_max 耗尽，而是 Linux 6.18 中 PAGE_TABLE_CHECK 对 time namespace 的 VVAR 页面错误记账，触发了 BUG_ON()。 最初看到的现象 高并发 testcontainers 场景下，监控 Pod 观察到： loadavg=90+ pids=6890 threads=12513 dstate_count=6 eBPF 还记录到一分钟内大量进程和网络命名空间操作： fork_parent[runc]: 1597 fork_parent[containerd-shim]: 1209 fork_parent[dockerd]: 779 netns operations: 1303 unshare: 38 同时出现两类 D-state 栈。一类在网络命名空间清理路径： rcu_barrier netdev_run_todo default_device_exit_batch ops_undo_list cleanup_net process_scheduled_works worker_thread 另一类在容器文件清理路径： folio_wait_bit_common folio_wait_writeback truncate_inode_partial_folio truncate_inode_pages_range xfs_fs_evict_inode evict do_unlinkat __x64_sys_unlinkat 这些现象很容易让人得出一个合理但不完整的结论：高并发容器创建、删除导致 netns、workqueue、XFS 和 NVMe 同时拥塞，最后触发 hard lockup。 ...

客户环境出现 MySQL 执行 SQL 超时：连接可以建立，简单查询大多正常，但应用复用同一个数据库连接执行多次查询后，会逐渐卡住并最终超时。 相同查询直接在 Navicat 中执行却是正常的。一开始容易怀疑慢 SQL、连接池或数据库负载，但数据库侧没有对应的慢查询和异常。检查网络配置后发现，客户将服务器网卡 MTU 从默认的 1500 改成了 8192。 根因 8192 属于巨帧配置。只有服务器、交换机、路由设备和对端链路都支持相同或更大的 MTU 时，巨帧才能正常工作。 这次链路中仍存在 1500 MTU 的设备。较大的 MySQL 响应包无法被路径正确转发，造成部分数据包丢失；TCP 重传后，应用层最终表现为 SQL 执行超时。 这也解释了为什么： Navicat 的单次查询正常 同一数据库连接连续执行多次查询后更容易超时 返回结果较大时更容易触发 数据库本身没有明显异常 处理 将网卡 MTU 恢复为 1500 后，超时现象消失。 巨帧不是单机优化项。调整 MTU 前，应确认网络路径全链路支持，并在变更后覆盖长连接、多次查询和大结果集等实际业务场景。遇到“单次查询正常、复用连接后超时”的问题时，除了查 SQL 和数据库，也应检查 MTU 是否一致。

线上有些问题很像“应用突然消失”：访问不到页面，应用日志里没有明显异常，服务却不断重启进程。遇到这种情况，Windows Event Log 往往比应用日志更早给出方向。 本文记录一次 .NET 应用 Stack Overflow 的排查过程。重点不在某个具体插件，而在于如何从一条异常码逐步缩小到具体的方法。 先从异常码确认方向 问题最初表现为应用无法访问，同时能看到大量应用异常退出，以及保活机制不断重启应用的日志。 Event Log 中有一条关键记录： Exception code: 0xc00000fd 在 Windows 中，0xc00000fd 通常对应栈溢出（STATUS_STACK_OVERFLOW）。 先拿到 dump，不要急着下结论 在 .NET 5 及更高版本中，可以参考 .NET 的 Stack Overflow 调试文档，让进程生成 dump。现场排查时，可以先让管理员权限启动相关服务，然后收集控制台输出；如果仍然需要更完整的现场信息，可以配置生成 mini dump。 拿到 dump 后使用 dotnet-dump 加载： dotnet-dump analyze .\dump.6012.dmp 一个容易踩到的坑是：加载完成后直接执行 crashinfo、printexception 或 clrstack，可能看不到有价值的信息： > crashinfo ERROR: No crash info to display > pe There is no current managed exception on this thread 这并不表示 dump 没有问题。Stack Overflow 发生时，运行时可能来不及建立普通异常上下文；排查重点应该转向线程状态和栈帧本身。 ...