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

Centralized Logging #90

Open
otaviof opened this issue Jan 19, 2022 · 3 comments
Open

Centralized Logging #90

otaviof opened this issue Jan 19, 2022 · 3 comments
Assignees
Labels
good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. kind/feature Categorizes issue or PR as related to a new feature.
Milestone

Comments

@otaviof
Copy link
Member

otaviof commented Jan 19, 2022

The command-line needs to print out information and errors for all sub-commands and we would benefit to have a single component responsible for this task. Right now we have a mixture of log and fmt.Printf going on, so we should come up with a new component which will be employed by all others that need to interact with the user.

Please share here your thoughts, and your ideas of what a logging component like this would have to have.

@otaviof otaviof added the kind/feature Categorizes issue or PR as related to a new feature. label Feb 3, 2022
@qu1queee qu1queee added good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. labels Feb 9, 2022
@qu1queee qu1queee added this to the release-v0.9.0 milestone Feb 9, 2022
@adambkaplan adambkaplan added the hacktoberfest Hacktoberfest Candidate Issues label Sep 28, 2022
@shubhamch71
Copy link

shubhamch71 commented Nov 1, 2023

Here are some of the ideas on what such a logging component should have:

  1. Logging Levels: Implement different logging levels, such as INFO, WARNING, ERROR, and DEBUG. This will allow us to control the verbosity of the logs based on user needs.

  2. Output Control: Define where the log messages should be directed, like the console, a file, or a remote server. This gives us flexibility in managing logs, especially in production scenarios.

  3. Message Formatting: Provide the ability to format log messages with timestamps, log levels, and any other relevant context information. This should be customizable to fit our application's needs.

  4. Color Coding: Consider adding color coding for different log levels. For example, errors can be shown in red to make them stand out.

  5. Log Rotation: Implement log rotation to prevent log files from becoming too large. This is particularly important when writing logs to files.

  6. Log Filters: Allow users to filter logs based on criteria like log level, keywords, or modules. This helps users focus on specific aspects of the application.

  7. Error Handling: Define how the logging component should behave when it encounters an error (e.g., when it cannot write to a file).

These are the ideas that I can think , please guide if anything is missing or anything is wrong!!

@qu1queee qu1queee removed the hacktoberfest Hacktoberfest Candidate Issues label Jan 11, 2024
@qu1queee qu1queee modified the milestones: release-v0.13.0, Backlog Jan 11, 2024
@qu1queee
Copy link
Contributor

From Refinement, this is a relevant item, but there is no milestone attached at the moment.

@Adarsh-jaiss
Copy link
Member

/assign

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Denotes an issue ready for a new contributor, according to the "help wanted" guidelines. help wanted Denotes an issue that needs help from a contributor. Must meet "help wanted" guidelines. kind/feature Categorizes issue or PR as related to a new feature.
Projects
Status: No status
Development

No branches or pull requests

6 participants