Consolidating Log Analytics References & Definitions

[nharper285]

Summary of the Pull Request

What is this about?

From issue #1614:
Right now, an instance has two Log Analytics Workspaces:

• logs-wb-..
• <instance-name>

One collects data that includes Azure Monitor logs and perf counters. The other gets App Insights data.

If possible, just deploy one workspace, named after the instance, which collects both. This will enable easily creating queries and workbooks that pull data from both workspaces.

---

The <instance-name> workspace was created to query App Insights data, as AI did not yet have the ability to do so. I am removing the original reference to this workspace and renaming the monitor-based workspace [log-wb-...] to [instance-name].

As a part of this update, VMSS OMSExtensions will now point to the consolidated [instance-name] log analytics workspace. Originally, the OMSExtension monitoring pointed to the [log-wb-...] workspace. This means that when a running instance is upgraded to include these changes, existing VMSS will initially still point to the old LA. However, timer-workers will eventually update the configs of these VMSS with the correct LA and once the nodes are upgraded and reimaged, they will correctly send VMInsights to the [instance-name] LA.

If customers would like to keep the original [log-wb-...] workspace to retain old VMSS logs, that is reasonable.
If the [log-wb-...] workspace is deleted immediately then VMInsights for existing VMSS from the last 30 days will no longer be accessible.

Regardless, log retention for all workspaces is 30 days. This means that 30 days after the last VMSS node updates to point to the [instance-name] workspace, there will no longer be logs left to query and the workspace can be safely deleted.

If customers do not want to wait for the update that will point VMSS nodes to the [instance-name] workspace, they can force an upgrade by setting the needs_config_update VMSS config property to true in the scaleset table in the OneFuzz func... storage account and then 'upgrading' the scaleset manually.

PR Checklist

• Applies to work item: Unify log analytics workspaces #1614
• Tests added/passed
• I've discussed this with core contributors already. If not checked, I'm ready to accept this work might be rejected in favor of a different grand plan. Issue number where discussion took place: #xxx

Info on Pull Request

What does this include?
Changes to AzureDeploy.json workspace and app insights definitions.

Validation Steps Performed

How does someone test & validate?

• Manual Deployment
• Verifying Presence of relevant logs
• Check-Pr
• Verifying Migration Story