The serviceapplication is the most complicated part of this set
of applications. Globally, it is responsible to collect the events
from a configured number of machines, servers or even workstations.
Internally, it consist of - technically spoken - a lot of classes
programmed in the C# language from the
The main classes are:
The CollectorService is invoked and initializes - and
possibly creates - a
For each event received by
The CollectorService has an interface, which enables
access to internal data by remote access, in the
The rest of the job is done by the DBWriter.
Tracking state is probably always a not to simple thing. This is
also true for running
The EventCollector uses an internal timer, which fires at a specified interval. Additionally, the last received message is remembered also. If the next timer event is received, it is checked, if there was a message since the previous event. If there was none, the internal state is set to <suspect>. Each new message resets this state back to <online>. If a new timer-event is received, the status is checked again. If the status is already set to <suspect>, the status is advanced to <waitconfirm>. Importent:This moment the EventCollector writes also a message to the remote machines eventlog!! Because it has adviced the remote machine to deliver new messages from the eventlog, it must get it back! If the next timer-event fires, the status will be set to <unreachable> and the collector will be stopped and restarted. But if the send message was received, the status was reset to <running>
The behavior is by design, just to ensure, each query remains running. As a small side-effect, you'll see the EventCollector's EventCollectorServiceNotificationMessage0 in the remote machines eventlog. This message may be suppressed and does usually not go to the event-database.
This application starts and looks for messages in the
Each received new message in held in memory, although
this gives some risks. If a short period of time has
gone, all collected messages a stored into the
This web-application part is the newest part and a more detailed description can currently not be given here, but a few infos.
The web-application is implemented by ASP.NET. If the user is already
ntlm-authorized, it starts checking
if the user has the right browser and only
The application consist mainly of - like you have possibly already seen - three components:
You'll find more details about this three components inside this documentation, start looking at The Application Parts.
The application is currently completely in beta-state and there are really some bugs. Feedback about each issue is really wanted, see also the Feedback-page.
The application was build with maintenance in mind. But this
is mostly the database, which may go offline for some time.
But this is naturally not true for the