-
Improvement
-
Resolution: Unresolved
-
Minor
-
None
This is a follow-up of https://issues.jenkins-ci.org/browse/JENKINS-58282
The change performed by allan_burdajewicz in https://github.com/jenkinsci/cloudbees-folder-plugin/pull/129 gives the opportunity to configure Global Metrics at Global level which is great! However, as a Jenkins Support Engineer I am seeing escalation problems with these metrics when you are running big instances with a non SSD disk. I know that this Jira might produce some controversy, but I really think we should disable the health metrics at folderlevel by default given all the outages I am seeing when rendering "/" in big instances. Users ends up by creating a Groovy which runs periodically to disable the health metrics in all the folders, but for me, this is a non-sense.
My experience tells me that very few users are looking at the weather icon at folder level - Most of the times, it is more interesting at the job level. Indeed, each time that I ask Jenkins administrator to disable this, they have never come back to me telling me that developers are complaining.
I think that disabling this by default is really a win-win. You can always enable it and it gives Jenkins more chances to better scale vertically.
I am +1000 for this to be implemented.
[JENKINS-63836] Not add heath metrics by default in the Global Configuration of cloudbees-folder plugin
| Description |
Original:
This is a follow-up of https://issues.jenkins-ci.org/browse/JENKINS-58282 The change performed by [~allan_burdajewicz] in https://github.com/jenkinsci/cloudbees-folder-plugin/pull/129 gives the opportunity to configure Global Metrics at Global level which is great! However, as a Jenkins Support Engineer I am seeing escalation problems with these metrics when you are running big instances with a non SSD disk. I know that this Jira might produce some controversy, but I really think we should disable the health metrics at folder level given all the outages I am seeing when rendering "/" in big instances. Users ends up by creating a Groovy which runs periodically to disable the health metrics in all the folders, but for me, this is a non-sense. My experience tells me that very few users are looking at the weather icon at folder level - Most of the times, it is more interesting at the job level. Indeed, each time that I ask Jenkins administrator to disable this, they have never come back to me telling me that developers are complaining. I think that disabling this by default is really a win-win. You can always disable it and it gives Jenkins more chances to better scale vertically. I am +1000 for this to be implemented. |
New:
This is a follow-up of https://issues.jenkins-ci.org/browse/JENKINS-58282 The change performed by [~allan_burdajewicz] in https://github.com/jenkinsci/cloudbees-folder-plugin/pull/129 gives the opportunity to configure Global Metrics at Global level which is great! However, as a Jenkins Support Engineer I am seeing escalation problems with these metrics when you are running big instances with a non SSD disk. I know that this Jira might produce some controversy, but I really think we should disable the health metrics at folderlevel by default given all the outages I am seeing when rendering "/" in big instances. Users ends up by creating a Groovy which runs periodically to disable the health metrics in all the folders, but for me, this is a non-sense. My experience tells me that very few users are looking at the weather icon at folder level - Most of the times, it is more interesting at the job level. Indeed, each time that I ask Jenkins administrator to disable this, they have never come back to me telling me that developers are complaining. I think that disabling this by default is really a win-win. You can always enable it and it gives Jenkins more chances to better scale vertically. I am +1000 for this to be implemented. |
| Status | Original: Open [ 1 ] | New: In Progress [ 3 ] |
I agree, not sure this is useful for most of the people so it would probably be better to deactivate them. Other approach if this controversial might be to deactivate it with a system property. That would help us put some more data on this feeling.