-
-
Notifications
You must be signed in to change notification settings - Fork 92
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Log output and user requests #33
Comments
I was actually just thinking about this a couple days ago 😄 I've had a few thoughts about this one, and it came down to a few questions and ideas: Questions:
Ideas:
Other than this, what format and information would you like being logged?
I was thinking, if storing to a file, store it as a CSV maybe? (so it's simple to import and parse) |
My answers:
Ideas:
Format and Detail
|
Excellent, thanks! In which case this is what I'm thinking with the above:
Work on support for sending logs to, say, fluentd/logstash/influxdb/splunk/etc should probably come in a separate issue that can be raised - allowing for this issue to just focus on getting logging to terminal/files in place. |
Started to put together a rough draft of the code for this. Tried to mimic the async-content Add-ContentResponseRunspace code/usage. Currently this just logs to the console if you add a -Log switch to a Server, and it only works for the web server. Not yet able to pull in the response length yet, but was able to get the rest of the data required to log in the Common Log Format. I didn't create a pull request for this as I used the async-content branch and didn't know if you'd want this under a separate branch or not. Just put together this code quickly as a rough draft for you to review and point me in the right direction. |
This change would allow us to log in Combined Log Format |
I was working on something for it last night as well (commit above). When I was going through it, I was thinking about the extra switches for logging, and decided it might be a bit too much and to only include a The idea behind the loggers was to allow you to define inbuilt loggers, or defined custom loggers with a custom scriptblock - for tools like logstash/fluentd. Currently the only ones I threw together were for terminal and file (file currently is just one big file). Example of a logger: Server -Port 8085 {
logger 'terminal'
logger 'file'
# GET "localhost:8085/"
route 'get' '/' {
param($session)
view 'simple' -Data @{ 'numbers' = @(1, 2, 3); }
}
}
For custom ones, say like Passing
|
Looks great. I agree that trying to fit everything in as switches/parameters to a Server will get messy quick. Good idea on moving it to defining 'loggers'. I'm starting to test it all out now. Looks great so far |
Updated that branch, so support for files is a little better: logger 'file' @{
'Path' = '<path-to-put-logs>';
'MaxDays' = 4;
} The hashtable is completely optional. If a no If a Also added in support for custom loggers; custom ones must have a name like logger 'custom_output' {
param($log)
$log.Request.Resource | Out-Default
} The @{
'Host' = '10.10.0.3';
'RfcUserIdentity' = '-';
'User' = '-';
'Date' = '14/Jun/2018:20:23:52 +01:00';
'Request' = @{
'Method' = 'GET';
'Resource' = '/api/users';
'Protocol' = "HTTP/1.1";
'Referrer' = '-';
'Agent' = '<user-agent>';
};
'Response' = @{
'StatusCode' = '200';
'StautsDescription' = 'OK'
'Size' = '-';
};
} |
Testing on my end looks good. Looks like some of the json and html responses aren't displaying response.ContentLength64 though. I sent a pull request to update the Readme on how to use the new logging functionality. |
Regarding json and html responses showing '-' for ContentLength64, I see in Tools\Responses.ps1 in the Attach function the ContentLength64 variable getting set: $PodeSession.Web.Response.ContentLength64 = $fs.Length I didn't see anything similar in the Write-ToResponse function. I pushed the above commit changing the WriteLine to a Write for Strings in the Write-ToResponse function and also to calculate the buffer. It looks like this works correctly for me, and now the logs are showing the response size. |
I can manage to get the ContentLength64 being set when using the MemoryStream; but having some difficulties when using the StreamWriter. Will keep digging. |
check this commit I think I got it working for the StreamWriter in there |
Ah awesome, github didn't refresh properly so I missed the above comment. I'll check out the commit in a bit, thanks! |
@ssugar Got it! Your commit gave me an idea; I scrapped the |
@Badgerati Elegant solution. It's working well for me now. |
@ssugar In which case, if we're happy with this, I can put it into tonight's v0.12.0 release later? I've seen the pull request for the documentation, and am happy with it - just needs a conflict resolving 😛 |
@Badgerati - I'm very happy with this. |
@Badgerati - Was wondering if you had any thoughts or plans on adding some logging to pode Servers in order to have a historic view of what is being requested, sourceip, ... along the lines of something we'd get if we ran an iis-based web/smtp server with basic logging enabled. I'd be willing to take a first crack at it if you'd like.
The text was updated successfully, but these errors were encountered: