<div dir="ltr"><div><div><div><div>Hi Jeremy,<br><br></div><div>Thank you for your help and feedback.<br></div><div>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.<br>
</div></div>So I redesigned my script so that it now generates exactly the same output for the "netstat" check as BBWin does.<br></div>And as expected, I now get the rrd files that are giving me the graphs of the TCP/IP statistics.<br>
</div><div>I didn't managed to create the interface rrd files through ifstat but these protocol statistics are just fine.</div><div><br></div>Here my script:<br><br>echo off<br>SETLOCAL ENABLEDELAYEDEXPANSION<br>SET count=1<br>
FOR /F "tokens=2 USEBACKQ delims==" %%F IN (`netstat -s`) DO (<br>  SET var!count!=%%F<br>  SET /a count=!count!+1<br>)<br>::# Redirect output to a textfile<br>@> "scripts\netstat" (<br>  @echo green %Date% %time%<br>
  @echo win32<br>  @echo    PacketsReceived=%var1%<br>  @echo    ReceivedHeaderErrors=%var2%<br>  @echo    ReceivedAddressErrors=%var3%<br>  @echo    DatagramsForwarded=%var4%<br>  @echo    UnknownProtocolsReceived=%var5%<br>
  @echo    ReceivedPacketsDiscarded=%var6%<br>  @echo    ReceivedPacketsDelivered=%var7%<br>  @echo    OutputRequests=%var8%<br>  @echo    RoutingDiscards=%var9%<br>  @echo    DiscardedOutputPackets=%var10%<br>  @echo    OutputPacketNoRoute=%var11%<br>
  @echo    ReassemblyRequired=%var12%<br>  @echo    ReassemblySuccessful=%var13%<br>  @echo    ReassemblyFailures=%var14%<br>  @echo    DatagramsSuccessfullyFragmented=%var15%<br>  @echo    DatagramsFailingFragmentation=%var16%<br>
  @echo    FragmentsCreated=%var17%<br>  @echo.<br>  @echo    tcpActiveOpens=%var18%<br>  @echo    tcpPassiveOpens=%var19%<br>  @echo    tcpFailedConnectionAttempts=%var20%<br>  @echo    tcpResetConnections=%var21%<br>  @echo    tcpCurrentConnections=%var22%<br>
  @echo    tcpSegmentsReceived=%var23%<br>  @echo    tcpSegmentsSent=%var24%<br>  @echo    tcpSegmentsRetransmitted=%var25%<br>  @echo.<br>  @echo    udpDatagramsReceived=%var26%<br>  @echo    udpNoPorts=%var27%<br>  @echo    udpReceiveErrors=%var28%<br>
  @echo    udpDatagramsSent=%var29%<br>  )<br>ENDLOCAL<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 26, 2013 at 4:18 AM, Jeremy Laidman <span dir="ltr"><<a href="mailto:jlaidman@rebel-it.com.au" target="_blank">jlaidman@rebel-it.com.au</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">On 26 June 2013 07:29, B-Art Gillis <span dir="ltr"><<a href="mailto:bacaselo@gmail.com" target="_blank">bacaselo@gmail.com</a>></span> wrote:<br>
<div class="gmail_quote"><div>

<br></div><span style="font-size:13px;font-family:arial,sans-serif">> But still no graph</span><br><div><br></div><div>Is there an RRD file?  Is there anything interesting in the rrd-data.log file?</div><div><br></div>


<div>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).</div><div><br></div><div>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.</div>


<div><br></div><div>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".</div>
<div class="im">

<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div>client ghostwus.win32
<br>[ifstat]
<br>ghostwus 65057048 3838258240</div></blockquote><div> </div></div></div>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.</div>


<div class="gmail_extra"><br></div><div class="gmail_extra">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.</div>


<div class="gmail_extra"><br></div><div class="gmail_extra">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:</div>


<div class="gmail_extra"><br></div><div class="gmail_extra">sudo -u xymon xymoncmd xymond_channel --channel=client grep -A10 ^@@.*ghostwus</div><div class="gmail_extra">sudo -u xymon xymoncmd xymond_channel --channel=data grep -A10 ^@@.*ghostwus</div>


<div class="gmail_extra"><br></div><div class="gmail_extra">The first command will show the first 10 lines of any client message that come from (or contain in their header) "ghostwus".</div><div class="gmail_extra">


<br></div><div class="gmail_extra">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.</div>


<div class="gmail_extra"><br></div><div class="gmail_extra">The flow goes like this:</div><div class="gmail_extra"><br></div><div class="gmail_extra">windows --(client message)--> xymond --(client channel)--> xymond_client --(data channel)--> xymond_rrd --> rrdfile</div>


<div class="gmail_extra"><br></div><div class="gmail_extra">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.<br>


</div><div class="gmail_extra"><br></div><div class="gmail_extra">Cheers</div><span class="HOEnZb"><font color="#888888"><div class="gmail_extra">Jeremy</div><div class="gmail_extra"><br></div></font></span></div>
</blockquote></div><br></div>