status-im
/
EIPs
mirror of https://github.com/status-im/EIPs.git
2
0
Fork 0
Code Issues Projects Releases Wiki Activity

Automatically merged updates to draft EIP(s) 2159 (#2249) 

Hi, I'm a bot! This change was automatically merged because:

 - It only modifies existing Draft or Last Call EIP(s)
 - The PR was approved or written by at least one author of each modified EIP
 - The build is passing
This commit is contained in:
Adrian Sutton 2019-08-23 07:17:06 +10:00 committed by EIP Automerge Bot
parent 8db2de158d
commit e92c13b3ba
1 changed files with 8 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

11
EIPS/eip-2159.md
View File

@ -14,7 +14,7 @@ created: 2019-07-01
## Simple Summary ## Simple Summary
<!--"If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the EIP.--> <!--"If you can't explain it simply, you don't understand it well enough." Provide a simplified and layman-accessible explanation of the EIP.-->
Standardized names of common metrics for Ethereum clients to use with [Prometheus](https://prometheus.io), a widely used monitoring and alerting solution. Standardized names of common metrics for Ethereum clients to use with Prometheus, a widely used monitoring and alerting solution.
## Abstract ## Abstract
<!--A short (~200 word) description of the technical issue being addressed.--> <!--A short (~200 word) description of the technical issue being addressed.-->
@ -44,7 +44,7 @@ Note that `ethereum_best_known_block_number` always has a value. When the `eth_s
<!--The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.--> <!--The rationale fleshes out the specification by describing what motivated the design and why particular design decisions were made. It should describe alternate designs that were considered and related work, e.g. how the feature is supported in other languages. The rationale may also provide evidence of consensus within the community, and should discuss important objections or concerns raised during discussion.-->
The defined metrics are independent of Ethereum client implementation but provide sufficient information to create an overview dashboard to support monitoring a group of Ethereum nodes. The defined metrics are independent of Ethereum client implementation but provide sufficient information to create an overview dashboard to support monitoring a group of Ethereum nodes.
There is a similar, though more prescriptive, specification for [beacon chain client metrics](https://github.com/ethereum/eth2.0-metrics/blob/master/metrics.md). There is a similar, though more prescriptive, specification for beacon chain client metrics.
The specific details of how to expose the metrics has been omitted as there is variance in existing implementations and standardising this does not provide any significant benefit. The specific details of how to expose the metrics has been omitted as there is variance in existing implementations and standardising this does not provide any significant benefit.
## Backwards Compatibility ## Backwards Compatibility
@ -56,7 +56,12 @@ Clients may already be publishing these metrics using different names and changi
## Implementation ## Implementation
<!--The implementations must be completed before any EIP is given status "Final", but it need not be completed before the EIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details.--> <!--The implementations must be completed before any EIP is given status "Final", but it need not be completed before the EIP is accepted. While there is merit to the approach of reaching consensus on the specification and rationale before writing code, the principle of "rough consensus and running code" is still useful when it comes to resolving many discussions of API details.-->
[Pantheon](https://pegasys.tech) switched to using these standard metric names in its 1.2 release ([see PR](https://github.com/PegaSysEng/pantheon/pull/1634)). Pantheon switched to using these standard metric names in its 1.2 release: https://github.com/PegaSysEng/pantheon/pull/1634.
## References
1. Prometheus. https://prometheus.io
2. Beacon chain metrics specification. https://github.com/ethereum/eth2.0-metrics/blob/master/metrics.md
## Copyright ## Copyright
Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/). Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).