Menu
▾
▴
devmon-support
|
From: Tom G. <to...@mc...> - 2007-03-22 16:56:10
|
Hi, I'm new to devmon but not to Hobbit. I was wondering if anyone on the list had templates or starting creating templates for IBM bladecenters and HP c-class bladesystems. If so, would you mind sharing them or want to collaborate on creating or improving one? Thanks, Tom -- Tom Georgoulias Systems Engineer McClatchy Interactive to...@mc... |
|
From: Gildas Le N. <gn...@sa...> - 2007-03-26 15:52:58
Attachments:
devmon_template_ibm_bladecenter.tgz
|
Hi Those are the template for the bladecenter (not the bladecenter H or T though they may be compatible) I started making. Hopefully they may be usable as is or be a starting base. <legal>They are "copyright 2006-2007 Genome Research Limited / Gildas Le Nadan" and released under the GPL </legal> HTH Tom Georgoulias wrote: > Hi, > > I'm new to devmon but not to Hobbit. I was wondering if anyone on the > list had templates or starting creating templates for IBM bladecenters > and HP c-class bladesystems. If so, would you mind sharing them or want > to collaborate on creating or improving one? > > Thanks, > Tom |
|
From: Tom G. <to...@mc...> - 2007-03-29 19:19:53
|
Gildas Le Nadan wrote: > Those are the template for the bladecenter (not the bladecenter H or T > though they may be compatible) I started making. > > Hopefully they may be usable as is or be a starting base. Thank you for the templates. They work as is, and I'm starting to experiment with them. -- Tom Georgoulias Systems Engineer McClatchy Interactive to...@mc... |
|
From: Tom G. <to...@mc...> - 2007-03-29 20:40:40
|
Tom Georgoulias wrote:
>> Those are the template for the bladecenter (not the bladecenter H or T
>> though they may be compatible) I started making.
>>
>> Hopefully they may be usable as is or be a starting base.
>
> Thank you for the templates. They work as is, and I'm starting to
> experiment with them.
Guess I spoke too soon, all of the bladecenters are showing red alerts
for the "power" test, even though they report that they OK. Here's an
example of the red power status:
Power Modules
-------------
Alarming on (1,2)
1 red 1 - Power domain status is good. Bay 1: 1875W Bay 2: 1875W
2 red 1 - Power domain status is good. Bay 3: 1875W Bay 4: 1875W
Looking at the templates for power, I see that the threshold for a red
alert is "3", but I'm not sure why the test is showing up as red when
the value returned for fuelGaugeStatus is 1 (or at least I think it is
returning 1.)
from thresholds template:
fuelGaugeStatusNumeric : red : =3 : Fuel Gauge status is
{fuelGaugeStatus}
fuelGaugeStatusNumeric : yellow: =2 : Fuel Gauge status is
{fuelGaugeStatus}
Doing a snmpget of the bladecenter, I get an error when I query the OID
.1.3.6.1.4.1.2.3.51.2.2.10.1.1.1.3 (as listed in the OID template), but
not when I query 1.3.6.1.4.1.2.3.51.2.2.10.1.1.1.3.1 and
1.3.6.1.4.1.2.3.51.2.2.10.1.1.1.3.2. (Note the addition of .1 and .2 at
the end of the OID).
Output from snmpwalk:
"1 - Power domain status is good."
That 1 is the value for fuelGaugeStatus, right? The transform template
replaces " with 1, right?
What am I missing or doing wrong? Any help is appreciated.
--
Tom Georgoulias
Systems Engineer
McClatchy Interactive
to...@mc...
|
|
From: Gildas Le N. <gn...@sa...> - 2007-03-30 10:21:16
|
Tom Georgoulias wrote:
> Tom Georgoulias wrote:
>
>
>>>Those are the template for the bladecenter (not the bladecenter H or T
>>>though they may be compatible) I started making.
>>>
>>>Hopefully they may be usable as is or be a starting base.
>>
>>Thank you for the templates. They work as is, and I'm starting to
>>experiment with them.
>
>
> Guess I spoke too soon, all of the bladecenters are showing red alerts
> for the "power" test, even though they report that they OK. Here's an
> example of the red power status:
Hum strange, I have no idea why it's not working for you as it was for
me. I used it with devmon v0.2.2 and this used to work for me ;)
> Power Modules
> -------------
> Alarming on (1,2)
> 1 red 1 - Power domain status is good. Bay 1: 1875W Bay 2: 1875W
> 2 red 1 - Power domain status is good. Bay 3: 1875W Bay 4: 1875W
>
> Looking at the templates for power, I see that the threshold for a red
> alert is "3", but I'm not sure why the test is showing up as red when
> the value returned for fuelGaugeStatus is 1 (or at least I think it is
> returning 1.)
>
> from thresholds template:
>
> fuelGaugeStatusNumeric : red : =3 : Fuel Gauge status is
> {fuelGaugeStatus}
> fuelGaugeStatusNumeric : yellow: =2 : Fuel Gauge status is
> {fuelGaugeStatus}
>
> Doing a snmpget of the bladecenter, I get an error when I query the OID
> .1.3.6.1.4.1.2.3.51.2.2.10.1.1.1.3 (as listed in the OID template), but
Yes, it's not a leaf and afaik it has no property and cannot be queried
but just "walked"
> not when I query 1.3.6.1.4.1.2.3.51.2.2.10.1.1.1.3.1 and
> 1.3.6.1.4.1.2.3.51.2.2.10.1.1.1.3.2. (Note the addition of .1 and .2 at
> the end of the OID).
>
> Output from snmpwalk:
>
> "1 - Power domain status is good."
>
> That 1 is the value for fuelGaugeStatus, right? The transform template
> replaces " with 1, right?
>
> What am I missing or doing wrong? Any help is appreciated.
Yes I think you got it.
Just in case, let me explain what it is supposed to do: fuel gauge
status is given as a string an not as a numeric value so I had to
transform it into a numeric value to be able to set thresholds.
In oids:
fuelGaugeStatus : .1.3.6.1.4.1.2.3.51.2.2.10.1.1.1.3 : branch
-> I retrieve all the leaves attached to this oid under the name
fuelGaugeStatus
In transform:
fuelGaugeStatusNumeric : SUBSTR : {fuelGaugeStatus} 0 1
-> Get the first char and assign it to fuelGaugeStatusNumeric (see
docs/TEMPLATES for documentation on SUBSTR)
Assuming that the SUBSTR is working as intended, what you may try to do
is to add the following in thresholds:
fuelGaugeStatusNumeric : green: =1 : Fuel Gauge status is
{fuelGaugeStatus}
That should force the green status.
A way to test if fuelGaugeStatusNumeric is what we thinks it is is to
display it:
--- templates/bladecenter/power/message.orig 2006-11-24
14:33:12.000000000 +0000
+++ templates/bladecenter/power/message 2007-03-30 11:19:26.985628680 +0100
@@ -1,8 +1,8 @@
Power Modules
-------------
TABLE:
- #|Status|1st Power Module|2nd Power Module
-{fuelGaugeIndex}|{fuelGaugeStatusNumeric.color}
{fuelGaugeStatus}|{fuelGaugeFirstPowerModule}|{fuelGaugeSecondPowerModule}
+ #|Status|1st Power Module|2nd Power Module|Fuel Gauge numeric status
+{fuelGaugeIndex}|{fuelGaugeStatusNumeric.color}
{fuelGaugeStatus}|{fuelGaugeFirstPowerModule}|{fuelGaugeSecondPowerModule}|{fuelGaugeStatusNumeric}
Power Domain 1
--------------
HTH
I am interested in any change you make ;)
Cheers
Gildas
|
|
From: Tom G. <to...@mc...> - 2007-03-30 13:10:15
|
Gildas Le Nadan wrote:
> Just in case, let me explain what it is supposed to do: fuel gauge
> status is given as a string an not as a numeric value so I had to
> transform it into a numeric value to be able to set thresholds.
>
> In oids:
> fuelGaugeStatus : .1.3.6.1.4.1.2.3.51.2.2.10.1.1.1.3 : branch
> -> I retrieve all the leaves attached to this oid under the name
> fuelGaugeStatus
>
> In transform:
> fuelGaugeStatusNumeric : SUBSTR : {fuelGaugeStatus} 0 1
> -> Get the first char and assign it to fuelGaugeStatusNumeric (see
> docs/TEMPLATES for documentation on SUBSTR)
>
> Assuming that the SUBSTR is working as intended, what you may try to do
> is to add the following in thresholds:
>
> fuelGaugeStatusNumeric : green: =1 : Fuel Gauge status is
> {fuelGaugeStatus}
>
> That should force the green status.
I tried this before posting yesterday and it didn't work.
> A way to test if fuelGaugeStatusNumeric is what we thinks it is is to
> display it:
Forcing the display of the fuelGaugeStatusNumericvalue shows a "1", as
shown by the poorly lined wrapped table below. (Note, I changed some of
the titles in that table)
Power Modules
-------------
Alarming on (1,2)
Domain Power Domain Status 1st Power Module 2nd Power Module Devmon
gauge value
1 red 1 - Power domain status is good. Bay 1: 1875W Bay 2: 1875W 1
2 red 1 - Power domain status is good. Bay 3: 1875W Bay 4: 1875W 1
Running devmon in debug mode and sending the output to the console, I
get the impression that the test is red because it is skipped all
together, possibly because the snmp returns 2 values and the transform
is setup to deal with only 1 value?
[07-03-30@09:03:29] Entering poll loop
[07-03-30@09:03:29] SUBSTR transform uses only a single oid, a numeric
offset and an optional shift value at
/home/hobbit/server/ext/devmon/templates/bladecenter/power/transforms,
line 1
[07-03-30@09:03:29] Undefined oid 'fuelGaugeStatusNumeric' referenced in
/home/hobbit/server/ext/devmon/templates/bladecenter/power/thresholds at
line 3
[07-03-30@09:03:29] Undefined oid 'fuelGaugeStatusNumeric' referenced in
/home/hobbit/server/ext/devmon/templates/bladecenter/power/thresholds at
line 3
[07-03-30@09:03:29] Undefined oid 'fuelGaugeStatusNumeric' referenced in
/home/hobbit/server/ext/devmon/templates/bladecenter/power/thresholds at
line 3
[07-03-30@09:03:29] Undefined oid 'fuelGaugeStatusNumeric' at line 17 of
/home/hobbit/server/ext/devmon/templates/bladecenter/power/message,
skipping this test.
> I am interested in any change you make ;)
I will be glad to share them.
--
Tom Georgoulias
Systems Engineer
McClatchy Interactive
to...@mc...
|
|
From: Gildas Le N. <gn...@sa...> - 2007-03-30 13:16:18
|
>>A way to test if fuelGaugeStatusNumeric is what we thinks it is is to >>display it: > > > Forcing the display of the fuelGaugeStatusNumericvalue shows a "1", as > shown by the poorly lined wrapped table below. (Note, I changed some of > the titles in that table) > > Power Modules > ------------- > Alarming on (1,2) > Domain Power Domain Status 1st Power Module 2nd Power Module Devmon > gauge value > 1 red 1 - Power domain status is good. Bay 1: 1875W Bay 2: 1875W 1 > 2 red 1 - Power domain status is good. Bay 3: 1875W Bay 4: 1875W 1 > > Running devmon in debug mode and sending the output to the console, I > get the impression that the test is red because it is skipped all > together, possibly because the snmp returns 2 values and the transform > is setup to deal with only 1 value? > > [07-03-30@09:03:29] Entering poll loop > [07-03-30@09:03:29] SUBSTR transform uses only a single oid, a numeric > offset and an optional shift value at > /home/hobbit/server/ext/devmon/templates/bladecenter/power/transforms, > line 1 > [07-03-30@09:03:29] Undefined oid 'fuelGaugeStatusNumeric' referenced in > /home/hobbit/server/ext/devmon/templates/bladecenter/power/thresholds at > line 3 > [07-03-30@09:03:29] Undefined oid 'fuelGaugeStatusNumeric' referenced in > /home/hobbit/server/ext/devmon/templates/bladecenter/power/thresholds at > line 3 > [07-03-30@09:03:29] Undefined oid 'fuelGaugeStatusNumeric' referenced in > /home/hobbit/server/ext/devmon/templates/bladecenter/power/thresholds at > line 3 > [07-03-30@09:03:29] Undefined oid 'fuelGaugeStatusNumeric' at line 17 of > /home/hobbit/server/ext/devmon/templates/bladecenter/power/message, > skipping this test. Yeah I suspect you're right here. Strange it didn't seem to have the same behaviour for me on devmon v0.2.2 thought I also have 4 power modules per bladecenter chassis. Maybe I had the exact same case but the other way round (i-e it was always green)? Which devmon version are you using? Cheers Gildas |
|
From: Tom G. <to...@mc...> - 2007-03-30 13:37:18
|
Gildas Le Nadan wrote: >>> A way to test if fuelGaugeStatusNumeric is what we thinks it is is to >>> display it: >> >> Forcing the display of the fuelGaugeStatusNumericvalue shows a "1", as >> shown by the poorly lined wrapped table below. (Note, I changed some of >> the titles in that table) >> >> Power Modules >> ------------- >> Alarming on (1,2) >> Domain Power Domain Status 1st Power Module 2nd Power Module Devmon >> gauge value >> 1 red 1 - Power domain status is good. Bay 1: 1875W Bay 2: 1875W 1 >> 2 red 1 - Power domain status is good. Bay 3: 1875W Bay 4: 1875W 1 >> >> Running devmon in debug mode and sending the output to the console, I >> get the impression that the test is red because it is skipped all >> together, possibly because the snmp returns 2 values and the transform >> is setup to deal with only 1 value? >> >> [07-03-30@09:03:29] Entering poll loop >> [07-03-30@09:03:29] SUBSTR transform uses only a single oid, a numeric >> offset and an optional shift value at >> /home/hobbit/server/ext/devmon/templates/bladecenter/power/transforms, >> line 1 >> [07-03-30@09:03:29] Undefined oid 'fuelGaugeStatusNumeric' referenced in >> /home/hobbit/server/ext/devmon/templates/bladecenter/power/thresholds at >> line 3 >> [07-03-30@09:03:29] Undefined oid 'fuelGaugeStatusNumeric' referenced in >> /home/hobbit/server/ext/devmon/templates/bladecenter/power/thresholds at >> line 3 >> [07-03-30@09:03:29] Undefined oid 'fuelGaugeStatusNumeric' referenced in >> /home/hobbit/server/ext/devmon/templates/bladecenter/power/thresholds at >> line 3 >> [07-03-30@09:03:29] Undefined oid 'fuelGaugeStatusNumeric' at line 17 of >> /home/hobbit/server/ext/devmon/templates/bladecenter/power/message, >> skipping this test. > > Yeah I suspect you're right here. Might be necessary to split it into 2 oids, along with what ever other bits are touched by this part of the tests. > Strange it didn't seem to have the same behaviour for me on devmon > v0.2.2 thought I also have 4 power modules per bladecenter chassis. > Maybe I had the exact same case but the other way round (i-e it was > always green)? Probably so. > Which devmon version are you using? 0.3. -- Tom Georgoulias Systems Engineer McClatchy Interactive to...@mc... |
|
From: Gildas Le N. <gn...@sa...> - 2007-03-30 13:41:47
|
>>Which devmon version are you using? > 0.3. Eric, is there a difference in the way SUBSTR works between 0.2.2 and 0.3? |
|
From: Schwimmer, E. E *H. <EE...@hs...> - 2007-03-30 13:48:49
|
Not an intentional difference :) I don't use substr in any of my templates though, so I might have broken something the last time I revamped all the translation routines. I'll take a look. e > -----Original Message----- > From: dev...@li... [mailto:devmon-support- > bo...@li...] On Behalf Of Gildas Le Nadan > Sent: Friday, March 30, 2007 9:42 AM > To: dev...@li... > Subject: Re: [Devmon] templates for IBM & HP bladecenter/bladesystems >=20 > >>Which devmon version are you using? > > 0.3. >=20 > Eric, is there a difference in the way SUBSTR works between 0.2.2 and 0.3? >=20 > ------------------------------------------------------------------------ - > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDE V > _______________________________________________ > Devmon-support mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devmon-support |
|
From: Gildas Le N. <gn...@sa...> - 2007-03-30 13:54:00
|
Schwimmer, Eric E *HS wrote: > Not an intentional difference :) I don't use substr in any of my > templates though, so I might have broken something the last time I > revamped all the translation routines. I'll take a look. > > e thx, I suspect it'll go quicker if you check instead of me ;) Cheers G. |
|
From: Schwimmer, E. E *H. <EE...@hs...> - 2007-03-30 14:54:42
Attachments:
devmon-0.3_substr.patch
|
Hrm. It looks like this error is coming from the template parsing code, which I don't *think* I changed. However, I think I might know what is causing it (extra whitespace on the end of the transform line). Try the attached patch (which also fixes a bug I found in the substr transform when not using a length value), and let me know if that helps. I'll update the sourceforge tarball in a few moments with this patch. e > -----Original Message----- > From: dev...@li... [mailto:devmon-support- > bo...@li...] On Behalf Of Gildas Le Nadan > Sent: Friday, March 30, 2007 9:54 AM > To: dev...@li... > Subject: Re: [Devmon] templates for IBM & HP bladecenter/bladesystems >=20 > Schwimmer, Eric E *HS wrote: > > Not an intentional difference :) I don't use substr in any of my > > templates though, so I might have broken something the last time I > > revamped all the translation routines. I'll take a look. > > > > e >=20 > thx, I suspect it'll go quicker if you check instead of me ;) >=20 > Cheers > G. >=20 > ------------------------------------------------------------------------ - > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDE V > _______________________________________________ > Devmon-support mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devmon-support |
|
From: Tom G. <to...@mc...> - 2007-03-30 19:21:53
|
Schwimmer, Eric E *HS wrote: > Hrm. It looks like this error is coming from the template parsing code, > which I don't *think* I changed. However, I think I might know what is > causing it (extra whitespace on the end of the transform line). Try the > attached patch (which also fixes a bug I found in the substr transform > when not using a length value), and let me know if that helps. I applied the patch and I am getting a different error than the one I posted before. Running "devmon --debug -f" produces this: [07-03-30@15:19:26] DEBUG: Doing substr transform on iadm200.nandomedia.com/fuelGaugeStatusNumeric Use of uninitialized value in numeric gt (>) at /home/hobbit/server/ext/devmon/modules/dm_tests.pm line 2300, <$__ANONIO__> line 163. Use of uninitialized value in numeric gt (>) at /home/hobbit/server/ext/devmon/modules/dm_tests.pm line 2300, <$__ANONIO__> line 163. Use of uninitialized value in numeric gt (>) at /home/hobbit/server/ext/devmon/modules/dm_tests.pm line 2300, <$__ANONIO__> line 163. -- Tom Georgoulias Systems Engineer McClatchy Interactive to...@mc... |
|
From: Schwimmer, E. E *H. <EE...@hs...> - 2007-03-30 20:27:46
|
That's odd. It looks like the parent OID (fuelGaugeStatus) is undefined, but the should be caught (and subsequently turned into an error) by the validate_deps subroutine. I haven't testing the SUBSTR transforms on a repeater-type OID yet, I'll try that and see if I can reproduce the error. e > -----Original Message----- > From: dev...@li... [mailto:devmon-support- > bo...@li...] On Behalf Of Tom Georgoulias > Sent: Friday, March 30, 2007 3:25 PM > To: dev...@li... > Subject: Re: [Devmon] templates for IBM & HP bladecenter/bladesystems >=20 > Schwimmer, Eric E *HS wrote: > > Hrm. It looks like this error is coming from the template parsing code, > > which I don't *think* I changed. However, I think I might know what is > > causing it (extra whitespace on the end of the transform line). Try the > > attached patch (which also fixes a bug I found in the substr transform > > when not using a length value), and let me know if that helps. >=20 > I applied the patch and I am getting a different error than the one I > posted before. Running "devmon --debug -f" produces this: >=20 > [07-03-30@15:19:26] DEBUG: Doing substr transform on > iadm200.nandomedia.com/fuelGaugeStatusNumeric > Use of uninitialized value in numeric gt (>) at > /home/hobbit/server/ext/devmon/modules/dm_tests.pm line 2300, > <$__ANONIO__> line 163. > Use of uninitialized value in numeric gt (>) at > /home/hobbit/server/ext/devmon/modules/dm_tests.pm line 2300, > <$__ANONIO__> line 163. > Use of uninitialized value in numeric gt (>) at > /home/hobbit/server/ext/devmon/modules/dm_tests.pm line 2300, > <$__ANONIO__> line 163. > -- > Tom Georgoulias > Systems Engineer > McClatchy Interactive > to...@mc... >=20 > ------------------------------------------------------------------------ - > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share > your > opinions on IT & business topics through brief surveys-and earn cash > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDE V > _______________________________________________ > Devmon-support mailing list > Dev...@li... > https://lists.sourceforge.net/lists/listinfo/devmon-support |
|
From: Tom G. <to...@mc...> - 2007-04-02 15:41:24
|
Gildas Le Nadan wrote:
>>>> Those are the template for the bladecenter (not the bladecenter H or T
>>>> though they may be compatible) I started making.
> I am interested in any change you make ;)
Here are two changes I made this morning, which enabled me to have
graphs of the blower fan speeds and temperature readings. Not sure if
it would be useful for your situation, but trend charts are very
important to me and I like to have as many of them as I can. I had to
shuffle the way that the messages are sent to the hobbit server for
blowers and temp to make sure the NCV module worked properly. Patches
are just applied to each message file in each template
(bladecenter/blowers/message and bladecenter/temp/message).
In addition to the patches, you need to make some changes on your Hobbit
server configs, then restart hobbit.
Add these lines to hobbitserver.cfg:
NCV_temp="*:GAUGE"
NCV_blowers="*:GAUGE"
Add these
"temp=ncv,blowers=ncv"
to TEST2RRD in hobbitserver.cfg
and
"temp,blowers"
to GRAPHS in hobbitserver.cfg.
Add these definitions to hobbitgraph.cfg:
[blowers]
TITLE Bladecenter Fan Speeds
YAXIS %
DEF:b1=blowers.rrd:blower1:AVERAGE
DEF:b2=blowers.rrd:blower2:AVERAGE
LINE2:b1#FF0000:Blower 1
-u 100
-l 0
GPRINT:b1:LAST: \: %5.0lf (cur)
GPRINT:b1:MAX: \: %5.0lf (max)
GPRINT:b1:MIN: \: %5.0lf (min)
GPRINT:b1:AVERAGE: \: %5.0lf (avg)\\n
LINE2:b2#0000FF:Blower 2
-u 100
-l 0
GPRINT:b2:LAST: \: %5.0lf (cur)
GPRINT:b2:MAX: \: %5.0lf (max)
GPRINT:b2:MIN: \: %5.0lf (min)
GPRINT:b2:AVERAGE: \: %5.0lf (avg)\\n
[temp]
TITLE Bladecenter Temperatures
YAXIS Celsius
DEF:mm=temp.rrd:mgmtmodule:AVERAGE
DEF:a=temp.rrd:ambient:AVERAGE
LINE2:mm#FF0000:Mgmt Module
GPRINT:mm:LAST: \: %5.0lf (cur)
GPRINT:mm:MAX: \: %5.0lf (max)
GPRINT:mm:MIN: \: %5.0lf (min)
GPRINT:mm:AVERAGE: \: %5.0lf (avg)\\n
LINE2:a#0000FF:Ambient
GPRINT:a:LAST: \: %5.0lf (cur)
GPRINT:a:MAX: \: %5.0lf (max)
GPRINT:a:MIN: \: %5.0lf (min)
GPRINT:a:AVERAGE: \: %5.0lf (avg)\\n
--
Tom Georgoulias
Systems Engineer
McClatchy Interactive
to...@mc...
|
|
From: Tom G. <to...@mc...> - 2007-04-02 15:43:14
Attachments:
blowers-message.patch
temp-message.patch
|
Gildas Le Nadan wrote:
>>>> Those are the template for the bladecenter (not the bladecenter H or T
>>>> though they may be compatible) I started making.
> I am interested in any change you make ;)
(resend with the patches.)
Here are two changes I made this morning, which enabled me to have
graphs of the blower fan speeds and temperature readings. Not sure if
it would be useful for your situation, but trend charts are very
important to me and I like to have as many of them as I can. I had to
shuffle the way that the messages are sent to the hobbit server for
blowers and temp to make sure the NCV module worked properly. Patches
are just applied to each message file in each template
(bladecenter/blowers/message and bladecenter/temp/message).
In addition to the patches, you need to make some changes on your Hobbit
server configs, then restart hobbit.
Add these lines to hobbitserver.cfg:
NCV_temp="*:GAUGE"
NCV_blowers="*:GAUGE"
Add these
"temp=ncv,blowers=ncv"
to TEST2RRD in hobbitserver.cfg
and
"temp,blowers"
to GRAPHS in hobbitserver.cfg.
Add these definitions to hobbitgraph.cfg:
[blowers]
TITLE Bladecenter Fan Speeds
YAXIS %
DEF:b1=blowers.rrd:blower1:AVERAGE
DEF:b2=blowers.rrd:blower2:AVERAGE
LINE2:b1#FF0000:Blower 1
-u 100
-l 0
GPRINT:b1:LAST: \: %5.0lf (cur)
GPRINT:b1:MAX: \: %5.0lf (max)
GPRINT:b1:MIN: \: %5.0lf (min)
GPRINT:b1:AVERAGE: \: %5.0lf (avg)\\n
LINE2:b2#0000FF:Blower 2
-u 100
-l 0
GPRINT:b2:LAST: \: %5.0lf (cur)
GPRINT:b2:MAX: \: %5.0lf (max)
GPRINT:b2:MIN: \: %5.0lf (min)
GPRINT:b2:AVERAGE: \: %5.0lf (avg)\\n
[temp]
TITLE Bladecenter Temperatures
YAXIS Celsius
DEF:mm=temp.rrd:mgmtmodule:AVERAGE
DEF:a=temp.rrd:ambient:AVERAGE
LINE2:mm#FF0000:Mgmt Module
GPRINT:mm:LAST: \: %5.0lf (cur)
GPRINT:mm:MAX: \: %5.0lf (max)
GPRINT:mm:MIN: \: %5.0lf (min)
GPRINT:mm:AVERAGE: \: %5.0lf (avg)\\n
LINE2:a#0000FF:Ambient
GPRINT:a:LAST: \: %5.0lf (cur)
GPRINT:a:MAX: \: %5.0lf (max)
GPRINT:a:MIN: \: %5.0lf (min)
GPRINT:a:AVERAGE: \: %5.0lf (avg)\\n
--
Tom Georgoulias
Systems Engineer
McClatchy Interactive
to...@mc...
|
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X