-
Notifications
You must be signed in to change notification settings - Fork 283
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
Improve validator logging #2024
Conversation
Improve the logging when validators fail to perform duties.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
@@ -67,12 +70,10 @@ protected void deliverTo(final T subscriber, final Method method, final Object[] | |||
return (SafeFuture<X>) method.invoke(subscriber, args); | |||
} catch (IllegalAccessException e) { | |||
incrementCounter(failedEventCounter, subscriber, method); | |||
exceptionHandler.handleException(e, subscriber, method, args); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks like deliverToWithResponse
no longer sends errors to the exceptionHandler - is that okay?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah that was deliberate - the exception is reported back to the SafeFuture
. Previously we were double handling the problem resulting in noisy logs for things that we actually handled cleanly.
final ForkInfo forkInfo, | ||
final Attestation attestation, | ||
final ValidatorWithCommitteePosition validator) { | ||
return validator | ||
.getSigner() | ||
.signAttestationData(attestation.getData(), forkInfo) | ||
.thenApply(signature -> createSignedAttestation(attestation, validator, signature)) | ||
.thenAccept(validatorApiChannel::sendSignedAttestation); | ||
.thenAccept(validatorApiChannel::sendSignedAttestation) | ||
.thenApply(__ -> DutyResult.success(attestation.getData().getBeacon_block_root())); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we not want the attestation root here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The logs (when they used to work) have always shown the block the attestation is attesting to. That' actually a lot more useful because what you're most interested in is whether the attestation will wind up being on the correct chain and thus get rewarded.
@bgravenorst This one introduces a new CLI option. Defaults to off but useful if you want logs showing what the validators are doing (probably quite noisy if you run a lot of validators) |
PR Description
Introduce validator event logging to log when validators perform duties. This can be enabled with the
--log-include-validator-duties-enabled
option and is off by default (it would be very noisy when running a lot of validators).Improve the logging output when validators fail to perform duties.
Fixed Issue(s)
fixes #2019