本文实用于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 |
ebpf | cpu/network profile, sql query, fs profile(etx4/xfs) | ebpf agent( skeywalking ravor), 除cpu profile外要自行扩大 |
jdbc client | virtual db,连接池状态等 | Java agent |
通过以上各种维度的监控能够全面把握MySQL的运行状态,并能在呈现性能问题时通过ebpf agent(Ravor)近程执行profiling剖析。基于ebpf的监控形式在DBaaS-MySQL容器化部署的形式下十分不便而且性能影响也最小。
限于篇幅起因,在后续的文章中会具体解说每种监控形式的配置和相干扩大代码。
Enjoy GreatSQL :)
文章举荐:
乏味的SQL DIGEST
ulimits不失效导致数据库启动失败和相干设置阐明
MGR及GreatSQL资源汇总
GreatSQL MGR FAQ
在Linux下源码编译装置GreatSQL/MySQL
## 对于 GreatSQL
GreatSQL是由万里数据库保护的MySQL分支,专一于晋升MGR可靠性及性能,反对InnoDB并行查问个性,是实用于金融级利用的MySQL分支版本。
Gitee:
https://gitee.com/GreatSQL/GreatSQL
GitHub:
https://github.com/GreatSQL/GreatSQL
Bilibili:
https://space.bilibili.com/1363850082/favlist
技术交换群:
微信:扫码增加GreatSQL社区助手
微信好友,发送验证信息加群
。