New metrics

[aviorma]

ould like to ask from if you could add some new metrics,
i would like to see some info which is important for our devops team
Jira: sprint remaining time per project, and log work per project,sprint,issue

[AndreyVMarkelov]

Will be done

[aviorma]

Thanks

[PatrickSchuster]

Hi,
I'm currently looking into this, but I have a few questions/concerns:
Having the remaining time, logged work (= worklog?), issues, etc. per project/sprint/issue might lead to a lot of output in case a team handles a lot of projects/issues/etc., right?
Might this be a problem for the performance of the Prometheus instance?

I'm trying to retrieve all relevant metrics and use Prometheus labels but have doubts if I can do it efficiently.

[aviorma]

Prometheus instance can handle with High number of metrics

The mission is to programmed with no delays.

[wbrauneis]

On the (non-)usage of labels please be referred to https://prometheus.io/docs/practices/naming/

CAUTION: Remember that every unique combination of key-value label pairs represents a new time series, which can dramatically increase the amount of data stored. Do not use labels to store dimensions with high cardinality (many different label values), such as user IDs, email addresses, or other unbounded sets of values.

and individual issues as labels imho are even worse in this respect than user ids...

[PatrickSchuster]

So far I have been experimenting with the time spent per project and per issue (see the following "worklog" metrics) and the result looks something like this:

However, I agree that having a lot of individual labels might be a problem.
I tried finding a better way of doing something like this and stumpled upon a similiar question: prometheus/prometheus#1015 where a core developer of Prometheus suggests:

You should use a general purpose processing system, such as Hadoop or Spark. Prometheus is intended as a real-time monitoring system that you can easily run and depend on in an emergency. High cardinality metrics tend to only grow and require work disproportionate to the benefit they bring you in such a system, and dealing with them in a less-realtime fashion is more appropriate.

How do you suggest we proceed in this matter?

[AndreyVMarkelov]

@PatrickSchuster Not really sure about issueKey. I think project is good enought

[aviorma]

Implementing issuekey will increase the number of metrics I think issues per project is enough Thanks you

…

On Thu, 12 Apr 2018 at 9:25 Andrey Markelov ***@***.***> wrote: @PatrickSchuster <https://github.com/PatrickSchuster> Not really sure about issueKey. I think project is good enought — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#21 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ASvoPdNtiudDCazOs51sIL-kg8tbdXqrks5tnvNOgaJpZM4TDQw6> .

[aviorma]

Sorry, I mean log work per project.

…

On Thu, 12 Apr 2018 at 14:17 Avior Malkukian ***@***.***> wrote: Implementing issuekey will increase the number of metrics I think issues per project is enough Thanks you On Thu, 12 Apr 2018 at 9:25 Andrey Markelov ***@***.***> wrote: > @PatrickSchuster <https://github.com/PatrickSchuster> Not really sure > about issueKey. I think project is good enought > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#21 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/ASvoPdNtiudDCazOs51sIL-kg8tbdXqrks5tnvNOgaJpZM4TDQw6> > . >

[PatrickSchuster]

Hi everyone,
I've added the number of projects as well as the times spent per project (link to pull request). The result looks something like this:

Let me know if this is useful or not. Also, I'm still not sure if this could cause problems in case there are a lot of projects, so please keep that in mind.

Thank you!

[Rohlik]

Please add also Jira version metric.
Thank you.

[lexek]

I don't understand why this should be implemented in this project.
As far as I understand, this project's purpose is to monitor health of Jira instance, and these metrics aren't related to this.

[AndreyVMarkelov]

@lexek Actually when implement feature to have all metrics togables it can be there.

[nteplov]

Maybe create an additional branch: "Various garbage for prometheus" and don't touch the main one in pursuit of stability?

[AndreyVMarkelov]

@nteplov It is not bed to have these metrics toggleable and switched off by default and maybe can active per project if cordinality allows. But in this way 100% sure not be applied.

[diverser]

Make it optional, configurable from plugin settings

[AndreyVMarkelov]

Yes. +1

[Rohlik]

@lexek If you have multiple instances then "JIRA version" come in handy for comparing JIRA health.

[lexek]

@Rohlik Jira version is legit of course, I was talking about original request.

[wbrauneis]

Having the version number available for display in the grafana dashboard is, at least for us, valuable information. It would then be possible for our administrators to quickly check versions in case of a vulnerability report without having to access all individual Jira instances.

Some of our systems (not Jira) even actively send out alerts based on prometheus metrics in case of available (important) software updates. Wish we could achieve the same with Atlassian products. But until then, the version number is perfectly fine for us.

From a performance perspective, having looked up Jira source code (v6.3.15), an additional gauge for the version information should not have any impact on the performance of the plugin or the prometheus system.

I am tempted to call this security monitoring, and we consider security to part of health care of our system, m2c :-).

@Rohlik would you mind to open another ticket for your request?