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 ***@***.***> 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 <#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 ***@***.***> 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 <#25 (comment)>, 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.