On Sat, Jun 30, 2018 at 5:08 PM Mykola Golub <to.my.trociny@xxxxxxxxx> wrote: > > On Fri, Jun 29, 2018 at 07:17:49PM +0100, John Spray wrote: > > > My preferred approach is to gather stats on the server side, and do it > > in a way that is flexible enough to work for CephFS as well. There's > > a sketch of a design here: > > https://tracker.ceph.com/projects/ceph/wiki/Live_Performance_Probes, > > which was written some time ago but never coded. > > Yes, and it looks like it could be very useful for real time > monitoring, for things like 'ceph/rbd top': > > https://pad.ceph.com/p/ceph-top > > I was not sure it could be used for persistent monitoring, when we > would want a set of stats from all images collected and stored in a > time series db. > > > The server side approach is more complex than client side > > instrumentation, but gives us a richer set of functionality (ability > > to break stats down however we want at runtime, not only per-client). > > > > > Or should we think that ceph-mgr is not designed for such a sort of > > > things and consider other solutions? > > > > The current use of ceph-mgr for gathering stats from server daemons is > > an opportunistic thing: because we already have a connection for > > command and control, it's efficient to piggy-back some stats on there > > too. It's probably not so worthwhile to try and use ceph-mgr for > > things like clients where it's only statistics. > > Understood. > > So, when talking about the server side apporoach for this particular > case, could it be a ceph-mgr module that when enabled asked osds to > tabulate their request streams by object name prefix and send periodic > reports to the mgr; the mgr module would combine reports and expose > metrics (to Prometheus)? Exactly. Ideally the Prometheus part would remain optional for people who needed persistence, while the realtime "top" functionality would work out of the box. John > > -- > Mykola Golub -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html