-
Notifications
You must be signed in to change notification settings - Fork 107
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 alarms #1336
Improve alarms #1336
Conversation
Reinitialize alarms with threshold more sensitive and monitor process restarted. Just watch in CloudWatch for sometime to see if that make sense. |
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.
+1, approving. Although I think we should move away from using boolean style metrics and we should just log numbers where possible. Maybe we can address in a separate PR.
Value: Number( | ||
channel.toEthereum.outbound < channel.toEthereum.inbound | ||
), | ||
Value: Number(channel.toEthereum.outbound < channel.toEthereum.inbound), |
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.
Instead of logging booleans, maybe we should log the difference. This would then be a metric of undelivered messages.
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.
785b59b metrics for the difference.
web/packages/operations/src/alarm.ts
Outdated
? parseInt(process.env["CheckIntervalToEthereum"]) | ||
: status.BlockLatencyThreshold.ToEthereum) && | ||
metrics.bridgeStatus.toEthereum.latestPolkadotBlockOnEthereum <= | ||
metrics.bridgeStatus.toEthereum.blockLatency > BlockLatencyThreshold.ToEthereum && |
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.
Maybe should also just log the blockLatency as a plain number instead of a boolean. Easier threshold management.
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.
SCAN_INTERVAL
more sensitiveResolves: https://linear.app/snowfork/issue/SNO-1233