上图是 EFK 架构图，k8s 环境下常见的日志采集形式。

日志需要

1 集中采集微服务的日志，能够依据申请 id 追踪到残缺的日志；

2 统计申请接口的耗时，超出最长响应工夫的，须要做报警，并针对性的进行调优；

3 慢 sql 排行榜，并报警；

4 异样日志排行榜，并报警；

5 慢页面申请排行，并告警；

k8s 的日志采集

k8s 自身不会为你做日志采集，须要本人做；

k8s 的容器日志解决形式采纳的 集群层级日志，

即容器销毁，pod 漂移，Node 宕机不会对容器日志造成影响；

容器的日志会输入到 stdout,stderr, 对应的存储在宿主机的目录中，

即 /var/lib/docker/container；

Node 上通过日志代理转发

在每个 node 上部署一个 daemonset , 跑一个 logging-agent 收集日志，

比方 fluentd, 采集宿主机对应的数据盘上的日志，而后输入到日志存储服务或者音讯队列；

优缺点剖析：

Pod 外部通过 sidecar 容器转发到日志服务

通过在 pod 中启动一个 sidecar 容器，比方 fluentd，读取容器挂载的 volume 目录，输入到日志服务端；

日志输出源：日志文件

日志解决：logging-agent , 比方 fluentd

日志存储：比方 elasticSearch , kafka

优缺点剖析：

示例：

apiVersion: v1
kind: Pod
metadata:
  name: counter
spec:
  containers:
  - name: count
    image: busybox
    args:
    - /bin/sh
    - -c
    - >
        i=0;
        while true;
        do
          echo "$i:$(data)" >> /var/log/1.log
          echo "$(data) INFO $i" >> /var/log/2.log
           i=$((i+1))
          sleep 1;
        done
    volumeMounts:
    - name: varlog
        mountPath: /var/log
  - name: count-agent
    image: k8s.gcr.io/fluentd-gcp:1.30
    env:
    - name: FLUENTD_ARGS
        value: -c /etc/fluentd-config/fluentd.conf
    valumeMounts:
    - name: varlog
        mountPath: /var/log
    - name: config-volume
        mountPath: /etc/fluentd-config
  volumes:
  - name: varlog
      emptyDir: {}
  - name: config-volume
      configMap:
        name: fluentd-config

Pod 外部通过 sidecar 容器输入到 stdout

实用于利用容器只能把日志输入到文件，无奈输入到 stdout,stderr 中的场景；

通过一个 sidecar 容器，间接读取日志文件，再从新输入到 stdout,stderr 中，

即可应用 Node 上通过日志代理转发的模式；

优缺点剖析：

利用容器间接输入日志到日志服务

实用于有成熟日志零碎的场景，日志不须要通过 k8s;

EFK 介绍

fluentd

fluentd 是一个对立日志层的开源数据收集器。

flentd 容许你对立日志收集并更好的应用和了解数据；

四大特色：

对立日志层

fluentd 隔断数据源，从后盾零碎提供对立日志层；

简略灵便
提供了 500 多个插件，连贯十分多的数据源和输入源，内核简略；

宽泛验证
5000 多家数据驱动公司以来 Fluentd
最大的客户通过它收集 5 万多台服务器的日志

** 云原生 **

是云原生 CNCF 的成员我的项目

4 大劣势：

对立 JSON 日志

fluentd 尝试采纳 JSON 结构化数据，这就对立了所有解决日志数据的方面，收集，过滤，缓存，输入日志到多目的地，上行流数据处理应用 Json 更简略，因为它曾经有足够的拜访构造并保留了足够灵便的 scemas；

插件化架构

fluntd 有灵便的插件体系容许社区扩大性能，500 多个社区奉献的插件连贯了很多数据源和目的地；通过插件，你能够开始更好的应用你的日志

最小资源耗费

c 和 ruby 写的，须要极少的系统资源，40M 左右的内存能够解决 13k/ 工夫 / 秒，如果你须要更紧凑的内存，能够应用 Fluent bit , 更轻量的 Fluentd

内核牢靠

Fluentd 反对内存和基于文件缓存，避免外部节点数据失落；
也反对 robust 失败并且能够配置高可用模式，2000 多家数据驱动公司在不同的产品中依赖 Fluentd，更好的应用和了解他们的日志数据 

应用 fluentd 的起因：

简略灵便

10 分钟即可在你的电脑上装置 fluentd，你能够马上下载它，500 多个插件买通数据源和目的地，插件也很好开发和部署；

开源

基于 Apache2.0 证书  齐全开源 

牢靠高性能

5000 多个数据驱动公司的不同产品和服务依赖 fluentd，更好的应用和了解数据，实际上，基于 datadog 的考察，是应用 docker 运行的排行 top7 的技术；

一些 fluentd 用户实时采集上千台机器的数据，每个实例只须要 40M 左右的内存，伸缩的时候，你能够节俭很多内存

社区

fluentd 能够改良软件并帮忙其它人更好的应用

大公司应用背书：微软，亚马逊；pptv ;

能够联合 elasticSearch + kibana 来一起组成日志套件；
疾速搭建 EFK 集群并收集利用的日志，配置性能排行榜；

elasticsearch

Elasticsearch 是一个分布式、RESTful 格调的搜寻和数据分析引擎，

可能解决不断涌现出的各种用例。作为 Elastic Stack 的外围，

它集中存储您的数据，帮忙您发现意料之中以及意料之外的状况。

具体介绍：https://www.elastic.co/guide/cn/elasticsearch/guide/current/foreword_id.html

kibana

Kibana 是一款开源的数据分析和可视化平台，它是 Elastic Stack 成员之一，

设计用于和 Elasticsearch 合作。您能够应用 Kibana 对 Elasticsearch 索引中的数据进行搜寻、

查看、交互操作。您能够很不便的利用图表、表格及地图对数据进行多元化的剖析和出现。

Kibana 能够使大数据通俗易懂。它很简略，

基于浏览器的界面便于您疾速创立和分享动态数据仪表板来追踪 Elasticsearch 的实时数据变动.

具体介绍：https://www.elastic.co/guide/cn/kibana/current/introduction.html

容器化 EFK 实现门路

https://github.com/kayrus/elk-kubernetes

间接拖代码下来，而后配置后 context, namespace , 即可装置；

cd elk-kubernetes

./deploy.sh --watch

上面是 deploy.sh 的脚本，能够简略看一下：

#!/bin/sh

CDIR=$(cd `dirname "$0"` && pwd)
cd "$CDIR"

print_red() {printf '%b' "\033[91m$1\033[0m\n"}

print_green() {printf '%b' "\033[92m$1\033[0m\n"}

render_template() {eval "echo \"$(cat "$1")\""
}


KUBECTL_PARAMS="--context=250091890580014312-cc3174dcd4fc14cf781b6fc422120ebd8"
NAMESPACE=${NAMESPACE:-sm}
KUBECTL="kubectl ${KUBECTL_PARAMS} --namespace=\"${NAMESPACE}\""eval"kubectl ${KUBECTL_PARAMS} create namespace \"${NAMESPACE}\""

#NODES=$(eval "${KUBECTL} get nodes -l'kubernetes.io/role!=master'-o go-template=\"{{range .items}}{{\\\$name := .metadata.name}}{{\\\$unschedulable := .spec.unschedulable}}{{range .status.conditions}}{{if eq .reason \\\"KubeletReady\\\"}}{{if eq .status \\\"True\\\"}}{{if not \\\$unschedulable}}{{\\\$name}}{{\\\"\\\\n\\\"}}{{end}}{{end}}{{end}}{{end}}{{end}}\"")
NODES=$(eval "${KUBECTL} get nodes -l'sm.efk=data'-o go-template=\"{{range .items}}{{\\\$name := .metadata.name}}{{\\\$unschedulable := .spec.unschedulable}}{{range .status.conditions}}{{if eq .reason \\\"KubeletReady\\\"}}{{if eq .status \\\"True\\\"}}{{if not \\\$unschedulable}}{{\\\$name}}{{\\\"\\\\n\\\"}}{{end}}{{end}}{{end}}{{end}}{{end}}\"")
ES_DATA_REPLICAS=$(echo "$NODES" | wc -l)

if ["$ES_DATA_REPLICAS" -lt 3]; then
  print_red "Minimum amount of Elasticsearch data nodes is 3 (in case when you have 1 replica shard), you have ${ES_DATA_REPLICAS} worker nodes"
  print_red "Won't deploy more than one Elasticsearch data pod per node exiting..."
  exit 1
fi

print_green "Labeling nodes which will serve Elasticsearch data pods"
for node in $NODES; do
  eval "${KUBECTL} label node ${node} elasticsearch.data=true --overwrite"
done

for yaml in *.yaml.tmpl; do
  render_template "${yaml}" | eval "${KUBECTL} create -f -"
done

for yaml in *.yaml; do
  eval "${KUBECTL} create -f \"${yaml}\""
done

eval "${KUBECTL} create configmap es-config --from-file=es-config --dry-run -o yaml" | eval "${KUBECTL} apply -f -"
eval "${KUBECTL} create configmap fluentd-config --from-file=docker/fluentd/td-agent.conf --dry-run -o yaml" | eval "${KUBECTL} apply -f -"
eval "${KUBECTL} create configmap kibana-config --from-file=kibana.yml --dry-run -o yaml" | eval "${KUBECTL} apply -f -"

eval "${KUBECTL} get pods $@"

简略合成一下部署的流程：

我的 k8s 环境中没有搭建胜利，后续搭建胜利了再出具体的装置笔记。

小结

一句话概括本篇：EFK 是一种通过日志代理客户端采集利用日志比拟罕用的实现形式。

原创不易，关注诚可贵，转发价更高！转载请注明出处，让咱们互通有无，共同进步，欢送沟通交流。