轻松构建微服务之监控平台

微信公众号:内核小王子
关注可了解更多关于数据库,JVM内核相关的知识;
若是你有任何疑问也能够加我pigpdong[^1]java

前言

随着微服务化,以及集群规模化,传统的日志检索,指标监控,调用链分析做为功能单一的系统,已经没法更好的帮咱们分析问题,咱们须要一个监控平台将他们之间的数据进行整合和分析,输出更友好的视图给用户.mysql

指标报警 -> 应用 -> 服务 -> 事物 -> 堆栈 -> 日志nginx

如下为随手记的监控平台的Focus架构redis

下图描述了典型的三层监控体系,将基础层,中间件层,应用层的数据进行聚合分析spring

  • 基础层:监控主机和底层资源,CPU,内存,网络吞吐,硬盘IO和硬盘容量sql

  • 中间件层:nginx redis kafka mysql tomcat数据库

  • 应用层: HTTP访问吞吐量,响应时间,调用链分析,用户行为分析缓存

调用链

咱们通常会遵循opentracing的接口,一个调用链入口,会开始一个trace,分配到一个traceid,而后缓存到调用链上下文,每个分支调用都会开启一个span,而后每个span都会记录本身的开始时间和结束时间,以及他的父span是谁.这样就能够清楚的记下,每个RPC调用,在每个步骤分别执行了多长时间,例如调用RPC-A花了多久,RPC-A又执行sql-a花了多久,RPC-A读取缓存花了多久等等.tomcat

咱们经过调用链的过程能够分析出服务间的调用,进而展现出应用间的依赖topo图,咱们能够借助这个topo他再监控页面展现核心指标的报警.
服务器

通常哪些节点须要埋点

  • jdbc 咱们能够借助druid进行数据采集,调用druid接口获取统计数据发给采集器
  • mybatis 在mybatis的拦截器中进行埋点
  • rpc dubbo能够在filter中进行卖掉
  • redis
  • rocketmq
  • httpclient
  • springMVC
  • log
  • jvm监控数据

日志监控

最开始单体引用的时候咱们能够直接让运维查看服务器上的日志,或者用一个跳板机,在这个跳板机上查看多个服务器上的日志,后来数据量和请求上来了,大量的日志进行检索的时候若是继续使用grep,AWK这种文本工具将不能知足需求,而后就有了ELK方案,通常在应用的日志中增长一个appender,将日志输出到kafka,日志存储在kafka中,而后经过logstash去kafka拉取日志,固然这个时候能够增长一些filter对日志进行过滤,而后输出到elastic search中,而后经过kibana提供使用中视图.

若是咱们须要将日志归入统一的监控平台,咱们能够将日志和调用链中的traceid进行绑定,而后一块儿存入ES中,这样在分析某一个调用链的时候,能够自动展现对应的日志.

日志降噪,能够借助kafka stream流处理的工具,将相同类型的日志进行去重,例如一个用户购买的日志,可能都是同样,只是用户id和购买金额不同,那么咱们能够只存储这个日志,分别在某个时间段出现了多少次,以及对应的用户,这样能够节省大量的日志空间,固然也能够提升减速效率.

指标

除了一些硬件负载,例如是否CPU使用率,线程数目,内存大小等,还有一些用户设置的指标,例如单位时间内购买请求的失败率等,某一个服务调用次数,日志条数等.以及服务的TOPN视图,例如按调用量,调用耗时,单位时间内的调用量等

采集器

数据采集器通常部署在应用端,为了支持更高的并发量,咱们能够借助ringbuffer这种无锁队列提升效率,或者直接推给KAFKA作中转,那么这里有个选择就是在推送前,是否须要在应用端节点作一些指标计算或者压缩,
若是应用端有大量的CPU空余就能够选择在应用端作,若是应用侧对带宽不敏感,CPU更敏感就将原始数据都推送过去.

有些同窗以为,监控层应该对应用无感,因此但愿应用不要依赖监控的SDK,这种方式通常借助 -javaagent对应用进行字节码加强,这种方式若是只是针对特定的拦截器增长指标,例如rpc调用,日志等,能够简单地针对特定的类加强,若是须要用户手工设置监控指标,则须要在用户层的类作字节码加强,开发会比较复杂,固然具体状况能够根据公司应用环境进行调整,例如只有用户手工增长的指标依赖SDK,某个应用没有指标则能够不依赖

数据存储

因为监控数据量很大,咱们能够选择放入es中,也将一些历史数据放入hadoop中

数据分析

能够借助kafka stream,使监控平台更轻量,不须要依赖spark straming或者 apach storm

相关文章
相关标签/搜索