為什麼很多公司都自主開發監控系統？（Linux運維方面）
網上開源的監控系統cacti、Nagios、zabbix和其他商業系統，有什麼方面不滿足公司的需求？ 我看到網上說的監控粒度和深度，但這個不好理解，如果方便，可以列舉一些業務？
幾年前做運維開發的時候, 曾經主導或參與過大概30多個運維自動化的項目, 我覺得自己還算業界人.
你覺得換工作的時候說, xxx我用的挺好和我寫了個yyy代替了xxx更能讓hr, 領導認可你?
簡單地說就是有錢有人有時間. 不自己搞什麼是KPI? 不自己搞留著那些什麼神奇的運維架構師有什麼用? 什麼都用開源的, 那些領導們, 架構師們面子多過不去, HR, boss會覺得你有什麼用?看人家的tutorial/manual??
美其名曰 1. 這是和我們的業務接軌; 2. 我們自己的東西我們完全可控; 3. 說不定以後還能開源.
為什麼這麼多公司都有自己號稱xxx的項目, 但是基本沒有開源? 我想除了知識產權, 怕競爭對手知道自己並會鄙視自己. 還有2個重要的問題, 怕太low放出來被吐槽, 怕被人說抄襲了xxx的思想
額 說的再清楚點, 是他們讀不了nagios的源碼(運維達到c精通的太少了)
其實放出來, 也沒別人用
______________________________以上純屬負能量, 說點實際的, 我來舉例一些和監控有關的場景
1. 系統和公司的SSO(單點登錄, 簡單的理解就是用你公司的賬號登錄所有系統)怎麼結合, 如何靈活的控制用戶訪問許可權
2. 有很多業務項開源的項目沒有給你準備, 你只能定製. 比如你想監控下伺服器的負載趨勢(好吧你可以讓瀏覽器時常自動刷新nagios頁面), 用戶實時訪問數據(你的一個業務新上線，作為領導你很想讓大家讓你的boss一起看你帶來多大的流量增長吧?), 還有很多的你的業務指標, 而且最變態的, 可能這還和不同的產品線或者項目有關. 你給A項目的人順便展示B項目的數據, 你覺得A的人願意看? 3. 看過阿里雙十一的銷售額的大屏幕沒? 好, 我們也可以做一個, 監控所有的想要監控指標, 放在一個監控室, 24個屏幕放一起的大屏. 效果特別好. 本來想放個圖片, 想想還是算了. 沒經過老東家授權.4. 讓你的監控和你其他的系統結合. 比如出現某種故障, 你就會報警. 當然發個郵件簡訊啥的就算走自己的sms平台也就是個用nagios的被動檢查調介面的問題. 關鍵是, 有監控的時候要會讓系統自己處理- 誰都不希望夜裡2點收到報警簡訊, 然後必須起來看問題這種情況吧?1. 那好監控X出現了問題, 直接graceful的把它從負載均衡上移走. 早上再解決唄. 伺服器那麼多的, 閑的都生鏽了. 2. 監控X出現了問題, 直接切換到一個正常的相同的備用系統上繼續用. 還比如資產管理系統, 同步伺服器數據.5. 比如nagios監控, 我要用大量的被動檢查腳本檢查我的業務, 還經常變動, 有人得專門的負責改, 刪腳本. 非常折磨人6. 說道開源軟體, 他的報警誤報幾率好高, 等你登陸伺服器的時候可能問題早就過去了, 我們的監控系統會做系統截圖(額 不知道用什麼詞了), 對相關的數據都收集起來7. 說點好玩的, 比如你不在公司還沒有網, 你想看看什麼樣的監控指標, 直接發一些暗號的簡訊給某些號碼, 他就會返回給你當前數據
8. caicti的畫圖也太丑了, 你知道這個世界已經發展的很美好了么? 還是php, 幾個運維喜歡php等等吧, 都想不起來了. 每當要做什麼的時候, 我們都義憤填膺的, 因為他有特別多的原因讓我們op不滿意先佔個坑
首先如果僅僅是用於linux運維 也就是如果你的監控系統僅需要機器指標 那麼開源產品隨便用 反正就那麼十幾個到幾十個指標 你就算有十萬台伺服器 分鐘級監控 也還是可以毫無壓力搞定的，但是吧，很多時候還有監控伺服器上的進程，甚至還有些業務數據或者說是進程性能數據。這樣現有開源就有點費勁了。之前我們用opentsdb，然後發現數據每天3.5g，查詢聚合數據的時候很慢（因為opentsdb每次從磁碟撈數據）。實在忍不了了，重寫。現在每天500g，查詢秒級返回。各種報警自行支持。這就是我們寫的目的。只因為已有的滿足不了並且開源社區的發展速度跟不上公司需求的發展速度。
最後，文無第一的原則，程序員還是有點炫技傾向的。
當然，從私人角度講，重頭解決採集，聚合，存儲，同步，報警甚至是智能化，這個過程本身就是一次非常好的學習經歷。其實這個問題可以延伸到，為什麼很多公司都自主開發訂餐系統，很多公司都自主開發客戶管理系統，為什麼很多公司都打算自主開發運營監控系統？
除開生產力過勝，和可惡的 KPI 之外，我覺得還有一些其他重要原因吧。
很多答案里提到了當業務變得慢慢複雜起來，開源的、第三方的監控解決方案，不能滿足需求，我覺得說不通。拿一張圖來說話吧：
上圖來自一家分享和發現各 IT 公司使用什麼工具的網站：StackShare Discover and discuss the best dev tools and cloud infrastructure services
可以看到 Facebook 用了 Datadog 來做運維監控，Netflix 用了 Boundary 來做運維監控。
那麼，那麼多業務量巨大的公司，在監控這塊依舊使用 Datadog Boundary 這樣的第三方監控解決方案。
說明業務量大、邏輯複雜，根本不是要轉向自己來研發這些系統的原因。
那為什麼還要反覆地造輪子、造輪子、造輪子呢？以我這幾年的工作經歷說說吧。
領導是傻 X
我現在所從事的剛好是給企業提供第三方監控解決方案的工作。在跟很多企業提供解決方案的時候，項目實施到一半，可能在監控本身需要加入：
- 你們能不能順便把 IT 資產管理也給做了？
- 你們能不能幫我們做下整個園區的 3D 建模？
- 你們能不能按照我們的行政劃分，把每項監控事宜都落到個人頭上？
這就是樓上很多人提到的所謂業務複雜，本身業務不複雜，只是領導們的要求很複雜。管理本身存在很多問題，不能夠將一件大事情細分到每一項具體的事情上。而領導們覺得自己只需要考慮全局，中層幹部們也沒有理順領導的要求並拆分領導的要求。
工具能夠幫助我們將每項具體的事情變得更高效，但是解決不了實際情況中某個大的命題。
我一直堅信：工具是讓聰明人變得更高效，而不是讓傻 X 變得牛 X。
當上層領導只能按照行政、業績來劃分具體實施人員的工作時，運維的監控這件事情就可以擴大到一個漫無邊際的地步，並且和自己的行政劃分、規章制度高度耦合。
有情懷的程序員太少
就拿系統監控工具這件事情來說吧，國外有 Host Graphite、Boundary、Datadog 等等。國內除了小米的 Open-Falcon|互聯網企業級監控系統 和 OneAPM 的 Cloud Insight， 鮮少有一些真正易用的、開源的、產品化的工具，來幫助我們解決某項具體事情。
但是大公司內部，卻有很多人在幫助所在的公司做這些事情。但是沒有想過自己做一款產品是什麼樣的，也沒有思考過從頭開始經營一款自己的產品是啥樣的。
活在大公司里，盼望著過 KPI、期待著公司上市後期權可以兌現。
中國的開源和 SaaS 服務落後於國外，很大一部分原因是因為企業文化的差異和制度本身的問題吧。
總的來說，就是程序員們都在造輪子，而且輪子越造越大，可能只適合所在的企業。沒有想過自己的輪子，可以形成通用化的產品。
沒耐心
將一個產品吃透，按照這個產品的設計思路來指導自己的工作。我覺得比自己本身去研發一個產品效率要高很多啊。
打個不恰當的比方，設計師覺得 Photoshop 不好用，因為用鋼筆要練習，而且 Photoshop 本身也不能給自己拓寬視野和給風格帶來影響。所以決定要自己研發一個取代 Photoshop 並且更適合自己的產品。
也許還不適合自己公司在交接工作中的流程，行政部門打不開 PSD 文件，具體實施的人沒有要求換成 CMYK 就印刷了。
幸好大部分設計師不具備研發的能力，只好耐著性子去學習了。
其實很多工具在經過反覆的迭代和設計時，都透漏著設計者本身的一些方法論和思想在裡面。有些成熟工具不好用，或者很麻煩，其實可能是使用者本身的工作方式有問題。
最後做個廣告吧。之前提到我也是做系統監控工具服務的，我們有一款系統監控工具 Cloud Insight：安裝簡單、UI 美麗、未來會有再開發能力。愛用不用，不用拉到。啊哈哈，上幾張圖。
說一下 Cloud Insight 的產品規劃吧。我們正在做事件處理，有參考國外的 Bigpanda，主要方向是報警風暴的處理、事件的聚合，以及動態門限類與演算法有關的報警策略。
然後我們也用到了 OpenTSDB，架在了 HBase 上，負載還不錯。雖然在公測，但是每天處理的數據量還是挺大的。
至於行政和規章制度需要架在產品里，我指的不是報警需要分發到不同的人、並且選擇不同的渠道來分發。這些一般的第三方工具，和開源工具集成一些渠道，都可以做到。
我指的是，之前面對的企業客戶。可能老闆根本不需要看指標，老闆需要看機房裡每天機器是不是 DOWN 掉了，還需要很酷炫的 3D 建模。
而真正的實際操作人員，又需要到很具體很具體的指標，甚至每個單位都需要落實到產品里。
一個工具不可能自上而下地解決管理上的問題，我們的目標是通過一個像 JIRA 的工具來達到通用的、科學的管理，而不是把這個工具做到跟公司一些很腐化的制度綁定在一起。
就像有些公司項目管理做得很爛，JIRA 用不起來，所以去找國內一些軟體公司來做一個和自己制度高度耦合的項目管理軟體，並天真地以為可以解決問題。大多數情況如饒琛琳所言：「自己寫一個，說出去KPI漲分」，萬惡的KPI，到處造輪子，輪子造了一個又一個，管它好不好用呢，自己工資是漲上去了。另，國內人員想為開源產品做貢獻熱情還不高（養家糊口要緊），也不願意提PR（不能給KPI漲分），都願意神馬都自己寫，自己控制，自己說了算。實在不行還 Fork 出來一個自娛自樂呢。事實上，造輪子不是也不應該是你的核心競爭力，只不過在KPI和自己控制的思想影響下，畸形了，走偏了。
1 無法滿足內部細化需求 不方便與內部其他平台模塊數據通信並進行二次開發 不方便收集內部業務程序的上報數據
2 不方便根據部門需要自行配置各種奇葩告警策略 以及自動反制策略（比如log文件把磁碟打滿了程序可以自動清磁碟里沒用的log）
3 一些開源方案不方便自定義獨自感興趣的指標4 zabbix等開源方案性能不足 比如前面提到的zabbix用mysql存儲 被監控的機器數量和指標增加起來會很痛苦5 基於snmp的方案很多時候沒有自行編寫agent插件好使獨立實現一套適合自己公司監控系統也是非常不容易的 作為一個失敗者 含淚路過因為每個企業都有特定的運維環境和條件，需要做一些特定的運維計劃。
下面是我們跟學習社群夥伴的一個討論與Python自動化運維的應用。
現階段，掌握一門開發語言已經成為高級運維工程師的必備計能，不會開發，你就不能充分理解你們系統的業務流程，你就不能幫助調試、優化開發人開發的程序， 開發人員有的時候很少關注性能的問題，這些問題就得運維人員來做，一個業務上線了，導致 CPU 使用過高，內存佔用過大。
如果你不會開發，你可能只能查到進程級別，也就是哪個進程佔用這麼多，然後呢？然後就交給開發人員處理了，這樣咋體現你的價值？
另外，大一點的公司，伺服器都上幾百，上千，甚至數萬台，這種情況下怎樣做自動化運維？用 SHELL 寫腳本 FOR 循環？呵呵，歇了吧， SHELL 也就適合簡單的系統管理工作。到複雜的自動化任務還得要用專門的開發語言。你可能說了，自動化管理有專門的開源軟體＼監控也有，直接拿來用下就好了，但是現有的開源軟體如 puppetsaltstackzabbix
agio 多為通用的軟體，不可能完全適用你公司的所有需求，當你需要做定製、做二次開發的時候，你咋辦？找開發部門？開發部門不懂運維的實際業務邏輯，寫出來的東西爛爛不能用，這活最後還得交給運維開發人員來做。
其次，不會運維開發，你就不能自己寫運維平台＼複雜的運維工具，一切要藉助於找一些開源軟體拼拼湊湊，如果是這樣，那就請不要抱怨你的工資低，你的工作不受重視了。
那為什麼是Python?PYTHON 第一是個非常牛 B 的腳本語言， 能滿足絕大部分自動化運維的需求，又能做後端 C/S 架構，又能用 WEB 框架快速開發出高大上的 WEB 界面，只有當你自已有能力做出一套運維自動化系統的時候，你的價值才體現出來，你才有資格跟老闆談重視， 否則，還是老老實實回去裝機器吧。
下面我們來說說主要的幾個在Linux運維中的常用的一些應用：
第一、靜態文件伺服器
重點練習使用redux管理狀態.
前端api與後端交互、數據封裝、狀態變化等
第二、Python開發的jumpserver跳板機
jumpserver跳板機是一款由Python編寫開源的跳板機(堡壘機)系統，實現了跳板機應有的功能。基於ssh協議來管理，客戶端無需安裝agent。
企業主要用於解決：可視化安全管理
特點：完全開源，GPL授權
Python編寫，Django開發框架，容易再次開發
實現了跳板機基本功能：認證、授權、審計。集成了Ansible、批量命令等。功能強大。
通俗點就是起到監控誰在伺服器上做了什麼操作等。錄像回放、命令搜索、實時監控、批量上傳下載等。
第三：Python開發的Magedu分散式監控系統
以自動化運維視角為出發點，自動化功能、監控告警、性能調優，結合saltstack實現自動化配置管理等內容進行了全方位的深入剖析。
企業主要用於解決：自動化監控常用系統服務、應用、網路設備等。分散式可監控更多伺服器，分區域監控再匯總。Zabbix監控結合Python自定義監控腳本。
監控系統需求討論：
監控常用系統服務、應用、網路設備等？一台主機上可監控多個不同服務、不同服務的監控間隔可不同？同一個服務在不同主機上的監控間隔、報警閾值可不同？告警級別？數據可視化，如何做出簡潔美觀的用戶界面？如何實現單機支持5000+機器監控需求？採取何種通信方式？主動、被動？
第四：Python開發的Magedu的CMDB
cmdb的開發需要包含三部分功能：採集硬體數據、API、頁面管理。
企業主要用於解決：項目功能，採集硬體數據、Api、頁面管理。統計資產，例如伺服器存放位置，伺服器上的賬號等等。
執行服務的過程如下：伺服器的客戶端採集硬體數據，然後將硬體信息發送到API，API負責將獲取到的數據保存到資料庫中，後台管理程序負責對伺服器信息的配置和展示。
第五：Python開發的任務調度系統
Python任務調度系統的multiprocessing模塊不但支持多進程，其中managers子模塊還支持把多進程分布到多台機器上。
企業主要用於解決：通俗的理解，批量管理crontab定時任務。原理用戶通過web頁面設置任務，傳輸到任務調度系統伺服器上的客戶端，客戶端收集數據反饋給伺服器端，伺服器端根據任務具體內容調度後端的集群伺服器做定時任務。
一個服務進程可以作為調度者，將任務分布到其他多個機器的多個進程中，依靠網路通信。想到這，就在想是不是可以使用此模塊來實現一個簡單的作業調度系統。
第六：Python運維流程系統
使用python語言編寫的調度和監控工作流的平台內部用來創建、監控和調整數據管道。任何工作流都可以在這個使用Python來編寫的平台上運行。
企業主要用於解決：通俗點說就是規範運維的操作，加入審批，一步一步操作的概念。
是一種允許工作流開發人員輕鬆創建、維護和周期性地調度運行工作流（即有向無環圖或成為DAGs）的工具。這些工作流包括了如數據存儲、增長分析、Email發送、A/B測試等等這些跨越多部門的用例。
這個平台擁有和 Hive、Presto、MySQL、HDFS、Postgres和S3交互的能力，並且提供了鉤子使得系統擁有很好地擴展性。除了一個命令行界面，該工具還提供了一個基於Web的用戶界面讓您可以可視化管道的依賴關係、監控進度、觸發任務等。
來個小總結
幾個實戰項目之間的結合，可以理解成，運維流程系統，就是規範運維的每一步操作，審批通過後，通過調用任務調度系統來定製批量操作。任務調度系統操作的過程中，可以通過CMDB資產管理系統來獲取伺服器的詳細信息，ip地址，用戶名，密碼等。
如果是需要運維人員直接登陸到伺服器上操作，需要通過跳板機來登陸伺服器，記錄誰登陸了哪台伺服器，具體做了什麼操作等。
——————————
以上為常見的五種應用，請指點！
Python自動化主要幫助企業解決日常繁雜的工作事務，數據化、可視化的監控日常的業務運行情況。
歡迎一起交流和補充！
1.一句話解釋，那就是現有監控軟體的功能無法滿足公司需求，並且公司在現有軟體上的二次開發的成本大於自己從零開始進行自主開發。
2.完整的解釋：
....2.1 現有的監控軟體，無論是開源還是閉源，都是通用軟體。....2.2 製作軟體的流程是：先有需求，再有軟體。因此，通用軟體的存在，實際上已經隱含了需求。
....2.3 如果公司的需求，剛好等於或少於這些隱含需求，那就直接用現成軟體就行了。畢竟在符合需求的情況下，自己開發的成本會大於學習與配置現成軟體的成本。
....2,4 如果公司的需求，大於這些隱含需求，那麼公司只有兩條路可選：A.對現有軟體做二次開發。B.公司自己從零開始進行自主開發。。
....2,5 問題來了。一般來說，需求越複雜，二次開發的成本就越會大於自己從頭開發。所以，這就是為什麼很多公司選擇自己從零開始進行自主開發。cacti是圍繞著snmp構建的，但是很多東西跟snmp沒啥關係。
nagios可以做到很多，但是框架太靈活就意味著達到具體定製要求需要你做很多工作，而一旦你想到哥都要做這麼多事情了，就差一個event loop還不如全自己來得了，說出去KPI也漲分啊。zabbix啥都存mysql，一旦數據量達到mysql扛不住，就抓瞎了。當然，歸根結底，落實到具體監控場景上，總會讓你覺得「自己寫一個程序」比「給通用框架寫一個擴展」容易多了。越通用的東西，考慮的你不用考慮的地方越多，你就可能覺得越不爽。第一，造輪子漲經驗比較快，第二，開發的東西雖然可能很挫，但是卻在那個時期最適合的。第三，開源的改起來各種依賴，關係梳理起來也比較繁瑣，而且為了改某個邏輯，還有可能得去揣測作者當時的意圖。。。
開源產品能滿足90%的需求，但為了那10%不被開源產品滿足的需求和KPI的需求，公司就喜歡自己搞一套。另外，大公司認為花時間了解一個產品，不如自己干一套出來。
我們公司就有自己的監控產品，裝好了賣給有錢的客戶。
那些有錢的客戶如銀行、證券、通訊，誰在乎這些錢啊？變成成本然後轉嫁到消費者身上去。關鍵是不出錯誤，不要讓他們承擔責任。
出了問題，義正嚴辭的叫系統公司來臭罵一頓，然後責任就是系統公司的。系統公司能接到這些壟斷企業業務的，也都是赫赫有名的大公司，這些大公司扯皮和化解問題都有專家團隊的。
所以成本不是需要首先考慮的，出錯誰來負責才是最重要的。大公司和政府部門一樣，四平八穩的幹部才能升上去。
反正大公司壟斷的是整個社會，為什麼要開源，壟斷有什麼不好啊？這些問題壟斷企業里的人是不想知道的。
這裡開源的方案我們都不敢提，萬一出了問題怎麼辦？叫John Smith來罵一頓？John Smith有個gmail，他不要你的錢當然也不幫你承擔責任高興回答一下你，不高興就不理你了 l。沒人承擔責任的時候，責任就是你的了。
1、絕對是偷工減料造成了系統質量出了問題！2、負責人是不是拿了紅包？3、一定是貪污了。4、這和豆腐渣工程不是一樣么？壟斷企業的上面都是國家行政機構啊，用OSS，不是找死么？1. 開源的無法滿足內部的細化的需求。比如一些特殊定製化的需求。2. 搞個系統KPI才有的寫啊。
伺服器設備規模小的時候可以用開源項目玩玩，規模達到一定的數量，業務複雜，需求繁多，開源項目沒法解決，必然自己從頭搞起。
1、資產（設備，網路...）管理；2、網路的拓撲維護；3、應用的自動化部署（上線，下線）；4、基本監控，應用監控，業務監控；5、沒有1，2，3；4將是一團亂糟糟。。我來扯個蛋。
運維監控系統和監控系統基本不是一個概念了，而是父子關係。
網上開源的監控系統cacti、Nagios、zabbix和其他商業系統，有什麼方面不滿足公司的需求？ 我看到網上說的監控粒度和深度，但這個不好理解，如果方便，可以列舉一些業務？
這些都很好，
做成個運維繫統，監控個系統狀態戳戳魷魚，但是PHP 5XX 監控
JAVA FULL GC 監控JVM 監控REDIS SLOWLOG自己開發的緩存MYSQL SLOWSQLNGINX 日誌監控自定義報警介面和業務相關的任何東西 APM &<-這玩意兒牛逼轟轟，例如阿里天眼、聽雲。安全監控 &<-當然這玩意兒一般還有安全團隊攙和進來。上千台伺服器的監控日誌存儲、聚合。&<-這可不是小數據。這些軟體基本都做的不好，甚至做不到。
你要是網工，小企業的運維，你要是僅僅只需要運維監控系統，你列舉的軟體對你的工作都綽綽有餘。
但是大公司不僅僅看重這些。系統穩定的同時，還看重業務、性能。對，這不僅僅是運維要做的事情了。只能做底層運維的人一輩子也不明白為什麼開發其他監控，明明nagios這些就夠了啊，你們肯定是為了業績，為了KPI。開源的監控系統，不少只能完成基本監控，很多需要二次開發，加之KPI的需求，就自己完成的造成個整車吧；業務也會有特性需求，需要細節監控，二次開發的成本可能也比較高。
T.T 還有，不能為了做監控而監控。監控是需求，運維體系是產品。如果光為了增加個需求點，把功能堆進系統；如果每一條產品線都是完全獨立的監控體系，不能平台化，公司內部成本還是很高的啊。
運維體系產品化，很多點是一致的，比如日誌系統，SLA體系，基本點監控；再融合業務特定細節監控。
鄙人HR一枚，講的不專業，逃：） 樓上大神太多。很多運維都有一顆轉程序員的心……
我是名運維，平常對zabbix使用較多，覺得zabbix真的很靈活，但確實也有一些需要的功能沒有，比如，多個proxy到同一台伺服器的網路質量情況匯成一張圖，這個就沒有smokeping方便。
開源軟體發展到一定程度，就開始向通用化發展，更關注與普適價值，細粒度和個性化的需求就無法滿足了。這無可厚非！但我是極力的反對，明明開源軟體能實現的資產管理，基本監控等功能，還要造個破輪子出來，難道真的以為比那些大牛做的更好？
我所欣賞的是二次開發，系統集成，這樣既能充分利用大牛們的智慧，又能實現自己的定製，何樂而不為？
回到問題上來，除開裝逼和KPI導向外，我認為自己開發監控系統更多的是與現有業務系統結合，拿我公司舉例，我們是提供CDN業務的，我們的監控不僅要提供基本的圖形和告警，還要為智能解析，業務切換，帶寬調度等系統提供數據，這時候如果用開源軟體，二次開發的成本很高，就只能造輪子了！個人對監控系統的一些理解：
- 穩定性：監控系統用於監控公司的所有系統，理論上其穩定性應該高於所有系統。如果監控系統掛掉，此時各系統處於未知的狀態，這是非常可怕的事情。
- 數據量：對於用戶規模較大的互聯網公司，通常內部有非常多的模塊，每個模塊又有很多監控指標，都需要接入監控系統；監控指標採集頻率應盡量小，通常為秒級，這樣當某個系統出現錯誤時，才能夠第一時間發現系統瓶頸。所以由於上述兩點，監控數據的數據量是非常巨大的，如何高效穩定的傳輸、存儲、分析海量多維監控數據成為挑戰。
- 易用性：默認情況下，監控系統就能自動夠採集絕大部分監控指標，當然用戶也可以通過簡單配置或者少量代碼發送監控指標。監控系統能夠為用戶提供自動報警、Dashboard、歷史監控數據分析等功能，便於用戶快速分析定位問題。
可見，監控系統對於公司而言，是一個非常重要系統，且面臨來自穩定性、數據完整性、實時性等眾多方面的挑戰。現階段開源項目基本能夠滿足中小互聯網監控需求，但對於規模較大的公司，則通常會遇到上述各種問題，不得不對開源項目深度定製或者自研核心組件。
開源產品能滿足90%的需求，但為了那10%不被開源產品滿足的需求和KPI的需求，公司就需要一套針對於自己的運維監控工具，最好像PIGOSS BSM 這樣能定向開發的最好！
真正用過就知道了。。。歡迎入坑！
推薦閱讀：