使用Logtail采集Kubernetes上挂载的NAS日志

本文涉及的产品
容器镜像服务 ACR,镜像仓库100个 不限时长
简介: 采集k8s挂载Nas后的日志该文档主要介绍使用logtail以两种不同的方式进行k8s挂载Nas后的日志采集。两种采集方式的实现原理是一样的,都是通过将Logtail和业务容器挂载到相同的NAS上,使Logtail和业务容器的日志数据共享,以此实现日志采集。

采集k8s挂载Nas后的日志


该文档主要介绍使用logtail以两种不同的方式进行k8s挂载Nas后的日志采集。两种采集方式的实现原理是一样的,都是通过将Logtail和业务容器挂载到相同的NAS上,使Logtail和业务容器的日志数据共享,以此实现日志采集。下面是两种采集方式的各自特点:


  1. SideCar模式。比较灵活、适合水平扩容,适用于数据量较大的场景;
  2. 单独部署Logtail的Deployment。资源消耗比较低、但灵活性以及伸缩性不强,适用于整体集群数据量较少的场景(建议整体日志量不超过每秒10M)。


1. Sidecar NAS采集方式


通过 链接 使用PV&PVC的方式配置挂载Nas的nas-pvc


  • 步骤一 创建pv
  • 步骤二 创建pvc
  • 步骤三 根据下面的yaml模板创建含有logtail的Pod,进行单个Pod的内部采集


sideCar模式实验yaml内容:


apiVersion: batch/v1
kind: Job
metadata:
  name: nginx-log-sidecar1-demo
spec:
  template:
    metadata:
      name: nginx-log-sidecar-demo
    spec:
      # volumes配置
      volumes:
      - name: nginx-log
        persistentVolumeClaim:
              claimName: nas-pvc
      containers:
      # 主容器配置
      - name: nginx-log-demo
        image: registry.cn-hangzhou.aliyuncs.com/log-service/docker-log-test:latest
        command: ["/bin/mock_log"]
        args: ["--log-type=nginx", "--stdout=false", "--stderr=true", "--path=/var/log/nginx/access.log", "--total-count=1000000000", "--logs-per-sec=100"]
        volumeMounts:
        - name: nginx-log
          mountPath: /var/log/nginx
      # Logtail的Sidecar容器配置
      - name: logtail
        image: registry.cn-hangzhou.aliyuncs.com/log-service/logtail:latest
        env:
          # user id
          - name: "ALIYUN_LOGTAIL_USER_ID"
            value: "${your_aliyun_user_id}"
          # user defined id
          - name: "ALIYUN_LOGTAIL_USER_DEFINED_ID"
            value: "${your_machine_group_user_defined_id}"
          # config file path in logtail's container
          - name: "ALIYUN_LOGTAIL_CONFIG"
            value: "/etc/ilogtail/conf/${your_region_config}/ilogtail_config.json"
          # env tags config
          - name: "ALIYUN_LOG_ENV_TAGS"
            value: "_pod_name_|_pod_ip_|_namespace_|_node_name_|_node_ip_"
          - name: "_pod_name_"
            valueFrom:
              fieldRef:
                fieldPath: metadata.name
          - name: "_pod_ip_"
            valueFrom:
              fieldRef:
                fieldPath: status.podIP
          - name: "_namespace_"
            valueFrom:
              fieldRef:
                fieldPath: metadata.namespace
          - name: "_node_name_"
            valueFrom:
              fieldRef:
                fieldPath: spec.nodeName
          - name: "_node_ip_"
            valueFrom:
              fieldRef:
                fieldPath: status.hostIP
        # 和主容器共享volume
        volumeMounts:
        - name: nginx-log
          mountPath: /var/log/nginx
        # 健康检查
        livenessProbe:
          exec:
            command:
            - /etc/init.d/ilogtaild
            - status
          initialDelaySeconds: 30
          periodSeconds: 30
      restartPolicy: "Never"


SLS控制台采集配置设置如下图:


 dd8bebdf-50a3-410a-9b9f-48409ebbc0e3.png




  • 日志路径与被采集容器的日志所在路径一致
  • 注意:由于NAS路径已经挂载到了Logtail容器上,所以不需要打开docker文件的按钮


采集上来的系统默认字段含义:  

__source__:  pod容器内部IP
__tag__:__hostname__:  pod名称
__tag__:__path__:  日志路径
__tag__:__receive_time__:  采集时间
__tag__:__user_defined_id__:  用户自定义标识
__tag__:_namespace_:  pod所属namaspace
__tag__:_node_ip_:  pod所在Node的IP地址
__tag__:_node_name_:  pod所属Node的name
__tag__:_pod_ip_:  pod容器内部IP
__tag__:_pod_name_:  pod名称


用户参数:


参数

说明

${your_region_config}

该参数由日志服务Project所在Region以及网络类型决定,请根据网络类型输入正确的格式。包括:

  •              公网:region-internet。例如,华东一为cn-hangzhou-internet            
  •              阿里云内网:region。例如,华东一为cn-hangzhou            

其中,region为
           表一,请根据Project地域选择正确的参数。

${your_aliyun_user_id}

用户标识,请替换为您的阿里云主账号用户ID。主账号用户ID为字符串形式,如何查看ID请参考
           用户标识配置中的2.1节。

说明?用户标识一定是?主账号用户ID,子账号ID没有任何意义。

${your_machine_group_user_defined_id}

您集群的机器组自定义标识。需确保该标识在您的日志服务所在Region内唯一。详细内容可参考
           创建用户自定义标识机器组


2. 一个Logtail采集所有POD的NAS数据


注意项:副本数spec.replicas只能为1,不能更多,多了会重复采集。


首先,创建一个logtail的deployment,以下是本次使用的模板:


apiVersion: apps/v1
kind: Deployment
metadata:
  name: logtail-deployment
  namespace: kube-system
  labels:
    k8s-app: nas-logtail-collecter
spec:
  replicas: 1
  selector:
    matchLabels:
      k8s-app : nas-logtail-collecter
  template:
    metadata:
      name: logtail-deployment
      labels:
        k8s-app : nas-logtail-collecter
    spec:
      containers:
      # Logtail的配置
      - name: logtail
        image: registry.cn-hangzhou.aliyuncs.com/log-service/logtail:latest
        env:
          # aliuid
          - name: "ALIYUN_LOGTAIL_USER_ID"
            value: "${your_aliyun_user_id}"
          # user defined id
          - name: "ALIYUN_LOGTAIL_USER_DEFINED_ID"
            value: "${your_machine_group_user_defined_id}"
          # config file path in logtail's container
          - name: "ALIYUN_LOGTAIL_CONFIG"
            value: "/etc/ilogtail/conf/${your_region_config}/ilogtail_config.json"
        volumeMounts:
        - name: nginx-log
          mountPath: /var/log/nginx
      # volumes配置
      volumes:
      - name: nginx-log
        persistentVolumeClaim:
              claimName: pvc-test-nginx


  • 注意:这里的 claimName: pvc-test-nginx 以及mountPath: /var/log/nginx 是将logtail的/var/log/nginx挂载了Nas下的/nginx文件夹
  • 相关参数设置请参考方案1中的表格说明


logtail运行成功之后,可以在SLS控制台根据模板中的ALIYUN_LOGTAIL_USER_DEFINED_ID创建对应的机器组,请参考方案1中的表格说明。


这里新建2个Pod来测试采集是否成功,其中一个POD的模板为:


apiVersion: v1
kind: Pod
metadata:
  name: "test-nginx-2"
spec:
  containers:
    - name: "nginx-log-demo"
      image: "registry.cn-hangzhou.aliyuncs.com/log-service/docker-log-test:latest"
      command: ["/bin/mock_log"]
      args: ["--log-type=nginx", "--stdout=false", "--stderr=true", "--path=/var/log/nginx/access.log", "--total-count=1000000000", "--logs-per-sec=100"]
      volumeMounts:
        - name: "nas2"
          mountPath: "/var/log/nginx"
  volumes:
    - name: "nas2"
      flexVolume:
        driver: "alicloud/nas"
        options:
          server: "Nas挂载地址"
          path: "/nginx/test2"
          vers: "4.0"


另一个Pod将 /var/log/nginx 挂载在了 /nginx/test1 目录下;结合logtail的挂载情况,现在两个Pod分别挂载在 /nginx/test1 和 /nginx/test2,而logtail挂载在了 /nginx 下。


最后配置logtail的采集配置

83cff657-ce65-4e1a-b444-d478f2ab986f.png

因为logtail也挂载了相同的Nas,所以logtail只需要采集自身文件夹下的日志就可以了,这里的是否为docker文件选项关闭。
注意:由于NAS路径已经挂载到了Logtail容器上,所以不需要打开docker文件的按钮

相关实践学习
基于ECS和NAS搭建个人网盘
本场景主要介绍如何基于ECS和NAS快速搭建个人网盘。
阿里云文件存储 NAS 使用教程
阿里云文件存储(Network Attached Storage,简称NAS)是面向阿里云ECS实例、HPC和Docker的文件存储服务,提供标准的文件访问协议,用户无需对现有应用做任何修改,即可使用具备无限容量及性能扩展、单一命名空间、多共享、高可靠和高可用等特性的分布式文件系统。 产品详情:https://www.aliyun.com/product/nas
目录
相关文章
|
23天前
|
监控 测试技术 开发者
一行代码改进:Logtail的多行日志采集性能提升7倍的奥秘
一个有趣的现象引起了作者的注意:当启用行首正则表达式处理多行日志时,采集性能出现下降。究竟是什么因素导致了这种现象?本文将探索Logtail多行日志采集性能提升的秘密。
|
2月前
|
存储 数据采集 分布式计算
Hadoop-17 Flume 介绍与环境配置 实机云服务器测试 分布式日志信息收集 海量数据 实时采集引擎 Source Channel Sink 串行复制负载均衡
Hadoop-17 Flume 介绍与环境配置 实机云服务器测试 分布式日志信息收集 海量数据 实时采集引擎 Source Channel Sink 串行复制负载均衡
57 1
|
3月前
|
Kubernetes API Docker
跟着iLogtail学习容器运行时与K8s下日志采集方案
iLogtail 作为开源可观测数据采集器,对 Kubernetes 环境下日志采集有着非常好的支持,本文跟随 iLogtail 的脚步,了解容器运行时与 K8s 下日志数据采集原理。
|
4月前
|
存储 Kubernetes Java
在k8S中,容器内日志是怎么采集的?
在k8S中,容器内日志是怎么采集的?
|
3天前
|
Prometheus Kubernetes 监控
OpenAI故障复盘 - 阿里云容器服务与可观测产品如何保障大规模K8s集群稳定性
聚焦近日OpenAI的大规模K8s集群故障,介绍阿里云容器服务与可观测团队在大规模K8s场景下我们的建设与沉淀。以及分享对类似故障问题的应对方案:包括在K8s和Prometheus的高可用架构设计方面、事前事后的稳定性保障体系方面。
|
5天前
|
Kubernetes 网络协议 应用服务中间件
Kubernetes Ingress:灵活的集群外部网络访问的利器
《Kubernetes Ingress:集群外部访问的利器-打造灵活的集群网络》介绍了如何通过Ingress实现Kubernetes集群的外部访问。前提条件是已拥有Kubernetes集群并安装了kubectl工具。文章详细讲解了Ingress的基本组成(Ingress Controller和资源对象),选择合适的版本,以及具体的安装步骤,如下载配置文件、部署Nginx Ingress Controller等。此外,还提供了常见问题的解决方案,例如镜像下载失败的应对措施。最后,通过部署示例应用展示了Ingress的实际使用方法。
21 2
|
17天前
|
存储 Kubernetes 关系型数据库
阿里云ACK备份中心,K8s集群业务应用数据的一站式灾备方案
本文源自2024云栖大会苏雅诗的演讲,探讨了K8s集群业务为何需要灾备及其重要性。文中强调了集群与业务高可用配置对稳定性的重要性,并指出人为误操作等风险,建议实施周期性和特定情况下的灾备措施。针对容器化业务,提出了灾备的新特性与需求,包括工作负载为核心、云资源信息的备份,以及有状态应用的数据保护。介绍了ACK推出的备份中心解决方案,支持命名空间、标签、资源类型等维度的备份,并具备存储卷数据保护功能,能够满足GitOps流程企业的特定需求。此外,还详细描述了备份中心的使用流程、控制台展示、灾备难点及解决方案等内容,展示了备份中心如何有效应对K8s集群资源和存储卷数据的灾备挑战。
|
1月前
|
Kubernetes 监控 Cloud Native
Kubernetes集群的高可用性与伸缩性实践
Kubernetes集群的高可用性与伸缩性实践
75 1
|
2月前
|
JSON Kubernetes 容灾
ACK One应用分发上线:高效管理多集群应用
ACK One应用分发上线,主要介绍了新能力的使用场景
|
2月前
|
Kubernetes 持续交付 开发工具
ACK One GitOps:ApplicationSet UI简化多集群GitOps应用管理
ACK One GitOps新发布了多集群应用控制台,支持管理Argo CD ApplicationSet,提升大规模应用和集群的多集群GitOps应用分发管理体验。

相关产品

  • 容器服务Kubernetes版