ITSM運維監控解決方案介紹和運維繫統需求

天府雲創發表於2017-06-06
運維

一、日常巡檢


1、每個維護點按天進行日常巡檢，巡檢內容按基礎巡檢表單進行填寫。巡檢表單在系統中可以按維護點維護內容不同進行靈活配置。

 

2、巡檢預警：每天各維護點定時巡檢時間點，超過時間點巡檢內容沒有上傳時則關閉當天的上傳功能，將沒有上傳的資訊通知相關主管，並做為維護點當天考核內容進行考核。

 

3、月度服務總結報表：配置月度服務表單，維護點按時間點填寫月度服務總結報表單。可以按月度報表生成對維護點及維護人員的當月考核結果。

 

4、維護表單統計功能：各維護點的維護表單按月進行統計分析，做為對維護人員當月的考核分析。

 

二、故障處理

 

1、故障提交：系統發生故障後維護人員根據故障表單及時填寫故障表單內容，提交服務支援中心，並能夠提示相應的人員。

 

2、故障分析：服務中心接到提交的問題單，要組織相應人員對問題單中描述的問題進行分析研判，確定問題的型別(技術問題、業務問題或者操作問題)。屬於技術問題，提交服務中心技術人員對存在的問題提出具體的處理意見和建議；屬於業務問題，提交服務中心業務員進行處理；屬於操作問題，可安排相關人員對問題提出人進行解釋，並將系統缺陷類問題提交單轉為系統諮詢類問題提交單。

 

3、故障確認、解決：服務中心的技術人員和業務人員收到系統缺陷類問題提交單後，對提交的問題進行歸類彙總和分析、確認。可以解決的，明確問題解決的具體處理建議和措施，經主管領導簽字同意後，交實施人員進行解決方案的實施。服務人員確認是否解決，並將解決方法提交至知識庫模組。

 

4、故障回覆：問題解決後及時向問題提交單位或問題交辦單位作出回覆，並將分析過程和問題產生原因一併提交。

 

三、裝置資源管理

針對中心裝置資源進行賬目管理，包括計算機裝置、網路裝置、一卡通終端裝置、耗材、配件等，包括編碼、名稱、位置、負責人、採購日期、登記時間、安裝使用時間、狀態等。——it資產管理

 

四、知識庫

 

運維知識庫是IT服務商進行運維工作的重要資源。故障處理後所有的解決方式必須提交至知識庫中。——統一資訊共享平臺

 

五、績效管理


自動從服務過程中採集績效資料，可幫助管理者可從以下幾個方面進行人員績效分析：其一、分析物件從專案、部門、崗位到個人；其二、考核指標從滿意度、工作量。


直接上乾貨《IT運維監控解決方案介紹》

現狀

•小公司/ 創業團隊< 500臺伺服器規模

開源方案：Zabbix、Nagios、Cacti…

雲服務提供商：監控寶、oneAlert等

•BAT級別> 10萬臺伺服器

投入大量的人力，內部自研，與業務嚴重耦合沒法作為產品推出

•中間階層

無從可選

 

早期，選用Zabbix

•Zabbix是一款開源的企業級監控系統

•對其進行二次開發、封裝、調優...

•為什麼選擇Zabbix

•Cacti

•Collectd

•RRDtool

•Nagios

•openTSDB

 

Zabbix實踐思路

•測試ZabbixNode

•Zabbix程式碼優化

•使用模式優化

•獨立部署多套Zabbix，通過API整合

 

Zabbix遇到的問題

•隨著公司業務規模的快速發展

•使用者“使用效率”低下，學習成本很高

•不具備水平擴充套件能力，無法支撐業務需求

•告警策略的維護、變更代價太大，導致運維人員深陷其中，無法自拔

•不利於自動化，不利於與運維平臺等基礎設施整合

------------------------------------------------------------------------------------------------

Open-Falcon

Open-Falcon是小米運維團隊設計開發的一款網際網路企業級監控系統

•提供最好用、最人性化的網際網路企業級監控解決方案

•專案主頁：http://open-falcon.com

•Github: https://github.com/xiaomi/open-falcon

•QQ討論組：373249123

•微信公眾號：OpenFalcon

 

社群貢獻

•交換機監控

•https://github.com/gaochao1/swcollector

•Windows監控

https://github.com/freedomkk-qfeng/falcon-scripts/tree/master/windows_collect

•Agent當機監控

https://github.com/freedomkk-qfeng/falcon-scripts/tree/master/agent_monitor

•Redis/memcached/rabbitmq監控

https://github.com/iambocai/falcon-monit-scripts

•MySQL 監控方案

https://github.com/open-falcon/mymon

 

典型案例

美團

•生產環境廣泛應用，1萬+agent

•整合服務樹、支援ping監控、多機房架構支援、報警第二接收人支援

•正在開發openTSDB介面、query增加正則功能

趕集

•深度定製，用於大資料部門平臺服務監控與自動運維，生產環境已上線

京東金融

•深度調研open-falcon

•正在開發測試drrs（一種分散式的time series data 儲存元件）並適配falcon

 

內部 

image

agent 
•負責機器資料採集 
•自發現各項監控指標 
•傳送資料給transfer 
•傳送心跳資訊給hbs 
•執行自定義外掛 
•業務資料不要用外掛採集！ 
•資料收集採用推還是拉的方式？ 

transfer 
•對接收到的資料做合法性校驗 
•轉發資料給graph和judge 
•為什麼要做這個統一的接入端？ 
•為什麼要對資料做分片？ 
•資料分片方案，用一致性hash還是路由表？

judge 
•對接收到的資料按照閾值進行判定 
•達到閾值的資料產生相應的event 
•觸發式判定or 輪詢？ 
•為什麼要使用記憶體？

graph 
•操作rrd檔案，對資料進行儲存和查詢 
•將多次操作合併後再flush磁碟 
•將要flush到磁碟的資料，打散到每個時間片，降低IO消耗 
•為什麼用rrd而不是opentsdb之類的？

hbs 
•提供介面給agent查詢機器所需監控的埠、程式、要執行的外掛列表等資訊 
•接收agent彙報的狀態資訊並寫入資料庫 
•快取使用者配置的告警策略 
•為什麼要用hbs快取策略列表？

query

•利用一致性hash演算法，查詢多個graph的資料並匯聚 
•需要使用與transfer相同的hash演算法及配置

各web端 
•Dashboard負責繪圖、展示、儀表盤等 
•Uic負責管理組合人的對應關係 
•Alarm-dashboard負責展示當前未恢復的告警 
•使用者在portal中配置告警策略 
•Portal中的hostgroup一般是從CMDB中同步過來的！

Aggregator 
目標：叢集監控 
•針對某個hostgroup的多個counter進行計算 
•分子：$(c1) + $(c2) -$(c3) 
•分母：可以是$# 或者數字或者$(d1) + $(d2) -$(d3) 
計算結果 
•封裝成一個metricItem，再次push回open-falcon 
為什麼這麼實現 
•歸一化的問題解決方案 
•複用整個open-falcon的繪圖展現、告警邏輯 

Gateway——跨資料中心

image

接駁服務樹（CMDB） 
•開源伺服器管理元件（服務樹） 
•監控物件通過服務樹來管理 
•伺服器進出節點、監控自動變更

歷史資料高可用 
rrd-on-hbase 
•繪圖資料儲存在hbase中，解決高可用的問題 
•歷史資料提供更詳細粒度的檢視 
drrs（@京東金融） 
•Distributed Round Robin Server 
•面向中心公司，輕量級的歷史資料儲存方案，解決資料擴容的問題

智慧告警 
同比、環比 
•Dashboard資料展示支援同比、環比 
•告警判定引入同比、環比作為參考 
動態閾值 
•通過對歷史資料的學習，生成動態的告警閾值 
關聯分析 
•精準告警 
•故障定位

SDK 
七層 
•Nginx 
•統計cps、200、5xx、4xx、latency、availability、throughput 
語言支援Java/C++/PHP/Python 
•內建統計每個介面的cps、latency 
•內建統計業務關注的指標的能力 
框架支援 
•resin、spring、flask… 
統計型別 
•Gauge/ Meter / Timer / Counter / Histogram

雲監控 
•服務端Host在公有云上 
•無需客戶安裝、運維服務端 
•支援namespace隔離、quota限額 
•從根本上對不同使用者的資料進行隔離 
•優化監控的新增、管理、檢視流程 
•提升使用者體驗、提高使用者使用效率

其他 
•Callback功能增強，推進故障自動處理 
•外掛的管理支援多種方式（不僅限於git） 
•Dashboard 增加使用者登入認證 
•告警排班/ 告警升級（@金山雲）


Open-Falcon部署實踐 
•初始階段 
•所有的元件部署在一臺物理機上即可 
機器量級~ 500 
•graph、judge、transfer三個元件拆分出來部署在1臺伺服器上 
機器量級~ 1000 
•graph、judge、transfer 增加到2~3個例項 
•query拆分出來，部署2個例項 
•dashboard 拆分出來部署 
機器量級~ 10K 
•graph、judge、transfer 增加到20個例項，graph儘量使用ssd磁碟 
•query增加到5個例項 
•dashboard 拆分出來，增加到3個例項

 

希望對您運維管理有幫助。

以上內容部分來自網路， 希望對您系統架構設計，軟體研發有幫助。 其它您可能感興趣的文章： 

構建高效的研發與自動化運維 
網際網路資料庫架構設計思路 
移動開發一站式解決方案 
某大型電商雲平臺實踐 
企業級應用架構模式N-Tier多層架構 
某企業社交應用網路拓撲架構圖 
IT基礎架構規劃方案一(網路系統規劃) 
餐飲連鎖公司IT資訊化解決方案一 

如有想了解更多軟體研發 , 系統 IT整合 , 企業資訊化，專案管理 等資訊，請關注我的微信訂閱號：


相關文章