如何诊断FiftyOne应用崩溃问题并获取更多相关排查信息

从你提供的MongoDB日志来看，进程是被外部发送的kill(2)信号终止，不是应用内部自发崩溃，你可以从以下几个方向采集信息定位根因：

1 采集完整的进程与服务日志 #

• 优先检查你重定向生成的fiftyone.log，查看崩溃时间点前后FiftyOne应用层的报错，比如Python异常、连接数溢出、资源调用失败等记录。你可以在启动时添加日志级别参数开启debug模式，拿到更细粒度的应用日志：

  FIFTYONE_LOG_LEVEL=debug nohup fiftyone app launch --remote > fiftyone.log 2>&1 &
  

• 检查系统内核日志，确认是否触发了OOM（内存溢出）kill：

  dmesg -T | grep -E 'kill|oom|out of memory'
  

  当MongoDB或FiftyOne进程占用内存超过系统/容器的内存上限时，内核会主动发送kill信号终止进程，是这类无报错崩溃的常见原因。
• 检查Docker容器的运行日志，确认是否是容器侧触发了资源限制导致进程被终止：

  # 查看近24小时的容器日志
  docker logs <你的FiftyOne容器ID> --since 24h
  # 查看容器的资源限制配置
  docker inspect <你的FiftyOne容器ID> | grep -E 'Memory|Cpu'
  

2 检查操作系统与EC2的资源监控 #

• 查看AWS EC2的CloudWatch监控指标，核对崩溃时间点的CPU利用率、内存使用率、磁盘使用率、磁盘IO、网络IO指标，确认是否出现资源耗尽的情况。
• 检查~/.fiftyone挂载分区的磁盘剩余空间，MongoDB运行过程中会持续写入数据和日志，磁盘占满会直接触发进程终止：

  df -h ~/.fiftyone
  

3 完善进程管理机制留存崩溃现场 #

• 替换nohup的启动方式，改用systemd管理FiftyOne进程，systemd会自动记录进程的退出状态码、接收信号类型，你可以通过journalctl工具回溯完整的进程生命周期日志，同时也能配置进程异常自动重启。
• 调高MongoDB的日志级别，修改~/.fiftyone/var/lib/mongo/mongod.conf中的日志级别配置为1或更高，记录所有连接、操作、错误信息，下次崩溃时可以拿到更完整的MongoDB侧上下文。
• 配置轻量的进程监控脚本，通过crontab定时采集FiftyOne和MongoDB进程的CPU、内存占用数据，崩溃后可以回溯资源占用的变化趋势：

  # 每5分钟记录一次进程资源状态
  */5 * * * * ps aux | grep -E 'fiftyone|mongod' >> /path/to/process_monitor.log
  

内容的提问来源于stack exchange，提问作者Cola