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

Improve validator logging #2024

Merged
merged 4 commits into from
Jun 2, 2020
Merged

Conversation

ajsutton
Copy link
Contributor

@ajsutton ajsutton commented Jun 2, 2020

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

Copy link
Contributor

@mbaxter mbaxter left a 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);
Copy link
Contributor

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?

Copy link
Contributor Author

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()));
Copy link
Contributor

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?

Copy link
Contributor Author

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.

@ajsutton ajsutton merged commit 6a00f49 into Consensys:master Jun 2, 2020
@ajsutton ajsutton deleted the validator-logging branch June 2, 2020 22:50
@ajsutton
Copy link
Contributor Author

ajsutton commented Jun 2, 2020

@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)

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

Successfully merging this pull request may close these issues.

No aggregation could be created
2 participants