Skip to content

Ability to pass in a custom log analytics workspace ID #85

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 10 commits into
base: master
Choose a base branch
from

Conversation

Henderson42
Copy link

@Henderson42 Henderson42 commented Jun 4, 2025

What?

  • Add the ability to pass in a custom log analytics workspace ID so that logging can be sent to an existing workspace.
  • Add an output for the log analytics workspace ID so it can be passed to other resources.

Why?

  • The current implementation of always creating a log analytics workspace of it's own without the ability to set any of the properties of the workspace is limiting.

How?

  • Added an optional variable log_analytics_workspace_id that defaults to null.
  • Added a count to the existing azurerm_log_analytics_workspace resource so it is only created when the new variable is undefined.
  • Set any resources using the original workspace ID to try(azurerm_log_analytics_workspace.workspace[0].id, var.azurerm_log_analytics_workspace_id).
  • Added an output to outputs.tf using the same logic as above.

Testing?

I first ran this against an existing deployment of the module that I have in my development environment to ensure that everything left default would be non-destructive (screenshot 1).

I then ran it with var.log_analytics_workspace_id defined to ensure that it could plan + apply without breaking anything other than deleting the existing workspace (screenshot 2).

Screenshots

Plan showing that with everything default the only change is an update to TF state because the resource now has a count index:
Screenshot 2025-06-04 at 21 50 51

Plan + apply showing successful deletion of the old log analytics workspace and updating the application insights to point at the custom workspace:
Screenshot 2025-06-04 at 22 03 07

Anything Else?

If you'd rather it were more explicit we could quite easily add a use_custom_workspace flag or similar rather than having it decided implicitly based on the new variable being defined.

We can also quite easily move away from count to for_each = var.log_analytics_workspace_id == null ? [1] : [] if you'd prefer not to introduce count.

I also moved the existing example about, added an example for using the custom log analytics workspace, added a new GitHub action for the custom log analytics workspace example and updated the working directory for the 'validate-example.yml' GitHub action to use the new directory structure.

@Henderson42 Henderson42 marked this pull request as ready for review June 4, 2025 21:38
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant