使用異常偵測程式單變數 API 的最佳做法
重要
從 2023 年 9 月 20 日起，您將無法建立新的異常偵測程式資源。 異常偵測程式服務將于 2026 年 10 月 1 日淘汰。
異常偵測程式 API 是無狀態異常偵測服務。 其結果的精確度和效能可能會受到下列影響：
- 時間序列資料的準備方式。
- 所使用的異常偵測程式 API 參數。
- API 要求中的資料點數目。
使用本文來瞭解使用 API 取得資料最佳結果的最佳做法。
何時使用批次 （整個） 或最新 （最後） 點異常偵測
異常偵測程式 API 的批次偵測端點可讓您透過整個時間序列資料偵測異常。 在此偵測模式中，會建立單一統計模型，並套用至資料集中的每個點。 如果您的時間序列具有下列特性，建議您使用批次偵測，在一個 API 呼叫中預覽您的資料。
- 季節性時間序列，偶爾會有異常。
- 一般趨勢時間序列，偶爾會有尖峰/下降。
不建議針對即時資料監視使用批次異常偵測，或針對沒有上述特性的時間序列資料使用它。
批次偵測只會建立並套用一個模型，每個點的偵測會在整個數列的內容中完成。 如果時間序列資料在沒有季節性的情況下向上和向下趨勢，模型可能會遺漏一些變更點（資料中的下降和尖峰）。 同樣地，資料集稍後較不重要的一些變更點可能不會算作足以併入模型。
批次偵測比在進行即時資料監視時偵測最新點的異常狀態慢，因為正在分析的點數。
針對即時資料監視，建議只偵測最新資料點的異常狀態。 藉由持續套用最新的點偵測，串流資料監視可以更有效率且準確地完成。
下列範例描述這些偵測模式對效能的影響。 第一張圖片顯示持續偵測 28 個先前看到資料點的異常狀態最新點的結果。 紅點是異常。
以下是使用批次異常偵測的相同資料集。 為作業建置的模型已忽略數個異常，以矩形標示。
資料準備
異常偵測程式 API 接受格式化為 JSON 要求物件的時間序列資料。 時間序列可以是依循序順序記錄在一段時間內的任何數值資料。 您可以將時間序列資料的時段傳送至異常偵測程式 API 端點，以改善 API 的效能。 您可以傳送的資料點數目下限為 12，最大值為 8640 點。 資料細微性定義為取樣資料的速率。
傳送至異常偵測程式 API 的資料點必須具有有效的國際標準時間 （UTC） 時間戳記和數值。
{
"granularity": "daily",
"series": [
{
"timestamp": "2018-03-01T00:00:00Z",
"value": 32858923
},
{
"timestamp": "2018-03-02T00:00:00Z",
"value": 29615278
},
]
}
如果您的資料是以非標準時間間隔取樣，您可以在要求中新增 customInterval 屬性來指定它。 例如，如果您的數列每隔 5 分鐘取樣一次，您可以將下列內容新增至 JSON 要求：
{
"granularity" : "minutely",
"customInterval" : 5
}
遺漏資料點
遺漏的資料點在平均分散的時間序列資料集中很常見，尤其是具有精細細微性的資料點（小型取樣間隔。例如，每隔幾分鐘取樣一次資料。 遺漏資料中預期的點數少於 10%， 不應該對您的偵測結果產生負面影響。 請考慮根據資料中的間距來取代先前期間的資料點、線性插補或移動平均等特性。
匯總分散式資料
異常偵測程式 API 最適合平均分散的時間序列。 如果您的資料是隨機散發的，您應該依時間單位匯總資料，例如每分鐘、每小時或每日。
使用季節性模式對資料的異常偵測
如果您知道時間序列資料具有季節性模式（定期發生的模式），您可以改善精確度和 API 回應時間。
period當您建構 JSON 要求時，指定 可降低高達 50% 的異常偵測延遲。 period是一個整數，這個整數會指定時間序列重複模式所花費的資料點數目。 例如，每天有一個資料點的時間序列會是 period7 ，而具有每小時一個點的時間序列（具有相同的每週模式）會有 的 period7*24 。 如果您不確定資料的模式，就不需要指定此參數。
為了獲得最佳結果，請提供四 period 個的資料點，再加上一個額外的資料點。 例如，具有每週模式的每小時資料，如上所述，應該在要求本文中提供 673 個資料點（ 7 * 24 * 4 + 1 ）。
即時監視的取樣資料
如果您的串流資料以短間隔取樣（例如秒或分鐘），傳送建議的資料點數目可能會超過允許的異常偵測程式 API 最大數目（8640 個資料點）。 如果您的資料顯示穩定的季節性模式，請考慮以較大的時間間隔傳送時間序列資料的範例，例如小時。 以這種方式取樣您的資料也可以明顯改善 API 回應時間。