<html dir="ltr"><head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body style="text-align:left; direction:ltr;">
    I updated the XymonPSClient to v2.42 just to make sure that wasn't
    the cause.  It didn't resolve anything.<div><br></div><div>I checked the rrd folders to make sure there wasn't some duplicate hostname folders or something.  There wasn't.</div><div><br></div><div>I reviewed the clientlog from both functioning and non-functioning hosts and the cpu data looks the same.  Both show load=NN.NN%</div><div>The difference between them is that the functioning host is 'Win Server 2012 R2 Datacenter' and non-functining one is 'Win Server 2019 Datacenter'.  But if the v2019 was the issue then my other 2019 hosts that are sending their data over port 1984 wouldn't be working either?</div><div><br></div><div>I ran the $XYMON $XYMSRV "xymondlog <hostname>.cpu" and reviewed the content for both hosts.  The content exists and looks the same, other than the non-functioning one has a LOT more of it.  I'm starting to think the data might be getting truncated.  But the same lack of cpu graphs are happening for 8 new hosts.  All other incoming data seems totally fine, just no cpu graphs.<br>
    <br>
    I looked through the 'Xymon client log' and noticed this message.<br>
    'Payload length reached 2738, greater than 1024'<br>
    <br>
    I ran into this issue once before long ago when I switched from
    BBwin to XymonPSClient.  The client data coming into the server was
    larger than the default allowed, so it was getting truncated and
    causing purple alerts.  Server default was 512k, so I increased it
    to 1024k and everything has been fine for years.  Now it seems with
    new Windows servers there's more client data coming in.  I'm thinking this may be my current issue, so I just
    increase it to 3072k in the xymonserver.cfg file and restarted
    Xymon Server.  I waited a few cycles and watched the 'Xymon client
    log' for the changes to appear.  It's still showing the same
    'Payload length is greater than 1024' message.  I also restarted the
    XymonPSClient service on the Windows host and it didn't seem to
    resolve anything.  What am I missing here?  The server should be
    allowing larger amounts of client data now.<br>
    <br>
    <pre>Kris Springer</pre><pre><br></pre><pre><br></pre><pre><br></pre>
    <div class="moz-cite-prefix">On 5/27/21 3:21 AM, Beck, Zak wrote:<br>
    </div>
    <blockquote type="cite" cite="mid:DM6P114MB1333EE441A73EEF7C7975D7F98239@DM6P114MB1333.NAMP114.PROD.OUTLOOK.COM" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex">
      
      
      <!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]-->
      <style>@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}span.EmailStyle18
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:#034BED;}.MsoChpDefault
        {mso-style-type:export-only;
        font-family:"Calibri",sans-serif;
        mso-fareast-language:EN-US;}div.WordSection1
        {page:WordSection1;}</style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
      <div class="WordSection1">
        <p class="MsoNormal"><span style="color:#034BED;mso-fareast-language:EN-US">Hi<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#034BED;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span style="color:#034BED;mso-fareast-language:EN-US">There’s no
            difference in the data sent between TCP / HTTP(S) transport
            (aside from a flag at the end to indicate whether TCP or
            HTTP was used).<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#034BED;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span style="color:#034BED;mso-fareast-language:EN-US">You
            probably know you can look at the xymon-lastcollect.txt log
            to see what is being sent. This log will get overwritten
            every time the client sends the data but you can retain and
            rotate the last so many versions using
            <clientlogretain><b>number</b></clientlogretain>
            in xymonclient_config.xml e.g.
            <clientlogretain>5</clientlogretain> to keep the
            last 5 copies, which may be helpful. The client will rotate
            the files so you should not run out of space.<o:p></o:p></span></p>
        <p class="MsoNormal"><span style="color:#034BED;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span style="color:#034BED;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span style="color:#034BED">Zak <br>
            <br>
          </span><span style="color:#034BED;mso-fareast-language:EN-US"><o:p></o:p></span></p>
        <div style="border:none;border-top:solid #E1E1E1
          1.0pt;padding:3.0pt 0cm 0cm 0cm">
          <p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Xymon <a class="moz-txt-link-rfc2396E" href="mailto:xymon-bounces@xymon.com"><xymon-bounces@xymon.com></a>
              <b>On Behalf Of </b>Jeremy Laidman<br>
              <b>Sent:</b> 27 May 2021 04:39<br>
              <b>To:</b> Kris Springer
              <a class="moz-txt-link-rfc2396E" href="mailto:kspringer@innovateteam.com"><kspringer@innovateteam.com></a><br>
              <b>Cc:</b> Xymon MailingList <a class="moz-txt-link-rfc2396E" href="mailto:xymon@xymon.com"><xymon@xymon.com></a><br>
              <b>Subject:</b> [External] Re: [Xymon] cpu rrd files not
              being generated<o:p></o:p></span></p>
        </div>
        <p class="MsoNormal"><o:p> </o:p></p>
        <div>
          <p class="MsoNormal" style="text-align:center" align="center"><span style="color:#EE0701">This message is from an EXTERNAL
              SENDER - be CAUTIOUS, particularly with links and
              attachments.</span><o:p></o:p></p>
          <div class="MsoNormal" style="text-align:center" align="center">
            <hr style="color:#EE0701" width="100%" size="2" noshade="noshade" align="center">
          </div>
          <p class="MsoNormal"><o:p> </o:p></p>
        </div>
        <div>
          <div>
            <p class="MsoNormal">On Thu, 27 May 2021 at 03:16, Kris
              Springer <<a href="mailto:kspringer@innovateteam.com" moz-do-not-send="true">kspringer@innovateteam.com</a>>
              wrote:<o:p></o:p></p>
          </div>
          <div>
            <blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex">
              <p class="MsoNormal">I added a new Windows host yesterday
                and I'm using XymonPSClient v2.41
                <br>
                and data is coming into server encrypted over port 443. 
                All data seems <br>
                to be coming in just fine, and disk/memory/tcp graphs
                were auto <br>
                generated and work fine.  But the cpu graph did not
                generate.  I am <br>
                receiving the cpu stats but the la.rrd file did not get
                created.  I <br>
                cleared the hosts data and let everything auto generate
                again, but the <br>
                same result occurred with no la.rrd file being created. 
                I added 7 more <br>
                new hosts all using the same XymonPSClient over port 443
                and the same <br>
                missing cpu graphs occurred with all of them.<o:p></o:p></p>
            </blockquote>
            <div>
              <p class="MsoNormal"><o:p> </o:p></p>
            </div>
            <div>
              <p class="MsoNormal">Firstly, RRD seems to need two
                consecutive samples to start outputting RRD data in
                graphs. If it only gets one, it doesn't show the data in
                graphs. Or something like that. Sometimes you need to
                give it a bit of time. If a sample is rejected due to
                being non-contiguous, I'd expect to see a log message in
                rrd-data.log or rrd-status.log (depending on the test).<o:p></o:p></p>
            </div>
            <div>
              <p class="MsoNormal"><o:p> </o:p></p>
            </div>
            <div>
              <p class="MsoNormal">Disk, memory and CPU all originally
                come from the client data message. So if you're getting
                data for one of these, you should be getting for all of
                these.<o:p></o:p></p>
            </div>
            <div>
              <p class="MsoNormal"><o:p> </o:p></p>
            </div>
            <div>
              <blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex">
                <p class="MsoNormal">I've got other hosts <br>
                  using the same PSClient over 443 and they work just
                  fine.  Any ideas?<o:p></o:p></p>
              </blockquote>
              <div>
                <p class="MsoNormal"><o:p> </o:p></p>
              </div>
              <div>
                <p class="MsoNormal">Same exact version of
                  XymonPSClient?<o:p></o:p></p>
              </div>
              <div>
                <p class="MsoNormal"><o:p> </o:p></p>
              </div>
            </div>
            <blockquote type="cite" style="margin:0 0 0 .8ex; border-left:2px #729fcf solid;padding-left:1ex">
              <p class="MsoNormal">I've looked through all the xymon
                logs and found no errors.  Server
                <br>
                reboot affected nothing.<br>
                <br>
                I added a new host using the same XymonPSClient but NOT
                sending the data <br>
                encrypted, just using port 1984, and the cpu graph auto
                generated <br>
                correctly.  Can anyone give me a clue?<o:p></o:p></p>
            </blockquote>
            <div>
              <p class="MsoNormal"><o:p> </o:p></p>
            </div>
            <div>
              <p class="MsoNormal">Hmm, interesting. I can't think why
                that would change the behaviour. Unless XymonPSClient
                behaves differently in this mode.<o:p></o:p></p>
            </div>
            <div>
              <p class="MsoNormal"><o:p> </o:p></p>
            </div>
            <div>
              <p class="MsoNormal">Check the client data for a working
                and a non-working host. Compare the "[cpu]" sections and
                see if there are any discrepancies. You can do this from
                the command line like so:<o:p></o:p></p>
            </div>
            <div>
              <p class="MsoNormal"><o:p> </o:p></p>
            </div>
            <div>
              <p class="MsoNormal">  $XYMON $XYMSRV "clientlog
                <hostname> section=cpu"<o:p></o:p></p>
            </div>
            <div>
              <p class="MsoNormal"><o:p> </o:p></p>
            </div>
            <div>
              <p class="MsoNormal">If the output of this command for the
                two hosts both look similar, there's a good chance that
                the faulty host's message is being parsed correctly. The
                status essentially looks for "load=NNNN%" where NNNN is
                one or more digits. It also expects to see "CPU states"
                but that's not mandatory for a successful data message
                to be created. If so, you should have a CPU status
                message.<o:p></o:p></p>
            </div>
            <div>
              <p class="MsoNormal"><o:p> </o:p></p>
            </div>
            <div>
              <p class="MsoNormal">The RRD data parser looks at the
                status message contents. It essentially looks for the
                first line to contain "up: " followed (at some point) by
                ", load=NNNN%" (or load=NN or load=NN.NN for other
                OSes). Compare the CPU status messages between the two
                hosts and see if there are any discrepancies. You can do
                this from the command line like so:<o:p></o:p></p>
            </div>
            <div>
              <p class="MsoNormal"><o:p> </o:p></p>
            </div>
            <div>
              <div>
                <p class="MsoNormal">  $XYMON $XYMSRV "xymondlog
                  <hostname>.cpu"<o:p></o:p></p>
              </div>
            </div>
            <div>
              <p class="MsoNormal"><o:p> </o:p></p>
            </div>
            <div>
              <p class="MsoNormal">If there is no difference in the
                structure of these messages, then both should be
                correctly handled by the RRD parser and the la.rrd file
                should be created. If this doesn't show any problems,
                but the la.rrd file still isn't being updated
                (double-check using "rrdtool fetch <filename>
                AVERAGE | tail" or similar), then you might need to run
                xymond_rrd with the "--debug" flag, and look for helpful
                output in rrd-status.log.<o:p></o:p></p>
            </div>
            <div>
              <p class="MsoNormal"><o:p> </o:p></p>
            </div>
            <div>
              <p class="MsoNormal">Cheers<o:p></o:p></p>
            </div>
            <div>
              <p class="MsoNormal">Jeremy<o:p></o:p></p>
            </div>
            <div>
              <p class="MsoNormal"><o:p> </o:p></p>
            </div>
          </div>
        </div>
      </div>
      <br>
      
      <font size="1" face="Arial" color="Gray"><br>
        This message is for the designated recipient only and may
        contain privileged, proprietary, or otherwise confidential
        information. If you have received it in error, please notify the
        sender immediately and delete the original. Any other use of the
        e-mail by you is prohibited. Where allowed by local law,
        electronic communications with Accenture and its affiliates,
        including e-mail and instant messaging (including content), may
        be scanned by our systems for the purposes of information
        security and assessment of internal compliance with Accenture
        policy. Your privacy is important to us. Accenture uses your
        personal data only in compliance with data protection laws. For
        further information on how Accenture processes your personal
        data, please see our privacy statement at
        <a class="moz-txt-link-freetext" href="https://www.accenture.com/us-en/privacy-policy">https://www.accenture.com/us-en/privacy-policy</a>. <br>
______________________________________________________________________________________<br>
        <br>
        <a class="moz-txt-link-abbreviated" href="http://www.accenture.com">www.accenture.com</a><br>
      </font>
    </blockquote>
    <br>
  

<div><span><pre> </pre><div style="width: 71ch;"></div></span></div></div></body></html>