Integrate Azure AI Anomaly Detector SDK for Java

Azure AI Anomaly Detector SDK for Java is a skill for building anomaly detection applications on Java, covering both univariate (single time series) and multivariate (300+ correlated signals, via a Graph Attention Network for inter-correlations) detection. It's installed as a Maven dependency:

<dependency>
  <groupId>com.azure</groupId>
  <artifactId>azure-ai-anomalydetector</artifactId>
  <version>3.0.0-beta.6</version>
</dependency>

Clients are created via AnomalyDetectorClientBuilder, authenticated with either an AzureKeyCredential or DefaultAzureCredential, and built as either a UnivariateClient or MultivariateClient depending on the detection type.

Use it for three univariate scenarios - batch detection (detectUnivariateEntireSeries, analyzing an entire series at once), streaming/last-point detection (detectUnivariateLastPoint, real-time on the latest data point), and change-point detection (detectUnivariateChangePoint, trend shifts) - and for multivariate anomaly detection, which follows a three-step train-then-infer-then-results workflow rather than a single call. It is not suited to time series with fewer than the minimum 12 data points required for univariate detection.

Univariate detection takes a list of TimeSeriesPoints plus UnivariateDetectionOptions (granularity, sensitivity 0-99) and returns per-point isAnomaly flags, or for the last-point case an expected value with upper/lower margins. Multivariate training takes a ModelInfo (blob-storage data source URL, start/end time, sliding window size 200-1000 based on pattern complexity, display name) via trainMultivariateModel, a long-running operation that returns a modelId whose status is checked with getMultivariateModel. Multivariate batch inference (detectMultivariateBatchAnomaly) and last-point inference (detectMultivariateLastAnomaly) both accept a topContributorCount to identify which variables contributed most to a detected anomaly, surfaced via AnomalyContributor/getInterpretation. Batch inference itself is asynchronous: the initial call returns a resultId, which is then polled via getBatchDetectionResult until the anomaly states are ready. Model lifecycle is managed with listMultivariateModels and deleteMultivariateModel.

Authentication reads AZURE_ANOMALY_DETECTOR_ENDPOINT and AZURE_ANOMALY_DETECTOR_API_KEY from the environment, or falls back to DefaultAzureCredential. Multivariate training and inference data sources are blob storage URLs with SAS tokens. Error handling wraps calls in a catch for HttpResponseException, reading the status code and message. Change-point results carry a getConfidenceScores() value per detected point, batch multivariate results carry a severity score per anomaly, last-point multivariate results are built from a list of named VariableValues (variable name, timestamps, values), and models are listed as a PagedIterable<AnomalyDetectionModel> for iterating an account's trained models alongside their status.

Java developers building time-series monitoring or anomaly-detection features who need guidance choosing between univariate and multivariate detection, tuning sensitivity and sliding-window size, and following the model train/infer/manage lifecycle for multivariate use cases.