-
Notifications
You must be signed in to change notification settings - Fork 3.8k
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
Set-AzDiagnosticSetting - impossible to set RentionInDays for individual categories #11589
Comments
Thanks for reporting. @VeryEarly , please check this issue. |
It seems like each settings is identified by its "Name", since your two settings have identical name, the previous one will be overwrite by the later one. Can you try give different names for these two settings? |
@VeryEarly, yes that might be a workaround, but it will still mean that this commandlet can't reproduce behaviour that is possible from the Azure Portal, and Azure CLI (based on the reading I've done, not actually tested Azure CLI because it's a pain to get working through an authenticated proxy which I can't bypass in my environment.) Here's a screenshot of the Azure Portal that shows that I can set different Retention days per category, under the single Diagnostic Setting: If I can do this in the Azure Portal, I would expect to be able to do the same with the PowerShell commandlet. Using multiple Diagnostic Settings, also means that I would need to use 2 Storage accounts as the one storage account can't be used for two Diagnostic settings. Whilst that is doable, and might have some other performance benefits, it adds additional undesired complexity into the solution. |
@VeryEarly, and to confirm: different names for the Diagnostic Settings (pointing to different storage accounts) produces the following results, when viewed in the Azure Portal This lets the Retention in days to be set to desired values for categories, but I would describe this as still broken due to it not supporting the same use-cases as the portal and the management REST API allows for. I would think the |
For reference, with the Azure CLI, its syntax allows for in a single Diagnostic Setting the retention policies independently for each category can be independently set:
|
Hi, I can make fix to have what you desired, set retention policy per Metric/Log |
@VeryEarly, that merged change you have made is an improvement, so thank you! However, I still would like to see this function match the Azure Portal behavior, but also understand that requires a major rewrite as the function's parameters have to be completely redesigned to cater for the scenario. Therefore it would be great if the documentation for |
Thanks for your feedback. The redesign involves breaking change and due to our heavy schedule it would not catch the next breaking change release (this May). However we will certainly consider refactor the cmdlet to match behavior from Azure Portal. |
fixed in #13535 |
Description
I'm trying to set diagnostic settings via the Set-AzDiagnosticSetting commandlet for an Azure Front Door resource.
I've tried a number a ways, but I have not been able to set a separate Retention policy per category. I can easily do this via the Azure portal, but I want to automate it with PowerShell. No matter how I call/chain the calls to
Set-AzDiagnosticSetting
command together, the last value given forRetentionInDays
is applied to all Categories.Steps to reproduce
The following are the values I am trying to set. Metrics should be stored for 180 days, the logs indefinitely.
Executing
Set-AzDiagnosticSetting
with these parameters in the following order:Results in all categories and metrics having a retention policy of
0 days
Executing
Set-AzDiagnosticSetting
with these parameters in the following order:Results in all categories and metrics having a retention policy of
180 days
Piping the commands together in any order results in the same behaviour.
I've taken a quick look at the source for Set-AzDiagnosticSetting and it looks like the
SetRetention
function is executed against ALL categories enabled on the resource, instead of just the categories that are passed in to the commandlet. This would confirm the behaviour that I'm experiencing.Environment data
(Sorry hand to write this out by hand - unable to cut'n paste from target environment to GitHub)
Module versions
Sorry unable provide this as unable to cut'n paste from target environment to GitHub.
Debug output
Sorry unable provide this as unable to cut'n paste from target environment to GitHub.
Error output
There's no errors executing the command.
The text was updated successfully, but these errors were encountered: