Document how one can disable/enable ELK output

[Trolldemorted]

for test setups w/o an elk

[ldruschk]

I don't think there is a user-facing setting for this atm

[domenukk]

For what it's worth, it looks like there used to be, see:

enochecker/src/enochecker/enochecker.py

Line 178 in d620593

runparser.add_argument(

It could make sense to bring it back.

[ldruschk]

But it would make more sense to have that as a global setting regardless of the runmode, right? When running the checker in listen mode locally for testing purposes, we would still like the human-readbale logs

[domenukk]

Maybe an env var to enable elk logging in docker?

[ldruschk]

we could also enable/disable it depending on the SERVER_SOFTWARE env variable: https://stackoverflow.com/a/25877937

[ldruschk]

Or maybe that is still too specific, generally I would assume we want to disable ELK logging when running it via command line (regardless of the run mode) and enable it otherwise, which would be when run through gunicorn/uwsgi/whatever

[Trolldemorted]

After giving this some more thought, should we switch this discussion to enospec and decide on a dedicated environment variable or something similar?

This way we can have CI disable elk output for all checkers.

[domenukk]

Or maybe that is still too specific, generally I would assume we want to disable ELK logging when running it via command line (regardless of the run mode) and enable it otherwise, which would be when run through gunicorn/uwsgi/whatever

While developing, you may still use the HTTP version of the checker in a docker, but you still want to disable JSON output, right?

[ldruschk]

Yes, but I would prefer default settings that could lead to people seeing JSON-formatted docs during development instead of having no logs in ELK in production due to a missing environment variable

[Savallator]

Would you really want to specify another logging format then? Because the ELK output is well defined and could also be parsed by the CI. Introducing another spec for a different log format shared by all checkers would just make it more complicated, without any significant gain imho.

[Trolldemorted]

Would you really want to specify another logging format then? Because the ELK output is well defined and could also be parsed by the CI. Introducing another spec for a different log format shared by all checkers would just make it more complicated, without any significant gain imho.

We don't have to specify the other format, specifying when and when not it does emit ELK-ready output should suffice.

[domenukk]

If I understand @Trolldemorted correctly, he wants to specify how to change the logs to human-readable format, so that it's the same for all checkers.
How the human-readable logs themself look can then differ (as humans are rather good at parsing)
Worst case, the checker can still choose to always output the same jsons format, it would just be painful to use.

[Savallator]

This way we can have CI disable elk output for all checkers.

I was referring this. If the CI disables ELK output, it can not automatically scan for errors...

[ldruschk]

The CI should not need to parse log output at all, all relevant information should be in the HTTP responses. This is more about humans being able to manually read through the logs in case something fails during CI runs

[Savallator]

I thought you wanted to parse the output to filter out the messages from the erroring run and show them in a condensed form to the user.