rrd network graphs on windows check
Hello,
Since january 2012 I continued the development of an alternative windows monitoring agent that is based on the Nagios client NSCient++
See the checkwin monitor in Xymonton or http://code.google.com/p/checkwin/
I would like to add some network statistics the same way as we have in the BBWin client.
I wrote the script that captures the inbound and outbound traffic values through the “netstat –e” command but I don’t know how I have to load it to the Xymon server.
In the source code I found the “do_ifstat.c” module In which I could find the code
/* IP Ibytes Obytes */
/* 192.168.0.1 1818 1802 */
static const char *ifstat_bbwin_exprs[] = {
"^([a-zA-Z0-9.:]+)\\s+([0-9]+)\\s+([0-9]+)"};
Can someone explain me to which xymon test I should post my ifstat info?
I see that the network graphics are only visible in the trends but I don’t find what is expected by xymon to generate the rrd files.
Best regards,
Bart
On 22 June 2013 00:04, B-Art Gillis <bacaselo at gmail.com> wrote:
Can someone explain me to which xymon test I should post my ifstat info?
Typically, ifstat numbers are sent in a "client" message in the [ifstat] section. Example here of an ifstat section:
http://www.xymon.com/xymon-cgi/svcstatus.sh?CLIENT=blixen.hswn.dk§ion=if...
It's for Linux, so the format is all wrong if you're trying to emulate BBWin. But gives you the idea.
J
Jeremy,
Thank you for your answer but I just saw on the graph that the values are converted to rrd data seem to come from the "do_netstat.c" module. I just want to graph the TCP/IP trafic using the Windows command "netstat -e". If I send my test page to the "netstat" test I see the following message in the rrd_status.log:
2013-06-20 22:34:28 Host 'server1' reports netstat for an unknown OS
I guess that I don't sent all required data to the Xymon server. Any idea of the requirements and the format?
At this moment I was sending the test in the format:
green ma 24/06/2013 22:56:58,51 [netstat] 192.168.17.1 144084269 41843593
The value that are available:
Interface Statistics
Received SentBytes 144681781 42531845 Unicast packets 184396 169026 Non-unicast packets 777 11827 Discards 0 0 Errors 0 0 Unknown protocols 0
On Sun, Jun 23, 2013 at 11:32 AM, Jeremy Laidman <jlaidman at rebel-it.com.au>wrote:
On 22 June 2013 00:04, B-Art Gillis <bacaselo at gmail.com> wrote:
Can someone explain me to which xymon test I should post my ifstat info?
Typically, ifstat numbers are sent in a "client" message in the [ifstat] section. Example here of an ifstat section:
http://www.xymon.com/xymon-cgi/svcstatus.sh?CLIENT=blixen.hswn.dk§ion=if...
It's for Linux, so the format is all wrong if you're trying to emulate BBWin. But gives you the idea.
J
On 25 June 2013 07:03, B-Art Gillis <bacaselo at gmail.com> wrote:
Thank you for your answer but I just saw on the graph that the values are converted to rrd data seem to come from the "do_netstat.c" module.
No, if you want interface statistics then you want ifstat parsed in do_ifstat.c. If you want protocol statistics (layer 3 and above such as TCP and UDP) then you would want a [netstat] section parsed in do_netstat.c. The message example you gave shows interface statistics.
Xymon expects the format to match ifstat_bbwin_exprs[] (defined in do_ifstat.c). This includes an IP address then the in and out byte count. The output of "netstat -e" does not provide an IP address, and it provides much more than just the bytes in and out. You'd have to select the Bytes line and prefix it with an IP address (probably a dummy device name would do also).
Something like:
EthDev 144681781 42531845
Any whitespace can be used as separators (one or more tabs or spaces).
You could probably get away with this:
echo [netstat] & netstat -e | find "Bytes"
This would give "Bytes" as a devicename, but I don't think it would break anything.
You need to prefix this message with the correct "client" message header. If you're sending other client data, this should be included with that message, otherwise one will mask the other.
The client message might look something like this:
client server1.win32 [netstat] Bytes 144681781 42531845
To get Xymon to match against the bbwin match string, you have to report your OS in the message as "bbwin" or "win32". This is probably why you're getting the "reports netstat for an unknown OS" message.
J
Jeremy,
I changed my script using your advices. It looks like this now:
::# Define the temp variable 'hostname' @For /f "tokens=1" %%* in ( 'hostname' ) Do @Set "hostname=%%*"
::# Define the temp variables 'Inbound and Outbound' @for /f "tokens=2" %%* in ( 'netstat.exe -e ^| findstr /i "Bytes"' ) do @set "Inbound=%%*" @for /f "tokens=3" %%* in ( 'netstat.exe -e ^| findstr /i "Bytes"' ) do @set "Outbound=%%*"
::# Redirect output to a textfile @> "scripts\netstat" ( rem @echo green %Date% %time% @echo client %hostname%.win32 @echo [netstat] @echo %hostname% %Inbound% %Outbound% )
This .bat script is creating the output: (My servers name is ghostwus)
client ghostwus.win32 [netstat] ghostwus 65057048 3838258240
And indeed the message "reports netstat for an unknown OS" is gone and I got some client data:
[collector:netstat] status ghostwus.netstat client Tue Jun 25 23:17:17 CEST 2013 [netstat] ghostwus 65874964 3838527680
<font color=DarkSlateBlue >Xy-checkwin-2.0.1</font>
But still no graph... :-(
I changed the message output to
client ghostwus.win32 [ifstat] ghostwus 65057048 3838258240
without any success.
On Tue, Jun 25, 2013 at 5:07 AM, Jeremy Laidman <jlaidman at rebel-it.com.au>wrote:
On 25 June 2013 07:03, B-Art Gillis <bacaselo at gmail.com> wrote:
Thank you for your answer but I just saw on the graph that the values are converted to rrd data seem to come from the "do_netstat.c" module.
No, if you want interface statistics then you want ifstat parsed in do_ifstat.c. If you want protocol statistics (layer 3 and above such as TCP and UDP) then you would want a [netstat] section parsed in do_netstat.c. The message example you gave shows interface statistics.
Xymon expects the format to match ifstat_bbwin_exprs[] (defined in do_ifstat.c). This includes an IP address then the in and out byte count. The output of "netstat -e" does not provide an IP address, and it provides much more than just the bytes in and out. You'd have to select the Bytes line and prefix it with an IP address (probably a dummy device name would do also).
Something like:
EthDev 144681781 42531845
Any whitespace can be used as separators (one or more tabs or spaces).
You could probably get away with this:
echo [netstat] & netstat -e | find "Bytes"
This would give "Bytes" as a devicename, but I don't think it would break anything.
You need to prefix this message with the correct "client" message header. If you're sending other client data, this should be included with that message, otherwise one will mask the other.
The client message might look something like this:
client server1.win32 [netstat] Bytes 144681781 42531845
To get Xymon to match against the bbwin match string, you have to report your OS in the message as "bbwin" or "win32". This is probably why you're getting the "reports netstat for an unknown OS" message.
J
On 26 June 2013 07:29, B-Art Gillis <bacaselo at gmail.com> wrote:
But still no graph
Is there an RRD file? Is there anything interesting in the rrd-data.log file? Bear in mind that (unless run with the --no-cache switch) xymond_rrd doesn't update the RRD file immediately, and instead caches updates for a period of time (up to 30 minutes). In my experience, viewing a graph seems to cause xymond_rrd to flush its cache, so if you're only looking for updates in the RRD file directly, you might not see new data come in straight away. But if you're looking at graphs, you're probably triggering a cache flush anyway. Where are you looking for the graph? There might be a delay in the graph showing up in the trends page, so what I usually do is to click another graph for the same host, and then change the URL to point at the graph I'm looking for. For example, click on the "CPU Load" (load average = "la") and then change the "la" in the URL to "ifstat".
client ghostwus.win32 [ifstat] ghostwus 65057048 3838258240
BBWin presents an IP address in the first field (rather than a hostname). My review of the do_ifstat.c code indicated that a hostname would probably be fine, but there could be other bits of code that reject the message before (or after) it gets to this point. So I would try adjusting the message so that the IP address of the interface (or any IP address, for testing) is used instead of the hostname. Even 0.0.0.0 would be a reasonable test. Also, could be worthwhile running client and data channel inspectors at the same time as you send the message (in separate windows). Here's what I would use: sudo -u xymon xymoncmd xymond_channel --channel=client grep -A10 ^@@.*ghostwus sudo -u xymon xymoncmd xymond_channel --channel=data grep -A10 ^@@.*ghostwus The first command will show the first 10 lines of any client message that come from (or contain in their header) "ghostwus". The second command will match any data messages from same, and you should see an "ifstat" message possibly among others. The data message is generated by the xymond_client process that takes the client messages, parses them (using the code in do_ifstat.c) and creates the data messages. The flow goes like this: windows --(client message)--> xymond --(client channel)--> xymond_client --(data channel)--> xymond_rrd --> rrdfile If you're getting the client message but not the data message, then the problem is somewhere in xymond_client. Look in the clientdata.log file. If you're getting the data messages, it could be something else, like a permissions problem on the RRD directory, or the xymond_rrd process isn't running. Look in the rrd-data.log file. Cheers Jeremy
Hi Jeremy, Thank you for your help and feedback. Having this extra knowledge I took a closer look at the output of the netstat result of the BBWin agent and discovered that the network graphs are generated by the "nestat -s" command. So I redesigned my script so that it now generates exactly the same output for the "netstat" check as BBWin does. And as expected, I now get the rrd files that are giving me the graphs of the TCP/IP statistics. I didn't managed to create the interface rrd files through ifstat but these protocol statistics are just fine. Here my script: echo off SETLOCAL ENABLEDELAYEDEXPANSION SET count=1 FOR /F "tokens=2 USEBACKQ delims==" %%F IN (`netstat -s`) DO ( SET var!count!=%%F SET /a count=!count!+1 ) ::# Redirect output to a textfile @> "scripts\netstat" ( @echo green %Date% %time% @echo win32 @echo PacketsReceived=%var1% @echo ReceivedHeaderErrors=%var2% @echo ReceivedAddressErrors=%var3% @echo DatagramsForwarded=%var4% @echo UnknownProtocolsReceived=%var5% @echo ReceivedPacketsDiscarded=%var6% @echo ReceivedPacketsDelivered=%var7% @echo OutputRequests=%var8% @echo RoutingDiscards=%var9% @echo DiscardedOutputPackets=%var10% @echo OutputPacketNoRoute=%var11% @echo ReassemblyRequired=%var12% @echo ReassemblySuccessful=%var13% @echo ReassemblyFailures=%var14% @echo DatagramsSuccessfullyFragmented=%var15% @echo DatagramsFailingFragmentation=%var16% @echo FragmentsCreated=%var17% @echo. @echo tcpActiveOpens=%var18% @echo tcpPassiveOpens=%var19% @echo tcpFailedConnectionAttempts=%var20% @echo tcpResetConnections=%var21% @echo tcpCurrentConnections=%var22% @echo tcpSegmentsReceived=%var23% @echo tcpSegmentsSent=%var24% @echo tcpSegmentsRetransmitted=%var25% @echo. @echo udpDatagramsReceived=%var26% @echo udpNoPorts=%var27% @echo udpReceiveErrors=%var28% @echo udpDatagramsSent=%var29% ) ENDLOCAL On Wed, Jun 26, 2013 at 4:18 AM, Jeremy Laidman <jlaidman at rebel-it.com.au>wrote:
On 26 June 2013 07:29, B-Art Gillis <bacaselo at gmail.com> wrote:
But still no graph
Is there an RRD file? Is there anything interesting in the rrd-data.log file?
Bear in mind that (unless run with the --no-cache switch) xymond_rrd doesn't update the RRD file immediately, and instead caches updates for a period of time (up to 30 minutes).
In my experience, viewing a graph seems to cause xymond_rrd to flush its cache, so if you're only looking for updates in the RRD file directly, you might not see new data come in straight away. But if you're looking at graphs, you're probably triggering a cache flush anyway.
Where are you looking for the graph? There might be a delay in the graph showing up in the trends page, so what I usually do is to click another graph for the same host, and then change the URL to point at the graph I'm looking for. For example, click on the "CPU Load" (load average = "la") and then change the "la" in the URL to "ifstat".
client ghostwus.win32 [ifstat] ghostwus 65057048 3838258240
BBWin presents an IP address in the first field (rather than a hostname). My review of the do_ifstat.c code indicated that a hostname would probably be fine, but there could be other bits of code that reject the message before (or after) it gets to this point.
So I would try adjusting the message so that the IP address of the interface (or any IP address, for testing) is used instead of the hostname. Even 0.0.0.0 would be a reasonable test.
Also, could be worthwhile running client and data channel inspectors at the same time as you send the message (in separate windows). Here's what I would use:
sudo -u xymon xymoncmd xymond_channel --channel=client grep -A10 ^@@.*ghostwus sudo -u xymon xymoncmd xymond_channel --channel=data grep -A10 ^@@.*ghostwus
The first command will show the first 10 lines of any client message that come from (or contain in their header) "ghostwus".
The second command will match any data messages from same, and you should see an "ifstat" message possibly among others. The data message is generated by the xymond_client process that takes the client messages, parses them (using the code in do_ifstat.c) and creates the data messages.
The flow goes like this:
windows --(client message)--> xymond --(client channel)--> xymond_client --(data channel)--> xymond_rrd --> rrdfile
If you're getting the client message but not the data message, then the problem is somewhere in xymond_client. Look in the clientdata.log file. If you're getting the data messages, it could be something else, like a permissions problem on the RRD directory, or the xymond_rrd process isn't running. Look in the rrd-data.log file.
Cheers Jeremy
participants (2)
-
bacaselo＠gmail.com
-
jlaidman＠rebel-it.com.au