Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refactor logging levels to use multiple winston transports #67

Open
adamegyed opened this issue Sep 12, 2020 · 1 comment
Open

Refactor logging levels to use multiple winston transports #67

adamegyed opened this issue Sep 12, 2020 · 1 comment
Assignees

Comments

@adamegyed
Copy link
Contributor

Right now, there is only one winston transport, which sends all logs to a slack hook, and options in the config to adjust what is logged. This presents some added complexity which can be refactored out, and leaves the potential for certain logging events that could be useful in a postmortem analysis to be lost if the config is set to not include certain event types.

A solution to this would be to adjust the logging levels of the winston slackhook, possibly with custom levels, to only report on large-scale, relevant updates, while keeping the low level logging intact. We could add another winston transport that would save the logs to log files, which would give deeper insight to debugging without forcing the slackhook to receive massive amounts of relatively simple operational data.

Additionally, there are certain drawbacks to using slack for logging, such as a scrollback maximum based on the free plan. While it is convenient to view, having a fallback can be very useful in the event of data loss due to Slack message rollover.

@adamegyed adamegyed added the performance Changes that result in more speed or efficiency label Sep 12, 2020
@haydenshively haydenshively added this to the September Polish milestone Sep 12, 2020
@adamegyed
Copy link
Contributor Author

This should also replace the usage of console.log anywhere in the code with winston logging at an appropriate level.

@adamegyed adamegyed self-assigned this Oct 6, 2020
@haydenshively haydenshively added nice-to-have and removed performance Changes that result in more speed or efficiency labels Oct 31, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants