[Gluster-devel] [Need Feedback] Monitoring

Amar Tumballi atumball at redhat.com
Wed Jun 14 17:08:24 UTC 2017


On Wed, Jun 14, 2017 at 11:30 AM, Michael Scherer <mscherer at redhat.com>
wrote:

> Le mardi 13 juin 2017 à 11:14 -0400, Amar Tumballi a écrit :
> > All,
> >
> > Please update the github issue [1], with what are the metrics you need to
> > see periodically. These may be metrics which helps you to understand the
> > health of the process, or the counters which gives insight into things to
> > monitor bottlenecks.
> >
> > I know there exists 'statedump' feature already. It provides some
> > information, but it also does provide more than required info like dump
> of
> > all inode table entries etc. What I am looking here is more of metrics
> > based on which, we can get a timebased graph.
> >
> > A simple example would be what is the number of malloc/free we have done
> > till now, and what is the total 'in-use' buffers (like you have info in
> > mem-pool), so you can see depending on work load how the memory usage
> > varies. A sample implementation i have looks like this [2].
> >
> > Feel free to ask questions, add pointers, and suggestions. This is not
> > about the tool for plotting graph, more of what should get in the graph.
>
> So the first question is:
> - who is gonna consume the stats ?
>
>
Sysadmins
Developers
Support personnels


> A sysadmin will not want the same stuff as someone focused on having a
> SLA to fullfill (like "all request must respond under X seconds").
>
>
We will differentiate at the display level to define what 'Dashboard' you
would need. Admins and Devs would choose different profiles.


> A team lead or a manager will not care about the same stuff (like,
> number of client served, to show to $upper_management that the systemm
> is used).
>
> And a developper will not want the same stuff either, as I am quite sure
> that they are likely the only ones caring about malloc/free, along with
> people focused on optimisation.
>
>
As explained earlier, I want to hear from all different angle, and have
code to provide all those information. We can't different builds, different
commands for different people. It will be differentiated at the display
layer.

So, please everyone, add more data at [1]

Regards,
Amar

[1] - https://github.com/gluster/glusterfs/issues/168



> --
> Michael Scherer
> Sysadmin, Community Infrastructure and Platform, OSAS
>
>
>
> _______________________________________________
> Gluster-devel mailing list
> Gluster-devel at gluster.org
> http://lists.gluster.org/mailman/listinfo/gluster-devel
>



-- 
Amar Tumballi (amarts)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gluster.org/pipermail/gluster-devel/attachments/20170614/9c9a732d/attachment.html>


More information about the Gluster-devel mailing list