mirror of
https://github.com/fnproject/fn.git
synced 2022-10-28 21:29:17 +03:00
cbe0d5e9ac
* add user syslog writers to app users may specify a syslog url[s] on apps now and all functions under that app will spew their logs out to it. the docs have more information around details there, please review those (swagger and operating/logging.md), tried to implement to spec in some parts and improve others, open to feedback on format though, lots of liberty there. design decision wise, I am looking to the future and ignoring cold containers. the overhead of the connections there will not be worth it, so this feature only works for hot functions, since we're killing cold anyway (even if a user can just straight up exit a hot container). syslog connections will be opened against a container when it starts up, and then the call id that is logged gets swapped out for each call that goes through the container, this cuts down on the cost of opening/closing connections significantly. there are buffers to accumulate logs until we get a `\n` to actually write a syslog line, and a buffer to save some bytes when we're writing the syslog formatting as well. underneath writers re-use the line writer in certain scenarios (swapper). we could likely improve the ease of setting this up, but opening the syslog conns against a container seems worth it, and is a different path than the other func loggers that we create when we make a call object. the Close() stuff is a little tricky, not sure how to make it easier and have the ^ benefits, open to idears. this does add another vector of 'limits' to consider for more strict service operators. one being how many syslog urls can a user add to an app (infinite, atm) and the other being on the order of number of containers per host we could run out of connections in certain scenarios. there may be some utility in having multiple syslog sinks to send to, it could help with debugging at times to send to another destination or if a user is a client w/ someone and both want the function logs, e.g. (have used this for that in the past, specifically). this also doesn't work behind a proxy, which is something i'm open to fixing, but afaict will require a 3rd party dependency (we can pretty much steal what docker does). this is mostly of utility for those of us that work behind a proxy all the time, not really for end users. there are some unit tests. integration tests for this don't sound very fun to maintain. I did test against papertrail with each protocol and it works (and even times out if you're behind a proxy!). closes #337 * add trace to syslog dial
54 lines
1.8 KiB
Markdown
54 lines
1.8 KiB
Markdown
# Logging
|
|
|
|
There are a few things to note about what Fn logs.
|
|
|
|
## Logspout
|
|
|
|
We recommend using [logspout](https://github.com/gliderlabs/logspout) to forward your logs to a log aggregator of your choice.
|
|
|
|
## Format
|
|
|
|
All logs are emitted in [logfmt](https://godoc.org/github.com/kr/logfmt) format for easy parsing.
|
|
|
|
## Call ID
|
|
|
|
Every function call/request is assigned a `call_id`. If you search your logs, you can track all the activity
|
|
for each function call and find errors on a call by call basis. For example, these are the log lines for an aynschronous
|
|
function call:
|
|
|
|
|
|
|
|
Note the easily searchable `call_id=x` format.
|
|
|
|
```sh
|
|
call_id=477949e2-922c-5da9-8633-0b2887b79f6e
|
|
```
|
|
|
|
## Remote syslog for functions
|
|
|
|
You may add a syslog url to any function application and all functions that
|
|
exist under that application will ship all of their logs to it. You may
|
|
provide a comma separated list, if desired. Currently, we support `tcp`,
|
|
`udp`, and `tls`, and this will not work if behind a proxy [yet?] (this is my
|
|
life now). This feature only works for 'hot' functions.
|
|
|
|
An example syslog url is:
|
|
|
|
```
|
|
tls://logs.papertrailapp.com:1
|
|
```
|
|
|
|
We log in a syslog format, with some variables added in logfmt format. If you
|
|
find logfmt format offensive, please open an issue and we will consider adding
|
|
more formats (or open a PR that does it, with tests, and you will receive 1
|
|
free cookie along with the feature you want). The logs from the functions
|
|
themselves are not formatted, only our pre-amble, thus, if you'd like a fully
|
|
logfmt line, you must use a logfmt logger to log from your function.
|
|
|
|
* All log lines are sent as level error w/ the current time and `fn` as hostname.
|
|
* call_id, func_name, and app_id will prefix every log line.
|
|
|
|
```
|
|
<11>2 1982-06-25T12:00:00Z fn - - - - call_id=12345 func_name=yo/yo app_id=54321 this is your log line
|
|
```
|