-
Notifications
You must be signed in to change notification settings - Fork 70
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
feat(booster-http): --log-file, defaulting to stdout, for standardised http log output #1737
Conversation
Depends on a tag from ipld/frisbii#59 |
4ebbf13
to
a553475
Compare
Updated to tagged [email protected] |
example http log output from the e2e test, first using just a go request, then via bifrost-gateway, then lastly directly with lassie:
Compression ratios don't look very happy, because (a) it's pure random content and (b) most of these are tiny, one's 1 byte long; so not representative of typical unixfs content! |
I've simplified this to 2 commits - the main feature addition and the refactor of the piece handler to a separate file and pulled it in to #1676 so it can be reviewed as part of that. |
On top of #1736 which is on top of #1676, separate to make it a bit easier to review but they can be merged in reverse order.
The meat of this is in the first commit. There's noise because in the second commit I did a minor reorg and moved all of the
/piece/
handling code intopiecehandler.go
with minimal change to the substance. So consider reviewing just the first commit if you want to see the diff.This uses some exposed stuff in ipld/frisbii#59 to do logging nicely. I've removed the custom logging stuff in here and replaced it with a unified HTTP logging middleware with a consistent format that prints to stdout by default, but with
--log-file=/path/to/file.log
you can put it where you want it and get an nginx-like log output that should be parseable by http log parsing tools for metrics and whatnot.Log format is described here: https://github.com/ipld/frisbii#log-format, we could put that in the boost docs too as it may be helpful.
One nice feature that we get from this and #1736 is the compression ratio - we now collect both bytes written by the respective handlers, and bytes sent to the client, so we get compression ratio in the logs; see the tests where there's high-compression data being sent so we have high compression ratios.
Old
/piece/
handler log output looked something like this, two lines per log output (there's a\n
in there):New log output is:
So we get a single log line, same information and a bit more, and we see the bytes sent to user (
19458
) and compression ratio (513.93
, i.e.19458 x 513.93
~10,000,000
as on the original).