背景
Falcon 很多item经常会出现长期未上报数据的问题比如磁盘出现异常，网卡异常，agent没法采集到数据，但是服务器还是存活的，实际上部分功能已经不可用，特别是某天故障发生，要检查服务器的监控数据，却发现CPU，内存都无数据，目前针对这种场景还没有一个较好的感知手段
falcon-nodata
falcon 本身有一个nodata 组件，该组件会根据 配置的metric，对这些metric进行监控，如果未获取到数据，就发送一个预设的值
该组件能在一定程度上规避问题，但存在如下几点问题
- 必须要预设metric与tag，且配置较为繁琐
- 如果配置过多，会频繁查询api，之前公司内网就有过将api组件查挂过，而且是只配置了agent.alive等三个指标
需求分析
告警收敛
比如网卡，网卡在falcon上的体现有in方向，out方向，还有服务器上绝对会不止一张网卡，如果发现长期未获取到数据，应该要将其收敛为一条通知
告警时效性
应支持可配置性，比如将网卡，磁盘的metric归纳为一个标签，该标签的告警要频繁发送，但其他的可以一天一封，以报告的形式发送
可行性
如果要实现上述需求仅仅依靠nodata组件是不够的，特别是nodata必须要精确到tag，而每台服务器的网卡名，磁盘名都可能不一样
graph组件内部索引缓存
graph内部有一个indexedItemCache的map，该map里面存的是当前graph接收到所有metric，同一个metric每接收一次会update一次，意味着metric的Timestamp也会更新，那是否可以从该map入手？定期将10分钟（暂定十分钟）未更新的数据提取出来，推入消息队列，再定时分析数据，发送报警，同时graph是分了多台的，能减缓计算的压力
注意点
- 目前我们的falcon-agent还无法对 指标做到精确过滤（只能做到根据metric的正则过滤，但一个指标除了metric还会有tag），所以要过滤掉无用指标的干扰（比如容器的挂载点）
- 定期清理 indexedItemCache
为什么要定期清理，因为通过这几天对源码的分析，发现该map根本就没有定期清理的机制，如果某kubernetes服务器频繁的启停pod，产生了数万的数据，意味着除非graph重启，不然这些数据都会常驻内存中
