目录
大家好，我是哪吒。
与单体应用相比，在微服务架构下，一次用户调用会因为服务化拆分后，变成多个不同服务之间的相互调用，这也就需要对拆分后的每个服务都监控起来。
在进行系统监控之前，需要明确三个问题：
- 监控的对象是什么？
- 具体监控哪些指标？
- 从哪几个维度进行监控？
一、监控对象
监控对象大概分为四个方向：
- 基础监控：通常指对服务器本身的健康状况的监控，主要包括CPU利用率、内存使用量、I/O读写量、网卡带宽等。
- 资源监控：通常指对接口依赖的外部资源的监控，如redis。
- 接口监控：通常指对业务提供的功能所依赖的具体RPC接口的监控。
- 用户端监控：通常是指业务直接对用户提供的功能的监控。
二、监控指标
1、请求量
这是微服务最基本的监控指标之一，包括实时请求量和历史请求量。实时请求量可以用QPS（每秒查询次数）来衡量，反映了服务的实时负载情况。历史请求量可以用来分析服务的负载趋势，为容量规划提供依据。
2、响应时间
响应时间是衡量微服务性能的重要指标。它反映了服务处理请求的速度。通常，我们关注平均响应时间和P99响应时间（即99%的请求的响应时间）。如果响应时间过长，可能意味着服务存在性能瓶颈或者资源不足。
3、错误率
错误率是衡量服务稳定性的重要指标。它包括HTTP错误率（如4xx、5xx错误）和业务错误率（如业务逻辑错误、数据库查询错误等）。如果错误率过高，可能意味着服务存在bug或者配置问题。
4、服务可用性
服务可用性是衡量服务健康状态的重要指标。它反映了服务是否能够正常处理请求。如果服务可用性降低，可能意味着服务存在故障或者资源不足。
5、资源使用率
这包括CPU使用率、内存使用率、磁盘使用率等。这些指标反映了服务的资源消耗情况，如果资源使用率过高，可能意味着服务存在资源泄露或者配置不足。
6、数据库访问量
包括数据库连接数、SQL执行次数、数据库读写延迟等。这些指标反映了微服务对数据库的访问情况，可以帮助发现数据库性能瓶颈和访问模式问题。
三、监控维度
1、全局维度
这一维度关注整体的服务运行状况，包括整体的请求量、平均耗时以及错误率。这个维度的监控帮助我们对服务的整体运行情况有个全面的了解。
2、分机房维度
由于服务可能部署在多个机房，这个维度关注不同机房内的服务运行状况。不同机房的服务可能会因为地域等因素导致各种指标存在很大的差异，因此需要从机房维度进行监控。
3、单机维度
即使在同一个机房，由于机器采购批次等因素，同一服务在不同机器上的表现也可能存在差异。这个维度的监控帮助我们了解每台机器上的服务运行情况。
4、时间维度
这个维度关注服务在不同时间段的性能表现，例如一天前，一周前等。通过时间维度的对比，我们可以了解服务的性能变化趋势，以便更好地预测未来的负载和需求。
通过这四个维度的监控，我们可以更全面地了解微服务的运行状态和性能，从而及时发现并解决问题，保证服务的稳定和高效运行。
四、监控系统原理
- 数据采集：在监控时，要收集每一次调用的详细信息，包括调用的响应时间、调用结果、调用的发起者和被调用者。
- 数据传输：采集到数据后，要把数据通过网络传递给数据中心进行处理；
- 数据处理：数据中心再按照服务的维度进行聚合，计算出不同服务的请求量、响应时间、错误率等信息，并存储；
- 数据展示：最后通过大屏进行数据展示。
1、数据采集
通常有两种方式：
- 主动上报，在处理数据时，服务代码将处理结果和相关信息主动传给监控系统；
- 日志分析，通过分析服务接口的调用日志，采集监控系统需要的信息；
无论哪种方式，要先确认采集频率，采样频率关系着数据实时性和精确度。频率越高，数据实时性和精确度越高，但性能压力也越大。过高的采样频率会导致系统写入磁盘的IO过高，存储压力也会过大，进而影响程序的性能。所以设置合理的采集频率非常重要。最好采用动态频率，系统比较空闲时间加大采样率，系统任务比较重时，减少采样频率，以减少系统的运行压力。
2、数据传输
数据传输最常用的方式有两种：
- UDP传输，这种处理方式是数据处理单元提供服务器的请求地址，数据采集后通过UDP协议与服务器建立连接，然后把数据发送过去。
- Kafka传输，这种处理方式是数据采集后发送到指定的Topic，然后数据处理单元再订阅对应的Topic，就可以从Kafka消息队列中读取到对应的数据。
无论采用哪种传输方式，数据格式都十分重要，尤其是对带宽敏感以及解析性能要求比较高的场景，一般数据传输时采用的数据格式有两种：
- 二进制协议，最常用的就是PB对象，它的优点是高压缩比和高性能，可以减少传输带宽并且序列化和反序列化效率特别高。
- 文本协议，最常用的就是JSON字符串，它的优点是可读性好，但相比于PB对象，传输占用带宽高，并且解析性能也要差一些。
3、数据处理
数据处理是对收集来的原始数据进行聚合并存储。数据聚合通常有两个维度：
- 接口维度聚合，这个维度是把实时收到的数据按照接口名维度实时聚合在一起，这样就可以得到每个接口的实时请求量、平均耗时等信息。
- 机器维度聚合，这个维度是把实时收到的数据按照调用的节点维度聚合在一起，这样就可以从单机维度去查看每个接口的实时请求量、平均耗时等信息。
聚合后的数据需要持久化到数据库中存储，所选用的数据库一般分为两种：
- 索引数据库，比如Elasticsearch，以倒排索引的数据结构存储，需要查询的时候，根据索引来查询。
- 时序数据库，比如OpenTSDB，以时序序列数据的方式存储，查询的时候按照时序如1min、5min等维度来查询。
4、数据展示
微服务监控系统的数据展示通常是通过监控仪表板来实现的。在这个仪表板上，可以展示各种监控维度的重要指标。
一般来说，数据展示会包括如下内容：
（1）实时数据
展示微服务的实时运行数据，例如当前的请求量、响应时间、错误率等。这些数据通常以图表或者数字的形式直观展示，便于快速了解服务状态。
（2）历史数据
通过折线图、柱状图等形式，展示微服务在过去一段时间内的性能变化趋势。这样可以观察到服务的负载变化，以及是否有性能瓶颈或者故障发生。
（3）告警提示
当某个监控指标超过预设的阈值时，监控系统会产生告警提示。这些数据展示通常会比较醒目，以便快速发现并处理问题。
服务详情：通过点击仪表板上的某个服务，可以展示该服务的详细信息，包括请求量、响应时间、错误率的详细数据，以及该服务所调用的其他服务和被调用的情况等。
（4）自定义视图
根据用户需要，可以选择展示特定的监控维度和数据，定制符合自己需求的监控视图。
请注意，上述描述的一般性数据展示方式可能会因不同的监控系统和工具而有所差异。实际使用中，建议参考具体监控系统的用户手册和操作指南，以获得更详细和准确的信息。
五、总结
服务监控在微服务改造过程中的重要性不言而喻，没有强大的监控能力，改造成微服务架构后，就无法掌控各个不同服务的情况，在遇到调用失败时，如果不能快速发现系统的问题，对于业务来说就是一场灾难。
搭建一个服务监控系统，涉及数据采集、数据传输、数据处理、数据展示等多个环节，每个环节都需要根据自己的业务特点选择合适的解决方案。
六、从零开始学架构：照着做，你也能成为架构师
京东购买链接：从零开始学架构：照着做，你也能成为架构师(博文视点出品)
在很多人眼中，架构师极其神秘，每天做什么，需要具备哪些能力，众说纷纭、莫衷一是。在我看来，架构师虽然是一个技术职位，但综合能力要求很高，是胸怀理想的现实主义者，是团队中的技术领导者，需要具备突出的软硬技能。许多人想成为架构师，却不得其法，本书提纲挈领，从概念到模式并结合实战，为我们掀开神秘面纱，展示架构师的全景视图，相信会成为很多工程师进阶架构师的入门宝典。可惜当初我当架构师的时候，没有这样接地气的好书，如今的同行们有福了！
1、作者简介
互联网资深技术专家，十多年技术老兵，目前带领多个研发团队，承担架构设计、架构重构、技术团队管理、技术培训等职责；专注于开源技术、系统分析、架构设计，对互联网技术的特点和发展趋势有较深入的研究，对系统解耦、高性能、高可用架构有丰富的经验。
2、内容简介
架构设计是技术人员成长和晋升过程中必须掌握的技能，但目前业界缺乏架构师学习和培养方面体系化的知识和实践的指导，本书结合作者多年在架构设计方面的学习、思考、实践，提出了完整的一套架构设计方法论，包括什么是架构、架构设计的目的、架构设计原则、架构设计流程、架构设计模式和技巧、互联网公司技术演进等内容。这套架构设计方法论适合不同行业，比如互联网、企业应用等；也适合不同的技术领域，比如后端架构设计、前端架构设计、客户端架构设计、测试平台架构设计、运维平台架构设计等。
本书由浅入深地阐述了架构设计的相关内容，比较适合以下类型的读者：
- 没有架构设计经验，但对架构设计非常有兴趣，希望学习架构设计技术，提升技术能力，成为“大厂面霸”的读者；
- 已经尝试了一些架构设计，但挖了各种“坑”或踩了各种“坑”，希望知道“为什么”的技术人员；
- 具备一定的架构设计经验，想进一步系统化地提升架构设计能力，成为令人羡慕的“高级技术专家”“资深技术专家”的读者。
微服务架构之路
微服务架构之路1，服务如何拆分？使用微服务的注意事项？
微服务架构之路2，一文讲透微服务核心架构（注册中心、服务通信、服务监控、服务追踪、服务治理）
🏆哪吒多年工作总结：Java学习路线总结，搬砖工逆袭Java架构师。
华为OD机试 2023B卷题库疯狂收录中，刷题点这里
刷的越多，抽中的概率越大，每一题都有详细的答题思路、详细的代码注释、样例测试，发现新题目，随时更新，全天CSDN在线答疑。
版权归原作者 哪 吒 所有， 如有侵权，请联系我们删除。