共计 2242 个字符，预计需要花费 6 分钟才能阅读完成。
为什么要有监控零碎
在我从业 4 年多的历程中, 大部分工夫是没有接触监控零碎的或者没有发现监控零碎的重要性. 这很失常, 因为 IT 界的演变实质上是从简略到简单从单节点到集群, 从裸金属到齐全托管云服务的过程.
我工作过程中接触到的技术演变大抵也是就如上, 也大抵经验了这几个阶段.
第一阶段:
Java SSM 单体利用 +dubbo rpc
- 手动在单体利用所在的服务器上一一手动 shell 检索数据
- 没有对单体利用的节点衰弱, 性能, 压力监控
- 没有链路追踪
这是最根底的服务, 勉强有了微服务的概念实质上还是单体, 没有任何的察看零碎概念. 然而这个在当年还是够用的, 因为单体利用这时数量无限, 即便扩散到各个服务器然而手动查问还是勉强应酬.
第二阶段:
Java Spring Cloud 微服务, 部署到裸金属上
- 手动在单体利用所在的服务器上一一手动 shell 检索日志数据
- 自带简略的单体利用的节点健康检查和容错
- 自带简略的链路追踪
这时有了根本的服务拆分和微服务的雏形了, 然而还没有做到服务节点的动静伸缩. 这时节点的数量比拟多了, 手动检索日志信息开始有点费劲, 产生了一些察看零碎的需要和必要性.
第三阶段:
Java Spring Cloud 微服务, 应用 K8S 编排
- 日志数据依照节点的类型做了集中的存储, 存储在 ES 中, 在 Kibana 检索集中起来的数据, 不用到每个容器中检索了
- 自带高级的单体利用的节点健康检查和容错
- 自带高级的链路追踪
- 除了日志的检索降级了, 其余的性能比方状态主动感知齐全没有
这时有了动静伸缩了, 手动检索节点的日志数据变得不可能, 然而察看零碎没有成形. 只好通过 ELK 技术集中存储日志而后搜寻, 察看零碎变成了十分重要的平台需要
第四阶段:
齐全上云, 应用 Serverless+K8S 容器话. 并且语言不再是 java 一种而是变成了 Java/Python/Node/Go
- 根本没有了节点的概念, 无奈晓得确切的服务节点拓扑和数量,ELK 的简略应用只能解决分布式日志源头聚合和检索的问题
在这个时候, 察看零碎曾经变成了刚需, 没有好的察看零碎团队很难直观的晓得当下的服务压力和资源消耗详细情况, 这样就会重大当初团队的开发能力和故障反馈能力.
总结
在容器化, 云原生,serverles 等新技术的大量应用事实下, 以往的手动 / 半手动日志检索曾经齐全不能持续产生任何价值.
它给整个开发团队提出了如下挑战
不单是是日志的检索. 新的技术的应用也对当初的后端服务提出了一些新的要求, 比方性能监控, 故障主动感知, 链路追踪, 高压力下的主动弹性解决等等. 在这个场景下, 一个好的察看零碎必须做到这些根本的性能, 不单是日志收集和检索
它出现给咱们那些方面的信息
首先是零碎多维的状态信息:
- 各种类型的日志数据. 做到分布式收集 -> 集中存储 -> 数据索引 -> 灵便检索
服务的指标数据
- 服务压力感知和指标数据
- 服务衰弱度监控
- 各服务间相互协作和调用时的性能状况
APM 数据
- 随工夫线倒退而产生的外界压力曲线以及这些工夫点上对应的平台的性能体现
- 用户的应用爱好和周期性法则
服务 uptime
- Serverless 服务的生产时长, 单个申请的服务耗时
- 容器的全生命周期中服务时长
- 裸金属服务器的启停工夫
其中 ELK 技术栈大抵能解决大部分的问题
不过链路追踪和更丰盛的可视化展示.ELK 做的不是 100% 的完满, 它须要在跨语言跨技术体系的日志设计这个顶层的设计上联合最合适的组件实现链路追踪. 同时数据的可视化上 Kibana 有时略显繁多. 业界个别应用 ELK+Grafana+Prometheus+ 云服务商的监控 (比方 AWS CloudWatch) 实现更加平面的 日志 / 指标收集 -> 数据存储 -> 数据的剖析 (解析, 提取, 索引..)-> 数据的高级感知 (服务链路流程感知, 主动告警, 主动扩缩容, 主动压力调配, 主动的资源事后筹备)-> 数据的展示(图形化展现, 数据检索, 趋势剖析)
它怎么展示
在数据可视化上, 个别咱们喜爱叫它 ’ 大屏 ’, 对于展现的技术个别这个没有规范, 业界比拟风行的是 Kibana 或者 Grafana, 以 Grafana 绝对更加业余一些.
它须要那些数据
次要是如下的根底数据:
- 日志数据, 文本类型或者流式传输都可, 不限于日志的传输模式, 然而日志是要有格局或者能被预格式化的, 这样不便自动化 / 人工的解读. 单条日志是单个事件, 代表某个工夫点某个服务做了什么, 是
点信息 - 服务资源指标, 这方面的数据有大量是有具体格局并做了记录的的, 比方 MySQL 慢查问日志, 然而大部分是实时的非记录的, 比方服务器的 CPU 资源占用默认就没有日志记录, 这也是
点信息. - 服务器, 服务节点等的心跳信息, 用于确定工夫点的衰弱, 这也是
点信息. - 服务链路中的
traceId, 如果没有traceId或者相似的追踪定位点, 那么一个网络申请过去通过了那些点是没法做工夫前后程序的链路连贯的, 也就是点无奈连成线. 这是针对某个流程, 观测其演变过程, 前因后果咱们成为线信息.
上述的根底信息从产生数据的源进行获取, 比方 MySQL,Serverless 实例, 容器化节点, 云厂商专有服务(SNS,SQS…)
在某个工夫窗口, 观测某些指标的法则, 以及指标与指标之间的分割咱们叫做 面信息. 基于上述的根底数据, 剖析服务间的协同情况, 将下面的线连成面才有可能能力造成服务间关联关系的感知.
对于整个平台全副服务的 点->线 -> 面的全局多维度感知和主动解决是一个好的察看零碎的实质诉求, 同时记录 面随工夫线的数据, 聚合为更加欠缺的 平面 察看平台是这个零碎的现实状态.
实现察看零碎的技术层次模型
本文原文链接: 察看零碎解决了什么它又须要什么
