微服务监控案例之一
| 编辑推荐: |
| 本文来自于cnblogs，分散在各个服务器上的日志怎么处理？如何快速定位问题？ 如何跟踪业务流的处理顺序和结果等等？针对这些问题展开的下文。 |
首先，您需要了解什么是微服务架构设计，同时了解相关微服务与Docker介绍， 微服务架构的本质，是把整体的业务拆分成很多有特定明确功能的服务，通过很多分散的小服务之间的配合，去解决更大，更复杂的问题。对被拆分后的服务进行分类和管理，彼此之间使用统一的接口来进行交互。
微服务的特点决定了功能模块的部署是分布式的，以往在单应用环境下，所有的业务都在同一个服务器上，如果服务器出现错误和异常，我们只要盯住一个点，就可以快速定位和处理问题，但是在微服务的架构下，大部分功能模块都是单独部署运行的，彼此通过总线交互，都是无状态的服务，这种架构下，前后台的业务流会经过很多个微服务的处理和传递，我们难免会遇到这样的问题：
分散在各个服务器上的日志怎么处理？
如果业务流出现了错误和异常，如何定位是哪个点出的问题？
如何快速定位问题？
如何跟踪业务流的处理顺序和结果？
我们发现，以前在单应用下的日志监控很简单，在微服务架构下却成为了一个大问题，如果无法跟踪业务流，无法定位问题，我们将耗费大量的时间来查找和定位问题，在复杂的微服务交互关系中，我们就会非常被动。
以下基于微服务监控案例之一
监控原则：
将更多的时间用于编写对数据指标的意义进行分析的代码，而不是用于编写收集、移动、保存以及显示指标的代码。
让关键业务指标的延迟降低到人类注意力的持续时间以下 （约10秒左右）。
请验证你的衡量系统是否具有足够的精确度与准确度，并将收集到的响应时间数据以柱状图表示。
对于比目前监控中的系统（与服务）需要更高可用性与可伸缩性的系统进行监控。
对分布式的、短期的、“cloud native”、容器化的微服务的监控进行优化。
让指标与你的模型相一致，以便理解它们之间的关系
问题与需求
我们想要价值
实时抓取数据，实时分析统计，生成统计和报表
可视化的报表系统，更快的了解系统运行状态
搜索功能，快速的定位关键问题
数据挖据，利用优秀的数据分析能力和数据模型，进行数据预测
正文到此结束
热门推荐
相关文章
近期评论
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
搞个gitee的项目
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
