TIBCO EMS policies
EMS_Agents_Minimal
As is typical for Minimal level supplied policies, the EMS_Agents_Minimal Agent Policy registers very limited monitoring. In general, you should use this policy when you wish to control your monitoring manually by selecting individual objects for monitoring. EMS_Agents_Minimal registers the BMM Agent for history collection using the SAMPLE history template and applies the Basic BMM Extension Object Policy (see BMM-self-monitoring-policies). It then has one main Object Policy Group (EMS_POLICY_Minimal), which includes only one Object Policy, which turns on history collection using the SAMPLE history template for all EMS Servers (but no underlying objects).
EMS_Agents_Basic
The EMS_Agents_Basic agent policy applies the same actions to BMM agents and extensions and to EMS Servers as the Minimal level.
However, it adds Basic level Object Policies for Durables, Queues, Routes, and Topics (see below). For each of these, it selects all objects for monitoring and registers them for history using the SAMPLE history template. You should use this policy when you want to ensure that all of your objects are monitored, but you want to configure events on your own.
EMS_Agents_Standard_EventTarget
The Standard level of monitoring is, as always, the general recommendation for normal systems.
Because the Standard level does Events as well as selection for monitoring and history, you need to choose the variant that matches the target (TrueSight Operations=BEM, EMail, or LogToFile) that you want to receive your events. Note that some configuration is necessary (see Event-Packs-overview) to connect to your Event Manager, email server, or log file.
As is normal for Standard level policies, the EMS_Agents_Standard_EventTarget policies apply the Standard level of monitoring against the BMM agents and extensions (see BMM (Self Monitoring) Policies) and then provide a single main Object Policy Group (EMS_POLICY_Standard_EventTarget) with nested object polices.
Just as with the EMS Basic level, these policies apply to Durables, Queues, Servers, Topics, and Routes. Each object policy then provides Policy Actions to register all such objects for history collection using the SAMPLE template and to add a set of events as appropriate for that object type. For example, for EMS, queues (see below), event templates are added to detect high in transit or pending message counts, low numbers of consumers, low inbound and outbound byte rates (note that byte rates are used rather than message rates since message rates are an integer per second and so can often be zero). Note that all thresholds can be customized. A more proactive composite alert is also registered for MsgsNotprocessed (Pending Msgs > 0 and Outbound Byte Rate = 0).
The EMS_Topic_Standard_EventTarget Object Policies are almost identical to those for Queues. The only difference is that the alert is on Low Subscriber Count rather than Low Consumer Count.
The EMS_Route_Standard_EventTarget Object Policies alert on the route stalled and low inbound or outbound rates.
The EMS_Durable_Standard_EventTarget Object Policy alert on disconnected or high pending message count/size.
The EMS_Server_Standard_EventTarget Object Policies alert on many conditions (see below).
EMS_Agents_ALL_EventTarget
The ALL Level of EMS monitoring adds many more alerts on Queues, Topics, Routes, and Servers. Of particular note are upper thresholds on all Rates (Inbound and Outbound, Byte and Message). No new alerts are added for durables.
Most significantly, the ALL Level adds monitoring and alerts on Application Level (Client Connection, Connection Factory, Consumers, Consumer Destinations, Producers, and Producer Destinations) and Dynamic Objects (Queues, Topics, and Durables). Each of those is contained in a nested Object Policy Group (EMS_Applications_ALL_EventTarget and EMS_Dynamic_Objects_ALL_EventTarget respectively).
Further, events and monitoring are added for System Connections and Route Destinations. Those are just additional Object Policies added to the parent. Note that it is generally not recommended to simply turn the ALL Level on in a production environment. Rather, turn it on in a controlled development or testing environment to understand the scope of what is available and then trim it back before implementing.