Kubernetes容器日志收集 (2)

可参考：https://github.com/kubernetes/enhancements/blob/master/keps/sig-storage/20181029-volume-subpath-env-expansion.md
日志落盘参考细节：

env: - name: POD_NAME valueFrom: fieldRef: apiVersion: v1 fieldPath: metadata.name ... volumeMounts: - name: workdir1 mountPath: /logs subPathExpr: $(POD_NAME)

我们主要使用了在Pod里的主容器挂载了一个fluent-agent的收集器，来将日志进行收集，其中我们修改了Kubernetes-Client的源码使之支持subPathExpr，然后发送到日志系统的kafka。这种方式能够处理多种日志的收集，比如业务方的日志打到控制台了，但是jvm的日志不能同时打到控制台，否则会发生错乱，所以，如果能够将业务日志挂载到宿主机上，同时将一些其他的日志比如jvm的日志挂载到容器上，就可以使用该种方式。

{ "_fileName":"/data/work/logs/epaas_2019-05-22-0.log", "_sortedId":"660c2ce8-aacc-42c4-80d1-d3f6d4c071ea", "_collectTime":"2019-05-22 17:23:58", "_log":"[33m2019-05-22 17:23:58[0;39m |[34mINFO [0;39m |[34mmain[0;39m |[34mSpringApplication.java:679[0;39m |[32mcom.hqyg.epaas.EpaasPortalApplication[0;39m | The following profiles are active: dev", "_domain":"rongqiyun-dev", "_podName":"aofjweojo-5679849765-gncbf", "_hostName":"dev4.gcloud.set" } 二、Daemonset方式

daemonset方式也是基于journal，日志使用journal的log-driver，变成二进制的日志，然后在每个node节点上部署一个日志收集的agent，挂载/var/log/journal的日志进行解析，然后发送到kafka或者es，如果节点或者日志量比较大的话，对es的压力实在太大，所以，我们选择将日志推送到kafka。容器日志收集普遍使用fluentd，资源要求较少，性能高，是目前最成熟的日志收集方案，可惜是使用了ruby来写的，普通人根本没时间去话时间学习这个然后进行定制，好在openshift中提供了origin-aggregated-logging方案。
我们可以通过fluent.conf来看origin-aggregated-logging做了哪些工作，把注释，空白的一些东西去掉，然后我稍微根据自己的情况修改了下，结果如下：

@include configs.d/openshift/system.conf 设置fluent的日志级别 @include configs.d/openshift/input-pre-*.conf 最主要的地方，读取journal的日志 @include configs.d/dynamic/input-syslog-*.conf 读取syslog，即操作日志 <label @INGRESS> @include configs.d/openshift/filter-retag-journal.conf 进行匹配 @include configs.d/openshift/filter-k8s-meta.conf 获取Kubernetes的相关信息 @include configs.d/openshift/filter-viaq-data-model.conf 进行模型的定义 @include configs.d/openshift/filter-post-*.conf 生成es的索引id @include configs.d/openshift/filter-k8s-record-transform.conf 修改日志记录，我们在这里进行了字段的定制，移除了不需要的字段 @include configs.d/openshift/output-applications.conf 输出，默认是es，如果想使用其他的比如kafka，需要自己定制 </label>

当然，细节上并没有那么好理解，换成一步步理解如下：

1. 解析journal日志
origin-aggregated-logging会将二进制的journal日志中的CONTAINER_NAME进行解析，根据匹配规则将字段进行拆解

"kubernetes": { "container_name": "fas-dataservice-dev-new", "namespace_name": "fas-cost-dev", "pod_name": "fas-dataservice-dev-new-5c48d7c967-kb79l", "pod_id": "4ad125bb7558f52e30dceb3c5e88dc7bc160980527356f791f78ffcaa6d1611c", "namespace_id": "f95238a6-3a67-11e9-a211-20040fe7b690" }

2. es封装
主要用的是elasticsearch_genid_ext插件，写在了filter-post-genid.conf上。

3. 日志分类
通过origin-aggregated-logging来收集journal的日志，然后推送至es，origin-aggregated-logging在推送过程中做了不少优化，即适应高ops的、带有等待队列的、推送重试等，详情可以具体查看一下。

还有就是对日志进行了分类，分为三种：
（1）.操作日志(在es中以.operations匹配的)，记录了对Kubernetes的操作
（2）.项目日志(在es中以project匹配的)，业务日志，日志收集中最重要的
（3）.孤儿日志(在es中以.orphaned.*匹配的)，没有namespace的日志都会打到这里