Archive for July 2005
I added the pieces for the new primary view today. These consist of 2 new automations (ViewBaseIn and ViewBaseNotIn). These set or unset the ViewBaseIn flag based on the same rules that governed the existing Primary view, excluding the ViewFlag rules. ViewBaseIn:
update alerts.status set ViewBaseIn = 1 where ViewBaseIn 1 and Type 0 or Smart24Status >= 20 ) and Severity <> 1 and TestFlag <> 1 and IncidentType ViewBaseNotIn: update alerts.status set ViewBaseIn = 0 where ViewBaseIn <> 0 and (Type > 1 or (Severity = 0 and Smart24Status 1 or ServerLifeCycle not in (0, 2));
In addition, there are a couple of new Menu items:
- Override to include in Primary View
- Override to exclude from Primary View
- Cancel Overrides
- Move to Pending View (new)
- Move out of Pending View (new)
The override menu items are in a new submenu called “Override Views”.
The move to pending now works from any view, not only pending. Move out of pending just unsets the pending flag and does not necessarily mean the item will show up in Primary.
The “Override to include in Primary” and “Override to exclude from Primary” items just set the corresponging ViewOverrideIn and ViewOverrideEx flags. Cancel overrides, conversely, just clears these flags.
Finally, there is a new primary view definition, that works off the view attributes. And naturally there is very simple new pending view definition.
Almost as a by product of the Service Correlator, there is a service called “AddCustomer”. This service runs in the same webservice as the Service Correlator and adds customer and Server Lifecycle state information to events.
Since the infrastructure to send new events to this service is already in place, and the service has access to the Smart24 database which has details on components, it seems convenient to use it to populate the notorious “category” attribute in events as well.
The primary purpose of an alert category is to help the operators in assigning Incident ticket activities. When the category says network, it is a hint that the problem is network related and needs to be handled by the network team.
However, categories are not set properly by most probes or agents. Most notoriously, it is not used at all by the SSMs. Therefore, currently it’s value is limited. However, the operators are asking for help in trying to figure out how to assign activities, so some action is needed. This is why a story was added to cycle 13.
One problem in the current AddCustomer service is that, as said, runs as a part of the service correlator, which uses a cache of components to avoid hitting the database too often. The reason it uses this cache is taht the service correlator needs to traverse the dependency hierarcy all the time, which is a very expensive operation to do if done directly on the database.
However, if the data that the AddCustomer service operates on is not up to date, the value of the service is limited. Until now, with customer information being populated, this was not much of a problem, since this data is quite static in nature. The same will hold for category information. Other pieces of information are more volatile though. The ServerLifeCycle information is one such piece of information. The situation will change more if we make this service also populate view flags.
Currently the cache is refreshed once a day, as the webservice is restarted by IIS. An obvious way to keep the benefits of caching for the service correlator, while still allowing information that is not very static to be added to events is by caching the dependencies table only, but always read Components from the database. The reason this works is that it is possible to traverse the dependencies hierarchy without having to read component records at all. When a component read is needed, it can be done quickly using a simple query on the primary key of the component, which will be fast.In addition, lookup of components from Address, Class and Instance of an event may also be need to be cached.
Additionally, information that is not in the Components table per se will be needed. For example, it is useful to populate OS information in alerts, and this info will also be necessary for the categories implementation. This information, however, is not present in a component, but in its associated Device record.
Work on the precision data server was completed. It mainly reuses the code that was written for the Netcool data server, using Apache mod-perl.
The Precision data server gets its data from the MySQL data base that is used by Topoviz, instead of using the main Precision OO database.
You can try it out at http://ip.ad.dr.ess:8080/query.
The current primary view filter for netcool view (as copied an pasted from the event viewer) is as follows:
( ViewFlag = 0 )
( Type 0 )
( Smart24Status >= 20 )
( Severity <> 1 )
( TestFlag <> 1 )
Just try to figure out what it is doing….
After stripping the extraneous parenthesis and removing the view flag attributes, the following remains:
When implementing the fixed Netcool filter definition, a number of flags are called for. These can be implemented in a bit vector. This saves space, as a single int field would be more than enough. However, it saves space at the sacrifice of readability and understandability.
The alternative is to use different attributes for each flag. This wastes some space, as each attribute will be a separate int. It will be more understandable since each attribute is easility identified by a descriptive name, which is a lot better than to have to remember positions in a bit vector.
A question that is often asked is why a certain event is not in the primary view. Having separate attributes will makes this more understandable for everybody. In addition, increased readability makes it less easy to make mistakes using separate attributes as compared to a bit vector. Finally, the amount of space wasted is fairly limited, and not likely to cause any problems.
The attributes will be:
The ViewInPending attribute is added to the original design. The reason is that when an alert is included in the primary view by a manual override (right-click menu) using ViewOverrideIn, it would be strange if that alert would have special behavior with regard to moving to the pending view. So ViewInPending hides alerts from the primary view, overriding all other inclusion attributes, and show the event in the pending view.
The cycle 12 release date is changed to August 11th (Thursday).
In order to keep the release and development cycles in sync, we’ll extend this cycle by one week as well. The new end date now becomes August 5th.