从0开始学微服务
胡忠想
微博技术专家
立即订阅
16289 人已学习
课程目录
已完结 42 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (1讲)
开篇词 | 微服务,从放弃到入门
免费
模块一 入门微服务 (10讲)
01 | 到底什么是微服务?
02 | 从单体应用走向服务化
03 | 初探微服务架构
04 | 如何发布和引用服务?
05 | 如何注册和发现服务?
06 | 如何实现RPC远程服务调用?
07 | 如何监控微服务调用?
08 | 如何追踪微服务调用?
09 | 微服务治理的手段有哪些?
10 | Dubbo框架里的微服务组件
模块二 落地微服务 (14讲)
11 | 服务发布和引用的实践
12 | 如何将注册中心落地?
13 | 开源服务注册中心如何选型?
14 | 开源RPC框架如何选型?
15 | 如何搭建一个可靠的监控系统?
16 | 如何搭建一套适合你的服务追踪系统?
17 | 如何识别服务节点是否存活?
18 | 如何使用负载均衡算法?
19 | 如何使用服务路由?
20 | 服务端出现故障时该如何应对?
21 | 服务调用失败时有哪些处理手段?
22 | 如何管理服务配置?
23 | 如何搭建微服务治理平台?
24 | 微服务架构该如何落地?
模块三 进阶微服务 (8讲)
25 | 微服务为什么要容器化?
26 | 微服务容器化运维:镜像仓库和资源调度
27 | 微服务容器化运维:容器调度和服务编排
28 | 微服务容器化运维:微博容器运维平台DCP
29 | 微服务如何实现DevOps?
30 | 如何做好微服务容量规划?
31 | 微服务多机房部署实践
32 | 微服务混合云部署实践
模块四 展望微服务 (4讲)
33 | 下一代微服务架构Service Mesh
34 | Istio:Service Mesh的代表产品
35 | 微博Service Mesh实践之路(上)
36 | 微博Service Mesh实践之路(下)
阿忠伯的特别放送 (4讲)
阿忠伯的特别放送 | 答疑解惑01
阿忠伯的特别放送 | 答疑解惑02
微博技术解密(上) | 微博信息流是如何实现的?
微博技术解密(下)| 微博存储的那些事儿
结束语 (1讲)
结束语 | 微服务,从入门到精通
从0开始学微服务
登录|注册

15 | 如何搭建一个可靠的监控系统?

胡忠想 2018-09-25
专栏第 7 期我给你讲解了监控系统的实现原理,先来简单回顾一下,一个监控系统的组成主要涉及四个环节:数据收集、数据传输、数据处理和数据展示。不同的监控系统实现方案,在这四个环节所使用的技术方案不同,适合的业务场景也不一样。
目前,比较流行的开源监控系统实现方案主要有两种:以ELK为代表的集中式日志解决方案,以及GraphiteTICKPrometheus等为代表的时序数据库解决方案。接下来我就以这几个常见的监控系统实现方案,谈谈它们的实现原理,分别适用于什么场景,以及具体该如何做技术选型。

ELK

ELK 是 Elasticsearch、Logstash、Kibana 三个开源软件产品首字母的缩写,它们三个通常配合使用,所以被称为 ELK Stack,它的架构可以用下面的图片来描述。
这三个软件的功能也各不相同。
Logstash 负责数据收集和传输,它支持动态地从各种数据源收集数据,并对数据进行过滤、分析、格式化等,然后存储到指定的位置。
Elasticsearch 负责数据处理,它是一个开源分布式搜索和分析引擎,具有可伸缩、高可靠和易管理等特点,基于 Apache Lucene 构建,能对大容量的数据进行接近实时的存储、搜索和分析操作,通常被用作基础搜索引擎。
Kibana 负责数据展示,也是一个开源和免费的工具,通常和 Elasticsearch 搭配使用,对其中的数据进行搜索、分析并且以图表的方式展示。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《从0开始学微服务》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(8)

  • wenxueliu
    elk更多是日志吧。大家买课程很多希望看到外面看不到的经验,而不是网上文章的拼凑,毫无营养,说实话。

    作者回复: elk用作监控的有很多地方,另外专栏面向的读者层次不同,有的读者没有基础知识,照顾下他们,科普还是有必要的,更深的使用经验在考虑单独篇幅里写。

    2018-10-01
    48
  • herome
    墙裂推荐 美团的CAT !!!!
    2018-09-28
    7
  • godtrue
    开开眼界,用时自行研究,这里就是常规介绍
    2019-06-15
    2
  • 玉剑冰锋
    个人认为ELK更适合进行故障排查定位、数据分析、深度挖掘方向,不知道老师是否认可?另外请教老师一个问题,Prometheus这种拉取方式在小规模可以体现出优势,大规模的情况拉取是不是就不如推送更优了?
    2018-09-27
    2
  • cqc
    从官方文档来看,Prometheus的指标存储,很高效,但是问题在于没有成熟的高可用,历史数据归档,海量历史数据查询支持。在调研监控系统的过程中,还发现了小米的open falcon,感觉设计得很复杂,它和Prometheus都属于现代的面向微服务设计的指标监控系统,老师能否有机会深度比较一下?另外,想让老师指正一下我对于监控系统的理解:根据我目前的理解,监控系统可以划分为不同的维度:指标监控(如Prometheus,Zabbix),日志监控(NLK/NFK),调用链监控(zipkin),不知道对不对?
    2018-11-15
    1
  • 金hb.Ryan 冷空氣駕到
    很欣慰,我司的监控技术栈是influxdb+grafana,配合程序/collectd 来推送,不过即使influxdb很强大还是建议适当merge一下,不然...都是泪

    作者回复: 哈哈,开源组件在生产环境中用肯定是要优化的

    2018-09-28
    1
  • 旭东
    国产的有好的监控组件吗?如CAT
    2018-09-27
    1
  • 天若有情天亦老
    elk+xpack 可以做到小规模的业务监控。
    就是watcher比较难用
    目前用的方案是 elk stack+zabbix ,求更优方案

    作者回复: 能cover住需求就行

    2018-09-25
收起评论
8
返回
顶部