We! Analyze - Automated Connector Log Analyzer
One of the biggest issues we have as ArcSight administrators is knowing what's going on with our connectors.
A connector may be "up and running" but actually it has not sent a single event in weeks.
Also, many single connectors collect events from multiple location (multi database, multi file, WUC) and we might never know one of these locations is unavailable as events from the other locations are arriving so the connector seems to be working fine.
Eventually, when we do understand that something is wrong, it takes a while to analyze, understand and solve.
In light of these problems in the process of error detection in connectors, I have developed an automated tool named 'We! Analyze' with its own UI which analyzes connector logs manually or using an API that can be started from the command line, a schedule task or from the console with an action in rule, tool or integration command (if you use the API you can forward the events to a syslog listener in CEF format).
You may choose to run 'We! Analyze' on all of your connectors at 7AM, forward it by syslog to a syslog listener and into your manager so when you arrive to work you'll have a report waiting for you in your mailbox with all the issues you have with you connectors.
Post analyze, 'We! Analyze' suggests possible solutions to 103 known errors (in version 22.214.171.124) as well as Google search an error, search ArcSight forum for the error and mailing the error to your colleagues.
'We! Analyze' enables us to change our approach towards connector troubleshooting – we know that something is wrong much faster than we knew before so we can fix it much faster and avoid critical errors like data loss.
Please view the attached PDF file, and view the video in the following link for a demonstration (watch at 1080p):
If you wish to receive 'We! Analyze' or if you have any questions feel free to contact me at any time.
Visit us: http://www.wemeansecurity.com/
Great initiative! Something like this should potentially be very helpful.
Last comment form the .pdf: "Needs .NET Framework 3.0 to run." 😞 I'm no coder so could not do any better, but any specific reason why java was not used for coding? Any roadmap for java code perhaps?
el mejor ajo
Thank you, It is very helpful .
Since implementation we were able to identify several sever issues with our connectors and fix them.
For example we noticed that every night one of our databases is rejecting our queries for about 2 hours claiming that the user or password is incorrect (due to a Kerberos ticket issue which we were able to fix), a lot of memory and cache issues alongside some parsing issues that caused us to lose events.
The reason it is written with .NET is simply because I'm better acquainted with .NET development than Java development.
Currently there is no roadmap for a Java application.
Visit us: http://www.wemeansecurity.com