通过ICAgent采集容器日志(不推荐)
CCE配合AOM收集工作负载的日志,在创建节点时会默认安装AOM的ICAgent(在集群kube-system命名空间下名为icagent的DaemonSet),ICAgent负责收集工作负载的日志并上报到AOM,您可以在CCE控制台和AOM控制台查看工作负载的日志。
约束与限制
ICAgent只采集*.log、*.trace和*.out类型的文本日志文件。
使用ICAgent采集日志
在工作负载中可以单独配置日志采集策略,此策略需要使用ICAgent。
- 在CCE中创建工作负载时,在配置容器信息时可以设置容器日志。
- 单击添加日志策略。
以nginx为例,不同工作负载根据实际情况配置。图1 添加日志策略
- 存储类型有“主机路径”和“容器路径”两种类型可供选择:
表1 配置日志策略 参数
参数说明
存储类型
- 主机路径:HostPath模式,将主机路径挂载到指定的容器路径(挂载路径)。用户可以在节点的主机路径中查看到容器输出在挂载路径中的日志信息。
- 容器路径:EmptyDir模式,将节点的临时路径挂载到指定的路径(挂载路径)。临时路径中存在的但暂未被采集器上报到AOM的日志数据在Pod实例删除后会消失。
主机路径
请输入主机的路径,如:/var/paas/sys/log/nginx
挂载路径
请输入数据存储要挂载到容器上的路径,如:/tmp须知:- 请不要挂载到系统目录下,如“/”、“/var/run”等,否则会导致容器异常。建议挂载在空目录下,若目录不为空,请确保目录下无影响容器启动的文件,否则文件会被替换,导致容器启动异常,工作负载创建失败。
- 挂载高危目录的情况下 ,建议使用低权限账号启动,否则可能会造成宿主机高危文件被破坏。
- AOM只采集最近修改过的前20个日志文件,且默认采集两级子目录。
- AOM只采集挂载路径下的“.log”、“.trace”、“.out”文本日志文件。
- 容器中挂载点的权限设置方法,请参见为Pod或容器配置安全性上下文。
主机扩展路径
仅“主机路径”类型需要填写
通过实例的ID或者容器的名称扩展主机路径,实现同一个主机路径下区分来自不同容器的挂载。
会在原先的“卷目录/子目录”中增加一个三级目录。使用户更方便获取单个Pod输出的文件。
- None:不配置拓展路径。
- PodUID:Pod的ID。
- PodName:Pod的名称。
- PodUID/ContainerName:Pod的ID/容器名称。
- PodName/ContainerName:Pod名称/容器名称。
采集路径
设置采集路径可以更精确的指定采集内容,当前支持以下设置方式:
- 不设置则默认采集当前路径下.log .trace .out文件
- 设置**表示递归采集5层目录下的.log .trace .out文件
- 设置*表示模糊匹配
例子: 采集路径为/tmp/**/test*.log表示采集/tmp目录及其1-5层子目录下的全部以test开头的.log文件。
注意:使用采集路径功能请确认您的采集器ICAgent版本为5.12.22或以上版本。
日志转储
此处日志转储是指日志的本地绕接。
- 设置:AOM每分钟扫描一次日志文件,当某个日志文件超过50MB时会对其转储(转储时会在该日志文件所在的目录下生成一个新的zip文件。对于一个日志文件,AOM只保留最近生成的20个zip文件,当zip文件超过20个时,时间较早的zip文件会被删除)。
- 不设置:若您在下拉列表框中选择“不设置”,则AOM不会对日志文件进行转储。
说明:- AOM的日志绕接能力是使用copytruncate方式实现的,如果选择了设置,请务必保证您写日志文件的方式是append(追加模式),否则可能出现文件空洞问题。
- 当前主流的日志组件例如Log4j、Logback等均已经具备日志文件的绕接能力,如果您的日志文件已经实现了绕接能力,则无需设置。否则可能出现冲突。
- 建议您的业务自己实现绕接,可以更灵活的控制绕接文件的大小和个数。
- 单击“确定”,并完成创建工作负载。
YAML示例(ICAgent)
您可以通过在YAML定义的方式设置容器日志存储路径。
如下所示,使用EmptyDir挂载到容器的“/var/log/nginx”路径下,这样ICAgent就会采集容器“/var/log/nginx”路径下的日志。其中policy字段是CCE自定义的字段,能够让ICAgent识别并采集日志。
apiVersion: apps/v1 kind: Deployment metadata: name: testlog namespace: default spec: selector: matchLabels: app: testlog template: replicas: 1 metadata: labels: app: testlog spec: containers: - image: 'nginx:alpine' name: container-0 resources: requests: cpu: 250m memory: 512Mi limits: cpu: 250m memory: 512Mi volumeMounts: - name: vol-log mountPath: /var/log/nginx policy: logs: rotate: '' volumes: - emptyDir: {} name: vol-log imagePullSecrets: - name: default-secret
使用HostPath方法如下所示,相比EmptyDir就是volume的类型变成hostPath,且需要配置hostPath在主机上的路径。下面示例中将主机上“/tmp/log”挂载到容器的“/var/log/nginx”路径下,这样ICAgent就会采集容器“/var/log/nginx”路径下的日志,且日志还会在主机的“/tmp/log”路径下存储。
apiVersion: apps/v1 kind: Deployment metadata: name: testlog namespace: default spec: replicas: 1 selector: matchLabels: app: testlog template: metadata: labels: app: testlog spec: containers: - image: 'nginx:alpine' name: container-0 resources: requests: cpu: 250m memory: 512Mi limits: cpu: 250m memory: 512Mi volumeMounts: - name: vol-log mountPath: /var/log/nginx readOnly: false extendPathMode: PodUID policy: logs: rotate: Hourly annotations: pathPattern: '**' format: '' volumes: - hostPath: path: /tmp/log name: vol-log imagePullSecrets: - name: default-secret
参数 |
解释 |
说明 |
---|---|---|
extendPathMode |
主机扩展路径 |
通过实例的ID或者容器的名称扩展主机路径,实现同一个主机路径下区分来自不同容器的挂载。 会在原先的“卷目录/子目录”中增加一个三级目录。使用户更方便获取单个Pod输出的文件。
|
policy.logs.rotate |
日志转储 |
此处日志转储是指日志的本地绕接。
说明:
|
policy.logs.annotations.pathPattern |
采集路径 |
设置采集路径可以更精确的指定采集内容,当前支持以下设置方式:
例子: 采集路径为/tmp/**/test*.log表示采集/tmp目录及其1-5层子目录下的全部以test开头的.log文件。
注意:
使用采集路径功能请确认您的采集器ICAgent版本为5.12.22或以上版本。 |
policy.logs.annotations.format |
多行日志匹配 |
有些程序打印的日志存在一条完整的日志数据跨占多行(例如 Java 程序日志)情况,日志采集系统默认是按行采集。如果您想在日志采集系统中按整条显示日志,可以开启多行日志,采用时间或正则匹配的方式,当某行日志匹配上预先设置的时间格式或正则表达式,就认为是一条日志的开头,而下一个行首出现作为该条日志的结束标识符。 格式如下 { "multi": { "mode": "time", "value": "YYYY-MM-DD hh:mm:ss" } } multi表示分行模式:
|
查看日志
日志采集路径配置和工作负载创建完成后,若已配置的路径下存在日志文件,则ICAgent会从已配置的路径中采集日志文件,采集大概需要1分钟,请您耐心等待。
待采集完成后,进入工作负载详情页,单击右上角的“日志”按钮查看日志详情。
您还可以在AOM控制台查看日志。
另外您还可以使用kubectl logs命令查看容器的标准输出,具体如下所示。
# 查看指定pod的日志 kubectl logs <pod_name> kubectl logs -f <pod_name> #类似tail -f的方式查看 # 查看指定pod中指定容器的日志 kubectl logs <pod_name> -c <container_name> kubectl logs pod_name -c container_name -n namespace (一次性查看) kubectl logs -f <pod_name> -n namespace (tail -f方式实时查看)