README
Plink Functions
Logging
Realm offers extremely minimal logging facilities, and so we have our own cloud logging system (Graylog 2) to allow us to keep more extensive, powerful logs. Ask Andrew how to access Graylog if you need to look at these logs.
pipeToRemote
This function from util
is how logs messages are sent back to a remote host.
If you have a need, you can redirect the logs to somewhere other than Graylog easily
by changing the function passed to pipeToRemote.
Log Levels
emergency - 1
"HOLY SHIT IT'S ON FIRE!"
Something bad enough that, if an automated system to do this existed, an engineer should immediately be paged to come handle the error.
An emergency
should be a big enough deal that it could result in a major breach, corrupted collections,
system-wide failures, massive performance degradation racking up $10,000's+ in Realm/Atlas bills, etc.
An example would be detecting a bad value which indicates a programmer error which will disable the whole application, such as a bug that prevents anyone from logging in.
alert - 2
"First thing in the morning!"
An error which, if ignored until the morning, wouldn't be ruinous but could still cause serious consequences like lost business, a sullied image, a small breach, or very limited corruption of user data.
An example would be if users from a rather small locale (>1%) had a locale-specific bug which prevented them from using the application without corrupting anything.
error - 3
"Sometime before Friday..."
Usually if the input being processed by a function was invalid, and the whole request must be abandoned. Can also indicate what's very likely to be a programmer error.
An example would be the frontend generating requests which, in some edge cases, cannot be processed, or a permission which references a type of resource that doesn't exist.
Another good usage of an error
would be detecting that a document is corrupted, such as if
a required parent was not specified.
warning - 4
"I mean, we should fix it soon, but..."
Appropriate if this is the kind of thing you would want to stick out in the logs, such as a missing configuration value for which a (potentially suboptimal) default exists or if it's going to degrade performance or cause the user problems, a warning is fitting.
notice - 5
Just making the logs a little more useful
Something that isn't indicative of any programmer error but also isn't the "happy path".
An example would be that when a requester is not authorized to make a request.
This is the lowest logging level that is normally recorded.
and info - 6debug - 7
Primarily for debugging and profiling
Information about what the function is doing that isn't "spammy".
The difference between info
and debug
is pretty subjective, so here's an example for permissions:
- Recording the resources derived from a document change in derivePermissions is an
info
statement. - Logging the result of a single atomic permission comparison is a
debug
statement (because, for example, updating a Point might involve dozens of these).
info
and debug
logs will typically dump whole documents and large amounts of data, and so the
default logging level is set to 5,