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

Limit messages to journald #2

Open
gufmar opened this issue Jul 28, 2023 · 2 comments
Open

Limit messages to journald #2

gufmar opened this issue Jul 28, 2023 · 2 comments
Assignees
Labels
enhancement New feature or request

Comments

@gufmar
Copy link
Collaborator

gufmar commented Jul 28, 2023

blockperf should output the details of the block propagation data to the console or, if explicitly requested by the operator, to the journal log.

By default - when blockperf is started as a systemd service - the journal log should only show that blockperf was started successfully as a service, and with which configuration it is running (networkmagic, port, mqtt target server).
In addition only errors and warnings (e.g. mqtt endpoint timeout, or incomplete parsing data for a block) should be logged.

@oversize oversize added this to the Internal Alpha Release milestone Jul 31, 2023
@oversize oversize added the enhancement New feature or request label Aug 24, 2023
@oversize oversize self-assigned this Sep 4, 2023
@oversize
Copy link
Member

oversize commented Sep 4, 2023

Yes, good point. Currently the way the output is generated is a bit messy.

So in a default setting, it should only write to stdout a handfull of initial configs/settings it has parsed and is going to run with. Plus anything of warning/error level that can happen during runtime.

Can you elaborate a little on what the user should be able to configure? Or how the configuration could look like? There is a --debug flag that one can provide that prints out alot of extra stuff that propably noone other then us will need for now.

But there certainly is also a middle ground which provides what you describe. But again, i am currently not having a good idea on how the user could specify that? Would it also go to stdout (thus journald), some extra file?

@gufmar
Copy link
Collaborator Author

gufmar commented Sep 7, 2023

I would suggest to have a (default) console, and a special service mode.

If the script is started in console mode, it should show all information it currently does.
In service mode, on the other hand, when no one is paying attention, all this data should not fill the journal logs.
In this mode, the script should only output information about startup/shutdown, as well as warning and critical messages for the parsing and transfer operations, if any

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants