Hi Frank,
Thanks for your reply. See mine inline.
AG
> -----Original Message-----
> From: Frank Ch. Eigler [mailto:fche@xxxxxxxxxx]
> Sent: 27 July 2015 23:31
> To: Aurelien Gonnay
> Cc: pcp@xxxxxxxxxxx; TED-DEV-CSP
> Subject: Re: [question] PCP UI FrontEnd
>
>
> aurelien.gonnay wrote:
>
> > [...]
> > 1. Metric name encoding: our servers are using ?-? in their name,
> > which
> > do not play well with the metric name encoding.
>
> Hyphens are used as an escape code for generic punctuation that can be
> present in pcp file names / metrics / instance names, but not in
> graphite name components. So host names like "foo-bar" will be
> represented with something like "foo-2E-bar". It's a necessary evil,
> considering the need to have a bijective mapping between the two
> namespaces.
>
I understand the need for a bijective encoding, but my eyes are not so good at
decoding on the fly, and it produces very long names (especially with archive
names included) making hard to display metrics afterwards.
> > [...]
> > Moreover pcp metric definition are more comprehensive than graphite can cope
> > with, and I'm feeling like we are not making the most out of the collected
> > metrics.
>
> Sorry, I'm not sure what you mean. Maybe just that the graphite
> information is lossy, like no events / strings / metadata being
> propagated from PCP? That's true, but somewhat implicit in the use of
> graphite web interfaces. (We could do more with graphite "events"
> though.)
I meant that indeed, units, discrete / counter / instant semantic, metric label
are not fully propagated to graphite.
Maybe a dashbord builder to generate json for grafana could take care of this
and display metric units in the legend.
> > What solutions are used by seasoned PCP users to visualize
> > realtime/historical
> > metrics, for
> >
> > 1. dashboards used on a daily basis,
>
> Within the pcp web-ui space, one way is to assemble dashboards in
> interactively in grafana, save them to .json files, then arrange to
> serve those from pmwebd (see grafana/app/dashboards/FOO.json). Heck,
> we'd be happy to include yours in the pcp-webjs packages if they are
> applicable generally.
That is clear. I tried that approach, but found that the perf penalty + name
mangling make it pretty painful to use pcp.
Besides, most of graphite's server side computation functions do not seem
supported.
I thought about using a brokered approach with
https://github.com/brutasse/graphite-api to implement graphite-api and delegate
actual data fetching to a either a raw finder based on pcpapi or a rest finder
calling pmwebapi.
This could also provide a mean to provide an easier way to customize name
mapping.
I'll keep you posted if I find time to do that.
> > 2. deep-dive solution to investigate / correlate events when a given
> > production issue arises
>
> That's such a big area. I think the clinching technical complication
> there is PCP's limitations in logging being governed by a static
> configuration: a set of metrics and a fixed polling interval. When a
> production issue arises, someone would have to notice, and reconfigure
> a pmlogger instance to do more logging, and/or eyeball extra live data
> interactively. It would be better if pmlogger could react dynamically.
>
>
> - FChE
___________________________________
The integrity of this message cannot be guaranteed on the internet. Therefore
EXANE cannot be considered responsible for the contents.
If you are not the intended recipient of this message, please delete it and
notify the sender.
This message is provided for information purposes only and should not be
construed as a solicitation or offer to buy or sell any securities or related
financial instruments.
Although it may contain some elements from publications produced by Exane's
research department, this message is not research.
Please consult our web site for important disclaimers and disclosures
concerning Exane's research. (http://www.exane.com)
___________________________________
|