The Basic Idea
When monitoring do not mistake components for services!
=> When configuring Nagios checks we almost always do.
How is SpurTracer Different?
This schema explains the main differences:
|Nagios, Munin, HP OM, Tivoli||Monitoring tool pulls status using agents or agents do push status.||Active||Services||Manual|
|SpurTracer||Your software pushes notifications to SpurTracer monitoring.||Passive||Components||None|
We believe the important difference between SpurTracer and many other tools is
- the object type monitored
- and the monitoring control flow direction.
Advantages of SpurTracer
Choosing a different monitoring architecture allows SpurTracer to...
1. Focus on Components -> Detect Interface Failures
SpurTracer monitors components that actively report their status and especially which interfaces they use. This allows SpurTracer to detect interface failures.
2. Auto-Discovery -> No Configuration
Instead of configuring services and services groups as in Nagios SpurTracer does collect notifications and automatically builds an internal representation of the host systems and the deployed and active components. This allows SpurTracer to perform non-functional tests by checking for abberations from the average component behaviour.
3. Interface Tracking -> Interface Performance Metrics
Using special notifications from your software components (called 'interface announcements') SpurTracer can detect active interfaces in your system and track performance metrics. This is not possible with an agent based monitoring.
4. Stop Building Deep Inspection Checks for Nagios
When solely relying on Nagios you'll find writing complex service check scripts often accessing your DB to detect failures or perform complex calculations to get performance metrics. By integrating SpurTracer into your SW components such scripts won't be necessary anymore as SpurTracer easily integrates with Nagios.