Open mckingho opened 6 years ago
I pick this task. It will start and finish by the end of phase 1.
To make a log more structural and searchable in future, I am proposing to make a more structural now. Following is a draft coming up from my mind.
logger is an object attached to the request as middleware, so the logger can provide context in log.
logger.debug('Summary of debug', {freeObj: null})
{
'channel': 'application',
'level': 'debug',
'message': 'Summary of debug',
'payload': {freeObj: null}
}
logger.info('GET /login', {params})
{
'channel': 'application',
'level': 'info',
'message': 'GET /login',
'payload': {params}
}
logger.metric('login', {likecoinID})
{
'channel': 'metric',
'event': 'login',
'payload': {likecoinId}
}
logger.metric('upload', {imgSha})
{
'channel': 'metric',
'event': 'upload',
'payload': {imgSha},
'user': {userIDfromrequest}
}
I am not sure mixing up behaviour and application is a good way. It really depends on what we want to log. Any idea?
I think it is fine to mix them up. It is good to maintain only one flow. The required logs are user events, e.g. uploading images, logging in, and error, exception logs. Adding logger middleware after route can handle above logs. In route part, I can add what exception has thrown or related database data to the req object.
For application logs, do you expect something similar to nginx access logs with request body? If so, it conflicts my above method, because i expect these should be logged before route.
Try to make the log work as a middleware of express too, so we don't need to pass the user info into every function call.
For application logs, do you expect something similar to nginx access logs with request body? If so, it conflicts my above method, because i expect these should be logged before route.
Agree, this log is not accesse log as in nginx.
api event log. logs wanted:
data flow or mq services are not concluded yet.