Logging framework versions for arc cluster

[chandrod]

Issue describing the changes in this PR

We use to receive customer tickets for azure functions, where to reproduce customer issues we need to fetch some basic data from customer’s cluster like : a)host version b)Framework c)Framework version d)Trigger used etc. (these are examples) Some of this data is already available in the environment variables and we wanted to fetch it. From what information I have so far, when we push logs (platform/app) for a functionapp, those logs are also written to a file in logProcessor pods and finally fluentd helps in flowing that data to logs analytics workspace.

With that intention I wish to introduce the log statements which would be dumped every1 hour (change verified in logs analytics workspace) Although we as developers can find this information from logs by doing some grep/regex, but for customers this process becomes cumbersome. With this change customer can go to their logs Analytics workspace and send us the query result of last 1 hour or so.

Pull request checklist

Only logging, none of these apply.

• [ ] My changes do not require documentation changes
  • [ ] Otherwise: Documentation issue linked to PR
• [ ] My changes should not be added to the release notes for the next release
  • [ ] Otherwise: I've added my notes to release_notes.md
• [ ] My changes do not need to be backported to a previous version
  • [ ] Otherwise: Backport tracked by issue/PR #issue_or_pr
• [ ] I have added all required tests (Unit tests, E2E tests)

Additional information

Additional PR information

[liliankasem]

Hi @chandrod, I think there's potentially a different approach you can take here; we'd like to avoid setting up a timer in the start up flow. The approach we think you should take here is to register a custom hosted service instead. here is an example you can use as a reference:

• FunctionsScaleMonitorService

For Arc, are you running your own build of the host?

• If yes, you can register the hosted services outside of our repo, injecting in your own service
• If not, you can still use this service approach and we can conditionally register your service based on environment

[chandrod]

@liliankasem your comment makes total sense. Made those changes. Please take a look.

[liliankasem]

Please also add some tests

[chandrod]

Hi @chandrod, I think there's potentially a different approach you can take here; we'd like to avoid setting up a timer in the start up flow. The approach we think you should take here is to register a custom hosted service instead. here is an example you can use as a reference:

• FunctionsScaleMonitorService

For Arc, are you running your own build of the host?

• If yes, you can register the hosted services outside of our repo, injecting in your own service
• If not, you can still use this service approach and we can conditionally register your service based on environment

Done

[chandrod]

@CooperLink. Had a short discussion with functions-host team. We need your approval as well if we wish to merge this PR. Could you please take a look ? Thank you

[pragnagopa]

Curious to understand why this change is needed when most of the information is already logged in script startup message - - https://github.com/Azure/azure-functions-host/blob/15e1c2bc4b610f42a1e40ad5de81dba478db6dd3/src/WebJobs.Script/Diagnostics/Extensions/ScriptHostLoggerExtension.cs#L126-L132 as part of ScriptHost startup

Are these logs missing in log analytics?

[liliankasem]

Closing as migrated to #8711