Re: RFC: Telemetry revamp

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, 25 Jul 2019, Ernesto Puerta wrote:
> I'd add this one to the wish-list:
> 
> - Configuration settings (out of the >1500 available) diverging from their
> defaults (sensitive ones redacted).

https://github.com/ceph/ceph/pull/29334

?

sage

> 
> Kind regards,
> Ernesto
> 
> 
> 
> 
> On Thu, Jul 25, 2019 at 5:55 PM Sage Weil <sage@xxxxxxxxxxxx> wrote:
> 
> > On Thu, 25 Jul 2019, Lars Marowsky-Bree wrote:
> > > Hi all,
> > >
> > > I've had a chat with Sage & Dan Mick about the current state of
> > > telemetry, and I'd like to propose a few ideas to hopefully improve it
> > > and make the data collected more relevant.
> > >
> > > The current data is quite limited. I was able to take a look at, say,
> > > how many pools out there (well, of the ~300ish clusters that ever
> > > reported) have a non-2^n pg_num, but seeing whether this affects
> > > performance or data distribution was not possible.
> > >
> > > My goal is to have telemetry data that allows us to make more informed
> > > decisions about what matters to the user base; the comments below are
> > > not necessarily ordered by relevance, since they grew out of a thread on
> > > looking at the current data reported.
> > >
> > > Curious about your thoughts - too detailed information? Anything you'd
> > > like to see included? What'd help you in your area?
> > >
> > > - The crash section does expose actual hostnames ("entity_name"). If we
> > >   want to preserve that we can see whether it's the same entity crashing
> > >   or another, I'd propose that, similar to report_id, we generate a
> > >   report_secret_salt in the plugin that we don't share with the server -
> > >   we can then use this to hash any potential strings consistently.
> >
> > +1. This is high priority.. we need to get it into the next nautilus point
> > release, update the endpoint to scrub new reports, and scrub all existing
> > data.
> >
> > >   (This will change with Sage's pending PR to point this at a different
> > >   channel.)
> >
> > For reference, https://github.com/ceph/ceph/pull/28847.  I think this is
> > ready for review.
> >
> > > [...]
> >
> > All of this sounds nice to have... probably one item per PR to add the new
> > info.
> >
> > > - I'd pull contact/organization/description into a separate section and
> > >   channel. We'll need to also document what this information is used
> > >   for.
> >
> > This is added to my open PR above.
> >
> > > I'm wondering what the best way of tracking all wishes and then deciding
> > > on which to fulfil is.
> >
> > Trello? :)
> >
> > sage
> > _______________________________________________
> > Dev mailing list -- dev@xxxxxxx
> > To unsubscribe send an email to dev-leave@xxxxxxx
> >
> 
_______________________________________________
Dev mailing list -- dev@xxxxxxx
To unsubscribe send an email to dev-leave@xxxxxxx



[Index of Archives]     [CEPH Users]     [Ceph Devel]     [Ceph Large]     [Information on CEPH]     [Linux BTRFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux