[wishlist] Better support of the @@ tag in NCV trends
Hi all, In do_ncv.c, I see this : 42: while (l && *l && strncmp(l, "@@\n", 3)) { If I understand correctly, that means the program will stop processing the status file if it encounter a "@@\n" line. Well, I tried and it seems to work that way (I have a status showing something like two counters followed by a bunch of SNMP values that I don't want to graph). It do not seem to be documented. Now the real cool thing would be to have start tag, so NCV values could be added last instead of first. (because humans like nice status reports and computer don't care to take the last bits). When the program hits the start tag, it forgets whatever it got and starts over. For people interrested, the status show this way : Thu Jun 29 18:41:21 CEST 2006 - 3623995988 incoming reqs - 845313333 outgoing reqs inreqs: 3623995988 outreqs: 845313333 @@ wwwServiceDescription.1 = CacheFlow 700/4.x.xxxx wwwServiceContact.1 = xxxxxxxxx at yyy.zz wwwServiceProtocol.1 = mgmt.xx.x.xx wwwServiceName.1 = myhostname wwwServiceType.1 = wwwCachingProxy (...) wwwSummaryInRequests.1 = 3624092091 wwwSummaryOutRequests.1 = 845335728 only the two first lines get a graph line. (the blank line before the @@ seems to be mandatory too) -- Charles
If this in fact is implemented, it might be nice if the start and end tags and the stuff in the middle isn't actually displayed. Or perhaps if displaying them was an option. Charles Goyard wrote:
Hi all,
In do_ncv.c, I see this :
42: while (l && *l && strncmp(l, "@@\n", 3)) {
If I understand correctly, that means the program will stop processing the status file if it encounter a "@@\n" line. Well, I tried and it seems to work that way (I have a status showing something like two counters followed by a bunch of SNMP values that I don't want to graph). It do not seem to be documented.
Now the real cool thing would be to have start tag, so NCV values could be added last instead of first. (because humans like nice status reports and computer don't care to take the last bits). When the program hits the start tag, it forgets whatever it got and starts over.
For people interrested, the status show this way :
Thu Jun 29 18:41:21 CEST 2006 - 3623995988 incoming reqs - 845313333 outgoing reqs
inreqs: 3623995988 outreqs: 845313333
@@
wwwServiceDescription.1 = CacheFlow 700/4.x.xxxx wwwServiceContact.1 = xxxxxxxxx at yyy.zz wwwServiceProtocol.1 = mgmt.xx.x.xx wwwServiceName.1 = myhostname wwwServiceType.1 = wwwCachingProxy (...) wwwSummaryInRequests.1 = 3624092091 wwwSummaryOutRequests.1 = 845335728
only the two first lines get a graph line. (the blank line before the @@ seems to be mandatory too)
-- Rich Smrcina VM Assist, Inc. Main: (262)392-2026 Cell: (414)491-6001 Ans Service: (360)715-2467 rich.smrcina at vmassist.com Catch the WAVV! http://www.wavv.org WAVV 2007 - Green Bay, WI - May 18-22, 2007
Can you add to the installer a quick little thing, that will save anyone trying to use scripts from deadcat.net a bit of a headache?
Just add a
ln -s hobbitclient.cfg bbdef.sh
In the xxx/etc directory?
Maybe?
Thought since so much more of Hobbit was built with backward compatibilty that this would be a nice touch.
Dave Overton, Owner SYIX.COM
dave at syix.com (530) 755-1751 x101 Fax (530) 751-8871 800-988-SYIX
On Thu, Jun 29, 2006 at 10:27:44AM -0700, Dave Overton wrote:
Can you add to the installer a quick little thing, that will save anyone trying to use scripts from deadcat.net a bit of a headache?
Just add a
ln -s hobbitclient.cfg bbdef.sh
In the xxx/etc directory?
Maybe?
In most cases it shouldn't be needed. The common construct I've seen in BB extension scripts goes like
if test "$BBTMP" = "" then . $BBHOME/etc/bbdef.sh fi
and since BBTMP (and the other BB* environment variables) have already been set when script are run via hobbitlaunch.cfg, it should never try to load the bbdef.sh file.
Thought since so much more of Hobbit was built with backward compatibilty that this would be a nice touch.
Source'ing the hobbitclient.cfg file has never been guaranteed to work in a shell script, so I really wouldn't encourage doing that. I could create an empty bbdef.sh file just so that script wouldn't complain.
Regards, henrik
In most cases it shouldn't be needed. The common construct I've seen in BB extension scripts goes like
if test "$BBTMP" = "" then . $BBHOME/etc/bbdef.sh fi
and since BBTMP (and the other BB* environment variables)
A quick random check on Deadcat, I see just this:
if test ! "${BBTMP}" # GET DEFINITIONS IF NEEDED then # echo "*** LOADING BBDEF ***" . ${BBHOME}/etc/bbdef.sh # INCLUDE STANDARD DEFINITIONS Fi
Always loading "bbdef.sh" seems to be the norm, perhaps I just pick the wrong scripts. The empty bbdef.sh would do the trick too though. Either way is good for me, I know how to fix it, just was thinking of future users, some bb extensions just don't "work" out of the box as I am sure you originally intended.
On Thu, Jun 29, 2006 at 06:51:40PM +0200, Charles Goyard wrote:
In do_ncv.c, I see this :
42: while (l && *l && strncmp(l, "@@\n", 3)) {
If I understand correctly, that means the program will stop processing the status file if it encounter a "@@\n" line. Well, I tried and it seems to work that way (I have a status showing something like two counters followed by a bunch of SNMP values that I don't want to graph). It do not seem to be documented.
There's a reason why it isn't documented: You shouldn't use it. The "@@<newline>" marker is actually used for something completely different, and embedding it into your data stream is generally not a good idea. In fact, I'd expect some complaints in your log files as a result of this. Hobbit 4.2 has a different solution to your problem. You can setup exactly which values you want to graph, e.g. in your case it would be NCV_something="inreqs:COUNTER,outreqs:COUNTER,*:NONE" and it would track only those two values. Regards, Henrik
Henrik Stoerner a écrit :
There's a reason why it isn't documented: You shouldn't use it.
Just what I was thinking :). Thanks, Henrik.
The "@@<newline>" marker is actually used for something completely different, and embedding it into your data stream is generally not a good idea. In fact, I'd expect some complaints in your log files as a result of this.
Something like "Task rrdstatus terminated, status 1"... Fun thing, the graphs have holes in them. I'll switch to 4.2 earlier than planned, then. I hope it will be released soon. Just to satisfy my curiosity, what's the purpose of "@@\n" ? -- Charles
participants (4)
-
cgoyard＠cvf.fr
-
dave＠syix.com
-
henrik＠hswn.dk
-
rsmrcina＠wi.rr.com