Community
Participate
Working Groups
Provide GLA sensor level filtering for each TPTP GLA adapters so the performance can be improved at the File->Import timeframe
Please make this a P1 for 4.3
Changing to the correct component and owner. This feature requires creating filter exit classes for the existing TPTP GLA parsers. Note, for the log import scenario, this feature is dependent on the Log Import Wizard passing the filter criteria to the adapter.
Changing priority to P1 as requested.
JStart team has developed this feature and used for several customers. Filtering in LTA does not give time benefit. This is done at the sensor, and hence events outside of a time range are not completely parsed. The filters we have in the LTA today don't really give you any performance benefit. A link to the developer works article on this (contains sample code also): http://www-128.ibm.com/developerworks/autonomic/library/ac-time/index.html The list of specific adapters that support this capability should be equivalent to the list of adapters that need static parsers in TPTP.
(In reply to comment #4) > Filtering in LTA does not give time benefit. This is done at the sensor, and > hence events outside of a time range are not completely parsed. The filters we > have in the LTA today don't really give you any performance benefit. I wouldn't say that the filters are the problem, I doubt that the result generated by the JStart team approach is always the correct one, I think they make the assumtion that the log entries are always in creation time order. Also I think (althogh I haven't looked at their code) that their implementation is written to optimize only this specific problem. If we implement this feature we need to let the user choose the behavior, stop at first event that happend after the selected range. I also think that instead of only one range the user should be able to specify multiple ranges (we should avoid overlapped ranges in the UI filter builder) with including/exluding rules. Instead of making this improvment only for creation time attribute we should handle in the same way any other attribute (not necessarly those that could be used in range expressions). Basically if a filter is provided the features values should be checked on the fly as the raw data is parsed, an example of such incremental evaluation mechanism is avaialble in the Import profile file filtering engine which is based on SimpleSearchEngine. As we tend to move to XPath filtering (in all areas) we could probably enhance the FastXPath engine with such incremental evaluation behavior and use it in GLA.
The filter should be based on: -Time range -Severity -Filter on String included in the Log Record Suggested filter format: XPATH
Add description document.
Adding plan keyword as it has been approved as a candidate for TPTP 4.3. Resources are available to complete this work. Added documentation and PII keywords because the filter exit class may generate new messages and the feature should be documented.
Reviewed and approved by the AG on July 14
This is targetted to complete in 4.3 iteration 2 (Code complete Sept. 8)
Code changes were committed to TPTP Head CVS. New filter exit interfaces and abstract classes added: org.eclipse.hyades.logging.adapter.util.ISeverityFilterExit org.eclipse.hyades.logging.adapter.util.ITimeFilterExit org.eclipse.hyades.logging.adapter.util.AbstractXPATHFilterExit New filter exit class implementations added: org.eclipse.hyades.logging.parsers.util.ApacheAccessLogFilterExit org.eclipse.hyades.logging.parsers.util.ApacheErrorLogFilterExit org.eclipse.hyades.logging.parsers.util.CommonBaseEventXMLLogFilterExit org.eclipse.hyades.logging.parsers.util.JavaLoggingXMLLogFilterExit org.eclipse.hyades.logging.parsers.util.WindowsEventLogFilterExit
As of TPTP 4.6.0, TPTP is in maintenance mode and focusing on improving quality by resolving relevant enhancements/defects and increasing test coverage through test creation, automation, Build Verification Tests (BVTs), and expanded run-time execution. As part of the TPTP Bugzilla housecleaning process (see http://wiki.eclipse.org/Bugzilla_Housecleaning_Processes), this enhancement/defect is verified/closed by the Project Lead since this enhancement/defect has been resolved and unverified for more than 1 year and considered to be fixed. If this enhancement/defect is still unresolved and reproducible in the latest TPTP release (http://www.eclipse.org/tptp/home/downloads/), please re-open.
