| B1 |
2004-Apr |
-
Implement the first version which works as a NT Service.
-
The re-animation has partially to be updated:The EventCollector
uses only one fixed timer-interval for all operations, like determining
the states <suspect>, <waitconfirm> and possibly the
<unreachable>. But this means, if the interval is set to
one hour, the keep-alive message will be sent after two hours [because
there are two states between] and this interval also works while the
state is <unreachable> and continues to be used in this time. One could
find this very ugly and I'll start thinking about two different intervals,
one for all more or less working states and another one for
all more or less error-states. This would allow faster re-connect
after error. Additionally, this would reduce the number of events
to pull from the remote machine, after a re-connect was detected
while the flag readExistingMessagesAtStartup is set.
-
The ServerService needs a method to send an e-mail
for testing purposes, just to verify the settings in the
configuration file.
-
In the ServerService, the defintion of the objectURI
for the remoting management interface has to be setup via
programming. This is due to the fact, that there can be
more than one instance running at the same time, for example,
while debugging.
-
We sometimes receive eventlog messages, even while dipsoing.
The eventhandler must be changed to regard the "isDisposing"
variable.
-
In console-mode, echo the fatal-errors to the console too.
Currently, they are only written to the eventlog.
-
THINK:A EventCollector should log to the eventlog by
raising an event and let the EventCollectorService log the
message into the local eventlog, if needed. This avoids an uncounted
number of EventLog instances [one for each EventCollector].
-
The EventCollector.Config.StaticConfig should get a new
property:Note, which allows an admin to make an annotation
the the configuration of a specific computer.
-
Add a new property, which allows to delete the remote eventlog[s],
after all events have been read.
-
Create a configuration-helper program, which uses a given
datasource and creates the xx.Collector.Static.config
file from it, setting all values to the templates defaults
and using only the computernames from the datasource.
-
EventlogCollector:Add methods to modify [add/del]
partial filter conditions for a collector including to
necessary behavior on this [which would be necessarily
a stop/start sequence].
-
FilterConditions should become enhanced to have
an additional <note> element which describes why.
-
EventlogCollectorViewer:Try to inject the
TableHeadMirror into the original document and try,
if cloneNode is then working!
-
A separate exe-tool should be developed to allow administrators
to remove registered eventsources on remote machines. This
is easier, than handling all the possibilities [as there
are:Computer no longer present in the configuration;Computer
currently not reachable etc.]
-
The larger methods inside the EventCollector class
should become static methods. This would reduce
the memory requirements while loading a large number
of EventCollector objects.
-
Implement all state-changes according the the now
implemented state-pattern.
|
| B2 |
2004-Mar |
-
In the EventCollector, based
on System.DirectoryServices,
a generic EventCollector.CheckDestinationReachable method will
now be provided to remove the
very ugly EventCollector.IsEventSourceRegistered
which implicitely has provided this status!!!
This new method has to respect an established secure channel!!!!
-
Because the does not contain any
WIN32-based security mechanisme, establishing a secure
channel to a remote box, for which credentials have to
be specified, must be based on System.DirectoryServices
which allows to specify username and password. In the context
of a secure channel build on this type of connection,
the reachability of the box can be properly determined and
also the necessary EventSource can be created [It
is always assumed, that the running identity is an administrator
at the destination!].
-
Implement a more clean state in the EventCollector class.
-
Implement the first version which works as a NT Service.
This plan is delayed into the april, because of my inability
to maintain the proper state and reconnecting-algorithme
in the EventCollector.
|
| @-0 |
2004-Feb |
-
Check, which configuration-related classes are useful for the other
components of this application also!Regard:If currently two instances
of the EventCollectorService are running, the DBWriter
needs not only possibly other queues, it also possibly needs another
database and/or another table inside this database!!!!
-
Remove the delayedAutoStart from the Collector's
static configuration;This is not necessary.
-
THINK about the influence of different times on the
computers to watch and also about working over different
timezones!!
-
Implement the statistics.
-
Implement the initial reading of events
stored in a .
Notes:This must be started, after the
query was started successful, because this gives the
timestamp for the latest event to pull. The timestamp
for the first event must be obtained from
the lastMessageReceivedTS of the CollectorStatisticsItem.
-
Check, if all nt-service-names could be defined dynamically.
-
Reduce number of namespaces, reduce number of files.
-
Apply new names to files and for the web, folders also.
-
CollectorService:The whole initializing of the timer-procedures
must move from the constructor to the Init() method.
-
Implement unique eventlogging mechanisme.
-
ECS.CollectorService:Implement clear re-animation for failed
collectors.
-
In console-mode, a separate config-file must be provided as
commandline parameter. This ensures a secure way to have
both versions running concurrently.
-
Looks into my mailbox and/or on MSDN. There was an article, which
points out how to use MSMQ and not loosing the messages in the
case of a computer shutdown. It looks like using transactional queues
is not necessary!!!
According to (sample)
a message can be persisted by:
Message recoverableMessage = new Message();
recoverableMessage.Body = "Sample Recoverable Message";
recoverableMessage.Recoverable = true;
MessageQueue msgQ = new MessageQueue(@".\$private\Orders");
msgQ.Send(recoverableMessage);
So it looks like, one do not need a transactional queue!!!!
The code essence is as follows:
MessageQueue msgQ = new MessageQueue(@".\private$\Orders");
msgQ.DefaultPropertiesToSend.Recoverable = true;
msgQ.Send("This message will be marked as Recoverable");
msgQ.Close();
-
Implement the other eventhandlers for the management query:Disposed
and Stopped and see, what they are for .... ;-)
|
| @-1 |
2004-Jan |
-
Apply global filters, enhanced error-trapping and better re-animation
mechanisme.
|
| @-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.
|