Wouldn't the server-side stats potentially feed the persistent monitoring? On Sun, Jul 1, 2018 at 3:20 PM, John Spray <jspray@xxxxxxxxxx> wrote: > 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 -- 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
