plink-functions v1.0.123

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.

info - 6 and debug - 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,