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