之前一个月准备完成项目的监控，但资源紧张，所以没采用成熟的框架而是用java原生程序实现了对项目的监控。这套监控程序更多的是从使用者角度（比较抽象），而且由于项目时间紧，我甚至没时间去参考现在开源的程序监控框架，所以也没法理论联系实际（笑），下面讲下思路和遇到的一些问题吧。
设计思路：
接入数据 验证数据接入是否正常，确定是数据源还是之后程序的问题
应用程序 监控应用程序是否正常启动，防止多次启动失败程序挂掉的情况
实时数据量监控 监控各模块写入数据量是否正常，防止程序内部逻辑错误或者连接断掉的情况。
这些监控项是基于业务数据量稳定，对机器性能进行了忽略，更多的是考虑出现问题后更快的干预和定位，而不是对集群负载的提前预测。与业务本身耦合度较高但对其他的监控思路也有一定参考性。
设计实现：
接入数据 监控接入kafka的偏移量和时间戳是否变化，后追加告警和数据记录。
应用程序 与定时启动程序（linux定时任务）应用，在脚本中实现启动数据记录，如短时间程序多次启动则进行告警。
实时数据量监控 解析Kafka数据，获取条数和每条点数相加，对Kafka每小时数据条数的监控，habase数据条数的监控，tsdb数据条数的监控，Kafka每小时数据量监控（每一条点数相加）。tsdb丢失测点监控（因程序不稳定导致数据大量写入且本身开销过大，已停止）
问题与总结
1.接入程序会出现长连接掉连接的问题，这个会写一篇来说。
2.定时启动任务对启动较慢或者启动卡住的程序非常危险，如storm，和yarn。有天一个storm程序启动了几十次，直接崩了storm集群。
3.监控程序最初的目的是想确认在逻辑运算中是否丢失测点，不过后面却更多应用于确认数据是否断掉，程序是否需要重启，而因为tsdb数据断掉，会写出大量测点，故暂时关闭。
实际应用下还是更多对数据断掉的情况下，对问题的定位起到了比较大的帮助，简化了流程，加快了速度。我自身也对项目的问题有了更深的了解。