無監控，不運維

監控系統俗稱「第三隻眼「，正所謂【無監控，不運維】，監控系統的地位不言而喻。沒有了監控，不管什麼基礎運維、業務運維都是「瞎子」。

監控系統的作用：

監控問題：有沒有做監控？監控是否及時？監控資訊是否有助於快速定位問題？

如何使用監控系統：

監控物件

硬體監控

包括：電源狀態、cpu狀態、機器溫度、風扇狀態、物理磁碟、raid狀態、記憶體狀態、網絡卡狀態

伺服器基礎監控

cpu：單個cpu以及整體的使用情況

記憶體：已用記憶體、可用記憶體

磁碟：磁碟使用率、磁碟讀寫的吞吐量

網路：出口流量、入口流量、tcp連線狀態

資料庫監控

包括：資料庫連線數、qps、tps、並行處理的會話數、快取命中率、主從延時、鎖狀態、慢查詢

中介軟體監控

nginx：活躍連線數、等待連線數、丟棄連線數、請求量、耗時、5xx錯誤率

tomcat：最大執行緒數、當前執行緒數、請求量、耗時、錯誤量、堆記憶體使用情況、gc次數和耗時

快取 ：成功連線數、阻塞連線數、已使用記憶體、記憶體碎片率、請求量、耗時、快取命中率

訊息佇列：連線數、佇列數、生產速率、消費速率、訊息堆積量

應用監控

http介面：url存活、請求量、耗時、異常量

rpc介面：請求量、耗時、超時量、拒絕量

jvm ：gc次數、gc耗時、各個記憶體區域的大小、當前執行緒數、死鎖執行緒數

執行緒池：活躍執行緒數、任務佇列大小、任務執行耗時、拒絕任務數

連線池：總連線數、活躍連線數

日誌監控：訪問日誌、錯誤日誌

業務指標：視業務來定，比如pv、訂單量等

監控的基本流程：

主流監控優劣勢

zabbix 的優勢：

產品成熟：由於誕生時間長且使用廣泛，擁有豐富的文件資料以及各種開源的資料採集外掛程式，能覆蓋絕大部分監控場景。

採集方式豐富：支援agent、snmp、jmx、ssh等多種採集方式，以及主動和被動的資料傳輸方式。

較強的擴充套件性：支援proxy分布式監控，有agent自動發現功能，外掛程式式架構支援使用者自定義資料採集指令碼。

配置管理方便：能通過web介面進行監控和告警配置，操作方便，上手簡單。

zabbix 的劣勢：

效能瓶頸：機器量或者業務量大了後，關係型資料庫的寫入一定是瓶頸，官方給出的單機上限是5000臺，個人感覺達不到，尤其現在應用層的指標越來越多。雖然最新版已經開始支援時序資料庫，不過成熟度還不高。

應用層監控支援有限：如果想對應用程式做侵入式的埋點和採集（比如監控執行緒池或者介面效能），zabbix沒有提供對應的sdk，通過外掛程式式的指令碼也能曲線實現此功能，個人感覺zabbix就不是做這個事的。

資料模型不強大：不支援tag，因此沒法按多維度進行聚合統計和告警配置，使用起來不靈活。

好吧，我目前就只用過zabbix，，，，，，

無監控，不運維 解讀企業全棧式監控運

企業應用由單體應用系統向分布式系統的發展趨勢已經不可逆轉。十年前 soa 大頻率的出現在軟體系統招標技術架構要求書中，相信用不了多久 微服務架構 也會被頻繁提及 分布式系統將成為主流。01為什麼分布式系統會 火 因為業務應用隨著自身功能的複雜化 應用間更頻繁的相互呼叫以及使用者數的不斷增長等諸多因素...

監控與運維

監控神器 普羅公尺修斯prometheus elk elasticsearch logstash和kibana。一種很典型的mvc思想，模型持久層，檢視層和控制層。logstash擔任控制層的角色，負責蒐集和過濾資料。elasticsearch擔任資料持久層的角色，負責儲存資料。kibana擔任檢視...

01 運維監控

聽聞前輩所說，在監控不發達的時代，出行基本靠走，安全基本靠狗，那個時候沒有自動化監控的概念，都是人工盯著機器，進行輪班 每天上班第一件事情就是去巡視一下，看看各項軟體列印的資訊是否有異常，順便拿execl記錄一下。現在如今的企業中，運維就要負責成百上千臺的機器，傳統的方式依然不行，沒有高大上的方法是...