一文带你读懂:云原生时代业务监控|社区征文

2023总结

picture.image

1、前言

对业务来说,完备的应用健康性和数据指标的监控非常重要,通过采集准确的监控指标、配置合理的告警机制,我们能够提前或者尽早发现问题,并做出响应、解决问题,进而保证产品的稳定性,提升用户体验。

过去单体服务或者微服务时代,对我们 JavaBoy 来说,或是通过 SpringBoot 的 Actuator 模块实现了本地应用的监控与管理,或者通过 javamelody 对 Tomcat 应用进行线程级别的监控(参考我另一篇文章:《一文看懂:性能监控神器JavaMelody》)。

如今进入到云原生时代,过去的一些监控在 k8s 应用部署的环境下,或是由于设计思路不同,或者开源社区不兼容等原因,变得不可用,这一下子让很多开发者变的束手无策起来。

在 k8s 应用部署的大背景下,下面将围绕着“建设云原生的可观测性监控指标”的主题,一起探讨“架构和业务层面可以做的事情”,最终得出建设业务监控系统平台的概念。

2、背景

picture.image 在微服务和容器化时代,我们开始大面积拆分小应用,将业务分割为一个个小系统,通过 Docker 来独立部署每个小系统,但遇到了容器编排、应用扩缩容、升级繁琐、容器难管理等诸多问题;

picture.image

进入云原生时代后,Kubernetes 横空出世,帮助运维同学高效实现容器集群的管理;

对于开发同学来说,我们所负责的业务系统经过上云部署之后,如果需要进行应用健康性和业务数据监控,会遇到哪些可观测性监控的问题,又应该如何解决呢?

3、云原生破局利剑与理论依据

必须先提及两个基础概念:Promutheus 和 可观测性理论。

Prometheus 不必多说,它就是云原生监控的破局利剑,是兵器;可观测性理论就是我们监控的理论来源,是兵法;有了兵法和兵器,我们才能披荆斩棘,解决实际问题。

Prometheus

Prometheus 受启发于 Google 的 Brogmon 监控系统(相似的 Kubernetes 是从 Google 的 Brog 系统演变而来)。

2012 年开始由前 Google 工程师在 Soundcloud 以开源软件的形式进行研发,并且于 2015 年早期对外发布早期版本。

2016 年 5 月继 Kubernetes 之后成为第二个正式加入 CNCF 基金会的项目,同年 6 月正式发布 1.0 版本。

2017 年底发布了基于全新存储层的 2.0 版本,能更好地与容器平台、云平台配合。

picture.image

可观测性理论:

我们通过图表来定义描述 Metrics, tracing, logging 三个概念,进而明确监控的作用域,使各名词的作用范围更明确。 

picture.image

(1)Metric:特点是可累加和有原子性,每个都是一个逻辑计量单元,或者一个时间段内的柱状图。

例如:队列的当前深度可以被定义为一个计量单元,在写入或读取时被更新统计;输入 HTTP 请求的数量可以被定义为一个计数器,用于简单累加;请求的执行时间可以被定义为一个柱状图,在指定时间片上更新和统计汇总。

(2)Logging:特点是描述一些离散的(不连续的)事件。

例如:应用通过一个滚动的文件输出 debug 或 error 信息,并通过日志收集系统,存储到 Elasticsearch 中;审批明细信息通过 Kafka,存储到数据库(BigTable)中;又或者,特定请求的元数据信息,从服务请求中剥离出来,发送给一个异常收集服务,如 NewRelic。

(3)Tracing: 特点是它在单次请求的范围内,处理信息。任何的数据、元数据信息都被绑定到系统中的单个事务上。

例如:一次调用远程服务的 RPC 执行过程;一次实际的 SQL 查询语句;一次 HTTP 请求的业务性 ID。

4、云原生应用特点

云原生:云原生是一种专门针对云上应用而设计的方法,用于构建和部署应用,以充分发挥云计算的优势,比如我们耳熟能详的“腾讯云”、“阿里云”等。 

云原生技术包含了一组应用的模式,用于帮助企业快速,持续,可靠,规模化地交付业务软件。

云原生由微服务架构,DevOps 和以容器为代表的敏捷基础架构组成。援引宋净超同学的一张图片来描述云原生所需要的能力与特征:

picture.image

因此,借由云原生技术可以实现快速和频繁的构建、发布、部署,结合云计算的特点实现和底层硬件和操作系统解耦,可以方便的满足在扩展性,可用性,可移植性等方面的要求,并提供更好的经济性。

云原生也带给开发模式、系统架构、部署模式和基础设施巨大的改变,这些改变代表着云原生应用的特点

picture.image

开发模式:效率要求更高,随着 DevOps 模式普及,规划、开发、测试、交付的效率越来越高。

系统架构:系统更加复杂,架构从开始的一体化到分层模式,到微服务架构。

部署模式:环境动态性增强了,容器化部署模式动态性增强,使得应用实例生命周期变短,更加可控制。

基础设施:上下游依赖更多了,依赖各种云原生应用和各类云厂商的产品,上下游变多了。

5、云原生监控的痛点与目标使命

中小企业往往是在公有云上部署自己的云原生应用,因此国内的五大云厂商(阿里云、华为云、腾讯云、天翼云和亚马逊云)都会定时采集用户反馈。我们梳理处下面五个常见的痛点:

picture.image

这些痛点,我们其实从新闻里也有听到过,对于 toC 用户来说,一些大故障,我们可以开诚布公,通过公开发文来解决舆论压力,比如:光缆被挖断;但是对于 toB 客户,云厂商面临的压力就很大,频率较高,这类产品要分类分级。

云原生监控的目标:监控体系做得好,保证一切都是可控的。

picture.image

我们可以从三个方面入手:应用层面、服务层面、用户层面。

(1)应用层面:及时覆盖发现问题,进而修复问题

(2)服务层面:服务健康性感知,全链路联动发现、分析和处理问题

(3)用户层面:化被动为主动,提升用户使用质量

6、云原生业务立体化监控方案

picture.image

云原生业务立体化监控方案针对了七个环节进行监控:

  1. 拨测监控:业务质量监控;

  2. 前端性能监控:小程序等;

    举例子:健康码白屏了,前端也要重点关注的

  3. 网络质量监控:国内外的网络环境差异较大

    举例子:俄乌冲突下的居民用网问题

  4. 后端指标监控/链路监控:后端比较关注

  5. 服务运营日志:中间件监控(Redis、Kafka 等)

  6. 云资源监控:数据库、云硬盘、服务器资源、CPU、带宽 IO 等。

    其实开源社区有非常多的组件支持,让数据库、中间件直接接入,就可以实时监控了

  7. 性能压测:金丝雀发布演练

以上七个环节,每个环节都有自己的侧重点,下面我们逐个分析。

6.1 业务拨测

picture.image

业务拨测: 依托云厂商专有的服务质量监测网络,利用分布于全球的服务质量监测点,对网站、域名、后台接口等进行周期性监控,通过查看可用率和延时随时间区间变化来帮助分析站点质量情况。。

拨测原理: 云厂商利用分布全球的检测网络(例如,腾讯云提供全球 200+城市的 1000+拨测点资源),提供模拟终端用户体验的拨测服务,来满足我们对未来、浏览、传输、协议、流媒体的周期性监控的拨测场景;

好处: 以黑盒视角重点保障关键域名、服务功能,从客户端最直接感受,做质量管控,比如下面六种场景:

(1)服务质量优化

从全球模仿用户访问服务,获取各种业务场景(电商网站性能、API 测试等)的服务质量指标。

(2) 发布验证

系统升级或新功能发布后的可用性和性能验证,提前发现业务打不开、运行速度慢等用户体验差的问题。

(3) CDN 质量评估

通过主动式拨测定位 CDN 的服务质量,并提供详细数据支撑,优化业务的用户体验。

(4) 防劫持和防篡改

监测域名劫持、流量劫持、页面篡改等行为,保护应用流量和品牌形象。

(5) IPV6 升级改造

对比验证 IPV6 改造后相对 IPV4 提升效果,以及全国各地区网络连通性等监测数据。

(6) 竞品分析

拨测不同竞品应用的性能数据,掌握应用在行业内重点竞争对手中的优劣势。

6.2 前端监控 &小程序监控

picture.image

前端监控:用户终端实际用户操作行为与前端服务质量监控,低门槛、场景化,主动进行行为分析。

应用场景:

  1. 页面性能分析和优化
  2. 前端服务服务异常监控:JS/web 元素异常
  3. 用户行为分析和运营数据处理

6.3 网络质量监控

picture.image 网络质量监控(尤其是核心网络质量)对业务健康性是至关重要的。

网络质量作为服务可用的第一关,对用户体验影响深远,而监测网络质量的方式其实并不复杂。一台 PC,通过 Ping、Dig、Telnet 等简单的命令行指令,就能快速发现网络问题。

其中,网络监控分为网络设备交换机、路由器等监控,光缆线路监控,网络连通性探测监控等。

picture.image

以腾讯云为例子,腾讯云提供全地域,运营商网络质量对比一目了然。能够帮助用户快速发现区域性、运营商网络问题,及时修复,最大化降低业务影响。

目的:云上网络质量监控,能够确保业务核心网络和骨干网的健康性监控、网络质量探测分析,业务调度容灾。

场景:有些产品对网络要求比较高,尤其是出海业务。因为国内大可不必太担忧,但是国外(中东打仗了,俄乌冲突)很多意外,基础设施上不了,导弹忽然就到了,网络就断了,非常的不稳定;另外,国外会有很多运营商,整体不是一个可控的网络

6.4 后端监控-自定义指标

picture.image

后端监控:Prometheus 提供了非常多的开源组件的指标监控实现,让我们能够开箱即用的使用社区开源能力。

但也有部分业务场景,需要我们研发侧自行定义的,Prometheus 提供了 4 种不同的度量指标类型(metric type):Counter(计数器)、Gauge(仪表盘)、Histogram(直方图)、Summary(摘要)。

结论:针对不同的服务场景,我们可以定义不同的指标监控,如果服务调用量、卡顿率、延迟分布监控、再比如服务价格性能、垃圾回收性能监控等。Prometheus 协议:已经成为一个标准。对云资源进行指标监控。

应用场景:容器、kafka、db,各大云厂商监控支持 Prometheus 协议,且支持微服务自定义监控架构设计。

6.5 后端监控-链路跟踪

picture.image

链路跟踪:专注于后台服务 APM(应用性能管理),应用性能观测(Application Performance Management ,APM)是一款应用性能管理平台,从服务代码层面实现全链路监控:调用量、成功率、耗时、异常问题详情。

作用:后端服务全链路监控、服务异常及时关联定位分析、业务活动重保护航、服务主动优化治理、业务成本优化和预算评估。

场景:大部分情况,我们是通过 Skywalking 进行 traceid 的链路传递和监控。

6.6 云资源监控

picture.image

云资源监控:专注于云资源:容器、虚拟机、存储、中间件等实时监控,更加倾向于运维保障效率、软硬件性能和可用性监控。

举个简单例子:云数据库产品(以腾讯云 Mysql 为例子)

过去的 DB 部署,是由 DBA 专门负责的,通过 DBA 手动敲指令盯着 Mysql 性能的方式来监控;

而如今现在的 DB 上云之后,Paas 交付给客户的只有一个 DB 实例了,监控手段更加多样化,可以通过云监控组件,可视化的了解各类数据库负载指标。

picture.image

监控指标

可以通过大盘方便快捷的监控我们的数据库实例的四类指标:

【1】资源监控:CPU/硬盘/网卡/内存

包括不限于下面指标:CPU 利用率、内存利用率、内存占用、磁盘利用率、磁盘使用空间、磁盘占用空间、IOPS、IOPS 利用率、内网出流量、内网入流量

picture.image

【2】引擎监控:数据库连接/表/InnoDB/访问响应

数据库连接包括了:每秒执行操作数、每秒执行事务数、连接数利用率、当前打开连接数、最大连接数等;

访问响应包括了:慢查询数、全表扫描数、查询数、更新数、删除数、插入数、覆盖数、总请求数、查询使用率;

表:临时表数量、等待表锁次数

InnoDB:缓存命中率、缓存使用率、读磁盘数量、写磁盘数量、fsync 数量、当前 InnoDB 打开表的数量等;

picture.image

【3】引擎监控的扩展指标

包括了连接数、InnoDB 写入读出量等

picture.image

【4】部署监控

由于大部分企业级应用都追求高可用性,往往会采取一主多从的部署模式,因此存在主从延迟等问题,云监控能够帮助我们方便快捷的监控到这类指标。

picture.image

6.7 性能压测

picture.image

全链路性能压测:借助云厂商的工具,丰富我们的测试场景:从简单模式(GET/POST/PUT/PATCH/DELETE)、脚本模式、自定义录制。才有 box/ship 方案,支持压测引擎动态插拔,通过灵活的第三方压测引擎,丰富我们的测试场景。

我们研发开发阶段,往往会通过 Jmeter 等工具模拟并发请求的场景;进入云原生时代,这种压测也可以在发布阶段后,给业务进行压测。

目的:新系统上线性能压测、业务峰值稳定性测验、业务容量规划评估、技术迭代升级验证。

6.8 建设业务质量监控

picture.image

业界认可的服务监控模型如上所示:越往上的指标越少(容易辨别是什么问题),越往下约多(分析维度多)。

建立云原生业务质量监控的步骤如下:

  1. 确定业务监控目标:明确需要监控的业务指标,如响应时间、成功率、用户满意度等。
  2. 选择合适的监控工具和技术:根据业务监控目标,选择合适的监控工具和技术,如 Prometheus、Grafana、InfluxDB 等。
  3. 设计监控指标和监控策略:根据业务监控目标和监控工具,设计合适的监控指标和监控策略,如告警、日志记录、性能监控等。
  4. 收集和整合监控数据:收集和整合监控系统中的数据,包括告警信息、日志记录、性能监控数据等,并进行数据清洗、汇总和分析。
  5. 建立监控告警机制:根据监控数据和分析结果,建立监控告警机制,及时发现和解决问题。
  6. 优化监控流程和系统:对监控系统进行优化和改进,提高监控效率和准确性。
7、总结

随着互联网业务的快速发展,云原生应用正在成为互联网应用的主流架构模式。云原生应用具有轻量、灵动、可伸缩、易于维护等特性,非常适合高并发、大流量的业务场景。

业务监控是云原生应用的关键能力之一,可以帮助运维团队实时了解应用的运行状态,发现和解决问题,确保应用的稳定性和可靠性。

总之,云原生时代的业务监控将更加智能化、高效化和可视化,帮助运维团队更加高效地管理和维护云原生应用,确保应用的稳定性和可靠性。朋友们,如果说编程已经无法提现我们的专业能力,那么云原生知识栈更应该要学起来。

InfoQ文章首发:https://xie.infoq.cn/article/4d336be3147bdb66a264155d7

80
0
0
0
关于作者
相关产品
评论
未登录
看完啦,登录分享一下感受吧~
暂无评论