Add statistics and log collection infrastructure

[nuest]

We have a Piwik instance running, so we could use it's reporting API to observe direkt calls to the API (which might not come from our website).

• https://github.com/fvdm/nodejs-piwik
• https://github.com/fhemberger/piwik-tracker

Alternatively (or preferably, we can simply analyse the nginx and webapp logs. See discussion below.

Tasks

• [ ] extend app logs to reflect all calls and actions that take some time
• [ ] evaluate piwik log analytics using the nginx logs, see https://piwik.org/docs/log-analytics-tool-how-to/ and https://piwik.org/log-analytics/
• [ ] if piwik does not suffice, then evaluate and install log collection solution (ELK, Prometheus, ..) on the server and collect the microservice's logs, see e.g. http://logz.io/learn/docker-monitoring-elk-stack/

[JanKoppe]

I'm not convinced that piwik should be integrated in our services. A cleaner solution would be to use nginx's log files, i.e. https://piwik.org/log-analytics/. This would a) not introduce more dependencies into the services and b) centralize the connection between API access and analytics.

[nuest]

I see your point, and Piwik Log Analytics look promising.

Another alternative would be collecting and analysing the logs with the ELK stack. This would require us to log the relevant information, though!

@JanKoppe Is it currently the case that all "timed" events (start of X, end of X) are written to the log? These statements must also be connected, for example via a request identifier. And the "end" statements should/must include a field saying "execution took X ms". Right?

[JanKoppe]

No, as of now the execution time for a request is not logged. I'm pretty sure that this is possible with nginx though, that should be done for the access_log. If not, we could extend the middleware in the microservices that logs every request (i.e. `GET request for …). Should be doable.

Also, I'm not sure if Piwik is really the best tool for performance analysis of the API. Something like Prometheus would be more suitable IMO.

[nuest]

I agree and updated the first comment accordingly.