Upgrade to the new monitoring experience - no data

Question

Upgrade to the new monitoring experience - no data

MarcVanderhaegen 306

Hello,

We have set up the 'new monitoring experience' for two arc enabled servers but even 16 hours later there is no data ingested.
The setup is pretty straightforward, you click 'Configure', in the Capabilities, the 'Preview OpenTelemetry metrics' check box is checked and you select the Azure Monitor Workspace (I created a new one when setting up the first machine), you click 'Review + enable' and it is done.

For each machine I got a message 'Onboarding has completed. Data may take a few minutes to start flowing while configuration syncs.' .
So far so good.
But, 16 hours later, there is still no data in the workspace.
I don't know if this could be the problem but when I check the DCRs, I see that a DCR is created for each machine and the platform type of the DCR is set to 'Linux' ! (my test servers are Windows machines)
I can't find any way to change that setting.

If I try to create a new DCR, I can't find the Microsoft-OtelPerfMetrics in the Data source list.

Any ideas if the cause of having no data can be related to the wrong type for the DCRs and how I can correct that ?

Thanks for your help

Bharath Y P 10,530 Reputation points Microsoft External Staff Moderator

2025-10-23T07:56:54.9566667+00:00
Hello MarcVanderhaegen,

You're having trouble with the new monitoring experience on your Arc-enabled servers, not ingesting data even after a significant wait time.

It seems like you've done the initial setup correctly by enabling the "Preview OpenTelemetry metrics" and linking it to a newly created Azure Monitor Workspace. The completion message is a good sign that the onboarding process was initiated successfully.

As you mentioned, the Data Collection Rules (DCRs) are set to 'Linux' while your servers are Windows, it is a factor that could be affecting data collection. DCR should match the operating system of the virtual machines they're monitoring.

The absence of "Microsoft-OtelPerfMetrics" when creating a new DCR could indicate that the necessary monitoring components for OpenTelemetry metrics are not correctly configured or available for Windows, which might be linked to the DCR type issue.

Here are the steps you can try to resolve your issue:

Check DCR Configuration: You can follow the below document to edit DCR: Create data collection rules (DCRs) in Azure Monitor - Azure Monitor | Microsoft Learn

If you are unable to edit or perform modification, the simplest path to correcting the issue is to delete the faulty configuration and create new ones ensuring the correct operating system type is selected.

Remove DCR Association (DCRA):

Go to your Azure Arc-enabled server resource in the Azure portal.

Navigate to Settings > Extensions + applications.

Locate the AzureMonitorWindowsAgent extension.

There should be a link or section to view Data Collection Rules. Disassociate or remove the link to the incorrect Linux DCR.

To delete the Incorrect DCRs:

Go to Azure Monitor > Data Collection Rules

Identify and delete the DCRs with platform type 'Linux' that are assigned to Windows servers

Create New DCRs for Windows: Use Azure CLI or ARM templates to create a DCR with platform type set to Windows

Reassign the New DCRs

Assign the new Windows-based DCRs to your Arc-enabled servers

Confirm that the Azure Monitor Agent (AMA) is installed and running

Verify Agent Installation: Ensure that the Azure Monitor Agent (AMA) is properly installed on your Windows machines, as the monitoring capabilities you're looking for depend on it.

Install and Manage the Azure Monitor Agent - Azure Monitor | Microsoft Learn

Azure Monitor Agent Overview - Azure Monitor | Microsoft Learn

Review Logs: Access Log Analytics and run specific queries to see if any log entries are being recorded at all: Perf | where ObjectName == "Processor" and Computer == "<your_server_name>" | take 10

Update DCR and Check Metrics: Make sure all updates are applied, including any necessary agent updates or Azure Monitor updates. After making these changes, wait to see if data starts showing up after few minutes.

The reason you cannot find Microsoft-OtelPerfMetrics in the standard DCR creation wizard is that these OpenTelemetry metrics are considered custom metrics and are not exposed in the simple wizard UI. You would need to create a DCR with Platform Type: Windows and ensure the data source section (dataSources) includes the correct stream for the metrics extension, targeting the Azure Monitor Metrics destination.

You can follow the below reference: Migrate to VM Insights OpenTelemetry - Azure Monitor | Microsoft Learn

Migrate to VM Insights OpenTelemetry - Azure Monitor | Microsoft Learn

If you still encounter issues, could you please help us on these below questions:

Have you installed and configured the Azure Monitor Agent on the Windows machines?

Are there any error messages or warnings in the Azure portal related to the monitoring setup?

Have you checked the Log Analytics workspace to see if any data is being recorded from the servers?

I hope this helps you resolve the issue effectively!
MarcVanderhaegen 306 Reputation points

2025-10-23T09:36:54.7766667+00:00
Hello @Bharath Y P

I have tried to create a DCR through an ARM template but it doesn't seem to work.

Yes, now, it says Windows, but the data sources are not displaying correct values and if I open the DCR it says that the data source is Microsoft-OTelPerfMetrics :

I applied this DCR to a machine and waited .

Unfortunately, still nothing for the Metrics based visualization, it says 'no events'.

Applying this DCR also 'killed' the insights through log analytics :

And the message to onboard the machine to the new monitoring experience is back.

So the DCR created, even if the validation was ok, is not good.

To restore the working of log based visualization I had to delete the manually created DCR.

To answer your question :

the Azure Monitor Windows Agent is installed on our machines

there is no error message, the onboarding is always 'successful'

in the log analytics wokspace, data are still ingested but in the azure monitor workspace, no data are ingested (that may be normal because of the linux type DCRs)
Bharath Y P 10,530 Reputation points Microsoft External Staff Moderator

2025-10-24T06:57:29.6466667+00:00
Hello MarcVanderhaegen, thank for the update, based on screenshot, it seems that the DCR is using Microsoft-OTelPerfMetrics as a data source, but the telemetry still isn’t flowing. Also, if a Data Collection Rule (DCR) only includes the Microsoft-OTelPerfMetrics stream, it will collect OpenTelemetry metrics but stop collecting standard logs like performance data and event logs. This can break the usual insights you get in Log Analytics.

Ensures all required streams and destinations are included.

Include both metrics and logs in the DCR, your streamDeclarations should include both Microsoft-OTelPerfMetrics that is Azure Monitor Metrics and Perf, InsightsMetrics, and WindowsEventLogs that is Log Analytics

You can follow the below reference:Migrate to VM insights OpenTelemetry - Azure Monitor | Microsoft Learn
Bharath Y P 10,530 Reputation points Microsoft External Staff Moderator

2025-10-28T09:27:51.13+00:00

Hello MarcVanderhaegen, kindly let us know if the provided information that helps you, If you need any further assistance, please feel free to reach out. Thanks,
MarcVanderhaegen 306 Reputation points

2025-10-28T09:29:45.5033333+00:00

Hello @Bharath Y P

I completely understand that seeing only Microsoft-OTelPerfMetrics would tell that no metrics ingestion would be done through Log Analytics but when you configure the new monitoring experience, you clearly configure that the system you continue the ingestion into the Log Analytics workspace :

But also, the servers are still in the resources list from the DCR that configures the ingestion into Log Analytics so it should never stop sending data there.
At the moment, it is still not working because the DCR created for each machine is still for Linux and not Windows :

Marc
MarcVanderhaegen 306 Reputation points

2025-10-28T09:33:48.8733333+00:00

Hello, sorry but there is no change to the situation. It is not working at all for us. As soon as the DCR is created through an arm template and configure on a Windows type, it is not working and breaks the ingestion through Log Analytics. And when the DCR is created through the portal during the onboarding, the type is set on Linux and it is not working.
Lucas, Stephen (Admin) 0 Reputation points

2025-11-04T14:42:00.9533333+00:00

@MarcVanderhaegen I'm curious if you were able to resolve your VM Insights OpenTelemetry issues? I too was running into the same issues, but I did manage to get it working for both Azure VMs and for Azure ARC VMs as well.

If you got it working, great! If not, let me know and I can tell you what I did to get it working.

Thanks,

Steve
MarcVanderhaegen 306 Reputation points

2025-11-04T15:00:20.79+00:00

Hello Steve,
Unfortunately no, we were not able to solve the problem.
The portal keeps creating linux type DCRs and trying to create a DCR with an arm template is not working.
We have a case at Microsoft for a week now but we haven't heard from them.
I am really interested on how you solved this.
Thanks.
Marc
Lucas, Stephen (Admin) 0 Reputation points

2025-11-04T17:46:28.1366667+00:00
No problem.

The first thing I want to address is, 'The portal keeps creating linux type DCRs'

This is also happening for me as well and I believe it's a bug where the 'Kind' was somehow implicitly set to 'Linux'. I'm sure Microsoft will work on it. But this issue will not prevent it from working.

I do see your screen shots and see some DCRs etc. but for the sake of being on the same page it might be best to start over.

Step 1:

In the Portal go to (AMW) Azure Monitor Workspaces. You will see AMWs like: 'Default-VMInsights-<region>-<guid>' unless you created custom AMWs like I did (if not, I’ll explain below).

While in Azure Monitor Workspaces – DELETE ALL 'Default-VMInsights-<region>-<guid>'

Deleting will not hurt anything and will make it easier going forward to be on the same page. Also, keep in mind those AMWs were and are AUTOMATICALLY created when you go to VM > Insights and click Configure to configure/enable (OTel) OpenTelemetry, so again, ok to delete.

NOTE: for me, 'Default-VMInsights-<region>-<guid>' is messy and a little confusing so before I enabled OTel I created my own custom standard Azure Monitor Workspaces (I did a little research and confirmed you can use custom AMW's for OTel).

NOTE: if you already enabled OTel on some VMs and are using 'Default-VMInsights-<region>-<guid>' don't worry if/when you delete them from the steps above as it resets the VM OTel configuration to start over (explained below).

If you choose to create custom AMW's, in the Portal go to: Azure Monitor Workspaces and create as many as needed, for me one per sub. e.g.: DCR-VMI-OTEL-Monitor-<subscription>

NOTE: whether you use 'Default-VMInsights-<region>-<guid>' or create custom AMWs Azure will automatically create corresponding DCR and (DCE) Data Collection Endpoints. If you create custom AMWs then the DCR and DCE will have the same name as the AMW so again that’s why I like the custom standard AMW, e.g.: DCR-VMI-OTEL-Monitor-<subscription>

NOTE: When you Configure/Enable OTel for VM > Insights you can then manually select the CUSTOM AMW you created for that subscription (explained below).

Step 2:

A MUST for me anyway. As you are probably aware if your VMs were/are running the classic VM Insights your VMs are already running the 'AzureMonitorWindowsAgent'.

Here is one thing that definitely was a problem for me. Now keep in mind I could not find any KB or doc stating this is required (thanks Microsoft!) and I found out myself because I was just trying anything - but update the 'AzureMonitorWindowsAgent' extension to at least version 1.38.1.0 (I believe Microsoft just released 1.39.0.0 on or after 11/01/2025). Last week all my VMs and ARC VMs were running version 1.36.x.x and OTel would NOT work until after updating to version 1.38.1.0. NOTE for Linux O/S a version shown might only be v.1.37.x.x so use that, otherwise it will be 1.38.1.0 or newer.

Step 3:

Next, this is a MUST. (I could not find a KB, doc., etc.) If you were/are already running the classic VM Insights (like I am) using DCR 'MSVMI-<dcr_name>', go to the Portal > Data Collection Rules, click on the DCR Rule for those VMs. On the left click Resources blade search for the VM or select all VMs and select disassociate. Disassociate the VMs from the DCR otherwise OTel will assume the VM is running classic Insights.

Step 4:

Go to Data Collection Rules and for EVERY VM you enabled OTel, DELETE those DCR's. e.g.: 'MSVMOtel-<region>-<servername>

New VM OTel DCR's will be re-created, so again, ok to delete.

Configuration Pre-check:

All 'Default-VMInsights-<region>-<guid>' have been deleted (step 1)

OPTIONAL: if (IF) you created custom AMWs (again, not required as you can use, 'Default-VMInsights-<region>-<guid>' ) (step 1)

You updated 'AzureMonitorWindowsAgent' extension to at least version 1.38.1.0 (or newer) (step 2)

Azure VMs

Azure ARC VMs

Disassociate VM(s) from classic 'MSVMI-<dcr_name>' DCR rule (step 3)

All OTel VM/ARC VM DCRs have been deleted (step 4)

Step 5:

NOTE: It doesn’t matter if you choose to use 'Default-VMInsights-<region>-<guid>' or if you use custom AMWs the same applies for both when configuring VM OTel.

Choose a VM > Insights > select Configure

NOTE the two check boxes:

Box 1: Leave the box checked for OpenTelemetry and if you did create a custom AMW it will either already be selected or you can click the drop-down and select the custom AMW. NOTE: in my case since I manually created custom AMWs and deleted all 'Default-VMInsights-<region>-<guid>' my custom AMW is preselected with no drop-down as it’s not needed. If not using a custom AMW then just leave the 'Default-VMInsights-<region>-<guid>' selected.

Box 2: This is a MUST! For classic Insights UNCHECK the box next to Classic log-based metrics. NOTE: OTel will NOT work if the VM is still using Classic log-based metrics. I do not know why that check box is even an option when enabling OTel.

Click Next or Review + Enable

Click Enable

Step 6: Only for ARC Machines

Now the last thing this, so far, ONLY applies to ARC VMs (I’m not sure why). As you know when you enable OTel for a VM and/or ARC VMs it automatically creates a DCR like: 'MSVMOtel-<region>-<vmname>'. This is also where we see ‘Kind’ = Linux even though the O/S is Windows.

In the Portal go to Data Collection Rules

For each ARC VM select/click the DCR: MSVMOtel<region><servername>

At the top of the Overview page click on 'Configure DCE' tab

Click the drop-down menu

Option 1 if custom: Select custom AMW for that subscription

OR option 2: Select - ‘'Default-VMInsights-<region>-<guid>’ AMWs

Click Save

Finished!

KEEP IN MIND. As I’m sure you know, making changes in Azure like this can be slow when updating at the back-end. And from my experience enabling OTel is no exception. In some cases Azure VMs took up to 30 minutes before data was being ingested. And especially for some of my ARC VMs (mostly because they are really remote) it took an hour before OTel was reporting data. So yeah, there’s that.

I realize this is a lot but hopefully all that makes sense. If you have any questions or concerns don’t hesitate to reach out. Hopefully you can get this working.

Let me know how it goes.

Best,

Steve
Lucas, Stephen (Admin) 0 Reputation points

2025-11-04T18:36:13.04+00:00

Hey Marc,

Not sure if you read through and have started this but I just remembered another step. I added another step so steps 4 - 6 changed.

sry for the confusion.

Steve
MarcVanderhaegen 306 Reputation points

2025-11-04T23:07:14.95+00:00

Hello Steve

Thank you very much for these detailed steps.

I just tried all the steps you explained on 2 machines but even after 2/3 hours... there is still the message 'no metrics detected'.

So, for the 2 machines :

All the extensions are up to date.

I deleted the associated MSVMOtel-westeurope-<machinename> dcr if one was found.

I removed the association to the MSVMI dcr (used by the classic log-based metrics)

I kept 2 other DCRs associated, one for the windows event logs and the other one for the ChangeTracking.

I configured the Insights for the 2 machines with only the Open Telemetry metrics. (i unchecked the log-based metrics)

I configured each newly created DCR with the DCE pointing to our azure monitor workspace.

And then I waited..... but nothing.

I will wait until tomorrow morning.

Thanks again for your help.

Marc
MarcVanderhaegen 306 Reputation points

2025-11-05T07:41:09.35+00:00

Hello Steve,

Well, even after a night, there are no metrics ingested for the 2 machines.
I have started over; I have deleted the azure monitor workspace, the DCRs.

This time I have removed all the DCRs from a machine.
I onboarded a machine with only the OpenTelemetry metrics and used the default amw :

After a few seconds the machine was onboarded :

I checked the DCRs and there is only one applied to the machine.
I modified the DCR to include the DCE like you did ( I don't understand why it is needed because in the docs it says it is only required for firewall logs and container insights, but ok, if it worked for you, let's try it).

But unfortunately, the result is the same :

Nothing is ingested.

Marc
MarcVanderhaegen 306 Reputation points

2025-11-05T10:44:05.5333333+00:00

Hello,
I found a log called himds_otel.log which is filled with errors like these ones :

The first error is :

time="2025-11-04T22:01:15+01:00" level=error msg="Failed to upload telemetry: &{ErrorReason:<html> <head><title>503 Service Temporarily Unavailable</title></head> <body> <center><h1>503 Service Temporarily Unavailable</h1></center> <hr><center>nginx</center> </body> </html> ErrorDesc: ErrorCode:[503] Timestamp:2025-11-04 22:01:15.745043 +0100 CET m=+140402.375629401 TraceID: CorrelationID:7c246981-43d3-461e-9cde-d9cffa4eec8a}"

The second error is :

time="2025-11-05T10:23:45+01:00" level=error msg="Failed to upload telemetry: &{ErrorReason:error sending request to the collector: Post "https://gbl.his.arc.azure.com/arc-telemetry/v1/metrics": context deadline exceeded (Client.Timeout exceeded while awaiting headers) ErrorDesc: ErrorCode:[500] Timestamp:2025-11-05 10:23:45.0559411 +0100 CET m=+10874.293433801 TraceID: CorrelationID:556dbe1d-4939-48ae-8bd8-77318a97fc1e}"
Lucas, Stephen (Admin) 0 Reputation points

2025-11-05T12:49:55.2966667+00:00

hey Marc,

as you said, "I modified the DCR to include the DCE like you did ( I don't understand why it is needed because in the docs it says it is only required for firewall logs and container insights"

I read the exact same and agree it makes no sense why it seems to fix ARC Machines.

I will admit onboarding ARC Machines is a bit more of a pain than Azure VMs. I do have one VM in particular that I onboarded yesterday morning and is still not working but all the other ARC Machines I onboarded are working just fine.

here is a screen shot of a working ARC Machine I onboarded late yesterday after I uploaded the doc.

just got in. let me think about it a few minutes as i sip down some coffee and wake my brain up.

Steve
Lucas, Stephen (Admin) 0 Reputation points

2025-11-05T13:00:05.8466667+00:00

Marc,

have you configured OTel for any of your Azure VMs?
MarcVanderhaegen 306 Reputation points

2025-11-05T13:03:21.8566667+00:00

Steve,

We don't have any Azure VM at the moment.
Lucas, Stephen (Admin) 0 Reputation points

2025-11-05T13:10:31.44+00:00
because i'm lazy i threw both logs in copilot

the second error in particular might be a bit more helpful

time="2025-11-05T10:23:45+01:00" level=error msg="Failed to upload telemetry: &{ErrorReason:error sending request to the collector: Post "https://gbl.his.arc.azure.com/arc-telemetry/v1/metrics": context deadline exceeded (Client.Timeout exceeded while awaiting headers) ErrorDesc: ErrorCode:[500] Timestamp:2025-11-05 10:23:45.0559411 +0100 CET m=+10874.293433801 TraceID: CorrelationID:556dbe1d-4939-48ae-8bd8-77318a97fc1e}"

This error message indicates that a telemetry upload attempt to Azure's ARC telemetry endpoint failed due to a timeout. Here's a breakdown of the key components:

🧾 Error Summary

Timestamp: 2025-11-05T10:23:45+01:00

Error Level: error

Error Message: Failed to upload telemetry

Reason: error sending request to the collector

HTTP Method & URL: POST https://gbl.his.arc.azure.com/arc-telemetry/v1/metrics

Cause: context deadline exceeded → The client timed out while waiting for a response header.

HTTP Error Code: [500] → Internal Server Error from the server

Trace Info: CorrelationID:556dbe1d-4939-48ae-8bd8-77318a97fc1e

🔍 What It Means

The client attempted to send telemetry data to Azure ARC but didn’t receive a response in time.

The server responded with a 500 error, indicating a problem on the server side.

The context deadline exceeded suggests the request took too long, possibly due to network latency, server overload, or misconfiguration.

🛠️ Possible Fixes

Retry logic: Ensure your telemetry client has retry mechanisms with exponential backoff.

Timeout settings: Review and possibly increase the client timeout threshold.

Network diagnostics: Check for connectivity issues between your system and the Azure endpoint.

Azure status: Verify if Azure ARC telemetry services are experiencing downtime or issues.time="2025-11-05T10:23:45+01:00" level=error msg="Failed to upload telemetry: &{ErrorReason:error sending request to the collector: Post "https://gbl.his.arc.azure.com/arc-telemetry/v1/metrics": context deadline exceeded (Client.Timeout exceeded while awaiting headers) ErrorDesc: ErrorCode:[500] Timestamp:2025-11-05 10:23:45.0559411 +0100 CET m=+10874.293433801 TraceID: CorrelationID:556dbe1d-4939-48ae-8bd8-77318a97fc1e}" This error message indicates that a telemetry upload attempt to Azure's ARC telemetry endpoint failed due to a timeout. Here's a breakdown of the key components:
🧾 Error Summary

Timestamp: 2025-11-05T10:23:45+01:00

Error Level: error

Error Message: Failed to upload telemetry

Reason: error sending request to the collector

HTTP Method & URL: POST https://gbl.his.arc.azure.com/arc-telemetry/v1/metrics

Cause: context deadline exceeded → The client timed out while waiting for a response header.

HTTP Error Code: [500] → Internal Server Error from the server

Trace Info: CorrelationID:556dbe1d-4939-48ae-8bd8-77318a97fc1e

🔍 What It Means

The client attempted to send telemetry data to Azure ARC but didn’t receive a response in time.

The server responded with a 500 error, indicating a problem on the server side.

The context deadline exceeded suggests the request took too long, possibly due to network latency, server overload, or misconfiguration.

🛠️ Possible Fixes

Retry logic: Ensure your telemetry client has retry mechanisms with exponential backoff.

Timeout settings: Review and possibly increase the client timeout threshold.

Network diagnostics: Check for connectivity issues between your system and the Azure endpoint.

Azure status: Verify if Azure ARC telemetry services are experiencing downtime or issues.
MarcVanderhaegen 306 Reputation points

2025-11-05T13:55:02.59+00:00

:) I tried it also but it didn't help. It always says that the error is on the remote side (so on Microsoft side).
Would it be possible for you to open the log file c:\programdata\azureconnectedmachineagent\log\himds_otel.log to see where your machine is sending the data.
On our side it is https://gbl.his.arc.azure.com/arc-telemetry/v1/metrics
Lucas, Stephen (Admin) 0 Reputation points

2025-11-05T14:13:47.82+00:00

Marc,

Since you've onboarded ARC Machines i'm guessing you've read through the required URLs for ARC to function? for our environment we had to whitelist about 15 or so URLs for our ARC Machines (all our ARC machines are remote) so this was a challenge for us.

The reason I ask is your log shows:
ErrorReason:error sending request to the collector: Post "***https://gbl.his.arc.azure.com/arc-telemetry/v1/metrics***": context deadline exceeded (Client.Timeout exceeded while awaiting headers

the URL: https://gbl.his.arc.azure.com is required for ARC. this URL needs to be whitelisted in your Firewall or Proxy see KB: https://learn.microsoft.com/en-us/azure/azure-arc/network-requirements-consolidated?tabs=azure-cloud#azure-arc-enabled-kubernetes-endpoints

again, i'm sure you are aware of these and it maybe it is whitelisted but if it's not this could be your issue.
Lucas, Stephen (Admin) 0 Reputation points

2025-11-05T16:19:44.86+00:00

Marc,

Since you've onboarded ARC Machines i'm guessing you've read through the required URLs for ARC to function? for our environment we had to whitelist about 15 or so URLs for our ARC Machines (all our ARC machines are remote) so this was a challenge for us.

The reason I ask is your log shows:
ErrorReason:error sending request to the collector: Post "***https://gbl.his.arc.azure.com/arc-telemetry/v1/metrics***": context deadline exceeded (Client.Timeout exceeded while awaiting headers

the URL: https://gbl.his.arc.azure.com is required for ARC. this URL needs to be whitelisted in your Firewall see KB: https://learn.microsoft.com/en-us/azure/azure-arc/network-requirements-consolidated?tabs=azure-cloud#azure-arc-enabled-kubernetes-endpoints

again, i'm sure you are aware of these and it maybe it is whitelisted but if it's not this could be your issue.
MarcVanderhaegen 306 Reputation points

2025-11-05T16:26:13.5766667+00:00

Steve,

Sorry, I was not able to answer faster, the post was locked.
Yes, the url is already in our whitelist, as it is a prerequisite for Azure Arc/Monitor.
I have asked my boss if it is possible to have an Azure VM to try if we would have the same problem. Waiting for an answer.
Lucas, Stephen (Admin) 0 Reputation points

2025-11-05T16:36:57.2366667+00:00

Marc,

in my previous post I mentioned I had an ARC Server that should have been working but wasn't. however, the server was rebooted and after about 30-45 mins the OpenTelemetry started working. keep in mind I enabled OTel yesterday morning and just now started working. I'm not saying that will fix your issue but I wanted to pass that along as maybe something to try.

Steve
MarcVanderhaegen 306 Reputation points

2025-11-05T16:41:24.73+00:00

Steve,
Already tried that too, the servers were rebooted multiple times.
I must say that I am running out of ideas.
It seems so easy to put in place but in fact it's the contrary.

Marc
Lucas, Stephen (Admin) 0 Reputation points

2025-11-05T17:36:01.8733333+00:00
something to check:

go to the portal > Azure Monitor Workspace

Start with the first AMW and open it.

yours might be: 'Default-VMInsights-<region>-<guid>'

i'm using custom AMWs: 'dcr-vmi-otel-monitor-sub'

On the left bar click the Networking blade

if not already done, select the radial button: Enable public access from all networks.

Repeat for all AMWs

When I set it to 'Disable' it broke all my OTel data ingestions. I have since set it back to 'Enable' all is well again.

now if this does fix your issue but would prefer to Disable to the public then as you know you will need to create a private endpoint for each AMW.

After changing to Enable allow some time to hopefully start working. It took over 30 minutes before ingestion started working again.
MarcVanderhaegen 306 Reputation points

2025-11-05T17:42:55.3+00:00

I just checked, it is set on 'enable' by default.
Lucas, Stephen (Admin) 0 Reputation points

2025-11-05T17:53:43.71+00:00

have you checked the logs on the server? especially the 'himds_otel' log

C:\ProgramData\AzureConnectedMachineAgent\Log\himds

C:\ProgramData\AzureConnectedMachineAgent\Log\himds_otel
Lucas, Stephen (Admin) 0 Reputation points

2025-11-05T18:53:49.31+00:00

Something I was thinking about is for the Classic Insights. it is possible that a VM can be assigned to more than one 'MSVMI' DCR even if it's in a different subscription.

I know this sounds a bit out there, but I would check ALL your 'MSVMI' DCRs for those 2 VMs you are testing OTel on. I don't mean the 2 other DCRs associated, one for the windows event logs and the other one for the ChangeTracking. UNLESS they are somehow also configured for VM Insights. If they are, this could be a problem, e.g.:

I would just double check every MSVMI and ensure those two Servers are not associated to any of those DCRs.

I'm running out of ideas. :(
MarcVanderhaegen 306 Reputation points

2025-11-05T20:13:21.49+00:00

I had removed the machines from all DCRs prior configuring the Insights to be sure to start from a clean situation.

I am also out of ideas. I will stop bothering you, I am going to wait for Microsoft to contact us about the case.
Thanks a lot for all your help.

Marc
Lucas, Stephen (Admin) 0 Reputation points

2025-11-06T11:54:22.9+00:00

hey Marc,

It's no bother at all. When you get it working and wouldn't mind sharing, I would be curious to know what you did to resolve it. Thanks!

Best,

Steve
MarcVanderhaegen 306 Reputation points

2025-11-06T12:16:39.2533333+00:00

Hello Steve,
No problem, as soon as we have it working i will post an update.
Thanks

Marc
Lucas, Stephen (Admin) 0 Reputation points

2025-11-14T19:34:58.7166667+00:00

hi Marc,

wanted to check in and see if you made any headway.

I want to drop an easy possible fix on you to see if this works if still not working.

even though my OTel is working I did have some problems with some of the AMA extensions not able to update to 1.38 or 1.39. After reading through a couple of these forums I read where someone updated the 'Azure Connected Machine Agent' aka the Azure ARC Agent on the Server itself.

So I took a chance and downloaded the most current version: AzureConnectedMachineAgent_v1.58.x

I ran the .msi and wouldn't you know it, it fixed my issues. Also, it seems to get OTel ingesting data faster after enabling it.

to download and see the full list go here:
https://www.catalog.update.microsoft.com/Home.aspx

then in search: AzureConnectedMachineAgent

You will then see the full list of the agents and versions. just pick the version you want and download

then click the blue *.cab link

after you download you just need to extract it.

then run in on the server.

not saying it will fix your issues, but it also won't hurt either.
fingers crossed!
MarcVanderhaegen 306 Reputation points

2025-11-15T11:14:26.4266667+00:00

Hello Steve,
Thanks for your message.
I was away from office for a few days, I still haven't had any news from our MS case.

I need to check again but on our side I didn't detect any problem upgrading AzureMonitorWindowsAgent to 1.39.
On the other hand, the MicrosoftDefenderForSQL extension is impossible to upgrade; we always get the error message :
"Failing to communicate with Defender. Error: SQL Channel Error: Failing reason: ExportClient Error: Failed to reach Defender endpoint. Exception: No such host is known. (defender-for-databases.westeurope.arcdataservices.com:443).\r\nInner Exception(1): No such host is known...\r\nAMA Channel Error: Failed to fetch configuration from AMA for all available sets of extension names."
Even if we delete the extension, it gets automatically reinstalled (so the system can access the source files) but the upgrade always fails on every servers with SQL installed.
But that's another story....

For Insights, I just tried to restart the onboarding process into Monitor and there is a change for the newly created DCR, the type is now 'All' :

I did that 1 hour ago but at the moment there is still no data : /

I hope it is just a question of time now.

For the Azure Connected Machine Agent, I will try the upgrade on Monday. I didn't saw anything related to the problem in the release notes but as you said .... fingers crossed.

Marc
MarcVanderhaegen 306 Reputation points

2025-11-16T09:08:11.7033333+00:00

Unfortunately more than 12 hours later still nothing. I had activated the monitoring on the azure monitor workspace and it tells me that until now no data have been ingested.
MarcVanderhaegen 306 Reputation points

2025-11-17T14:47:53.2633333+00:00

Hello Steve,

I have upgraded the Azure Connected Machine agent but it doesn't change anything; no data are ingested in the amw.
MarcVanderhaegen 306 Reputation points

2025-11-18T05:46:32.3933333+00:00

Hello Steve,
Unfortunately still no news about the OTel problem but yesterday I have noticed a more serious problem in Arc : the status of the machines is different between Azure Arc - Machines and the detailed view of a machine.
The problem is not occuring on all machines but still on a lot of them.

For example :

It means that a machine that would go offline would be undetected because a query in log analytics for the heartbeat still shows the machine up and running (the MS engineer confirmed that the data source in Azure Arc - Machines and in the detailed view of a machine is not the same).
It is not only the field 'status' that may be different, I have also noticed a difference for the 'agent version'/'operating system version' fields.
I had to open a case that has now been escalated to the product group as a 'bug'.

For us, the problem seem to have started yesterday at around 09h00 (GMT+1).

Have you also noticed this problem ?
Lucas, Stephen (Admin) 0 Reputation points

2025-11-18T12:33:55.98+00:00

hey Marc,

yes, I actually have that issue on some of my ARC machines. the one thing that is slightly different from yours is the ones that show 'offline' are on the view of the list of servers. however, when you select an ARC machine then on the Overview page it shows as 'connected'.

Even though the connection status is out of sync the OTel is still working so whatever the issue I don't think it has any impact.
MarcVanderhaegen 306 Reputation points

2025-11-18T13:21:33.27+00:00

Hello Steve,

Thanks for your answer.
The problem goes in both ways (really online, shown offline / really offline, shown online); they are still looking into it. And they inform me that it has no impact on other Azure services, except the reporting through log analytics.

Answer accepted by question author

0 additional answers

Your answer

MarcVanderhaegen 306 Reputation points

2025-10-23T09:36:54.7766667+00:00

Hello @Bharath Y P

I have tried to create a DCR through an ARM template but it doesn't seem to work.

Yes, now, it says Windows, but the data sources are not displaying correct values and if I open the DCR it says that the data source is Microsoft-OTelPerfMetrics :

I applied this DCR to a machine and waited .

Unfortunately, still nothing for the Metrics based visualization, it says 'no events'.

Applying this DCR also 'killed' the insights through log analytics :

And the message to onboard the machine to the new monitoring experience is back.

So the DCR created, even if the validation was ok, is not good.

To restore the working of log based visualization I had to delete the manually created DCR.

To answer your question :

the Azure Monitor Windows Agent is installed on our machines

there is no error message, the onboarding is always 'successful'

in the log analytics wokspace, data are still ingested but in the azure monitor workspace, no data are ingested (that may be normal because of the linux type DCRs)
Bharath Y P 10,530 Reputation points Microsoft External Staff Moderator

2025-10-24T06:57:29.6466667+00:00

Hello MarcVanderhaegen, thank for the update, based on screenshot, it seems that the DCR is using Microsoft-OTelPerfMetrics as a data source, but the telemetry still isn’t flowing. Also, if a Data Collection Rule (DCR) only includes the Microsoft-OTelPerfMetrics stream, it will collect OpenTelemetry metrics but stop collecting standard logs like performance data and event logs. This can break the usual insights you get in Log Analytics.

Ensures all required streams and destinations are included.

Include both metrics and logs in the DCR, your streamDeclarations should include both Microsoft-OTelPerfMetrics that is Azure Monitor Metrics and Perf, InsightsMetrics, and WindowsEventLogs that is Log Analytics

You can follow the below reference:Migrate to VM insights OpenTelemetry - Azure Monitor | Microsoft Learn
Bharath Y P 10,530 Reputation points Microsoft External Staff Moderator

2025-10-28T09:27:51.13+00:00

Hello MarcVanderhaegen, kindly let us know if the provided information that helps you, If you need any further assistance, please feel free to reach out. Thanks,
MarcVanderhaegen 306 Reputation points

2025-10-28T09:29:45.5033333+00:00

Hello @Bharath Y P

I completely understand that seeing only Microsoft-OTelPerfMetrics would tell that no metrics ingestion would be done through Log Analytics but when you configure the new monitoring experience, you clearly configure that the system you continue the ingestion into the Log Analytics workspace :

But also, the servers are still in the resources list from the DCR that configures the ingestion into Log Analytics so it should never stop sending data there.
At the moment, it is still not working because the DCR created for each machine is still for Linux and not Windows :

Marc
MarcVanderhaegen 306 Reputation points

2025-10-28T09:33:48.8733333+00:00

Hello, sorry but there is no change to the situation. It is not working at all for us. As soon as the DCR is created through an arm template and configure on a Windows type, it is not working and breaks the ingestion through Log Analytics. And when the DCR is created through the portal during the onboarding, the type is set on Linux and it is not working.
Lucas, Stephen (Admin) 0 Reputation points

2025-11-04T14:42:00.9533333+00:00

@MarcVanderhaegen I'm curious if you were able to resolve your VM Insights OpenTelemetry issues? I too was running into the same issues, but I did manage to get it working for both Azure VMs and for Azure ARC VMs as well.

If you got it working, great! If not, let me know and I can tell you what I did to get it working.

Thanks,

Steve
MarcVanderhaegen 306 Reputation points

2025-11-04T15:00:20.79+00:00

Hello Steve,
Unfortunately no, we were not able to solve the problem.
The portal keeps creating linux type DCRs and trying to create a DCR with an arm template is not working.
We have a case at Microsoft for a week now but we haven't heard from them.
I am really interested on how you solved this.
Thanks.
Marc
Lucas, Stephen (Admin) 0 Reputation points

2025-11-04T18:36:13.04+00:00

Hey Marc,

Not sure if you read through and have started this but I just remembered another step. I added another step so steps 4 - 6 changed.

sry for the confusion.

Steve
MarcVanderhaegen 306 Reputation points

2025-11-04T23:07:14.95+00:00

Hello Steve

Thank you very much for these detailed steps.

I just tried all the steps you explained on 2 machines but even after 2/3 hours... there is still the message 'no metrics detected'.

So, for the 2 machines :

All the extensions are up to date.

I deleted the associated MSVMOtel-westeurope-<machinename> dcr if one was found.

I removed the association to the MSVMI dcr (used by the classic log-based metrics)

I kept 2 other DCRs associated, one for the windows event logs and the other one for the ChangeTracking.

I configured the Insights for the 2 machines with only the Open Telemetry metrics. (i unchecked the log-based metrics)

I configured each newly created DCR with the DCE pointing to our azure monitor workspace.

And then I waited..... but nothing.

I will wait until tomorrow morning.

Thanks again for your help.

Marc
MarcVanderhaegen 306 Reputation points

2025-11-05T07:41:09.35+00:00

Hello Steve,

Well, even after a night, there are no metrics ingested for the 2 machines.
I have started over; I have deleted the azure monitor workspace, the DCRs.

This time I have removed all the DCRs from a machine.
I onboarded a machine with only the OpenTelemetry metrics and used the default amw :

After a few seconds the machine was onboarded :

I checked the DCRs and there is only one applied to the machine.
I modified the DCR to include the DCE like you did ( I don't understand why it is needed because in the docs it says it is only required for firewall logs and container insights, but ok, if it worked for you, let's try it).

But unfortunately, the result is the same :

Nothing is ingested.

Marc
MarcVanderhaegen 306 Reputation points

2025-11-05T10:44:05.5333333+00:00

Hello,
I found a log called himds_otel.log which is filled with errors like these ones :

The first error is :

time="2025-11-04T22:01:15+01:00" level=error msg="Failed to upload telemetry: &{ErrorReason:<html> <head><title>503 Service Temporarily Unavailable</title></head> <body> <center><h1>503 Service Temporarily Unavailable</h1></center> <hr><center>nginx</center> </body> </html> ErrorDesc: ErrorCode:[503] Timestamp:2025-11-04 22:01:15.745043 +0100 CET m=+140402.375629401 TraceID: CorrelationID:7c246981-43d3-461e-9cde-d9cffa4eec8a}"

The second error is :

time="2025-11-05T10:23:45+01:00" level=error msg="Failed to upload telemetry: &{ErrorReason:error sending request to the collector: Post "https://gbl.his.arc.azure.com/arc-telemetry/v1/metrics": context deadline exceeded (Client.Timeout exceeded while awaiting headers) ErrorDesc: ErrorCode:[500] Timestamp:2025-11-05 10:23:45.0559411 +0100 CET m=+10874.293433801 TraceID: CorrelationID:556dbe1d-4939-48ae-8bd8-77318a97fc1e}"
Lucas, Stephen (Admin) 0 Reputation points

2025-11-05T12:49:55.2966667+00:00

hey Marc,

as you said, "I modified the DCR to include the DCE like you did ( I don't understand why it is needed because in the docs it says it is only required for firewall logs and container insights"

I read the exact same and agree it makes no sense why it seems to fix ARC Machines.

I will admit onboarding ARC Machines is a bit more of a pain than Azure VMs. I do have one VM in particular that I onboarded yesterday morning and is still not working but all the other ARC Machines I onboarded are working just fine.

here is a screen shot of a working ARC Machine I onboarded late yesterday after I uploaded the doc.

just got in. let me think about it a few minutes as i sip down some coffee and wake my brain up.

Steve
Lucas, Stephen (Admin) 0 Reputation points

2025-11-05T13:00:05.8466667+00:00

Marc,

have you configured OTel for any of your Azure VMs?
MarcVanderhaegen 306 Reputation points

2025-11-05T13:03:21.8566667+00:00

Steve,

We don't have any Azure VM at the moment.
MarcVanderhaegen 306 Reputation points

2025-11-05T13:55:02.59+00:00

:) I tried it also but it didn't help. It always says that the error is on the remote side (so on Microsoft side).
Would it be possible for you to open the log file c:\programdata\azureconnectedmachineagent\log\himds_otel.log to see where your machine is sending the data.
On our side it is https://gbl.his.arc.azure.com/arc-telemetry/v1/metrics
Lucas, Stephen (Admin) 0 Reputation points

2025-11-05T14:13:47.82+00:00

Marc,

Since you've onboarded ARC Machines i'm guessing you've read through the required URLs for ARC to function? for our environment we had to whitelist about 15 or so URLs for our ARC Machines (all our ARC machines are remote) so this was a challenge for us.

The reason I ask is your log shows:
ErrorReason:error sending request to the collector: Post "***https://gbl.his.arc.azure.com/arc-telemetry/v1/metrics***": context deadline exceeded (Client.Timeout exceeded while awaiting headers

the URL: https://gbl.his.arc.azure.com is required for ARC. this URL needs to be whitelisted in your Firewall or Proxy see KB: https://learn.microsoft.com/en-us/azure/azure-arc/network-requirements-consolidated?tabs=azure-cloud#azure-arc-enabled-kubernetes-endpoints

again, i'm sure you are aware of these and it maybe it is whitelisted but if it's not this could be your issue.
Lucas, Stephen (Admin) 0 Reputation points

2025-11-05T16:19:44.86+00:00

Marc,

Since you've onboarded ARC Machines i'm guessing you've read through the required URLs for ARC to function? for our environment we had to whitelist about 15 or so URLs for our ARC Machines (all our ARC machines are remote) so this was a challenge for us.

The reason I ask is your log shows:
ErrorReason:error sending request to the collector: Post "***https://gbl.his.arc.azure.com/arc-telemetry/v1/metrics***": context deadline exceeded (Client.Timeout exceeded while awaiting headers

the URL: https://gbl.his.arc.azure.com is required for ARC. this URL needs to be whitelisted in your Firewall see KB: https://learn.microsoft.com/en-us/azure/azure-arc/network-requirements-consolidated?tabs=azure-cloud#azure-arc-enabled-kubernetes-endpoints

again, i'm sure you are aware of these and it maybe it is whitelisted but if it's not this could be your issue.
MarcVanderhaegen 306 Reputation points

2025-11-05T16:26:13.5766667+00:00

Steve,

Sorry, I was not able to answer faster, the post was locked.
Yes, the url is already in our whitelist, as it is a prerequisite for Azure Arc/Monitor.
I have asked my boss if it is possible to have an Azure VM to try if we would have the same problem. Waiting for an answer.
Lucas, Stephen (Admin) 0 Reputation points

2025-11-05T16:36:57.2366667+00:00

Marc,

in my previous post I mentioned I had an ARC Server that should have been working but wasn't. however, the server was rebooted and after about 30-45 mins the OpenTelemetry started working. keep in mind I enabled OTel yesterday morning and just now started working. I'm not saying that will fix your issue but I wanted to pass that along as maybe something to try.

Steve
MarcVanderhaegen 306 Reputation points

2025-11-05T16:41:24.73+00:00

Steve,
Already tried that too, the servers were rebooted multiple times.
I must say that I am running out of ideas.
It seems so easy to put in place but in fact it's the contrary.

Marc
Lucas, Stephen (Admin) 0 Reputation points

2025-11-05T17:36:01.8733333+00:00

something to check:

go to the portal > Azure Monitor Workspace

Start with the first AMW and open it.

yours might be: 'Default-VMInsights-<region>-<guid>'

i'm using custom AMWs: 'dcr-vmi-otel-monitor-sub'

On the left bar click the Networking blade

if not already done, select the radial button: Enable public access from all networks.

Repeat for all AMWs

When I set it to 'Disable' it broke all my OTel data ingestions. I have since set it back to 'Enable' all is well again.

now if this does fix your issue but would prefer to Disable to the public then as you know you will need to create a private endpoint for each AMW.

After changing to Enable allow some time to hopefully start working. It took over 30 minutes before ingestion started working again.
MarcVanderhaegen 306 Reputation points

2025-11-05T17:42:55.3+00:00

I just checked, it is set on 'enable' by default.
Lucas, Stephen (Admin) 0 Reputation points

2025-11-05T17:53:43.71+00:00

have you checked the logs on the server? especially the 'himds_otel' log

C:\ProgramData\AzureConnectedMachineAgent\Log\himds

C:\ProgramData\AzureConnectedMachineAgent\Log\himds_otel
Lucas, Stephen (Admin) 0 Reputation points

2025-11-05T18:53:49.31+00:00

Something I was thinking about is for the Classic Insights. it is possible that a VM can be assigned to more than one 'MSVMI' DCR even if it's in a different subscription.

I know this sounds a bit out there, but I would check ALL your 'MSVMI' DCRs for those 2 VMs you are testing OTel on. I don't mean the 2 other DCRs associated, one for the windows event logs and the other one for the ChangeTracking. UNLESS they are somehow also configured for VM Insights. If they are, this could be a problem, e.g.:

I would just double check every MSVMI and ensure those two Servers are not associated to any of those DCRs.

I'm running out of ideas. :(
MarcVanderhaegen 306 Reputation points

2025-11-05T20:13:21.49+00:00

I had removed the machines from all DCRs prior configuring the Insights to be sure to start from a clean situation.

I am also out of ideas. I will stop bothering you, I am going to wait for Microsoft to contact us about the case.
Thanks a lot for all your help.

Marc
Lucas, Stephen (Admin) 0 Reputation points

2025-11-06T11:54:22.9+00:00

hey Marc,

It's no bother at all. When you get it working and wouldn't mind sharing, I would be curious to know what you did to resolve it. Thanks!

Best,

Steve
MarcVanderhaegen 306 Reputation points

2025-11-06T12:16:39.2533333+00:00

Hello Steve,
No problem, as soon as we have it working i will post an update.
Thanks

Marc
Lucas, Stephen (Admin) 0 Reputation points

2025-11-14T19:34:58.7166667+00:00

hi Marc,

wanted to check in and see if you made any headway.

I want to drop an easy possible fix on you to see if this works if still not working.

even though my OTel is working I did have some problems with some of the AMA extensions not able to update to 1.38 or 1.39. After reading through a couple of these forums I read where someone updated the 'Azure Connected Machine Agent' aka the Azure ARC Agent on the Server itself.

So I took a chance and downloaded the most current version: AzureConnectedMachineAgent_v1.58.x

I ran the .msi and wouldn't you know it, it fixed my issues. Also, it seems to get OTel ingesting data faster after enabling it.

to download and see the full list go here:
https://www.catalog.update.microsoft.com/Home.aspx

then in search: AzureConnectedMachineAgent

You will then see the full list of the agents and versions. just pick the version you want and download

then click the blue *.cab link

after you download you just need to extract it.

then run in on the server.

not saying it will fix your issues, but it also won't hurt either.
fingers crossed!
MarcVanderhaegen 306 Reputation points

2025-11-15T11:14:26.4266667+00:00

Hello Steve,
Thanks for your message.
I was away from office for a few days, I still haven't had any news from our MS case.

I need to check again but on our side I didn't detect any problem upgrading AzureMonitorWindowsAgent to 1.39.
On the other hand, the MicrosoftDefenderForSQL extension is impossible to upgrade; we always get the error message :
"Failing to communicate with Defender. Error: SQL Channel Error: Failing reason: ExportClient Error: Failed to reach Defender endpoint. Exception: No such host is known. (defender-for-databases.westeurope.arcdataservices.com:443).\r\nInner Exception(1): No such host is known...\r\nAMA Channel Error: Failed to fetch configuration from AMA for all available sets of extension names."
Even if we delete the extension, it gets automatically reinstalled (so the system can access the source files) but the upgrade always fails on every servers with SQL installed.
But that's another story....

For Insights, I just tried to restart the onboarding process into Monitor and there is a change for the newly created DCR, the type is now 'All' :

I did that 1 hour ago but at the moment there is still no data : /

I hope it is just a question of time now.

For the Azure Connected Machine Agent, I will try the upgrade on Monday. I didn't saw anything related to the problem in the release notes but as you said .... fingers crossed.

Marc
MarcVanderhaegen 306 Reputation points

2025-11-16T09:08:11.7033333+00:00

Unfortunately more than 12 hours later still nothing. I had activated the monitoring on the azure monitor workspace and it tells me that until now no data have been ingested.
MarcVanderhaegen 306 Reputation points

2025-11-17T14:47:53.2633333+00:00

Hello Steve,

I have upgraded the Azure Connected Machine agent but it doesn't change anything; no data are ingested in the amw.
MarcVanderhaegen 306 Reputation points

2025-11-18T05:46:32.3933333+00:00

Hello Steve,
Unfortunately still no news about the OTel problem but yesterday I have noticed a more serious problem in Arc : the status of the machines is different between Azure Arc - Machines and the detailed view of a machine.
The problem is not occuring on all machines but still on a lot of them.

For example :

It means that a machine that would go offline would be undetected because a query in log analytics for the heartbeat still shows the machine up and running (the MS engineer confirmed that the data source in Azure Arc - Machines and in the detailed view of a machine is not the same).
It is not only the field 'status' that may be different, I have also noticed a difference for the 'agent version'/'operating system version' fields.
I had to open a case that has now been escalated to the product group as a 'bug'.

For us, the problem seem to have started yesterday at around 09h00 (GMT+1).

Have you also noticed this problem ?
Lucas, Stephen (Admin) 0 Reputation points

2025-11-18T12:33:55.98+00:00

hey Marc,

yes, I actually have that issue on some of my ARC machines. the one thing that is slightly different from yours is the ones that show 'offline' are on the view of the list of servers. however, when you select an ARC machine then on the Overview page it shows as 'connected'.

Even though the connection status is out of sync the OTel is still working so whatever the issue I don't think it has any impact.
MarcVanderhaegen 306 Reputation points

2025-11-18T13:21:33.27+00:00

Hello Steve,

Thanks for your answer.
The problem goes in both ways (really online, shown offline / really offline, shown online); they are still looking into it. And they inform me that it has no impact on other Azure services, except the reporting through log analytics.

Answer 1

Anonymous

Hi MarcVanderhaegen
Currently, proxy support for metrics is not available. Microsoft plans to add this feature in an upcoming AMA release.
Please let me know if you face any challenge here, I can help you to resolve this issue further

Provide your valuable Comments.

Please do not forget to "Accept the answer” and “upvote it” wherever the information provided helps you, this can be beneficial to other community members.it would be greatly appreciated and helpful to others.

MarcVanderhaegen 306 Reputation points

2026-01-27T15:28:21.1066667+00:00

Hello,
Thank you for your answer.
Is there any estimated time for the proxy support ?

Thanks

Marc
Anonymous

2026-01-30T11:50:01.23+00:00

Hi MarcVanderhaegen
Microsoft plans to roll this out in April
MarcVanderhaegen 306 Reputation points

2026-01-31T13:52:53.8933333+00:00

Hello @Naveena Patlolla
Thank you very much for the information. I will resume my tests after April.

Upgrade to the new monitoring experience - no data

🧾 Error Summary

🔍 What It Means

🛠️ Possible Fixes

🧾 Error Summary

🔍 What It Means

🛠️ Possible Fixes

0 additional answers

Your answer