* p2p: add a per-message type send and receive metric (#9622)
* p2p: ressurrect the p2p envelope and use to calculate message metric
Add new SendEnvelope, TrySendEnvelope, BroadcastEnvelope, and ReceiveEnvelope methods in the p2p package to work with the new envelope type.
Care was taken to ensure this was performed in a non-breaking manner.
Co-authored-by: William Banfield <4561443+williambanfield@users.noreply.github.com>
Co-authored-by: William Banfield <wbanfield@gmail.com>
* Ignore generated/copied RPC docs
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Sync vuepress config with main
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Sync docs package-lock.json with main
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Sync docs redirects with main
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Sync docs versions with main
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Update OpenAPI version to v0.34
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Sync DOCS_README with main
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Update all v0.34.x docs references from master to main
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Update v0.34 OpenAPI references from master to main
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Update repo doc links from master to main
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Update code comment references from master to main
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Update repo root doc links from master to main
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Update repo root doc links for docs.tendermint.com from master to main
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Build v0.34.x as "latest"
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Explicitly mark v0.34 docs as latest in version selector
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Add nav link to main and clearly mark as unstable
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Direct all docs.tendermint.com links to v0.34 on v0.34.x
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Update all relevant links on v0.34.x branch to be v0.34-specific
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Update changelog refs to docs.tendermint.com
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Update remaining GH master link to main
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Sync docs build and nav config with main
Signed-off-by: Thane Thomson <connect@thanethomson.com>
* Migrate spec links to GitHub repo from docs site
Signed-off-by: Thane Thomson <connect@thanethomson.com>
Signed-off-by: Thane Thomson <connect@thanethomson.com>
This change updates the lock handling in the consensus reactor. The consensus reactor now periodically fetches the RoundState and the gossip routines operate on this fetched copy instead of fetching the latest copy in each iteration of the gossip routine.
* change lock handling in consensus state file
* add comment explaining the unlock
* comment fix
* Update consensus/state.go
Co-authored-by: M. J. Fromberger <fromberger@interchain.io>
* spelling fix
Co-authored-by: M. J. Fromberger <fromberger@interchain.io>
* consensus: calculate prevote message delay metric (#7551)
## What does this pull request do?
This pull requests adds two metrics intended for use in calculating an experimental value for `MessageDelay`.
The metrics are as follows:
```
# HELP tendermint_consensus_complete_prevote_message_delay Difference in seconds between the proposal timestamp and the timestamp of the prevote that achieved 100% of the voting power in the prevote step.
# TYPE tendermint_consensus_complete_prevote_message_delay gauge
tendermint_consensus_complete_prevote_message_delay{chain_id="test-chain-aZbwF1"} 0.013025505
# HELP tendermint_consensus_quorum_prevote_message_delay Difference in seconds between the proposal timestamp and the timestamp of the prevote that achieved a quorum in the prevote step.
# TYPE tendermint_consensus_quorum_prevote_message_delay gauge
tendermint_consensus_quorum_prevote_message_delay{chain_id="test-chain-aZbwF1"} 0.013025505
```
## Why this change?
For more information on what these metrics are calculating, see #7202. The aim is to merge to backport these metrics to v0.34 and run nodes on a few popular chains with these metrics to determine the experimental values for `MessageDelay` on these popular chains and use these to select our default `SynchronyParams.MessageDelay` value.
## Why Gauges for the metrics?
Gauges allow us to overwrite the metric on each successive observation. We can then capture these metrics over time to track the highest and lowest observed value.
(cherry picked from commit 0c82ceaa5f)
# Conflicts:
# consensus/metrics.go
# consensus/state.go
* fix merge conflicts
Co-authored-by: William Banfield <4561443+williambanfield@users.noreply.github.com>
Co-authored-by: William Banfield <wbanfield@gmail.com>
Issues reported in Osmosis, where the message is extremely long. Also, there is absolutely no reason to log the message IMO. If we must, we can make the message log DEBUG.
(cherry picked from commit 58a6cfff9a)
Co-authored-by: Aleksandr Bezobchuk <alexanderbez@users.noreply.github.com>
This is an attempt to clean up the logging message as requested in #6269.
(cherry picked from commit 3f9066b290)
Co-authored-by: Sam Kleinman <garen@tychoish.com>
Executed a local network using simapp and looked for logs that seemed superfluous. This isn't by any means an exhaustive grooming, but should drastically help legibility of logs.
ref: #5912
Conflicting votes are now sent to the evidence pool to form duplicate vote evidence only once
the height of the evidence is finished and the time of the block finalised.
blockchain/vX reactor priority was decreased because during the normal operation
(i.e. when the node is not fast syncing) blockchain priority can't be
the same as consensus reactor priority. Otherwise, it's theoretically possible to
slow down consensus by constantly requesting blocks from the node.
NOTE: ideally blockchain/vX reactor priority would be dynamic. e.g. when
the node is fast syncing, the priority is 10 (max), but when it's done
fast syncing - the priority gets decreased to 5 (only to serve blocks
for other nodes). But it's not possible now, therefore I decided to
focus on the normal operation (priority = 5).
evidence and consensus critical messages are more important than
the mempool ones, hence priorities are bumped by 1 (from 5 to 6).
statesync reactor priority was changed from 1 to 5 to be the same as
blockchain/vX priority.
Refs https://github.com/tendermint/tendermint/issues/5816
After a reactor has failed to parse an incoming message, it shouldn't output the "bad" data into the logs, as that data is unfiltered and could have anything in it. (We also don't think this information is helpful to have in the logs anyways.)
This fixes spurious `TestByzantinePrevoteEquivocation` failures by extending the block range and time spent waiting for evidence. I've seen many runs where the evidence isn't committed until e.g. height 27. Haven't looked into _why_ this happens, but as long as the evidence is committed eventually and the test doesn't spuriously fail I'm (mostly) happy. WDYT @cmwaters?
## Description
Part of the issue is to add metrics to the websocket connection. It seems this would require some moving around of things in the node pkg. I opted to not make this change now, and wait for when we do a node pkg refactor.
If someone disagrees with this appraoch please let me know, I can attempt to get metrics into the rpc layer.
There is not a need to update documentation as it already states this metric is a histogram..
Closes: #1791
