Java|行业 SaaS 微服务稳定性保障实战( 五 )


Prometheus Exporter
除了 ARMS 等商业化产品外 , 我们也积极开源 , 拥抱 Prometheus 社区 , 接入了较多 Exporter 组件 , 包括 SSLExport 和 BlackBoxExporter , 极大提升了整个系统的可观测性 。 Exporter 可以用于黑盒探针 , 比如探测 HTTP 请求是否正常、HTTPS 请求是否正、DNS 是否正常、TCP 是否正常等 , 典型的使用场景是探测当前服务入口地址是否正常 。 SSL 证书异常更为常见 , 通过 SSLExporter 可以定期轮询证书是否过期 , 进一步提升可观测性 。
成本观测
除了日常服务可观测 , 我们还实践了成本可观测等优化项目 。 对于云原生环境 , 可以利用 kubecost 开源组件进行成本优化 , 直接输出资源使用率以及报表等 , 反馈给研发人员进行优化 , 甚至可以用来发现 CPU 和内存是否呈正常比例 , 尽可能实现资源合理分配 。
未来畅想 基于 eBPF 的 Kuberneters 一站式可观测性
eBPF 云原生组件愈发进入到深水区 , 很多问题不再只停留于应用层面 , 更多地会出现在系统层面和网络层面 , 需要更加底层的数据进行追踪和排障 。 利用 eBPF 可以更好地回答 Google SRE 提出的比如延迟、流量、错误率、饱和度等黄金指标出现的问题 。
比如 Redis 进行闪断切换的过程中 , 可能会形成 TCP 半开连接 , 从而对业务产生影响;再比如 TCP 连接刚建立时 , backlog 是否合理等 , 都可以通过数据得到相应结论 。
Chaos-engineering
Chaos-engineering 混沌工程鼓励和利用可观测性 , 试图帮助用户先发制人地发现和克服系统弱点 。 2020 年 6 月 , CNCF 针对可观测性提出了特别兴趣小组 。 除了三大支柱外 , CNCF 还提出了混沌工程和持续优化 。
对于混沌工程是否能划分在可观测性里 , 当前社区依然存在疑议 , 而 CNCF 的可观测性特别兴趣小组里已包含了 chaos-engineering 和持续优化 。 我们认为 , CNCF 的做法有一定道理 , 混沌工程可以被认为是一种可观测性的分析工具 , 但其重要前提是可观测性 。 试想 , 如果在实施混沌工程过程中发生故障 , 我们甚至都无法确定它是否由混沌工程引起 , 这也将带来极大麻烦 。
因此 , 可以利用可观测性尽可能缩小爆炸半径、定位问题 , 通过 chaos-engineering 持续优化系统 , 提前发现系统薄弱点 , 更好地为系统稳定性保驾护航 。
OpenTelemetry
OpenTelemetry 是一个通过多个项目合并而来的开源框架 。 我们需要更加面向终端研发统一的可观测性视图 , 比如期望将 logging、metrics 和 tracing 数据进行互相关联打标 , 尽可能减少数据孤岛 , 通过多数据源的关联提升整体可观测性 。 并利用可观测性尽可能缩短线上故障排查时间 , 为业务服务恢复争取时间 。
本文为阿里云原创内容 , 未经允许不得转载 。