Add standard exports into the documentation #529
Conversation
|
I guess the reason why those are still in the Google doc is that they are not quite finalized yet. But they should, obviously, so we could use this PR to do so. I'll leave a few comments, but I guess @brian-brazil has the strongest opinions on this. |
| In addition, client libraries are ENCOURAGED to also offer whatever makes sense | ||
| in terms of metrics for their language’s runtime (e.g. Garbage collection | ||
| stats). | ||
| at [standard exports](/docs/instrumenting/standard_exports). |
There was a problem hiding this comment.
I'd vote for including it right here instead of having yet another section.
The client library guide is anyway long, so no harm in making it a bit longer.
There was a problem hiding this comment.
This was mostly to separate it from clients.
If some things are standardized, it's also relevant for scrapers and consoles, not just for the ones writing clients.
Say I wanna write a generic template for metric visualizations, it'd be nice to know what some standard metrics are named, but I don't care about what conventions for other metrics are, I just want to be able to scrape some default ones.
|
👍 Thank you! All our documents were on Google once (client library guide lines, exporter, exposition formats, etc.). We simply haven't ported this yet, but the presented process metrics were the ones we agreed upon end of 2014. |
|
Ok, updated. Changes made (in separate commit) is:
Did not really change any phrasing, as I think you probably can come up with better ones anyway 😄 |
|
|
||
| In addition, client libraries are ENCOURAGED to also offer whatever makes sense | ||
| in terms of metrics for their language’s runtime (e.g. Garbage collection | ||
| stats). |
There was a problem hiding this comment.
I'd append "with an appropriate prefix such as go_, hostspot_" to separate them from the standard exports.
|
@brian-brazil Done 😄 |
| | Metric name | Help string | Unit | | ||
| | ------------------------------- | ------------------------------------------------------ | ------- | | ||
| | `process_cpu_seconds_total` | Total user and system CPU time spent in seconds. | Seconds | | ||
| | `process_open_fds` | Number of open file descriptors. | Integer | |
There was a problem hiding this comment.
The unit of open file descriptors is file descriptors.
|
@beorn7 @grobie @brian-brazil any other comments? It'd be great to land this so we can point to it 😄 |
| | `process_start_time_seconds` | Start time of the process since unix epoch in seconds. | Seconds | | ||
|
|
||
| In addition, client libraries are ENCOURAGED to also offer whatever makes sense | ||
| in terms of metrics for their language’s runtime (e.g. Garbage collection |
|
Just nits left from my side. We can iterate on larger additions or improvements later. For now, it's great to have this in the real docs. |
|
@beorn7 sounds great! I'll fix it as soon as I get to my laptop (half hour). Want me to squash, or do you use GH's squash? |
|
@SimenB Thanks! And that was my first time trying out GitHub's squash feature! |
* Fix the wrong statement * Fix a typo * Fix the statement * Fix the quotation mark * Update the statement of tikv-ctl * Update the MySQL related statement * Update the statement regarding the MySQL client * Add the link to the tutorial * adopter: update the latest adopter list * fix a type in faq * Address comments
It seems weird to me that this list lives on an open Google Docs document.
Even if it's work in progress, it should rather be marked as such instead of living somewhere else. This way, you have more control over it, and it makes it more official.
A benefit, other than the obvious standardizing, is discoverability. It took me quite some digging to find this, having Google index it might help.