Nginx有兩套日誌,一套access.log一套error.log,access.log用戶能夠自定義,兩套日誌處理好,業務的質量就瞭然於心了,另外,日誌關鍵指標可視化分析我認爲是運維中最重要的事情了,沒有之一。nginx
對於後期的可視化監控,核心觀點兩個字「收斂」,工具用grafana,把最有用的關鍵指標放到dashboard上,我線上設計的一個版面以下,因爲日誌量大,200 ok的日誌基本不看,因此結合filebeat只收集了一套異常日誌,異常日誌定義爲狀態碼非200或者響應時間大於0.5秒,裏面要考慮幾個點:api
一、要用日誌時間建es索引,便於分析排障;ruby
二、數據字段要轉化爲數據類型,便於計算;bash
三、Dashbord考慮質量、性能、錯誤3個維度內容;app
四、爲了方便聚合分析,url要把問號前的接口拆出來,好比/v1/feedback/check_regid_valid?regId=DmuZXBoN4nRulcjmZczGw1fZLya151h7%2BtY0%2FgoM6qwllq%2BR723oL8fK9Wahdxee&packageName=com.tencent.news&appId=2882303761517336368,拆成/v1/feedback/check_regid_valid,後面一堆參數可處理可不處理,後面會寫一下若是處理能夠繼續拆一下k/v;運維
五、grafana要動態可選業務類型、機房、機器、響應時間等信息,便於鑽取分析。dom
對於access.logelasticsearch
原始日誌以下(我用上撇作的分隔)ide
#access.log 10.132.10.29`api.xmpush.xiaomi.com`103.107.217.171`-`14/May/2019:00:00:01 +0800`/v1/feedback/check_regid_valid?regId=46quGCb9wT89VV2XzUW89bORMmralBlKriPnZbeAmIzF2nABHj LJKCI8%2FF0InyHR&packageName=com.smile.gifmaker&appId=2880376151713534`325`332`0.009`200`10.132.50.2:9085`-`0.009`GET`okhttp/3.12.1`200`lT666Qlxdq6G6iUqt/G3FrQ==
logstash清洗規則以下工具
filter { ruby { init => "@kname = ['server_addr','domain','remote_addr','http_x_forwarded_for','time_local','request_uri','request_length','bytes_sent','request_time','status','upstream_addr','upstream_cache_status','upstream_response_time','request_method','http_user_agent','upstream_status','key']" code => "event.append(Hash[@kname.zip(event['message'].split('`'))])" } #將api接口拆開 if [request_uri] { grok { match => ["request_uri","%{DATA:api}(\?%{DATA:args})?$"] } } #用日誌時間創建索引,把無用字段去掉 date { match => ["time_local", "dd/MMM/yyyy:HH:mm:ss Z"] target => "@timestamp" remove_field => ["time_local","message","path","offset","prospector","[fields][ttopic]","[beat][version]","[beat][name]"] } #把類型從字符型轉爲數字型 mutate { convert => [ "request_length" , "integer", "status" , "integer", "upstream_response_time" , "float", "request_time" , "float", "bytes_sent" , "integer" ] } } output { #再次判斷一下只收集處理異常日誌 if [status] != 200 or [request_time] > 1 { elasticsearch { hosts => ["1.1.1.1:9220","2.2.2.2:9220","3.3.3.3:9220"] #workers => 4 index => "logstash-im-push-mt-nginx-access-%{+YYYY.MM.dd.hh}" } } #某幾臺機器收集全量日誌,用於抽樣總體狀況瞭解 else if [beat][hostname] == 'c4-hostname01.bj' or [beat][hostname] == 'c4-hostname02.bj' { elasticsearch { hosts => ["1.1.1.1:9220","2.2.2.2:9220","3.3.3.3:9220"] #workers => 4 index => "logstash-im-push-mt-nginx-access-%{+YYYY.MM.dd.hh}" } } #stdout { codec => rubydebug } }
清洗後的一個截圖以下,知足需求
對於error.log
原始日誌以下
#error.log 有不少種,這裏只寫一條,後面正則會作所有匹配 2019/05/14 10:28:16 [error] 13655#0: *3199 connect() failed (111: Connection refused) while connecting to upstream, client: 47.111.97.155, server: api.xmpush.xiaomi.co m, request: "POST /v2/message/regid HTTP/1.1", upstream: "http://10.132.28.28:9085/v2/message/regid", host: "api.xmpush.xiaomi.com"
logstash清洗規則以下
#根據error日誌的規律,兩個正則覆蓋全部狀況,正則忘記從哪一個大神那取的經了,多謝,另外,爲了防止特殊狀況出現,我保留了原始msg filter { grok { match => [ "message", "(?<time>\d{4}/\d{2}/\d{2}\s{1,}\d{2}:\d{2}:\d{2})\s{1,}\[%{DATA:err_severity}\]\s{1,}(%{NUMBER:pid:int}#%{NUMBER}:\s{1,}\*%{NUMBER}|\*%{NUMBER}) %{DATA:err_message}(?:,\s{1,}client:\s{1,}(?<client_ip>%{IP}|%{HOSTNAME}))(?:,\s{1,}server:\s{1,}%{IPORHOST:server})(?:, request: %{QS:request})?(?:, host: %{QS:host})?(?:, referrer: \"%{URI:referrer})?", "message", "(?<time>\d{4}/\d{2}/\d{2}\s{1,}\d{2}:\d{2}:\d{2})\s{1,}\[%{DATA:err_severity}\]\s{1,}%{GREEDYDATA:err_message}"] } date{ match=>["time","yyyy/MM/dd HH:mm:ss"] target=>"@timestamp" remove_field => ["time_local","time","path","offset","prospector","[fields][ttopic]","[beat][version]","[beat][name]"] } }
清洗後的截圖以下
延伸配置
對於拆出來的args,若是業務上有須要分析的信息,要繼續將k/v分開,好比a=111&b=2222,拆到es裏a做爲key數字做爲value,能夠在logstash裏編寫以下配置
if [args] { #不少url是通過decode過的,亂碼不便於閱讀,咱們把它恢復 urldecode { field => "args" } #以&爲分隔符,將args的k/v分開 kv { source => "args" field_split => "&" } }
好了,但願能在這個基礎上,幫助你搭建本身的nginx可視化監控。
查看更多請到博主原創站:運維網咖社(www.net-add.com)