many roads to accomplish that and many tools available, that help you with it. i'll not going to show you all of them, but just what we ended up using at ResearchGate. They work great for us, but depending on your use cases other tools may be more suited to your needs. The important thing to get out of this talk: take care of it
this information but also write it to your log ﬁles, you can easily do this in your custom error handler, and if you need to ﬁnd the error that resulted in this error page you can just grep for the error code
/var/logs/apache/access.log custom http://httpd.apache.org/docs/2.2/mod/ mod_log_conﬁg.html#logformat and you conﬁgure it in apache like this, there is already lots of information from the request you can put in there, like url, response code, request time etc
"" ] ) but with the apache_note function you can add additional information from your application. by the way this is of course also possible with nginx, there you just set some response headers in php, in nginx you can then access these upstream headers, log them, and then ﬁlter them out so the clients don't get them
•Gelf •Null •Test •FingersCrossed nice thing is: it supports multiple handlers out of the box, to log wherever you need it, especially useful: the ﬁngers crossed handler: you just put your logs in this handler but it does not log them directly to a ﬁle, only when a certain condition was met, like a threshold all already written logs and all further logs are written to a ﬁle
Logger('name'); $handler = new StreamHandler( 'path/to/your.log', Logger::WARNING ); $handler->setFormatter(new JsonFormatter()); $log->pushHandler($handler); in monolog you can just set a formatter for this
user request log log log log log the setup may look like this, a request comes to a webserver and your php application on there calls other services. each of them have their own logs. for example the http service there. now if an error happens in the http service we are probably going to display an error as well in our php app. but how can we identify then which exception on the http service lead to the displayed error on the web server?
create unique trace_id for request user request trace_id trace_id trace_id trace_id log log log log log so when the user request ﬁrst hits your system you generate a unique trace_id for this request and you then pass this to all underlying services through an http header.
create unique trace_id for request user request trace_id trace_id trace_id trace_id log log log log log everyone then puts these tracing id in every logs they write. so if you have a tracing id you can easily ﬁnd all logs for this request by just greping for the trace_id
approach is to just send the messages in a special format (gelf, supported by a monolog handler) with a upd request from your app servers to graylog which stores them in elasticsearch. udp is quite nice since it is ﬁre and forget, so it does not inﬂuence our application too much (if you reuse connections and don't create a new one for each log)