On Wed, Jun 14, 2017 at 11:30 AM, Michael Scherer <mscherer@xxxxxxxxxx> 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,
--
Michael Scherer
Sysadmin, Community Infrastructure and Platform, OSAS
_______________________________________________
Gluster-devel mailing list
Gluster-devel@xxxxxxxxxxx
http://lists.gluster.org/mailman/listinfo/gluster-devel
--
Amar Tumballi (amarts)
_______________________________________________ Gluster-devel mailing list Gluster-devel@xxxxxxxxxxx http://lists.gluster.org/mailman/listinfo/gluster-devel
