【日志服务CLS】TKEX 接入 CLS

TOC

引言

老项目上容器环境（TKEX），需要一套简单、易用的日志搜索、日志统计分析方案。

在这之前，日志搜索使用项目组自己搭建的 es，统计分析通过 Kiabana 展示聚合数据，还有些通过打点系统分析展示，用起来体验稍差，还需要项目组自己投入机器、人力去维护管理，费心费力。

以前可能是没有选择，没有现在这么多日志组件：cms、cls、uta、监控中台。使用公共组件，虽然也有投入，但对比自行维护，太省心省力。经过了解比对，最终选择了容器环境也默认支持的 cls，他可以搜索日志、分析处理日志，我们也可以用他来做打点系统。

方案比对

对日志统计分析方面，各种组件基本都使用了时序数据库，比如cms 使用了 Druid；监控中台 使用了 influxdb；cls 使用自研优化定制方案。这方面对使用者来说基本是黑盒，使用起来也大同小异，要么是类 sql 查询，要么是 restful 查询，到数据库底层，转换为对应的查询规则，了解下就可以了。

cms 尝试

cms 在使用过程中还算流畅，但里面概念比较多，比如数据源、任务流、数据集，不是很好理解；任务流加工数据源中的数据，留下需要的字段，转存到 Druid ，然后在 dashboard中去分析处理，或者在自己的多维分析中去分析，基本各种情况的统计分息都可以满足，比如下面是统计分析的截图

image.png

但是在我调研整理完成之后，没几天，发现他分别显示这个

image.png

image.png

随后，cms 就作为一个备选方案了，我又去尝试了监控中台，监控中台，没有中间商，直接将数据存入 influxdb，然后通过 grafana 去分析、处理、告警之类的。但在使用过程中发现按照文档，测试环境的例子一直通过不了，就只能终止，然后去尝试了 cls 。

cls 尝试

大概体验了一遍 cls ，嗯，这就是我想要的，尤其在容器环境中，接入、使用简直太方便了，下面我来详细的说说。

cls 中日志怎么收集的

在 cls 之前，cms、监控中台这些，我采用的最简单、快速的接入日志方式，是使用 http 接入，在业务中封装函数，通过发送 http 请求记录单个、或多个日志到日志系统，这种方式为了让业务请求快速返回，日志发送的时候异步，不等待返回，可能会丢失，但在日志量小的情况下，这种方式不失为一种快捷方式。

image.png

等到使用 cls 的时候，发现 TKEX 中已经内置了收集日志的进程，直接配置即可，不用自己启动 sidecar，也不用在 pod 中安装日志采集客户端，按照规则配置日志集收集路径，就会收集日志，对容器环境来说方便程度十足。

使用之后，你可能也会有跟我一样的疑惑：日志怎么收集的？pod 中也没有启动日志收集进程？

经过查询官方文档、资料以及请教同事，原来是通过用户自定义资源 CRD（CustomResourceDefinition） 实现的。让日志收集客户端作为一种资源（一切皆资源，比如Deployment、StatefulSet）以DaemonSet 的方式运行。

CRD

详细内容查看 https://lihaoquan.me/2020/3/8/k8s-crd-develop.html

自定义控制器是 CRD 的核心，他是实际操作处理资源的，他会从 API-Server（etcd） 监听自己感兴趣的数据，当数据发生变动（增加、更新、删除），他会拿到数据，然后触发自定义的动作，比如启动日志收集、或者更新日志收集的配置。

说这个可能有点儿跑题，目的是为了让大家了解，日志这里大概怎么工作的，用起来会更得心应手，更可控。不会像我刚开始一样，产生日志采集会不会每个 pod 都启动一个采集进程这种错误的思路。

cls 使用

日志基本使用，比如配置，查询日志，就不多说了，官方文档写的很详细了，基本按着来就可以成功，不过这里要注意的是，cls 这里TKEX 环境使用只能选择南京，TKEX 创建负载的时候，南京有如下两个集群不支持（我用的时候，只能配置一个规则，就等于只能采集负载中的一个路径）：

image.png

日志主题和日志集规划

一个项目一个日志集，各种类型的日志分别放在不同的日志主题中，这样可以方便配置不同的格式、索引。

image.png

比如 nginx 日志这里，我们可以用 json 格式，配置起来就很方便，日志主题里面，采集配置设置为json就可以直接解析了，不用去正则匹配、或者切分字段

log\_format json escape=none '{"host":"$host","remote\_addr":"$remote\_addr","http\_x\_forwarded\_for":"$http\_x\_forwarded\_for","time\_local":"$time\_iso8601",'

        '"request\_uri":"$request\_uri","method":"$request\_method","status":"$status",'

        '"request\_body":$request\_body,'

        '"body\_bytes\_sent":"$body\_bytes\_sent","http\_referer":"$http\_referer",'

        '"http\_user\_agent":"$http\_user\_agent",'

        '"upstream\_addr":"$upstream\_addr","upstream\_response\_time":"$upstream\_response\_time","request\_time":"$request\_time"}';

之后就可以在检索页面检索了，检索相关的语法也很简单明了，看看官方问道就可以了。

打点统计分析

打点（埋点）统计分析，本来想找个专门的组件来做，结果试了下cls，基本也可以满足。

先看看统计分析的效果：

image.png

实现上面的图表，只需要很简单的语句就可以了，这里看下里面还算复杂的右下角这个图标的语句

image.png

identify:live\_service | select histogram( cast(\_\_TIMESTAMP\_\_ as timestamp),interval 1 minute) as time, ret\_val, count(\*) as LogCount group by time, ret\_val order by time asc，里面做了一次 group by，然后展示的时候根据 ret_val 进行聚合，统计相同 ret_val 的数量。

本来后端业务打点，是通过接口调用去打点的，比如调用 monitor 之类的，这里没有采用这种，而是直接把打点信息也作为日志记录去处理。单独新建一个日志集，收集打点信息，每条数据4个字段，分号分隔，分别代表业务标识、接口名称、调用耗费时间、返回值 4 个字段 live\_service;Live\_User\_DescribeLivePackageInfo;538.39;0，然后每个字段配置索引，就可以很容易的展示出上图中的内容了，其中列表类型（上图中右上角的图）还可以下载。

诉求 & 建议

希望尽快支持海外版本的 cls。海外隐私法律比较严格，涉及到合规的，日志数据也要完全部署到海外服务器，如果 cls 不支持的话，相关的业务可能都需要海外搭建 es 之类的，希望尽快支持海外。

仪表盘增加多条语句展示到同一个坐标系。统计分析展示这里，稍微有些弱，比如在一个坐标系中，x 轴是时间，y 轴同时展示三条折线：总条数、成功条数、失败条数，这个就不好实现，如果像 Grafana 一样，将多条语句展示到同一个坐标系，应该能实现更多更丰富的图表。

总结

TKEX 容器环境，接入 cls 是首选，使用体验很棒，瑕不掩瑜。非容器环境，可以考虑其他组件，比如 cms ，可能会更方便些。

文章是一边儿研究日志组件，一边儿学习相关技术，整理出来的，写的比较浅，可能有不对的地方，还望斧正。