dustball
Add logging library
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.
What kind of logging?
To accomplish ... ?
On Tue, Jan 3, 2017 at 10:46 PM falun [email protected] 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 .
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)
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 [email protected] 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 .
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.