不少企業內部都有本身的ElasticSearch集羣,咱們沒有必要在kubernetes集羣內部再部署一個,並且這樣還難於管理,所以咱們考慮在容器裏部署logstash收集日誌到已有的ElasticSearch集羣中。git
Kubernetes官方提供了EFK的日誌收集解決方案,可是這種方案並不適合全部的業務場景,它自己就有一些侷限性,例如:github
基於以上幾個緣由,咱們決定使用本身的ELK集羣。web
Kubernetes集羣中的日誌收集解決方案docker
編號 | 方案 | 優勢 | 缺點 |
---|---|---|---|
1 | 每一個app的鏡像中都集成日誌收集組件 | 部署方便,kubernetes的yaml文件無須特別配置,能夠爲每一個app自定義日誌收集配置 | 強耦合,不方便應用和日誌收集組件升級和維護且會致使鏡像過大 |
2 | 單首創建一個日誌收集組件跟app的容器一塊兒運行在同一個pod中 | 低耦合,擴展性強,方便維護和升級 | 須要對kubernetes的yaml文件進行單獨配置,略顯繁瑣 |
3 | 將全部的Pod的日誌都掛載到宿主機上,每臺主機上單獨起一個日誌收集Pod | 徹底解耦,性能最高,管理起來最方便 | 須要統一日誌收集規則,目錄和輸出方式 |
綜合以上優缺點,咱們選擇使用方案二。api
該方案在擴展性、個性化、部署和後期維護方面都能作到均衡,所以選擇該方案。app
咱們建立了本身的logstash鏡像。建立過程和使用方式見https://github.com/rootsongjc/docker-images工具
鏡像地址:index.tenxcloud.com/jimmy/logstash:5.3.0
性能
咱們部署一個應用對logstash的日誌收集功能進行測試。測試
建立應用yaml文件logstash-test.yaml
。ui
apiVersion: extensions/v1beta1 kind: Deployment metadata: name: logstash-test namespace: default spec: replicas: 3 template: metadata: labels: k8s-app: logstash-test spec: containers: - image: sz-pg-oam-docker-hub-001.tendcloud.com/library/logstash:5.3.0 name: logstash resources: requests: cpu: 100m memory: 500M volumeMounts: - name: app-logs mountPath: /log env: - name: LogFile value: '["/log/*","/log/usermange/common/*"]' - name: ES_SERVER value: 172.23.5.255:9200 - name: INDICES value: logstash-docker - name: CODEC value: plain - image: sz-pg-oam-docker-hub-001.tendcloud.com/library/analytics-docker-test:Build_8 name : app volumeMounts: - name: app-logs mountPath: /usr/local/TalkingData/logs volumes: - name: app-logs emptyDir: {}
注意事項
/usr/local/TalkingData/logs
目錄掛載到logstash的/log
目錄下。manifests/test/logstash-test.yaml
找到。建立應用
部署Deployment
kubectl create -f logstash-test.yaml
查看http://172.23.5.255:9200/_cat/indices
將能夠看到列表有這樣的indices:
green open logstash-docker-2017.05.16 VkFWx3b_Ss6n4keDmXm-TQ 5 1 2078 0 1.6mb 795.3kb
訪問Kibana的web頁面,查看logstash-docker-2017.05.16
的索引,能夠看到logstash收集到了app日誌。