Abstract

TOC

ECS.ChangeLog

ECS.ChangeLog
Version Date Description
@-0 2004-Aug
  • Changed comments in V41, but due to the long time, I've not worked in this project, I generated V42, so far I know, without any changes.
  • The viewers are more needed than ever, but all is alpha-code and has nearly no organization. So I build a small framework based on frames, treeview and aspx/html pages. There is a screenshot which shows what I think.
  • ECS.Collector:In Init(), an eventhandler was only established for the case, that autoStart ist set to true for a collector. This is a bug, because Start() does not correct this for a collector. Now, the handler is always established, if used or - in this moment - not. If the collector is later started, the handler is already present.
@-0 2004-Apr
  • CollectorService
    New classes, CollectorCompositum, CollectorComposita, CollectorNotificationStatus and CollectorStateTransition were introduced. The CollectorCompositum is simply a composition of the CollectorStateTransition, the CollectorNotificationStatus, CollectorStatistics and the EventCollector itself, while the CollectorComposita is just a strong typed collection of the CollectorCompositum class[es]. This is V41 now.
  • CollectorService
    A lot of new internal methods are also introduced:LoadStaticConfigItems, SaveStaticConfigItems, LoadCollectorStatisticsItems, SaveCollectorStatisticsItems, CreateCollectorCompositaList, MergeCollectorStatisticsIntoCollectorCompositaList, InsertMissingCollectorStatistics, CleanupCollectorCompositaList, WriteCollectorStateTransistionTable. The latter ist just test-code, which will later be moved to the CollectorServicemanager.
  • A new, possibly importent note about accessing the HResult in exceptions, was found;See EventlogSourceExistsReturnValues.cs for details.
  • V37 has finshed the global changes for the state-management and works stable, V38 is only an intermediate version, which starts to remove the most debugging-code. Additionally, a new state, CollectorStateName.deleted was introduced. This state is irreversible and only used while disposing.
  • Even after implementing the state-pattern to handle the different states, there were more problems. Finally, difficult, but done, all event-related methods are also implemented in the state-classes now, which makes the implementation of the state-pattern more clear. The main problem was to recognize, that even the timer-event related code [naturally] has to be moved into the concrete state-classes!!!!! The other problem was, that several concrete state-classes have to implement the same code. This code than, was moved again, back to the EventCollector class itself. In this case, it plays more a role as a programming-library for the state-classes. The methods are the same like the methods, which is offered by the EventCollector class as part of the public interface, but naturally different. They carry all the same name, but written in lowercase, while the public methods use the usual convention and starts with an uppercase letter [So we have Start() and start() for example].
  • Since the first version based on the new statemanagement was basically running, a new version V31 was started to make the details.
  • The EventCollector.startTimer and EventCollector.startTimer methods were removed and the timer is now always running, but acting only on several states.
  • The EventCollector.SendKeepAliveMessage method was removed from the public and so from the remoting interface.
  • The EventCollector.IsEventSourceRegistered method was removed to simplify the class. Instead, EventCollector.RegisterEventSource is called each time, a connection was made. This could be a small performance catch, but doing the connection will be rarely called, mostly on starting the service.
  • The EventCollector.RemoveEventSource method was removed to simply this class. Better is to implement this functionality as a separate exe-tool.

  • Several huge steps were processed:

    • Several new versions were developed and tested, but were not very helpful to simplify the state-handling inside the EventCollector.
    • The complete turn was from V23 to V30.
    • V27 was a useful step forward and is a working example, of how re-animating lost connections could be implemented, but, to this point, without using the state-pattern.
    • The last decision in this change-cycle was, to study the state-pattern again and this time, I was a bit more successful than before. A new and more clear state-transision-table was build and based on this, a state-mechanisme was implemented, based on the state-pattern. Starting from this, all state-handling is now based on a new class, the CollectorState, which is a member of the EventlogCollector itself. The CollectorState is the base-class for all concrete state-implementations, which are derived from CollectorState. There are different concrete classes, which implements all methods, which are valid for a state. Executing this methods, in turn, results in a new state.
@-0 2004-Mar
  • The CollectorService got a new method:CollectorService.LoadEventCollector. This is just to load ONE entry from the configuration-file and replace the existing Collector instance wit it for the case, that this isntance was misconfigured.
  • The EventCollector has a new method:EventCollector.RemoveEventSource. This is to simplify the management a bit. Via the remoting interface, an administrator can delete the remotely existing EventSource, for example, because the box will no longer be monitored.
  • The EventCollector has two new events:
    • FirstEventlogMessage
    • NoConnection
    and the existing event Message was renamed to EventlogMessage.
    • FirstEventlogMessage

      This event is raised for each eventlogmessage received after each [also the first] start of an instance. This allows the CollectorService to determine the first and latest messages received and advice a [TBD] EventlogReader class to pull all events between these two timestamps and store them into the DB, if the flag allowReadingStoredMessagesAtStartup [from ServerService.Config.StaticConfig class] is set.

    • NoConnection

      This allows the ServerService to directly notify an administrator, if a connection to a box was lost.

  • The EventCollector now starts using System.DirectoryServices to establish a secure channel to the remote machine. Within this context, the EventSource can be created. This was verified with a small separate exe-tool.
  • V0.23 is a first version with basic re-animation working, but offers security problems for non-trusted connections. This version is now frozen and V0.24 continues.
  • Because of the growth of the EventCollector class, methods which are bigger are now build as static class members to shrink runtime-requirements. The methods are:
    • PrepareWQLQuery
    • SendKeepAliveMessage
    • ManagementBaseObjectToEventlogMessageRecord
  • The EventCollector's state is now only maintained in this class itself. The cost is, that each instance now has it's own timer.
  • In V0.22, the main changes to the CollectorService was to run the CollectorService.BuildEventCollector method on a separate therad, because instantiating the EventCollector was too expensive, because in it's constructor, the connection to the remote machine was created, which could fail and block the constructor.
  • The EventCollector.IsEventSourceRegistered fails with Access denied error, if the remote box is not on the same domain and credential have to be specified. There is currently a lack......
  • The EventCollector.EventCollector connects directly to the remote machine, which is very time expensive, if this machine is currently not reachable.
    The EventCollector.EventCollector uses the IsEventSourceRegistered method to determine, if a connection to the remote box is available.
  • The CollectorService has now only two timers, one for updating the statistics, one for writing current Collector stati into the local eventlog.
  • The CollectorService does no longer expose methods to manage individual Collector's;The Collector is already available as the class's indexer. Also all ALLxxx-methods have been removed.
  • Version 0.21 invalidated by chaotical changes ;-)
@-1 2004-Feb
  • UserInteractive, from System.Environment added to the startup-info.
  • New:Writing the StartupSummary to the local eventlog and introducing an additional timer for this.
  • CollectorService:The timers are now initialized in method Init() then in the constructor.
  • Collector:In OnEventArrived, there was a wrong catch-block. The catch is now to handle errors in ManagementBaseObjectToEventlogMessageRecord(mbo).
  • CollectorService:Locking the whole class is not necessary in OnMessage;removed.
  • The property instanceIdentifier added to the ECS.ServiceApplication.Config.xml [class ECS.ServiceApplication.Config.StaticConfig].
    This is used to define the keepAliveMessage as a string, unique for the running instance to allow tests with another instance on the same machine and to allow detection of each's keepAliveMessage.
  • Collector:The method Reset() removed.
  • CollectorService:The method ResetAllEventCollectors(), ResetEventCollector(), StartAllEventCollectors() and StopAllEventCollectors() have been removed.
  • Collector:There was a code-part to decode the WMI Type, which is a string, as an integer to allow to store an integer into the DB instead of the string. All Windows NT versions before Windows 2000 SP3 have a wmi-design-bug:The Type is a localized string. Since Windows 2000 SP3, the EventType from WMI is available and is an integer. The code-part mentioned was to map between the strings and the integer value and allows to store the integer into the DB instead of the string-value.
    This code-part is removed and all configuration-files are changed as follows:
    • The service-configuration now reads an array named eventTypeNames which allows to configure, from which language the names are translated.
      Regard:Only one language can be translated and this is global.
    • This array is passed into the Collector dynamic configuration and the code-part mentioned has changed to lookup in this array, where the index of the array is the EventType.
  • CollectorService:BuildQuery removed from the class and inserted as FilterHelper.BuildQuery in the Structures assembly. This is more clear and simplifies the CollectorService.
  • Collector.Config.Dynamic and Collector.Config.Static are now melted together to Collector.Config[.cs/.dll].
  • In CollectorService:BuildEventCollector(), each collector was added to the list of collectors, after the collector was created/started. This could fail, because there is no other check of uniqueness of collector-names. So adding the collector to the list is now done in CollectorService:Init(), but only adding it's name, with a following update at CollectorService:BuildEventCollector() to insert the collector-instance itself.
  • The ApplicationService now logs more information in the startup-phase:The running users identity, the process ID and the thread ID.
  • The EventlogFilter and all derived classes implement IComparable because later, in combining local filters [specific to an individual collector] and global filters [to apply to all collectors] they must be comparable to be able to remove filters which are declared both, on the collector and and global.
  • Applied global filters.
  • Prevent a collector to use credentials, if the name localhost was used in the config-file.
@-2 2003-Dec
  • Split the service-application, the server-service and the collectors in separate classes and modules.
@-3 2003-11-12
  • Implement a rudimentary basic version, which shows just some ideas.

mb, jan 2004, manfred.braun@manfbraun.de

›