Unsupported contentThis version of the documentation is no longer supported. However, the documentation is available for your convenience. You will not be able to leave comments.

Time frame and blackout policy creation best practices

This topic discusses the best practices for creating time frames and blackout policies.

Best practices for creating time frames

Establish a standard and provide meaningful names for time frames. Include an abbreviation for the actual time frame in the time frame name.  For example, a time frame that starts at midnight on Friday night and ends at midnight Sunday night can be named “Weekends.” If a time frame is related to a specific maintenance period for a specific application, include an abbreviation of the application name in the name as well as a representation of the actual time period for the time frame.

Provide a complete description for each time frame and put the information with the maximum impact at the beginning of the description.

Do not create unnecessary time frames. For example, if you never intend to use a time frame that covers 100% of the time, do not create a time frame for “24x7.”  The reason for not doing this is to help avoid mistakes as the time frame can be accidentally applied. 

Avoid creating overlapping time frames to avoid confusion.

Note

Time frames based on start and end times cannot “span across” midnight. If you need to set up a time frame that spans midnight, you must set it up using the duration-based time frame capability. For example, if you want a time frame that starts at 6:00 P.M. on Saturday night and ends at 6:00 A.M. Sunday morning, create a time frame as shown in the following screen shot.

timeframe_duration.png

Best practices for creating blackout policies

  • Blackout policies apply to PATROL Agents and the related data collection, events, and recovery actions. They do not apply to the behavior of the BMC TrueSight Infrastructure Management Server. The following are best practices for blackout policies:
  • Establish a standard and provide meaningful names for blackout policies. Include an abbreviation for the managed technology and/or agent domain and/or applications that the blackouts apply to.
  • Provide a complete description for each blackout policy and put the information with the maximum impact at the beginning of the description.
  • Follow the recommendations for precedence values.
  • Do not create time frames as part of the blackout policy creation process. Although this feature is available, time frames must be defined and created before creating blackout policies.
  • Avoid creating overlapping blackout policies as much as possible.

Notes

  • The time frame for blackout policies is applied according to the PATROL Agent local time. For example, a blackout set for 3 A.M.– 6 A.M. and applied to four agents (2 PDT, 2 EDT) makes the PATROL Agents in US Eastern Daylight Savings Time (EDT) go into blackout 3 hours before the two PATROL Agents in the US Pacific Daylight Saving Time (PDT).
  • Blackout policies do not work with the remote monitoring OS Knowledge Modules and Knowledge Modules that are not Infrastructure Management 9.6 compliant. Use event management blackout configuration for scenarios such as these. Additionally, you can use event management blackout capability for all blackouts as your standard blackout methodology.

Related topics

Creating-a-blackout-policy

Creating-a-time-frame

Monitoring-configuration-best-practice-reference

 

Tip: For faster searching, add an asterisk to the end of your partial query. Example: cert*