Hi -
> > [...] 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.
This will be improved shortly with brolley's "open directory as
archive" extensions in libpcp (git://oss.sgi.com/brolley/pcp.git
branch brolley/multi-archive). With that, code already in pmwebd will
arrange to drop the archive file name parts from the graphite metrics.
> > > [...]
> > > 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.
Yes. Or the server-side-png rendering code (used in the graphite /
graphlot / png-grafana modes) could add such metadata to the legend
imagery.
> [archiving json dashboards] I tried that approach, but found that
> the perf penalty + name mangling make it pretty painful to use pcp.
(Well, we hope to "ease his pain" over time.)
> Besides, most of graphite's server side computation functions do not
> seem supported.
Yes, see <http://oss.sgi.com/bugzilla/show_bug.cgi?id=1094>.
> 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. [...]
See also pcp2graphite.
- FChE
|