首页
登录 | 注册

微服务来了,监控怎么办?

微服务来了,监控怎么办?

  • 分散在各处的日志怎么办?
  • 是某个宿主服务器的问题?还是某个服务的问题?
  • 无论是服务还是服务器问题,影响链有哪些?
  • ......
  • 事故预警:比如基于阀值对比的实时的事件告警等
  • 故障定位:比如静态点的异常日志收集等
  • 优化决策:比如用户行为数据分析,发现瓶颈等

微服务来了,监控怎么办?

    • 管道除了传输,还有很多能力,最常用的是简单预处理和数据缓冲(比如很多架构里用到了kafka)
    • 传输可以是多级,一般来说规模大到一定程度,数据往一个点的海量汇聚很容易出问题,分级处理是个很好的方式
    • 日志收集方式尽量统一,很多设计里对于业务日志、容器日志(如docker)、宿主机日志等采用不同agent,这是一个不好的设计方式,agent也要管理,引入太多agent只会给自己增加不必要的麻烦 
    • 都可以做到的前提下,后端采集是首选
    • 前端采集尽量采用框架进行埋点,不要到处插入自定义代码(框架的做法其实不复杂,比如web端,用过类似selenium这些框架自然就清楚原理了)
    • 埋点很难做到语言无关性,尤其后端埋点,微服务架构下,尽量结合各微服务语言特征来实现
    • 指标库的选型一般会采用一些内存计算框架,对于主题的设计和优化要充分考虑内存容量
    • 无论容器、虚机、物理机,性能数据采集都面临着窗口的问题,一般是两个窗口(多长时间采集一次和采集的数据是多长时间的数据平均值),需结合业务设置合理值
    • 还有一点,包括上述的两个场景也都要注意,就是采集器本身对宿主机的性能影响,需尽量降到最低
微服务来了,监控怎么办?

    • 决策者:最关注的是这周或这个月比前段周期负载增加或降低了多少,给他的只需是个数字对比结果,明细数据根本不重要,最多他希望能对比到半年前即可
    • 运维人员:运维人员其实对数据实时性要求很高,他们根本不在乎几个月前的数据,只要能看到最近时间的数据有没有问题即可
    • 日志收集的需求,因为我们是基于容器技术的,使用的CoreOS系统,最终我们采用了Journald+Fluentd+ElasticSearch的技术(业务日志亦是如此),简单场景下,ELK、Flume等其实就足够了,我们在一些小项目中实践过。而实时分析系统部分,大家可选择akka、或者esper、或者storm作为实现框架,akka通过actor模型实现信息流转,esper我们是用来做CEP产品的,storm就不用多说了
    • 对于埋点的一些需求,大家可参考java的Metrics项目,或者Netflix的Suro项目,都是java实现,前者简单,后者则考虑更周全。
    • 对于性能指标的一些需求,influxdb可作为后端存储(不过influxdb的版本间兼容性做的很一般),大家尽可能使用最新版本,还有opentsdb,有朋友推荐过,不过毕竟是基于HBase的,比较重,大家有兴趣可尝试 


2020 jeepxie.net webmaster#jeepxie.net
10 q. 0.008 s.
京ICP备10005923号