Ingest Logs to Azure Monitor with Java SDK

Azure Monitor Ingestion SDK for Java sends custom logs to Azure Monitor via the Logs Ingestion API, routed through a Data Collection Rule (DCR), authenticated with DefaultAzureCredential against a Data Collection Endpoint (DCE). It requires the DCE, a DCR, a Log Analytics workspace, and a target table (custom, or built-in tables like CommonSecurityLog, SecurityEvents, Syslog, WindowsEvents) already provisioned.

LogsIngestionClient.upload() (or the async LogsIngestionAsyncClient for reactive pipelines) sends a list of log objects to a DCR ID and stream name (e.g. Custom-MyTable_CL) - each log object's fields must match what the DCR's transformation expects, and most tables require a TimeGenerated timestamp field. For large collections, LogsUploadOptions.setMaxConcurrency() uploads in parallel, and a LogsUploadErrorConsumer handles partial upload failures per-batch - logging and continuing, or re-throwing to abort the remaining uploads. Log entries are plain Java objects with getters for JSON serialization.

Use it when an application needs to push custom application logs, security events, or other structured data into Azure Monitor/Log Analytics for querying and alerting, rather than relying only on platform-emitted diagnostic logs. Querying what you've ingested is a separate concern handled by the azure-monitor-query SDK's LogsQueryClient, not this ingestion client.

Input is a list of log objects whose fields match the DCR's expected schema, targeted at a specific DCR ID and stream name. Output is a successful upload confirmation or, for large batches, a per-log failure report via the error consumer. Install it with:

<dependency>
    <groupId>com.azure</groupId>
    <artifactId>azure-monitor-ingestion</artifactId>
    <version>1.2.11</version>
</dependency>

Its own best practices: batch logs together rather than uploading one at a time, set maxConcurrency for large uploads, handle partial failures explicitly with an error consumer rather than assuming an upload either fully succeeds or fully fails, make sure log entry fields match the DCR's transformation schema (especially a TimeGenerated field), reuse a single client instance throughout the application, and use the async client for high-throughput reactive pipelines. Errors surface as HttpResponseException - 403 typically means a DCR permission or managed-identity problem, 404 means the DCE endpoint or DCR ID is wrong.

It writes into an Azure Monitor Data Collection Rule targeting a Log Analytics workspace table, and pairs with the separate azure-monitor-query SDK's LogsQueryClient for reading back what was ingested (e.g. MyTable_CL | where TimeGenerated > ago(1h)).

Java developers pushing custom application or security logs into Azure Monitor for centralized querying and alerting, who need reliable batched uploads with concurrency and partial-failure handling.