Separate validation logs from operation logs #31
Comments
|
First draft by @pcarana (translated by me): Requirements
Log typesApplication/execution/operation logs
Validation logs
Proposal
Current: {
"log": {
"color-output": true | false,
"file-name-format": "global-url" | "local-path" | "file-name",
"output": "console" | "syslog",
"level": "error" | "warning" | "info" | "debug"
}
}Proposal: {
"log": {
"enable": true | false,
"color-output": true | false,
"file-name-format": "global-url" | "local-path" | "file-name",
"output": "console" | "syslog",
"level": "error" | "warning" | "info" | "debug"
},
"validation-log": {
"enable": true | false,
"color-output": true | false,
"file-name-format": "global-url" | "local-path" | "file-name",
"output": "console" | "syslog",
"level": "error" | "warning" | "info" | "debug"
}
}Definitions:
Default values:
|
I think these should be moved to the validation logs section.
Consider adding a {
"log": {
"enable": true | false,
(...)
"prefix": "[Operation log] "
},
"validation-log": {
"enable": true | false,
(...)
"prefix": "[Validation log] "
}
}These should probably default to empty strings. |
Maybe, but there's one reason that holds me for doing this: what if the "communication info/error" is the host's responsibility? e.g. the host where fort is running it's having network issues, or has a firewall that's blocking rsync/https. In that case, I believe it's important to notify the operator. As of today, there are common errors at the global RPKI servers, so yes, this logs will be present at the operation logs even when this isn't the host fault; but I think that's better to notify on any error of this kind at such logs which will be enabled by default, rather than sending them to the validation logs (that will be disabled by default).
I like this, let the prefix to be configured rather than hardcoded. Using empty strings as default: I'm not so sure; I would prefer to use the default values just as you wrote: What do you think regarding this comments? |
Each TAL maps to a very small amounts of servers. For example, a standalone run using Lacnic's TAL currently downloads files from repository.lacnic.net and rpki-repo.registro.br, and nowhere else. A standalone run using Afrinic's TAL downloads files from rpki.afrinic.net, and nowhere else. Therefore, it doesn't make sense to flood the operation logs with messages like Those belong to the validation logs. The operation logs should at most have one message per iteration like But I'd say that, as long as you could download at least one file from a server, then you can tell that any problems with that server are unlikely (impossible?) to be the host's responsibility. Personally, I would only notify the admin if the entire server is unavailable.
The validation log is disabled by default. That means that there is no need for a prefix by default. As a compromise, how about
|
This seems the way, there's no need to flood the operation logs with individual messages. The operation logs will have one general message related to a communication error only if such error persists. To achieve that, we could use a new argument to log this error (communication error) at the operation log only if the error has persisted after some time (e.g. if after 4 hours the download isn't successful). On the meanwhile, after that time hasn't passed yet, send this log the validation logs. There's only one exception to consider: the first validation run: if there's an error during this run, log it as a warning at the operation logs.
True, I like your proposal. Let's do it that way |
|
Add also the |
|
Can anyone help with the query: from which location of the server this log files can be viewed? |
|
Logs are sent to syslog. By default, my Ubuntu places them in |
|
I have not found anything on that location. Console is set for the logs. In
that case, where to view the logs?
Thanks.
…On Tue, Jun 28, 2022, 22:08 Alberto Leiva Popper ***@***.***> wrote:
Logs are sent to syslog. By default, my Ubuntu places them in
/var/log/syslog.
—
Reply to this email directly, view it on GitHub
<#31 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AZELP6C3DEXL6FZL2RSGKL3VRMPRJANCNFSM4MLCBTXQ>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
|
AFAIK, If If it's still not writing to |
Some people have manifested annoyance over the large volume of complaints that Fort logs due to issues found in the RPKI tree:
The admin running this is unlikely to have the authority to correct these problems, and they tend to obfuscate the actual operation errors, which are much more important for them.
On the other hand, downgrading the priority of these messages to debug would be a bit extreme because they can be helpful for people trying to validate the compliance of their own RPKI objects.
It has been therefore proposed to separate these messages into a separate logging channel.
Update: This bug is independent of incidences:
The text was updated successfully, but these errors were encountered: