serilog-contrib/serilog-sinks-azuretablestorage

Output template for column creation from parameters?

Closed this issue · 7 comments

sturlath commented

Control column creation

What I would really like is ** a way to select what properties become a column** in the azure table when using AzureTableStorageWithProperties().

Something like e.g RollingFile is using
{Timestamp:dd-MM-yyyy HH:mm:ss.fff zzz} {Level} {MachineName} {ThreadId} {ProcessId}{MemberName}{Message}{Exception} where each {} would become a column and just them, others would be skipped.

But I would also like to have the option to keep the json Data column that AzureTableStorage() creates. I don´t want to loose that.

Has anything like this been discussed? What are the problems? I will also dig around the code in the meantime.

adamchester commented

👍 From me. I haven't seen this discussed before. Maybe @nblumhardt would know if something similar has been done in any other sinks?

adamchester commented

I wonder if it's appropriate to use the message template syntax to declare which properties become columns. Wouldn't it be easier to just provide a list (maybe csv would fit with configuration options)?

  • 👍1
nblumhardt commented

I think the most similar functionality right now would be in the SQL Server sink - https://github.com/serilog/serilog-sinks-mssqlserver.

In that case, an "options" class is used. It's not particularly configuration-friendly, so there's room to improve the way we approach it (or the configuration API).

MNorgren commented

This would be a really nice feature to have! @adamchester, I think providing a list of columns to the configuration would suffice for the requirements. Because this is not SQL Server, we don't need to have a complex configuration by specifying the type, lengths, etc...

Another idea would be to add only Enriched properties to the Azure data tables.

In the meantime, anyone know how to configure only a few additional columns without it auto-creating a column for everything?

nblumhardt commented

Just to link things up: #31 is a PR from @montijr2007 for this.

I'm not using table storage so it's hard for me to reach a solid conclusion on what the correct behaviour/trade-offs are. Might be good to continue the discussion over on the PR.

  • 👍1
untilted-document commented

Any chance we could extend this so that any column the logger wants to write is checked against this array first? I'd like to e.g. pass an array of new string[] { "Level", "RenderedMessage", "Exception" } to have those columns, but knock out the MessageTemplate and AggregatedProperties columns, that I do not care to log

nblumhardt commented

Just a note, the PR for this one has been merged, would be better to open a new ticket for follow-on work. Cheers!