You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

116 lines
5.7 KiB

6 years ago
6 years ago
6 years ago
6 years ago
  1. # ADR 011: Monitoring
  2. ## Changelog
  3. 08-06-2018: Initial draft
  4. 11-06-2018: Reorg after @xla comments
  5. 13-06-2018: Clarification about usage of labels
  6. ## Context
  7. In order to bring more visibility into Tendermint, we would like it to report
  8. metrics and, maybe later, traces of transactions and RPC queries. See
  9. https://github.com/tendermint/tendermint/issues/986.
  10. A few solutions were considered:
  11. 1. [Prometheus](https://prometheus.io)
  12. a) Prometheus API
  13. b) [go-kit metrics package](https://github.com/go-kit/kit/tree/master/metrics) as an interface plus Prometheus
  14. c) [telegraf](https://github.com/influxdata/telegraf)
  15. d) new service, which will listen to events emitted by pubsub and report metrics
  16. 2. [OpenCensus](https://opencensus.io/introduction/)
  17. ### 1. Prometheus
  18. Prometheus seems to be the most popular product out there for monitoring. It has
  19. a Go client library, powerful queries, alerts.
  20. **a) Prometheus API**
  21. We can commit to using Prometheus in Tendermint, but I think Tendermint users
  22. should be free to choose whatever monitoring tool they feel will better suit
  23. their needs (if they don't have existing one already). So we should try to
  24. abstract interface enough so people can switch between Prometheus and other
  25. similar tools.
  26. **b) go-kit metrics package as an interface**
  27. metrics package provides a set of uniform interfaces for service
  28. instrumentation and offers adapters to popular metrics packages:
  29. https://godoc.org/github.com/go-kit/kit/metrics#pkg-subdirectories
  30. Comparing to Prometheus API, we're losing customisability and control, but gaining
  31. freedom in choosing any instrument from the above list given we will extract
  32. metrics creation into a separate function (see "providers" in node/node.go).
  33. **c) telegraf**
  34. Unlike already discussed options, telegraf does not require modifying Tendermint
  35. source code. You create something called an input plugin, which polls
  36. Tendermint RPC every second and calculates the metrics itself.
  37. While it may sound good, but some metrics we want to report are not exposed via
  38. RPC or pubsub, therefore can't be accessed externally.
  39. **d) service, listening to pubsub**
  40. Same issue as the above.
  41. ### 2. opencensus
  42. opencensus provides both metrics and tracing, which may be important in the
  43. future. It's API looks different from go-kit and Prometheus, but looks like it
  44. covers everything we need.
  45. Unfortunately, OpenCensus go client does not define any
  46. interfaces, so if we want to abstract away metrics we
  47. will need to write interfaces ourselves.
  48. ### List of metrics
  49. | | Name | Type | Description |
  50. | --- | ------------------------------------ | ------ | ----------------------------------------------------------------------------- |
  51. | A | consensus_height | Gauge | |
  52. | A | consensus_validators | Gauge | Number of validators who signed |
  53. | A | consensus_validators_power | Gauge | Total voting power of all validators |
  54. | A | consensus_missing_validators | Gauge | Number of validators who did not sign |
  55. | A | consensus_missing_validators_power | Gauge | Total voting power of the missing validators |
  56. | A | consensus_byzantine_validators | Gauge | Number of validators who tried to double sign |
  57. | A | consensus_byzantine_validators_power | Gauge | Total voting power of the byzantine validators |
  58. | A | consensus_block_interval | Timing | Time between this and last block (Block.Header.Time) |
  59. | | consensus_block_time | Timing | Time to create a block (from creating a proposal to commit) |
  60. | | consensus_time_between_blocks | Timing | Time between committing last block and (receiving proposal creating proposal) |
  61. | A | consensus_rounds | Gauge | Number of rounds |
  62. | | consensus_prevotes | Gauge | |
  63. | | consensus_precommits | Gauge | |
  64. | | consensus_prevotes_total_power | Gauge | |
  65. | | consensus_precommits_total_power | Gauge | |
  66. | A | consensus_num_txs | Gauge | |
  67. | A | mempool_size | Gauge | |
  68. | A | consensus_total_txs | Gauge | |
  69. | A | consensus_block_size | Gauge | In bytes |
  70. | A | p2p_peers | Gauge | Number of peers node's connected to |
  71. `A` - will be implemented in the fist place.
  72. **Proposed solution**
  73. ## Status
  74. Implemented
  75. ## Consequences
  76. ### Positive
  77. Better visibility, support of variety of monitoring backends
  78. ### Negative
  79. One more library to audit, messing metrics reporting code with business domain.
  80. ### Neutral
  81. -