F5 BIG-IP与ELK完美对接，实现业务与态势完美可视

F5 BIG-IP 平台是应用交付控制器 (ADC) 技术的智能演变，是应用和用户之间的信息流的核心所在，在 BIG-IP 平台上运行的 F5 产品模块可确保应用程序始终快速、可用且安全。

基于BIG-IP 产品的数据可视化和分析平台可以让应用维护人员清晰的掌握实时的流量动态，了解业务流数据的内在关系、趋势及异常存在，实现应用的智能化监控和高可用能力。

 

本文将讲述如何将这些数据信息收集起来，并以直观易懂的形式显示，这是F5大数据分析展示平台存在的重大意义：

让流量数据尽收眼底，让业务态势了然于心！

 

F5 大数据分析展示平台 在线访问：http://bde.f5se.io

一、视图与展示

以下F5 大数据分析展示平台的截图，从以下截图我们可以看到，平台的首页有两部分组成：

·      首页头部：

o   平台简要介绍

o   滚动窗口：动态显示BIG-IP 告警信息或相关新闻。

o   指向Kibana界面的连接：方便高阶用户自定义更多dashboard。

·      首页主题：

这里以分Tab页的方式展示平台图表及视图。各图表及视图可以按照预定义的时间间隔定时刷新以获取实时的数据状态。

 

 

 

在现有平台中我们已经内置了诸多的统计分析图表（Dashboard），每一个图表中包含很多视图（Visualization）。

接下来我们一一讨论每个图表中主要的视图及作用。

注意：每个图表及视图不是一成不变的，都可以根据实际场景再调整。

·      客户端与请求分析

此图表负责展示客户端请求的情况，包括

o   客户端地理位置分布；

o   请求总量；

o   最近一段时间（30分钟、24小时、7天、1个月）的访问情况；

o   访问城市分布、IP分布；

o   客户端类型。

截图如下：

 

 

·      应用及响应分析

此图表主要负责展示服务器端的运行状态，包括：

o   服务器访问量比例；

o   响应码分布比例；

o   延迟情况统计；

o   响应传输带宽消耗情况；

o   资源文件情况。

截图如下

 

 

·      TCP层数据延迟分析

此图标主要展示4层数据流访问情况。主要针对握手过程、响应延迟等方面做统计展示。

截图如下：

 

·      请求与响应视图-给定时段

此图表是对请求和响应两种数据流的汇总，同时对BIG-IP各个vs链路实现统计展示。

不同于其他图表，此图表的头部可以自定义时间段，比如可以选择最近1个小时：Last 1 hour. 同时也可以添加自定义的过滤条件做特定显示，这是Kibana相对比较高阶的使用技巧，这里不展开讨论。

截图如下：

 

·      DNS解析视图展示

F5 BIG-IP 在各种应用环境下都有广泛的应用，不仅可以当做LTM APM用还可以做为DNS服务器。此图表展示的是当BIG-IP作为DNS时实时log的统计能力。

截图如下：

 

·      系统自监控

为了保证F5 大数据分析展示平台的正常运行，我们需要时刻关注其本身的运行状况，通过脚本自动化的方式我们将平台运行状态数据我加入到统计分析中。

截图如下：

 

二、收据的收集

在讨论本部分内容之前，需要大家注意的是，F5大数据分析展示平台可以收集的数据集不限于以下提到的这些，主要取决于BIG-IP端可以收集的信息。

收集数据的格式为JSON，采用JSON的好处是可以直接在源端将数据格式化，而不需要在ELK部分做正则匹配，当然ELK是完全可以做到的。

 

目前F5大数据分析展示平台共收集三类数据：

·      LTM数据

o   timestamp

o   client-ip

o   host

o   user-agent

o   cookie

o   method

o   uri

o   username

o   content-type

o   server-ip

o   latency

o   resp-status

o   sender

o   stdout

o   vs_name

o   client_remote_port

o   client_local

o   server_local

o   server_local_port

o   server_remote

o   server_remote_port

o   delay_type

o   delay_value

o   cdnumber

o   transmission.resource_name

o   transmission.resource_size

 

·      DNS数据

o   clientip

o   clientport

o   listenerip

o   requestid

o   queryname

o   querytype

o   status

o   origin

o   f5hostname

o   responsecode

o   responseflag

o   answer

 

·      自监控数据

o   avail_size_m

o   es_data_size_m

o   fluentd.worker*

o   fluentd_size_bytes

o   kfk_data_size_m

o   total_size_m

o   usage_rate

 

在BIG-IP端收集LTM和DNS数据有以下几种方式：

·      Request Logging Profile + HSL

关于使用Request Logging Profile的方法可以参考以下链接：https://techdocs.f5.com/kb/en-us/products/big-ip_ltm/manuals/product/bigip-external-monitoring-implementations-12-0-0/3.html

这里还定义了所有可以收集的字段，HTTP_REQUEST CLIENT_IP 等。

以下是一个Request Logging Profile的示例：

{

    "timestamp": "$DATE_YYYY-$DATE_MM-${DATE_DD}T${TIME_HMS}.000${TIME_OFFSET}",

    "vs_name": "$VIRTUAL_NAME",

    "client-ip": "${X-Forwarded-For}",

    "host": "$Host",

    "user-agent": "${User-agent}",

    "cookie": "$Cookie",

    "method": "$HTTP_METHOD",

    "uri": "$HTTP_URI",

    "username": "$Username",

    "content-type": "${Content-Type}",

    "server-ip": "$SERVER_IP",

    "latency": $RESPONSE_MSECS,

    "status": "$HTTP_STATCODE"

}

 

·      iRule + HSL

使用iRule方式是比Request Logging 更灵活的方式，但其性能较Request Logging 稍稍差一点。关于如何书写iRule，可以参考F5 iRule 文档：https://clouddocs.f5.com/api/irules/, iRule中使用cmd的规范遵循：http://www.tcl.tk/man/tcl8.4/TclCmd/clock.htm#M48

以下是收集Logging信息的iRule示例：

 

when HTTP_REQUEST {

    set request_start [clock clicks -milliseconds]

    if { [HTTP::header X-Forwarded-For] ne "" } {

        set client_ip [HTTP::header X-Forwarded-For]

    } else {

        set client_ip [IP::client_addr]

    }

 

    # set client_port [TCP::client_port]

    set host [HTTP::header host]

    set user_agent [HTTP::header user-agent]

    set content_type [HTTP::header content-type]

    set cookie [HTTP::header cookie]

    set uri [HTTP::uri]

    set method [HTTP::method]

    set username [HTTP::username]

}

 

when HTTP_RESPONSE {

    set hsl [HSL::open -proto UDP -pool f5-logging-pool]

   

    set timestamp [clock format [clock seconds] -format "%Y-%m-%dT%T.000%z"]

    set request_end [clock clicks -milliseconds]

    set server_ip [IP::server_addr]

    set resp_status [HTTP::status]

    set latency [expr {$request_end-$request_start}]

   

    # FOR DEBUG:

    # Add this line to the following line to check log reachment to logstash

    # \"stdout\": \"OK\", \

    HSL::send $hsl "\

    {\

        \"timestamp\": \"$timestamp\", \

        \"vs_name\": \"[virtual name]\", \

        \"client-ip\": \"183.84.2.166\", \

        \"host\": \"$host\", \

        \"user-agent\": \"$user_agent\", \

        \"cookie\": \"$cookie\", \

        \"method\": \"$method\", \

        \"uri\": \"$uri\", \

        \"username\": \"$username\", \

        \"content-type\": \"$content_type\", \

        \"server-ip\": \"$server_ip\", \

        \"latency\": $latency, \

        \"resp-status\": \"$resp_status\"\

    }"

}

 

·      Telemetry Streaming

TS是BIG-IP日志收集中较新的方式：https://clouddocs.f5.com/products/extensions/f5-telemetry-streaming/latest/#，可以看到TS可支持多种下游接收方式，其中就有kafka 或Fluentd或generic HTTP。

 

如何配置F5 BIG-IP 以联用 F5 大数据分析展示平台的部分，可以参考社区的另外一篇文章：《配置F5 BIG-IP 以联用 F5 大数据分析展示平台》。

  

三、设计实现、监控与自动化

1.组织架构

以上是F5 大数据分析展示平台的实现架构。

从这个图可以看出：它由基于Docker的EFK来源工具集成。 横向扩展是另一回事，因此性能改进工作正在进行中。它的运行依赖于docker 运行时环境。

运行start-all.sh：首次运行start-all.sh时，docker命令将拉出或构建映像，因此可能需要几分钟才能完成，具体取决于docker映像的下载速度。

start-all.sh进程按顺序执行以下4件事（部分由启动后的CTRLBOX代为执行）：

1.     启动容器：ELASTICSEARCH FLUENTD .. KIBANA和CTRLBOX。

2.     将预定义图表导入到KIBANA。

3.     在ELASTICSEARCH中创建索引和映射。

4.     创建定时任务执行周期性操作，管理磁盘、索引等。

 

2.各容器作用

·      CTRLBOX：主要是配置并管理其他容器的运行状态，执行一些定期任务。

·      KIBANA：ELK标准组件，制作并展示各种图表。在启动初期会被导入各种图表。

·      ES CLUSTER：这个容器是一个集群，主要负责存储从BIG-IP上传上来的数据。分Index的方式存储供查询。

·      LOGSTASH：从KAFKA到ES CLUSTER的中转组件，主要是为了从KAFKA高速缓存里面把数据取出来，然后放置在ESCLUSTER里面。在大规模部署的时候，日志量特别大的时候可以有效缓冲流量。它的存在是从性能角度去考虑的。

·      FLUENTD：这个容器开放了接收端口，能够从BIG-IP 接收数据，目前接收方式为UDP方式。

·      NGINX：这个容器的作用是将KIBANA上的dashboard直接内嵌为web 服务器，简单用户不需要登录KIBANA操作，而是以更直观更快捷的方式让用户访问到视图。

 

更多的实现细节请参考：https://github.com/zongzw/bde-over-bigip。

 

3.监控与自动化

 

目前这个平台是以container的方式运行，所以可移植性较强，对于系统的依赖也很少。目前只有两个依赖，Docker 和docker-compose，只要在用户环境的虚机里安装这两个依赖就可以完美运行。

平台的拉起是一个一键式的操作，用户只要执行start_all.sh 脚本，不需要带参数，就可以把平台拉起来，内部的启动和配置细节不需要干预。

监控方面，定时脚本由cron job 调用定时收集系统的磁盘使用信息，在出现磁盘空间不足时触发数据保存窗口的移动。

监控的另外一个访问是针对平台访问量的统计，这里我们使用GoAccess 访问NGINX 容器的access.log做F5 大数据分析展示平台的访问统计：

 

4.性能评估

目前系统的服务量级如下：

•       索引数量：3

•       收集属性：42（ltm） + 38（dns） + 29（health）

•       视图数量：66（visualization） 7（dashboard）

•       吞吐能力：126GB/10-work-hour (3.5MB/s)

•       部署过程：一键式

•       首次，时间较长，取决于网络（< 5.5GB Docker Images）

•       之后，启动时间< 30 秒

 

5.运行环境需求：

因为系统的运行共10个container，同时要处理大量的log，不只要保存，还要同时检索，所以那个系统的配置需求稍大，以上测试数据是在最好配置下测得。

目前只支持单节点部署，所要求的配置如下：

配置项	最低	正常	最好（推荐）
CPU	4 core	8 core	16 core
Memory	8 GB	16 GB	32 GB
disk	磁盘容量：根据客户实际业务场景计算： 每条日志的长度（500 Byte） x 每天http访问数量 x 缓存日志天数 读写速度：普通SSD水平（rw: > 50 MB/s）即可
Network	该虚机对接 BIG-IP HSL， BIG-IP log以UDP的形式发给该虚机，需要该虚机与BIG-IP之间网络带宽能够容纳BIG-IP 日志量，最好直连局域网，避免对周边网络设施产生额外负荷。
预装	CENTOS 7（推荐，其他Linux亦可），该虚机部署安装过程依赖（且仅依赖）Docker运行时环境，期间会下载相关docker images，所以（至少首次）需要连接外网，代理访问也可以。