Azure Container Apps Debug Console 工具完全指南

在云原生时代，容器化应用的故障排查是每个开发者和运维工程师必须掌握的核心技能。Azure Container Apps 平台提供了一个功能强大的 Debug Console（调试控制台），其中预装了一系列专业的诊断工具，能够帮助你在不修改容器镜像的情况下，快速定位和解决生产环境中的各种问题。本文将深入介绍这些工具的功能特性、使用方法和实际应用场景，助你成为容器故障排查的专家。

---

Debug Console 与普通 Console 的区别

在开始介绍具体工具之前，有必要先了解 Azure Container Apps 提供的两种控制台的区别：

特性	Console (Exec)	Debug Console
运行环境	直接进入你的容器	独立的调试容器
可用工具	仅容器镜像中包含的工具	预装完整的诊断工具集
适用场景	查看应用文件、运行应用命令	网络诊断、系统分析
访问方式	Azure Portal 或 az containerapp exec	az containerapp debug

Debug Console 会创建一个独立的调试容器，与你的应用容器共享底层网络和存储资源，但拥有完整的诊断工具集。这意味着即使你使用的是精简的 distroless 镜像，也能进行全面的故障排查。

---

预装工具概览

Azure Container Apps 的 Debug Console 预装了以下工具包：

工具包	主要用途	典型命令
iputils	网络连通性测试	ping, arping, tracepath
net-tools	传统网络工具集	netstat, ifconfig, route
procps	进程监控和系统状态	ps, top, free, vmstat
lsof	文件和端口占用分析	lsof
util-linux	系统管理实用工具	dmesg, mount, df, kill
netcat	网络连接测试	nc
wget	HTTP/HTTPS 下载和测试	wget
openssl	SSL/TLS 证书诊断	openssl
traceroute	网络路由追踪	traceroute
ca-certificates	CA 证书管理	update-ca-trust
bind-utils	DNS 查询诊断	dig, nslookup, host
tcpping	TCP 端口连通性测试	tcpping

---

1. iputils - 网络连通性测试工具

iputils 是 Linux 系统中用于测试网络连通性的基础工具包，在网络故障排查中扮演着不可或缺的角色。该工具包主要提供 ping、arping 和 tracepath 三个核心命令，分别用于测试 ICMP 层连通性、ARP 层连通性和网络路径追踪。

在容器环境中，网络问题是最常见的故障类型之一。当你的应用无法访问外部服务时，第一步通常是使用 ping 命令验证基本的网络连通性。ping 通过发送 ICMP Echo Request 数据包并等待 Echo Reply 响应，可以快速判断目标主机是否可达以及网络延迟情况。

需要特别注意的是，iputils 包不包含 ip 命令。很多工程师容易混淆这一点，因为包名中包含 “ip” 字样。实际上，ip addr、ip route 等命令来自 iproute2 包，需要单独安装。如果你需要使用这些命令，可以通过 tdnf install -y iproute 进行安装。作为替代方案，Debug Console 预装的 net-tools 包提供了功能相似的传统命令：ifconfig 对应 ip addr，route -n 对应 ip route。

核心命令示例

# 测试主机连通性（发送 4 个数据包）
ping -c 4 portal.azure.cn

# 持续 ping 并设置间隔（每 0.5 秒发送一次，共 10 次）
ping -c 10 -i 0.5 target-host

# ARP 层测试（用于同网段主机，验证 Layer 2 连通性）
arping -c 3 10.0.0.1

# 追踪网络路径（不需要 root 权限，比 traceroute 更安全）
tracepath portal.azure.cn

典型排查场景

当容器无法访问外部服务时，首先使用 ping 测试目标主机是否可达。如果 ping 成功，说明网络层面连通，问题可能在应用层；如果 ping 失败，需要进一步判断是网络配置问题还是防火墙阻止了 ICMP。值得注意的是，很多云服务和企业网络会阻止 ICMP 协议，此时 ping 不通并不代表网络不通，应该使用 tcpping 或 nc 进行 TCP 层测试。

---

2. net-tools - 经典网络工具集

net-tools 是 Linux 系统中历史最悠久的网络工具包之一，包含了 netstat、ifconfig、route、arp 等经典命令。虽然这些工具在技术上已被 iproute2 套件取代，但由于其简洁直观的输出格式和广泛的使用基础，至今仍是许多系统管理员的首选工具。

在容器故障排查中，netstat 是使用频率最高的命令之一。它能够显示网络连接状态、路由表、接口统计等关键信息。通过 netstat -tlnp 可以快速查看容器内所有监听的 TCP 端口，这对于验证应用是否正确启动并监听预期端口至关重要。netstat -ant 则显示所有 TCP 连接的状态，帮助你分析连接数量和状态分布。

ifconfig 命令用于查看和配置网络接口，在 Debug Console 中主要用于查看容器的 IP 地址、子网掩码、MAC 地址等网络配置信息。当你需要确认容器是否获得了正确的 IP 地址，或者检查网络接口是否正常工作时，ifconfig 是最直接的工具。

route 命令用于查看和管理路由表。在容器环境中，路由配置决定了流量如何被转发。通过 route -n（-n 参数避免 DNS 解析，加快输出速度）可以查看默认网关和路由规则，这对于排查"容器能访问同网段但无法访问外部网络"等问题非常有帮助。

核心命令示例

# 查看所有监听的 TCP 端口（t=TCP, l=Listen, n=数字格式, p=进程信息）
netstat -tlnp

# 查看所有 TCP 连接状态
netstat -ant

# 统计各状态的连接数（快速发现连接泄漏）
netstat -ant | awk '{print $6}' | sort | uniq -c

# 查看网络接口配置
ifconfig

# 查看路由表（-n 避免 DNS 解析）
route -n

典型排查场景

当应用启动后无法接收请求时，使用 netstat -tlnp 可以快速确认应用是否在预期端口上监听。如果端口没有监听，问题在应用启动；如果端口正常监听但请求无法到达，问题可能在网络配置或防火墙。另一个常见场景是连接数异常：如果发现大量 TIME_WAIT 状态的连接，可能是短连接过于频繁；如果发现大量 CLOSE_WAIT 状态，通常表示应用没有正确关闭连接，存在连接泄漏问题。

---

3. procps - 进程监控专家

procps 是一组用于监控系统进程和资源使用情况的核心工具包，包含了 ps、top、free、vmstat、pgrep、pkill 等经典命令。这些工具通过读取 /proc 文件系统获取内核提供的进程和系统信息，是性能调优和故障排查的必备工具。

ps 命令用于显示当前进程的快照。在容器环境中，ps auxf 是最常用的组合：a 显示所有用户的进程，u 显示详细信息（用户、CPU、内存等），x 包括没有控制终端的进程，f 以树状格式显示进程关系。通过这个命令可以快速了解容器内运行了哪些进程，以及它们之间的父子关系。

top 命令提供实时的进程监控视图，是排查 CPU 和内存问题的首选工具。它会持续刷新显示系统负载、CPU 使用率、内存使用情况以及各进程的资源消耗。在 Debug Console 中，可以使用 top 然后按 P 键按 CPU 排序，或按 M 键按内存排序，快速定位资源消耗最大的进程。

free 命令显示系统内存使用情况，包括物理内存、交换空间、缓冲区和缓存的使用量。free -h 以人类可读的格式（KB、MB、GB）显示结果，便于快速判断内存是否紧张。在容器环境中，了解内存使用情况对于设置合理的资源限制至关重要。

vmstat 命令提供虚拟内存、进程、CPU 活动的统计信息。通过 vmstat 1 5（每秒采样一次，共 5 次）可以观察系统资源使用的变化趋势，这对于判断是突发性负载还是持续性问题非常有帮助。

核心命令示例

# 查看所有进程（树状显示进程关系）
ps auxf

# 实时监控进程
top

# 查看内存使用情况（人类可读格式）
free -h

# 查看虚拟内存统计（每秒采样，共 5 次）
vmstat 1 5

# 按内存使用排序显示前 20 个进程
ps aux --sort=-%mem | head -20

# 按 CPU 使用排序显示前 20 个进程
ps aux --sort=-%cpu | head -20

典型排查场景

当容器响应变慢时，首先用 top 观察整体资源使用情况。如果 CPU 使用率持续很高，按 P 键找出消耗 CPU 最多的进程；如果内存使用率很高或频繁使用 swap，按 M 键找出内存消耗大户。对于 Java 应用，内存持续增长可能预示着内存泄漏，此时可以结合 free -h 监控内存趋势，并使用 ps aux --sort=-%mem 确认具体是哪个进程在消耗内存。

---

4. lsof - 文件与端口侦探

lsof（List Open Files）是 Linux 系统中功能最强大的诊断工具之一。在 Unix/Linux 的设计哲学中，“一切皆文件”——不仅普通文件是文件，网络连接、管道、设备、目录等都被抽象为文件。因此，lsof 不仅能查看普通文件的打开情况，还能查看网络连接、管道、设备等所有类型的文件描述符。

在容器故障排查中，lsof 最常用于两个场景：一是查看端口占用情况，二是分析文件句柄泄漏问题。当你需要知道某个端口被哪个进程占用时，lsof -i :8080 可以立即给出答案。当应用报告 “Too many open files” 错误时，lsof -p <PID> 可以列出该进程打开的所有文件，帮助你分析是什么类型的文件描述符被大量打开。

lsof 的输出包含丰富的信息：COMMAND（进程名）、PID（进程 ID）、USER（用户）、FD（文件描述符）、TYPE（类型，如 REG 表示普通文件，IPv4/IPv6 表示网络连接）、DEVICE（设备）、SIZE/OFF（大小/偏移）、NODE（节点）、NAME（文件名或网络地址）。通过分析这些信息，可以深入了解进程的文件和网络活动。

核心命令示例

# 查看占用特定端口的进程
lsof -i :8080

# 查看某进程打开的所有文件
lsof -p <PID>

# 统计进程打开的文件数量
lsof -p <PID> | wc -l

# 查看所有网络连接
lsof -i

# 查看所有 TCP 连接
lsof -i TCP

# 查看连接到特定主机的进程
lsof -i @10.0.0.1

# 查看特定用户打开的文件
lsof -u username

典型排查场景

当应用报错 “Too many open files” 或 “Cannot allocate file descriptor” 时，首先使用 lsof -p <PID> | wc -l 统计进程打开的文件数量，然后与系统限制（ulimit -n）对比。如果确实接近或超过限制，使用 lsof -p <PID> 详细查看打开的文件列表。如果发现大量 socket 类型的文件描述符，可能是连接池泄漏；如果发现大量普通文件，可能是日志文件或临时文件没有正确关闭。

---

5. util-linux - 系统管理瑞士军刀

util-linux 是一个庞大的系统管理工具集，包含了数十个实用命令，几乎涵盖了 Linux 系统管理的方方面面。在容器调试场景中，最常用的命令包括 dmesg（查看内核日志）、mount（查看挂载点）、df（查看磁盘使用）、kill（发送进程信号）和 uname（查看系统信息）。

dmesg 命令用于查看内核环形缓冲区中的消息，这些消息包含了系统启动信息、硬件检测、驱动加载以及各种内核级别的事件和错误。在容器环境中，虽然容器与宿主机共享内核，但 dmesg 仍然能够提供有价值的诊断信息。例如，当容器因为内存不足被 OOM Killer 杀死时，相关信息会记录在内核日志中。

mount 命令显示当前系统的所有挂载点。在容器中，你可以看到根文件系统、各种特殊文件系统（如 proc、sys、cgroup）以及通过 Volume 挂载的外部存储。这对于验证存储配置、排查文件访问问题非常有帮助。

df 命令显示文件系统的磁盘空间使用情况。当容器报告磁盘空间不足时，df -h 可以快速定位是哪个文件系统空间不足。在容器环境中，需要特别关注 / 根文件系统和挂载的持久化存储的使用情况。

核心命令示例

# 查看内核日志（最后 50 行）
dmesg | tail -50

# 查看内核日志中的错误和警告
dmesg --level=err,warn

# 持续监控内核日志（实时显示新消息）
dmesg -w

# 查看所有挂载点（格式化输出）
mount | column -t

# 查看磁盘使用情况（人类可读格式）
df -h

# 查看系统信息
uname -a

# 优雅终止进程（SIGTERM）
kill -15 <PID>

# 强制终止进程（SIGKILL）
kill -9 <PID>

典型排查场景

当容器突然崩溃或出现异常行为时，dmesg 是第一个要查看的地方。如果看到 “Out of memory: Kill process” 相关日志，说明容器内存配置不足，需要增加内存限制或优化应用内存使用。如果看到 “segfault” 相关信息，说明应用存在内存访问错误，可能是程序 bug 或依赖库问题。如果看到磁盘 I/O 错误，需要检查存储系统的健康状况。

---

6. netcat (nc) - 网络连接瑞士军刀

netcat（简称 nc）被誉为网络工具中的"瑞士军刀"，它可以建立几乎任何类型的网络连接。无论是测试 TCP/UDP 端口连通性、创建简单的客户端/服务端、传输数据，还是进行端口扫描，netcat 都能轻松胜任。它是网络调试中最灵活、最实用的工具之一。

netcat 的核心能力是建立 TCP 或 UDP 连接并在连接上读写数据。在最简单的使用场景中，你可以用 nc -zv host port 测试端口是否可达：-z 表示零 I/O 模式（只测试连接，不发送数据），-v 表示详细输出。这比 telnet 更加简洁高效，是验证网络连通性的首选方法。

netcat 还可以作为简单的服务器使用。通过 nc -l -p 8080 可以在 8080 端口启动一个监听服务，任何连接到该端口的数据都会显示在终端上。这对于测试网络配置、验证防火墙规则非常有用。你甚至可以用它来创建简单的 HTTP 服务器或进行文件传输。

在进行 HTTP 测试时，netcat 可以发送原始的 HTTP 请求。通过 echo -e "GET / HTTP/1.1\r\nHost: example.com\r\n\r\n" | nc example.com 80 可以手工构造并发送 HTTP 请求，查看服务器的原始响应。这对于调试 HTTP 协议问题、验证反向代理配置非常有帮助。

核心命令示例

# 测试 TCP 端口连通性
nc -zv target-host 443

# 测试端口范围
nc -zv target-host 80-85

# 设置连接超时（5 秒）
nc -w 5 -zv target-host 3306

# 测试 UDP 端口
nc -u -zv target-host 53

# 启动一个简单的 TCP 服务器
nc -l -p 8080

# 发送原始 HTTP 请求
echo -e "GET / HTTP/1.1\r\nHost: example.com\r\n\r\n" | nc example.com 80

# 简单的端口扫描（扫描常用端口）
nc -zv target-host 22 80 443 3306 6379

典型排查场景

当应用无法连接数据库或外部 API 时，使用 nc -zv db-host 3306 可以快速验证网络层面是否可达。如果 nc 连接成功（显示 “succeeded”），说明网络是通的，问题可能在应用层（如认证失败、TLS 配置错误）；如果 nc 连接失败（显示 “Connection refused” 或 “Connection timed out”），问题在网络层面，需要检查防火墙规则、网络策略或目标服务是否运行。这种由底层向上的排查方法能快速缩小问题范围。

---

7. wget - HTTP/HTTPS 测试专家

wget 是一个功能完善的命令行下载工具，支持 HTTP、HTTPS、FTP 协议。与 curl 相比，wget 的语法更加简单直观，特别适合快速测试和下载任务。在容器调试中，wget 常用于测试 HTTP 端点可达性、验证 SSL/TLS 配置、下载配置文件等场景。

wget 的一个独特优势是 --spider 模式，它只检查目标是否存在而不实际下载内容。结合 -S 参数可以显示服务器返回的 HTTP 响应头，这对于验证服务状态、检查重定向、分析 HTTP 响应码非常有用。例如，wget --spider -S https://api.example.com/health 可以快速验证健康检查端点是否正常响应。

在处理 HTTPS 连接时，wget 提供了灵活的证书验证选项。默认情况下，wget 会验证服务器证书的有效性。如果遇到证书问题（如自签名证书、证书过期、域名不匹配），可以使用 --no-check-certificate 参数临时绕过验证，以便确定问题是证书相关还是网络相关。当然，这个参数只应在调试时使用，生产环境中应该确保证书配置正确。

wget 还支持设置各种 HTTP 头、超时时间、重试次数等参数，可以模拟各种客户端行为进行测试。-qO- 是一个常用的组合，表示安静模式（-q）并将内容输出到标准输出（-O-），适合在脚本中使用或快速查看响应内容。

核心命令示例

# 检查 HTTP 端点状态（显示响应头）
wget --spider -S http://api-server/health

# 下载文件
wget https://example.com/config.json

# 忽略 SSL 证书错误（仅调试用）
wget --no-check-certificate https://internal-api/

# 设置超时时间（10 秒）
wget --timeout=10 http://slow-api/

# 将响应内容输出到标准输出
wget -qO- http://api/health

# 带自定义 Header 的请求
wget --header="Authorization: Bearer token" http://api/

# 显示详细的调试信息
wget -v http://target-url/

典型排查场景

当需要验证容器能否访问外部 HTTP 服务时，wget --spider -S https://target-api/ 是最快的方法。从响应头中可以获取大量诊断信息：HTTP 状态码（200 正常、4xx 客户端错误、5xx 服务器错误）、重定向位置（Location 头）、服务器类型、内容类型等。如果遇到 SSL 错误，先用 --no-check-certificate 绕过验证，确认是证书问题还是网络问题，然后再用 openssl 进一步诊断证书问题。

---

8. openssl - SSL/TLS 证书诊断大师

openssl 是加密和 SSL/TLS 领域的标准工具，在容器环境中主要用于诊断 HTTPS 连接问题、查看服务器证书信息、测试 TLS 握手、验证证书链等。当应用报告 SSL 相关错误时，openssl 是定位问题的不二之选。

openssl s_client 是最常用的子命令，它可以建立一个 SSL/TLS 连接并显示详细的握手信息。通过分析这些信息，你可以了解服务器支持的 TLS 版本、使用的加密套件、证书链的完整性等关键细节。这对于排查 “SSL handshake failed”、“certificate verify failed”、“unknown CA” 等常见错误非常有帮助。

证书问题是 HTTPS 连接失败的主要原因之一。常见的证书问题包括：证书过期（可通过 -dates 选项查看有效期）、域名不匹配（证书中的 CN 或 SAN 与访问的域名不一致）、证书链不完整（服务器没有发送中间证书）、根 CA 不受信任（容器中缺少必要的 CA 证书）。openssl 可以帮助你逐一排查这些问题。

在某些场景下，你可能需要测试特定的 TLS 版本或加密套件。例如，某些旧系统可能只支持 TLS 1.0，而现代安全标准要求至少使用 TLS 1.2。通过 openssl s_client -tls1_2 可以强制使用特定的 TLS 版本进行测试，帮助你了解服务器的兼容性配置。

核心命令示例

# 连接服务器并显示证书信息
openssl s_client -connect portal.azure.cn:443 -servername portal.azure.cn

# 查看证书有效期
openssl s_client -connect portal.azure.cn:443 </dev/null 2>/dev/null | openssl x509 -noout -dates

# 查看证书详细信息
openssl s_client -connect portal.azure.cn:443 </dev/null 2>/dev/null | openssl x509 -noout -text

# 显示完整的证书链
openssl s_client -connect portal.azure.cn:443 -showcerts

# 测试特定 TLS 版本
openssl s_client -connect portal.azure.cn:443 -tls1_2

# 验证本地证书文件
openssl x509 -in certificate.crt -text -noout

# 检查证书链验证结果
openssl s_client -connect portal.azure.cn:443 -verify_return_error

典型排查场景

当应用报告 “certificate verify failed” 或 “unable to get local issuer certificate” 时，使用 openssl s_client -connect target:443 -showcerts 连接目标服务器，查看返回的证书链。如果 “Verify return code” 不是 0，说明证书验证失败，具体原因会在输出中显示。常见的错误代码包括：18（自签名证书）、19（证书链中自签名证书）、20（无法获取本地颁发者证书）、21（无法验证第一个证书）。根据错误类型采取相应的解决措施。

---

9. traceroute - 网络路径追踪器

traceroute 是一个用于追踪网络数据包路径的诊断工具。它通过发送不同 TTL（Time To Live，生存时间）值的数据包，逐跳记录数据包经过的路由器，从而显示从源到目的地的完整网络路径。这对于排查网络延迟、路由问题、网络不可达等问题非常有价值。

traceroute 的工作原理是利用 IP 协议的 TTL 字段。当数据包的 TTL 减为 0 时，路由器会丢弃该数据包并返回一个 ICMP “Time Exceeded” 消息。traceroute 首先发送 TTL=1 的数据包，第一跳路由器返回超时消息，traceroute 记录该路由器的地址和响应时间；然后发送 TTL=2 的数据包，第二跳路由器返回超时消息；以此类推，直到数据包到达目的地或达到最大跳数。

在复杂的云网络环境中，traceroute 帮助你理解流量的实际路径。这对于排查"为什么访问某个服务特别慢"、"流量是否经过了预期的路由"等问题非常有帮助。然而，需要注意的是，很多网络设备会阻止或限制 ICMP 协议，导致某些跳显示 * * *（超时）。此时可以尝试使用 TCP 模式（-T 参数）进行追踪。

traceroute 的输出包含每一跳的 IP 地址（如果可以解析，还会显示主机名）和三次探测的响应时间。通过分析响应时间的变化，可以定位延迟突增的节点。如果某一跳开始出现持续超时，说明问题可能在该节点或其后的网络。

核心命令示例

# 基本路由追踪
traceroute portal.azure.cn

# 使用 TCP 模式（可绕过 ICMP 防火墙）
traceroute -T -p 443 portal.azure.cn

# 使用 UDP 模式
traceroute -U portal.azure.cn

# 不解析域名（加快速度）
traceroute -n portal.azure.cn

# 设置最大跳数
traceroute -m 20 portal.azure.cn

# 设置等待超时时间
traceroute -w 2 portal.azure.cn

典型排查场景

当容器访问外部服务延迟很高时，使用 traceroute 可以看到延迟在哪一跳突然增加。如果延迟在前几跳就很高，问题可能在本地网络或容器网络配置；如果延迟在某一跳突然增加，问题可能在该节点或该段网络。如果某一跳显示 * * *，不一定表示网络不通，可能只是该节点不响应探测包。此时应该尝试 -T 参数使用 TCP 模式，或者结合 tcpping 进行进一步测试。

---

10. ca-certificates - CA 证书管理

ca-certificates 不是一个命令行工具，而是一个包含受信任 CA（证书颁发机构）根证书的软件包。它为系统提供验证 HTTPS 连接所需的根证书信任链。当应用报告 SSL 证书验证失败时，往往需要检查或更新 CA 证书配置。

需要特别注意的是，Azure Container Apps 的 Debug Console 基于 Fedora/Mariner 系统，使用 ca-trust 机制管理证书，而非 Debian/Ubuntu 系统中常见的 update-ca-certificates 命令。这是很多工程师容易踩的坑：在 Debug Console 中执行 update-ca-certificates 会报 “command not found” 错误。

在 Fedora/Mariner 系统中，CA 证书的管理结构如下：/etc/pki/ca-trust/ 是 CA 信任管理的根目录；/etc/pki/ca-trust/source/anchors/ 是添加自定义 CA 证书的位置；/etc/pki/ca-trust/extracted/ 存放系统提取的证书文件；常见的 /etc/ssl/certs/ 目录实际上只包含指向 /etc/pki/ 的符号链接。

当需要添加企业内部的私有 CA 证书时，正确的步骤是：将证书复制到 /etc/pki/ca-trust/source/anchors/ 目录，然后执行 update-ca-trust 命令更新证书存储。注意，Debug Console 中的更改是临时的，容器重启后会丢失。如需永久添加自定义 CA，应该在构建容器镜像时将证书添加进去。

核心命令示例

# 查看证书存储位置（注意这里只有符号链接）
ls -la /etc/ssl/certs/

# 查看实际的 CA 证书 bundle
ls -la /etc/pki/ca-trust/extracted/pem/

# 查看 CA bundle 中包含的证书数量
awk '/BEGIN CERTIFICATE/{ count++ } END { print count }' /etc/pki/ca-trust/extracted/pem/tls-ca-bundle.pem

# 添加自定义 CA 证书（正确方法）
cp custom-ca.crt /etc/pki/ca-trust/source/anchors/
update-ca-trust

# 验证证书是否已添加
trust list | grep -i "your-ca-name"

典型排查场景

当应用报告 “unable to get local issuer certificate” 或 “certificate verify failed” 时，通常是因为服务器证书的根 CA 不在容器的信任列表中。这在访问企业内部服务（使用私有 CA 签发的证书）时很常见。解决方案是将企业的根 CA 证书添加到 /etc/pki/ca-trust/source/anchors/ 并运行 update-ca-trust。如果问题只在调试时出现，可以通过这种方式临时解决；如果是生产环境的问题，需要在容器镜像中预置必要的 CA 证书。

---

11. bind-utils - DNS 诊断专家

bind-utils 提供了一组强大的 DNS 查询和诊断工具，包括 dig、nslookup、host 等。在容器环境中，DNS 解析问题是最常见的故障类型之一。这些工具帮助你验证 DNS 配置、排查解析失败、分析 DNS 响应，是网络故障排查的必备工具。

dig（Domain Information Groper）是功能最强大的 DNS 查询工具，它可以查询各种类型的 DNS 记录，并显示详细的查询过程和响应信息。dig 的输出包含多个部分：QUESTION SECTION 显示查询内容，ANSWER SECTION 显示查询结果，AUTHORITY SECTION 显示权威 DNS 服务器，ADDITIONAL SECTION 显示附加信息。通过分析这些信息，可以全面了解 DNS 解析的情况。

dig +trace 是一个非常有用的选项，它会从根 DNS 服务器开始，逐级追踪域名解析的完整过程。这对于排查 “NXDOMAIN”、“SERVFAIL” 等 DNS 错误非常有帮助，可以准确定位是哪一级 DNS 服务器出了问题。

nslookup 和 host 是两个更简单的 DNS 查询工具。nslookup 提供交互式和非交互式两种模式，输出格式较为传统；host 的输出最为简洁，适合快速查询。三个工具各有特点，可以根据需要选择使用。

核心命令示例

# 查询 A 记录
dig portal.azure.cn A

# 简洁输出（只显示 IP 地址）
dig +short portal.azure.cn

# 指定 DNS 服务器查询
dig @8.8.8.8 portal.azure.cn

# 追踪完整解析过程
dig +trace portal.azure.cn

# 查询所有记录类型
dig portal.azure.cn ANY

# 反向 DNS 查询（IP 到域名）
dig -x 10.0.0.1

# 使用 nslookup
nslookup portal.azure.cn

# 使用 host（最简洁）
host portal.azure.cn

典型排查场景

当应用报告 “Name or service not known” 或 “DNS resolution failed” 时，首先使用 dig target-host 查看是否能正常解析。如果解析失败，需要判断是本地 DNS 配置问题还是域名本身的问题。方法是使用公共 DNS 服务器进行对比测试：dig @8.8.8.8 target-host（Google DNS）或 dig @1.1.1.1 target-host（Cloudflare DNS）。如果公共 DNS 能解析但本地不行，问题在本地 DNS 配置；如果都不能解析，问题在域名本身。dig +trace 可以追踪完整的解析链，帮助你定位具体是哪一级出了问题。

---

12. tcpping - TCP 端口连通性测试

tcpping 是一个专门用于测试 TCP 端口连通性和延迟的工具。与传统 ping 使用 ICMP 协议不同，tcpping 使用 TCP 连接进行测试，能够更准确地反映应用层的实际网络连通性。在很多云环境和企业网络中，ICMP 协议被防火墙阻止，此时 tcpping 就成为测试网络连通性的最佳选择。

tcpping 的工作原理是向目标主机的指定端口发起 TCP 连接（三次握手），测量连接建立的时间，然后立即关闭连接。这个过程与应用程序建立 TCP 连接的过程完全一致，因此 tcpping 显示的延迟更能反映应用的真实网络体验。

与 nc -zv 相比，tcpping 的优势在于可以持续进行多次测试，并显示每次测试的延迟和统计信息（最小、最大、平均延迟）。这对于监控网络质量、发现间歇性网络问题非常有帮助。例如，你可以使用 tcpping -c 100 target 443 进行 100 次测试，观察延迟的波动情况。

tcpping 是容器网络故障排查的利器。当 ping 不通但你确信服务是运行的，tcpping 往往能够成功连接，证明 TCP 层面网络是通的，只是 ICMP 被阻止了。这种情况在云环境中非常常见，了解这一点可以避免走很多弯路。

核心命令示例

# 测试 TCP 端口连通性
tcpping portal.azure.cn 443

# 指定测试次数
tcpping -c 10 portal.azure.cn 443

# 测试数据库端口
tcpping database-server 3306

# 测试 Redis 端口
tcpping redis-server 6379

# 测试 SSH 端口
tcpping jump-server 22

典型排查场景

当 ping 显示目标不可达，但你确信服务是运行的，使用 tcpping target 80 可能会发现 TCP 端口其实是通的。这说明网络本身没有问题，只是 ICMP 被阻止了。tcpping 还可以用于监控服务可用性：通过定期执行 tcpping -c 10 并观察成功率和延迟，可以发现网络质量问题或服务不稳定的情况。如果发现延迟偶尔突然增大或偶尔连接失败，可能存在网络抖动或服务负载问题。

---

安装额外工具

如果预装工具不能满足需求，可以使用 tdnf 包管理器安装其他工具。tdnf 是 Fedora/Mariner 系统的包管理器，类似于 CentOS/RHEL 的 yum 或 dnf。

# 安装 iproute2（提供 ip 命令）
tdnf install -y iproute

# 安装 curl（更强大的 HTTP 客户端）
tdnf install -y curl

# 安装 vim 编辑器
tdnf install -y vim

# 安装 JDK（用于 Java 应用调试）
tdnf install -y msopenjdk-17

# 安装 strace（系统调用追踪）
tdnf install -y strace

# 搜索可用的包
tdnf search keyword

注意：Debug Console 中安装的工具是临时的，仅在当前调试会话中有效。如果需要经常使用某些工具，建议在应用的 Dockerfile 中预先安装。

---

常见故障排查流程

网络连接问题排查流程

# Step 1: 检查容器网络配置
ifconfig              # 查看 IP 地址
route -n              # 查看路由表

# Step 2: 测试 DNS 解析
dig target-host       # 详细 DNS 查询
dig +short target-host  # 简洁输出

# Step 3: 测试网络连通性
ping -c 4 target-host   # ICMP 测试
tcpping target-host 443 # TCP 测试（更可靠）
nc -zv target-host 443  # 端口扫描

# Step 4: 追踪网络路径
traceroute target-host  # 路由追踪
traceroute -T -p 443 target-host  # TCP 模式

SSL/TLS 证书问题排查流程

# Step 1: 测试 TLS 连接
openssl s_client -connect target:443 -servername target

# Step 2: 检查证书有效期
openssl s_client -connect target:443 </dev/null 2>/dev/null | openssl x509 -noout -dates

# Step 3: 查看证书链
openssl s_client -connect target:443 -showcerts

# Step 4: 验证证书（查看错误代码）
openssl s_client -connect target:443 -verify_return_error

性能问题排查流程

# Step 1: 检查系统资源
top                   # 实时监控
free -h               # 内存使用

# Step 2: 分析进程
ps aux --sort=-%cpu | head -20  # CPU 消耗排序
ps aux --sort=-%mem | head -20  # 内存消耗排序

# Step 3: 检查文件句柄
lsof -p <PID> | wc -l  # 统计打开文件数

# Step 4: 查看内核日志
dmesg | tail -50      # 检查系统级错误
dmesg | grep -i oom   # 检查 OOM 事件

---

总结

Azure Container Apps 的 Debug Console 提供了一套完整的诊断工具集，覆盖了网络诊断、进程监控、文件分析、SSL/TLS 调试等各个方面。熟练掌握这些工具，能够帮助你快速定位和解决容器化应用中遇到的各种问题。

在进行故障排查时，建议遵循"由底层向上"的原则：

1. 网络层：先用 ping/tcpping 确认基本连通性
2. DNS 层：用 dig 验证域名解析
3. 传输层：用 nc/tcpping 测试端口可达性
4. 应用层：用 wget/curl 测试 HTTP 响应
5. 安全层：用 openssl 诊断 SSL/TLS 问题

这种分层排查方法能够快速缩小问题范围，提高排查效率。

最后，记住 Debug Console 中的所有更改都是临时的。如果你发现某些工具或配置经常需要使用，应该考虑在容器镜像中预先配置，或者创建一个专门的调试用 sidecar 容器。