CN115357459A - 一种基于kubernetes的日志搜集方法 - Google Patents

一种基于kubernetes的日志搜集方法 Download PDF

Info

Publication number
CN115357459A
CN115357459A CN202210196112.3A CN202210196112A CN115357459A CN 115357459 A CN115357459 A CN 115357459A CN 202210196112 A CN202210196112 A CN 202210196112A CN 115357459 A CN115357459 A CN 115357459A
Authority
CN
China
Prior art keywords
log
fluent
kubernets
cluster
logs
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
CN202210196112.3A
Other languages
English (en)
Inventor
华张辉
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Zhongjiao Yunzhi Digital Technology Co ltd
Original Assignee
Zhongjiao Yunzhi Digital Technology Co ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Zhongjiao Yunzhi Digital Technology Co ltd filed Critical Zhongjiao Yunzhi Digital Technology Co ltd
Priority to CN202210196112.3A priority Critical patent/CN115357459A/zh
Publication of CN115357459A publication Critical patent/CN115357459A/zh
Pending legal-status Critical Current

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3466—Performance evaluation by tracing or monitoring
    • G06F11/3476—Data logging
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/1805—Append-only file systems, e.g. using logs or journals to store data
    • G06F16/1815—Journaling file systems

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Debugging And Monitoring (AREA)

Abstract

本发明公开了一种基于kubernetes的日志搜集方法，包括S1、交付Fluentd至k8s集群，并配置日志源；S2、交付Elasticsearch至k8s集群；S3、进行WEB展示。本方案使用统一日志存储：使用统一日志存储后，所有集群分散日志将可以在统一web平台查看；Fluentd支持基于内存和基于文件的缓冲区来避免内部节点的数据丢失。Fluentd还支持容错和设置高可用，使得本方法具有高可靠性。本方法基于kubernetes进行日志搜集，使用JSON后，下游的数据处理灵活，因为JSON结构在保留了灵活的模式的同时，可以被无障碍的使用，有良好的可扩展性，可移植性和可维护性，提高故障定位效率以及降低运行维护成本，同时能够提高kubernetes集群中故障定位效率，降低性能损耗、提升资源利用率，以及便于持续观察维护以及针对性优化产品。

Description

一种基于kubernetes的日志搜集方法
技术领域
本发明涉及软件开发技术领域，具体而言，涉及一种基于kubernetes的日志搜集方法。
背景技术
通常的，需要进行日志分析场景直接在日志文件中grep、awk就可以获得自己想要的信息。但在规模较大的场景中，此方法效率低下，面临问题包括日志量太大如何归档、文本搜索太慢怎么办、如何多维度查询。需要集中化的日志管理，所有服务器上的日志收集汇总。常见解决思路是建立集中式日志收集系统，将所有节点上的日志统一收集，管理，访问。
一般大型系统是一个分布式部署的架构，不同的服务模块部署在不同的服务器上，问题出现时，大部分情况需要根据问题暴露的关键信息，定位到具体的服务器和服务模块，构建一套集中式日志系统，可以提高定位问题的效率。一个完整的集中式日志系统，需要包含以下几个主要特点：收集-能够采集多种来源的日志数据；传输-能够稳定的把日志数据传输到中央系统；存储-如何存储日志数据；分析-可以支持UI分析；警告-能够提供错误报告，监控机制。传统软件架构部署模式已不足以支持现在比较潮流的云原生模式，所以本专利提供了一整套解决方案，并且是基于中教云数字课程教材云平台的部署架构所提出的一种基于kubernetes的日志搜集方法。
发明内容
本发明的主要目的在于提供一种基于kubernetes的日志搜集方法，以改善相关技术中的传统软件架构部署模式已不足以支持现在比较潮流的云原生模式的问题。
为了实现上述目的，本发明提供了一种基于kubernetes的日志搜集方法，包括以下具体步骤：
S1、交付Fluentd至k8s集群，并配置日志源；
S2、交付Elasticsearch至k8s集群；
S3、进行WEB展示。
在本发明的一种实施例中，S2中，修改Fluentd的配置项match，将match配置成＊＊。
在本发明的一种实施例中，S2中，修改type，将type配置成Elasticsearch，并将Fluentd数据源地址指向为Elasticsearch。
在本发明的一种实施例中，S3中，已经搜集到pod日志至数据存储Elasticsearch中。
在本发明的一种实施例中，S3中，使用kibana作为Elasticsearch提供日志分析的web接口，使用它对日志进行高效的搜索、可视化、分析等各种操作。
在本发明的一种实施例中，S1中，k8s日志收集具体步骤包括：配置configmap，作为配置文件挂载到fluentd；创建自定义镜像，安装需要的插件；创建部署脚本deploy.sh；版本控管脚本version.sh。
在本发明的一种实施例中，配置configmap的步骤具体包括：添加Kubernetesmetadata数据；只保留具有logging＝1标签的Pod日志；删除一些多余的属性；设置index前缀为k8s。
在本发明的一种实施例中，S1中，使用自己搭建的es集群时，只需要在kubernetesgithubcluster/addons/fluentd-elasticsearch中下载create-logging-namespace.yaml、fluentd-es-conflgmap.yaml和fluentd-es-ds.yaml三个文件即可。
与现有技术相比，本发明的有益效果是：通过上述设计的基于kubernetes的日志搜集方法，使用时，使用JSON统一日志结构：使用JSON后，下游的数据处理起来相当的容易，因为JSON结构在保留了灵活的模式的同时，可以被无障碍的使用；使用统一日志存储：使用统一日志存储后，所有集群分散日志将可以在统一web平台查看；Fiuentd支持基于内存和基于文件的缓冲区来避免内部节点的数据丢失。Fluentd还支持容错和设置高可用，使得本方法具有高可靠性。本方法基于kubernetes进行日志搜集，有良好的可扩展性，可移植性和可维护性，提高故障定位效率以及降低运行维护成本，同时能够提高kubernetes集群中故障定位效率，降低性能损耗、提升资源利用率，以及便于持续观察维护以及针对性优化产品。
附图说明
图1为根据本发明实施例提供的基于kubernetes的日志搜集方法的流程示意图；
图2为根据本发明实施例提供的基于kubernetes的日志搜集方法的集群结构示意图；
图3为根据本发明实施例提供的基于kubernetes的日志搜集方法的交付Fluentd至k8s集群并配置日志源示意图；
图4为根据本发明实施例提供的基于kubernetes的日志搜集方法的配置项match示意图。
具体实施方式
为了使本技术领域的人员更好地理解本发明方案，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本发明一部分的实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都应当属于本发明保护的范围。
需要说明的是，本发明的说明书和权利要求书及上述附图中的术语“第一”、“第二”等是用于区别类似的对象，而不必用于描述特定的顺序或先后次序。应该理解这样使用的数据在适当情况下可以互换，以便这里描述的本发明的实施例。此外，术语“包括”和“具有”以及他们的任何变形，意图在于覆盖不排他的包含，例如，包含了一系列步骤或单元的过程、方法、系统、产品或设备不必限于清楚地列出的那些步骤或单元，而是可包括没有清楚地列出的或对于这些过程、方法、产品或设备固有的其它步骤或单元。
在本发明中，术语“上”、“下”、“左”、“右”、“前”、“后”、“顶”、“底”、“内”、“外”、“中”、“竖直”、“水平”、“横向”、“纵向”等指示的方位或位置关系为基于附图所示的方位或位置关系。这些术语主要是为了更好地描述本发明及其实施例，并非用于限定所指示的装置、元件或组成部分必须具有特定方位，或以特定方位进行构造和操作。
并且，上述部分术语除了可以用于表示方位或位置关系以外，还可能用于表示其他含义，例如术语“上”在某些情况下也可能用于表示某种依附关系或连接关系。对于本领域普通技术人员而言，可以根据具体情况理解这些术语在本发明中的具体含义。
另外，术语“多个”的含义应为两个以及两个以上。
需要说明的是，在不冲突的情况下，本发明中的实施例及实施例中的特征可以相互组合。下面将参考附图并结合实施例来详细说明本发明。
实施例1
请参阅图1-图4，本发明提供了一种基于kubernetes的日志搜集方法，见图1，包括以下具体步骤：
S1、交付Fluentd至k8s集群，并配置日志源；
S2、交付Elasticsearch至k8s集群；
S3、进行WEB展示。
见图2，Fluentd是一个开源的日志收集系统，能够收集各式各样的日志，并将日志转换成方便机器处理的json格式。Kubernetes是Google开源的一个容器编排引擎，它支持自动化部署、大规模可伸缩、应用容器化管理。在生产环境中部署一个应用程序时，通常要部署该应用的多个实例以便对应用请求进行负载均衡。在Kubernetes中，可以创建多个容器，每个容器里面运行一个应用实例，然后通过内置的负载均衡策略，实现对这一组应用实例的管理、发现、访问而这些细节都不需要运维人员去进行复杂的手工配置和处理Kubernetes整个框架产生的日志主要划分为以下四种：
1.Cluster(集群)级别的日志
2.Node(节点)级别的日志
3.Pod(共同构成一个应用的容器集合)级别的日志
4.Docker(容器)级别的日志
通过应用和系统日志可以了解Kubernetes集群内所发生的事情，对于调试问题和监视集群活动来说日志非常有用。对于大部分的应用来说，都会具有某种日志机制。因此，大多数容器引擎同样被设计成支持某种日志机制。对于容器化应用程序来说，最简单和最易接受的日志记录方法是将日志内容写入到标准输出和标准错误流。
因此，日志应该具有独立于Node、Pod或者容器的单独存储和生命周期，这个概念被称为群集级日志记录。群集级日志记录需要一个独立的后端来存储、分析和查询日志。Kubernetes本身并没有为日志数据提供原生的存储解决方案，但可以将许多现有的日志记录解决方案集成到Kubernetes集群中。kubernetes基础日志即将日志数据输出到标准输出流，使用kubectl logs加容器名和命名空间来获取容器日志信息。因为日志记录必须在每个Node上运行，所以通常将它作为DaemonSet副本、或一个清单Pod或Node上的专用本机进程。然而，后两种方法后续将会被放弃，Node级别日志记录仅适用于应用程序的标准输出和标准错误。
Kubernetes本身并没有指定日志记录代理，和谷歌云平台一起使用的Stackdriver和Elasticsearch，两者都使用自定义配置的fluentd作为Node上的代理。在本方案中，Logging-agent采用Fluentd，而Logging Backend采用Elasticsearch，前端展示采用Kibana。即通过Fluentd作为Logging-agent收集日志，并推送给后端的Elasticsearch；前端展示采用Kibana从Elasticsearch中获取日志，并进行统一的展示。
S1中，用k8s的daemonset可以方便的在每个node上安装fluent agent，k8s日志收集具体步骤包括：配置configmap，作为配置文件挂载到fluentd；创建自定义镜像，安装需要的插件；创建部署脚本deploy.sh；版本控管脚本version.sh。
配置configmap的步骤具体包括：添加Kubernetesmetadata数据；只保留具有logging＝1标签的Pod日志；删除一些多余的属性；设置index前缀为k8s。
S1中，使用自己搭建的es集群时，只需要在kubernetesgithubcluster/addons/fluentd-elasticsearch中下载create-logging-namespace.yaml、fluentd-es-configmap.yaml和fluentd-es-ds.yaml三个文件即可。按照需要修改output.conf中的match选项，使之能正确发送到es集群。修改完成后依次apply上述三个文件即可。
默认情况下logstash_format为true，索引为logstash-yyyy.mm.dd类别的字段，logstash_format为false后，设置索引名称为fluentd.${tag}，那么默认索引格式为fluentd.kubernetes.var.log.containers.busybox-log-6c5dc946b4-7x2ns_sre-test_busybox-463230e3342d38e89c79fod997c81b445b00d1032311ac9b641d439607d4cce4.log。
S2中，在创建Elasticsearch集群之前，先创建一个命名空间，将在其中安装所有日志相关的资源对象。新建一个namespace-logging.yaml文件vim namespace-logging.yaml。然后通过kubectl创建该资源清单，创建一个名为logging的namespace；接下来可以部署EFK相关组件，首先开始部署一个3节点的Elasticsearch集群。
一个关键点是您应该设置参数discover.zen.minimum_master_nodes＝N/2+1，其中N是Elasticsearch集群中符合主节点的节点数，这里3个节点，意味着N应该设置为2。如果一个节点暂时与集群断开连接，则另外两个节点可以选择一个新的主节点，并且集群可以在最后一个节点尝试重新加入时继续运行，在扩展Elasticsearch集群时，要记住这个参数。
首先创建一个名为elasticsearch的无头服务，新建文件elasticsearch-svc.yaml，文件内容如下：vim elasticsearch-svc.yaml。定义了一个名为elasticsearch的Service，指定标签app＝elasticsearch，当将Elasticsearch StatefulSet与此服务关联时，服务将返回带有标签app＝elasticsearch的Elasticsearch Pods的DNS A记录，然后设置clusterIP＝None，将该服务设置成无头服务。最后，分别定义端口9200、9300，分别用于与REST API交互，以及用于节点间通信。使用kubectl直接创建上面的服务资源对象，为Pod设置了无头服务和一个稳定的域名.elasticsearch.logging.svc.cluster.local，接下来通过StatefulSet来创建具体的Elasticsearch的Pod应用。
Kubernetes StatefulSet允许为Pod分配一个稳定的标识和持久化存储，Elasticsearch需要稳定的存储来保证Pod在重新调度或者重启后的数据依然不变，所以需要使用StatefulSet来管理Pod。
创建statefulset的资源清单：
vim elasticsearch-statefulset.yaml；
1、replicas：3副本数
2、将matchLabels设置为app＝elasticsearch，所以Pod的模板部分.spec.template.metadata.lables也必须包含app＝elasticsearch标签
3、cluster.name：Elasticsearch集群的名称，这里命名成k8s-logs
4、node.name：节点的名称，通过metadata.name来获取。这将解析为es-[0，1，2]，取决于节点的指定顺序
5、discovery.zen.minimum_master_nodes：将其设置为(N/2)+1，N是的群集中符合主节点的节点的数量。有3个
6、ES_JAVA_OPTS：这里设置为-Xms512m-Xmx512m，告诉JVM使用512MB的最小和最大堆。
由于添加了nodeSelector策略，需要在每个节点上加上label标签为es＝log，es集群才能部署成功，执行以下命令。使用volumeClaimTemplates来定义持久化模板，Kubernetes会使用它为Pod创建PersistentVolume，设置访问模式为ReadWriteOnce，这意味着它只能被mount到单个节点上进行读写，然后最重要的是使用了一个StorageClass对象，这里需要创建的Ceph RBD类型的名为es-data-db的StorageClass对象即可。最后，指定了每个PersistentVolume的大小为50GB，可以根据自己的实际需要进行调整该值。
创建kubernetes持久化存储-StorageClass，以NFS作为后端存储资源，在主节点安装NFS，共享/data/k8s/目录，也可以新找一台机器作为存储。
安装NFS：
创建Provisioner，使用nfs-client的自动配置程序：
vim nfs-client.yaml；
创建sa，然后绑定上对应的权限：
vim nfs-client-sa.yaml；
创建StorageClass：
vim elasticsearch-storageclass.yaml；
使用kubectl工具部署elasticsearch statefulset资源，Pods部署完成后，可以通过请求一个REST API来检查Elasticsearch集群是否正常运行。使用下面的命令将本地端口9200转发到Elasticsearch节点(如es-0)对应的端口。
Elasticsearch集群启动成功后，可以来部署Kibana服务，新建一个名为kibana.yaml的文件，对应的文件内容为vim kibana，定义了两个资源对象，一个Service和Deployment，为了测试方便，将Service设置为了NodePort类型，Kibana Pod中配置都比较简单，唯一需要注意的是使用ELASTICSEARCH_HOSTS这个环境变量来设置Elasticsearch集群的端点和端口，直接使用Kubernetes DNS即可，此端点对应服务名称为elasticsearch，由于是一个headless service，所以该域将解析为3个Elasticsearch Pod的IP地址列表。直接使用kubectl工具创建，创建完成后，可以查看Kibana Pod的运行状态。如果Pod已经是Running状态了，证明应用已经部署成功了，然后可以通过NodePort来访问Kibana这个服务，在浏览器中打开http：//<任意节点IP>：30417即可，如果看到如下欢迎界面证明Kibana已经成功部署到了Kubernetes集群之中。
S2中，Fluentd是一个高效的日志聚合器，是用Ruby编写的，并且可以很好地扩展。对于大部分企业来说，Fluentd足够高效并且消耗的资源相对较少，另外一个工具Fluent-bit更轻量级，占用资源更少，但是插件相对Fluentd来说不够丰富，所以整体来说，Fluentd更加成熟，使用更加广泛，所以这里也同样使用Fluentd来作为日志收集工具。Fluentd通过一组给定的数据源抓取日志数据，处理后(转换成结构化的数据格式)将它们转发给其他服务，比如Elasticsearch、对象存储等等
1、首先Fluentd从多个日志源获取数据；
2、结构化并且标记这些数据；
3、然后根据匹配的标签将数据发送到多个目标服务去。
见图3，部分参数说明如下
1、id：表示引用该日志源的唯一标识符，该标识可用于进一步过滤和路由结构化日志数据
2、type：Fluentd内置的指令，tail表示Fluentd从上次读取的位置通过tail不断获取数据，另外一个是http表示通过一个GET请求来收集数据。
3、path：tail类型下的特定参数，告诉Fluentd采集/var/log/containers目录下的所有日志，这是docker在Kubernetes节点上用来存储运行容器stdout输出日志数据的目录。
4、pos_file：检查点，如果Fluentd程序重新启动了，它将使用此文件中的位置来恢复日志数据收集。
5、tag：用来将日志源与目标或者过滤器匹配的自定义字符串，Fluentd匹配源/目标标签来路由日志数据。
使用JSON后，下游的数据处理起来相当的容易，因为JSON结构在保留了灵活的模式的同时，可以被无障碍的使用；使用统一日志存储：使用统一日志存储后，所有集群分散日志将可以在统一web平台查看；Fluentd支持基于内存和基于文件的缓冲区来避免内部节点的数据丢失。Fluentd还支持容错和设置高可用，使得本方法具有高可靠性。
见图4，修改Fluentd的配置项match，将match配置成＊＊。
1、match：标识一个目标标签，后面是一个匹配日志源的正则表达式，这里想要捕获所有的日志并将它们发送给Elasticsearch，所以需要配置成＊＊。
2、id：目标的一个唯一标识符。
3、type：支持的输出插件标识符，这里要输出到Elasticsearch，所以配置成elasticsearch，这是Fluentd的一个内置插件。
4、log_level：指定要捕获的日志级别，这里配置成info，表示任何该级别或者该级别以上(INFO、WARNING、ERROR)的日志都将被路由到Elsasticsearch。
5、host/port：定义Elasticsearch的地址，也可以配置认证信息，的Elasticsearch不需要认证，所以这里直接指定host和port即可。
6、logstash_format：Elasticsearch服务对日志数据构建反向索引进行搜索，将logstash_format设置为true，Fluentd将会以logstash格式来转发结构化的日志数据。
7、Buffer：Fluentd允许在目标不可用时进行缓存，比如，如果网络出现故障或者Elasticsearch不可用的时候。缓冲区配置也有助于降低磁盘的IO。
修改type，将type配置成Elasticsearch，并将Fluentd数据源地址指向为Elasticsearch。+要收集Kubernetes集群的日志，直接用DasemonSet控制器来部署Fluentd应用，这样，它就可以从Kubernetes节点上采集日志，确保在集群中的每个节点上始终运行一个Fluentd容器。直接使用Helm来进行一键安装，为了能够了解更多实现细节，我采用手动方法来进行安装。
基于kubernetes进行日志搜集，有良好的可扩展性，可移植性和可维护性，提高故障定位效率以及降低运行维护成本，同时能够提高kubernetes集群中故障定位效率，降低性能损耗、提升资源利用率，以及便于持续观察维护以及针对性优化产品。
通过ConfigMap对象来指定Fluentd配置文件，新建fluentd-configmap.yaml文件。将上面创建的fluentd-config这个ConfigMap对象通过volumes挂载到了Fluentd容器中，另外为了能够灵活控制哪些节点的日志可以被收集，这里还添加了一个nodSelector属性。另外由于的集群使用的是kubeadm搭建的，默认情况下master节点有污点，所以如果要想也收集master节点的日志，则需要添加上容忍。获取docker的容器目录需要更改成/data/docker/containers，这个地方非常重要，当然如果你没有更改docker根目录则使用默认的/var/lib/docker目录。
分别创建上面的ConfigMap对象和DaemonSet，创建完成后，查看对应的Pods列表，检查是否部署成功。
S3中，已经搜集到pod日志至数据存储Elasticsearch中。使用kibana作为Elasticsearch提供日志分析的web接口，使用它对日志进行高效的搜索、可视化、分析等各种操作。
为了后续使用Kibana，需要配置至少一个Index名字或者Pattern，它用于在分析时确定ES中的Index。这里我输入之前配置的Index名字applog，Kibana会自动加载该Index下doc的field，并自动选择合适的field用于图标中的时间字段。点击Create后，可以看到左侧增加了配置的Index名字，切换到Discover标签上就能看到ES中的数据，执行搜索后，点击右边的保存按钮，保存该查询为search_all_logs。接下来去Visualize页面，点击新建一个柱状图(Vertical Bar Chart)，然后选择刚刚保存的查询search_all_logs，之后，Kibana将生成柱状图。在左边设置图形的各项参数，点击Apply Changes按钮，右边的图形将被更新，同理，其他类型的图形都可以实时更新。点击右边的保存，保存此图，命名为search_all_logs_visual。接下来切换到Dashboard页面，单击新建按钮，选择刚刚保存的search_all_logs_visual图形，面板上将展示该图。如果有较多数据，可以根据业务需求和关注点在Dashboard页面添加多个图表：柱形图，折线图，地图，饼图等等。需要说明的是，可以设置更新频率，让图表自动更新，如果设置的时间间隔够短，几乎趋近于实时显示。
具体的，该基于kubernetes的日志搜集方法的工作原理：使用时，使用JSON统一日志结构：使用JSON后，下游的数据处理起来相当的容易，因为JSON结构在保留了灵活的模式的同时，可以被无障碍的使用；使用统一日志存储：使用统一日志存储后，所有集群分散日志将可以在统一web平台查看；Fluentd支持基于内存和基于文件的缓冲区来避免内部节点的数据丢失。Fluentd还支持容错和设置高可用，使得本方法具有高可靠性。本方法基于kubernetes进行日志搜集，有良好的可扩展性，可移植性和可维护性，提高故障定位效率以及降低运行维护成本，同时能够提高kubernetes集群中故障定位效率，降低性能损耗、提升资源利用率，以及便于持续观察维护以及针对性优化产品。
以上所述仅为本发明的优选实施例而已，并不用于限制本发明，对于本领域的技术人员来说，本发明可以有各种更改和变化。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (8)

1.一种基于kubernetes的日志搜集方法，其特征在于，包括以下具体步骤：
S1、交付Fluentd至k8s集群，并配置日志源；
S2、交付Elasticsearch至k8s集群；
S3、进行WEB展示。
2.如权利要求1所述的一种基于kubernetes的日志搜集方法，其特征在于，S2中，修改Fluentd的配置项match，将match配置成＊＊。
3.如权利要求1所述的一种基于kubernetes的日志搜集方法，其特征在于，S2中，修改type，将type配置成Elasticsearch，并将Fluentd数据源地址指向为Elasticsearch。
4.如权利要求1所述的一种基于kubernetes的日志搜集方法，其特征在于，S3中，已经搜集到pod日志至数据存储Elasticsearch中。
5.如权利要求4所述的一种基于kubernetes的日志搜集方法，其特征在于，S3中，使用kibana作为Elasticsearch提供日志分析的web接口，使用它对日志进行高效的搜索、可视化、分析等各种操作。
6.如权利要求1所述的一种基于kubernetes的日志搜集方法，其特征在于，S1中，k8s日志收集具体步骤包括：配置configmap，作为配置文件挂载到fluentd；创建自定义镜像，安装需要的插件；创建部署脚本deploy.sh；版本控管脚本version.sh。
7.如权利要求6所述的一种基于kubernetes的日志搜集方法，其特征在于，配置configmap的步骤具体包括：添加Kubernetesmetadata数据；只保留具有logging＝1标签的Pod日志；删除一些多余的属性；设置index前缀为k8s。
8.如权利要求1所述的一种基于kubernetes的日志搜集方法，其特征在于，S1中，使用自己搭建的es集群时，只需要在kubernetesgithubcluster/addons/fluentd-elasticsearch中下载create-logging-namespace.yaml、fluentd-es-configmap.yaml和fluentd-es-ds.yaml三个文件即可。
CN202210196112.3A 2022-03-01 2022-03-01 一种基于kubernetes的日志搜集方法 Pending CN115357459A (zh)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN202210196112.3A CN115357459A (zh) 2022-03-01 2022-03-01 一种基于kubernetes的日志搜集方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202210196112.3A CN115357459A (zh) 2022-03-01 2022-03-01 一种基于kubernetes的日志搜集方法

Publications (1)

Publication Number Publication Date
CN115357459A true CN115357459A (zh) 2022-11-18

Family

ID=84030101

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202210196112.3A Pending CN115357459A (zh) 2022-03-01 2022-03-01 一种基于kubernetes的日志搜集方法

Country Status (1)

Country Link
CN (1) CN115357459A (zh)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116340005A (zh) * 2023-05-26 2023-06-27 北京好心情互联网医院有限公司 容器集群的调度方法、装置、设备及存储介质

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN116340005A (zh) * 2023-05-26 2023-06-27 北京好心情互联网医院有限公司 容器集群的调度方法、装置、设备及存储介质
CN116340005B (zh) * 2023-05-26 2023-08-15 北京好心情互联网医院有限公司 容器集群的调度方法、装置、设备及存储介质

Similar Documents

Publication Publication Date Title
US11757720B2 (en) Distributed computing dependency management system
US7716319B2 (en) Computer system and method for managing log information
CN108881477B (zh) 一种基于分布式的文件采集监控的方法
CN105677251B (zh) 基于Redis集群的存储系统
CN112084098A (zh) 资源监控系统及工作方法
US11403269B2 (en) Versioning validation for data transfer between heterogeneous data stores
CN106021381A (zh) 一种云存储服务系统的数据访问/存储方法及装置
CN106156289A (zh) 一种读写对象存储系统中的数据的方法以及装置
CN101788917A (zh) 一种部署应用软件的方法和系统
CN102880658A (zh) 基于地震数据处理的分布式文件管理系统
US20130066869A1 (en) Computer system, method of managing a client computer, and storage medium
CN105045905B (zh) 一种基于全文检索的日志维护方法及系统
CN108845865A (zh) 一种监控服务部署方法、系统和存储介质
US20140237121A1 (en) Cluster-free techniques for enabling a directory protocol-based domain name system (dns) service for high availability
CN111371891B (zh) 业务处理方法、装置、设备及存储介质
CN103077034A (zh) 混合虚拟化平台java应用迁移方法与系统
CN115357459A (zh) 一种基于kubernetes的日志搜集方法
CN111898122A (zh) 容器内应用的日志采集方法、装置、介质及电子设备
CN113127526A (zh) 一种基于Kubernetes的分布式数据存储和检索系统
CN113032356B (zh) 一种客舱分布式文件存储系统及实现方法
CN113824801B (zh) 一种智能融合终端统一接入管理组件系统
CN110247801A (zh) 一种对集群宿主机的监控系统及方法
CN104717091A (zh) 服务器品质验证方法及其系统
CN114356718A (zh) 日志处理方法、介质、系统和计算设备
CN105426489A (zh) 基于内存计算的分布式可扩展数据搜索系统

Legal Events

Date Code Title Description
PB01 Publication
PB01 Publication
SE01 Entry into force of request for substantive examination
SE01 Entry into force of request for substantive examination