RFCnnnn - HTTP POSTing ScriptBlock Logging Provider #106
Conversation
|
|
rhysjtevans
changed the title
rhysjtevans
changed the title
|
@SteveL-MSFT this RFC seems to miss labels in order to be considered for review |
|
@SteveL-MSFT Is that something for myself to action? |
|
cc @dantraMSFT this may be of interest to you |
|
Any progress on this? |
|
This is useful, but it makes no sense to do this in PowerShell repository - it is too expensive. I'd look that .Net Core suggest for remote logging. |
|
@TravisEz13 @PaulHigin please take a look at this to see if it aligns with some discussions we've had to enable logging to Azure Log Analytics |
| ##### Configuration | ||
| The plan would be to import the configuration data with the following example properties with example values; | ||
| 1. StreamLogType | ||
| * TCP, UDP, HTTP, HTTPS |
There was a problem hiding this comment.
How would TCP, UDP, and HTTP data be encrypted? If we don't have an plan to encrypt, the options should not be included.
There was a problem hiding this comment.
Perhaps move these to alternatives with notes that we need to figure out how to secure the channels.
|
@PowerShell/powershell-committee discussed this one in detail today. We believe that there's massive value in figuring out how to tee logs off to remote logging providers, but a bunch of the semantics in this RFC are specific to Splunk. Instead, we think an RFC should be authored that builds a provider/plugin model for allowing multiple remote logging providers. This RFC should also give consideration to whether local logging targets should be treated the same way (e.g. if you want to exclusively log to a remote target, maybe in serverless/stateless scenarios). There should also be a consideration of whether we should have something like a The PowerShell Team has a strong interest in picking this up, but we have no idea when we can get to it right now. We only know that it should be a flexible, pluggable model. For this particular RFC, we're rejecting it and filing an issue to track the need for the new RFC. |
No description provided.