[gpfsug-discuss] Scale / Perfmon / Grafana - services running but no data

Oesterlin, Robert Robert.Oesterlin at nuance.com
Wed Jul 19 12:26:43 BST 2017


Getting this: python zimonGrafanaIntf.py –s < pmcollector host>

via system is a bit of a tricky process, since this process will abort unless the pmcollector is fully up. With a large database, I’ve seen it take 3-5 mins for pmcollector to fully initialize. I’m sure a simple ‘sleep and try again’ wrapper would take care of that. It’s on my lengthy to-do list!

On the CherryPy version - I run the bridge on my RH/Centos system with python 3.4 and used “pip install cherrypy” and it picked up the latest version. Seems to work just fine.

Bob Oesterlin
Sr Principal Storage Engineer, Nuance




From: <gpfsug-discuss-bounces at spectrumscale.org> on behalf of "Greg.Lehmann at csiro.au" <Greg.Lehmann at csiro.au>
Reply-To: gpfsug main discussion list <gpfsug-discuss at spectrumscale.org>
Date: Wednesday, July 19, 2017 at 2:54 AM
To: "gpfsug-discuss at spectrumscale.org" <gpfsug-discuss at spectrumscale.org>
Subject: [EXTERNAL] Re: [gpfsug-discuss] Scale / Perfmon / Grafana - services running but no data

I’m having a play with this now too. Has anybody coded a systemd unit to handle step 2b in the knowledge centre article – bridge creation on the gpfs side? It would save me a bit of effort.

I’m also wondering about the CherryPy version. It looks like this has been developed on SLES which has the newer version mentioned as a standard package and yet RHEL with an older version of CherryPy is perhaps more common as it seems to have the best support for features of GPFS, like object and block protocols. Maybe SLES is in favour now?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://gpfsug.org/pipermail/gpfsug-discuss_gpfsug.org/attachments/20170719/b6421062/attachment-0002.htm>


More information about the gpfsug-discuss mailing list