Konfigurowanie reguł opartych na progach w usłudze Azure Stream Analytics
W tym artykule opisano sposób użycia danych referencyjnych w celu uzyskania rozwiązania do zgłaszania alertów, które korzysta z konfigurowalnych reguł opartych na progach w usłudze Azure Stream Analytics.
Scenariusz: Alerty oparte na regulowanych progach reguł
Może być konieczne wygenerowanie alertu jako danych wyjściowych, gdy przychodzące zdarzenia przesyłane strumieniowo osiągnęły określoną wartość lub gdy zagregowana wartość oparta na przychodzących zdarzeniach przesyłanych strumieniowo przekracza określony próg. Proste konfigurowanie zapytania usługi Stream Analytics, które porównuje wartość z progiem statycznym, który jest stały i wstępnie określony. Stały próg można trwale zakodować w składni zapytań przesyłania strumieniowego przy użyciu prostych porównań liczbowych (większych niż, mniejszych niż i równości).
W niektórych przypadkach wartości progowe muszą być łatwiejsze do skonfigurowania bez konieczności edytowania składni zapytania za każdym razem, gdy zmienia się wartość progowa. W innych przypadkach może być konieczne użycie wielu urządzeń lub użytkowników przetworzonych przez to samo zapytanie, przy użyciu których każda z nich ma inne wartości progowe na każdym urządzeniu.
Ten wzorzec może służyć do dynamicznego konfigurowania progów, selektywnego wybierania rodzaju urządzenia, którego dotyczy próg, przez filtrowanie danych wejściowych i selektywne wybieranie pól do uwzględnienia w danych wyjściowych.
Zalecany wzorzec projektu
Użyj danych wejściowych referencyjnych do zadania usługi Stream Analytics jako wyszukiwania progów alertów:
- Zapisz wartości progowe w danych referencyjnych, jedną wartość na klucz.
- Dołącz zdarzenia wejściowe danych przesyłanych strumieniowo do danych referencyjnych w kolumnie klucza.
- Użyj wartości kluczowanej z danych referencyjnych jako wartości progowej.
Przykładowe dane i zapytania
W tym przykładzie alerty są generowane, gdy agregacja danych przesyłanych strumieniowo z urządzeń w oknie minutowym jest zgodna z określonymi wartościami w regule dostarczonej jako dane referencyjne.
W zapytaniu dla każdego identyfikatora urządzenia i każdej metrykiName w obszarze deviceId można skonfigurować od 0 do 5 wymiarów do GRUPOWANIA WEDŁUG. Grupowane są tylko zdarzenia z odpowiednimi wartościami filtru. Po zgrupowaniu agregacje okienne wartości Min, Max, Avg są obliczane w 60-sekundowym oknie wirowania. Filtry na zagregowanych wartościach są następnie obliczane zgodnie ze skonfigurowanym progiem w odwołaniu w celu wygenerowania zdarzenia wyjściowego alertu.
Załóżmy na przykład, że istnieje zadanie usługi Stream Analytics, które ma dane wejściowe referencyjne o nazwach reguł i dane wejściowe danych przesyłanych strumieniowo o nazwie metrics.
Dane referencyjne
Te przykładowe dane referencyjne pokazują, jak można przedstawić regułę opartą na progach. Plik JSON przechowuje dane referencyjne i jest zapisywany w usłudze Azure Blob Storage, a kontener magazynu obiektów blob jest używany jako dane wejściowe danych referencyjnych o nazwie rules. Możesz zastąpić ten plik JSON i zastąpić konfigurację reguły w miarę upływu czasu bez zatrzymywania lub uruchamiania zadania przesyłania strumieniowego.
- Przykładowa reguła służy do reprezentowania regulowanego alertu, gdy procesor CPU przekracza (średnia jest większa lub równa) wartości
90procentowej. Polevaluemożna skonfigurować zgodnie z potrzebami. - Zwróć uwagę, że reguła ma pole operatora , które jest dynamicznie interpretowane w składni zapytania później w dniu
AVGGREATEROREQUAL. - Reguła filtruje dane dla określonego klucza
2wymiaru przy użyciu wartościC1. Inne pola są pustymi ciągami wskazującymi, że nie należy filtrować strumienia wejściowego według tych pól zdarzeń. W razie potrzeby można skonfigurować dodatkowe reguły procesora CPU, aby filtrować inne pasujące pola. - Nie wszystkie kolumny mają być uwzględnione w zdarzeniu alertu wyjściowego. W takim przypadku numer
2klucza jest włączonyTRUEwincludedDimcelu reprezentowania tego pola numer 2 danych zdarzenia w strumieniu zostanie uwzględniony w kwalifikujących się zdarzeniach wyjściowych. Inne pola nie są uwzględniane w danych wyjściowych alertu, ale można dostosować listę pól.
{
"ruleId": 1234,
"deviceId" : "978648",
"metricName": "CPU",
"alertName": "hot node AVG CPU over 90",
"operator" : "AVGGREATEROREQUAL",
"value": 90,
"includeDim": {
"0": "FALSE",
"1": "FALSE",
"2": "TRUE",
"3": "FALSE",
"4": "FALSE"
},
"filter": {
"0": "",
"1": "",
"2": "C1",
"3": "",
"4": ""
}
}
Przykładowe zapytanie przesyłane strumieniowo
To przykładowe zapytanie usługi Stream Analytics łączy reguły odwołujące się do danych z powyższego przykładu do strumienia wejściowego danych o nazwie metrics.
WITH transformedInput AS
(
SELECT
dim0 = CASE rules.includeDim.[0] WHEN 'TRUE' THEN metrics.custom.dimensions.[0].value ELSE NULL END,
dim1 = CASE rules.includeDim.[1] WHEN 'TRUE' THEN metrics.custom.dimensions.[1].value ELSE NULL END,
dim2 = CASE rules.includeDim.[2] WHEN 'TRUE' THEN metrics.custom.dimensions.[2].value ELSE NULL END,
dim3 = CASE rules.includeDim.[3] WHEN 'TRUE' THEN metrics.custom.dimensions.[3].value ELSE NULL END,
dim4 = CASE rules.includeDim.[4] WHEN 'TRUE' THEN metrics.custom.dimensions.[4].value ELSE NULL END,
metric = metrics.metric.value,
metricName = metrics.metric.name,
deviceId = rules.deviceId,
ruleId = rules.ruleId,
alertName = rules.alertName,
ruleOperator = rules.operator,
ruleValue = rules.value
FROM
metrics
timestamp by eventTime
JOIN
rules
ON metrics.deviceId = rules.deviceId AND metrics.metric.name = rules.metricName
WHERE
(rules.filter.[0] = '' OR metrics.custom.filters.[0].value = rules.filter.[0]) AND
(rules.filter.[1] = '' OR metrics.custom.filters.[1].value = rules.filter.[1]) AND
(rules.filter.[2] = '' OR metrics.custom.filters.[2].value = rules.filter.[2]) AND
(rules.filter.[3] = '' OR metrics.custom.filters.[3].value = rules.filter.[3]) AND
(rules.filter.[4] = '' OR metrics.custom.filters.[4].value = rules.filter.[4])
)
SELECT
System.Timestamp as time,
transformedInput.deviceId as deviceId,
transformedInput.ruleId as ruleId,
transformedInput.metricName as metric,
transformedInput.alertName as alert,
AVG(metric) as avg,
MIN(metric) as min,
MAX(metric) as max,
dim0, dim1, dim2, dim3, dim4
FROM
transformedInput
GROUP BY
transformedInput.deviceId,
transformedInput.ruleId,
transformedInput.metricName,
transformedInput.alertName,
dim0, dim1, dim2, dim3, dim4,
ruleOperator,
ruleValue,
TumblingWindow(second, 60)
HAVING
(
(ruleOperator = 'AVGGREATEROREQUAL' AND avg(metric) >= ruleValue) OR
(ruleOperator = 'AVGEQUALORLESS' AND avg(metric) <= ruleValue)
)
Przykład danych wejściowych danych wejściowych przesyłania strumieniowego
W tym przykładzie dane JSON reprezentują dane wejściowe metryk , które są używane w powyższym zapytaniu przesyłanym strumieniowo.
- Trzy przykładowe zdarzenia są wyświetlane w 1-minutowym przedziale czasu o wartości
T14:50. - Wszystkie trzy mają tę samą
deviceIdwartość978648. - Wartości metryk procesora CPU różnią się odpowiednio w każdym zdarzeniu ,
98,9580. Tylko dwa pierwsze przykładowe zdarzenia przekraczają regułę alertu procesora CPU ustanowioną w regule. - Pole includeDim w regule alertu miało numer klucza 2. Odpowiednie pole klucza 2 w przykładowych zdarzeniach nosi nazwę
NodeName. Trzy przykładowe zdarzenia mają odpowiednio wartościN024,N024iN014. W danych wyjściowych zobaczysz tylko węzełN024, ponieważ są to jedyne dane spełniające kryteria alertu dotyczące wysokiego użycia procesora CPU.N014nie spełnia wysokiego progu procesora CPU. - Reguła alertu jest skonfigurowana
filtertylko dla klucza numer 2, który odpowiadaclusterpolu w przykładowych zdarzeniach. Trzy przykładowe zdarzenia mają wartośćC1i spełniają kryteria filtrowania.
{
"eventTime": "2018-04-30T14:50:23.1324132Z",
"deviceId": "978648",
"custom": {
"dimensions": {
"0": {
"name": "NodeType",
"value": "N1"
},
"1": {
"name": "Cluster",
"value": "C1"
},
"2": {
"name": "NodeName",
"value": "N024"
}
},
"filters": {
"0": {
"name": "application",
"value": "A1"
},
"1": {
"name": "deviceType",
"value": "T1"
},
"2": {
"name": "cluster",
"value": "C1"
},
"3": {
"name": "nodeType",
"value": "N1"
}
}
},
"metric": {
"name": "CPU",
"value": 98,
"count": 1.0,
"min": 98,
"max": 98,
"stdDev": 0.0
}
}
{
"eventTime": "2018-04-30T14:50:24.1324138Z",
"deviceId": "978648",
"custom": {
"dimensions": {
"0": {
"name": "NodeType",
"value": "N2"
},
"1": {
"name": "Cluster",
"value": "C1"
},
"2": {
"name": "NodeName",
"value": "N024"
}
},
"filters": {
"0": {
"name": "application",
"value": "A1"
},
"1": {
"name": "deviceType",
"value": "T1"
},
"2": {
"name": "cluster",
"value": "C1"
},
"3": {
"name": "nodeType",
"value": "N2"
}
}
},
"metric": {
"name": "CPU",
"value": 95,
"count": 1,
"min": 95,
"max": 95,
"stdDev": 0
}
}
{
"eventTime": "2018-04-30T14:50:37.1324130Z",
"deviceId": "978648",
"custom": {
"dimensions": {
"0": {
"name": "NodeType",
"value": "N3"
},
"1": {
"name": "Cluster",
"value": "C1 "
},
"2": {
"name": "NodeName",
"value": "N014"
}
},
"filters": {
"0": {
"name": "application",
"value": "A1"
},
"1": {
"name": "deviceType",
"value": "T1"
},
"2": {
"name": "cluster",
"value": "C1"
},
"3": {
"name": "nodeType",
"value": "N3"
}
}
},
"metric": {
"name": "CPU",
"value": 80,
"count": 1,
"min": 80,
"max": 80,
"stdDev": 0
}
}
Przykładowe dane wyjściowe
W tym przykładzie dane wyjściowe JSON pokazują, że pojedyncze zdarzenie alertu zostało wygenerowane na podstawie reguły progu procesora CPU zdefiniowanej w danych referencyjnych. Zdarzenie wyjściowe zawiera nazwę alertu, a także zagregowaną (średnią, minimalną, maksymalną) uwzględnionych pól. Dane zdarzenia wyjściowego zawierają wartość N024 klucza pola 2 NodeName ze względu na konfigurację reguły. (Plik JSON został zmieniony w celu pokazania podziałów wierszy na potrzeby czytelności).
{"time":"2018-05-01T02:03:00.0000000Z","deviceid":"978648","ruleid":1234,"metric":"CPU",
"alert":"hot node AVG CPU over 90","avg":96.5,"min":95.0,"max":98.0,
"dim0":null,"dim1":null,"dim2":"N024","dim3":null,"dim4":null}