More about linecount
Well, now I know how linecount works. I was hoping that it would let me track the number of lines in a file and spot changes over time. But this is not what line count is for -- it is intended to match some arbitrary subset of lines in a file, and then this is tracked via RRD as a "derived" value, meaning what is graphed is how the count changes over time, scaled into units per second. This is perfect if you want to watch the rate of login failures on your system, but not very useful for what I wanted.
So I will monitor changes in file size (which might show me changes), but cannot readily translate this into a line count.
So, an enhancement request -- add a "line count" as a file parameter, in addition to all the normal things that are available now?
GLH
Greg,
On Fri, 25 Aug 2006, Hubbard, Greg L wrote:
Well, now I know how linecount works. I was hoping that it would let me track the number of lines in a file and spot changes over time. But this is not what line count is for -- it is intended to match some arbitrary subset of lines in a file, and then this is tracked via RRD as a "derived" value, meaning what is graphed is how the count changes over time, scaled into units per second. This is perfect if you want to watch the rate of login failures on your system, but not very useful for what I wanted.
So I will monitor changes in file size (which might show me changes), but cannot readily translate this into a line count.
So, an enhancement request -- add a "line count" as a file parameter, in addition to all the normal things that are available now?
If I'm remembering correctly what Henrik said about how linecount works (sorry, didn't keep the message), can't you do something like
totallines:.*
to make the pattern match every line of the file?
HTH, Richard
Replying to myself ...
On Fri, 25 Aug 2006, Richard.Hall wrote:
Greg,
On Fri, 25 Aug 2006, Hubbard, Greg L wrote:
Well, now I know how linecount works. I was hoping that it would let me track the number of lines in a file and spot changes over time. But this is not what line count is for -- it is intended to match some arbitrary subset of lines in a file, and then this is tracked via RRD as a "derived" value, meaning what is graphed is how the count changes over time, scaled into units per second. This is perfect if you want to watch the rate of login failures on your system, but not very useful for what I wanted.
So I will monitor changes in file size (which might show me changes), but cannot readily translate this into a line count.
So, an enhancement request -- add a "line count" as a file parameter, in addition to all the normal things that are available now?
If I'm remembering correctly what Henrik said about how linecount works (sorry, didn't keep the message), can't you do something like
totallines:.*
to make the pattern match every line of the file?
Doh! Obviously not - you want the total, not the rate of change. Apologies for the noise.
Richard
Yep, the problem is really in how the RRD is set up. I have some custom scripts that simply "wc -l" some files and these go into an RRD as a gauge...I thought this function might let me get out from under all the custom moving parts, but no luck in this release.
But I also use "DERIVED" counts to see what my incoming syslog and trap rates are -- so the linecount function could replace these custom scripts, except that the way I have it now these items get their own status dot and a nicely labeled graph. The new linecount graphs are buried in the "trends" stack so you have to know to go look for them there.
Lest I sound too much like a whiner -- I really like where Henrik is taking us all with each new Hobbit release!
GLH
-----Original Message----- From: Richard.Hall [mailto:Richard.Hall at ingenta.com] Sent: Friday, August 25, 2006 12:22 PM To: hobbit at hswn.dk Subject: Re: [hobbit] More about linecount
Replying to myself ...
On Fri, 25 Aug 2006, Richard.Hall wrote:
Greg,
On Fri, 25 Aug 2006, Hubbard, Greg L wrote:
Well, now I know how linecount works. I was hoping that it would let me track the number of lines in a file and spot changes over time. But this is not what line count is for -- it is intended to match some arbitrary subset of lines in a file, and then this is tracked via RRD as a "derived" value, meaning what is graphed is how
the count changes over time, scaled into units per second. This is perfect if you want to watch the rate of login failures on your system, but not very useful for what I wanted.
So I will monitor changes in file size (which might show me changes), but cannot readily translate this into a line count.
So, an enhancement request -- add a "line count" as a file parameter, in addition to all the normal things that are available now?
If I'm remembering correctly what Henrik said about how linecount works (sorry, didn't keep the message), can't you do something like
totallines:.*
to make the pattern match every line of the file?
Doh! Obviously not - you want the total, not the rate of change. Apologies for the noise.
Richard
To unsubscribe from the hobbit list, send an e-mail to hobbit-unsubscribe at hswn.dk
On Fri, Aug 25, 2006 at 12:56:41PM -0500, Hubbard, Greg L wrote:
Yep, the problem is really in how the RRD is set up. I have some custom scripts that simply "wc -l" some files and these go into an RRD as a gauge...I thought this function might let me get out from under all the custom moving parts, but no luck in this release.
I figured that out from your previous mail - that you've been using a GAUGE RRD file, whereas the linecount function uses a DERIVE file.
In fact, since the GAUGE/DERIVE setting is only used when the RRD file is created, you could - as a workaround - create the RRD file by hand, and then just use the current linecount function to update it. That would work, I think.
But I also use "DERIVED" counts to see what my incoming syslog and trap rates are -- so the linecount function could replace these custom scripts, except that the way I have it now these items get their own status dot and a nicely labeled graph. The new linecount graphs are buried in the "trends" stack so you have to know to go look for them there.
Several nice ideas here; the ability to track absolute linecounts is reasonable, and having a way of configuring what graphs go on what status columns has been discussed before - it is definitely one of those things that really need improvement. And I think it would be a good idea to create status columns from any RRD data item that we have, which would solve your last point.
Lest I sound too much like a whiner -- I really like where Henrik is taking us all with each new Hobbit release!
Thanks, but it's a long journey. Each time we get a little closer, though.
Regards, Henrik
participants (3)
-
greg.hubbard＠eds.com
-
henrik＠hswn.dk
-
Richard.Hall＠ingenta.com