下载文档原格式
kubernetes常见⽇志采集问题和解决⽅案分析传统⽇志与kubernetes⽇志对⽐传统服务1. ⽬录固定2. 重启不会丢失3. 不⽤关注标准与错误⽇志输出容器服务1. 节点不固定2. 重启服务会漂移3. 需要关注标准与错误⽇志输出4. ⽇志⽂件重启会丢失5. ⽇志⽬录不固定常见⽇志采集⽅案：1.远程⽇志将容器中⽇志直接写⼊远程kafka、es等，再由logstash等处理。
劣势就是需要改造服务由写⼊本地的就要进⾏修改传输到远端存储。
2.sidecar模式，在每个pod中运⾏⼀个filebeat，logstash等pod共享⼀个valume，由采集⼯具将⽇志内容采集发送。
缺点每个pod都需要额外增加⼀个⽇志采集⼯具，对pod有侵⼊。
3.logagent模式，在node中运⾏⼀个filebeat，logstash等，通过将pod⽇志⽬录固定事先约定好，直接采集对应⽬录内容传输⾄远端。
优点节约资源，对pod⽆侵⼊。
缺点：⽂件后缀名尽量统⼀否则维护较为困难。
⽬录预先定义好⽆法判断来源于哪个pod，只能区分node。
实践：⽇志采集⼯具使⽤阿⾥开源logpilot（优点与docker主进程进⾏交互能够通过docker动态识别各个pod⽇志⽬录，底层采⽤filebeat）搭建es：---apiVersion: v1kind: Servicemetadata:name: elasticsearch-api namespace: kube-systemlabels:name: elasticsearchspec:selector:app: esports:- name: transportport: 9200protocol: TCP---apiVersion: v1kind: Servicemetadata:name: elasticsearch-discovery namespace: kube-systemlabels:name: elasticsearchspec:selector:app: esports:- name: transportport: 9300protocol: TCP---apiVersion: apps/v1beta1kind: StatefulSetmetadata:name: elasticsearchnamespace: kube-systemlabels:kubernetes.io/cluster-service: "true" spec:replicas: 3serviceName: "elasticsearch-service"selector:matchLabels:app: estemplate:metadata:labels:app: esspec:tolerations:- effect: NoSchedulekey: node-role.kubernetes.io/master serviceAccountName: dashboard-admin initContainers:- name: init-sysctlimage: busybox:1.27command:- sysctl- -w- vm.max_map_count=262144securityContext:privileged: truecontainers:image: /imooc/elasticsearch:5.5.1 ports:- containerPort: 9200protocol: TCP- containerPort: 9300protocol: TCPsecurityContext:capabilities:add:- IPC_LOCK- SYS_RESOURCEresources:limits:memory: 4000Mirequests:cpu: 100mmemory: 2000Mienv:- name: "http.host"value: "0.0.0.0"- name: "network.host"value: "_eth0_"- name: ""value: "docker-cluster"- name: "bootstrap.memory_lock"value: "false"- name: "discovery.zen.ping.unicast.hosts"value: "elasticsearch-discovery"- name: "discovery.zen.ping.unicast.hosts.resolve_timeout"value: "10s"- name: "discovery.zen.ping_timeout"value: "6s"- name: "discovery.zen.minimum_master_nodes"value: "2"- name: "discovery.zen.fd.ping_interval"value: "2s"- name: "discovery.zen.no_master_block"value: "write"- name: "gateway.expected_nodes"value: "2"- name: "gateway.expected_master_nodes"value: "1"- name: "transport.tcp.connect_timeout"value: "60s"- name: "ES_JAVA_OPTS"value: "-Xms2g -Xmx2g"livenessProbe:tcpSocket:port: transportinitialDelaySeconds: 20periodSeconds: 10volumeMounts:- name: es-datamountPath: /dataterminationGracePeriodSeconds: 30volumes:- name: es-datahostPath:path: /es-dataes.yaml搭建logpilot：---apiVersion: extensions/v1beta1kind: DaemonSetmetadata:name: log-pilotnamespace: kube-systemlabels:k8s-app: log-pilotkubernetes.io/cluster-service: "true"spec:template:metadata:labels:k8s-app: log-eskubernetes.io/cluster-service: "true"version: v1.22spec:tolerations:- key: node-role.kubernetes.io/mastereffect: NoScheduleserviceAccountName: dashboard-admincontainers:- name: log-pilotimage: /imooc/log-pilot:0.9-filebeat resources:limits:memory: 200Mirequests:cpu: 100mmemory: 200Mienv:- name: "FILEBEAT_OUTPUT"value: "elasticsearch"- name: "ELASTICSEARCH_HOST"value: "elasticsearch-api"- name: "ELASTICSEARCH_PORT"value: "9200"- name: "ELASTICSEARCH_USER"value: "elastic"- name: "ELASTICSEARCH_PASSWORD"value: "changeme"volumeMounts:- name: sockmountPath: /var/run/docker.sock- name: rootmountPath: /hostreadOnly: true- name: varlibmountPath: /var/lib/filebeatmountPath: /var/log/filebeatsecurityContext:capabilities:add:- SYS_ADMINterminationGracePeriodSeconds: 30volumes:- name: sockhostPath:path: /var/run/docker.sock- name: roothostPath:path: /- name: varlibhostPath:path: /var/lib/filebeattype: DirectoryOrCreate- name: varloghostPath:path: /var/log/filebeattype: DirectoryOrCreatelogpilot.yaml搭建kibana：---apiVersion: v1kind: Servicemetadata:name: kibananamespace: kube-systemlabels:component: kibanaspec:selector:component: kibanaports:- name: httpport: 80targetPort: http---#ingressapiVersion: extensions/v1beta1kind: Ingressmetadata:name: kibananamespace: kube-systemspec:rules:- host: http:paths:- path: /backend:serviceName: kibanaservicePort: 80---apiVersion: apps/v1beta1kind: Deploymentmetadata:name: kibananamespace: kube-systemlabels:component: kibanaspec:replicas: 1selector:matchLabels:component: kibanatemplate:metadata:labels:component: kibanaspec:containers:- name: kibanaimage: /imooc/kibana:5.5.1 env:- name: CLUSTER_NAMEvalue: docker-cluster- name: ELASTICSEARCH_URLvalue: http://elasticsearch-api:9200/resources:limits:cpu: 1000mrequests:cpu: 100mports:- containerPort: 5601name: httpkibana.yaml。
Kubernetes（K8s）集群监控与日志管理方法Kubernetes（简称为K8s）是一个用于自动部署、扩展和管理容器化应用的开源平台。
随着容器技术的快速发展，Kubernetes已成为云原生应用开发和部署的事实标准。
然而，随着应用规模的增长和复杂性的提高，有效的集群监控和日志管理变得至关重要。
本文将介绍Kubernetes集群监控与日志管理的方法和工具。
一、集群监控方法Kubernetes集群监控旨在实时监测集群的状态、资源使用情况和应用程序性能。
下面列举了几种常见的集群监控方法：1. PrometheusPrometheus是一种开源的监控系统，专注于监控和警报。
通过Prometheus Operator，可以在Kubernetes上部署和管理Prometheus。
它可以收集各种指标，并提供灵活的查询语言PromQL来查询和分析数据。
2. GrafanaGrafana是一个流行的开源数据可视化工具，可与Prometheus集成，用于创建仪表盘和图表。
通过Grafana，用户可以直观地查看集群的监控数据，并进行数据分析和报表生成。
3. Elastic StackElastic Stack是一套用于日志管理和分析的工具集合，包括Elasticsearch、Logstash和Kibana。
在Kubernetes集群中，可以使用Filebeat或Fluentd来收集容器日志，并将其发送到Elasticsearch进行存储和索引。
然后，可以使用Kibana来搜索、分析和可视化日志数据。
4. HeapsterHeapster是Kubernetes的一个插件，用于收集和聚合集群中的监控数据。
它可以采集容器和主机的CPU、内存、网络等指标，并将这些数据存储在InfluxDB或Grafana等组件中。
Heapster提供了丰富的API接口和可视化界面，方便用户查看和导出监控数据。
二、日志管理方法Kubernetes集群中容器产生的大量日志需要进行有效的管理和检索，以便故障排查、安全审计和性能优化。
filebeat采集日志原理一、概述Filebeat是一个轻量级的开源数据采集器，主要用于将日志和文件数据发送到Elasticsearch或Logstash进行分析和可视化。
在ELK （Elasticsearch、Logstash、Kibana）堆栈中，Filebeat通常被用作数据采集器，负责将系统日志或应用程序日志发送到Elasticsearch或Logstash进行处理。
二、工作原理Filebeat的工作原理可以分为以下几个步骤：1. 读取文件Filebeat会定期读取指定目录下的文件，并将新添加到文件中的行标记为“待发送”。
2. 解析数据Filebeat会对待发送的行进行解析，并将其转换为JSON格式。
这些JSON对象包含了文件名、时间戳和文本内容等信息。
3. 发送数据Filebeat会将解析后的JSON对象发送到指定的输出目标，如Elasticsearch或Logstash等。
4. 处理响应如果输出目标返回响应，则Filebeat会对响应进行处理。
如果出现错误，则Filebeat会记录错误信息并尝试重新发送数据。
三、配置选项在使用Filebeat之前，需要通过配置文件指定要监视的文件路径、输出目标等信息。
常用的配置选项包括：1. filebeat.inputs：指定要监视的文件路径。
2. output.elasticsearch：指定要发送数据到Elasticsearch的地址。
3. output.logstash：指定要发送数据到Logstash的地址。
4. logging.level：指定日志记录级别。
四、优点使用Filebeat采集日志有以下几个优点：1. 轻量级Filebeat是一个轻量级的数据采集器，占用资源少，对系统性能影响小。
2. 灵活性Filebeat可以监视任何文件，并将数据发送到多种输出目标，如Elasticsearch、Logstash等。
3. 实时性Filebeat可以实时监视文件，并将新添加到文件中的行立即发送到输出目标。
Filebeats采集⽇志到ES什么是 Filebeat?Filebeat 是⼀个属于 Beats 系列的⽇志托运者 - ⼀组安装在主机上的轻量级托运⼈，⽤于将不同类型的数据传送到 ELK 堆栈进⾏分析。
每个Beat 专门⽤于传送不同类型的信息 - 例如，Winlogbeat 发布 Windows 事件⽇志，Metricbeat 发布主机指标等等。
顾名思义，Filebeat 提供⽇志⽂件。
在基于 ELK 的⽇志记录管道中，Filebeat 扮演⽇志代理的⾓⾊ - 安装在⽣成⽇志⽂件的计算机上，跟踪它们，并将数据转发到Logstash 以进⾏更⾼级的处理，或者直接转发到 Elasticsearch 进⾏索引。
因此，Filebeat 不是 Logstash 的替代品，但在⼤多数情况下可以并且应该同时使⽤。
您可以在本⽂中阅读有关 Beats 和 Filebeat 开发背后的故事的更多信息。
Logstash 需要运⾏ JVM，这种依赖性与 Ruby 中的实现相结合成为⼤量内存消耗的根本原因，尤其是涉及多个管道和⾼级过滤时。
Beats 是基于 Lumberjack 协议⽤ Go 语⾔编写的，旨在实现内存占⽤少，处理⼤量数据，⽀持加密以及有效处理背压。
例如，Filebeat 记录在注册表中索引的最后⼀条成功⾏，因此，如果⽹络问题或传输中断，Filebeat将记住重新建⽴连接时中断的位置。
如果输出，Logstash 或Elasticsearch 存在摄取问题，Filebeat 将减慢⽂件读取速度。
在选⽤ Filebeat 或者是 Logstash 呢？简单的答案是 - ⾄少在记录⽂件时，您⼏乎总是需要使⽤ Filebeat 和 Logstash 的组合。
为什么？因为除⾮您只对时间戳和消息字段感兴趣，否则仍需要 Logstash ⽤于 ETL（转换）中的 “T”，并充当多个⽇志记录管道的聚合器。
Filebeat 是当今最好的⽇志⽂件发送器之⼀ - 它轻量级，⽀持 SSL 和 TLS 加密，⽀持背压，具有良好的内置恢复机制，并且⾮常可靠。
IP 地址节点名称安装的服务192.168.10.171K8s-master NFS ，K8S 的必要组件服务192.168.10.172node-1NFS ，K8S 的必要组件服务192.168.10.173node-2NFS-server ，K8S 的必要组件服务ELK+filebeat 收集K8S 平台⽇志如果把⽇志保存在容器内部或通过数据卷挂载在宿主机上还是保持在远程存储上，⽐如保存在容器内部，也就是说没有经过任何改动，⾃是在容器⾥原封不动的启动了，起来之后⽇志还是和原来⼀样保持在原来的⽬录⾥，但是这个容器是会经常的删除，销毁和创建是常态。
因此我们需要⼀种持久化的保存⽇志⽅式。
如果⽇志还是放在容器内部，会随着容器删除⽽被删除容器数量很多，按照传统的查看⽇志⽅式变得不太现实容器本⾝特性容器密集，采集⽬标多：容器⽇志输出到控制台，docker 本⾝提供了⼀种能⼒来采集⽇志了。
如果落地到本地⽂件⽬前还没有⼀种好的采集⽅式容器的弹性伸缩：新扩容的pod 属性信息(⽇志⽂件路径，⽇志源)可能会发送变化收集那些⽇志K8S 系统的组件⽇志和应⽤程序⽇志，组件⽇志就是打到宿主机的固定⽂件和传统的⽇志收集⼀样，应⽤程序⽇志⼜分为了标准输出和⽇志⽂件ELK ⽇志收集的三个⽅案⼤致分为采集阶段→数据存储→分析→展⽰Node 上部署⼀个⽇志收集程序 DaemonSet ⽅式部署⽇志收集程序，对本节点/var/log/pods/或/var/lib/docker/containers/两个⽬录下的⽇志进⾏收集Pod 中附加专⽤⽇志收集的容器 每个运⾏应⽤程序的Pod 中增加⼀个⽇志收集容器，使⽤emtyDir 共享⽇志⽬录让⽇志收集程序读取到应⽤程序直接推送⽇志 应⽤程序直接将⽇志推送到远程存储上，不经过docker 的管理和kubernetes 的管理集群规划(kubeadm 安装)部署NFS部署NFS 是为了实现动态供给存储部署NFS 服务器，前提需要关闭防⽕墙和selinux yum install -y nfs-utils #所有的节点都需要安装配置NFS 共享的⽬录，no_root_squash 是挂载后以匿名⽤户进⾏使⽤,通常变成nobody [root@node-2 ~]# echo "/ifs/kubernetes 192.168.10.0/24(rw,no_root_squash)" > /etc/exports #多⾏不能使⽤清空⽅法，需要使⽤ >>进⾏追加[root@node-2 ~]# mkdir -p /ifs/kubernetes #共享⽬录不存在的话需要创建启动NFS 并设置开机⾃启动[root@node-2 ~]# systemctl enable nfs && systemctl start nfs查看已经共享的⽬录 （没有启动NFS 服务的节点不能查询）[root@node-2 ~]# showmount -eExport list for node-2:/ifs/kubernetes 192.168.10.0/24[root@node-2 ~]#部署NFS 实现⾃动创建PV 插件yum install -y gitgit clone https:///kubernetes-incubator/external-storagecd external-storage/nfs-client/deploy/#顺序部署kubectl apply -f rbac.yaml # 授权访问apiserverkubectl apply -f deployment.yaml # 部署插件，需要修改⾥⾯NFS 服务器地址和共享⽬录kubectl apply -f class.yaml # 创建存储类型，是否启⽤归档kubectl get sc # 查看存储类型在K8S 中部署ELK部署elasticsearch[root@k8s-maste ~]# cat elasticsearch.yamlapiVersion: apps/v1kind: StatefulSetmetadata:name: elasticsearchnamespace: kube-systemlabels:k8s-app: elasticsearchspec:serviceName: elasticsearchselector:matchLabels:k8s-app: elasticsearchtemplate:metadata:- image: elasticsearch:7.5.0name: elasticsearchresources:limits:cpu: 1memory: 2Girequests:cpu: 0.5memory: 500Mienv:- name: "discovery.type"value: "single-node"- name: ES_JAVA_OPTSvalue: "-Xms512m -Xmx2g"ports:- containerPort: 9200name: dbprotocol: TCPvolumeMounts:- name: elasticsearch-datamountPath: /usr/share/elasticsearch/datavolumeClaimTemplates:- metadata:name: elasticsearch-dataspec:storageClassName: "managed-nfs-storage"accessModes: [ "ReadWriteOnce" ]resources:requests:storage: 20Gi---apiVersion: v1kind: Servicemetadata:name: elasticsearchnamespace: kube-systemspec:clusterIP: Noneports:- port: 9200protocol: TCPtargetPort: dbselector:k8s-app: elasticsearch⽣效清单⽂件[root@k8s-maste ~]# kubectl apply -f elasticsearch.yaml statefulset.apps/elasticsearch createdservice/elasticsearch created[root@k8s-maste ~]# kubectl get pods -n kube-system elasticsearch-0 NAME READY STATUS RESTARTS AGE elasticsearch-0 1/1 Running 0 50s[root@k8s-maste ~]#部署kibana[root@k8s-maste ~]# cat kibana.yamlapiVersion: apps/v1kind: Deploymentmetadata:name: kibananamespace: kube-systemlabels:k8s-app: kibanaspec:replicas: 1selector:matchLabels:k8s-app: kibanatemplate:metadata:labels:k8s-app: kibanaspec:containers:- name: kibanaimage: kibana:7.5.0resources:limits:cpu: 1memory: 500Mirequests:cpu: 0.5memory: 200Mienv:- name: ELASTICSEARCH_HOSTSvalue: http://elasticsearch-0.elasticsearch.kube-system:9200 - name: I18N_LOCALEvalue: zh-CNports:- containerPort: 5601name: uiprotocol: TCP---namespace: kube-systemspec:type: NodePortports:- port: 5601protocol: TCPtargetPort: uinodePort: 30601selector:k8s-app: kibana⽣效清单⽂件[root@k8s-maste ~]# kubectl apply -f kibana.yamldeployment.apps/kibana createdservice/kibana created[root@k8s-maste ~]# kubectl get pods -n kube-system |grep kibanaNAME READY STATUS RESTARTS AGEkibana-6cd7b9d48b-jrx79 1/1 Running 0 3m3s[root@k8s-maste ~]# kubectl get svc -n kube-system kibanaNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEkibana NodePort 10.98.15.252 <none> 5601:30601/TCP 105s[root@k8s-maste ~]#filebeat采集标准输出⽇志filebeat⽀持动态的获取容器的⽇志[root@k8s-maste ~]# cat filebeat-kubernetes.yamlapiVersion: v1kind: ConfigMapmetadata:name: filebeat-confignamespace: kube-systemlabels:k8s-app: filebeatdata:filebeat.yml: |-filebeat.config:inputs:# Mounted `filebeat-inputs` configmap:path: ${path.config}/inputs.d/*.yml# Reload inputs configs as they change:reload.enabled: falsemodules:path: ${path.config}/modules.d/*.yml# Reload module configs as they change:reload.enabled: false# To enable hints based autodiscover, remove `filebeat.config.inputs` configuration and uncomment this: #filebeat.autodiscover:# providers:# - type: kubernetes# hints.enabled: trueoutput.elasticsearch:hosts: ['${ELASTICSEARCH_HOST:elasticsearch}:${ELASTICSEARCH_PORT:9200}']---apiVersion: v1kind: ConfigMapmetadata:name: filebeat-inputsnamespace: kube-systemlabels:k8s-app: filebeatdata:kubernetes.yml: |-- type: dockercontainers.ids:- "*"processors:- add_kubernetes_metadata:in_cluster: true---apiVersion: apps/v1kind: DaemonSetmetadata:name: filebeatnamespace: kube-systemlabels:k8s-app: filebeatspec:selector:matchLabels:k8s-app: filebeattemplate:metadata:labels:k8s-app: filebeatspec:serviceAccountName: filebeatterminationGracePeriodSeconds: 30containers:- name: filebeatimage: elastic/filebeat:7.5.0- name: ELASTICSEARCH_HOSTvalue: elasticsearch-0.elasticsearch.kube-system- name: ELASTICSEARCH_PORTvalue: "9200"securityContext:runAsUser: 0# If using Red Hat OpenShift uncomment this:#privileged: trueresources:limits:memory: 200Mirequests:cpu: 100mmemory: 100MivolumeMounts:- name: configmountPath: /etc/filebeat.ymlreadOnly: truesubPath: filebeat.yml- name: inputsmountPath: /usr/share/filebeat/inputs.dreadOnly: true- name: datamountPath: /usr/share/filebeat/data- name: varlibdockercontainersmountPath: /var/lib/docker/containersreadOnly: truevolumes:- name: configconfigMap:defaultMode: 0600name: filebeat-config- name: varlibdockercontainershostPath:path: /var/lib/docker/containers- name: inputsconfigMap:defaultMode: 0600name: filebeat-inputs# data folder stores a registry of read status for all files, so we don't send everything again on a Filebeat pod restart- name: datahostPath:path: /var/lib/filebeat-datatype: DirectoryOrCreate---apiVersion: rbac.authorization.k8s.io/v1beta1kind: ClusterRoleBindingmetadata:name: filebeatsubjects:- kind: ServiceAccountname: filebeatnamespace: kube-systemroleRef:kind: ClusterRolename: filebeatapiGroup: rbac.authorization.k8s.io---apiVersion: rbac.authorization.k8s.io/v1beta1kind: ClusterRolemetadata:name: filebeatlabels:k8s-app: filebeatrules:- apiGroups: [""] # "" indicates the core API groupresources:- namespaces- podsverbs:- get- watch- list---apiVersion: v1kind: ServiceAccountmetadata:name: filebeatnamespace: kube-systemlabels:k8s-app: filebeat这⾥指定了es的路径output.elasticsearch:hosts: ['${ELASTICSEARCH_HOST:elasticsearch}:${ELASTICSEARCH_PORT:9200}']这⾥是⼀个处理器，他会⾃动的为⽇志添加k8s属性。
elkfilebeat 搭建日记系统Elasticsearch散布式搜寻和剖析引擎。
拥有高可伸缩、高靠谱和易管理等特色。
鉴于Apache Lucene 建立，能对大容量的数据进行接近及时的储存、搜寻和剖析操作。
Logstash日记采集器。
采集各样数据源，并对数据进行过滤、剖析、格式化等操作，而后储存到Elasticsearch。
Kibana数据剖析和可视化平台。
与 Elasticsearch 配合使用，对此中数据进行搜寻、剖析、图表展现。
Filebeat一个轻量级开源日记文件数据采集器， Filebeat 读取文件内容，发送到 Logstash 进行分析后进入 Elasticsearch，或直接发送到Elasticsearch 进行集中式储存和剖析。
架构介绍鉴于 ELK 的使用方式， Logstash 作为日记采集器，Elasticsearch 进行日记储存， Kibana 作为日记体现，大概以下几种架构。
架构一图中Logstash 多个的原由是考虑到程序是散布式架构的状况，每台机器都需要部署一个Logstash，假如的确是单服务器的状况部署一个Logstash 即可。
前面提到Logstash 会对数据进行剖析、过滤、格式化等操作，这一系列操作对服务器的CPU 和内存资源的耗费都是比较高的，因此这类架构会影响每台服务器的性能，因此并不介绍采纳。
架构二对比于架构一，增添了一个MQ和Logstash，Logstash 的输出和输入支持Kafka 、Redis、RabbitMQ等常见信息行列，MQ 前的Logstash 只作为日记采集和传输，其实不分析和过滤，先将日记加入行列，由MQ 后边的Logstash 持续分析和过滤，这样就不至于每台服务器耗费费源都好多。
架构三这类架构是鉴于架构二简化来的，实质在使用过程中也是能够采纳的，日记直接进入MQ ，Logstash 花费MQ数据即可。
架构四这类架构在日记数据源和Logstash（或 Elasticsearch）中增添了Beats 。
基于ELK的运维辅助系统的设计与实现作者：李书达刘遵仁朱琦来源：《青岛大学学报（工程技术版）》2022年第01期文章编号： 10069798（2022）01001806; DOI： 10.13306/j.10069798.2022.01.003摘要：针对分布式集群在服务出现异常情况下存在的无法快速定位到异常所在服务器，并获取报错详情的问题，本文采用技术栈（elasticsearch，ELK）捕获异常，并解析日志内容来展示详情，以实现快速定位，最终以邮件形式告知运维人员进行处理。
测试结果表明，部署在A公司多台服务器上的集群出现异常后，本系统最快可在2 s内监控到异常，5 s内完成对运维人员的邮件通知，邮件内容包括问题发生时详细信息，方便运维人员快速定位问题。
本系统大大缩短了运维人员处理故障时间，提升了运维效率，降低了公司损失，可以辅助运维人员实现对多服务器集群的监控，做到对异常集群的快速定位。
该研究对企业分布式集群节点的异常定位具有重要意义。
关键词： ELK; 辅助运维; 大数据; 日志中图分类号： TP311.13文献标识码： A随着互联网飞速发展，高速网络不但增加了用户体验，也增加了企业服务器负载压力，在此情况下，分布式集群成为企业服务器应对大数据高并发场景的主流解决方案[1]。
分布式集群保证机器宕机时仍有其余机器可对外提供访问，但如果代码层面出现异常，不能被及时发现并修正，也会造成严重损失，因此深入代码层面的监控对企业意义重大。
日志记录了各自服务器运行时的核心信息，这对定位问题具有重要作用，所以利用好服务器日志成为关键点。
近年来，为方便管理大型集群，一些团队设计了集群监控系统，但与日志相关的功能并不丰富。
Zabbix是一个常用的集群监控系统，其实现了多条报警及自带画图功能，当集群出现异常时，可以执行对应的紧急预案脚本自动修复[2];Prometheus是由SoundCloud开发的开源监控报警系统和时序列数据库，其通过超文本传输协议（hypertext transfer protocol，HTTP），周期性抓取被监控组件的状态，组件只需提供对应的HTTP接口就可接入监控，不需要任何软件开发工具包或者其他集成过程[3]。
es日志采集存储方法
以下是几种常用的日志采集存储方法：
1. 通过Filebeat采集：Filebeat是最常用的日志采集方法之一。
通过使用Filebeat，您可以使用Elastic提供的模块，或创建自己的input来收集日志。
2. Elasticsearch作为日志存储介质：由于Elasticsearch的查询便利性和与Kibana的可视化查询功能，许多项目选择使用Elasticsearch作为日志的存储介质。
3. 使用Logstash：Logstash可以用于对数据进行清洗，并通过Logstash 对数据和外部数据库进行丰富等操作。
它还提供了一个缓冲的作用，特别是针对大量生成日志的情况。
4. 使用Kafka：针对大量数据，Kafka是一个常用的解决方法。
它可以起到缓冲的作用。
5. 使用ElasticsearchAppender：通过集成ElasticsearchAppender插件的方式采集日志，具体操作包括在中引入依赖，并在中新增appender。
请注意，每种方法都有其适用的场景和优势，根据实际需求选择最适合的方法是关键。
k8s使⽤filebeat收集所有容器标准输出的⽇志k8s-filebeat收集所有容器标准输出的⽇志1. k8s-收集所有容器标准输出的⽇志filebeat-kubernetes.yaml # 采集所有容器标准输出app-log-stdout.yaml # 标准输出测试应⽤app-log-logfile.yaml # ⽇志⽂件测试应⽤1.1 filebeat-kubernetes 配置⽂件filebeat-kubernetes采集⽰意图针对标准输出：以DaemonSet⽅式在每个Node上部署⼀个⽇志收集程序，采集/var/lib/docker/containers/⽬录下所有容器⽇志⽰例filebeat-kubernetes.yaml配置⽂件---apiVersion: v1kind: ConfigMapmetadata:name: filebeat-confignamespace: opslabels:k8s-app: filebeatdata:filebeat.yml: |-filebeat.config:inputs:# Mounted `filebeat-inputs` configmap:path: ${path.config}/inputs.d/*.yml# Reload inputs configs as they change:reload.enabled: falsemodules:path: ${path.config}/modules.d/*.yml# Reload module configs as they change:reload.enabled: falseoutput.elasticsearch:hosts: ['49.65.125.91:9200']---apiVersion: v1kind: ConfigMapmetadata:name: filebeat-inputsnamespace: opslabels:k8s-app: filebeatdata:kubernetes.yml: |-- type: dockercontainers.ids:- "*"processors:- add_kubernetes_metadata:in_cluster: true---apiVersion: apps/v1kind: DaemonSetmetadata:name: filebeatnamespace: opslabels:k8s-app: filebeatspec:selector:matchLabels:k8s-app: filebeattemplate:metadata:labels:k8s-app: filebeatspec:serviceAccountName: filebeatterminationGracePeriodSeconds: 30containers:- name: filebeatimage: elastic/filebeat:7.9.2args: ["-c", "/etc/filebeat.yml","-e",]securityContext:runAsUser: 0# If using Red Hat OpenShift uncomment this:#privileged: trueresources:limits:memory: 200Mirequests:cpu: 100mmemory: 100MivolumeMounts:- name: configmountPath: /etc/filebeat.ymlreadOnly: truesubPath: filebeat.yml- name: inputsmountPath: /usr/share/filebeat/inputs.dreadOnly: true- name: datamountPath: /usr/share/filebeat/data- name: varlibdockercontainersmountPath: /var/lib/docker/containersreadOnly: truevolumes:- name: configconfigMap:defaultMode: 0600name: filebeat-config- name: varlibdockercontainershostPath:path: /var/lib/docker/containers- name: inputsconfigMap:defaultMode: 0600name: filebeat-inputs# data folder stores a registry of read status for all files, so we don't send everything again on a Filebeat pod restart - name: datahostPath:path: /var/lib/filebeat-datatype: DirectoryOrCreate---apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata:name: filebeatsubjects:- kind: ServiceAccountname: filebeatnamespace: opsroleRef:kind: ClusterRolename: filebeatapiGroup: rbac.authorization.k8s.io---apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata:name: filebeatlabels:k8s-app: filebeatrules:- apiGroups: [""] # "" indicates the core API groupresources:- namespaces- podsverbs:- get- watch- list---apiVersion: v1kind: ServiceAccountmetadata:name: filebeatnamespace: opslabels:k8s-app: filebeat可视化展⽰⽇志：1.查看索引（⽇志记录集合）：Management -> Stack Management -> 索引管理2.将索引关联到Kibana：索引模式-> 创建-> 匹配模式-> 选择时间戳3.在Discover选择索引模式查看⽇志图⽰1.2 ⽇志⽂件输出⽇志⽂件输出架构图解针对容器中⽇志⽂件：在Pod中增加⼀个容器运⾏⽇志采集器，使⽤emtyDir共享⽇志⽬录让⽇志采集器读取到⽇志⽂件2. 操作案例编写filebeat-kubernetes.yaml配置⽂件[root@k8s-master elk]# vim filebeat-kubernetes.yaml[root@k8s-master elk]# cat filebeat-kubernetes.yaml---apiVersion: v1kind: ConfigMapmetadata:name: filebeat-confignamespace: opslabels:k8s-app: filebeatdata:filebeat.yml: |-filebeat.config:inputs:# Mounted `filebeat-inputs` configmap:path: ${path.config}/inputs.d/*.yml# Reload inputs configs as they change:reload.enabled: falsemodules:path: ${path.config}/modules.d/*.yml# Reload module configs as they change:reload.enabled: falseoutput.elasticsearch:hosts: ['127.0.0.1:9200']username: "admin"password: "12345678"---apiVersion: v1kind: ConfigMapmetadata:name: filebeat-inputsnamespace: opslabels:k8s-app: filebeatdata:kubernetes.yml: |-- type: dockercontainers.ids:- "*"processors:- add_kubernetes_metadata:in_cluster: true---apiVersion: apps/v1kind: DaemonSetmetadata:name: filebeatnamespace: opslabels:k8s-app: filebeatspec:selector:matchLabels:k8s-app: filebeattemplate:metadata:labels:k8s-app: filebeatspec:serviceAccountName: filebeatterminationGracePeriodSeconds: 30containers:- name: filebeatimage: elastic/filebeat:7.10.1args: ["-c", "/etc/filebeat.yml","-e",]securityContext:runAsUser: 0# If using Red Hat OpenShift uncomment this:#privileged: trueresources:limits:memory: 200Mirequests:cpu: 100mmemory: 100MivolumeMounts:- name: configmountPath: /etc/filebeat.ymlreadOnly: truesubPath: filebeat.yml- name: inputsmountPath: /usr/share/filebeat/inputs.dreadOnly: true- name: datamountPath: /usr/share/filebeat/data- name: varlibdockercontainersmountPath: /var/lib/docker/containersreadOnly: truevolumes:- name: configconfigMap:defaultMode: 0600name: filebeat-config- name: varlibdockercontainershostPath:path: /var/lib/docker/containers- name: inputsconfigMap:defaultMode: 0600name: filebeat-inputs# data folder stores a registry of read status for all files, so we don't send everything again on a Filebeat pod restart - name: datahostPath:path: /var/lib/filebeat-datatype: DirectoryOrCreate---apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRoleBindingmetadata:name: filebeatsubjects:- kind: ServiceAccountname: filebeatnamespace: opsroleRef:kind: ClusterRolename: filebeatapiGroup: rbac.authorization.k8s.io---apiVersion: rbac.authorization.k8s.io/v1kind: ClusterRolemetadata:name: filebeatlabels:k8s-app: filebeatrules:- apiGroups: [""] # "" indicates the core API groupresources:- namespaces- podsverbs:- get- watch- list---apiVersion: v1kind: ServiceAccountmetadata:name: filebeatnamespace: opslabels:k8s-app: filebeat运⾏配置[root@k8s-master elk]# kubectl create namespace opsnamespace/ops created[root@k8s-master elk]# kubectl apply -f filebeat-kubernetes.yamlconfigmap/filebeat-config createdconfigmap/filebeat-inputs createddaemonset.apps/filebeat createdclusterrolebinding.rbac.authorization.k8s.io/filebeat unchanged clusterrole.rbac.authorization.k8s.io/filebeat unchangedserviceaccount/filebeat created查看运⾏配置[root@k8s-master elk]# kubectl get pods -n opsNAME READY STATUS RESTARTS AGEfilebeat-dmbzg 1/1 Running 0 24m[root@k8s-master elk]# kubectl logs -f filebeat-dmbzg -n ops查看kibana是否有索引3. 可视化展⽰数据可视化展⽰数据创建索引查看索引数据4. 验证⽇志输出创建nginx服务[root@k8s-master elk]# kubectl run nginx --image=nginx请求nginx，得到⽇志数据[root@k8s-master elk]# kubectl get podsNAME READY STATUS RESTARTS AGEnginx 1/1 Running 0 33htomcat 1/1 Running 0 33hweb-5df8b97c79-hksfc 1/1 Running 0 3d3h[root@k8s-master elk]# kubectl get pods -o wideNAME READY STATUS RESTARTS AGE IP NODE NOMINATED NODE READINESS GATES nginx 1/1 Running 0 33h 10.244.85.196 k8s-node01 <none> <none>tomcat 1/1 Running 0 33h 10.244.85.197 k8s-node01 <none> <none>web-5df8b97c79-hksfc 1/1 Running 0 3d3h 10.244.85.195 k8s-node01 <none> <none>[root@k8s-master elk]# curl -I 10.244.85.196HTTP/1.1 200 OKServer: nginx/1.21.1Date: Thu, 08 Jul 2021 14:13:02 GMTContent-Type: text/htmlContent-Length: 612Last-Modified: Tue, 06 Jul 2021 14:59:17 GMTConnection: keep-aliveETag: "60e46fc5-264"Accept-Ranges: bytes[root@k8s-master elk]# curl -I 10.244.85.196HTTP/1.1 200 OKServer: nginx/1.21.1Date: Thu, 08 Jul 2021 14:13:04 GMTContent-Type: text/htmlContent-Length: 612Last-Modified: Tue, 06 Jul 2021 14:59:17 GMTConnection: keep-aliveETag: "60e46fc5-264"Accept-Ranges: bytes查看输出⽇志[root@k8s-master elk]# kubectl logs nginx10.244.235.192 - - [07/Jul/2021:05:15:13 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.29.0" "-"10.244.235.192 - - [07/Jul/2021:05:15:18 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.29.0" "-"10.244.235.192 - - [08/Jul/2021:14:08:55 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.29.0" "-"10.244.235.192 - - [08/Jul/2021:14:08:57 +0000] "GET / HTTP/1.1" 200 612 "-" "curl/7.29.0" "-"10.244.235.192 - - [08/Jul/2021:14:13:02 +0000] "HEAD / HTTP/1.1" 200 0 "-" "curl/7.29.0" "-"10.244.235.192 - - [08/Jul/2021:14:13:04 +0000] "HEAD / HTTP/1.1" 200 0 "-" "curl/7.29.0" "-" kibana验证nginx数据是否被收集。
EFK（Elasticsearch+Filebeat+Kibana）收集K8s容器⽇志⼀、Kubernetes⽇志采集难点 在 Kubernetes 中，⽇志采集相⽐传统虚拟机、物理机⽅式要复杂很多，最根本的原因是 Kubernetes 把底层异常屏蔽，提供更加细粒度的资源调度，向上提供稳定、动态的环境。
因此⽇志采集⾯对的是更加丰富、动态的环境，需要考虑的点也更加的多。
1. 对于运⾏时间很短的 Job 类应⽤，从启动到停⽌只有⼏秒的时间，如何保证⽇志采集的实时性能够跟上⽽且数据不丢？2. K8s ⼀般推荐使⽤⼤规格节点，每个节点可以运⾏ 10-100+ 的容器，如何在资源消耗尽可能低的情况下采集 100+ 的容器？3. 在 K8s 中，应⽤都以 yaml 的⽅式部署，⽽⽇志采集还是以⼿⼯的配置⽂件形式为主，如何能够让⽇志采集以 K8s 的⽅式进⾏部署？⼆、Kubernetes⽇志采集⽅式1. 业务直写：在应⽤中集成⽇志采集的 SDK，通过 SDK 直接将⽇志发送到服务端。
这种⽅式省去了落盘采集的逻辑，也不需要额外部署 Agent，对于系统的资源消耗最低，但由于业务和⽇志 SDK 强绑定，整体灵活性很低，⼀般只有⽇志量极⼤的场景中使⽤；2. DaemonSet ⽅式：在每个 node 节点上只运⾏⼀个⽇志 agent，采集这个节点上所有的⽇志。
DaemonSet 相对资源占⽤要⼩很多，但扩展性、租户隔离性受限，⽐较适⽤于功能单⼀或业务不是很多的集群；3. Sidecar ⽅式：为每个 POD 单独部署⽇志 agent，这个 agent 只负责⼀个业务应⽤的⽇志采集。
Sidecar 相对资源占⽤较多，但灵活性以及多租户隔离性较强，建议⼤型的 K8s 集群或作为 PaaS 平台为多个业务⽅服务的集群使⽤该⽅式。
总结：1. 业务直写推荐在⽇志量极⼤的场景中使⽤2. DaemonSet⼀般在中⼩型集群中使⽤3. Sidecar推荐在超⼤型的集群中使⽤ 实际应⽤场景中，⼀般都是使⽤ DaemonSet 或 DaemonSet 与 Sidecar 混⽤⽅式，DaemonSet 的优势是资源利⽤率⾼，但有⼀个问题是 DaemonSet 的所有 Logtail 都共享全局配置，⽽单⼀的 Logtail 有配置⽀撑的上限，因此⽆法⽀撑应⽤数⽐较多的集群。
文章标题：深入解析filebeat sidecar原理及应用1. 引言在今天的信息时代，数据无处不在。
为了更好地管理、分析和利用数据，日志收集和管理成为了一个至关重要的环节。
其中，filebeat sidecar作为一种高效的日志数据收集工具，在实际应用中发挥着重要作用。
本文将深入探讨filebeat sidecar的原理及其应用。
2. filebeat sidecar的基本概念filebeat sidecar是filebeat的一个重要衍生产品，它通过与Docker容器或Kubernetes Pod集成，实现对容器内部日志数据的收集和传输。
它采用轻量级的方式，实现了对容器内部日志的快速收集和传输，为企业提供了高效的日志管理方案。
3. filebeat sidecar的工作原理filebeat sidecar通过与Docker或Kubernetes的集成，实现了自动发现、收集和传输容器内部的日志数据。
它通过监控指定目录或文件，将变化的日志数据实时发送给指定的Logstash或Elasticsearch服务器，实现了日志数据的实时传输和分析。
4. filebeat sidecar的应用场景filebeat sidecar在实际应用中有着广泛的应用场景，特别适用于大规模的容器化环境或Kubernetes集群中。
它可以作为日志数据的搜集者和传输者，为企业提供高效的日志管理解决方案。
5. 个人观点和总结从以上内容可以看出，filebeat sidecar作为一种高效的日志数据收集工具，在实际应用中发挥着重要的作用。
它的原理简单清晰，应用场景广泛，为企业提供了高效的日志管理解决方案。
在未来的信息时代，随着容器化和集群化的发展，filebeat sidecar将会有着更广阔的应用前景和发展空间。
6. 结语通过本文对filebeat sidecar的深入解析，相信读者对其原理和应用都有了更加全面、深刻的理解。
基于流量特征的问题分析平台设计与实现摘要：研发人员遇到系统业务问题时，使用传统的日志框架越来越难以定位和追踪。
本文首先对日志系统的研究背景进行分析，然后分析了系统的具体需求，并对系统功能模块进行了划分和设计。
基于流量特征实现了系统问题实时精确分析平台，操作简单、结果直观，给研发人员提供一种全新的排查问题的方法。
关键词：日志系统；动态配置；精确分析1研究背景日志可以用于用户的行为信息分析，发现潜在商机；日志可以帮助开发人员找到bug的来源，修复漏洞。
伴随着近些年来互联网上用户量的飞速增长，互联网上提供服务的服务器数量也与日俱增，随之产生了越来越多的日志数据。
日志系统用于收集程序运行过程中的各种行为和状态信息，是分析系统业务问题的核心工具。
ELK是由Elasticsearch、Logstash、Kibana组成的开源日志处理平台解决方案。
在面对大流量、长链路的应用时，ELK仍然有很多不方便的地方：浪费系统性能，无法实时开启、关闭日志收集；无法将一次请求链路的日志完整的串联起来，存在无关请求干扰；日志没有结构，可视化不够清晰。
2系统需求分析本系统面向的用户主要是开发人员和测试人员。
从开发人员的角度分析，对系统的主要需求包括根据资源id和用户id进行流量识别动态决定是否开启日志收集、日志分级打印、兼容主流的日志框架、信息预处理、日志持久化等；而测试人员的基本需求则是对规则配置进行统一的维护、日志可视化、用户认证授权等。
根据上述基本需求分析，本系统在设计与实现上应该具备如下基本的功能操作：基于资源id和用户id进行流量识别动态决定是否收集日志；日志分级打印；兼容主流的日志框架；对日志参数和日志整体进行预处理；将日志详情和日志基本信息持久化；对规则配置进行统一的维护；日志基本信息和日志详情的可视化；对不同用户的权限进行管理。
3系统总体设计3.1系统特征本平台的根本目的是提供一个便捷的工具，帮助研发人员迅速定位系统问题所在，使原本黑盒状态的应用逻辑处理与数据变化变得清晰明朗。
Kubernetes容器⽇志收集⽇志采集⽅式⽇志从传统⽅式演进到容器⽅式的过程就不详细讲了，可以参考⼀下这篇⽂章，由于容器的漂移、⾃动伸缩等特性，⽇志收集也就必须使⽤新的⽅式来实现，Kubernetes官⽅给出的⽅式基本是这三种：原⽣⽅式、DaemonSet⽅式和Sidecar⽅式。
1.原⽣⽅式：使⽤ kubectl logs 直接在查看本地保留的⽇志，或者通过docker engine的 log driver 把⽇志重定向到⽂件、syslog、fluentd等系统中。
2.DaemonSet⽅式：在K8S的每个node上部署⽇志agent，由agent采集所有容器的⽇志到服务端。
3.Sidecar⽅式：⼀个POD中运⾏⼀个sidecar的⽇志agent容器，⽤于采集该POD主容器产⽣的⽇志。
三种⽅式都有利有弊，没有哪种⽅式能够完美的解决100%问题的，所以要根据场景来贴合。
⼀、原⽣⽅式简单的说，原⽣⽅式就是直接使⽤kubectl logs来查看⽇志，或者将docker的⽇志通过⽇志驱动来打到syslog、journal等去，然后再通过命令来排查，这种⽅式最好的优势就是简单、资源占⽤率低等，但是，在多容器、弹性伸缩情况下，⽇志的排查会⼗分困难，仅仅适⽤于刚开始研究Kubernetes的公司吧。
不过，原⽣⽅式确实其他两种⽅式的基础，因为它的两种最基础的理念，daemonset和sidecar模式都是基于这两种⽅式⽽来的。
1.1 控制台stdout⽅式这种⽅式是daemonset⽅式的基础。
将⽇志全部输出到控制台，然后docker开启journal，然后就能在/var/log/journal下⾯看到⼆进制的journal⽇志，如果要查看⼆进制的⽇志的话，可以使⽤journalctl来查看⽇志：journalctl -u docker.service -n 1 --no-pager -o json -o json-pretty在上⾯的json中，_CMDLINE以及其他字段占⽤量⽐较⼤，⽽且这些没有什么意义，会导致⼀条简短的⽇志却被封装成多了⼏⼗倍的量，所以的在⽇志量特别⼤的情况下，最好进⾏⼀下字段的定制，能够减少就减少。
Filebeat是一个轻量级的日志收集工具，它可以从文件、系统、网络和其他来源收集日志，并将它们发送到Elasticsearch、Logstash或Kafka等日志集中存储和分析系统。
要使用Filebeat收集Kubernetes Pod的日志，您可以使用Filebeat的Docker log input插件。
以下是一些步骤：1. 安装Filebeat：您可以从Filebeat官方网站下载适用于您的操作系统的安装程序，并按照说明进行安装。
2. 安装Docker log input插件：Filebeat Docker log input插件允许您从Docker容器中收集日志。
您可以从Filebeat插件存储库下载插件并安装。
3. 配置Filebeat：您需要编辑Filebeat配置文件（通常是`filebeat.yml`），以便指定要收集的日志来源和输出目标。
以下是一个示例配置文件，用于从Kubernetes Pod中收集日志并将其发送到Elasticsearch：```yamlfilebeat.inputs:- type: containerpaths:- '/var/lib/docker/containers/*/*.log'output.elasticsearch:hosts: ['<elasticsearch_host>:<port>']```在上面的配置中，`/var/lib/docker/containers/*/*.log`是Docker容器的日志文件路径。
您可以根据您的系统配置进行更改。
`output.elasticsearch`部分指定了要将日志发送到的Elasticsearch主机和端口。
4. 启动Filebeat：保存配置文件并启动Filebeat。
您可以使用以下命令启动Filebeat：```shellsudo systemctl start filebeat```5. 检查日志是否被收集：在容器中执行一些操作并查看Filebeat 是否正在收集日志。
使⽤FileBeat⼯具抓取⽇志信息推送到ElasticSearch1.查看ElasticSearch的版本号：2.根据对应的ElasticSearch的版本7.3.0下载对应的FileBeat版本7.3.0我下载的是Window版本：filebeat-7.3.0-windows-x86_64.zip3.解压filebeat-7.3.0-windows-x86_64.zip⽂件夹-打开filebeat.yml进⾏配置3.1：配置采集⽇志的paths:路径。
3.2：配置 enabled: true 这个配置很重要，只有配置为true之后配置才可⽣效，否则不起作⽤。
3.3：配置Outputs ，这⾥的Outputs有elasticsearch，logstash。
按照配置⽂件下⾯的⽰例配置即可。
只能配置⼀个输出。
默认是ElasticSearch4.Cmd运⾏在当前⽬录下，新建⼀个bat⽂件，名字为: run.bat内容:.\filebeat -e -c filebeat.yml4.1单击bat，启动filebeat4.2正常情况下，应该有个链接ES的过程，将数据输出到es。
如果连接ElasticSearch出现重试异常：需要查看Filebeat的版本跟ElasticSearch版本是否⼀致(最好⼀致，要不然会存在连接不上的情况)。
4.3 打开ES能看到多了⼀个filebeat-7.3.0-年⽉⽇的索引。
若没有这个，⽽是⼀直Non-zero metrics inthe last 30s。
这个时间参数是个扫描⽂件的频率，可以修改。
那就要看下配置的路径对不对。
命令⾏中会有读取的⽂件的路径信息，仔细检查⼀下。
5.结果在ES上⾯看到对应的采集信息就成功。
k8s部署filebeatsidecar模式2020-06-12⼩试⽜⼑：先在⾃⼰本地wmware上尝试k8s中⽇志的收集⽅式。
⼀般有两种⽅式：⼀：sidecar模式，就是⼀个pod中部署两个容器，⼀个跑应⽤，⼀个采集⽇志，⽤emptdir的共享⽬录形式。
缺点：⼀个应⽤⼀个收集⽇志的容器，后期的话资源消耗是个问题。
⼆：节点模式，⼀个节点跑⼀个agent来采集标准输出和标准错误输出的⽇志，然后发送给后端。
（标准⽇志：容器内输出到/dev/std...，或tail -f ，默认会存储在节点的/var/lib/docker/containers/...路径下，kubectl logs 能看到的⽇志就是标准⽇志。
集群系统的⽇志⼀般在/var/log/containers/下。
）详情⽹上查阅资料，这个只是简单的⼀个说法，并不严谨。
先尝试第⼀个模式： sidecar模式⼀：创建filebeat的dockerfile，这⾥我⽤了centos，做好后镜像⼤约300+M，先尝试看看问题，后期换个基础镜像。
FROM centos:latestWORKDIR /usr/localADD filebeat-7.5.0-linux-x86_64.tar.gz .RUN ln -s filebeat-7.5.0-linux-x86_64 filebeat \&& cd filebeat \&& mkdir config \&& chmod +x filebeat \&& cp filebeat.yml config/ENTRYPOINT ["/usr/local/filebeat/filebeat","-c","/usr/local/filebeat/config/filebeat.yml"]直接构建镜像，并推送到私有仓库docker build -t 10.0.0.200:5000/centos-fb:v4 .docker push 10.0.0.200:5000/centos-fb:v4可以docker run运⾏看⼀下是否正常⼆：创建⼀个deploymen资源，包含两个容器[root@k8s-master ~/software]# cat nginx-filebeat-sidecar.yamlapiVersion: apps/v1kind: Deploymentmetadata:name: nginx-fbnamespace: sidecarspec:replicas: 1selector:matchLabels:app: nginx-fbtemplate:metadata:namespace: sidecarlabels:app: nginx-fbspec:containers:- image: nginx:alpinename: nginxports:- containerPort: 80volumeMounts:- name: applogmountPath: /var/log/nginx- image: 10.0.0.210:5000/centos-fb:v4name: filebeatvolumeMounts:- name: applogmountPath: /log- name: filebeat-configmountPath: /usr/local/filebeat/config/volumes:- name: applogemptyDir: {}- name: filebeat-configconfigMap:name: filebeat-config三：创建好yaml总的namespace和configmapnamespace，metadata⾥只填写name就可以[root@k8s-master ~/software]# kubectl get namespaces sidecar -o yamlapiVersion: v1kind: Namespacemetadata:creationTimestamp: "2020-06-10T09:38:02Z"name: sidecarresourceVersion: "669711"selfLink: /api/v1/namespaces/sidecaruid: 5b4d0ecc-ff6a-4b62-a41f-a9924efa4e0aspec:finalizers:- kubernetesstatus:phase: Activeconfigmap：以命令⾏的⽅式创建的，看⼀下filebeat的配置⽂件，配置⽂件有些问题，并不标准，下期更新⼀下kubectl create configmap filebeat-config --from-file=filebeat.yml --namespace=sidecar #configmap名字要和上⾯deployment资源中引⽤的configmap名字相同，均标了红⾊。
Kubernetes⽇志采集-EFKKubernetes⽇志采集-EFK1. ⽇志采集⽅案image.pngimage.png因为⽅案⼀在业界使⽤更为⼴泛，并且官⽅也更为推荐，所以我们基于⽅案⼀来做k8s的⽇志采集。
2. 架构选型ELKFilebeat（收集）、Logstash（过滤）、Kafka（缓冲）、Elasticsearch（存储）、Kibana（展⽰）image.pngEFKFluentbit （收集）、Fluentd（过滤）、Elasticsearch（存储）、Kibana（展⽰）image.jpg本⽂使⽤Fluentd--->Elasticsearch -->Kibana3. 部署Elasticsearch 集群使⽤3个 Elasticsearch Pod 来避免⾼可⽤下多节点集群中出现的“脑裂”问题创建⼀个名为 logging 的 namespace$ kubectl create namespace logging创建建⼀个名为 elasticsearch 的⽆头服务elasticsearch-svc.yamlkind: ServiceapiVersion: v1metadata:name: elasticsearchnamespace: logginglabels:app: elasticsearchspec:selector:app: elasticsearchclusterIP: Noneports:- port: 9200name: rest- port: 9300name: inter-node创建服务资源对象$ kubectl create -f elasticsearch-svc.yaml$ kubectl get svc -n loggingNAME TYPE CLUSTER-IP EXTERNAL-IP PORT(S) AGEelasticsearch ClusterIP None <none> 9200/TCP,9300/TCP 13d创建ES持久化存储创建创建elasticsearch-storageclass.yamlapiVersion: storage.k8s.io/v1kind: StorageClassmetadata:name: es-data-dbprovisioner: fuseim.pri/ifs创建服务资源对象$ kubectl create -f elasticsearch-storageclass.yaml$ kubectl get storageclassNAME PROVISIONER AGEes-data-db fuseim.pri/ifs 13d使⽤StatefulSet 创建Es PodKubernetes StatefulSet 允许我们为 Pod 分配⼀个稳定的标识和持久化存储，Elasticsearch 需要稳定的存储来保证 Pod 在重新调度或者重启后的数据依然不变，所以需要使⽤StatefulSet 来管理 Pod。
