Community
Participate
Working Groups
1. support new symptom model in the existing analysis engine 2. make AE extension point for plugging in other engines 3. new symptoms view in the eclipse LTA
This work was done outside of TPTP and the requirement is to contribute it at TPTP 4.0 since it is breaking api.
Updating feature target per 01/10 UI main committers meeting
Documentation to be contributed, too.
Please set version to 4.1, this is my requirement although I did not open it.
retarget to 3.3i2 per 02/09 Platform meeting
This is related to bug 64800
Finished.
moving to 4.1
Documentation backed out of 4.0. When this goes into 4.1, ID should do the following: 1. Go to org.eclipse.tptp.platform.doc.user. 2. Right-click and select Replace with > Another branch or version. 3. Under Versions, select "new_sdb_info". This will put the files into your workspace as they were before I backed out the changes. 4. Check to see if any changes made since the "old_sdb_info" tag was applied (see Team > Show in revision history) need to be made to the new files, and if so, move those changes over. 5. Edit logging_toc.xml and remove the comments from around the tmigrate_sdb.htm element. 6. Commit the changes. Test.
More info for ID: ----------------- Help topics tagged with new_sdb_info/old_sdb_info: concepts/cesdb.htm concepts/cesdbed.htm images/sdb_editor.gif (only exists for new_sdb_info) tasks/tecrsdb.htm tasks/teedsdb.htm tasks/teexsdb.htm tasks/tmigrate_sdb.htm (only exists for new_sdb_info) tasks/teprpsdb.htm Note: Some files outside this group were updated with new labels on related links to match the <h1> titles of the new files. I have not backed out these changes, as they don't make a huge difference to the user.
moving target to 4.2 per Chris's request
1. Provide analysis engine extension interfaces for plugging in any OEM analysis engine 2. Provide implementation engine to consume this Symptom/OSR format 3. Provide analysis results (symptoms) window
The paradigm used here is to analyze a set of events (or an entire file) for a list of well-known symptoms,displaying those symptoms, providing the ability to drill-down into how you came to that conclusion (i.e. the list of events associated with the symptom), and finally to any recommended actions to address the event/symptom. The view should be able to distinguish between multiple occurrences of the same symptom, not represents them all as the same symptom. One occurrence of a symptom vs. multiple occurrences of the same symptom is very different, and we should communicate that to our customers. A scenario can illustrate. Let's say I have a log file for an entire day. During that day, there were three times that customers could not log into the system (8:00, 8:30, and 10:45). The reason they could not log on was access to an LDAP server was failing. So: The symptom is 'Cannot log on' The events that lead up to that symptom are: 'logon failed' and 'Access to LDAP server failed'. View would show: Symptom : 'Cannot log on' Events : 'Logon failed' 'Access to LDAP server failed' 'Logon failed' 'Access to LDAP server failed' 'Logon failed' 'Access to LDAP server failed' Recommended Action: Re-establish link to LDAP server The correct view would have been multiple symptoms (one for each occurrence of the event), with each symptom having one event associated with it. * Keep the functionality of the symptom analysis background icon in the Log view and continue giving the user the capability to navigate from the Log view to the symptom analysis results view. * The the capability to sort by time the symptom instances in the symptom analysis results view and show the most recent one at the top of the view.
Theme: Design for Extensibility: Be a Better Platform
Provide an implementation for an XPATH analysis engine based on FastXPATH. It should support XPATH 1.0 format for the Symptom rule format. Provide analysis engine interfaces that looks like the following in order to plugin any analysis engine from any company: * @param objects List of objects to associate. * @param rules List of rules which will be used to associate the list of input objects. * @param monitor optional parameter used to provide information about the progress of the association process. * @param the result of the association process. * @param rebuild indicates if we need to rebuild the symptom rules or not. * */ public void associate(List events, List symptoms, IAssociationMonitor monitor, List Results, Boolean rebuild); This new Analysis Engine interface should be the same as the new Correlation Engine interface. Also, we need to create a new symptom analysis result view in TPTP which will display the symptom analysis results in order. This order can be sorted in ascendant/descendant mode. This analysis result view will display all the symptom properties. It will also need to provide an extension point so it can display OEM symptom rules in the proper OEM rule format. Clicking on a matched event in the Analysis result view should bring the user to the selected event in the log view and the log correlation view. Finally, when clicking on a log correlation in the log navigator, we should disable the Open With->Statistical Data menu item.
Clarifications: For the symptom analysis results view, we need to be able to persist the results into EMF. This would mean that we need to create an EMF model for the analysis results. Also, for scalability, we need to be able to persist these results in an RDB when large log support is enabled. These results would need to be saved in XML format instead of XMI.
Also, this new analysis result model needs to be in its own plugin just like the CBE model and the Symptom model. It has to be supported outside an Eclipse environment.
Done.
close bug
