Consider - Expanding on Semantic Logging

[chassq]

Right now it seems logging "in the box" is limited to writing a string message. Sure you can write your own logging extension and add it (e.g. logger.MyLog() in Program.cs). However when looking at what that takes (see https://github.com/aspnet/Logging/tree/dev/src/Microsoft.Extensions.Logging.AzureAppServices) with all the option monitoring and batch logging it is kind of involved and time consuming. And you are subject to framework changes by MS.

It would be great to add into the "in the box" logging framework an semantic logger that defines a log message object (much like the Blob logger does today) and hooks up to a structured data persistence store (e.g. CosmosDB or DynamoDB). For example both of these stores have REST APIs in common and document storage and query capabilities that can hook into other cloud and on prem services to maintain, monitor and parse logs in an intelligent way (e.g. Cold Storage, AI, Search). Yes you can do this with just string messages but a more structured schema for log data would be really great!

Thanks for listening!

[muratg]

Thanks for the suggestion, @chassq.

We're not planning to add new features to Logging in our upcoming minor release. We may consider this in a future release.

cc @glennc

[analogrelay]

We're planning to do some work to produce JSON from the default console logger as described in #2479, including defining a schema for log message (by way of the JSON formatting). Most modern guidance for cloud-native apps (such as the The 12-factor app) recommends the use of console logging (with an external process scraping the logs to store in a relevant data store).

Given that and the relatively low activity on this issue, I don't expect we're going to build default integrations with components like CosmosDB or DynamoDB. We have integrations with Azure Log Analytics and third-party libraries do a great job of integrating with other components. Adding abstractions over structured logging is tricky too since logging is a tricky area for performance and allocating objects or abstractions can be costly.

I'm going to close this, since I don't expect this to be something we can prioritize given the history and the work planned in the future. Thanks for the feedback, please let us know if you have further thoughts on our current plans in this space and if they don't align with your needs!

---

Note: Inactive closed issues are locked after 30 days since we don't triage closed issues and new comments tend to be lost. Feel free to post a new issue if this issue is locked and you have questions. See our issue management policies for more details.