Where and how to store metrics for queries.

[Alexey Kuznetsov]

Hi, All!

I'm working on IGNITE-3443 "Implement collecting what SQL statements
executed on cluster and their metrics." [1]

And I need to discuss where and how store collected metrics.

I see 2 options:

1) Store metrics in a special separate replicated cache. In this case I
could easily add, collect and evict metrics. But I will need  somehow made
this cache "system" in order to not show it for users (for example in Visor
console).

2) Store metrics in system utility cache. In this case I could easily add
metrics, but collecting and evicting will be not so trivial...

Which way should I choose?

Please, share your thoughts.

[1] https://issues.apache.org/jira/browse/IGNITE-3443

--
Alexey Kuznetsov

[dsetrakyan]

Alexey, why do you need to store the SQL metrics in a cache? I would avoid
it. Instead, is there a way to have a local metric store on every node and
have WebConsole send a task to each node and aggregate the results?

D.

On Wed, Oct 5, 2016 at 9:56 PM, Alexey Kuznetsov <[hidden email]>
wrote:

> Hi, All!
>
> I'm working on IGNITE-3443 "Implement collecting what SQL statements
> executed on cluster and their metrics." [1]
>
> And I need to discuss where and how store collected metrics.
>
> I see 2 options:
>
> 1) Store metrics in a special separate replicated cache. In this case I
> could easily add, collect and evict metrics. But I will need  somehow made
> this cache "system" in order to not show it for users (for example in Visor
> console).
>
> 2) Store metrics in system utility cache. In this case I could easily add
> metrics, but collecting and evicting will be not so trivial...
>
> Which way should I choose?
>
> Please, share your thoughts.
>
> [1] https://issues.apache.org/jira/browse/IGNITE-3443
>
> --
> Alexey Kuznetsov
>

[Valentin Kulichenko]

Alexey,

Why do you need to store metrics in cache? For all our metrics we just
store them locally and aggregate on demand. What is the reason for
different approach here?

Generally, I think we should avoid using system caches wherever possible,
and probably rework current usages of such caches. If global notification
is needed, custom discovery message is much better option.

-Val

On Wed, Oct 5, 2016 at 9:56 PM, Alexey Kuznetsov <[hidden email]>
wrote:

> Hi, All!
>
> I'm working on IGNITE-3443 "Implement collecting what SQL statements
> executed on cluster and their metrics." [1]
>
> And I need to discuss where and how store collected metrics.
>
> I see 2 options:
>
> 1) Store metrics in a special separate replicated cache. In this case I
> could easily add, collect and evict metrics. But I will need  somehow made
> this cache "system" in order to not show it for users (for example in Visor
> console).
>
> 2) Store metrics in system utility cache. In this case I could easily add
> metrics, but collecting and evicting will be not so trivial...
>
> Which way should I choose?
>
> Please, share your thoughts.
>
> [1] https://issues.apache.org/jira/browse/IGNITE-3443
>
> --
> Alexey Kuznetsov
>

[Alexey Kuznetsov]

Dima & Val,

My first intention was to store metrics locally and collect them on demand.

But after that I start to think about following scenarios:

What if we have a grid with clients that connected to grid, execute some
query and *disconnected*?
In this case we would have no option to collect metrics about what queries
were executed on grid.

Also, very often clients may resided in a *slow* network segment and
sending a task for collecting metrics
 from *fast server nodes* and *slow clients* may take a lot of time in case
of large grid.

Could you suggest me how I could deal with two mentioned above cases?

Or we could ignore them for now?

--
Alexey Kuznetsov

[dsetrakyan]

To my knowledge we already use MongoDB in web console for storing user
profile data and other settings. How about you store all the metrics in
MongoDB as well?

On Thu, Oct 6, 2016 at 6:26 PM, Alexey Kuznetsov <[hidden email]>
wrote:

> Dima & Val,
>
> My first intention was to store metrics locally and collect them on demand.
>
> But after that I start to think about following scenarios:
>
> What if we have a grid with clients that connected to grid, execute some
> query and *disconnected*?
> In this case we would have no option to collect metrics about what queries
> were executed on grid.
>
> Also, very often clients may resided in a *slow* network segment and
> sending a task for collecting metrics
>  from *fast server nodes* and *slow clients* may take a lot of time in case
> of large grid.
>
> Could you suggest me how I could deal with two mentioned above cases?
>
> Or we could ignore them for now?
>
> --
> Alexey Kuznetsov
>