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)? -- 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
