let user know Node Name for OS metrics in pmm-admin
General
Escalation
General
Escalation
Description
The goal: We need to provide an easy way for the user to get an understanding on what the name of this current server.
User story:
As a PMM user I need to be able to run the pmm-admin command and see the Node name used for this Node/Server so that I can know what Node name I should use in Dashboards to see the metrics for this Nod
Use case:
As a Developer, I can log in into the server where someone else installed PMM and no DB Services added for monitoring. I need to get some way to know what Node-name was used/assigned by default for this Node.
Suggested solution:
use pmm-admin status command to provide information about the Node name used. this command is supposed to provide information about PMM
UI:
Original report:
To my knowledge, there is currently no easy way of mapping a node with its "node name" for OS metrics. An example:
If I were to add a MySQL exporter, for instance, we would have the "Service name" column in pmm-admin list output, showing us the name to be used in the GUI drop-down lists. However, there is no way to know this with the OS node_exporter, unless we guess it's default, and use pmm-admin config --help to see what defaults are, or if we use a command like history | grep pmm-admin to check past commands used. This is error prone, and confusing.
Is there a better way of checking this? If not, we should add it to the pmm-admin list command (or pmm-admin status, or any other you see fit).
How to test
None
How to document
None
AFFECTED CS IDs
CS0012555
Smart Checklist
Activity
Show:
Jira Bot September 30, 2020 at 7:55 PM
To: CC:
Hi, I'm jira-bot, Percona's Jira automation tool. I've detected that someone from Percona has made an edit to the Summary field of an issue that you reported.
I'm not sentient (yet) so I'm not sure whether the person fixed a typo, changed a few words, or completely rewrote the text. In any case, it is Percona Engineering's intention to make the Summary and Description of an issue as accurate as possible so that we're fixing the actual problem you're encountering, and to avoid misunderstandings about symptoms and causes.
If the current Summary does not accurately reflect the problem you are reporting, or if you feel the change was otherwise inappropriate in some way, please add a new comment explaining things and we'll address it as soon as we can.
This message will be added only once per issue, regardless of how many times the Summary is edited.
message-code:summary-edited
Agustin Gallego September 30, 2020 at 7:09 PM
Yes, that will be perfectly fine! Thanks, Roma!
Roma Novikov September 30, 2020 at 6:54 PM
thanks for the idea. I'm thinking about pmm-admin status as an option to display this information. will it work for your case/need?
The goal: We need to provide an easy way for the user to get an understanding on what the name of this current server.
User story:
As a PMM user I need to be able to run the pmm-admin command and see the Node name used for this Node/Server so that I can know what Node name I should use in Dashboards to see the metrics for this Nod
Use case:
As a Developer, I can log in into the server where someone else installed PMM and no DB Services added for monitoring. I need to get some way to know what Node-name was used/assigned by default for this Node.
Suggested solution:
use
pmm-admin status
command to provide information about the Node name used. this command is supposed to provide information about PMMUI:
Original report:
To my knowledge, there is currently no easy way of mapping a node with its "node name" for OS metrics. An example:
If I were to add a MySQL exporter, for instance, we would have the "
Service name"
column inpmm-admin list
output, showing us the name to be used in the GUI drop-down lists. However, there is no way to know this with the OS node_exporter, unless we guess it's default, and usepmm-admin config --help
to see what defaults are, or if we use a command likehistory | grep pmm-admin
to check past commands used. This is error prone, and confusing.Is there a better way of checking this? If not, we should add it to the
pmm-admin list
command (orpmm-admin status
, or any other you see fit).