iLogtail惊喜配置，你值得拥有！

预计阅读时间3分钟

前言

在Kubernetes环境中日志收集会遇到以下几种情况：

• 「动态迁移」 ：在Kubernetes集群中经常存在Pod主动或者被动的迁移，频繁的销毁、创建，我们无法和传统的方式一样人为的给每个服务下发日志采集配置。
• 「日志存储方式多样性」 ：容器的日志存储方式有很多不同的类型，例如stdout、hostPath、emptyDir、pv等。
• 「Kubernetes元信息」 ：由于日志数据采集后会被集中存储，所以查询日志时，需要根据namespace、pod、container、node，甚至包括容器的环境变量、label等维度来检索、过滤，此时要求Agent感知并默认在日志里注入这些元信息。

为了更好的适应Kubernetes环境下的日志收集，我们没有选择继续使用filebeat而是将目光投向了iLogtail，其核心优势如下：

• 支持多种Logs、Traces、Metrics数据采集，尤其对容器、Kubernetes环境支持非常友好；
• 数据采集资源消耗极低，相比同类遥测数据采集的Agent性能好5-20倍；
• 高稳定性，在阿里巴巴以及数万阿里云客户生产中使用验证，部署量近千万，每天采集数十PB可观测数据；
• 支持插件化扩展，可任意扩充数据采集、处理、聚合、发送模块；
• 支持配置远程管理，支持以图形化、SDK、K8s Operator等方式进行配置管理，可轻松管理百万台机器的数据采集；
• 支持自监控、流量控制、资源控制、主动告警、采集统计等多种高级特性；

问题

然而在实际使用中我们还是遇到了问题：

• 版本：ilogtail-1.8.4
• 部署方式：DaemonSet
• 问题描述：在node节点上的从本地磁盘创建pv/pvc并以hostpath 方式挂载到了容器内/data路径下，用于集中收集容器应用打印日志。因此节点所有容器是共享/data的。但此时使用ilogtail采集出现了tag 和 具体日志目录不匹配的问题。

# 日志目录，其中hcapp、pgapp均为应用名tree /data/logshcapp/detail.logpgapp/detail.log# ilogtail 配置如下vim ilogtail-user-configmap.yaml......部分省略......inputs:  - Type: file_log    LogPath: /data/logs/    FilePattern: "*.log"    MaxDepth: 5	ContainerFile: true    ContainerInfo:      K8sNamespaceRegex: test      ExcludeEnv:        envo: stgprocessors:  - Type: processor_split_log_regex    SplitRegex: \d+-\d+-\d+\s\d+:\d+:\d+.*	SplitKey: content	PreserveOthers: trueflushers:  - Type: flush_kafka_v2    Brokers:      - x.x.x.x:9092  - Type: flusher_stdout    OnlyStdout: true......部分省略......

最终从ELK中展示的tag信息如下：

_tags.k8s.pod.name hcapp-mcnrr_tag.logs.file.path /data/logs/pgapp/detail.log

其中pod名和最终的日志路径是不匹配的，出现tag错乱的情形。

猜测原因：由于/data共享，任何容器内都能看到所有其他容器的日志，导致tag 与实际日志内容错乱。

基于上述原因，我们也自行脑补了通过sidecar 或 重新定义日志目录规范的方案，但处于集群资源的过渡占用和规范调整的适应期，我们还是选择了放弃。

但从另一角度来分析，微服务应用拆分数量上百上千是很正常的场景，那么配置文件中的FilePattern 是否支持变量的方式，与采集到的环境变量来组合匹配，实现文件匹配的自配置应该是一种强需求啊！

因此，我们和ilogtail的maintainer进行了询问。

解决方案

经ilogtail的maintainer徐老师确认，可以通过 enable_env_ref_in_config 实现，而是此功能在开源版是默认开启的，如下图所示。
最终ilogtail配置如下：

# ilogtail 配置如下vim ilogtail-user-configmap.yaml......部分省略......inputs:  - Type: file_log    LogPath: /data/logs/${APP_NAME}    FilePattern: "*.log"    MaxDepth: 5	ContainerFile: true    ContainerInfo:      K8sNamespaceRegex: test      ExcludeEnv:        envo: stgprocessors:  - Type: processor_split_log_regex    SplitRegex: \d+-\d+-\d+\s\d+:\d+:\d+.*	SplitKey: content	PreserveOthers: trueflushers:  - Type: flush_kafka_v2    Brokers:      - x.x.x.x:9092  - Type: flusher_stdout    OnlyStdout: true......部分省略......

其中 APP_NAME 是K8S中的环境变量，通过自定义环境变量的方式，我们可以将日志收集进一步配置到应用名级别，而不是只根据日志文件名进行模糊匹配。 最终，借助于ilogtail的 enable_env_ref_in_config 功能，我们解决了tag错乱的问题，这是开源版本中针对此字段功能没有提及到，但我认为可能是一个比较强需求的功能，特在此分享下。

另，在此也非常感谢ilogtail  maintainer 徐老师的在百忙之中的热心支持！

❝

关于此问题的discussions如下：

https://github.com/alibaba/ilogtail/discussions/1467#discussioncomment-9335584

❞

对的那条路，往往不是最好走的！



精彩文章合集
文章推荐 ☞ 【合集】 运维思索系列 ☞ 【 合集 】 运维管理系列 ☞ 【 合集 】 运维监控之路 ☞ 【 合集 】 蓝鲸之路 ☞ 【 合集 】 CI/CD之路 ☞ 【 合集 】 Ansible之路 ☞ 【 合集 】 K8S之路
札 记：“缺少价值表达的运维不是个好运维！ ” -- 优秀的运维小伙伴
喜欢这篇文章，记得 点赞+在看 哦~