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 数据进行互相关联打标，尽可能减少数据孤岛，通过多数据源的关联提升整体可观测性。并利用可观测性尽可能缩短线上故障排查时间，为业务服务恢复争取时间。
本文为阿里云原创内容，未经允许不得转载。