自動化運維技術(shù)討論之----運維監(jiān)控如何幫你提前發(fā)現(xiàn)故障（獲獎名單已公布-2013-7-31）

GB_juno

1，分享您在日常運維過程中是通過什么方式發(fā)現(xiàn)故障的？
開源cacti、zabbix、zenoss等開源軟件，還有用snmp做的一個破系統(tǒng)，一些比較簡單的腳本。
交換機用netflow做流量分析。另外機房里面還用了IBM的tivoli。通常都是每天巡檢時看看有沒有警告之類的，
另外就是被監(jiān)控系統(tǒng)發(fā)告警短信了（悲劇）。

2，針對目前使用的故障的預警和監(jiān)控機制，您有哪些優(yōu)化心得或建議，請分享一二？
有些東西軟件沒有的話就得自己寫腳本，但是預警和監(jiān)控肯定是要設置好規(guī)則，不然每天收到一大堆的監(jiān)控信息郵件就是個問題，會讓
人看都看不過來的。另外就是每天做好規(guī)劃的巡檢事務，有序的逐項檢查，不能忽視每一項，因為會出現(xiàn)一些以前完全沒有發(fā)生過問題
的系統(tǒng)出問題。最后就是寫好故障處理歷史，形成良好的故障處理記錄，以后一查就大概能直到是什么回事了。

gavindev

主題好像是說如何提前發(fā)現(xiàn)問題，感覺變成了監(jiān)控工具的討論了

osapub

回復 12# gavindev

監(jiān)控工具是提前發(fā)現(xiàn)故障的一種途徑，討論的會比較多，也歡迎提供其他方面的思路和經(jīng)驗分享:wink:


   

gavindev

個人感覺可以細分點討論的幾個方面，
信息的采集：采集哪些數(shù)據(jù)，采集方法
信息的記錄：是臨時報警用還是持久記錄在案
信息的后續(xù)處理：是展示成圖還是文本保存，是僅僅記錄，有需要去查看一下，還是能夠監(jiān)控閾值，超過則報警
告警方式：手機短信，QQ,還是郵件等，或者是人工
告警的實時性：是實時還是監(jiān)控10分鐘，5分鐘，1分鐘
也可以包括如何記錄處理記錄，
如何做到比用戶先發(fā)現(xiàn)問題，比業(yè)務方先發(fā)現(xiàn)問題

perpyy

用過cacti
上次下載過osa 看了一下大概是用python+php+shell腳本實現(xiàn)的吧?
既然用了python  為何前臺不直接用django之類框架的呢
我不懂php....只好舍棄了

send_linux

perpyy 發(fā)表于 2013-07-08 21:33
用過cacti
上次下載過osa 看了一下大概是用python+php+shell腳本實現(xiàn)的吧?
既然用了python  為何前臺不直 ...

@osapub  幫忙看看呢？

litao941

我也來湊湊熱鬧

分享您在日常運維過程中是通過什么方式發(fā)現(xiàn)故障的？
第一個問題說3點：

1. 監(jiān)控平臺（最能第一時間反映問題出在哪里，某個服務掛了，空間滿了……）

2. 日志及相關(guān)服務進程是否正常（通過錯誤日志、系統(tǒng)進程是否正常來著手，也是1的進化版，90%問題在這步能搞定）

3. 例如性能瓶頸引發(fā)的故障問題，從監(jiān)控和日志都可能無法獲取，業(yè)務邏輯復雜性，可能需要開發(fā)協(xié)同查問題，這是最麻煩的，處理時間 30min +

附一個處理故障流程圖：



針對目前使用的故障的預警和監(jiān)控機制，您有哪些優(yōu)化心得或建議，請分享一二？
第二個問題也說3點：

1. OSA 部署過，監(jiān)控配置的復雜性沒有做到更好的智能化（或者說自動化不夠），一般服務器上跑應用是必須的，模塊化的嵌入到
這些服務器上如純 web（nginx/apache+php) 的監(jiān)控， 數(shù)據(jù)庫緩存（redis/mongo/mysql……）監(jiān)控，目前這些監(jiān)控需要有一
個通用web api，用戶直接通過平臺來輸入一些信息即可添加成功，而不是手動的去增加文件之類，另外這些“插件”也不是很齊全。

2. 監(jiān)控的關(guān)聯(lián)性需要完善， 例如有三個站點要在監(jiān)控平臺上，涉及到的監(jiān)控服務多了，可能無法直接關(guān)聯(lián)，比如其中一個502，我們
需要更快的速度去發(fā)現(xiàn)是這個站點是 php 有問題，還是緩存有問題，又或者是數(shù)據(jù)庫問題。將同一個域名關(guān)聯(lián)到一個組，可以一眼望
盡。同樣，可以按不同服務來 group by。

3. 說一點建議，前面發(fā)現(xiàn)故障第二點有提到，90% 問題能在日志和進程中服務體現(xiàn)，如何集中快捷提取這些日志，針對出現(xiàn)過如
“error”、“warnning”關(guān)鍵字報警機制，希望能在OSA 中實現(xiàn)。

litao941

再補一下：監(jiān)控的方式不管是使用的agent 還是snmp，監(jiān)控工具不管是nagios、cacti、zabbix、還是osa，都是為了達到同樣的目的--->便于我們快速發(fā)現(xiàn)和定位故障。

osa 雖有不足，但只要去做，才有能做出好樣工具的希望，支持osa 開發(fā)者們！

qingduo04

1，分享您在日常運維過程中是通過什么方式發(fā)現(xiàn)故障的？
   主要原理是根部不同的監(jiān)控內(nèi)容采取不同的監(jiān)控方式進行監(jiān)控，主要有：
   1.數(shù)據(jù)庫級別的監(jiān)控，包含表空間、事務日志、數(shù)據(jù)庫連接正常與否，分區(qū)數(shù)據(jù)庫各分區(qū)連接正常與否，通過perl程序和java 進行監(jiān)控，出現(xiàn)異常或者達到閥值進行報警。
   2.針對windows主機、小型機、linux主機等進行python監(jiān)控，主要是監(jiān)控主機PING是否正常？小型機硬件報警？文件系統(tǒng)空間是否正常？相關(guān)的關(guān)鍵程序（核心程序）是否正常？ 通過配置進行閥值報警。
   3. 針對服務器等監(jiān)控，一般采用機房巡檢的方式，涉及到設備繁多、hp、ibm小型機、刀片、存儲等監(jiān)控。 。
2，針對目前使用的故障的預警和監(jiān)控機制，您有哪些優(yōu)化心得或建議，請分享一二？
   當前我們監(jiān)控系統(tǒng)對于前兩種比較好，但是機房巡檢這個有時候很耗費人力和物力，尤其是機房離辦公場所很遠的時候，耗費的更多了!
綜述現(xiàn)場監(jiān)控沒有采用開源的監(jiān)控軟件，比如osa等監(jiān)控，純屬是自己根據(jù)現(xiàn)場情況進行報警，當然需要報警的內(nèi)容應該還遠遠不夠，比如存儲鏈路等，還請各位大俠互享一下監(jiān)控方式，讓我們能學習一下。謝謝

qingduo04

回復 19# qingduo04


    再補充一下，前兩種有短信報警和平臺報警，后一種純屬人工報警。