-
1 # 急速馬力快de原始碼控
-
2 # Docker進擊之路
每個人由於所在的行業、公司、業務、崗位不同，對監控的理解也不盡相同，但是我們需要注意，監控是需要站在公司的業務角度去考慮，而不是針對某個監控技術的使用。
對系統不間斷的實時監控：實際上是對系統不間斷的實時監控(這就是監控)；
實時反饋系統當前狀態：我們監控某個硬體、或者某個系統，都是需要能實時看到當前系統的狀態，是正常、異常、或者故障。
保證服務可靠性安全性：我們監控的目的就是要保證系統、服務、業務正常執行
保證業務持續穩定執行：如果我們的監控做得很完善，即使出現故障，能第一時間接收到故障報警，在第一時間處理解決，從而保證業務持續性的穩定執行。
針對以上目標大多數開源監控系統都已經很不錯了，Zabbix是一個分散式監控系統，支援多種採集方式和採集客戶端，有專用的Agent代理，也支援SNMP、IPMI、JMX、Telnet、SSH等多種協議，它將採集到的資料存放到資料庫，然後對其進行分析整理，達到條件觸發告警。其靈活的擴充套件性和豐富的功能是其他監控系統所不能比的。相對來說，它的總體功能做得非常優秀。各種監控系統的對比來看，Zabbix都是具有優勢的，其豐富的功能、可擴充套件的能力、二次開發的能力和簡單易用的特點，讀者只要稍加學習，即可構建自己的監控系統。
另外最近兩年小米的openfalcon，prometheus也逐漸成熟可以在自動化監控中嘗試。
-
3 # 木訥大叔愛運維
你好,很高興回答你這個問題。作為運維工程師，非常理解你的這個問題，我們也希望透過監控的自動化來提高運維的效率，把更多的精力放到業務上；但是這需要各子系統及流程的配合，才能達到更好的效果。換句話說就是運維自動化不是孤立的，必須依賴上下游系統，基於規範和流程才能完成。
下面咱們來舉個簡單場景來分析下吧。
需求:產品部門需要上線一個業務子系統。
運維需要的工作主要為以下三步：
1.上架新的伺服器或虛擬機器；
2.業務子系統部署上線；
3.上線完成後新增監控；
以上三步中涉及到監控系統的有：
1.上架的新機器的自動錄入到監控系統,進行統一納管；
2.對錄入機器及業務系統需要從幾個維度的監控:硬體監控、基礎狀態監控、應用監控、業務日誌監控、流量監控；
3.與監控平臺聯動的平臺也要及時進行資料更新；
對於運維監控自動化來說，我們需要從以上幾個維度出發去考慮如何實現自動化。無論是從哪個維度出發，必須都要有一套自動化指令碼或模板去統一實現，因此我們需要制定規範去配合指令碼或模板的自動化執行，才能順利完成。如果監控系統依賴其他上下游平臺，在自動化過程中還要聯動其他平臺。
總結
透過以上的描述，如果我們在各個監控維度，有統一的規範、統一的模板、完善的流程以及各個平臺的API（或統一的ESb），那麼我們肯定是能夠實現自動化的。當然監控系統的自動化遠不止於此，例如故障自愈、智慧監控等，現在很多大廠也都已經實現。但我覺得無論多麼高大上，都需要打好基礎。
-
4 # 影視家大咖
結合現在雲計算和DevOps的發展趨勢，實現自動化運維監控，100%可以實現的。
這個先要看你個人還是公司提出問題的，可以結合自身需要適當權衡選擇
1.藉助第三方現有的運維監控整合
2.自主研發，適合成本不高的
3.合作
4.雲伺服器監控
5.資金充足，不缺錢，買伺服器自主架構研發
最後在你做決定前，先計算下成本，已有的資源是否可行，成本估算及風險。
-
5 # 小趙搞IT
運維監控大致可以分為以下幾個大類：
1、伺服器資源監控(CPU，記憶體,磁碟)
2、網路質量監控(延時，丟包，流量)
3、業務監控(埠，程序，api介面)
4、內容監控(某個頁面響應時間, 某個頁面的關鍵字等)
5、資料庫監控(資料庫相關的效能引數監控)
6、自定義監控(比如日誌監控等)
如果是把 現有的一些監控項做自動化，那是可以的。
我以 zabbix 為例子，把固定的一些監控項做成模板，新伺服器可以實現自動註冊，自動新增監控項。
但是如果要完全自動化，那比較困難，因為在實際工作中經常會有一些新需求，這些都是需要先手工進行配置的。
-
6 # 徐三刀gg
剛好有這個東西，這是一個適合快速安裝，易用，輕量級的運維監控工具——WGCLOUD監控系統
屬於伺服器效能監控視覺化類專案，在github上star數量2.2K，碼雲star數量600左右
和zabbix不同，WGCLOUD這款工具的特點初衷就是輕量，易用，無模板，無指令碼，安裝後不用特別配置，預設啟動後就開始全自動監控，不用費勁到處找資料，再學習培訓啦
輕量並不代表它功能簡單，WGCLOUD支援主機各種指標監控(cpu/溫度，記憶體，硬碟空間/IO，系統負載，網路流量，硬體資訊等)，資料監控視覺化，大屏展示，API介面檢測，docker監控，公眾看板服務，自動生成網路拓撲圖，埠監控，日誌監控，告警資訊推送（預設郵件，可整合釘釘微信簡訊等）
WGCLOUD服務端基於輕量級springboot架構，採集端基於go，是高效能高併發的分散式監控系統。也有商業版本，當然商業版也有免費版本，免費版對我們中小企業足夠用，可以應對平時使用場景，即使突發情況也可以
WGCLOUD可以做到秒級監控，採集端每隔30秒掃描一次主機狀態，然後上報給server端
以下是WGCLOUD部分功能截圖
-
7 # 果果張415
當然可以，相信大家都走過人肉運維的痛苦階段，儘管運維工程師 7*24 輪班待命，但客戶仍然投訴不斷，系統問題不斷。雲幫手透過監控報警功能，將故障的平均發現時間從 1 小時縮短到1分鐘，讓運維可以在故障發生前，提前預警並採取行動，並實現無人值守監控全過程。
回覆列表
一個非常好的問題。運維監控能夠實現自動化，而且建議實現自動化。
雲服務已經成為IT技術的核心基礎設施，充分利用雲服務帶來的彈性和分散式優勢，賦能自動化運維。
一，自動化部署CI/CD持續化整合和自動化部署，比如常用的Jenkins，配置Git程式碼提交時觸發構建，然後自動部署。
二，Docker容器技術Docker將應用以及依賴打包到一個可移植的映象中，可以實現虛擬化，有助於快捷高效的交付應用。
搭建阿里雲容器映象服務+Git+Docker自動構建系統，結合資源編排服務，實現自動部署更新，不再需要常用的Jenkins構建伺服器。
三，AutoScaling自動伸縮配置一定的觸發條件，滿足時自動增加或者釋放伺服器資源。比如當CPU使用率達到80%或者記憶體佔用率達到80%時，根據配置好的伺服器和數量，自動觸發。
四，系統日誌收集處理系統1，ELK是常見的日誌收集管理系統，包括ElasticSearch, LogStash, Kibana三個服務，架構示意圖如下：
2，在ELK系統中，Kibana是一個圖形化展示工具，配置查詢條件，運維人員隨時可以搜尋指定日誌資訊，分析處理故障。
五，服務監控1，雲監控CloudMonitor
主流雲服務商都將監控功能整合到了基礎架構中，以阿里云為例，雲監控提供了多種配置，多維度全方位監控。
比如配置CPU使用率到達80%時，自動觸發動作，增加伺服器例項，同時郵件通知運維人員。
2，應用監控
以監控寶為例，配置服務地址，選擇分佈在不同地區和運營商的監測點。當監測點不能正常呼叫配置的服務地址時，將收到警告資訊，可以選擇郵件、簡訊、電話等通知方式。
六，雲原生雲原生是指從開始設計應用時，就充分考慮並且利用雲服務的特點，比如彈性和分散式，可以簡單的理解為：雲原生 = 微服務 + DevOps + 持續交付 + 容器化。
在雲原生應用系統裡，運營、維護和監控，完全是自動化的。