Tags: k8s环境下的容器日志收集
K8S环境下面如何收集应用日志
===
在本文中重点讲一下K8S容器环境中如何收集容器的日志;
创新互联-专业网站定制、快速模板网站建设、高性价比盐亭网站开发、企业建站全套包干低至880元,成熟完善的模板库,直接使用。一站式盐亭网站制作公司更省心,省钱,快速模板网站建设找我们,业务覆盖盐亭地区。费用合理售后完善,十余年实体公司更值得信赖。
在K8S集群中,容器的日志收集方案一般有三种;第一种方案是通过在每一个k8s节点安装日志收集客户端软件,比如fluentd。这种方案不好的一点是应用的日志必须输出到标准输出,并且是通过在每一台计算节点的/var/log/containers目录下面的日志文件,这个日志文件的名称是这种格式user-center-765885677f-j68zt_default_user-center-0867b9c2f8ede64cebeb359dd08a6b05f690d50427aa89f7498597db8944cccc.log,文件名称有很多随机字符串,很难和容器里面的应用对应起来。并且在网上看到别人说这个里面的日志,对于JAVA的报错内容没有多行合并,不过我还没有测试过此方案。
第二种方案就是在应用的pods里面在运行一个sidecar container(边角容器),这个容器会和应用的容器挂载同一个volume日志卷。比如这个sidecar容器可以是filebeat或者flunetd等;这种方案不足之处是部署了sidecar , 所以会消耗资源 , 每个pod都要起一个日志收集容器。
第三种方案就是直接将应用的日志收集到kafka,然后通过kafka再发送到logstash,再处理成json格式的日志发送到es集群,最后在kibana展示。我实验的就是这种方案。通过修改logsbak配置文件实现了日志直接发送到kafka缓存的功能;下面直接看配置了
-
-
[%date{ISO8601}] [%level] %logger{80} [%thread] [%tid] ${dev-group-name} ${app-name} Line:%-3L - %msg%n
-
${log-path}/${app-name}/${filename}.log
-
/${log-path}/${app-name}/${filename}.%d{yyyy-MM-dd}.%i.log
15
300MB
-
[%date{ISO8601}] [%level] %logger{80} [%thread] [%tid] ${dev-group-name} ${app-name} Line:%-3L - %msg%n
${log-path}/${app-name}/${filename}-error.log
/${log-path}/${app-name}/${filename}-error.%d{yyyy-MM-dd}.%i.log
300MB
15
[%date{ISO8601}] [%level] %logger{80} [%thread] [%tid] ${dev-group-name} ${app-name} Line:%-3L - %msg%n
ERROR
ACCEPT
DENY
[%date{ISO8601}] [%level] %logger{80} [%thread] [%tid] ${dev-group-name} ${app-name} Line:%-3L - %msg%n
elk-stand-sit-fkp-eureka
bootstrap.servers=192.168.1.12:9092,192.168.1.14:9092,192.168.1.15:9092
acks=0
linger.ms=1000
max.block.ms=0
client.id=${HOSTNAME}-${CONTEXT_NAME}-logback-relaxed
block.on.buffer.full=false
###2. 针对logsbak配置说明:###
%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36} - %msg%n
important-logs
0
bootstrap.servers=localhost:9092
buffer.memory=8388608
metadata.fetch.timeout.ms=99999999999
client.id=${HOSTNAME}-${CONTEXT_NAME}-logback-restrictive
compression.type=gzip
通过配置logsbak直接输出到kafka,并且使用异步模式,就成功的在kibana里面看到了容器的日志了;