java原生项目监控设计思路(二)

之前写过第一版监控思路，收到我都想不到的关注度，后面梳理需求进行了一个更大范围的监控，并支持后续报表的生成。最近因为资源增加，也在关注elk监控相关思路，之后应该也会有新的文章产出（把监控的坑越挖越大），现在结合旧版讲下设计思路和实现。

---

设计思路：

这次专注于数据量监控，因为这是一个痛点。同时每天数据量能直观对数据接入是否成功进行验证，同时比对每个模块数据是否正常写入，发现延迟卡死等问题。

相比之前监控拓展了监控范围，从最开始的输入端到最后的输出。同时方便小组其他人员查看并提供之后报告到处的接口，为推送给客户做准备。

---

设计实现：

首先把时间粒度由一小时延长到一天，因为按照这个时间粒度仍然能很快发现数据异常，并可以迅速向下查找问题，同时把输出改为mysql，增加了字段描述，并为之后导出为报表提供了接口。 同时这次新增了计算数据频率字段，能更直观发现数据变化，也能做相应统计指标。

这次没有监控kafka的数据，而是从接入端flume和数据存储的tsdb，habse，hive和kylin进行存储，实现整个流程的完整监控。

所以这次程序是java原生程序和脚本辅助构成的。flume是通过定时脚本读取flume的日志获取数据条数和数据字节大小，写入redis缓存。hbase和tsdb是在程序中直接查询。hive和kylin也是通过定时脚本（因为是定时任务，所以会在3-4点左右查前一天数据）。本次hbase，tsdb，hive和kylin也是采取指标点查询数据（查询单点）。

最后通过程序聚合数据，写出到mysql中。

---

问题与总结
1.flume日志会很多有用的信息，而且日志的规范会对脚本统计非常重要。后续做elk准备继续总结修改相关日志。

2.hive和kylin的脚本必须运行在安装相应客户端的节点，kylin脚本的一个小坑：https://blog.youkuaiyun.com/jyj1100/article/details/89667694

3.注意查询延迟，其中hive查询会执行10分钟左右，kylin会执行2分钟左右。这也是扩大粒度的一个原因

这次除了数据断掉，更直接的发现了服务挂掉或者卡死的问题，并且能快速定位。但对于整个系统仍然是不够的 ，目前准备调研和上elk，之后的监控应该就由elk完成了。