Skip to content
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

Logging improvement request #2981

Closed
anpiskai opened this issue Mar 8, 2023 · 5 comments · Fixed by #3091, #3099 or #3140
Closed

Logging improvement request #2981

anpiskai opened this issue Mar 8, 2023 · 5 comments · Fixed by #3091, #3099 or #3140

Comments

@anpiskai
Copy link

anpiskai commented Mar 8, 2023

In order to correlate events more easily between drifted and non-drifted resources for reporting purposes, is it possible to include either one of the following?

  • Include the InstanceName value (as visible from the output of the Test-DSCConfiguration command) within the logged M365DSC drift events that are created
  • Create informational events for non-drifted M365DSC events to complement the drifted M365DSC events already being created with the desired attribute list (similar to current drift events).

Either of these approaches would permit a common attribute to be referenced regardless of drifted/not-drifted status for any given resource.

@andikrueger andikrueger added Enhancement New feature or request Core Engine labels Mar 9, 2023
@anpiskai
Copy link
Author

anpiskai commented Mar 15, 2023

It looks like the second option (logging non-drifted events to event logs) would be more easily implemented because the event generation is centralized in the M365DSCUtil.psm1 file. (By contrast, the first option seems like it would require modifying each DSC resource to pass in an instance identity attribute in the Test step into Test-M365DSCParameterState).

In that M365DSCUtil.psm1 file, we could add an else to complement the if($returnValue -eq $false) section in the Test-M365DSCParameterState command to handle and generate events for when $returnValue -eq $true.

Perhaps adding something like:

elseif($returnValue -eq $true)
    {
        $EventMessage = "<M365DSCEvent>`r`n"
        $EventMessage += "    <ConfigurationDrift Source=`"$Source`">`r`n"
        $EventMessage += "        <ParametersNotInDesiredState>`r`n"
        $EventMessage += "        </ParametersNotInDesiredState>`r`n"
        $EventMessage += "    </ConfigurationDrift>`r`n"
        $EventMessage += "    <DesiredValues>`r`n"
        foreach ($Key in $DesiredValues.Keys)
        {
            $Value = $DesiredValues.$Key
            if ([System.String]::IsNullOrEmpty($Value))
            {
                $Value = "`$null"
            }
            $EventMessage += "        <Param Name =`"$key`">$Value</Param>`r`n"
        }
        $EventMessage += "    </DesiredValues>`r`n"
        $EventMessage += '</M365DSCEvent>'

        Add-M365DSCEvent -Message $EventMessage -EventType 'Drift' -EntryType 'Information' `
            -EventID 2 -Source $Source
    }

@ykuijs
Copy link
Member

ykuijs commented Mar 20, 2023

The InstanceName is not available inside of the resource code, so that option is not possible unfortunately.
Adding an entry for each non-drifted resource will add a huge amount of additional logging data to the event log.

Currently we are outputting the Desired State to the event log as well. That should contain all the information you need to determine what resource it is all about. Isn't that what you are looking for?

@anpiskai
Copy link
Author

The Desired State info in the logging is fine for drifted events, but since events aren't being written for non-drifted events, getting that same information from the event logs is not possible for all resources---just the drifted ones.

So you have to pull the list of the non-drifted events elsewhere---like the Test-DSCConfiguration output. But, since there's no unique identifier common between the Test-DSCConfiguration output and the detailed event log output, a resource would show a different name depending whether it was drifted or not (which is inconvenient for dashboard purposes).

Is there a way to have an optional flag that would permit the non-drifted event logs to be generated in cases where people are okay with the performance hit?

@ykuijs
Copy link
Member

ykuijs commented Mar 20, 2023

Ah ok, I understand what you are looking for here. Let us think if this would be feasible and what would be the best way to implement this.

As a workaround: You could use the value of the Key parameter(s) in the instance name, so you are able to match the results.

@anpiskai
Copy link
Author

Are you saying to specify the instance name within the DSC configuration to match what the value being used from the event log output?

If so, that could be a workaround, but it is subject to mistakes if people don't comply since it's a different attribute. They could be set to the same value, but it requires compliance by all the code authors to get correct.

NikCharlebois added a commit to NikCharlebois/Microsoft365DSC that referenced this issue Mar 29, 2023
NikCharlebois added a commit that referenced this issue Mar 29, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants