Writer instructions | |
---|---|
Page title | For most spaces, this page must be titled Space announcements. For spaces with localized content, this page must be titled Space announcements l10n. |
Purpose | Provide an announcement banner on every page of your space. |
Location | Move this page outside of your home branch. |
Guidelines |
TIBCO EMS policies
Policy and Event Pack Content
This particular Policy and Event Pack contains a series of Triggers, Action Pipelines, and Templates for detecting and notifying you of events related to TIBCO EMS technology as monitored by MVMM. While this documentation does not provide true documentation of each trigger, a few words on naming conventions should help you to understand.
The heart of the Policy and Event Pack is a series of Triggers to detect various key conditions on TIBCO EMS objects as monitored by MVMM. The naming convention for Policy and Event Pack Triggers is Technology_ObjectType_TriggerCondition.
For each Trigger, there are three provided Templates offering different notification mechanisms. Templates of the form TriggerName_BEM will send an event message (via msend) to BMC Event Manager when the TriggerName condition is met. Note that this uses the BEM_Generic Action Pipeline and does require the configuration of the integration between the MVMM Server and a BEM Cell in order to operate. Templates of the form TriggerName_Console will produce an alert in the Middleware Monitor Console Event pane when the TriggerName condition is met using the standard consoleAlert Action Pipeline (part of the base MVMM product). (Note that some triggers use Delta conditions that preclude the use of Console Alerts. For those triggers, no TriggerName_Console template is provided.) Finally, templates of the form TriggerName_LogToFile will append an event message to the specifiied log file (logToFile_Generic.log in the MVMM home directory by default) when the TriggerName condition is met.
Event Triggers and Templates
There are many triggers and templates, to obtain a list of the triggers and templates contained in this zip use the following command being careful to use the -n option to prevent an actual import. It is recommended you redirect the output to a file and use an editor to search for desired triggers or templates. Both the triggers and templates follow a naming convention beginning with EMS_<object type>_<trigger condition>.
Agent Policies
- MVMQ_Agents_ALL_BEM
- MVMQ_Agents_ALL_EMail
- MVMQ_Agents_ALL_LogToFile
- MVMQ_Agents_Basic
- MVMQ_Agents_Minimal
- MVMQ_Agents_Standard_BEM
- MVMQ_Agents_Standard_EMail
- MVMQ_Agents_Standard_LogToFile
Using the Policy and Event Pack
The Event Pack contains a zip file produced by mqsexport. To use the Event Pack objects, run the mqsimport command. Depending on which portions of the Event pack you want to use, the command may vary. It is assumed that you will have knowledge of the mqsimport command to customize, but below are some sample commands:
To import the entire Event Pack, use the following command:
mqsimport --policy-read-only Samples/EventPacks/EMS/EMS_EventPack.zip SATo import no policies and all the event triggers and templates, use the following command:
mqsimport --event-template EMS_.* --event-trigger EMS_.* Samples/EventPacks/EMS/EMS_EventPack.zip SATo import all templates and triggers for a specific object type, use the following command (sample for a Server):
mqsimport --event-template EMS_Server.* --event-trigger EMS_Server_.* Samples/EventPacks/EMS/EMS_EventPack.zip SATo import all triggers but only the templates associated with a particular action, use the following command (sample for BEM):
mqsimport --event-action-pipeline .*_Generic --event-template EMS_.*_BEM --event-trigger EMS_.* Samples/EventPacks/EMS/EMS_EventPack.zip SATo import one specific trigger and template, use the following command (sample for EMS_Server_Down_BEM):
mqsimport --event-action-pipeline BEM_Generic --event-template EMS_Server_Down_BEM --event-trigger EMS_Server_Down Samples/EventPacks/EMS/EMS_EventPack.zip SA
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 MVMM-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 Policies-and-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.
Where to go from here
Once you have identified and found the Policy and Event Pack refer to the appropriate details in the Policies supplied with MainView Middleware Monitor, which includes instructions for importing and a more in depth description of the content.