@Eureka122 #90 发布于2026/6/2 12:51:22，编辑于2026/6/2 12:51:37 我个人觉得这个项目目前还有些很严重的问题 延迟面板，不可达采用数值0ms，且参与了平均桶计算，导致丢包率高的情形下平均下来甚至表现为延迟低，这是不可接受的。 长区间拼接逻辑比如6h，拼接了最近 1h 原始点+ 1h 以前聚合点+ 前端再次抽稀，6h 图里既有 8min 间隔，也可能出现 30-50min 间隔；前端会把缺口直接连起来，看起来像连续数据，导致在波动数据中出现一条诡异的平滑斜线 现在为了一些资源节省默认最近1h，那这些曲线几乎只是好看的花瓶，我觉得探针除了列表栏用于显示基本信息，图表栏就数延迟栏有用，但是目前的实现连晚高峰拥堵都体现不出来，几乎没有参考价值 我觉得与其增加能支持的服务器数量，还是不如先实现一个扎实的数据监控效果，否则省下来的资源也是浪费 已修复，见dev分支commit https://github.com/huilang-me/CF-Server-Monitor/commit/bc422f2ce1a5f693382e6c478c73af9b6c82d054 已调整逻辑 dev分支的多个commit，一小时以上的数据目前也完整输出，限制登录用户才能查看。后端抽稀功能还是考虑加上，可能换个方式，晚上模拟数据再测试下，目前全部返回数据有点密 初版存在很多问题，感谢指正，持续优化中。D1限制太多，前面几天都是在优化读写，最近几个版本已经大幅压缩查询数量和效率了 再次感谢
@nssk #78 每日定时任务清除三天，其实额度不是在这里，记录多目前仅影响D1占用空间，这个额度大的很，完全不用顾虑。 现在的读写方式没有遍历所有记录的查询，加上了只有管理员才能查看1小时以上的历史记录来避免超额。
@Eureka122 #90 可以看dev分支的
再次感谢
@nssk #78 每日定时任务清除三天，其实额度不是在这里，记录多目前仅影响D1占用空间，这个额度大的很，完全不用顾虑。
现在的读写方式没有遍历所有记录的查询，加上了只有管理员才能查看1小时以上的历史记录来避免超额。