|
 |
Local vs Remote Monitoring |
|
|
|
|
| |
When you're looking to implement a monitoring solution, efficiency is key. The solution mustn’t overload your server & it mustn't cause
your existing systems to slow down ... yet it must also be capable of operating
in more hostile conditions, when problems are being encountered. It must also be
easy to configure and, as far as possible, be easy to understand, rather than
requiring a whole team of people to "monitor the monitor".
With Sentry-go from the outset, we have designed the system with issues such as
these in mind.
|
Monitoring Overhead
|
|
|
|
One of the most often asked questions is what overhead does running Sentry-go have ? The answer is
obviously dependent on what you're asking it to do, but in basic terms, the
monitoring service normally has little or no noticeable impact on your system.
Designed specifically to "sleep" when not required, monitoring components work
only when needed and for the length of the check being performed.
|
 |
All monitors are designed to minimise network traffic. Typically they only
access the network when absolutely necessary, either to perform a monitoring
task that requires network access, to send an alert or when responding to remote
communication.
|
Local vs Remote Monitoring
|
Sentry-go operates primarily on a local "per server" or "per desktop" basis.
In some cases, the reason is more obvious - e.g. the Desktop Error Monitor
checks windows displayed on the local desktop and hence operating locally is
required.
In others, the decision was made for other reasons - some of which are
described here.
|
 |
|
Minimal Network Overhead
|
Remote solutions implicitly require network access to perform their tasks, whereas a local
solution puts far less strain, if any, on the network.
With Sentry-go server monitoring, only the checks that require network access use it, along with
alerting & web reporting etc. By minimising network traffic, less load is typically placed on your network
- especially important if your network is often under stress or uses slower
links such as a WAN.
|
|
Security |
Performing remote actions often means allowing a remote user or machine access
to your resources. This not only exposes a weakness in the configured user account, but
also means your firewall protection may be compromised. In a DMZ, access may be
forbidden meaning a remote solution cannot operate from outside the zone. By
running locally, all these potential issues are avoided.
|
|
Flexibility & control of the monitoring process
|
By running locally, external factors do not typically
effect monitored results or responses.
|
|
Automatic Responses
|
Local monitoring provides an ideal base for automatic responses,
which allow the monitor itself to take action when faults are detected without user intervention, or the need for more
complex remote control-style software.
|
No single point of failure
|
A central solution implicitly creates two points of failure – the
monitoring machine and the network connecting it to the monitored machines. Running locally removes these limitations. |
|
|
|
Retaining Centralised Benefits
|
Of course, there are also benefits in having a
centralised solution. When it comes to
the overall management of the monitoring system
for example, it much easier to run things centrally. With Sentry-go, we've also taken
this into account.
|
Control tasks & access alerts
from a single location |
The Sentry-go Client Console provides an easy all-in-one client solution
to all your monitors. With it you can access & configure each monitor
directly
from your desktop, as well as review alerts from them, as they occur in
real-time.
You can also alert to e-mail
queues (e.g. a support/monitoring user) and/or log details to a central file or
database.
You can also alert to e-mail
queues (e.g. a support/monitoring user) and/or log details to a central file or
database.
Find out more about the Sentry-go Client Console
|
I can ensure the monitor
itself is functioning from a
single machine
|
The Client Console lists the status of each registered monitor, either local or
remote. If a monitor's status changes - maybe due to a network failure for
example, you'll be alerted to it.
The Enterprise Option allows status & alert information to be captured to a
central SQL Server database & further accessed through dedicated web reports.
This gives you an immediate enterprise view of the entire monitored environment
as well as spot trends in errors etc.
Find out more about the Enterprise Option
|
I only have to configure
my checks once |
With Sentry-go, you have the flexibility
of either setting up unique
configurations on a per server basis, or creating a single configuration and replicating parts or all of it to other
monitors using client tools.
|
|
Installation & Updates |
With Sentry-go, we’ve made the installation
& setup process as quick & easy as possible. It would also be possible to
automate the Setup process if required.
Once installed, updates can be applied centrally using the Remote Update Wizard. Simply upgrade a single monitor
& you can upgrade the others automatically based on the new files, quickly &
easily.
Find out more about the Remote Update Wizard
Find out more information ...
See the
Getting Started Guide
See
Sentry-go Installation Types & Examples |
|
|
|
|
|
|