Add logging library

[falun]

echo just doesn't cut it any more.

Need to add a logging library and make it configurable. The problem here is finding a good balance between simplicity (of use & config) and flexibility.

This should include updating docs/Production.md or linking from it to a doc describing logging solution.

[dustball]

What kind of logging?

To accomplish ... ?

On Tue, Jan 3, 2017 at 10:46 PM falun notifications@github.com wrote:

echo just doesn't cut it any more.

Need to add a logging library and make it configurable. The problem here is finding a good balance between simplicity (of use & config) and flexibility.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/dustball/gping.io/issues/25, or mute the thread https://github.com/notifications/unsubscribe-auth/AAHjUsE4-1eoQjLWitgwKK4fthKROeYgks5rO0AzgaJpZM4LaVY4 .

[falun]

logging error output (stack traces and such) that we don't want to push back to clients but would be nice to have for debugging.

We would hook into www/api-logging.php.

In fancy-fancy land we could also do stuff like hooking to external log/error aggregation services via RPC or message queue (since it seems lame to block our API on a disk write on error)

[dustball]

How about a dev/production flag?

On dev, spit out to the client.

On prod, log to syslog (fast, reliable, and well understood)?

On Wed, Jan 4, 2017 at 12:58 AM falun notifications@github.com wrote:

logging error output (stack traces and such) that we don't want to push back to clients but would be nice to have for debugging.

We would hook into www/api-logging.php.

In fancy-fancy land we could also do stuff like hooking to external log/error aggregation services via RPC or message queue (since it seems lame to block our API on a disk write on error)

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/dustball/gping.io/issues/25#issuecomment-270323575, or mute the thread https://github.com/notifications/unsubscribe-auth/AAHjUlMVYahandX_ry5Fma06_Y8Ia9-Nks5rO19IgaJpZM4LaVY4 .

[falun]

In general I want to avoid the client so even on dev I was imagining not printing to stdout so as to not break the "don't output content before header calls" rule.

I have no objection to syslog as a destination or doing a simple but relatively rigid system initially. The only thing I'd really like is to have an easy way to switch to a psr-3 compatible logger in the future if we need. That could be trivially accomplished by just having all our log functions in a single place instead of doing some kind of:

if ($prod) {
   prod_log(...);
} else {
    dev_log(...);
}

pattern everywhere.