看起来还是可以的，上面就是效果图
功能还是挺多的，有了数据以后呢，就可以方便的进行各种分析与挖掘，继而为运维、选购提供决策支持：
也可以基于目标区域的视角进行数据比对：
在这个图对比一下，就一眼可知，成都电信是一定会被排除的，继而，相对而言上海电信的稳定性会略差于武汉电信，但是延迟会略好一些。
还可以时间聚合的方式来观察目标节点的时段表现，比如：
这个图就是一周以内我自己网站（听涛 www.tingtao.org）的时段表现，那么可知，现在所用的这个kurun垃圾机房在高峰期面向国内线路是挺炸裂的。。。一天两天出问题正常，但是一周平均数还是这样，那就没什么好说的了。
更多功能还在思考中，暂未对外开放。
孩子还有两周就中考了，考完还要根据情况看看能不能上高中，以及后续，最近事情听多了。
做这整套系统，也挺逗的。起初只是想搞个替代现有单机工具，并且好用一些的。然后又感觉有点弱，单纯的看个平均延迟和总计丢包率其实没多大用，于是又开始搞了个服务器版。接着又发现单一节点的观测效果其实意义也不大，于是最终搞成这么一套体系了。
观测点运行的是go做的程序，根据目标节点设置来执行任务，并生成每分钟报表，提交给服务器端，由服务器端入库，最后由web端呈现。这中间也遇到不少难题，最终观测点做了本地文件缓存，当连不上服务器的时候把报表队列写文件，直到能连上的时候一次性提交，这样可以规避服务器端单点故障的时段没有数据，也避免了起初的内存队列会撑爆内存的问题。
而服务器端一样做了缓存队列，如果数据库暂时连不上，一样先写到文件缓存里。
web就更糟心了，我很不擅长做界面，就现在这界面还是找了个模板硬套上去的，我对这方面的要求是别太丑就行。。。
然后用户等级3个，还有附加用户等级3个，管理员等级2个，详细的权限控制，以及所有数据的有效性验证等等，对我这种前端门外汉来说，挺累的。。。
这中途我还想到一个挺大的风险点，比如若有人在本系统内添加10万个相同地址，那么我这5个观测点实际上会对这个目标发起每秒钟50万包的攻击量，这就成了借刀杀人的刀了，于是又在观测点做了优化，相同地址进行聚合处理，现在的逻辑是即便添加100万，实际上也只会执行1次/秒，而生成的报表依然会映射到100万，这样就解决这问题了。
细节挺多的，以后想到再说了，先歇几天。。。
就像上篇文章说的那样，这种东西会让中小服务商挺难受，我这都还没做好呢，就被人喷了。。。
随你们咯，都说自己是行业领导者低位，都说自己100%在线率，拿数据说话吧，数据面前，谁都别装逼，是骡子还是菜逼，拉出来溜溜就知道了，呵呵
暂时算是测试阶段吧，注册功能虽然很简单，但我根本就没做，咱也学人“邀请制”，有需要使用的联系我。