Monitors are entities that are used to collect system data. Synthetic monitors have one or more simulated user transactions or resource checks associated with them. They forward received data along to execution servers. Some monitors correlate directly with individual Silk Performer projects in a "one-to-many" relationship (the user, transaction, and script attributes of a single Silk Performer project can be tweaked to create multiple monitors with different attributes). Some monitors, such as simple URL checkers, are not associated with Silk Performer projects.
Execution servers are the software entities that execute Performance Manager monitors.
Locations are the physical sites where execution servers are housed. When multiple execution servers are present at one physical location, the Performance Manager engine alternates monitoring between the servers based on load balancing algorithms. Monitors are not tied exclusively to individual locations (and by extension not to individual agents). They can be run from multiple locations simultaneously. Transactions are scheduled based on locations, not on individual execution servers, so the number of available execution servers at a location does not affect the number of times that a transaction is run at that location.
Locations are logical containers for execution servers. Since Performance Manager supports worldwide distribution PoPs (Points of Presence)-meaning, the global distribution of execution servers-it is desirable to group execution servers into locations.
Transactions simulate client-side business processes. Transactions may be as complex as ordering a book from a web shop, or as simple as opening a Web page. Transactions can (and normally do) have multiple measure points, such as measures for individual page requests in the case of Web business transactions.
Incidents are comparable to error conditions. Incidents are raised when predefined conditions are met (for example, when performance drops below a certain minimum threshold for a certain length of time and a service target violation is triggered).
Conditions define how monitor results are evaluated. They specify the measurements that are relevant to testing. When specified conditions are met at a certain frequency during testing (for example, when a specified threshold is exceeded 25% of the time) an incident is raised. Conditions are the building blocks from which rules are built. Examples include, "accuracy < 100%" and "availability < 100%".
Rules define how errors are raised and what actions Performance Manager performs when incidents occur. Certain incidents may trigger email notifications while other incidents may trigger more advanced actions, such as data captures or calls to mobile phone providers.
Exclusions are scheduled periods of monitor down-time. Typically exclusions are scheduled for periods of system maintenance so that anticipated system irregularities will not be factored into monitoring results. Multiple independent exclusions may be scheduled.
Projects serve as containers for related sets of tasks and results (for example, monitors configured for a common system). Resources such as project managers and analysts are assigned to projects. Projects can only be created and maintained by system- and domain administrators.