On Mon, Jul 2, 2018 at 12:15 PM Brett Niver <bniver@xxxxxxxxxx> wrote: > > Wouldn't the server-side stats potentially feed the persistent monitoring? Yes, that's what I'm getting at. The confusing part is that we've got two potential roles for prometheus here: - rigging up a direct client monitoring in the absence of server side stats - acting as an optional persistence layer for the server side stats. John > > > 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
