|
上圖是EFK架構圖，k8s環(huán)境下常見的日志采集方式。
日志需求
1 集中采集微服務的日志，可以根據(jù)請求id追蹤到完整的日志；
2 統(tǒng)計請求接口的耗時，超出最長響應時間的，需要做報警，并針對性的進行調優(yōu)；
3 慢sql排行榜，并報警；
4 異常日志排行榜，并報警；
5 慢頁面請求排行，并告警；
k8s的日志采集
k8s本身不會為你做日志采集，需要自己做；
k8s的容器日志處理方式采用的 集群層級日志，
即容器銷毀，pod漂移，Node宕機不會對容器日志造成影響；
容器的日志會輸出到stdout,stderr,對應的存儲在宿主機的目錄中，
即 /var/lib/docker/container ；
Node上通過日志代理轉發(fā)
在每個node上部署一個daemonset , 跑一個logging-agent收集日志，
比如fluentd, 采集宿主機對應的數(shù)據(jù)盤上的日志，然后輸出到日志存儲服務或者消息隊列；
優(yōu)缺點分析：
| 對比 |
說明 |
| 優(yōu)點 |
1每個Node只需要部署一個Pod采集日志 2對應用無侵入 |
| 缺點 |
應用輸出的日志都必須直接輸出到容器的stdout,stderr中 |
Pod內部通過sidecar容器轉發(fā)到日志服務
通過在pod中啟動一個sidecar容器，比如fluentd， 讀取容器掛載的volume目錄，輸出到日志服務端；
日志輸入源： 日志文件
日志處理： logging-agent ,比如fluentd
日志存儲： 比如elasticSearch , kafka
優(yōu)缺點分析：
| 對比 |
說明 |
| 優(yōu)點 |
1 部署簡單；2 對宿主機友好； |
| 缺點 |
1. 消耗較多的資源；2. 日志通過kubectl logs 無法看到 |
示例：
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上通過日志代理轉發(fā)的模式；
優(yōu)缺點分析：
| 對比 |
說明 |
| 優(yōu)點 |
只需耗費比較少的cpu和內存，共享volume處理效率比較高 |
| 缺點 |
宿主機上存在兩份相同的日志，磁盤利用率不高 |
應用容器直接輸出日志到日志服務
適用于有成熟日志系統(tǒng)的場景，日志不需要通過k8s;
EFK介紹
fluentd
fluentd是一個統(tǒng)一日志層的開源數(shù)據(jù)收集器。
flentd允許你統(tǒng)一日志收集并更好的使用和理解數(shù)據(jù)；
四大特征：
統(tǒng)一日志層
fluentd隔斷數(shù)據(jù)源，從后臺系統(tǒng)提供統(tǒng)一日志層；
簡單靈活
提供了500多個插件，連接非常多的數(shù)據(jù)源和輸出源，內核簡單；
廣泛驗證
5000多家數(shù)據(jù)驅動公司以來Fluentd
最大的客戶通過它收集5萬多臺服務器的日志
**云原生**
是云原生CNCF的成員項目
4大優(yōu)勢：
統(tǒng)一JSON日志
fluentd嘗試采用JSON結構化數(shù)據(jù)，這就統(tǒng)一了所有處理日志數(shù)據(jù)的方面，收集，過濾，緩存，輸出日志到多目的地，下行流數(shù)據(jù)處理使用Json更簡單，因為它已經有足夠的訪問結構并保留了足夠靈活的scemas；
插件化架構
fluntd 有靈活的插件體系允許社區(qū)擴展功能，500多個社區(qū)貢獻的插件連接了很多數(shù)據(jù)源和目的地； 通過插件，你可以開始更好的使用你的日志
最小資源消耗
c和ruby寫的，需要極少的系統(tǒng)資源，40M左右的內存可以處理13k/時間/秒 ，如果你需要更緊湊的內存，可以使用Fluent bit ,更輕量的Fluentd
內核可靠
Fluentd支持內存和基于文件緩存，防止內部節(jié)點數(shù)據(jù)丟失；
也支持robust失敗并且可以配置高可用模式， 2000多家數(shù)據(jù)驅動公司在不同的產品中依賴Fluentd，更好的使用和理解他們的日志數(shù)據(jù)
使用fluentd的原因：
簡單靈活
10分鐘即可在你的電腦上安裝fluentd，你可以馬上下載它，500多個插件打通數(shù)據(jù)源和目的地，插件也很好開發(fā)和部署；
開源
**基于Apache2.0證書 完全開源 **
可靠高性能
5000多個數(shù)據(jù)驅動公司的不同產品和服務依賴fluentd，更好的使用和理解數(shù)據(jù)，實際上，基于datadog的調查，是使用docker運行的排行top7的技術；
一些fluentd用戶實時采集上千臺機器的數(shù)據(jù)，每個實例只需要40M左右的內存，伸縮的時候，你可以節(jié)省很多內存
社區(qū)
fluentd可以改進軟件并幫助其它人更好的使用
大公司使用背書： 微軟 ， 亞馬遜； pptv ;
可以結合elasticSearch + kibana來一起組成日志套件；
快速搭建EFK集群并收集應用的日志，配置性能排行榜；
elasticsearch
Elasticsearch 是一個分布式、RESTful 風格的搜索和數(shù)據(jù)分析引擎，
能夠解決不斷涌現(xiàn)出的各種用例。 作為 Elastic Stack 的核心，
它集中存儲您的數(shù)據(jù)，幫助您發(fā)現(xiàn)意料之中以及意料之外的情況。
詳細介紹：https://www./guide/cn/elasticsearch/guide/current/foreword_id.html
kibana
Kibana 是一款開源的數(shù)據(jù)分析和可視化平臺，它是 Elastic Stack 成員之一，
設計用于和 Elasticsearch 協(xié)作。您可以使用 Kibana 對 Elasticsearch 索引中的數(shù)據(jù)進行搜索、
查看、交互操作。您可以很方便的利用圖表、表格及地圖對數(shù)據(jù)進行多元化的分析和呈現(xiàn)。
Kibana 可以使大數(shù)據(jù)通俗易懂。它很簡單，
基于瀏覽器的界面便于您快速創(chuàng)建和分享動態(tài)數(shù)據(jù)儀表板來追蹤 Elasticsearch 的實時數(shù)據(jù)變化.
詳細介紹：https://www./guide/cn/kibana/current/introduction.html
容器化EFK實現(xiàn)路徑
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環(huán)境中沒有搭建成功，后續(xù)搭建成功了再出詳細的安裝筆記。
小結
一句話概括本篇：EFK是一種通過日志代理客戶端采集應用日志比較常用的實現(xiàn)方式。
原創(chuàng)不易，關注誠可貴，轉發(fā)價更高！轉載請注明出處，讓我們互通有無，共同進步，歡迎溝通交流。
|
