可观测性｜使用Splunk 转发器实现容器overlay网络环境下的2-7层全局可观测性

小咩社长 2021-11-28

979

阅读提示｜本文大概3879字阅读需要6分钟

写在前面：

先解释下标题，本篇说的容器网络下的可观测性，并非指的是Splunk Observability cloud 产品，该产品专注云原生领域，但是目前只提供SaaS版本，这意味着不管你是公有云还是私有云环境下的容器环境，都需要外联云端才可以使用。产品很强很炫酷，有需要测试的可以后台私信。以下图片摘取官方Splunk Observability cloud实例。

现在都在说云原生可观测性，我们想一下在传统环境我们是怎么做可观测性的。由于可观测性的领域很庞大，仅从xiao咩目前所擅长的领域挑出以下三个简单说说：网络、应用服务和安全。先说网络的可视化这块主要是传统的NPM厂商，比如国内做网络分析起家的科来网络分析平台RAS，应用可视化接触比较多的比如天旦，安全这块主要是各个安全厂商推出的所谓的“态势感知”平台。随着可观测性的市场持续火热，大家都似乎不太满足自己只关注在一个领域，于是互相把产品线都抄的很全，360度全覆盖无死角。

如果想真的实现整个企业网络、应用服务、安全的可观测性，将是一笔很大的投入，毕竟要想看到的越多部署的探针就要越多，市面上有卖铁盒子、有卖软件，之前听过某个企业为了应对hw，一口气买了十几二十台的某厂商的铁盒子，想想一想得花多少钱。

以上简单分享下目前市面上产品的现状，并没有贬低的意思，一些头部的产品抛开价格不说，易用性还是不错的。说回咱们今天聊的splunk，splunk平台是一个高度可定制化的软件平台，可以在此平台基础上实现比如基础架构监控，企业安全SEIM、SOC平台建设、应用监控APM以及云原生可观测性。

回归正题

说回Splunk 转发器实现容器overlay网络环境下的2-7层全局可观测性这一主题，说下这篇文章的背景，是因为最近在某清洁能源用户那做Splunk SEIM平台建设项目，用户提出了个需求：我想监控下内网DNS服务器解析行为（是否请求恶意域名），解析日志输出到splunk，然后结合防火墙、IPS、WAF、AD、VPN、威胁情报等数据源做出基于用户级的网络访问行为关联分析，以上安全前期已对接完毕，需要单独再对接Windows DNS server数据，于是就在客户的 DNS服务器上安装splunk 转发器去转发dns的解析日志，装完转发器后splunk平台可以正常接收，但是用户反馈说装完后DNS服务器的使用率一直在增加并没有释放的意思，需要改用其他对接DNS服务器的方案。

由于目前客户没有其他类似NPM的TAP设备，于是对接DNS一度陷入僵局。于是楼下点了根烟，捋了捋思路，想了想既然客户没有TAP设备，那我能不能给用户免费“造”一个TAP设备出来，于是想到splunk有单独的转发器的软件可以装在X86主机上，实现TAP设备的功能，然后通过splunk转发器TAP设备把DNS流量解析后转发给splunk 索引器。于是大腿一拍，干！

我们再梳理下思路：

1. 部署一台splunk 充当TAP设备

2.交换机端口镜像，将DNS server的接口流量镜像一份给splunk转发器

3.splunk转发器对DNS流量进行解析，解析完毕后将日志发送到splunk索引器供后续数据呈现及搜索

以下是通过此种方式获取到的DNS解析日志(以百度的DNS解析为例)，可以看到客户端地址，请求的记录类型、请求的域名、解析IP，数据包的大小、延迟：

扩展下思维

既然我都能玩的这么骚了，还能不能再骚一点。从客户那回来我又想了一下想想，目前kubernetes容器网络的监控对于大部分传统的NPM/APM厂商来说并没有比较成熟的产品和解决方案，因为硬件盒子或者说比较重的软件无法“塞到”到容器的overlay网络层面，只有像基于BPF的cilium网络插件可以做到链路层面的可视化，另外在kubenetes中的应用监控这一块，大部分的日志监控和实时的访问流量监控，前者是通过flunted这种组件去监控日志目录或者标准输出；实时的应用流量，需要通过代理去输出，比如nginx、pipy、envoy这种软负载去输出实时的访问请求。

想到这，那我直接在宿主机部署一个SPLUNK转发器去抓流量就完事，让软负载只关注业务逻辑处理，访问流量我自己自己记录，并且我记录的东西更多更全，于是在我之前公司内部搭的kubernetes集群里面做个简单的测试，还是之前的环境没有变化。

传送门

Rancher Server自动下发F5负载均衡策略实践

这里不说南北向的流量记录，这个比较简单，我们重点看一下大家一直说的微服治理中，东西流量实时访问流量的输出和记录（大部分是通过sidecar的方式输出）。

以下是我集群k8s-node1上面的的两个pod，使用的nginx的镜像
imageID: docker-pullable://nginxdemos/nginx-hello
[root@k8s-master01 ~]# kubectl get pod -owide 
coffee-5f56ff9788-vhb9q      1/1     Running   0          32d    10.42.1.98    k8s-node01   <none>           <none>
coffee-5f56ff9788-xpbgs      1/1     Running   0          32d    10.42.1.89    k8s-node01   <none>           <none>   


进入到pod coffee-5f56ff9788-vhb9q 执行curl 10.42.1.89:8080/hello/splunk，简单模拟东西向程序调用
[root@k8s-master01 ~]# kubectl exec -it coffee-5f56ff9788-vhb9q /bin/sh
/ $ curl 10.42.1.89:8080/hello/splunk
Server address: 10.42.1.89:8080
Server name: coffee-5f56ff9788-xpbgs
Date: 28/Nov/2021:07:37:17 +0000
URI: /hello/splunk
Request ID: eddf6626e1a6174a1e7d6090b535d5e1
复制

以下是访问过程中，实时输出到splunk上的请求及相应日志（由于输出的字段过分的详细，一页没截全，哈哈！）

从日志上看有很多关键字段，不仅可以帮助应用部门实时了解业务的状态信息，也可以帮助安全部门诊断有无攻击行为，帮助网络部门判断有没有网络高延迟或波动。

简要列以下字段：

{ [-]
   accept: */*
   bytes: 471
   bytes_in: 91 
   bytes_out: 380 
   client_rtt: 595 
   client_rtt_packets: 1
   client_rtt_sum: 595
   data_packets_in: 1
   data_packets_out: 1
   dest_ip: 10.42.1.89 
   dest_mac: E2:B2:F7:EA:1D:CD
   dest_port: 8080 
   endtime: 2021-11-28T07:44:14.651890Z
   flow_id: 23562808-67c8-4d04-8c09-0f8412bc4763
   http_comment: HTTP/1.1 200 OK
   http_content_length: 166
   http_content_type: text/plain
   http_method: GET
   http_user_agent: curl/7.78.0
   packets_in: 4
   packets_out: 3
   protocol_stack: ip:tcp:http
   reply_time: 4682
   request: GET /hello/splunk HTTP/1.1
   request_ack_time: 622
   request_time: 0
   response_ack_time: 183
   response_time: 0
   sc_date: Sun, 28 Nov 2021 07:44:14 GMT
   server: nginx/1.21.1
   server_rtt: 622
   server_rtt_packets: 1
   server_rtt_sum: 622
   site: 10.42.1.89:8080
   src_ip: 10.42.1.98
   src_mac: 5A:F9:56:0E:57:65
   src_port: 33428
   status: 200
   time_taken: 5277
   timestamp: 2021-11-28T07:44:14.647208Z
   transport: tcp
   uri: /hello/splunk
   uri_path: /hello/splunk
复制