再见 ELK，您好 fluent-bit-aliyun

[adieu]

ELK是Elasticsearch，Logstash，Kibana的缩写，是我们在处理日志时最常用到的方案。其中Logstash负责日志采集， Elasticsearch负责日志存储，Kibana负责日志展示。三款开源项目分工合作，提供了完整的解决方案。 此外也有使用Fluentd替换Logstash组成的EFK方案，同样也非常受欢迎。

针对不同的环境，已经有大量的文档详细介绍了安装和配置的方法。在 Kubernetes 环境中，管理员甚至可以使用一键部署脚本完成安装。 这些总结下来的经验极大的降低了ELK的上手门槛，运维人员可以很方便的开始将所有服务器产出日志统一的搜集起来。

但在使用了一段时间之后，随着数据量的增加以及集群规模的扩大，维护一套高效运转的ELK系统所需要付出的运维成本在逐渐增大。 管理员将面临以下几个挑战：

• 多种不同应用的日志格式不同，需要为不同的应用配置专门的日志解析器
• 在所有服务器上更新组件版本以及配置带来的运维工作量的增加
• 单机版本的Elasticsearch的性能跟不上日志产出的速度，需要集群化部署ES
• ES集群的搭建和管理过程中的复杂度对运维人员的能力要求较高。过度依赖脚本和教程的工程师可能无法顺利完成
• ES消耗的 IO，CPU，内存资源均较高。为了能够提供足够的日志处理能力，ELK所需要的计算资源投入对于小型团队来说是不小的负担
• ELK方案中缺少日志归档，持久保存的功能。而ES的存储能力受集群规模的限制无法无限扩张。管理员需要面临删除老数据或是研发数据导出存档功能的选择

在 Kubernetes 环境中，使用 k8s 所提供的调度功能和ConfigMap所提倡的配置管理最佳实践，再配合上elasticsearch-operator这样的工具， 可以大大降低日常的运维负担，但在算力消耗以及成本增加的问题上，能够带来的改善有限。

对于小型项目，我们需要更加轻量更加经济的解决方案，将日志管理 SaaS 化，交给合适的供应商来提供，用户按需付费可能是更适合的解决方案。

阿里云日志服务

阿里云提供的日志服务是一套完整的日志管理解决方案。它提供的搜集、消费、存储、查询、归档等功能基本覆盖了日志管理绝大部分的需求。 具体的功能清单如下图所示，在阿里云的网站上有更加详细的介绍，这里就不进一步展开了。

阿里云日志服务对运行在阿里云上的服务器有原生的支持，但是对于 Kubernetes 下的容器环境的支持有限，此外对于非阿里云服务器， 用户需要自己完成配置和对接。为了解决容器环境的日志搜集以及方便大量的非阿里云用户使用阿里云日志服务， 我们为fluent-bit开发了插件来支持向阿里云日志服务输出日志。

fluent-bit-aliyun

fluent-bit和fluentd来自同一家公司。fluent-bit使用 C 语言开发，比使用 Ruby 开发的fluentd性能更好，资源占用更低。 作为一个新项目，虽然目前支持的插件还没有fluentd丰富，但已经有不少团队开始在生产环境中使用它。

fluent-bit-aliyun是使用 Go 语言开发的fluent-bit插件，通过 API 调用将日志输出到阿里云日志服务。 项目地址在https://github.com/kubeup/fluent-bit-aliyun。

为了方便使用，我们提供了打包好的 Docker 镜像，在https://hub.docker.com/r/kubeup/fluent-bit-aliyun/

在 Docker 环境中安装

Docker 原生支持fluentd格式日志输出。我们可以在容器中运行fluent-bit-aliyun，然后在启动新容器时进行配置将日志发送给它即可。

$ docker run -d --network host -e ALIYUN_ACCESS_KEY=YOUR_ACCESS_KEY -e ALIYUN_ACCESS_KEY_SECRET=YOUR_ACCESS_KEY_SECRET -e ALIYUN_SLS_PROJECT=YOUR_PROJECT -e ALIYUN_SLS_LOGSTORE=YOUR_LOGSTORE -e ALIYUN_SLS_ENDPOINT=cn-hangzhou.log.aliyuncs.com kubeup/fluent-bit-aliyun:master /fluent-bit/bin/fluent-bit -c /fluent-bit/etc/fluent-bit-forwarder.conf -e /fluent-bit/out_sls.so
$ docker run --log-driver=fluentd -d nginx

如果在启动 Docker Daemon 时进行配置，还可以默认将所有日志发送到阿里云日志服务。

在 Kubernetes 环境中安装

在 Kubernetes 环境中，我们使用DaemonSet在集群中的所有Node上部署fluent-bit-aliyun，它将搜集每台服务器上所有 Pod 所输出的日志。 fluent-bit内置的kubernetes过滤器会将 Pod 的元数据附加到日志上。

首先，我们创建一个新的Secret来保存所有的配置信息：

$ kubectl create secret generic fluent-bit-config --namespace=kube-system --from-literal=ALIYUN_ACCESS_KEY=YOUR_ACCESS_KEY --from-literal=ALIYUN_ACCESS_KEY_SECRET=YOUR_ACCESS_KEY_SECRET --from-literal=ALIYUN_SLS_PROJECT=YOUR_PROJECT --from-literal=ALIYUN_SLS_LOGSTORE=YOUR_LOGSTORE --from-literal=ALIYUN_SLS_ENDPOINT=cn-hangzhou.log.aliyuncs.com

接下来部署DaemonSet:

$ kubectl create -f https://raw.githubusercontent.com/kubeup/fluent-bit-aliyun/master/fluent-bit-daemonset.yaml

我们可以使用kubectl来检查部署情况：

$ kubectl get pods --namespace=kube-system

在阿里云中查看日志

当日志发送到阿里云之后，可以通过管理界面的日志预览功能确认日志搜集和发送的正确性。

在日志查询中开启索引后，可以进行复杂的过滤和查询。

配置日志归档

阿里云还提供了在ELK方案中缺失的归档功能，只需要简单配置即可开通。

具体的设置方案以及其他相关功能，在阿里云有详细的文档说明，这里就不过多展开了。

总结

本文介绍了使用ELK管理日志可能遇到的挑战，同时提出了新的基于阿里云日志服务以及fluent-bit-aliyun管理日志的办法。 新的办法有如下特点：

• 不再依赖Elasticsearch，减少大量计算资源消耗。fluent-bit的资源占用也远远低于fluentd，可以随着任务 Pod 部署
• 当负载增加时，仅需要在阿里云添加更多的 Shard 即可，伸缩性更好
• SaaS 模式的计费方式，根据使用量计费，大部分情况下可以降低运行成本
• 依赖阿里云日志服务的扩展功能，可以实现基于日志的消息处理总线，架构上更加灵活
• 基于开源系统搭建，仅替换了fluent-bit的输出插件，可以复用 input 和 filter 插件。当需要切换后端时，前端无需修改
• 内置归档功能。只需要简单配置，即可将日志输出到 OSS 长期保存
• 同时支持阿里云 ECS 以及阿里云以外的服务器，对于阿里云以外的服务器，可以将阿里云日志服务作为 SaaS 来使用

fluent-bit-aliyun的项目地址在https://github.com/kubeup/fluent-bit-aliyun，欢迎大家试用和反馈。

[metrue]

有银子可以直接上 splunk

[ericls]

Elastic 有 graph query

[jhaohai]

上云也别上阿里云～～

[mlhorizon]

把日志送到阿里云，给不给钱啊？亲！

[yghack]

降低成本不敢苟同，只能说能降低人员成本

[adieu]

回复下各位：

@metrue splunk 确实是好咚咚。就是太贵了，小团队用不起啊
@ericls es 的索引和查询功能比阿里云的好用，如果有特殊查询需求用 es 靠谱
@jhaohai 算力不放在阿里云，但是日志输出到阿里云会不会是一个折中的方案。主要国内也没有好的第三方日志管理 SaaS
@mlhorizon 应该要给钱的哦亲，但是数据量小的时候应该不贵，毕竟按量付费
@yghack 成本核算要看具体场景。一个最小的 es 按照 1g 内存，0.5 个核来算，一年也要不少钱。如果日志量比较小，可能直接用日志服务划算些。

总的来说，ELK 是很优秀的方案，合理使用可以满足绝大部分的需求。但是也有一些场景使用阿里云日志服务会比使用 ELK 更加合适。系统管理员应当不应该迷信 ELK，根据需求和场景选择适合的的方案才是硬道理。

[momocraft]

不太敢用 感觉会成为贵云的大数据...

[yghack]

@adieu 对比 ecs 的费用，还是 ecs 划算些。当然从技术层面讲，人员的维护成本远远大于产品本身。

[adieu]

@momocraft 误会了，我们跟阿里云没有关系，这是一个第三方工具。之前有客户有这方面的需求，所以我们开发了这个工具。开源出来是想分享给其他有相同需求的同学。如果对隐私非常看重，我们也建议不要使用 SaaS 类型的服务。

[adieu]

@yghack 在 k8s 下面运维 elk 所带来的运维成本增加还可以接受。成本上要核算了之后才能确定，可能每个项目的情况都不太一样。anyway，非常“同意人员的维护成本远远大于产品本身”这个观点。

[momocraft]

@adieu 对不起搞错了 逃走

[server]

楼主 你确定你了解过 es，还是只把 es 当个日志 db。

[zhengxiaowai]

阿里云的工单能回复的快一点就好了。

[adieu]

@server 可能表达的不太准确。本文的主要意思是希望那些把 es 当个日志 db 用的同学也看看 SaaS 的方案，如果只为了保存日志维护一个 es 可能太重了。

[adieu]

@zhengxiaowai 这。。。只能说，有的时候把 V2EX 当作工单系统来用会有奇效

[linoder]

考虑到 E 当检索性能还不错 ELK 还能再战 10 年 （ E 队列坑除外

[zdyxry]

Splunk 的 免费版本每天 可以提供 500MB 的日志收集及分析，日常小规模使用够用了

[zzg]

楼主有测试过 fluent-bit 性能吗？