Kubernetes中部署ELK Stack日志收集平台

编程入门 行业动态 更新时间:2024-10-28 18:32:48

Kubernetes中部署ELK Stack日志收集<a href=https://www.elefans.com/category/jswz/34/1769748.html style=平台"/>

Kubernetes中部署ELK Stack日志收集平台

微信公众号:运维开发故事,作者:double冬

主要内容

  • 1 ELK概念

  • 2 K8S需要收集哪些日志

  • 3 ELK Stack日志方案

  • 4 容器中的日志怎么收集

  • 5 部署操作步骤

准备环境

一套正常运行的k8s集群,kubeadm安装部署或者二进制部署即可

1 ELK概念

ELK是Elasticsearch、Logstash、Kibana三大开源框架首字母大写简称。市面上也被称为Elastic Stack。其中Elasticsearch是一个基于Lucene、分布式、通过Restful方式进行交互的近实时搜索平台框架。像类似百度、谷歌这种大数据全文搜索引擎的场景都可以使用Elasticsearch作为底层支持框架,可见Elasticsearch提供的搜索能力确实强大,市面上很多时候我们简称Elasticsearch为es。Logstash是ELK的中央数据流引擎,用于从不同目标(文件/数据存储/MQ)收集的不同格式数据,经过过滤后支持输出到不同目的地(文件/MQ/redis/elasticsearch/kafka等)。Kibana可以将elasticsearch的数据通过友好的页面展示出来,提供实时分析的功能。

通过上面对ELK简单的介绍,我们知道了ELK字面意义包含的每个开源框架的功能。市面上很多开发只要提到ELK能够一致说出它是一个日志分析架构技术栈总称,但实际上ELK不仅仅适用于日志分析,它还可以支持其它任何数据分析和收集的场景,日志分析和收集只是更具有代表性。并非唯一性。我们本教程主要也是围绕通过ELK如何搭建一个生产级的日志分析平台来讲解ELK的使用。

官方网站:/

image

2 日志管理平台

在过往的单体应用时代,我们所有组件都部署到一台服务器中,那时日志管理平台的需求可能并没有那么强烈,我们只需要登录到一台服务器通过shell命令就可以很方便的查看系统日志,并快速定位问题。随着互联网的发展,互联网已经全面渗入到生活的各个领域,使用互联网的用户量也越来越多,单体应用已不能够支持庞大的用户的并发量,尤其像中国这种人口大国。那么将单体应用进行拆分,通过水平扩展来支持庞大用户的使用迫在眉睫,微服务概念就是在类似这样的阶段诞生,在微服务盛行的互联网技术时代,单个应用被拆分为多个应用,每个应用集群部署进行负载均衡,那么如果某项业务发生系统错误,开发或运维人员还是以过往单体应用方式登录一台一台登录服务器查看日志来定位问题,这种解决线上问题的效率可想而知。日志管理平台的建设就显得极其重要。通过Logstash去收集每台服务器日志文件,然后按定义的正则模板过滤后传输到Kafka或redis,然后由另一个Logstash从KafKa或redis读取日志存储到elasticsearch中创建索引,最后通过Kibana展示给开发者或运维人员进行分析。这样大大提升了运维线上问题的效率。除此之外,还可以将收集的日志进行大数据分析,得到更有价值的数据给到高层进行决策。

3 K8S中的ELK Stack日志采集方案

image.png

  • 方案一:Node上部署一个日志收集程序 使用DaemonSet的方式去给每一个node上部署日志收集程序logging-agent 然后使用这个agent对本node节点上的/var/log和/var/lib/docker/containers/两个目录下的日志进行采集 或者把Pod中容器日志目录挂载到宿主机统一目录上,这样进行收集

image

因为使用stdout的方式,只需要在宿主机上收集每个容器中的日志/var/log和/var/lib/docker/containers (目录要根据docker info中的dir进行修改,容器会将日志转化为JSON格式,是docker中的配置起的作用)

  • 方案二:Pod中附加专用日志收集的容器 每个运行应用程序的Pod中增加一个日志收集容器,使用emtyDir共享日志目录让日志收集程序读取到。

image

  • 方案三:应用程序直接推送日志 这个方案需要开发在代码中修改直接把应用程序直接推送到远程的存储上,不再输入出控制台或者本地文件了,使用不太多,超出Kubernetes范围

image

方式优点缺点
方案一:Node上部署一个日志收集程序每个Node仅需部署一个日志收集程序,资源消耗少,对应用无侵入应用程序日志需要写到标准输出和标准错误输出,不支持多行日志
方案二:Pod中附加专用日志收集的容器低耦合每个Pod启动一个日志收集代理,增加资源消耗,并增加运维维护成本
方案三:应用程序直接推送日志无需额外收集工具侵入应用,增加应用复杂度

4 K8S中日志采集应该注意的问题

问题1: 一个K8S集群我们需要收集哪些日志?

这里只是以主要收集日志为例:

  • K8S系统的组件日志

  • K8S Cluster里面部署的应用程序日志 -标准输出 -日志文件

问题2: 我们需要收集的日志在哪里,如何去收集当下比较常用的runtime?

docker和containerd的容器日志及相关参数

对比项dockercontainerd
存储路径docker作为k8s容器运行时的情况下,容器日志的落盘由docker来完成, 默认保存在/var/lib/docker/containers/$CONTAINERID目录下。kubelet会在/var/log/pods/var/log/containers下面建立软链接,指向/var/lib/docker/containers/$CONTAINERID目录下的容器日志文件containerd作为k8s容器运行时的情况下, 容器日志的落盘由kubelet来完成,保存到/var/log/pods/$CONTAINER_NAME目录下,同时在/var/log/containers目录下创建软链接,指向日志文件
配置参数在docker配置文件中指定: “log-driver”: “json-file”, “log-opts”: {“max-size”: “100m”,“max-file”: “5”}方法一:在kubelet参数中指定: --container-log-max-files=5 --container-log-max-size=“100Mi” 方法二:在KubeletConfiguration中指定: “containerLogMaxSize”: “100Mi”, “containerLogMaxFiles”: 5,
把容器日志保存到数据盘把数据盘挂载到"data-root"(缺省是/data/var/lib/docker)即可创建一个软链接/var/log/pods指向数据盘挂载点下的某个目录(ln -s /data/var/log/pods /var/log/)

问题3: 是否需要做日志的标准化规范

基本格式

采用json格式输出,为了方便采集,日志应该使用一行输出

定义

所有运行在k8s集群内的业务应用所输出的所有日志。

必要字段
  • level

日志等级字段,字段值统一为小写。

  • debug :指明细致的事件信息,对调试应用最有用。

  • info:指明描述信息,从粗粒度上描述了应用运行过程

  • warn:指明潜在的有害状况。

  • error: 指明错误事件,但应用可能还能继续运行

  • fatal:指明非常严重的错误事件,可能会导致应用终止执行。

日志等级会作为日志采集和日志报警的依据。在生产系环境日志采集器只会采集INFO以上等级的日志,日志报警会拉取error级别以上进行告警。

  • msg

日志主要内容。

  • remote_ip

请求的源ip

  • project

服务名加版本号,如srv-oc-task@1.0.0-cb5d0af

  • time

日志打印时间,统一使用 UTC 时间格式。

  • func

日志所在代码里的目录和行数

可选字段(可选字段按需使用,日志采集后会解析下列字段)
  • request_url

该请求的url

  • status

该请求返回http状态码

  • cost

本次请求花费时间,单位为ms

  • method

该条请求的http方法

  • _id

日志id

ingress日志

统一使用nginx-ingress暴露业务,因此在集群初始化之后,部署的nginx-ingress需要规定一下字段,采用json格式输出,为了方便采集,日志应该使用一行输出。

  • 字段要求
log-format-upstream: '{"@timestamp":"$time_iso8601","host":"$server_addr", "clientip": "$remote_addr", "size" : "$body_bytes_sent" ,"requesttime":"$request_time","upstremtime":"$upstream_response_time","upstremhost":"$upstream_addr","httphost":"$host","referer":"$http_referer","xff":"$http_x_forwarded_for","agent":"$http_user_agent","clientip":"$remote_addr","request":"$request","uri":"$uri","status":"$status"}'

5 部署操作步骤

本次部署采集方案采用为方案一:在Node上部署一个日志收集程序

  • 支持的cpu架构

  • amd64

  • arm64

  • 支持k8s的runtime类别

  • docker

  • containerd

  • ELK Stack各组件版本

  • elasticsearch:7.9.3

  • filebeat:7.9.3

  • kibana:7.9.3

  • logstash:7.9.3

  • 支持的k8s版本

  • v1.15.0+以上版本

本次部署的yaml见项目地址:

5.1 单节点方式部署ES

单节点部署ELK的方法较简单,可以参考下面的yaml编排文件,整体就是创建一个es,然后创建kibana的可视化展示,创建一个es的service服务,然后通过ingress的方式对外暴露域名访问

  • 首先,编写es的yaml,这里部署的是单机版,在k8s集群内中,通常当日志量每天超过20G以上的话,还是建议部署在k8s集群外部,支持分布式集群的架构,这里使用的是有状态部署的方式,并且使用的是hostpath才持久化,因此需要给node打上es的落盘节点标签,才能运行该yaml
#需要提前给es落盘节点打上标签
kubectl label node xxxx es=data
[root@k8s-master fek]# cat es.yaml
---
apiVersion: v1
kind: Service
metadata:name: elasticsearch-loggingnamespace: kube-systemlabels:k8s-app: elasticsearch-loggingkubernetes.io/cluster-service: "true"addonmanager.kubernetes.io/mode: Reconcilekubernetes.io/name: "Elasticsearch"
spec:ports:- port: 9200protocol: TCPtargetPort: dbselector:k8s-app: elasticsearch-logging
---
# RBAC authn and authz
apiVersion: v1
kind: ServiceAccount
metadata:name: elasticsearch-loggingnamespace: kube-systemlabels:k8s-app: elasticsearch-loggingkubernetes.io/cluster-service: "true"addonmanager.kubernetes.io/mode: Reconcile
---
kind: ClusterRole
apiVersion: rbac.authorization.k8s.io/v1
metadata:name: elasticsearch-logginglabels:k8s-app: elasticsearch-loggingkubernetes.io/cluster-service: "true"addonmanager.kubernetes.io/mode: Reconcile
rules:
- apiGroups:- ""resources:- "services"- "namespaces"- "endpoints"verbs:- "get"
---
kind: ClusterRoleBinding
apiVersion: rbac.authorization.k8s.io/v1
metadata:namespace: kube-systemname: elasticsearch-logginglabels:k8s-app: elasticsearch-loggingkubernetes.io/cluster-service: "true"addonmanager.kubernetes.io/mode: Reconcile
subjects:
- kind: ServiceAccountname: elasticsearch-loggingnamespace: kube-systemapiGroup: ""
roleRef:kind: ClusterRolename: elasticsearch-loggingapiGroup: ""
---
# Elasticsearch deployment itself
apiVersion: apps/v1
kind: StatefulSet #使用statefulset创建Pod
metadata:name: elasticsearch-logging #pod名称,使用statefulSet创建的Pod是有序号有顺序的namespace: kube-system  #命名空间labels:k8s-app: elasticsearch-loggingkubernetes.io/cluster-service: "true"addonmanager.kubernetes.io/mode: Reconcilesrv: srv-elasticsearch
spec:serviceName: elasticsearch-logging #与svc相关联,这可以确保使用以下DNS地址访问Statefulset中的每个pod (es-cluster-[0,1,2].elasticsearch.elk.svc.cluster.local)replicas: 1 #副本数量,单节点selector:matchLabels:k8s-app: elasticsearch-logging #和pod template配置的labels相匹配template:metadata:labels:k8s-app: elasticsearch-loggingkubernetes.io/cluster-service: "true"spec:serviceAccountName: elasticsearch-loggingcontainers:- image: docker.io/library/elasticsearch:7.9.3name: elasticsearch-loggingresources:# need more cpu upon initialization, therefore burstable classlimits:cpu: 1000mmemory: 2Girequests:cpu: 100mmemory: 500Miports:- containerPort: 9200name: dbprotocol: TCP- containerPort: 9300name: transportprotocol: TCPvolumeMounts:- name: elasticsearch-loggingmountPath: /usr/share/elasticsearch/data/   #挂载点env:- name: "NAMESPACE"valueFrom:fieldRef:fieldPath: metadata.namespace- name: "discovery.type"  #定义单节点类型value: "single-node"- name: ES_JAVA_OPTS #设置Java的内存参数,可以适当进行加大调整value: "-Xms512m -Xmx2g" volumes:- name: elasticsearch-logginghostPath:path: /data/es/nodeSelector: #如果需要匹配落盘节点可以添加nodeSelectes: datatolerations:- effect: NoScheduleoperator: Exists# Elasticsearch requires vm.max_map_count to be at least 262144.# If your OS already sets up this number to a higher value, feel free# to remove this init container.initContainers: #容器初始化前的操作- name: elasticsearch-logging-initimage: alpine:3.6command: ["/sbin/sysctl", "-w", "vm.max_map_count=262144"] #添加mmap计数限制,太低可能造成内存不足的错误securityContext:  #仅应用到指定的容器上,并且不会影响Volumeprivileged: true #运行特权容器- name: increase-fd-ulimitimage: busyboximagePullPolicy: IfNotPresentcommand: ["sh", "-c", "ulimit -n 65536"] #修改文件描述符最大数量securityContext:privileged: true- name: elasticsearch-volume-init #es数据落盘初始化,加上777权限image: alpine:3.6command:- chmod- -R- "777"- /usr/share/elasticsearch/data/volumeMounts:- name: elasticsearch-loggingmountPath: /usr/share/elasticsearch/data/
  • 使用刚才编写好的yaml文件创建Elasticsearch,然后检查是否启动,如下所示能看到一个elasticsearch-0 的pod副本被创建,正常运行;如果不能正常启动可以使用kubectl describe查看详细描述,排查问题
[root@k8s-master fek]# kubectl get pod -n kube-system
NAME                        READY   STATUS             RESTARTS   AGE
coredns-5bd5f9dbd9-95flw    1/1     Running            0          17h
elasticsearch-0             1/1     Running            1          16m
  • 然后,需要部署一个Kibana来对搜集到的日志进行可视化展示,使用Deployment的方式编写一个yaml,seivice中使用的是nodeport 25601端口对外进行暴露访问,直接引用了es,也可以选择使用ingress进行暴露
[root@k8s-master fek]# cat kibana.yaml
---
apiVersion: v1
kind: Service
metadata:name: kibananamespace: kube-systemlabels:k8s-app: kibanakubernetes.io/cluster-service: "true"addonmanager.kubernetes.io/mode: Reconcilekubernetes.io/name: "Kibana"srv: srv-kibana
spec:type: NodePort #采用nodeport方式进行暴露,端口默认为25601ports:- port: 5601nodePort: 25601protocol: TCPtargetPort: uiselector:k8s-app: kibana
---
apiVersion: apps/v1
kind: Deployment
metadata:name: kibananamespace: kube-systemlabels:k8s-app: kibanakubernetes.io/cluster-service: "true"addonmanager.kubernetes.io/mode: Reconcilesrv: srv-kibana
spec:replicas: 1selector:matchLabels:k8s-app: kibanatemplate:metadata:labels:k8s-app: kibanaannotations:seccomp.security.alpha.kubernetes.io/pod: 'docker/default'spec:containers:- name: kibanaimage: docker.io/kubeimages/kibana:7.9.3 #该镜像支持arm64和amd64两种架构resources:# need more cpu upon initialization, therefore burstable classlimits:cpu: 1000mrequests:cpu: 100menv:- name: ELASTICSEARCH_HOSTSvalue: http://elasticsearch-logging:9200ports:- containerPort: 5601name: uiprotocol: TCP
---
apiVersion: extensions/v1beta1
kind: Ingress
metadata:name: kibananamespace: kube-system
spec:rules:- host: kibana.ctnrshttp:paths:- path: /backend:serviceName: kibanaservicePort: 5601
  • 使用刚才编写好的yaml创建kibana,可以看到最后生成了一个kibana-b7d98644-lshsz的pod,并且正常运行
[root@k8s-master fek]# kubectl apply -f kibana.yaml
deployment.apps/kibana created
service/kibana created
[root@k8s-master fek]# kubectl get pod -n kube-system
NAME                        READY   STATUS             RESTARTS   AGE
coredns-5bd5f9dbd9-95flw    1/1     Running            0          17h
elasticsearch-0             1/1     Running            1          16m
kibana-b7d98644-48gtm       1/1     Running            1          17h
  • 最后在浏览器中,输入http://(任意一节点的ip):25601,就会进入kibana的web界面,已设置了不需要进行登陆,当前页面都是全英文模式,可以修改上网搜一下修改配置文件的位置,建议使用英文版本

image.png

5.2 Node上部署一个filebeat采集器采集k8s组件日志

  • es和kibana部署好了之后,我们如何采集pod日志呢,我们采用方案一的方式,是要在每一个node上中部署一个filebeat的采集器,采用的是7.9.3版本,除此之外我已经按照文中4小节里面的问题2中对docker或者containerd的runtime进行了标准的日志落盘
[root@k8s-master fek]# cat filebeat.yaml
---
apiVersion: v1
kind: ConfigMap
metadata:name: filebeat-confignamespace: kube-systemlabels:k8s-app: filebeat
data:filebeat.yml: |-filebeat.inputs:- type: containerpaths:- /var/log/containers/*.log #这里是filebeat采集挂载到pod中的日志目录processors:- add_kubernetes_metadata: #添加k8s的字段用于后续的数据清洗host: ${NODE_NAME}matchers:- logs_path:logs_path: "/var/log/containers/"#output.kafka:  #如果日志量较大,es中的日志有延迟,可以选择在filebeat和logstash中间加入kafka#  hosts: ["kafka-log-01:9092", "kafka-log-02:9092", "kafka-log-03:9092"]# topic: 'topic-test-log'#  version: 2.0.0output.logstash: #因为还需要部署logstash进行数据的清洗,因此filebeat是把数据推到logstash中hosts: ["logstash:5044"]enabled: true
---
# Source: filebeat/templates/filebeat-service-account.yaml
apiVersion: v1
kind: ServiceAccount
metadata:name: filebeatnamespace: kube-systemlabels:k8s-app: filebeat---
# Source: filebeat/templates/filebeat-role.yaml
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRole
metadata:name: filebeatlabels:k8s-app: filebeat
rules:
- apiGroups: [""] # "" indicates the core API groupresources:- namespaces- podsverbs:- get- watch- list---
# Source: filebeat/templates/filebeat-role-binding.yaml
apiVersion: rbac.authorization.k8s.io/v1beta1
kind: ClusterRoleBinding
metadata:name: filebeat
subjects:
- kind: ServiceAccountname: filebeatnamespace: kube-system
roleRef:kind: ClusterRolename: filebeatapiGroup: rbac.authorization.k8s.io---
# Source: filebeat/templates/filebeat-daemonset.yaml
apiVersion: apps/v1
kind: DaemonSet
metadata:name: filebeatnamespace: kube-systemlabels:k8s-app: filebeat
spec:selector:matchLabels:k8s-app: filebeattemplate:metadata:labels:k8s-app: filebeatspec:serviceAccountName: filebeatterminationGracePeriodSeconds: 30containers:- name: filebeatimage: docker.io/kubeimages/filebeat:7.9.3 #该镜像支持arm64和amd64两种架构args: ["-c", "/etc/filebeat.yml","-e","-httpprof","0.0.0.0:6060"]#ports:#  - containerPort: 6060#    hostPort: 6068env:- name: NODE_NAMEvalueFrom:fieldRef:fieldPath: spec.nodeName- name: ELASTICSEARCH_HOSTvalue: elasticsearch-logging- name: ELASTICSEARCH_PORTvalue: "9200"securityContext:runAsUser: 0# If using Red Hat OpenShift uncomment this:#privileged: trueresources:limits:memory: 1000Micpu: 1000mrequests:memory: 100Micpu: 100mvolumeMounts:- name: config #挂载的是filebeat的配置文件mountPath: /etc/filebeat.ymlreadOnly: truesubPath: filebeat.yml- name: data #持久化filebeat数据到宿主机上mountPath: /usr/share/filebeat/data- name: varlibdockercontainers #这里主要是把宿主机上的源日志目录挂载到filebeat容器中,如果没有修改docker或者containerd的runtime进行了标准的日志落盘路径,可以把mountPath改为/var/libmountPath: /data/var/readOnly: true- name: varlog #这里主要是把宿主机上/var/log/pods和/var/log/containers的软链接挂载到filebeat容器中mountPath: /var/log/readOnly: true- name: timezonemountPath: /etc/localtimevolumes:- name: configconfigMap:defaultMode: 0600name: filebeat-config- name: varlibdockercontainershostPath: #如果没有修改docker或者containerd的runtime进行了标准的日志落盘路径,可以把path改为/var/libpath: /data/var/- name: varloghostPath:path: /var/log/# data folder stores a registry of read status for all files, so we don't send everything again on a Filebeat pod restart- name: inputsconfigMap:defaultMode: 0600name: filebeat-inputs- name: datahostPath:path: /data/filebeat-datatype: DirectoryOrCreate- name: timezonehostPath:path: /etc/localtimetolerations: #加入容忍能够调度到每一个节点- effect: NoExecutekey: dedicatedoperator: Equalvalue: gpu- effect: NoScheduleoperator: Exists
  • 部署之后,检查是否成功创建,能看到两个命名为filebeat-xx的pod副本分别创建在两个nodes上
[root@k8s-master elk]# kubectl apply -f filebeat.yaml
[root@k8s-master elk]# kubectl get pod -n kube-system
NAME                        READY   STATUS    RESTARTS   AGE
coredns-5bd5f9dbd9-8zdn5    1/1     Running   0          10h
elasticsearch-0             1/1     Running   1          13h
filebeat-2q5tz              1/1     Running   0          13h
filebeat-k6m27              1/1     Running   2          13h
kibana-b7d98644-tllmm       1/1     Running   0          10h

5.3 增加logstash来对采集到的原始日志进行业务需要的清洗

  • 这里主要是结合业务需要和对日志的二次利用,grafana展示,所以加入了logstash进行日志的清洗,需要是对ingrss的字段类型进行了转换,业务服务日志进行了字段的变更和类型转换,大家可以根据自己的业务需求进行调整
[root@k8s-master fek]# cat logstash.yaml
---
apiVersion: v1
kind: Service
metadata:name: logstashnamespace: kube-system
spec:ports:- port: 5044targetPort: beatsselector:type: logstashclusterIP: None
---
apiVersion: apps/v1
kind: Deployment
metadata:name: logstashnamespace: kube-system
spec:selector:matchLabels:type: logstashtemplate:metadata:labels:type: logstashsrv: srv-logstashspec:containers:- image: docker.io/kubeimages/logstash:7.9.3 #该镜像支持arm64和amd64两种架构name: logstashports:- containerPort: 5044name: beatscommand:- logstash- '-f'- '/etc/logstash_c/logstash.conf'env:- name: "XPACK_MONITORING_ELASTICSEARCH_HOSTS"value: "http://elasticsearch-logging:9200"volumeMounts:- name: config-volumemountPath: /etc/logstash_c/- name: config-yml-volumemountPath: /usr/share/logstash/config/- name: timezonemountPath: /etc/localtimeresources: #logstash一定要加上资源限制,避免对其他业务造成资源抢占影响limits:cpu: 1000mmemory: 2048Mirequests:cpu: 512mmemory: 512Mivolumes:- name: config-volumeconfigMap:name: logstash-confitems:- key: logstash.confpath: logstash.conf- name: timezonehostPath:path: /etc/localtime- name: config-yml-volumeconfigMap:name: logstash-ymlitems:- key: logstash.ymlpath: logstash.yml---
apiVersion: v1
kind: ConfigMap
metadata:name: logstash-confnamespace: kube-systemlabels:type: logstash
data:logstash.conf: |-input {beats {port => 5044}}filter{ # 处理ingress日志if [kubernetes][container][name] == "nginx-ingress-controller" {json {source => "message"target => "ingress_log"}if [ingress_log][requesttime] {mutate {convert => ["[ingress_log][requesttime]", "float"]}}if [ingress_log][upstremtime] {mutate {convert => ["[ingress_log][upstremtime]", "float"]}}if [ingress_log][status] {mutate {convert => ["[ingress_log][status]", "float"]}}if  [ingress_log][httphost] and [ingress_log][uri] {mutate {add_field => {"[ingress_log][entry]" => "%{[ingress_log][httphost]}%{[ingress_log][uri]}"}}mutate{split => ["[ingress_log][entry]","/"]}if [ingress_log][entry][1] {mutate{add_field => {"[ingress_log][entrypoint]" => "%{[ingress_log][entry][0]}/%{[ingress_log][entry][1]}"}remove_field => "[ingress_log][entry]"}}else{mutate{add_field => {"[ingress_log][entrypoint]" => "%{[ingress_log][entry][0]}/"}remove_field => "[ingress_log][entry]"}}}}# 处理以srv进行开头的业务服务日志if [kubernetes][container][name] =~ /^srv*/ {json {source => "message"target => "tmp"}if [kubernetes][namespace] == "kube-system" {drop{}}if [tmp][level] {mutate{add_field => {"[applog][level]" => "%{[tmp][level]}"}}if [applog][level] == "debug"{drop{}}}if [tmp][msg]{mutate{add_field => {"[applog][msg]" => "%{[tmp][msg]}"}}}if [tmp][func]{mutate{add_field => {"[applog][func]" => "%{[tmp][func]}"}}}if [tmp][cost]{if "ms" in [tmp][cost]{mutate{split => ["[tmp][cost]","m"]add_field => {"[applog][cost]" => "%{[tmp][cost][0]}"}convert => ["[applog][cost]", "float"]}}else{mutate{add_field => {"[applog][cost]" => "%{[tmp][cost]}"}}}}if [tmp][method]{mutate{add_field => {"[applog][method]" => "%{[tmp][method]}"}}}if [tmp][request_url]{mutate{add_field => {"[applog][request_url]" => "%{[tmp][request_url]}"}}}if [tmp][meta._id]{mutate{add_field => {"[applog][traceId]" => "%{[tmp][meta._id]}"}}}if [tmp][project] {mutate{add_field => {"[applog][project]" => "%{[tmp][project]}"}}}if [tmp][time] {mutate{add_field => {"[applog][time]" => "%{[tmp][time]}"}}}if [tmp][status] {mutate{add_field => {"[applog][status]" => "%{[tmp][status]}"}convert => ["[applog][status]", "float"]}}}mutate{rename => ["kubernetes", "k8s"]remove_field => "beat"remove_field => "tmp"remove_field => "[k8s][labels][app]"}}output{elasticsearch {hosts => ["http://elasticsearch-logging:9200"]codec => jsonindex => "logstash-%{+YYYY.MM.dd}" #索引名称以logstash+日志进行每日新建}}
---apiVersion: v1
kind: ConfigMap
metadata:name: logstash-ymlnamespace: kube-systemlabels:type: logstash
data:logstash.yml: |-http.host: "0.0.0.0"xpack.monitoring.elasticsearch.hosts: http://elasticsearch-logging:9200

5.4 在kibana的web界面进行配置日志可视化

  • 首先登录kibana界面之后,打开菜单中的stack management模块

image.png

  • 点开索引管理,可以发现,已经有采集到的日志索引了

image.png

  • 为避免es日志占用磁盘空间越来越大,因此我们可以根据业务需要增加一个索引生命周期策略,点击index lifecycle policites

image

  • Policy name写为logstash-history-ilm-policy,不能随意更改,后续的模版中会引用

image

image

  • 为了能够在kibana中能够discover查看日志,因此需要设置一个索引匹配,选择index patterns,然后创建

image

image

image

  • 由于我们是部署的单节点,因此创建的索引使用默认的索引模版会产生一个1副本,所以会发现索引都是yellow,解决办法如下

在菜单中打开,dev tools

image.png

然后调用api进行更改,会把所有的索引副本数全部改为0

image

PUT _all/_settings
{"number_of_replicas": 0
}
  • 为了根本解决和链接索引生命周期策略,标准化日志字段中的map类型,因此我们需要修改默认的template
PUT _template/logstash
{"order": 1,"index_patterns": ["logstash-*"],"settings": {"index": {"lifecycle" : {"name" : "logstash-history-ilm-policy"},"number_of_shards": "2","refresh_interval": "5s","number_of_replicas" : "0"}},"mappings": {"properties": {"@timestamp": {"type": "date"},"applog": {"dynamic": true,"properties": {"cost": {"type": "float"},"func": {"type": "keyword"},"method": {"type": "keyword"}}},"k8s": {"dynamic": true,"properties": {"namespace": {"type": "keyword"},"container": {"dynamic": true,"properties": {"name": {"type": "keyword"}}},"labels": {"dynamic": true,"properties": {"srv": {"type": "keyword"}}}}},"geoip": {"dynamic": true,"properties": {"ip": {"type": "ip"},"latitude": {"type": "float"},"location": {"type": "geo_point"},"longitude": {"type": "float"}}}}},"aliases": {}}

image

  • 最后验证索引和discover

image

image.png

写在最后

日志采集只是业务可观测性中的一部分,并且对于日志不光有Elastic Stack,也有Loki、Splunk或者托管云上的日志收集方案等,条条大路通罗马,不管怎么做,最终到达效果即可,没有哪个方案绝对的好,只能是在什么业务场景最适合,最能反应出业务的问题,快速排查到业务上问题才是好的

公众号:运维开发故事

github:

爱生活,爱运维

如果你觉得文章还不错,就请点击右上角选择发送给朋友或者转发到朋友圈。您的支持和鼓励是我最大的动力。喜欢就请关注我吧~

扫码二维码

关注我,不定期维护优质内容

温馨提示

如果你喜欢本文,请分享到朋友圈,想要获得更多信息,请关注我。

                                          ........................

更多推荐

Kubernetes中部署ELK Stack日志收集平台

本文发布于:2024-02-12 03:15:24,感谢您对本站的认可!
本文链接:https://www.elefans.com/category/jswz/34/1685553.html
版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系,我们将在24小时内删除。
本文标签:平台   日志   Kubernetes   ELK   Stack

发布评论

评论列表 (有 0 条评论)
草根站长

>www.elefans.com

编程频道|电子爱好者 - 技术资讯及电子产品介绍!