| To: | Nathan Scott <nathans@xxxxxxxxxx> |
|---|---|
| Subject: | Re: RFC: filtered metrics |
| From: | fche@xxxxxxxxxx (Frank Ch. Eigler) |
| Date: | Wed, 09 Oct 2013 12:47:42 -0400 |
| Cc: | pcp@xxxxxxxxxxx |
| Delivered-to: | pcp@xxxxxxxxxxx |
| In-reply-to: | <1405249421.4047171.1381288021302.JavaMail.root@xxxxxxxxxx> (Nathan Scott's message of "Tue, 8 Oct 2013 23:07:01 -0400 (EDT)") |
| References: | <1717961238.2089908.1380100281235.JavaMail.root@xxxxxxxxxx> <y0mvc1g5tyg.fsf@xxxxxxxx> <1551478303.2549744.1381116552518.JavaMail.root@xxxxxxxxxx> <y0mwqlpyx0x.fsf@xxxxxxxx> <1405249421.4047171.1381288021302.JavaMail.root@xxxxxxxxxx> |
| User-agent: | Gnus/5.1008 (Gnus v5.10.8) Emacs/21.4 (gnu/linux) |
nathans wrote: > [...] Thinking system wide filters like "when looking at > per-process metrics, this system is expected to have N million > insts, so force a system wide filter for all access to per-process > metrics via a specified cgroup". [...] Would this be a administrative preference for security/load-limiting? If so, it's bound to be ineffective. Is it for a user's convenience, to automagically limit system view to her own context (if she's stuck within a cgroup)? That could be done by extending our use of the unix-socket SO_PEERCRED system to also pass the incoming pid to the pmdas, which could then (if desired - ie. in some PMNS subhierarchy) govern themselves accordingly. - FChE |
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | Re: RFC: filtered metrics, Nathan Scott |
|---|---|
| Next by Date: | pmdagfs2: Updates from continued testing and changes for future updates, Paul Evans |
| Previous by Thread: | Re: RFC: filtered metrics, Nathan Scott |
| Next by Thread: | Re: RFC: filtered metrics, Nathan Scott |
| Indexes: | [Date] [Thread] [Top] [All Lists] |