智能家居科技|如何用ELK搭建TB级的日志监控系统?( 二 )


甚至有些服务还打印着Debug级别的日志 。 在成本、资源的有限条件下 , 所有所有的日志是不现实的 , 即使资源允许 , 一年下来将是一比很大的开销 。
所以我们采用了过滤、清洗、动态调整日志优先级采集等方案 。 首先把日志全量采集到Kafka集群中 , 设定一个很短的有效期 。
我们目前设置的是一个小时 , 一个小时的数据量 , 我们的资源暂时还能接受 。
⑥LogStreams是我们的日志过滤、清洗的流处理服务 。 为什么还要ETL过滤器呢?
因为我们的日志服务资源有限 , 但不对啊 , 原来的日志分散在各各服务的本地存储介质上也是需要资源的哈 。
现在我们也只是汇集而已哈 , 收集上来后 , 原来在各服务上的资源就可以释放掉日志占用的部分资源了呀 。
没错 , 这样算确实是把原来在各服务上的资源化分到了日志服务资源上来而已 , 并没有增加资源 。
不过这只是理论上的 , 在线上的服务 , 资源扩大容易 , 收缩就没那么容易了 , 实施起来极其困难 。
所以短时间内是不可能在各服务上使用的日志资源化分到日志服务上来的 。 这样的话 , 日志服务的资源就是当前所有服务日志使用资源的量 。
随存储的时间越长 , 资源消耗越大 。 如果解决一个非业务或非解决不可的问题 , 在短时间内需要投入的成本大于解决当前问题所带来收益的话 , 我想 , 在资金有限的情况下 , 没有哪个领导、公司愿意采纳的方案 。
【智能家居科技|如何用ELK搭建TB级的日志监控系统?】所以从成本上考虑 , 我们在LogStreams服务引入了过滤器 , 过滤没有价值的日志数据 , 从而减少了日志服务使用的资源成本 。
技术我们采用KafkaStreams作为ETL流处理 。 通过界面化配置实现动态过滤清洗的规则 。
大概规则如下:
界面化配置日志采集 。 默认Error级别的日志全量采集 。
以错误时间点为中心 , 在流处理中开窗 , 辐射上下可配的N时间点采集非Error级别日志 , 默认只采info级别 。
每个服务可配100个关键日志 , 默认关键日志全量采集 。
在慢SQL的基础上 , 按业务分类配置不同的耗时再次过滤 。
按业务需求实时统计业务SQL , 比如:高峰期阶段 , 统计一小时内同类业务SQL的查询频率 。 可为DBA提供优化数据库的依据 , 如按查询的SQL创建索引 。
高峰时段按业务类型的权重指标、日志等级指标、每个服务在一个时段内日志最大限制量指标、时间段指标等动态清洗过滤日志 。
根据不同的时间段动态收缩时间窗口 。
日志索引生成规则:按服务生成的日志文件规则生成对应的index , 比如:某个服务日志分为:debug、info、error、xx_keyword , 那么生成的索引也是debug、info、error、xx_keyword加日期作后缀 。 这样做的目的是为研发以原习惯性地去使用日志 。
⑦可视化界面我们主要使用Grafana , 它支持的众多数据源中 , 其中就有普罗米修斯和Elasticsearch , 与普罗米修斯可谓是无缝对接 。 而Kibana我们主要用于APM的可视分析 。
日志可视化
我们的日志可视化如下图:
智能家居科技|如何用ELK搭建TB级的日志监控系统?
文章图片
智能家居科技|如何用ELK搭建TB级的日志监控系统?
文章图片
智能家居科技|如何用ELK搭建TB级的日志监控系统?
文章图片
智能家居科技|如何用ELK搭建TB级的日志监控系统?
文章图片
智能家居科技|如何用ELK搭建TB级的日志监控系统?
文章图片
智能家居科技|如何用ELK搭建TB级的日志监控系统?


推荐阅读