Argus management records

Carter Bullard carter at qosient.com
Mon Nov 12 10:40:03 EST 2007


Hey Esteban,
Sorry for the delayed response.
The man records contain the state of the probe, and we generate
these every ARGUS_MAR_STATUS_INTERVAL, which is every
60 secs by default, ( you can specify another time in the argus.conf ).
The clients use these are keep-alives, so that they know that their
source of data is still there, whether it is generating FARs or not.

The contents of the 128 byte management record currently are/is:

    unsigned int status, argusid, localnet, netmask, nextMrSequenceNum;
    struct ArgusTime startime, now;
    unsigned char  major_version, minor_version, interfaceType,  
interfaceStatus;
    unsigned short reportInterval, argusMrInterval;
    unsigned long long pktsRcvd, bytesRcvd, timedrift;

    unsigned int records, flows, dropped, queue, output, clients;
    unsigned int memorybufs, memorybytes;
    unsigned short suserlen, duserlen;
    unsigned int thisid, record_len;

and the purpose is to expose/externalize the key aspects of
the performance of the argus/radium.

Many of the objects are identification oriented, argusid, localnet,
netmask, major_version, minor_version, interfaceType,
FarReportInterval, MarReportInterva, suserlen, duserlen, and
all help the clients to know what to expect, and if anything has
changed with regard to the probe itself.

The rest of the objects are metrics, and can be important.  They
include:
    startime, now;  (reporting interval for this man record)
    pktsRcvd, bytesRcvd (probe load)
    timedrift (perceived drift from correct time, usually
                    supplied by radium/ra* programs).
    records (number of records written out)
    flows     (total number of flows tracked)
    dropped (number of input packets dropped by engine)
    queue    (current number of flows being tracked)
    output    (current number of records scheduled to be written)
    clients    (number of registered output clients)
    memorybufs (number of buffers allocated)
    memorybytes (total number of bytes allocated)
    suserlen, duserlen (max user buffer capture size)


from this data you should be able to tell if the argus/radium is
healthy or not.

When you print the contents of the mar record using ra*, the
fields are mapped like the list below.  There is no real justification
for this, and so if you have a better way of mapping the Far and
Mar Fields, please make suggestions, before the release!!!

    stime  startime
    ltime   now
    flgs     blank
    proto  'man'
    saddr  "queue count"
    sport   "packets dropped"
    dir      blank
    daddr  "memory bufs"
    dport  "registered clients"
    spkts  "pkts received"
    dpkts  "records written"
    sbytes "bytes received"
    dbytes "memory bytes"
    State   "status"


I know that these seems like chaos, so if you have any
suggestion as to how to overload this, that would be great.

Carter



On Nov 8, 2007, at 2:55 PM, Esteban G wrote:

> sorry meant to include the paste of the ra command:
> ra -L0 -n -r <argus file> - man
>
> -esteban
>
>
> On 11/8/07, Esteban G <infoape at gmail.com> wrote:
>> Just out of curiosity what are we looking at when we see these  
>> records:
>>
>>          StartTime    Flgs  Proto            SrcAddr  Sport   Dir
>>       DstAddr  Dport  SrcPkts  DstPkts     SrcBytes     DstBytes  
>> State
>>    00:01:02.164051            man               1412      0
>>          5930      1    44205     1625     18052533      3825435    
>> CON
>>    00:02:02.168611            man               1835      0
>>          7219      1    47569     3029     17959596      7166675    
>> CON
>>    00:03:02.173056            man               1696      0
>>          6968      1    61118     3603     30275159     10517483    
>> CON
>>
>>
>> -esteban
>>
>



More information about the argus mailing list