SentryOne Components and Architecture

SentryOne Components

SentryOne consists of the following components:

ComponentPurpose
SentryOne ClientProvides a thin client interface for viewing and managing collected information.
SentryOne Monitoring ServiceCollects event metadata and historical information for the monitored device(s).
SentryOne DatabaseA SQL Server database that stores event metadata and historical information collected by the SentryOne monitoring service.

One SentryOne monitoring service is typically required for every 50 to 100 monitored SQL Servers, Analysis Services instances, SharePoint Servers, or Windows Task Schedulers. Install multiple monitoring services for scalability, redundancy, or to collect information from remote sites. Normally a SentryOne client is installed on each DBA's workstation.

Note:  See the Implementation Examples section of the Recommendations article for additional information on the number of SentryOne monitoring services.

SentryOne ArchitectureSentryOne Architecture Example

Note:  All SentryOne monitoring services and clients connect to the same database.

Important:  SentryOne doesn't attempt to replace SQL Server Agent, Windows Task Scheduler or any other scheduling agents. SentryOne communicates with these schedulers to determine event status and collect history and performance information using a lightweight polling architecture. SentryOne doesn't require installed agents on each monitored target which dramatically reduces associated setup and maintenance overhead of agent-based systems. SentryOne also doesn't install a database on every monitored SQL Server.

Alerting and Response System

For its alerting and response system, SentryOne uses the concept of conditions and actions. Conditions describe the various states of monitored objects in your environment. Configure actions to take place when a condition is met.

All actions work on the principle of inheritance, meaning that an action configured in response to a condition being met at the global level (Shared Groups node in the Navigator pane), is automatically passed down to all applicable objects below it. This allows you to define global actions for the most common issues across your environment once, and have those passed down to every monitored target automatically.

Refine actions at each level as needed to determine what happens in response to events occurring in your server environment. Each instance type supports multiple conditions and actions. 

Configuring actions globally significantly reduces the setup and configuration time required to implement notifications. For example, by enabling the Send Email action for the global SQL Server Agent Job: Failure condition, you automatically receive email alerts for any SQL Agent job failures across your enterprise. The only requirement is that the SQL Server instance and its jobs are watched by SentryOne. For a more detailed explanation of how conditions and actions work, see the Alerting and Response System topic.

Watching Instances and Objects

Throughout this document you'll also see the term Watch used frequently, in the context of watching instances or objects. When you have SentryOne Watch an instance or object through the context menu this simply means that SentryOne begins monitoring it.

Consider the following rules regarding watched instances and objects:

  • When an instance is Watched, SentryOne monitors the instance and fires any applicable conditions for the instance based on its type.
  • When an object is Watched, SentryOne monitors the object and fires conditions for the object based on its type.
  • An instance can be Watched without watching any of its objects.
  • If any object on an instance is set to Watched, the instance is automatically set to Watched.
  • An object and its instance must be Watched to utilize SentryOne's queuing, chaining, and performance monitoring features.