日志采集快速排障指南

为什么我的日志没有采集？

日志采集中，最为关键核心的问题是，日志有没有被采集到，为什么我配置的日志没有发送过去？
下面提供了核心的排查思路和手段供参考。
另外，最重要的是，在环境里配置Loggie的Prometheus监控和Grafana图表，可以快速发现问题。

日志采集核心机制

了解实现机制是排障的基础：

  1. 下发采集任务：创建日志采集任务LogConfig CR至Kubernetes
  2. 接收日志配置：节点的Agent Loggie监听到K8s相应事件，将LogConfig转换成Pipelines配置文件
  3. 采集日志文件：Loggie会自动Reload然后读取配置文件，然后根据配置发送相应的日志数据到下游服务

（针对非Kubernetes的主机场景，只是少了LogConfig CRD配置下发的步骤，其余类似）

Loggie dashboard

在Kubernetes的场景下，目前Loggie提供了一个基于terminal的可交互式dashboard，可以更好的帮助我们便捷的排查问题。

进入dashboard

  • 找到任意一个Loggie Pod

    1. kubectl -nloggie get po -owide

  • 进入其中一个Loggie Pod

    1. kubectl -nloggie exec -it ${podName} bash

  • 运行dashboard

    1. ./loggie inspect

使用dashboard

dashboard首页展示示例如下所示： dashboard

具体请参考使用说明视频。

Tips

Loggie dashboard功能仅从v1.4版本开始提供，如果从低版本升级，需增加clusterrole配置，请参考这里。

手动排查步骤

排查问题关键先要确定是哪一步出现了问题。

日志采集任务排查

查看我们要排查的日志采集任务LogConfig/ClusterLogConfig的Events事件：

  1. kubectl -n ${namespace} describe lgc ${name}

如果没有events，则可能为：

  • ❓ Pod Label未匹配：
    logConfig中labelSelector指定的label未和我们期望的Pod匹配。通过以下命令查看

    1. kubectl -n ${namespace} get po -owide -l ${labels}

    比如kubectl -n ns1 get po -owide -l app=tomcat,service=web 来判断一下是否有匹配的Pod。

如果没有类似sync success的events，可根据events同时结合Loggie日志排查问题：

  • ❓ 配置问题或者Loggie异常：
    通过下面命令查看

    1. kubectl -n ${loggie-namespace} logs -f ${loggie-pod-name} —-tail=${N}

    比如kubectl -nloggie logs -f loggie-5x6vf --tail=100。 查看对应节点的Loggie日志，根据日志情况进行处理。

常见的异常有：

  • 找不到日志路径：填写的path没有使用volume挂载，可以仔细检查一下path和volumeMount的路径，path是否包含在volumeMount内部。
  • 日志path未匹配到具体的日志文件：path需要填写glob表达式，例如/var/log/*.log。最快速的做法是，在需要采集的业务的Pod里，执行ls <path>，因为ls也是使用的glob表达式去匹配日志文件。另外也需额外注意是否配置了ignoreOlder/excludeFiles等参数，忽略或者排除了我们希望采集的日志文件。

节点日志Agent排查

1. 🔎 找到logConfig匹配的pod所在节点的日志Agent

根据在logConfig的labelSelector找到一个匹配的业务pod：

  1. kubectl -n ${namespace} get po -owide -l ${labels}

找到任意一个所在的Node节点${node-name}，然后通过：

  1. kubectl -n ${loggie-namespace} get po -owide |grep ${node-name}

找到该节点所在的Loggie。

2. 🔎 查看对应节点的Loggie日志

检查是否有异常，如果有异常，则需根据异常日志再做分析判断

  1. kubectl -n ${loggie-namespace} logs -f ${loggie-pod-name} —-tail=${N}

3. 🔎 查看采集情况

调用自动排障接口

针对对应的Agent，调用help接口：

  1. curl <ip>:9196/api/v1/help

接口返回里最开头包括了一个使用提示：

  1. --------- Usage: -----------------------
  2. |--- view details: /api/v1/help?detail=<module>, module is one of: all/pipeline/log
  3. |--- query by pipeline name: /api/v1/help?pipeline=<name>
  4. |--- query by source name: /api/v1/help?source=<name>

我们可以使用curl <ip>:9196/api/v1/help?detail=all来查询所有的细节详情，也可以使用根据pipeline或者source的名称来搜索。

目前返回主要包括两部分：

  • Pipeline Status：整体的pipeline运行情况，配置以及一些一致性的检查
  • Log Collection Status：file source日志采集的详情，详细列举了每个pipeline/source下的日志文件的采集情况和进度等。

正常情况下，该接口覆盖了以下操作得到的内容，无需继续进行以下操作，下文步骤仅供参考。

查看节点Loggie渲染生成的配置

进入到容器中：

  1. kubectl -n ${loggie-namespace} exec -it ${loggie-pod-name} bash

查看渲染生成的Pipeline配置：

  1. ls /opt/loggie/pipeline/

当然，你也可以选择通过调用Loggie接口来查看渲染生成的Pipeline配置：

  1. curl ${loggie-pod-ip}:9196/api/v1/reload/config

确认日志采集配置

  1. cat /opt/loggie/pipeline/

查看现在渲染后的日志配置，这里的path为根据logconfig里填写的容器里path转换后的路径，为实际节点的path，正常可以在节点上找到。
当然，因为Loggie使用容器化部署，Loggie Pod里无法查看到节点所有的配置，需要确保Loggie也挂载了相关的路径前缀。

查看日志采集持久化状态

Loggie会记录每个日志文件的采集状态，这样即使Loggie重启后，也可以继续保持上一次的采集进度，避免重新采集日志文件。 可以通过调用接口来查看：

  1. curl ${loggie-pod-ip}:9196/api/v1/source/file/registry?format=text | grep XXX

一般返回的类似：

  1.   {
  2.     "id": 85,
  3.     "pipelineName": "default/tomcat",
  4.     "sourceName": "tomcat-7d64c4f6c9-cm8jm/tomcat/common",
  5.     "filename": "/var/lib/kubelet/pods/9397b8be-8927-44ba-8b94-73e5a4459377/volumes/kubernetes.io~empty-dir/log/catalina.2022-06-02.log",
  6.     "jobUid": "3670030-65025",
  7.     "offset": 4960,
  8.     "collectTime": "2022-06-06 12:44:12.861",
  9.     "version": "0.0.1"
  10.   },

其中的filename为Loggie转换后的实际节点上的日志路径，jobUid组成为文件的inode-deviceId，offset为sink发送成功接收到ack后的offset。
另外，我们可以通过在Loggie容器中执行：

  1. stat ${filename}

查看文件的size/inode等信息，例如：

stat

  1.   File: /var/lib/kubelet/pods/9397b8be-8927-44ba-8b94-73e5a4459377/volumes/kubernetes.io~empty-dir/log/catalina.2022-06-02.log
  2.   Size: 4960        Blocks: 16         IO Block: 4096   regular file
  3. Device: fe01h/65025d    Inode: 3670030     Links: 1
  4. Access: (0640/-rw-r-----)  Uid: (    0/    root)   Gid: (    0/    root)
  5. Access: 2022-06-06 12:44:12.859236003 +0000
  6. Modify: 2022-06-02 08:54:33.177240007 +0000
  7. Change: 2022-06-02 08:54:33.177240007 +0000

可通过比较size和offset来判断采集进度。如果size=offset，则说明已经文件已经全部采集并发送成功。