今天小編就為大家?guī)硪黄獰o代碼制作實時監(jiān)控預(yù)警系統(tǒng)的文章。小編覺得挺不錯的，為此分享給大家做個參考。一起跟隨小編過來看看吧。

創(chuàng)新互聯(lián)公司服務(wù)項目包括鎮(zhèn)江網(wǎng)站建設(shè)、鎮(zhèn)江網(wǎng)站制作、鎮(zhèn)江網(wǎng)頁制作以及鎮(zhèn)江網(wǎng)絡(luò)營銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢、行業(yè)經(jīng)驗、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，鎮(zhèn)江網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到鎮(zhèn)江省份的部分城市，未來相信會繼續(xù)擴大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！

為什么要做監(jiān)控

線上發(fā)布了服務(wù)，怎么知道它一切正常，比如發(fā)布5臺服務(wù)器，如何直觀了解是否有請求進來，訪問一切正常。
當(dāng)年有一次將線上的庫配置到了Beta，這么低級的錯誤，排錯花了一個通宵，十幾個人。
某個核心服務(wù)掛了，導(dǎo)致大量報錯，如何確定到底是哪里出了問題。
SOA帶來的問題，調(diào)用XX服務(wù)出問題，很慢，是否可以衡量？

由于業(yè)務(wù)系統(tǒng)數(shù)量大，每天都會產(chǎn)生大量的系統(tǒng)日志和業(yè)務(wù)日志，單流式業(yè)務(wù)的一臺服務(wù)器產(chǎn)生的日志達400M 想直接查看內(nèi)容打開可能幾分鐘，而且內(nèi)容之多根本無法查看，給開發(fā)和運維帶來諸多不便，現(xiàn)業(yè)務(wù)都是分布式的，日志也是分布在每臺服務(wù)器上，所以查看日志和統(tǒng)計更是效率低下。實時收集分布在不同節(jié)點或機器上的日志，供離線或在線查閱及分析來提升工作效率的需求異常迫切，在此背景下，特對公司統(tǒng)一日志平臺進行初步架構(gòu)設(shè)計。

在信息化時代，日志的價值是無窮的。為了對系統(tǒng)進行有效的監(jiān)控、維護、優(yōu)化、改進，都離不開對日志的收集和分析，接下來我們來看看秉著“短平快”的互聯(lián)網(wǎng)精神，構(gòu)建的這套適合現(xiàn)有業(yè)務(wù)系統(tǒng)的統(tǒng)一日志平臺，總體分為業(yè)務(wù)日志監(jiān)控平臺和軟硬件服務(wù)監(jiān)控平臺。

業(yè)務(wù)日志平臺總體設(shè)計

以上是最終的一個最終的一個架構(gòu)規(guī)劃，統(tǒng)一日志監(jiān)控系統(tǒng)負責(zé)將所有系統(tǒng)日志和業(yè)務(wù)日志集中，再通過flume或logstash上傳到日志中心(kafka集群)，然后供Storm、Spark及其它系統(tǒng)實時分析處理日志，或直接將日志持久化存儲到HDFS供離線數(shù)據(jù)分析處理，或?qū)懭隕lasticSearch提供數(shù)據(jù)查詢，或直接發(fā)起異常報警或提供指標(biāo)監(jiān)控查詢。

根據(jù)現(xiàn)有業(yè)務(wù)量來看，以上架構(gòu)有點“重”，可以作為以后的目標(biāo)，現(xiàn)階段來說可以參考以下架構(gòu)： 

      以上內(nèi)容皆以配置為主，對現(xiàn)有業(yè)務(wù)沒有影響，針對于Windows環(huán)境可以用FileBeat監(jiān)控本地日志全量、增量的上傳日志，對于一些穩(wěn)定的日志，比如系統(tǒng)日志或框架日志(如HAproxy訪問日志、系統(tǒng)異常日志等)，通過rsyslog寫到本地目錄local0，然后logstash根據(jù)其配置，會將local0中的增量日志上傳到日志中心。Java環(huán)境下可以采用log4j直接發(fā)送到Logstash。

日志處理層

可以在Logstash中對日志作簡單的分類加工處理再發(fā)送出去。

我們可以將日志聚合，根據(jù)業(yè)務(wù)不同，建立不同的索引，存入ElasticSearch提供查詢。 發(fā)現(xiàn)異常日志時，發(fā)往監(jiān)控中心，向?qū)?yīng)的業(yè)務(wù)方發(fā)起報警，發(fā)現(xiàn)和預(yù)發(fā)問題的實時性提高了。統(tǒng)計一些訪問日志或調(diào)用日志等指標(biāo)信息，發(fā)往監(jiān)控中心來掌握相關(guān)調(diào)用趨勢。調(diào)用鏈開始做起來了，系統(tǒng)性能瓶頸一目了然了。

日志存儲層

ElosticSearch中按照不同業(yè)務(wù)建索引主題（數(shù)據(jù)庫），業(yè)務(wù)里面再按照需求建類型（表），不需要的歷史數(shù)據(jù)可按需要持久化到HDFS，以減少ES的壓力。

展示層Kibana

Kibana是ELK中的組件，是一個針對Elasticsearch的開源分析及可視化平臺，用來搜索、查看交互存儲在Elasticsearch索引中的數(shù)據(jù)。使用Kibana，可以通過各種圖表進行高級數(shù)據(jù)分析及展示。

Kibana讓海量數(shù)據(jù)更容易理解。它操作簡單，基于瀏覽器的用戶界面可以快速創(chuàng)建儀表板（dashboard）實時顯示Elasticsearch查詢動態(tài)。

Kibana可以非常方便地把來自Logstash、ES-Hadoop、Beats或第三方技術(shù)的數(shù)據(jù)整合到Elasticsearch，支持的第三方技術(shù)包括Apache Flume、Fluentd等。

監(jiān)控ES的整體健康狀態(tài)

直接查詢ES索引內(nèi)容

簡單的查詢過濾日志數(shù)據(jù)窗口

可實時的圖形統(tǒng)計展示 

采用ElastAlert實現(xiàn)日志監(jiān)控告警

平臺缺失針對MySQL連接數(shù)的告警，指定業(yè)務(wù)如流式服務(wù)數(shù)據(jù)異常，當(dāng)異常觸發(fā)時能夠及時通過短信、郵件等方式通知相關(guān)負責(zé)人員 

如故障信息：

以上說的“日志”不僅限于日志信息，也可以是業(yè)務(wù)數(shù)據(jù)。

軟硬件服務(wù)監(jiān)控平臺設(shè)計

當(dāng)業(yè)務(wù)層日志發(fā)現(xiàn)異常時如保存數(shù)據(jù)到Mysql時經(jīng)常性報連接數(shù)據(jù)庫超時，只有當(dāng)業(yè)務(wù)人中發(fā)現(xiàn)再通知我們時已經(jīng)過了一段時間才發(fā)現(xiàn)問題，但已無法重現(xiàn)當(dāng)時的生產(chǎn)環(huán)境，也就靠經(jīng)驗來猜原因是服務(wù)器的網(wǎng)絡(luò)問題還是數(shù)據(jù)庫的真實連接滿了還是程序的寫法出現(xiàn)問題，因此就需要監(jiān)控當(dāng)時生產(chǎn)環(huán)境的軟硬件監(jiān)控數(shù)據(jù)。

經(jīng)過多方咨詢參考各大廠的監(jiān)控方案和對比在此采用Zabbix作監(jiān)控。

最近各服務(wù)整體問題一覽

針對Web服務(wù)器和API的訪問性能、HAproxy、IIS、Tomcat

實時繪圖監(jiān)控服務(wù)器所有TCP端口的數(shù)量和 MySql數(shù)據(jù)庫連接數(shù)、redis性能

自定義聚合展示服務(wù)器各指表最近的狀態(tài),CPU、內(nèi)存、流量。

顯示所有服務(wù)器的一個健康狀況，一目了然

自動注冊監(jiān)控新的服務(wù)器

報警機制，Email、微信、短信等

其它特性

可監(jiān)控Linux、Windows、打印機、文件系統(tǒng)、網(wǎng)卡設(shè)備、 SNMP OID、數(shù)據(jù)庫等平臺服務(wù)狀態(tài)。

允許靈活地自定義問題閥值， Zabbix 中稱為觸發(fā)器(trigger), 存儲在后端數(shù)據(jù)庫中。

高級告警配置，可以自定義告警升級(escalation)、接收者及告警方式。

數(shù)據(jù)存儲在數(shù)據(jù)庫中  歷史數(shù)據(jù)可配置 內(nèi)置數(shù)據(jù)清理機制。

web 前端采用 php 訪問無障礙。
Zabbix API 提供程序級別的訪問接口，第三方程序可以很快接入。

靈活的權(quán)限系統(tǒng)。

結(jié)合以上業(yè)務(wù)和軟硬件上的日志方便開發(fā)和運維實時查找問題提高解決問題的效率，而且前期均可只通過配置0代碼就可實現(xiàn)監(jiān)控和報表展示。

擴展性

可用Spark對數(shù)據(jù)實時分析，智能攔截異常數(shù)據(jù)和直接發(fā)送異常警報。

在Zabbix上結(jié)合自己的業(yè)務(wù)需求二次開發(fā)應(yīng)用系統(tǒng)層面上的預(yù)警監(jiān)控系統(tǒng)。

以后可加入Kafka將日志集中，至于為什么選用kafka集群來構(gòu)建日志中心，理由主要如下:

1、分布式架構(gòu)，可支持水平擴展。

2、高吞吐量，在普通的服務(wù)器上每秒鐘也能處理幾十萬條消息(遠高于我們的峰值1.5萬條/秒)。

3、消息持久化，按topic分區(qū)存儲，支持可重復(fù)消費。

4、可根據(jù)broker配置定期刪除過期數(shù)據(jù)。

以上就是無代碼制作實時監(jiān)控預(yù)警系統(tǒng)的具體步驟，內(nèi)容較為全面，而且我也相信有相當(dāng)?shù)囊恍┲R點可能是我們?nèi)粘９ぷ骺赡軙姷交蛴玫降?。通過這篇文章，希望你能收獲更多。

新聞名稱：無代碼制作實時監(jiān)控預(yù)警系統(tǒng)
地址分享：http://jinyejixie.com/article22/gpsejc.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供外貿(mào)建站、建站公司、網(wǎng)站制作、手機網(wǎng)站建設(shè)、網(wǎng)站設(shè)計公司、外貿(mào)網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)