日志中心

如何关闭日志中心？

关闭容器日志、kubernetes事件采集

方法一：进入“日志中心”，单击右上角“日志采集策略”，删除对应的日志策略。其中default-event为默认上报kubernetes事件，default-stdout为默认上报标准输出。

方法二：进入“插件中心”，卸载CCE 云原生日志采集插件，注意：卸载后插件将不再上报kubernetes事件到AOM。

关闭控制面组件日志采集

进入“日志中心 > 控制面组件日志”，单击“配置控制面组件日志”，取消勾选不需要采集的组件。

关闭控制面审计日志采集

进入“日志中心 > 控制面审计日志”，单击“配置控制面审计日志”，取消勾选不需要采集的组件。

插件中除log-operator外组件均未就绪

问题现象：插件中除log-operator外组件均未就绪，且出现异常事件“实例挂卷失败”。

解决方案：请查看log-operator日志，安装插件时，其余组件所需的配置文件需要log-operator生成，log-operator生成配置出错，会导致所有组件无法正常启动。

日志信息如下：

MountVolume.SetUp failed for volume "otel-collector-config-vol":configmap "log-agent-otel-collector-config" not found

log-operator标准输出报错

问题现象：

2023/05/05 12:17:20.799 [E] call 3 times failed, resion: create group failed, projectID: xxx, groupName: k8s-log-xxx, err: create groups status code: 400, response: {"error_code":"LTS.0104","error_msg":"Failed to create log group, the number of log groups exceeds the quota"}, url: https://lts.cn-north-4.myhuaweicloud.com/v2/xxx/groups, process will retry after 45s

解决方案：LTS日志组有配额限制，如果出现该报错，请前往LTS下删除部分无用的日志组。限制详情见：日志组。

节点容器引擎为docker时采集不到容器文件日志

问题现象：

配置了容器文件路径采集，采集的目录不是挂载到容器内的，且节点容器引擎为docker，采集不到日志。

解决方案：

请检查工作负载所在节点的容器存储模式是否为Device Mapper，Device Mapper不支持采集容器内日志（创建日志策略时已提示此限制）。检查方法如下：

1. 进入业务工作负载所在节点。
2. 执行docker info | grep "Storage Driver"。
3. 若返回的Storage Driver值为Device Mapper，则该日志无法采集。

图1 创建日志策略

日志无法上报，otel组件标准输出报错：log's quota has full

解决方案：

云日志服务（LTS）有免费赠送的额度，超出后将收费，报错说明免费额度已用完，如果需要继续使用，请前往云日志服务控制台“配置中心”，打开“超额继续采集日志”开关。

图2 配额设置

采集容器内日志，且采集目录配置了通配符，日志无法采集

排查方法：请检查工作负载配置中Volume挂载情况，如果业务容器的数据目录是通过数据卷（Volume）挂载的，插件不支持采集它的父目录，需设置采集目录为完整的数据目录。例如/var/log/service目录是数据卷挂载的路径，则设置采集目录为/var/log或/var/log/*将采集不到该目录下的日志，需设置采集目录为/var/log/service。

解决方案：若日志生成目录为/application/logs/{应用名}/*.log，建议工作负载挂载Volume时，直接挂载/application/logs，日志策略中配置采集路径为/application/logs/*/*.log

fluent-bit容器组一直重启

排查方法：节点上fluent-bit容器组一直重启，且通过kubectl describe pod命令查看Pod重启原因为OOM。查询该fluent-bit所在节点存在大量被驱逐的Pod，资源被占用导致出现OOM。

解决方案：删除节点上被驱逐的Pod。

节点OS为Ubuntu 18.04时出现日志无法采集

排查方法：重启当前节点的fluent-bit pod，查看日志是否正常采集。如依然无法采集，请确认需要采集的文件是否为打包镜像时已经存在于镜像中的日志文件。对于容器日志采集的场景来说，镜像打包时已存在的文件的日志非运行日志，属于无效日志无法采集。该问题为社区已知问题，详情请参见开源issue。

解决方案：若需要采集打包镜像时已经存在于镜像中的日志文件，建议添加在创建工作负载时，设置“生命周期>启动后命令”，在工作负载Pod启动前，先删除原来日志文件，使日志文件重新生成。

采集Job日志时出现日志无法采集

排查方法：确认Job的存活时间。若Job存活时间低于1分钟，日志还未被采集，Pod就已经被销毁，可能存在日志采集不到的情况。

解决方案：延长Job的存活时间。

云原生日志采集插件运行正常，部分日志策略未生效

解决方案：

• 若未生效的日志策略采集类型为事件类型或插件版本低于1.5.0，则检查log-agent-otel-collector工作负载的标准输出。

  可在插件中心单击 “云原生日志采集插件”名称，在“实例列表”中选择 log-agent-otel-collector 最右侧的日志查看。

  

• 若未生效的日志策略类型不为事件类型，且插件版本高于1.5.0，则检查需要采集的容器所在节点的log-agent-fluent-bit实例日志。

  

  容器选择fluent-bit，并在日志中查看关键字“fail to push {event/log} data via lts exporter”，查看后面的errorMessage。

  

  1. 若报错为“The log streamId does not exist.”，则日志组或日志流不存在，可前往“日志中心>日志采集策略”中，通过“编辑”或“删除”重建日志策略，更新策略中的日志组日志流。
  2. 其余报错可前往LTS搜索错误码，查看报错原因。详情请参见LTS错误码。

log-agent-otel-collector组件出现OOM

排查方法：

1. 查看log-agent-otel-collector组件标准输出，查看近期是否有错误日志。

   kubectl logs -n monitoring log-agent-otel-collector-xxx

   若存在报错请优先处理报错，确认日志恢复正常采集。

2. 若日志近期没有报错，且仍然出现OOM，则参考以下步骤进行处理：
   1. 进入“日志中心”，单击“展开日志条数统计图”查看日志统计图。若上报的日志组日志流不是默认日志组日志流，则单击“全局日志查询”页签，选择上报的日志组和日志流后进行查看。

      

   2. 根据统计图中的柱状图，计算每秒上报的日志量，检查是否超过当前规格的日志采集性能。

      若超过当前规格的日志采集性能，可尝试增加log-agent-otel-collector副本数或提高log-agent-otel-collector的内存上限。

   3. 若CPU使用率超过90%，则需要提高log-agent-otel-collector的CPU上限。

节点负载过多，采集日志时缺少部分Pod信息

问题：插件版本在1.5.0以上，采集容器内日志或容器标准输出过程中出现日志缺少部分Pod信息，例如podID、podName等。

排查方法：

进入“插件中心”，单击“云原生日志采集插件”，选择实例列表，找到对应节点的log-agent-fluent-bit，单击“更多>日志”。

容器选择fluent-bit，并在日志中查看关键字“cannot increase buffer: current=512000 requested=*** max=512000”。

解决方案：

前往节点执行kubectl edit deploy -n monitoring log-agent-log-operator， 编辑log-operator容器的命令行参数，添加命令行--kubernetes-buffer-size=20MB，当前默认值为16MB，请根据节点pod信息总大小估算该值大小。0为无限制。

若升级插件，则需要重新配置该参数。