IPC相机核心业务运行状态监控的重要性

IPC相机开发，总结一下，对于系统核心业务运行状态监控的一些看法。

个人对于系统核心业务的状态监控非常的热衷，开发IPC这么久，我发现，除软件架构，模块封装，业务分层，解耦之外，业务状态监控非常非常重要。

嵌入式设备，开发起来其实也很愉快，最头疼的事情是，设备供货给客户，运行了几个月后，客户突然打电话过来，说我们买的设备出现了异常情况，比如什么IPC跑黑屏了，视频出现花屏了，你们的相机抓拍功能失效了，等等等等。在刚开始研发IPC业务系统时，没想那么多，简单粗暴，怎么容易怎么来，把业务功能做好了就一切万岁了。直到，把设备卖到市场上后，才发现，有些BUG，测试是很难测出来的，测试间那几台或者是几十台设备，测它个把月，你别说，运气好的话，一点异常都没有。但是到了市场成百上千台，那就完全不是一回事情了。开发人员面对现场出问题的设备，让客户无语的情况就是你们重启机器，到底是什么问题研发自己也说不清。这麻烦就大了，一次两次偶尔出现还情有可原，出现次数多了，那可直接影响公司形象，说白了，下次人家在市场上能找到替代品，很大概率是不会再买咱们公司产品的，这是实打实的客户流失。然而，这种事情，作为开发人员，我是无法容忍的。出BUG可以，但是，我们得在出问题的环境下，迅速定位出问题，给客户明确的答复，以及提出解决方案后的修复版本日期，这样客户心理有底，人家也容易接受些。

只要是我参与开发的IPC产品，我一定会分离出一个模块，这个模块就是核心业务监控，IPC设备，现在调试的手段已经很丰富了，FTP，telnet，足够用了，如果说要连接串口进行调试，那么问题就很严重了。其实这个监控模块，可以做得无比复杂，不过核心的东西抽象起来也不是很多，比如说我们业务线程的运行状态、我们每个线程主控的业务流，现在跑的状态是什么，出问题了，系统是停止在哪个代码块上了，具体的是哪一个模块，哪一行，我们IPC的采集数据回调正常与否，采集周期耗时正常与否，核心业务线程平均耗时，突发耗时最大、最小值是多少，我们通过网络之间的通信过程中，顺利完成的是多少次，失败的占比是多少，我们推送出去的结构数据、图片、文本等等信息耗时怎样，丢包多少，这些统统的可以加入检测模块中。

        其实很多时候，我们一次搞定不了所有的监控项目，可以随着开发的进程不断的添加进去，比如开发过程中，哪里出现过问题，我们很自然的会把这个问题加入到检测列表中，这是个不断优化，不断扩展的过程。其实IPC相机调度业务，抛开一些比较有难度的算法模块，还是很好控制的。最终，我们可以实现一个注册函数，或者是一个log就能迅速定位出问题。

出BUG不可怕，可怕的是跑很久很久出来的BUG，我们一点点定位的线索都没有，那就只能抓瞎了，这对开发来说是很悲剧，很悲哀的情况。