DeepFlow 6.4 支持 TLS 握手消息解析以后,HTTPS 的全栈分布式追踪链路更精细了!
01
关于 TLS 握手
这里我们引用一张来自 bytebytego.com 的图,来展示 HTTPS 通信全过程:
从上图可以看到,为了完成一次 HTTPS 请求,客户端、服务端需要以此完成如下交互:
- TCP 三次握手:SYN、SYN-ACK、ACK
- TLS 握手和秘钥协商:三个到四个 TLS 协商消息,包括 Client Hello、Server Hello、Certificate、Key Exchange 等
- 应用层 HTTP 通信
01
DNS、TLS、HTTPS 全面覆盖
为了展示 DeepFlow 对 HTTPS 通信全过程的分布式追踪能力,我们让 ChatGPT 帮忙写了一个名为 golang-tls-demo 的演示进程。这个进程将会监听 48080 端口,在收到一个 HTTP 请求以后会向上游请求 https://deepflow.io 并将结果返回给客户端。
就是这样一个简单的 Demo 程序,我们来看看在 DeepFlow 的 AutoTracing 能力之下,精细到毛孔的分布式追踪效果:
从上图中可以看到,一次完整的通信涉及到:
- 客户端请求 golang-tls-demo
http://$ip:48080/test/golang/tls/demo
,耗时约 500ms - golang-tls-demo 发起一次 HTTPS 调用,包括 5 个请求
- DNS 请求 deepflow.io,耗时约 10ms
- TLS Client Hello、Server Hello 握手,耗时约 50ms
- TLS Cipher Spec、Key Exchange 握手,耗时约 50ms
- DNS 请求 deepflow.io,耗时约 1ms
- HTTPS 请求 deepflow.io,耗时约 50ms
实现这样的效果,只需要在 Host 上运行一个 deepflow-agent,不需要对 golang-tls-demo 做任何修改、也不需要重编译和重启。
注:TLS 握手仅 DeepFlow 企业版支持解析,其他调用企业版和社区版均支持。
03
K8s、KVM、物理网络一网打尽
DeepFlow 不仅能通过 eBPF 采集数据,也能使用 cBPF 获取 K8s 网卡、KVM 网卡、物理网络设备的流量,并展示在一张火焰图上:
04
持续剖析排查 TLS 热点
通常 HTTPS 通信相比 HTTP 会有更高的资源开销,此时我们也能进一步使用 DeepFlow 基于 eBPF 的持续剖析能力,查看 golang-tls-demo 的 CPU 火焰图,定位瓶颈函数:
看起来这个 ChatGPT 写的 Demo 性能瓶颈在系统调用上,即图中以 [k]
开头的函数。
05
彩蛋 - 对 mTLS 的支持
Istio 使用 mTLS(mutual TLS)来实现通信双方的双向校验。在 mTLS 场景下通信过程更为复杂,后续文章中我们将会展示 DeepFlow 在 Istio 环境中的分布式追踪能力。
06
什么是 DeepFlow
DeepFlow 是云杉网络开发的一款可观测性产品,旨在为复杂的云基础设施及云原生应用提供深度可观测性。DeepFlow 基于 eBPF 实现了应用性能指标、分布式追踪、持续性能剖析等观测信号的零侵扰(Zero Code)采集,并结合智能标签(SmartEncoding)技术实现了所有观测信号的全栈(Full Stack)关联和高效存取。使用 DeepFlow,可以让云原生应用自动具有深度可观测性,从而消除开发者不断插桩的沉重负担,并为 DevOps/SRE 团队提供从代码到基础设施的监控及诊断能力。
GitHub 地址:https://github.com/deepflowio/deepflow
访问 DeepFlow Demo,体验零插桩、全覆盖、全关联的可观测性。