SentryOne Components and Architecture

Overview

SentryOne Components

SentryOne consists of the following components:

ComponentPurpose
SentryOne ClientProvides a thin client interface for viewing and managing collected information.

Associated application services and processes: 
  • SentryOne Client.exe
SentryOne Monitoring ServiceCollects event metadata and historical information for the monitored device(s).

Associated application services and processes:
  • SQLSentryServer / SentryOne.App.MonitoringService.exe
  • SQLSentryServer / SentryOne.App.DiskSynchronizer.exe
SentryOne DatabaseA SQL Server database that stores event metadata and historical information collected by the SentryOne monitoring service.
SentryOne ControllerWhen using EPI, this service controls the SentryOne services, allowing them to be managed remotely. It must exist on all machines where a monitoring service, portal service, or client is installed for the EPI version of SentryOne.

Associated application services and processes:
  • SentryOneController / SentryOne.App.ClientBootstrapper.exe
  • SentryOneController / SentryOne.App.ServiceBootstrapper.exe
SentryOne Monitor PortalIf using the self-hosted version of SentryOne Portal, this service runs on the machine where the portal is installed.

Associated application services and processes:
  • SentryOneMonitorPortal / SentryOne.Monitor.WebClient.Web.exe
Miscellaneous processes & services (things that may need to be added to a safelist in your security software, if applicable)
  • SentryOne Report Viewer / SsrsViewer.exe
  • SQL Sentry Scheme Handler / SqlSentrySchemeHandler.exe
  • Startup Wizard / SqlSentry.StartupWizard.exe
  • Service Configuration Utility / SentryOne.App.MonitoringService.Configuration.exe

Notes

One SentryOne monitoring service is typically required for every 50 to 100 monitored targets. 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.
  • All SentryOne monitoring services and clients connect to the same SentryOne 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. See the Watched Target Objects article for details on which database objects are placed on a watched SQL Server target.
  • There are times when the SentryOne client connects directly to the watched targets (monitored servers). For more information about when that happens, and how it can be secured, see the Client Security article.

SentryOne Architecture Examples

Overall Example

SentryOne ArchitectureSentryOne Architecture Example

Example with SentryOne Portal and EPI

When using the EPI version of SentryOne, the components remain the same, but there are controller services and bootstrappers associated with some components. For example, when the SentryOne client is installed via EPI, it includes the client bootstrapper which allows for updates to be pushed out automatically to the clients during the upgrade process.

SentryOne SQL Sentry Installed Software Components and ArchitectureSentryOne architecture example with SentryOne installed across multiple machines (with EPI components when applicable)

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 (All Targets 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.