The configuration for Serilog in the appsettings.json file looks something like this:
"Serilog": {
"MinimumLevel": "Debug",
"WriteTo": [
{
"Name": "AzureTableStorage",
"Args": {
"storageTableName": "logs",
"connectionString": ""
}
}
]
}
I've been trying to replicate the structure using the '--' delimiter notation so I can store the connection string in Key Vault and inject it at runtime but it doesn't appear to be working. Is it possible to replicate the Serilog configuration object using this provider?
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.
Hello @Jaffacakes82 ... Yes, but make sure you use the approach in the "prefix" sample that replaces the double-dash (--) in AKV keys with a colon (:) for configuration ...
... barring the prefix parts ... You don't need to implement those bits, since that doesn't apply to your scenario.
The keys/values will be ...
| AKV Key | Value | Read in config as |
| --- | --- | --- |
| Serilog--MinimumLevel | Debug | Serilog:MinimumLevel |
| Serilog--WriteTo--Name | AzureTableStorage | Serilog:WriteTo:Name |
| Serilog--WriteTo--Args--storageTableName | logs | Serilog:WriteTo:Args:storageTableName |
| Serilog--WriteTo--Args--connectionString | value | Serilog:WriteTo:Args:connectionString |
it doesn't appear to be working
Make sure that your AVK provider (AddAzureKeyVault) is after the File Configuration Provider (AddJsonFile) or call to CreateDefaultBuilder.
I also note that the sample README (possibly the "basic" sample; possibly language in the topic) could use a touch of work. There are two samples here (basic and prefix). The "prefix" sample has the bits to store hierarchical keys in AKV and load them properly for configuration of the app, but the "basic" sample doesn't. The "basic" sample is set up for the simplest case, which is just to read non-hierarchical keys from AKV. Either the "basic" sample should use the same approach as the "prefix" sample, or the README should be updated. I need to take a closer look and mull it over a bit more.
I'm out on vacation until the end of next week 🏖, and I'll take a closer look when I get back. In the meantime, see the "prefix" sample and see if you have your keys set up as I show. Let me know if you have a :smile: or ☹️ outcome. Let's leave this issue open either way until I can take a closer look.
Thanks for getting back to me so quickly @guardrex, I think it's still a 😞outcome for now.
I've got it working for other hierarchical values e.g. connection strings and my Serilog keys do match those you have detailed above.
Do I not have to index the 'WriteTo' property?
Enjoy your vacation :).
Do I not have to index the 'WriteTo' property?
~"index" ?? I don't follow.~
Oh, I see what you mean 0, 1, ... [n]. Perhaps so ... Idk how Serilog wants its config values stored.
WRT troubleshooting: You could have it show you what it's bringing into configuration from AKV. I have a test app that does it this way ...
@using Microsoft.Extensions.Configuration
@inject IConfiguration Configuration
...
<ul>
@foreach(var kvp in Configuration.AsEnumerable())
{
<li>@kvp.Key : @kvp.Value</li>
}
</ul>
Serilog expects an array of sink configuration objects to the 'WriteTo' property. Will the AKV provider be clever enough to expand a secret with the following name for example?
Serilog--WriteTo[0]--Args--connectionString
I'll do some debugging and let you know what I find.
Will the AKV provider be clever enough to expand a secret with the following name for example?
Good question ... I don't know. Normally, array binding to a POCO class uses a "colon-array index-colon" structure (e.g., entry:0:key, entry:1:key, ... entry:[n]:key).
Serilog--WriteTo--1--Args--connectionString
Serilog--WriteTo--2--Args--connectionString
OK, I've got it working locally using the notation in your comment above. Thanks for your help! It's still blowing up from my Azure Web App but I'm guessing this is probably something wrong with the deployment.
You're a legend!
Let's leave this open. This issue will auto-close when the PR merges.
Most helpful comment
OK, I've got it working locally using the notation in your comment above. Thanks for your help! It's still blowing up from my Azure Web App but I'm guessing this is probably something wrong with the deployment.
You're a legend!