前言：
這個國內也有一些第三方的廠商在用，比如 dnspod 的 url 回調和監控寶的 url 回調！
有人開源了一個腳本，監控寶的 url 回調，可以聯合 dnspod 的 api 接口。可以處理當 ip-A 的 web 死掉的時候，dns 記錄切換到 ip-B 上。 當然這只是個小應用罷了，但不能不說，這個想法確實不錯。 我這邊也實現了類似方式。
所謂的 URL 回調功能，您可以讓告警通知發送到您指定的 URL，使你能更加靈活處理告警消息。 打個比方，有個服務器的 nginx 進程死掉了，這個時候 nagios 監控到了這個情況，然後調用了我這邊的接口，我這邊接到的 post 數據，不僅發郵件，而且會根據註冊事件的情況，進行處理。 如果註冊了一個遠程 nginx 重啟的事項，我這邊就遠程 paramiko 或者是 saltstack 過去重啟該進程 ！！！
圖片 20.1 pic
怎麼個靈活法：
每個業務部門其實都想自己統計 error 情況，但是監控平台一般是在基礎監控部門手裡掌控者，又不太方便做部署，這個時候，url 回調是個好方法。我會把每次告警的信息不僅推到你的 mail 和手機上，而且會給你的 url 地址做 webhook。你服務端接受認證後的 url 地址後，會有相應的措施，比如調用 saltsatck 來進行處理特定的主機，比如插入到庫裡面，自己做報表統計，根據來著的信息做自動化處理。
關於觸發式的處理：
只是個人的想法而已 ~
在監控系統的體系下，比如有 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.com/1030776/1332160
有後文，會補上的～
本文出自 「峰雲，就她了。」 博客，謝絕轉載！