20 報警監控平台擴展功能 url 回調的設計及應用 [python 語言]
Python實戰-從菜鳥到大牛的進階之路 作者：極客學院 投票推薦 加入書簽 留言反饋
<h2>前言：</h2>
這個國內也有一些第三方的廠商在用，比如 dnspod 的 url 回調和監控寶的 url 回調！
有人開源了一個腳本，監控寶的 url 回調，可以聯合 dnspod 的 api 接口。可以處理當 ip-a 的 web 死掉的時候，dns 記錄切換到 ip-b 上。 當然這隻是個小應用罷了，但不能不說，這個想法確實不錯。 我這邊也實現了類似方式。
所謂的 url 回調功能，您可以讓告警通知發送到您指定的 url，使你能更加靈活處理告警消息。 打個比方，有個服務器的 nginx 進程死掉了，這個時候 nagios 監控到了這個情況，然後調用了我這邊的接口，我這邊接到的 post 數據，不僅發郵件，而且會根據注冊事件的情況，進行處理。 如果注冊了一個遠程 nginx 重啟的事項，我這邊就遠程 paramiko 或者是 saltstack 過去重啟該進程 ！！！
圖片 20.1 pic <h2>怎麽個靈活法：</h2>
每個業務部門其實都想自己統計 error 情況，但是監控平台一般是在基礎監控部門手裏掌控者，又不太方便做部署，這個時候，url 回調是個好方法。我會把每次告警的信息不僅推到你的 mail 和手機上，而且會給你的 url 地址做 webhook。你服務端接受認證後的 url 地址後，會有相應的措施，比如調用 saltsatck 來進行處理特定的主機，比如插入到庫裏麵，自己做報表統計，根據來著的信息做自動化處理。 <h2>關於觸發式的處理：</h2>
隻是個人的想法而已 ~
在監控係統的體係下，比如有 nagios，zabbix 專業監控係統。 咱們還是用例子說話： 監控 mysql 從是否高延遲，嚴重不同步問題的時候，咱們一般是在 nagios 裏加載監控獲取判斷從延遲的腳本，以及在某個節點上做處理腳本【腳本的內容是 while get 每個 mysql 從情況，高延遲的那台在負載群裏麵踢出去】，這樣算的話是兩個腳本了。
如果利用 url 回調，可以用處理腳本，這個腳本也隻是當觸發 url 回調的時候，才執行才處理的。避免了處理腳本沒完沒了的去判斷和獲取狀態。要是監控一些統計壓力大的服務，那就有點悲催了。
當然這樣也會有些問題的，比如 web 死掉的話，他無法接受 url 回調，另一方麵 開發部也不想調用係統層麵的外部命令，畢竟責任是個問題。
下麵是我寫的 url 回調的 demo，等有機會上線供大神們測試下。
第一版的時候，沒有定義 post 的方式，以及回調結果的查看。
圖片 20.2 pic
第二版做了，get 和 post 的方式，返回結果的驗證。
圖片 20.3 pic
下麵是平台的 demo ~ 我想說的是，現在好多公司的告警信息都沒有統計，隨意的調用 smtp 發郵件，而不知道發送成功了沒有，每個月發送了幾次，發送都是啥內容。當然這些東西在 nagios zabbix 也大體可以看到，但是個人覺得還是綜合到一個管理係統下，管理係統更加直觀。
也有想這麽搞的朋友直接提問題就行，我會第一時間給大家解答~
框架：
nginx tornado jquery
圖片 20.4 pic
圖片 20.5 pic
此文接上文： http://rfyiamcool.blog.51cto/1030776/1332160
有後文，會補上的～
本文出自 “峰雲，就她了。” 博客，謝絕轉載！
這個國內也有一些第三方的廠商在用，比如 dnspod 的 url 回調和監控寶的 url 回調！
有人開源了一個腳本，監控寶的 url 回調，可以聯合 dnspod 的 api 接口。可以處理當 ip-a 的 web 死掉的時候，dns 記錄切換到 ip-b 上。 當然這隻是個小應用罷了，但不能不說，這個想法確實不錯。 我這邊也實現了類似方式。
所謂的 url 回調功能，您可以讓告警通知發送到您指定的 url，使你能更加靈活處理告警消息。 打個比方，有個服務器的 nginx 進程死掉了，這個時候 nagios 監控到了這個情況，然後調用了我這邊的接口，我這邊接到的 post 數據，不僅發郵件，而且會根據注冊事件的情況，進行處理。 如果注冊了一個遠程 nginx 重啟的事項，我這邊就遠程 paramiko 或者是 saltstack 過去重啟該進程 ！！！
圖片 20.1 pic <h2>怎麽個靈活法：</h2>
每個業務部門其實都想自己統計 error 情況，但是監控平台一般是在基礎監控部門手裏掌控者，又不太方便做部署，這個時候，url 回調是個好方法。我會把每次告警的信息不僅推到你的 mail 和手機上，而且會給你的 url 地址做 webhook。你服務端接受認證後的 url 地址後，會有相應的措施，比如調用 saltsatck 來進行處理特定的主機，比如插入到庫裏麵，自己做報表統計，根據來著的信息做自動化處理。 <h2>關於觸發式的處理：</h2>
隻是個人的想法而已 ~
在監控係統的體係下，比如有 nagios，zabbix 專業監控係統。 咱們還是用例子說話： 監控 mysql 從是否高延遲，嚴重不同步問題的時候，咱們一般是在 nagios 裏加載監控獲取判斷從延遲的腳本，以及在某個節點上做處理腳本【腳本的內容是 while get 每個 mysql 從情況，高延遲的那台在負載群裏麵踢出去】，這樣算的話是兩個腳本了。
如果利用 url 回調，可以用處理腳本，這個腳本也隻是當觸發 url 回調的時候，才執行才處理的。避免了處理腳本沒完沒了的去判斷和獲取狀態。要是監控一些統計壓力大的服務，那就有點悲催了。
當然這樣也會有些問題的，比如 web 死掉的話，他無法接受 url 回調，另一方麵 開發部也不想調用係統層麵的外部命令，畢竟責任是個問題。
下麵是我寫的 url 回調的 demo，等有機會上線供大神們測試下。
第一版的時候，沒有定義 post 的方式，以及回調結果的查看。
圖片 20.2 pic
第二版做了，get 和 post 的方式，返回結果的驗證。
圖片 20.3 pic
下麵是平台的 demo ~ 我想說的是，現在好多公司的告警信息都沒有統計，隨意的調用 smtp 發郵件，而不知道發送成功了沒有，每個月發送了幾次，發送都是啥內容。當然這些東西在 nagios zabbix 也大體可以看到，但是個人覺得還是綜合到一個管理係統下，管理係統更加直觀。
也有想這麽搞的朋友直接提問題就行，我會第一時間給大家解答~
框架：
nginx tornado jquery
圖片 20.4 pic
圖片 20.5 pic
此文接上文： http://rfyiamcool.blog.51cto/1030776/1332160
有後文，會補上的～
本文出自 “峰雲，就她了。” 博客，謝絕轉載！