故障排查

在容器中调用华为云 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。 ...

我们的端到端测试是一个由 Playwright、Testcontainers 和容器运行时组成的多层工作流。 测试工作流 每个 Playwright worker 通过 Testcontainers 管理一组相互隔离的容器和 bridge network。启动前会清理残留资源，测试期间按需启动浏览器、应用和数据库，结束后再停止并删除容器和网络。 清理残留资源 -> 创建 network 和容器 -> 执行浏览器测试 -> stop/remove 容器 -> remove network 这些操作都由 Testcontainers 通过连接 podman Docker 兼容 API 完成， worker 的 teardown 会让 stop、remove、network remove 与容器状态查询交错执行，这正是本次调查关注的并发场景。 实验条件 为了避免大型业务镜像的启动成本和业务行为干扰测试，只使用了一个小镜像： 工作负载：busybox:1.36.1 Podman：quay.io/podman/stable:v5.8.2-immutable Docker：docker:dind，Docker Engine 29.7.2 每轮 24 个并发操作，共 5 轮 两个运行时均运行在 privileged 容器内，状态目录使用 4 GiB tmpfs 每个并发操作创建 bridge network，创建并启动一个 busybox 容器，然后执行 stop、remove 和 network remove。teardown 阶段同时发起 24 个 GET /containers/json?all=1 请求，并持续采样 containers-list、/info 和 /_ping。 ...

线上有些问题很像“应用突然消失”：访问不到页面，应用日志里没有明显异常，服务却不断重启进程。遇到这种情况，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 发生时，运行时可能来不及建立普通异常上下文；排查重点应该转向线程状态和栈帧本身。 ...