Troubleshoot message as loaded into the table

[RSAAdmin]

How do I troubleshoot were a message is not showing up in the desired table?

I am parsing the message and assigning it to a table.  The message tag in the xml is this:

<MESSAGE
    level="7"
    parse="1"
    parsedefvalue="1"
    tableid="24"
    id1="021"
    id2="021"
    eventcategory="1901000000"
    content="PCNX  E TPM_CF    (&lt;threshold&gt Connection &lt;action&gt; for user &lt;username&gt; reason : &lt;reason&gt;" />

 

  My uds -device axwaygateway -parm command returns this:

-device class information 267

   InternalName:             Name:           CategoryName:   LI: MsgInfo:
   DID: Image:      Hdrs:  T / L / S
01 Axway Gateway             axwaygateway    APPLICATION SERVERSU621axwaygateway
msg621  axwaygateway1       (0.2511 / 1 / 0)

-parm:

10: axwaygateway Lines 1
Variable List for data category access_security identifier 57
        Variable:       Ref:    Use:
         action         1
         reason         1
         threshold      1
         username       1
parseData 0:

 After running injector I can see the messages coming in, but queries to the Access Control Security table return no data.

Can anyone see an error on my part?  How can I troubleshoot the data after I see it in a realtime Events - Message View and why it is not loaded into the table?

[RSAAdmin]

Kurta,

You need to post a header as well as a sample of the event - otherwise we're all just guessing where the mismatch may be.

Also, please post samples you'd like the Intelligence Community to look at as attached files rather than pasting directly into the body of the message - sometimes the formatting comes out weird and certain character combinations get replaced with emoticons.

Suggestion:  attach the xml for the device as well as a scrubbed version of your logs from an lsdata dump.

[RSAAdmin]

Also:  the -parm parameter does not tell you that an event has parsed correctly with your XML - it just indicates whether the fields you chose actually exist within an enVision reporting table.

To actually check whether a message is parsing, use the -parse -msg combination

[RSAAdmin]

I found the problem in the header.  These logs for the Axway Gateway are not simple one-liners.

If I add a field to a table and restart the service will future system updates and upgrades overwrite the sqltbl files?

[RSAAdmin]

Yes - so save a copy of any table files you update!

[RSAAdmin]

Attached is some info of the problems I'm having.  From the ouptut of the uds -parse, it _seems_ to parse to the fields, but.....

What is missing?

Thanks,

Kurt

[RSAAdmin]

On the surface, what you have presented here looks OK, but I have no way to do any deeper testing as far as a direct data import to enVision without the logs.

[RSAAdmin]

What logs should I be looking at?

[RSAAdmin]

I also noticed that the saddr is NOT USED, even tho saddr is a valid field in access_accounting.  Could this indicate another problem?

E:\nic\3700\ENVLAB01-ES\bin>uds -device axwaygateway -parm

-device class information 267

   InternalName:             Name:           CategoryName:   LI: MsgInfo:          DID: Image:      Hdrs:  T / L / S
01 Axway Gateway             axwaygateway    APPLICATION SERVERSU621axwaygatewaymsg621  axwaygateway1       (0.2503 / 2/ 0)

-parm:

10: axwaygateway Lines 2
Variable List for data category access_accounting identifier 56
        Variable:       Ref:    Use:
         conn_id        1
         faddr          1
         fport          1
         sport          1
         saddr          1       NOT USED
Variable List for data category access_security identifier 57
        Variable:       Ref:    Use:
         accountid      1
         action         1
         reason         1
         username       1
parseData 0:

[RSAAdmin]

You are using the Generic Filereader, so you are ultimately putting a file containing your raw events into one of the FTP_files folders for enVision to process - that is the file I want to examine - the one with the events you are collecting.

Again, you may scrub any IP addresses/usernames/other sensitive data as long as the events retain their format.