OPMDG/opm-core

bug: public.create_graph_for_new_metric(p_id_server bigint)

Closed this issue · 3 comments

I really use OPM deeply. So, Thank you, all OPM contributors.

I found one bug on public.create_graph_for_new_metric(p_id_server bigint).

If one metric(usually database name) is added, new graph is created.
but, I want to show new metric data on existing graph.

So, I trace opm code. And I found If new metric is added, on public.create_graph_for_new_metric function , it added new data into graphs and series table.

So, same graph data is continuously added like this.

select * from public.graphs where graph = 'PGSQL-connections (no unit)';
17;"PGSQL-connections (no unit)";"";"{"type": "lines"}"
30;"PGSQL-connections (no unit)";"";"{"type": "lines"}"
65;"PGSQL-connections (no unit)";"";"{"type": "lines"}"
81;"PGSQL-connections (no unit)";"";"{"type": "lines"}"
87;"PGSQL-connections (no unit)";"";"{"type": "lines"}"

Please fix this issue. Thanks.

Hi geeluck,

Yes, I agree this behaviour is quite anoying at some point, but it's not a bug, it has been a design choice.

Imagine the following (real) examples:

  • a service which gather 10+ metrics and the admin splitted them accors multiple graphs, where the new serie should appears?
    *I do split the lock graph in two distinct one: the granted locks and the waiting ones. When the new "SIReadLock" appeared, where should it draw it ?
  • a graph is already messing with 20 or 30 series. and a new one appear. You would be pretty lucky if you seen it immediately, you might have loose this information.

That's why we decided to create a new graph to deal with these questions: it jumps to the admin head. But as I wrote, I 100% agree this is annoying and we should work on this issue.

The most promising idea would be do support drag'n'drop of series between graphs and auto-destruction of graph when they are empty. Any other idea or comment are welcome of course. This ossue is open for discussion :)

Regards,

Hi,

In a first time, we will change the behaviour when a new metric is detected:

  • if there is only one corresponding graph, we will add the new metric to this one ;
  • otherwise, we will create a new graph (which is the current behaviour).

Commit 6ed0ed8 implements this behavior, which is "don't create a new graph if there's only one graph that suits the new metric". News graphs will still be created if the admin already splitted metrics in multiple graphs.

So, with OPM 2.4, you can't rely on the new graph creation to check for new metrics. We could add some way to show this kind of information (like displaying the metrics that were added the last x days) if someone want this information.

@geeluck : sorry for the delay to deal with this issue.