Sonarr容器崩溃问题分析与解决方案

问题现象

在使用Sonarr容器化部署时，用户报告容器会在运行20-30分钟后自动崩溃退出。类似的问题也出现在Radarr容器中，但Prowlarr容器运行正常。

排查过程

日志分析

从提供的日志片段可以看出，Sonarr在正常运行一段时间后突然终止，日志最后显示的是正常的API请求处理，随后直接跳转到应用关闭的信息：

2024-07-01 12:00:00.0|Debug|Api|[GET] /api/v3/queue: 200.OK (1 ms)
2024-07-01 12:00:07.8|Debug|Microsoft.Extensions.Hosting.Internal.Host|Hosting stopping
2024-07-01 12:00:07.8|Info|Microsoft.Hosting.Lifetime|Application is shutting down...

这种突然终止的行为通常表明容器遇到了某种不可恢复的错误，或者被外部因素强制终止。

可能原因排查

1. 资源限制问题：检查容器是否设置了内存限制或CPU限制，资源不足可能导致容器被OOM Killer终止。

2. 挂载点问题：容器依赖的存储卷或挂载点不可用会导致应用崩溃。

3. API密钥泄露：有恶意脚本频繁调用API可能导致资源耗尽。

4. 依赖服务故障：如数据库连接中断或外部服务不可达。

根本原因

经过深入排查，发现问题根源在于远程挂载服务停止工作。当Sonarr和Radarr尝试访问挂载点时，由于挂载点不可用，导致应用无法继续运行而崩溃。

解决方案

1. 修复远程挂载服务：确保远程挂载服务稳定运行，设置自动重启机制。

2. 增加健康检查：在容器配置中添加对挂载点的健康检查，当挂载点不可用时自动尝试恢复。

3. 错误处理优化：虽然这是应用层面的改进，但可以配置Sonarr在挂载点不可用时进入降级模式而非直接崩溃。

4. 监控设置：对关键挂载点设置监控告警，及时发现并处理问题。

预防措施

1. 对关键服务设置进程管理工具守护进程，确保服务异常退出后能自动重启。

2. 在容器编排配置中，为关键挂载点添加required标记，确保挂载点可用性。

3. 定期检查系统日志，及时发现潜在问题。

总结

容器化应用崩溃往往不是应用本身的问题，而是运行环境或依赖服务出现异常。本例中，远程挂载服务故障导致挂载点不可用，进而引发应用崩溃。通过完善监控体系和增加容错机制，可以有效预防类似问题的发生。