Distinguish Logs ingestion authorization failures from a wrongly addressed request

Source facts

The Logs ingestion API addresses a DCR by immutableId, not its display name. Microsoft’s custom-table workflow grants the sending application Monitoring Metrics Publisher on that DCR, providing Microsoft.Insights/Telemetry/Write. Role propagation can take up to 30 minutes; an early request can return 403. Microsoft Learn.

For the tutorial’s 404 case, Microsoft directs operators to check the immutable ID and the table’s _CL suffix, with a stream named Custom-<TableName_CL>. Its portal workflow requires a DCE; template or Logs management API creation can instead use a DCR endpoint. Microsoft Learn.

Applicability

Review applications sending data through the Azure Monitor Logs ingestion API using the documented DCE-based custom-table workflow. Do not apply its URI construction blindly to another ingestion method.

DSE recommendation

DSE recommends comparing the actual request address with the DCR JSON and intended table before changing permissions. For an authorization failure, verify the exact sending identity, assignment scope and elapsed propagation time. Keep the immutable identifier separate from friendly names in configuration records. Do not respond to a not-found error by granting subscription-wide administration.

Verification

Send a harmless, identifiable record through the intended client after the authorized correction. Preserve the response status and nonsensitive address components, then confirm the expected row reached the target table. If ingestion succeeds but fields are wrong, open a separate transformation investigation instead of continuing to change identity permissions. Record the corrected boundary without storing a bearer token or client secret.

Official references

Microsoft Learn: Logs ingestion API portal tutorial.