文档中心

日志服务

数据采集常见问题

如何安装升级与配置 LogCollector

本章节介绍如何安装升级与配置 LogCollector：

类别	说明
如何安装 LogCollector	安装 LogCollector（宿主机）安装 LogCollector（DaemonSet 方式）安装 LogCollector（Sidecar 方式）
如何升级 LogCollector	升级 LogCollector（宿主机）升级 LogCollector（Kubernetes 集群）
如何配置 LogCollector	采集宿主机日志单行全文模式多行全文模式 JSON 模式分隔符模式单行完整正则模式多行完整正则模式 NGINX 配置模式采集容器日志采集容器文本日志（DaemonSet-控制台方式）采集容器标准输出（DaemonSet-控制台方式）采集容器日志（DaemonSet-CRD方式）采集容器日志（DaemonSet-Pod 环境变量方式）采集容器日志（Sidecar-控制台方式）采集容器日志（Sidecar-CRD方式）采集配置管理 LogCollector 采集配置管理
LogCollector 常见配置	LogCollector 是否支持日志轮转？ LogCollector 日志采集延时情况修改 LogCollector 采集配置后多久生效？机器组显示的 LogCollector 心跳 IP 为什么不准确？如何检查容器 LogCollector 运行状态？容器 LogCollector 常见处理方案？容器 LogCollector 常见处理方案？

LogCollector 是否支持日志轮转？

LogCollector 支持日志文件轮转场景下的日志采集。

（推荐）rename 日志文件轮转：当日志文件达到一定大小或时间限制时，将当前的日志文件重命名为一个新的文件名，例如添加时间戳或序号，然后创建一个新的日志文件，并继续写入新的日志。例如原日志文件为 bar.log，轮转后会生成 bar.log.1、bar.log.2 等日志文件。

LogCollector 会自动识别轮转前后的日志文件，保证日志的完整性。

如果日志文件轮转过于频繁，导致短时间内轮转创建大量的日志文件，那么 LogCollector 仅同时采集 20 个轮转日志文件，超过 20 个的轮转日志无法被采集，可能导致部分轮转日志文件尚未被采集就被删除，从而导致日志丢失。

copytruncate 日志文件轮转：当日志文件达到一定大小或时间限制时，将当前的日志文件复制到一个新的日志文件中，例如添加时间戳或序号，然后清空原日志文件，并继续写入新的日志。例如原日志文件为 bar.log，轮转后会生成 bar.log.1、bar.log.2 等日志文件。

假设配置的采集路径是 bar.log，当 LogCollector 存在采集延迟时，copytruncate 日志文件轮转会导致延迟采集的日志丢失。

假设配置的采集路径是 bar.log*，copytruncate 日志文件轮转会导致已经采集过的日志重复采集。

LogCollector 日志采集延时情况

LogCollector 使用轮询机制和事件监听机制来进行日志采集，一般情况会在 3 秒内将日志发送日志服务。

Logcollector 的采集性能与分配的系统资源和采集模式相关，具体参考推荐参数值。

修改 LogCollector 采集配置后多久生效？

您在 TLS 控制台修改 LogCollector 采集配置后，LogCollector 将在 1 分钟内加载新的配置并生效。

机器组显示的 LogCollector 心跳 IP 为什么不准确？

默认情况下 LogCollector 将第一张网卡 IP 地址作为宿主机或容器 IP 地址，您可以调整为读取指定网卡 IP 地址或根据一定顺序获取 IP 地址。详细说明请参考策略说明。

在 Kubernetes 场景下，LogCollector 默认会使用 Pod IP 地址作为心跳的 IP 地址上报到日志服务。如果您需要使用节点 IP 地址作为 LogCollector 心跳 IP 地址，可以修改 LogCollector daemonset 配置文件，增加两个配置项 hostNetwork: true 和 dnsPolicy: ClusterFirstWithHostNet。

如何检查容器 LogCollector 运行状态？

如果容器的 LogCollector 心跳状态异常，往往需要首先排查对应 Pod 的 LogCollector 运行状态。如果运行状态为 Running，表示已成功安装 LogCollector，且 LogCollector 正常运行中。其他的 LogCollector 状态表示安装或运行异常，可参考本文档进行问题排查。

在以下示例中，Daemonset 的名称是 log-collector，所属的 namespace 是 tls-log。

如果回显信息显示 STATUS 字段值全部为 Running，表示当前 Kubernetes 集群已经成功安装 LogCollector，且运行状态正常。如果没有状态信息，或状态为 Evicted 等其他值，请参考处理方案进行进一步排查。

容器 LogCollector 常见处理方案？

没有状态信息

问题现象：回显信息中 NAME 字段没有名为 “log-collector-xxxxx” 的 Pod。

问题原因：该 Kubernetes 集群尚未安装 LogCollector。

处理方案：

请参考安装 LogCollector（DaemonSet 方式）或安装 LogCollector（Sidecar 方式）安装并运行 LogCollector。

说明

请确保按照日志服务所在地域和网络类型正确安装 LogCollector。

再次执行以下命令检查 LogCollector 运行状态。Status 显示为 Running 表示安装成功。

kubectl -n tls-log get pods | grep log-collector

状态为 Evicted

问题现象：回显信息中，指定 Pod 的 Status 字段显示为 Evicted。

问题原因：Pod 状态为 Evicted，说明节点存在污点，并且 LogCollector Daemonset 没有设置容忍度，导致 LogCollector Pod 无法调度到这个节点。污点及容忍度说明请参考 Kubernetes 官网文档。

处理方案：

为 LogCollector Daemonset 设置容忍度。假设节点存在一个键是 key1，值是 value1，效果是 NoSchedule的污点：key1=value1:NoSchedule，表示只有拥有和这个污点匹配的容忍度的 Pod 才能够被调度到这个节点。

在 logcollector_ds.yaml 中为 LogCollector Daemonset 设置容忍度。

在 logcollector_ds.yaml 中的 spec.template.spec 部分，添加以下容忍度可以匹配节点的污点 key1=value1:NoSchedule，进而保证 LogCollector Pod 能够被调度到这个节点。

apiVersion: apps/v1
kind: DaemonSet
metadata:
......
spec:
......
template:
......
spec:
tolerations:
- key: "key1"
operator: "Equal"
value: "value1"
effect: "NoSchedule"
......
containers:
......

再次执行以下命令检查 LogCollector 运行状态。Status 显示为 Running 表示安装成功。

kubectl -n tls-log get pods | grep log-collector

最近更新时间：2026.06.18 18:25:49

这个页面对您有帮助吗？

有用

无用