Condividi tramite


Procedure consigliate per l'uso dell'API Rilevamento anomalie univariato

Importante

A partire dal 20 settembre 2023 non sarà possibile creare nuove risorse di Rilevamento anomalie. Il servizio Rilevamento anomalie verrà ritirato il 1° ottobre 2026.

L'API Rilevamento anomalie è un servizio di rilevamento anomalie senza stato. L'accuratezza e le prestazioni dei relativi risultati possono essere influenzate da questi fattori:

  • Il modo in cui vengono preparati i dati delle serie temporali.
  • I parametri dell'API Rilevamento anomalie usati.
  • Il numero di punti dati nella richiesta API.

Usare questo articolo per informazioni sulle procedure consigliate sull'uso dell'API per ottenere i risultati migliori per i dati.

Quando usare il rilevamento anomalie batch (intero) o più recente (ultimo)

L'endpoint di rilevamento batch dell'API Rilevamento anomalie consente di rilevare anomalie tramite i dati dell'intera serie temporale. In questa modalità di rilevamento viene creato un singolo modello statistico applicato a ogni punto del set di dati. Se la serie temporale presenta le caratteristiche seguenti, è consigliabile usare il rilevamento batch per visualizzare in anteprima i dati in una chiamata API.

  • Una serie temporale stagionale, con anomalie occasionali.
  • Una serie temporale con tendenza piatta, con picchi/cali occasionali.

Non è consigliabile usare il rilevamento anomalie batch per il monitoraggio dei dati in tempo reale o per i dati di serie temporali che non hanno le caratteristiche su indicate.

  • Il rilevamento batch crea e applica un solo modello e il rilevamento per ogni punto viene eseguito nel contesto dell'intera serie. Se le tendenze dei dati delle serie temporali aumentano e diminuiscono senza stagionalità, alcuni punti di modifica (cali e picchi nei dati) potrebbero non essere rilevati dal modello. Analogamente, alcuni punti di modifica meno significativi di quelli successivi nel set di dati potrebbero non essere considerati sufficientemente significativi da essere incorporati nel modello.

  • Quando si esegue il monitoraggio dei dati in tempo reale, il rilevamento batch è più lento rispetto al rilevamento dello stato di anomalia del punto più recente, a causa del numero di punti analizzati.

Per il monitoraggio dei dati in tempo reale, è consigliabile rilevare solo lo stato di anomalia del punto dati più recente. Applicando continuamente il rilevamento del punto più recente, il monitoraggio dei dati in streaming può essere eseguito in modo più efficiente e accurato.

L'esempio seguente descrive l'impatto che queste modalità di rilevamento possono avere sulle prestazioni. La prima immagine mostra il risultato del rilevamento continuo del punto più recente con stato di anomalia nei 28 punti dati precedentemente visualizzati. I punti rossi sono anomalie.

Immagine che mostra il rilevamento anomalie usando il punto più recente

Di seguito è riportato lo stesso set di dati usando il rilevamento anomalie batch. Il modello creato per l'operazione ha ignorato diverse anomalie, contrassegnate da rettangoli.

Immagine che mostra il rilevamento anomalie usando il metodo batch

Preparazione dei dati

L'API Rilevamento anomalie accetta i dati delle serie temporali formattati in un oggetto richiesta JSON. Una serie temporale può essere qualsiasi dato numerico registrato nel tempo in ordine sequenziale. È possibile inviare finestre dei dati delle serie temporali all'endpoint dell'API Rilevamento anomalie per migliorare le prestazioni dell'API. Il numero minimo di punti dati che è possibile inviare è 12 e il numero massimo è 8640. La granularità viene definita come frequenza con cui vengono campionati i dati.

I punti dati inviati all'API Rilevamento anomalie devono avere un timestamp UTC (Coordinated Universal Time) valido e un valore numerico.

{
    "granularity": "daily",
    "series": [
      {
        "timestamp": "2018-03-01T00:00:00Z",
        "value": 32858923
      },
      {
        "timestamp": "2018-03-02T00:00:00Z",
        "value": 29615278
      },
    ]
}

Se i dati vengono campionati a intervalli di tempo non standard, è possibile specificarlo aggiungendo l'attributo customInterval nella richiesta. Ad esempio, se la serie viene campionata ogni 5 minuti, è possibile aggiungere quanto segue alla richiesta JSON:

{
    "granularity" : "minutely", 
    "customInterval" : 5
}

Punti dati mancanti

I punti dati mancanti sono comuni nei set di dati delle serie temporali distribuiti in modo uniforme, in particolare in quelli con una granularità fine (un intervallo di campionamento ridotto, ad esempio, con i dati campionati ogni pochi minuti). Se manca meno del 10% del numero di punti previsti nei dati, non dovrebbe verificarsi un impatto negativo sui risultati del rilevamento. È consigliabile colmare le lacune nei dati in base alle relative caratteristiche, ad esempio sostituendo i punti dati di un periodo precedente oppure applicando l'interpolazione lineare o la media mobile.

Dati con distribuzione aggregata

L'API Rilevamento anomalie funziona meglio in una serie temporale distribuita uniformemente. Se i dati vengono distribuiti in modo casuale, è consigliabile aggregarli in base a un'unità di tempo, ad esempio al minuto, ogni ora o ogni giorno.

Rilevamento anomalie sui dati con modelli stagionali

Se si sa che i dati delle serie temporali hanno un modello stagionale (che si verifica a intervalli regolari), è possibile migliorare l'accuratezza e il tempo di risposta dell'API.

Specificando period quando si crea la richiesta JSON, è possibile ridurre fino al 50% la latenza del rilevamento anomalie. period è un numero intero che specifica approssimativamente il numero di punti dati richiesto dalla serie temporale per ripetere un modello. Ad esempio, una serie temporale con un punto dati al giorno avrà period impostato su 7 e una serie temporale con un punto all'ora (con lo stesso modello settimanale) avrà period impostato su 7*24. In caso di dubbi sui modelli dei dati, non è necessario specificare questo parametro.

Per ottenere risultati ottimali, fornire punti dati di quattro valori di period, più uno aggiuntivo. Ad esempio, i dati orari con un modello settimanale come descritto in precedenza devono fornire 673 punti dati nel corpo della richiesta (7 * 24 * 4 + 1).

Campionamento dei dati per il monitoraggio in tempo reale

Se i dati in streaming vengono campionati in un breve intervallo (ad esempio pochi secondi o minuti), l'invio del numero consigliato di punti dati può superare il numero massimo consentito dell'API Rilevamento anomalie (8640 punti dati). Se i dati mostrano un modello stagionale stabile, è consigliabile inviare un campione dei dati delle serie temporali secondo un intervallo di tempo più ampio, ad esempio in ore. Il campionamento dei dati in questo modo può anche migliorare notevolmente il tempo di risposta dell'API.

Passaggi successivi