|
在過去的2年多的時間里，隨著在公司推進容器云，陸陸續(xù)續(xù)的和日志打了不少交道，在這里做一個總結(jié)： 為什么需要日志 日志如何接收與存儲 日志如何收集 日志收集客戶端分析 日志的標準化 日志報警 日志歸檔 其他問題 為什么需要日志 日志的作用我覺得有三點： 故障排錯 數(shù)據(jù)分析 業(yè)務審計 1，關(guān)于故障排錯，當線上發(fā)生異常，查看應用的錯誤日志、堆棧信息、代理層的訪問日志是非常有幫助的，不同級別的日志能夠很好的幫助我們定位到故障點，而訪問日志則能讓我們知道異常情況發(fā)生在哪個環(huán)節(jié)，是client到代理，還是代理到后端。這也是降低MTTD的一個很好的工具。 2，對日志數(shù)據(jù)的分析，一方面能協(xié)助分析問題、定位故障，另一方面還可以幫我們更好的了解系統(tǒng)運行狀態(tài)甚至是了解我們的用戶。比如基于HTTP狀態(tài)碼和響應時間可以分析出系統(tǒng)的穩(wěn)定性和性能狀況。而基于訪問日志的來源IP可以分析出用戶地域?qū)傩?、而基于日志量級的時間分布可以了解到系統(tǒng)和用戶的活躍時間范圍。 3，上面兩種多數(shù)是最近幾個月的熱數(shù)據(jù)，需要實時查看和分析，也有一部分需要保存的更久，以滿足合規(guī)、審計等的需求。比如有些備案就要求不同級別的日志保存不同的時長以備隨時調(diào)用查看。 日志的收集與存儲 在分布式系統(tǒng)中，眾多服務分散部署在成百上千臺甚至成千上萬臺服務器上，要想快速方便的實現(xiàn)上述的查找、分析和歸檔功能，就需要有一個集中的日志系統(tǒng)，通過日志收集器將各類日志進行統(tǒng)一匯總，存儲，這樣不僅能方便查找所有的日志，還有可能在眾多日志數(shù)據(jù)中挖掘到一些意想不到的關(guān)聯(lián)關(guān)系。 有了這個定位接下來就可以開始詳細的規(guī)劃了，首先是日志服務器的選型，有經(jīng)典的ELK，有商業(yè)的splunk，但我們并沒有采取上述兩種，splunk功能完全符合，但對大量級的日志而言成本偏高，ELK中的kibana也在高版本中開始商業(yè)化，這讓我們開始尋找替代方案，graylog便是一種。它的絕大多數(shù)功能都是免費的，并且性能優(yōu)越，上圖： graylog也采用Elasticsearch作為存儲和索引以保障性能，MongoDB用來存儲少量的自身配置信息，master-node模式具有很好的擴展性，UI上自帶的基礎查詢與分析功能比較實用且高效，支持LDAP、權(quán)限控制并有豐富的日志類型和標準（如syslog，GELF）并支持基于日志的報警。 在日志接收方面通常是網(wǎng)絡傳輸，可以是TCP也可以是UDP，在實際生產(chǎn)環(huán)境量級較大多數(shù)采用UDP，也可以通過MQ來消費日志。 不同日志有不同的收集方式，總結(jié)下來有如下幾種： 服務器系統(tǒng)日志、登錄日志可通過rsyslog傳輸?shù)浇y(tǒng)一服務器 $ head /etc/rsyslog.conf *.* @your-log-server-addr:port;RSYSLOG_SyslogProtocol23Format 1 2 訪問日志，如access.log這類文本，可經(jīng)過日志收集器傳輸 應用日志，可通過落地文本后，再經(jīng)過日志收集器傳輸；也可以直接經(jīng)網(wǎng)絡發(fā)送到日志服務器或消息隊列應用日志，可通過落地文本后，再經(jīng)過日志收集器傳輸；也可以直接經(jīng)網(wǎng)絡發(fā)送到日志服務器或消息隊列 docker日志，除了將日志掛載到宿主機上然后通過收集器傳輸之外，還可以在docker的配置中可設置不同logdriver將日志以不同渠道輸出，我不推薦如gelf這類driver，因為它雖然可以無縫對接日志平臺，但配置不靈活，如需變更還需要重啟docker daemon（默認情況下），而且在實際使用中發(fā)現(xiàn)gelf在性能上也存在問題。demo：docker日志，除了將日志掛載到宿主機上然后通過收集器傳輸之外，還可以在docker的配置中可設置不同logdriver將日志以不同渠道輸出，但我不推薦如gelf等driver，因為它雖然可以無縫對接日志平臺，但配置不靈活，如需變更還需要重啟docker daemon（默認情況下），而且在實際使用中發(fā)現(xiàn)性能上也存在問題，demo： docker版本要求在1.8以上。 $ docker --version Docker version 1.12.0, build 8eab29e 修改配置文件/usr/lib/systemd/system/docker.service ExecStart=/usr/bin/dockerd --storage-driver=overlay --graph=/data/dockerapp \ --log-driver=gelf \ --log-opt gelf-address=udp://xxx.com:9999 \ --log-opt tag=docker \ --log-opt env=pro \ --log-opt gelf-compression-type=gzip \ --log-opt gelf-compression-level=1 1 2 3 4 5 6 7 8 9 10 kubernetes，如果是在公有云如Google Cloud上面的Stackdriver Logging 日志收集器主要有： Logstash Filebeat Fluentd Fluent-bit Logstash功能強大，但性能消耗也大，相對比較重，更適合作為中間環(huán)節(jié)，elastic后來推出的Filebeat更適合，它的性能好且資源占用少。而Fluentd作為CNCF指定用品，在17年初用了一段時間，覺得性能不是很好，它基于磁盤或內(nèi)存的buffer優(yōu)化空間也非常有限，但隨著加入CNCF后市場占比更多，也推出了Fluent-bit消耗1/10的資源。 這些收集器可以以daemonset的方式部署，確保每個節(jié)點上有且只有一個實例在收集日志。 日志標準化 上述只能實現(xiàn)日志的收集、存儲和展示，但想要更好的分析，就需要用到日志標準化，對不同日志、不同類型做不同的管理。如為方便快速查找某個系統(tǒng)在過去一段時間的訪問質(zhì)量，對需要對代理層日志中的HTTP狀態(tài)碼做清晰明了的界定。對于應用程序我們在日志中的通用字段包含： 環(huán)境信息（如;dev,test,beta） 團隊信息（類似namespace） 應用名 時間戳 日志級別 為提高可擴展性，在應用日志和Nginx日志都以json格式輸出，這樣就省去如logstash等組件的加工環(huán)節(jié)，同時也可基于json中的字段對日志做處理，如生產(chǎn)環(huán)境下logLevel=debug級別的日志不做處理，對size過大的做截斷。 對訪問日志，可添加的就更多了，如： log-format-upstream: '{ "message":"$remote_addr $host $request_time $status", "remote_addr": "$remote_addr", "domain_name": "$host", "remote_user": "$remote_user", "http_tracker_id": "$http_tracker_id", "time_local": "$time_local", "request_proto": "$server_protocol", "request_path": "$request_uri","request_args": "$args","response_status":"$status","request_time":"$request_time","body_bytes_sent":"$body_bytes_sent","request_length":"$request_length", "http_referer":"$http_referer","http_user_agent": "$http_user_agent","upstream_addr":"$upstream_addr", "upstream_connect_header_response_time":"$upstream_connect_time $upstream_header_time $upstream_response_time","upstream_status":"$upstream_status","http_x_forwarded_for": "$http_x_forwarded_for" }' 1 2 3 4 5 6 7 8 但注意，在日志量級較大的情況下如果字段設置過多會對日志收集器有一些性能壓力。 日志報警 graylog自身支持對日志的報警，如某個域名\應用在某個時間段內(nèi)的錯誤日志數(shù)如果超過某個閾值就報警。 日志歸檔 graylog商業(yè)版自帶歸檔功能，如果自己做可以通過消息隊列將日志數(shù)據(jù)再存入到HDFS中一份。 總結(jié) 其他問題 日志依賴ES和Luence，后者對每個字段要求最大為32kb，超出的將不再保存?？梢栽O置ignore_above =256 對過大字段不做解析y，也可以在收集端過濾較大日志，如filebeat上設置：max_bytes = 327660 注意日志生成時間與日志存入時間的區(qū)分，避免組件或網(wǎng)絡故障后的日志時間顯示不準確。 關(guān)于日志標準化的推廣，可以對不同語言可以做不同的包，供開發(fā)團隊直接引用。 反思之前為了確保日志不隨著pod刪除而刪除，將日志文本化并掛載到宿主機上再做消費，這樣會導致2份IO，且違反12因子中的日志事件原則，當前完全基于docker的json-file日志消費目前已經(jīng)較為成熟，可以考慮直接使用該方案。 graylog對日志字段有一定的要求，除syslog外，其他應用入口比如必須包含“short_message”這樣的一個字段，這個不太友好。 參考： [1]:https://gist.github.com/StevenACoffman/4e267f0f60c8e7fcb3f77b9e504f3bd7 [2]:https://docs./v0.12/articles/kubernetes-fluentd --------------------- 作者：按時睡覺 來源：CSDN 原文：https://blog.csdn.net/weixin_43181696/article/details/84060710 版權(quán)聲明：本文為博主原創(chuàng)文章，轉(zhuǎn)載請附上博文鏈接！ |
|
|
