只收集系統日誌的話，zabbix，nagios都行，本文完結。
但是既然你提到設計了，那請繼續往下看。
中小型的監控系統無非如下三樣東西：1.資料庫2.展示介面3.監控agent
那麼很簡單了：
1.資料庫
資料庫用opentsdb，或者influxdb，一般選用時序資料庫，按照時間戳（timestamp）對一個維度（measurement）進行監控，並且每個機器有自己的標籤（tag），標籤可以有多個，監控數值（value），後續可以針對維度（measurement）進行分類，針對標籤(tag)進行聚合。時序資料庫唯一的缺點是，只能存數值。但是監控，只需要知道數值。
2.展示介面
chronograf（不建議用，雖然我用）grafana（都在用）
對，介面和資料庫一樣，同樣不建議自研。
3.監控agent，嫌麻煩就用telegraf或者collectd
agent原理說起來很簡單，一個死迴圈，X秒執行一次操作。
舉系統日誌監控項CPU的例子：
取出cpu當前用量（例如44%），打上維度標籤（measurement=cpu），打上tag標籤（hostname=a, group=aGroup, ip=10.1.1.1），打上時間戳 timestamp，記錄數值（value=0.44）取前記憶體用量……
取磁碟用量……都取出來之後，扔進資料庫。
作為使用者，配置一下grafana即可
參考文章：利用Metrics+influxdb+grafana構建監控平臺
使用 Grafana＋collectd＋InfluxDB 打造現代監控系統
本文結束。
關於更進一步和報警系統
如果你司只收集系統日誌的話，下面的就不需要讀了。
當然如果你司要收集業務監控的話，那麼相信到這一步你司一定有個小小的監控系統專案了。
下面說一點我這裡曾經遇到的事情/需求。
4.實時性：如果不願意把資料庫直接暴露給agent，可以做一層proxy，由proxy進行資料驗證和身份驗證然後存入資料庫。對，proxy這裡可以做很多事情，例如cpu>80%就報警。
5.持久化說白了，儲存問題。監控資料量非常大，一般三個月的資料量就很讓人頭大。後續要存多久的日誌，怎麼存，都是個問題。有時候時序資料庫無法滿足問題，可以考慮換成分散式儲存了。是否需要快取，最近多久的的日誌放到快取裡，用什麼更新策略。
6.報警雖然上面提到了，這裡還是得專門拉出來。報警不一定必須要在proxy層做掉，因為處理速度可能跟不上。例如有些要求連續三分鐘怎麼樣就持續報警。有些要求報警簡訊先快後慢，避免撐爆手機。
有時候你想知道某些報警是否已解除，便需要一個控制檯來查詢。
7.介面有些應用我想臨時不報警，有寫我想拿出監控資料進行計算，有些我想自己傳給你資料，用你的介面和資料庫……
8.自定義監控說起來也不難，支援agent執行自定義指令碼進行監控，支援各種傳入引數監控，支援這個支援那個，總歸一個自定義二字。
9.暫時想不起來了。你先搞定前三點吧。1，2有現成的，配置一下就能用，3一般自研，做起來很簡單，現成的也能用，我也給出了參考文件，程式碼都不用寫就能跑起來。
並且，telegraf+influxdb+grafana一下午就能搞出來一套監控系統。4，5，6，7，8酌情。
10.其他可能遇到的問題
例如資料庫達到上萬臺之後，opentsdb也撐不住，這個時候你可能需要考慮其他資料庫。
恩，我這裡用kafka，也在調研scylladb。
對了，以上內容看起來很簡單，做起來很難。
另：influxdata有一系列的監控解決方案，可以參考他們的架構設計。
本文完結。
prometheus最近的勢頭很猛，也可以關注下。
不過原理上prometheus依靠的不是agent上報，而是服務端（透過http協議）到被監控機器抓取監控資訊，例如監控mysql需要一個mysqld_exporter的agent來提供匯出，同樣需要agent來提供http介面。這種做法和傳統的agent上報模式各有優劣，請自行選擇方案。
只收集系統日誌的話，zabbix，nagios都行，本文完結。
但是既然你提到設計了，那請繼續往下看。
中小型的監控系統無非如下三樣東西：1.資料庫2.展示介面3.監控agent
那麼很簡單了：
1.資料庫
資料庫用opentsdb，或者influxdb，一般選用時序資料庫，按照時間戳（timestamp）對一個維度（measurement）進行監控，並且每個機器有自己的標籤（tag），標籤可以有多個，監控數值（value），後續可以針對維度（measurement）進行分類，針對標籤(tag)進行聚合。時序資料庫唯一的缺點是，只能存數值。但是監控，只需要知道數值。
2.展示介面
chronograf（不建議用，雖然我用）grafana（都在用）
對，介面和資料庫一樣，同樣不建議自研。
3.監控agent，嫌麻煩就用telegraf或者collectd
agent原理說起來很簡單，一個死迴圈，X秒執行一次操作。
舉系統日誌監控項CPU的例子：
取出cpu當前用量（例如44%），打上維度標籤（measurement=cpu），打上tag標籤（hostname=a, group=aGroup, ip=10.1.1.1），打上時間戳 timestamp，記錄數值（value=0.44）取前記憶體用量……
取磁碟用量……都取出來之後，扔進資料庫。
作為使用者，配置一下grafana即可
參考文章：利用Metrics+influxdb+grafana構建監控平臺
使用 Grafana＋collectd＋InfluxDB 打造現代監控系統
本文結束。
關於更進一步和報警系統
如果你司只收集系統日誌的話，下面的就不需要讀了。
當然如果你司要收集業務監控的話，那麼相信到這一步你司一定有個小小的監控系統專案了。
下面說一點我這裡曾經遇到的事情/需求。
4.實時性：如果不願意把資料庫直接暴露給agent，可以做一層proxy，由proxy進行資料驗證和身份驗證然後存入資料庫。對，proxy這裡可以做很多事情，例如cpu>80%就報警。
5.持久化說白了，儲存問題。監控資料量非常大，一般三個月的資料量就很讓人頭大。後續要存多久的日誌，怎麼存，都是個問題。有時候時序資料庫無法滿足問題，可以考慮換成分散式儲存了。是否需要快取，最近多久的的日誌放到快取裡，用什麼更新策略。
6.報警雖然上面提到了，這裡還是得專門拉出來。報警不一定必須要在proxy層做掉，因為處理速度可能跟不上。例如有些要求連續三分鐘怎麼樣就持續報警。有些要求報警簡訊先快後慢，避免撐爆手機。
有時候你想知道某些報警是否已解除，便需要一個控制檯來查詢。
7.介面有些應用我想臨時不報警，有寫我想拿出監控資料進行計算，有些我想自己傳給你資料，用你的介面和資料庫……
8.自定義監控說起來也不難，支援agent執行自定義指令碼進行監控，支援各種傳入引數監控，支援這個支援那個，總歸一個自定義二字。
9.暫時想不起來了。你先搞定前三點吧。1，2有現成的，配置一下就能用，3一般自研，做起來很簡單，現成的也能用，我也給出了參考文件，程式碼都不用寫就能跑起來。
並且，telegraf+influxdb+grafana一下午就能搞出來一套監控系統。4，5，6，7，8酌情。
10.其他可能遇到的問題
例如資料庫達到上萬臺之後，opentsdb也撐不住，這個時候你可能需要考慮其他資料庫。
恩，我這裡用kafka，也在調研scylladb。
對了，以上內容看起來很簡單，做起來很難。
另：influxdata有一系列的監控解決方案，可以參考他們的架構設計。
本文完結。
prometheus最近的勢頭很猛，也可以關注下。
不過原理上prometheus依靠的不是agent上報，而是服務端（透過http協議）到被監控機器抓取監控資訊，例如監控mysql需要一個mysqld_exporter的agent來提供匯出，同樣需要agent來提供http介面。這種做法和傳統的agent上報模式各有優劣，請自行選擇方案。