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

本文涉及的产品
容器镜像服务 ACR,镜像仓库100个 不限时长
容器服务 Serverless 版 ACK Serverless,317元额度 多规格
容器服务 Serverless 版 ACK Serverless,952元额度 多规格
简介: 采集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
目录
相关文章
|
6月前
|
存储 运维 监控
Kubernetes 集群监控与日志管理实践
【5月更文挑战第28天】在微服务架构日益普及的当下,容器编排工具如 Kubernetes 已成为运维工作的核心。有效的集群监控和日志管理是确保系统稳定性和服务可靠性的关键。本文将深入探讨 Kubernetes 集群的监控策略,以及如何利用现有的工具进行日志收集、存储和分析,以实现对集群健康状况的实时掌握和问题快速定位。
|
6月前
|
存储 监控 Kubernetes
Kubernetes 集群监控与日志管理实践
【5月更文挑战第27天】 在微服务架构日益普及的当下,容器化技术与编排工具如Kubernetes已成为现代云原生应用的基石。然而,随着集群规模的不断扩大和复杂性的增加,如何有效监控和管理这些动态变化的服务成为了维护系统稳定性的关键。本文将深入探讨Kubernetes环境下的监控策略和日志管理的最佳实践,旨在为运维人员提供一套系统的解决思路,确保应用性能的最优化和问题的快速定位。
|
4月前
|
存储 运维 Serverless
函数计算产品使用问题之遇到NAS已经挂载但显示未挂载的情况时,该怎么办
函数计算产品作为一种事件驱动的全托管计算服务,让用户能够专注于业务逻辑的编写,而无需关心底层服务器的管理与运维。你可以有效地利用函数计算产品来支撑各类应用场景,从简单的数据处理到复杂的业务逻辑,实现快速、高效、低成本的云上部署与运维。以下是一些关于使用函数计算产品的合集和要点,帮助你更好地理解和应用这一服务。
函数计算产品使用问题之遇到NAS已经挂载但显示未挂载的情况时,该怎么办
|
4月前
|
人工智能 运维 Serverless
函数计算产品使用问题之如何实现NAS的挂载
阿里云Serverless 应用引擎(SAE)提供了完整的微服务应用生命周期管理能力,包括应用部署、服务治理、开发运维、资源管理等功能,并通过扩展功能支持多环境管理、API Gateway、事件驱动等高级应用场景,帮助企业快速构建、部署、运维和扩展微服务架构,实现Serverless化的应用部署与运维模式。以下是对SAE产品使用合集的概述,包括应用管理、服务治理、开发运维、资源管理等方面。
|
5月前
|
运维 Serverless 文件存储
Serverless 应用引擎产品使用合集之如何将nas挂载到fc目录中
阿里云Serverless 应用引擎(SAE)提供了完整的微服务应用生命周期管理能力,包括应用部署、服务治理、开发运维、资源管理等功能,并通过扩展功能支持多环境管理、API Gateway、事件驱动等高级应用场景,帮助企业快速构建、部署、运维和扩展微服务架构,实现Serverless化的应用部署与运维模式。以下是对SAE产品使用合集的概述,包括应用管理、服务治理、开发运维、资源管理等方面。
|
5月前
|
存储 运维 Serverless
Serverless 应用引擎产品使用合集之在FC中挂载NAS到函数上,该如何操作
阿里云Serverless 应用引擎(SAE)提供了完整的微服务应用生命周期管理能力,包括应用部署、服务治理、开发运维、资源管理等功能,并通过扩展功能支持多环境管理、API Gateway、事件驱动等高级应用场景,帮助企业快速构建、部署、运维和扩展微服务架构,实现Serverless化的应用部署与运维模式。以下是对SAE产品使用合集的概述,包括应用管理、服务治理、开发运维、资源管理等方面。
|
6月前
|
运维 Prometheus 监控
Kubernetes 集群监控与日志管理实践
【5月更文挑战第29天】 在微服务架构日益盛行的今天,容器化技术已成为现代应用部署的标准。其中,Kubernetes 作为容器编排的事实标准,其集群的稳定性和性能监控变得至关重要。本文将深入探讨 Kubernetes 集群的监控策略和日志管理的最佳实践,旨在为运维工程师提供一套高效、可靠的集群监控解决方案。通过引入 Prometheus 和 Grafana 工具进行数据收集与可视化,以及 Fluentd 和 Elasticsearch 配合 Kibana 实现日志聚合与分析,本文将带领读者构建起一个全面的 Kubernetes 监控系统,确保系统的高可用性和故障快速响应。
|
5月前
|
运维 Serverless 文件存储
函数计算产品使用问题之在利用Docker镜像部署应用时,容器内的应用如何能访问函数计算配置的NAS挂载
函数计算产品作为一种事件驱动的全托管计算服务,让用户能够专注于业务逻辑的编写,而无需关心底层服务器的管理与运维。你可以有效地利用函数计算产品来支撑各类应用场景,从简单的数据处理到复杂的业务逻辑,实现快速、高效、低成本的云上部署与运维。以下是一些关于使用函数计算产品的合集和要点,帮助你更好地理解和应用这一服务。
|
6月前
|
Prometheus 监控 Kubernetes
Kubernetes 集群的监控与日志管理实践
【5月更文挑战第25天】在现代微服务架构中,容器编排工具如Kubernetes已成为部署、管理和扩展应用程序的关键。随着其广泛应用,对集群的监控和日志管理的需求也日益增长。本文将探讨如何利用Prometheus和Fluentd等开源工具实现对Kubernetes集群的有效监控和日志收集,旨在为运维工程师提供一套可行的解决方案,以保障集群的稳定性和提高故障排查效率。
|
6月前
|
Prometheus 监控 Kubernetes
Kubernetes 集群的监控与日志管理实践深入理解PHP的命名空间与自动加载机制
【5月更文挑战第30天】 在容器化和微服务架构日益普及的背景下,Kubernetes 已成为众多企业的首选容器编排工具。然而,随之而来的挑战是集群的监控与日志管理。本文将深入探讨 Kubernetes 集群监控的最佳实践,包括节点资源使用情况、Pods 健康状态以及网络流量分析等关键指标的监控方法。同时,我们也将讨论日志聚合、存储和查询策略,以确保快速定位问题并优化系统性能。文中将介绍常用的开源工具如 Prometheus 和 Fluentd,并分享如何结合这些工具构建高效、可靠的监控和日志管理系统。

热门文章

最新文章

相关产品

  • 容器服务Kubernetes版