feat: add kernelVersion to telemetry traces

[Anirudh2112]

Description

This pull request adds the kernelVersion property to telemetry traces in the TrackTrace method. This enhancement allows pinpointing the specific kernel version responsible for producing logs.

To achieve this:

Introduced a kernelVersionFunc variable to enable easier mocking during tests.
Updated the TrackTrace method to include kernelVersion in telemetry traces.
Added a test (TestTrackTraceIncludesKernelVersion) to verify the inclusion of kernelVersion in trace properties.
Related Issue
This pull request addresses the issue:
#1071

Checklist

I have read the contributing documentation
I signed and signed-off the commits (git commit -S -s ...).
I have tested the changes locally.
I have followed the project's style guidelines.
I have added tests.

Screenshots (if applicable) or Testing Completed

Test Output

The following test passes successfully:

• go test -run TestTrackTraceIncludesKernelVersion

[Anirudh2112]

@microsoft-github-policy-service agree

[Anirudh2112]

Yes, @matmerr that is true, and thank you @rbtr for catching that. I’ve updated the conditional to check for err != nil to avoid infinite recursion. Please let me know if there are any other concerns.

[rbtr]

@Anirudh2112 the infinite recursion is still present, trackWarning calls TrackTrace

[Anirudh2112]

Apologies for the oversight regarding the infinite recursion. In the recent changes, I’ve addressed this by:

1. Replacing the call to t.trackWarning with direct error logging to avoid recursion.
2. Ensuring that errors are logged as separate telemetry traces using appinsights.NewTraceTelemetry.
3. Preserving the original functionality by adding kernelVersion to the properties map when available and maintaining the flow for the main trace.

[Anirudh2112]

Hi @matmerr @rbtr, I've addressed all the review comments on my PRs. Just wanted to check if there are any other issues I should address or if there's anything else needed from my side to help move these forward. Thanks!

[timraymond]

@Anirudh2112 I had a few suggestions, mostly around the use of the global var to mock the KernelVersion func. Two issues with it: 1) it makes the tests racy, which limits the amount of concurrency we can use when running the test suite. Fast tests are nice, and you can only really have fast tests by staying vigilant for things that slow them down :) 2) Depending on the KernelVersion func is really the wrong dependency to take--what we want to depend on the behavior of "give me the kernel version from this host." The way to depend on behavior in Go is to depend on an interface.

Looking at the patch closer though, I can see what you had to work with, and a lot of it was pre-existing. I went ahead and made the changes I suggested to save some back-and-forth. The commit is on traymond/kernelversion-traces. Assuming the typical "triangular workflow," you should be able to fetch it from your upstream remote, then git merge --ff-only onto your branch to pull the change in.

[Anirudh2112]

@timraymond I've merged your changes from the traymond/kernelversion-traces branch. I appreciate the improvements made to handle platform detection at runtime and the cleaner approach using the HostInfoClient. I've reviewed the changes and understand this removes the need for compile-time platform detection while making the code more testable. Please let me know if there's anything else needed.