近期有小伙伴反饋在使用 Basic Azure Load Balancer 時,后端池內主機會拒絕響應探針,從而影響業務連續性。我們一般自然而然的會想到通過增加監控告警來提升響應及修復速度,但目前 Basic Azure Load Balancer 不支持提供 Metric 監控指標,Standard Load Balancer 可以提供 Metric 指標。有了指標解決了監控數據源頭的問題,但是 Azure China 的小伙班還需要注意,目前 Azure China 的 Monitor 服務不支持對 Standard Load Balancer 的 Metric 來關聯 Alert 告警,所以 Azure 第一方的 monitor 服務在 Azure China 目前暫時無法滿足需求。本文通過 Azure Monitor 服務提供的 API 接口,通過代碼完成指標抓取及告警的工作。我們先來看一下架構圖:
本文主要介紹中間部分通過 API 獲取 Metric 信息,然后執行事件響應操作(如發送告警郵件,短消息,或集成外部的 Webhook)。
import adal import requests import time from datetime import datetime, timedelta authentication_endpoint = 'https://login.microsoftonline.com/' resource = 'https://management.core.windows.net/' tenant_id = 'xxx' application_id ='xxx' application_secret = 'xxx' subscriptionid = 'xxx' resoucegroupname = 'xxx' loadbalancername = 'xxx' # get an Azure access token using the adal library context = adal.AuthenticationContext(authentication_endpoint + tenant_id) token_response = context.acquire_token_with_client_credentials(resource, application_id, application_secret) access_token = token_response.get('accessToken') # print(access_token) # input your monitor interval interval = 60 while True: #datetime format 2018-06-05T03:00:00Z now = datetime.utcnow() lastfivemins = datetime.utcnow() - timedelta(minutes=5) current_date_time = now.strftime("%Y-%m-%dT%H:%M:%SZ") lastfivemins_data_time = lastfivemins.strftime("%Y-%m-%dT%H:%M:%SZ") #https://management.azure.com/subscriptions/{subscriptionId}/resourceGroups/{resourceGroupName}/providers/Microsoft.Network/loadBalancers/{loadBalancerName}/providers/microsoft.insights/metrics?api-version=2018-01-01&metricnames=ByteCount×pan=2018-06-05T03:00:00Z/2018-06-07T03:00:00Z endpoint = 'https://management.azure.com/subscriptions/%s/resourceGroups/%s/providers/Microsoft.Network/loadBalancers/%s/providers/microsoft.insights/metrics?api-version=2018-01-01&metricnames=VipAvailability×pan=%s/%s'%(subscriptionid,resoucegroupname,loadbalancername,lastfivemins_data_time,current_date_time) headers = {"Authorization": 'Bearer ' + access_token} json_output = requests.get(endpoint,headers=headers).json() mask_json_output = json_output["value"][0]["timeseries"][0]["data"] counter = 0 sum = 0 for sub in mask_json_output: sum = sum + sub["average"] counter = counter + 1 print(sum/counter) average = sum/counter if average < 1: # input your alert code herer time.sleep(interval) else: time.sleep(interval) continue
上述代碼直接通過 Azure Monitor 提供的 Rest API 接口獲取 Standard Load Balancer 提供的 VipAvailability 指標,該指標體現的是后端池的健康狀態。當后端池全部主機處於活躍狀態時,Metric 指標打點返回值為 100,當后端池中有無活躍節節點時返回值將等於0,該指標的打點頻率為1mins。上述代碼中我們通過每分鍾抓取過去五分鍾的指標並計算平均值,然后來判斷是否觸發告警。在訪問 Azure monitor 的 Rest API 中有幾個關鍵點,1. 確認 Endpoint URL,不同的指標 Endpoint URL 是不同的,Endpoint URL 可以參閱文檔:https://docs.microsoft.com/en-us/rest/api/monitor/metrics/list;2. 返回值的 Schema,前面的文檔里面有示例,最有效的辦法是將返回值的 json 結果打印出來,來獲得 schema 示例。3. 不同服務支持哪些 Metric 指標,可以訪問如下鏈接:https://docs.microsoft.com/en-us/azure/azure-monitor/platform/metrics-supported
有了上述邏輯,那這個代碼跑在哪里呢? 跑在一台虛擬機上?那這台虛擬機掛了怎么辦?從成本和可用性的角度,這里建議大家可以把上述代碼邏輯在 LogicApp 服務或 Function 服務中實現,好處是通過 PaaS 服務實現高可用,另外這兩種服務都可以通過按需調用次數來收費。具體這兩個服務上的配置就不在這里贅述了,大家可以按照這個上述邏輯自己玩一下。