Modernizing Tidepool: Part 7: Logging
In our last article, we explored our migration from a self-hosted Mongo database to the Atlas Mongo database hosted by MongoDB. In this article, we discuss how we handle logging.
Every programmer has used log messages to debug problems. We do too. For logging to be useful, we must:
- log the right data, and
- aggregate and persist the data that we need long term access too.
Logging the Right Data
We looked at the log messages generated by our services. Some services were very noisy. At this point of development, we needed the log messages for debugging. Noisy logs were impeding our progress, so we combed through each service to quiet the noisy ones. Some of our services log practically every HTTP request. Some log none. We still have much inconsistency.
Access Logging
As we mentioned in our blog post on our API Gateway, our gateway logs every HTTP access to our backend. We collect several fields from the request. We also log information about the response. Here are the fields that we log, using the Envoy access logging notation:
%REQ(:authority)%
%REQ(:scheme)%
%REQ(:method)%
%REQ(:path)%
%REQ(authorization)%
%REQ(content-type)%
%REQ(x-tidepool-trace-request)%…
