注:本文适用于SkyWalking v9.1.0。


SkyWalking简介

SkyWalking是一个分布式系统的应用程序性能监视(APM)工具,专为微服务、云原生架构和基于容器(K8s)架构而设计。当前版本具备了全路径跟踪、指标采集、日志记录等功能,并对多种编程语言及平台(Java/C/C++/Go/Rust/Node/PHP等)提了采集代理(agent),并对service mesh(stio + Envoy )提供支持。

SkyWalking的对比其他常用监控工具  Zabbix、Prometheus、ELK、Zipkin、Jaeger等有以下特点:

优点

  1. 一站式全功能的解决方案,支持全路径跟踪、指标采集和日志记录。当前版本仍需依赖外部存储组件(H2/MySQL/PostgreSQL/Elasticsearch)。项目自带的BanyanDB正在积极研发中,正式发布后可不再依赖外部存储。

  2. 非侵入式为主的指标采集方式,一般不需要代码级的调整,对几十种主流Java组件都有官方插件支持。Java程序通过javaagent+bytebuddy实现动态生成监控插件,Native应用则通过ebpf实现类似功能。

  3. 标准协议的支持,支持OpenTelemetry、Kafka、estapi、Zabbix多种行业规范或者事实标准的接入,方便各种应用的对接。

  4. 微服务和云原生的支持,对基于容器(K8s+Java)的全链路监控,支持ebpf agent 通过sidecar注入。

缺点

  1. agent不够完善,OpenTelemetry采集方式目前需要用Prometheus node expoter采集,再通过Opentelemetry collector转换后导出传导SkyWalking oap.

  2. 比Zabbix等传统监控工具缺少自动探测和资产管理功能,增加自定义监控指标需要手工修改MAL配置文件,不能通过UI配置。

  3. 官方文档不完善,只是相当于参数手册加功能列表,但缺乏各种监控场景的配置指引。

  4. ebpf agent虽然是亮点但实现很初级,最新发布版(0.2.0)只支持cpu profiling。git最新代码已增加network profiling。功能均为Go和C混合的硬编实现,用户自行扩展不便。硬编码的ebpf代码也导致对Linux内核的兼容性差。gcc4.5+在不同的优化级别(O?)产生的符号命名不一样,会导致ebpf启动失败。

MySQL的监控方案

监控项类别监控项监控方式
主机或vm的OS指标cpu 内存  磁盘Zabbix agent/Prometheus exporter + otl collect
MySQL 日志日志文件Filebeat httpoutput + SkyWalking http json api
ebpfcpu/network profile, sql query, fs profile(etx4/xfs)ebpf agent( skeywalking ravor), 除cpu profile外要自行扩展
jdbc clientvirtual db,连接池状态等Java agent

通过以上各种维度的监控可以全面掌握MySQL的运行状态,并能在出现性能问题时通过ebpf agent(Ravor)远程执行profiling分析。基于ebpf的监控方式在DBaaS-MySQL容器化部署的方式下非常方便而且性能影响也最小。

限于篇幅原因,在后续的文章中会详细讲解每种监控方式的配置和相关扩展代码。

Enjoy GreatSQL :)


《深入浅出MGR》视频课程

戳此小程序即可直达B站

https://www.bilibili.com/medialist/play/1363850082?business=space_collection&business_id=343928&desc=0



文章推荐:


想看更多技术好文,点个“在看”吧!

Logo

K8S/Kubernetes社区为您提供最前沿的新闻资讯和知识内容

更多推荐