Open drewburr opened 3 months ago
@drewburr Makes sense to me. Would it be fine for you if the server_name
can be set in the plugin config?
As for the default, I'd suggest to do the following:
Do you agree?
I think setting server_name
via the plugin config would work great, with that value taking highest priority, if set. The suggested default values also sound like a good option, assuming this is available. I'm assuming this would be like pulling the level-name
from server.properties
?
can i work on this issue!
@geethika870 sure, go for it!
I want to give my comment. I can't use this plugin because, for example, I have dozens of servers and some of them are created automatically via CloudNet. I want to get data from all of them, such as memory, but I can't do it because the system forces me to manually enter each server. It's horrible. So actually I can only use for static servers, but even here it is inconvenient. I hope something will be worked out with server-name. For example, I have a cluster-id in some cross-server support plugins that defines the server id by “Lobby-*”, i.e. lobby-1,2,3. Could some such function be made, only more flexible.
@geethika870 just wanted to see if this is something you're still considering implementing? If it's fallen off, it would be worth making a note in here so another has the opportunity to pick it up
Is your feature request related to a problem? Please describe.
To help simplify the Prometheus configuration, it would be great if the
server_name
label populated by the exporter automatically. My thought is that if the provided dashboards can accept this information and, in a way, tend tend to expect it, it could make sense to have the exporter supply this value itself.Describe the solution you'd like
The ability to tell the exporter what value should be set for the
server_name
label, and for it to have a sensible default (i.e.minecraft
)Describe alternatives you've considered
In my Kubernetes environment, it's inconvenient to update the Prometheus scrape configs to provide these values. Alternatively, I can have these labels added in using
relabelings
ormetricRelabelings
on the serviceMonitor instead, but this makes templating options like Helm a bit of a pain to manage. While setting up my serviceMonitors, I wondered if it made sense for the exporter to define this label.Additional context
Given that this label is a fully static value, the cost to storage should be negligible. It would also simplify setup for those who are less familiar with Prometheus and run multiple servers. In addition, I believe that the suggested use of scrapeconfig would override any defaults that the exporter would set itself, meaning existing configuration shouldn't break.