Azure Ingestion

Decide by the customer’s intent, not by whether they already name a mechanism. Most customers won’t know the agent or any setup process — guiding them there is the whole point — so routing on keywords like “CloudWatch agent” is wrong. Route on what telemetry they are trying to collect.

Decide by intent

Ask what the customer actually wants to ingest:

• The telemetry their own application/service produces — the logs they write in their own code, and the metrics and traces their application emits. This is the supported path: load custom-telemetry.md and guide them through installing the CloudWatch agent on their Azure VM or AKS cluster.

• Telemetry their Azure resources emit on their own — resource/platform diagnostic logs and metrics they did not author, the Azure equivalent of AWS VPC flow logs or Route 53 query logs. This is not available today. Tell the customer this directly and stop. Do not offer the CloudWatch agent as an alternative or workaround for this: the agent only ships the customer’s own application telemetry and cannot collect telemetry that Azure resources emit on their own, so suggesting it here would be misleading.

If the intent is unclear, ask exactly one question to disambiguate:

Are you trying to send the telemetry your own application produces (the logs/metrics/traces from your code), or telemetry that your Azure resources emit on their own (like resource diagnostic logs)?

The former is supported today; the latter is not.

Then

For the customer’s own application telemetry, follow custom-telemetry.md.