Update/correct logging for store-frontend about ecommerce-workshop HOT 5 CLOSED

Also noticed that the logs that are being processed (log lines with content duration...) have http.status_code: 200 or http.status_code: 500, but the official log status in DD is INFO. For the Ruby Integration Pipeline, log status is mapped to the attribute level.

Can logging in the service include categorizing http.status_code into a level attribute? Categories like the ones below or whatever would make sense for the app.

from ecommerce-workshop.

After more than a few rounds of local testing, I think lograge as we prescribe does not cover all cases for logging and thus we will probably want to update the docs to cover this particular case. Lograge is built around covering request logs, but doesn't cover caching or SQL queries for example which you point to up there. Even our own advice by default does not cover severity either so I will try to make some quick patches for now, but figure out a longer term solution with our ruby folks to see if there is a better out of the box method here.

from ecommerce-workshop.

I am now exploring using semantic logger to replace lograge. If it works, I will probably discuss with the docs and logs teams to see if we can shift our recommendations to that solution since it is more actively maintained and might have a better out of the box experience.

from ecommerce-workshop.

This is the furthest I can reasonably go in cutting down the logging noise right now

Once we can ship the default logs changes internally, I can do a fresh PR to switch us to semantic logger which will help a lot for formatting all the log messages correctly and work out of the box better.

from ecommerce-workshop.

This is now resolved by #80

from ecommerce-workshop.