你的問題不是太清楚需要寫出用處。我想你需要的主要分系統監控和業務監控兩類吧
系統監控就是每臺主機的CPU,記憶體，網路頻寬等使用情況，以及Mysql, Redis, Nginx等服務的核心指標等，這是比較基本的監控，必須得有，如果這塊監控做的好，生產環境可以提前發現很多問題，防患於未然。
業務監控就是業務相關的指標，如某API每秒呼叫次數，每分鐘該API的平均響應時間，服務的線上人數，甚至一些運營相關的資料，如七日留存率啦，每日新增使用者，每日流失使用者等。這些資料也很重要，他是你整個業務的晴雨表，為你做一些重要決策提供依據。
對於系統監控，有很多開源軟體可以拿來用，如比較出名的ngios,cacti,zabbix等，部署都比較複雜，客戶端要部agent，還得裝一個center用來收集，儲存展現資料，還有好多外掛需要維護。但有一個比較簡單的東西是collectd，它自帶了各種外掛，如系統CPU，磁碟利用率，mysql,nginx,redix等常用服務都可
以進行監控，而且自動給你推薦了要監控哪些指標。安裝很方便，基本上./configuration && make && make install就可以了。
對於業務監控，肯定是需要自己寫程式碼上報業務資料的，現在比較流行的方案是statsd+graphite，比較輕量級，而且有很多語言的sdk，可以很輕鬆把各種指標監控起來。
大多監控體系都差不多，如下
1、每臺機器上安裝一個agent，用來採集本機的效能資料，服務資料
2、每臺機器部署的業務，根據一個sdk，向center提交本業務相關的資料
3、每個agent可以動態的按需求載入一些外掛，以便監控新的指標
4、一般一個機房內有一個center用來收集各agent和各業務上報的指標
5、center要把採集到的指標資料進行儲存，歸檔，壓縮，一般用rrd database
6、center還得有一個web介面來檢視各個指標的歷史圖表，甚至要有各種檢視和dashborad來顯示一組相關的指標。
7、center還要每天把使用者自定義的幾個關鍵的指標生產報表發給運維或者相關人員。
8、center還需要儲存各種告警規則，如某個指標連續幾次超過某個閾值產生告警，或者波動超過某個範圍產生告警，或者某個指標超過多長時間沒有上報資料產生告警
9、center還要進行各種告警的收斂，如同類告警的合併，臨時遮蔽某類告警，防止因為網路抖動引起大量告警等，沒有這些運維人員會淹沒在各種告警聲中。
11、center還要對每次告警進行回顧，統計，分析，得出每個系統的薄弱點，可用率，線上時間，穩定性等。
所以說，自己搭建一套完善可靠的監控體系，挺不容易的，需要投入大量的人力和精力去開發和維護。
現在國外也有一些專門做運維外包的廠商，center託管在給他們，免去了很大的工作量，剩下的agent和plugin還是得自己安裝，但這就簡單了，反正有很多可以做批次部署的運維工具。
比較出名的有NewRelic,StatHat,hostedgraphite，可以去了解一下，基本上就是安裝個agent就可以向它們的center上報資料了，或者是利用他們的Sdk提交一些自定義資料，他們負責儲存，展現，告警方面的事情，節省很多人力。
國內的話，也有人做類似的事情，如DNSPod的D監控最近推出了自定義監控的功能，相容graphite的上報介面，你自己部署個collectd就可以把各種系統監控指標監控起來了，如果要做業務監控，graphite也有各種語言的sdk。graphite本身開源，周邊工具和軟體也特別多，能滿足很多的需求。
你的問題不是太清楚需要寫出用處。我想你需要的主要分系統監控和業務監控兩類吧
系統監控就是每臺主機的CPU,記憶體，網路頻寬等使用情況，以及Mysql, Redis, Nginx等服務的核心指標等，這是比較基本的監控，必須得有，如果這塊監控做的好，生產環境可以提前發現很多問題，防患於未然。
業務監控就是業務相關的指標，如某API每秒呼叫次數，每分鐘該API的平均響應時間，服務的線上人數，甚至一些運營相關的資料，如七日留存率啦，每日新增使用者，每日流失使用者等。這些資料也很重要，他是你整個業務的晴雨表，為你做一些重要決策提供依據。
對於系統監控，有很多開源軟體可以拿來用，如比較出名的ngios,cacti,zabbix等，部署都比較複雜，客戶端要部agent，還得裝一個center用來收集，儲存展現資料，還有好多外掛需要維護。但有一個比較簡單的東西是collectd，它自帶了各種外掛，如系統CPU，磁碟利用率，mysql,nginx,redix等常用服務都可
以進行監控，而且自動給你推薦了要監控哪些指標。安裝很方便，基本上./configuration && make && make install就可以了。
對於業務監控，肯定是需要自己寫程式碼上報業務資料的，現在比較流行的方案是statsd+graphite，比較輕量級，而且有很多語言的sdk，可以很輕鬆把各種指標監控起來。
大多監控體系都差不多，如下
1、每臺機器上安裝一個agent，用來採集本機的效能資料，服務資料
2、每臺機器部署的業務，根據一個sdk，向center提交本業務相關的資料
3、每個agent可以動態的按需求載入一些外掛，以便監控新的指標
4、一般一個機房內有一個center用來收集各agent和各業務上報的指標
5、center要把採集到的指標資料進行儲存，歸檔，壓縮，一般用rrd database
6、center還得有一個web介面來檢視各個指標的歷史圖表，甚至要有各種檢視和dashborad來顯示一組相關的指標。
7、center還要每天把使用者自定義的幾個關鍵的指標生產報表發給運維或者相關人員。
8、center還需要儲存各種告警規則，如某個指標連續幾次超過某個閾值產生告警，或者波動超過某個範圍產生告警，或者某個指標超過多長時間沒有上報資料產生告警
9、center還要進行各種告警的收斂，如同類告警的合併，臨時遮蔽某類告警，防止因為網路抖動引起大量告警等，沒有這些運維人員會淹沒在各種告警聲中。
11、center還要對每次告警進行回顧，統計，分析，得出每個系統的薄弱點，可用率，線上時間，穩定性等。
所以說，自己搭建一套完善可靠的監控體系，挺不容易的，需要投入大量的人力和精力去開發和維護。
現在國外也有一些專門做運維外包的廠商，center託管在給他們，免去了很大的工作量，剩下的agent和plugin還是得自己安裝，但這就簡單了，反正有很多可以做批次部署的運維工具。
比較出名的有NewRelic,StatHat,hostedgraphite，可以去了解一下，基本上就是安裝個agent就可以向它們的center上報資料了，或者是利用他們的Sdk提交一些自定義資料，他們負責儲存，展現，告警方面的事情，節省很多人力。
國內的話，也有人做類似的事情，如DNSPod的D監控最近推出了自定義監控的功能，相容graphite的上報介面，你自己部署個collectd就可以把各種系統監控指標監控起來了，如果要做業務監控，graphite也有各種語言的sdk。graphite本身開源，周邊工具和軟體也特別多，能滿足很多的需求。