Using alerts

Alerts are alarms that warn you about situations that need attention. The Get-OMAlert cmdlet retrieves alerts from the specified vRealize Operations Manager server. The syntax of the Get-OMAlert cmdlet is given here. The first parameter set is the default:

Get-OMAlert [-Status <OMAlertStatus[]>] [-Impact <OMImpact[]>]
    [-Criticality <OMCriticality[]>] [-Resource <OMResource[]>]
    [-Subtype <OMAlertSubtype[]>] [-AssignedUser <OMUser[]>]
    [-Type <OMAlertType[]>] [-ControlState <OMAlertControlState[]>]
    [-AlertDefinition <OMAlertDefinition[]>] [[-Name] <String[]>]
    [-Server <OMServer[]>] [<CommonParameters>]

The second parameter set is required to retrieve alerts by ID:

Get-OMAlert -Id <String[]> [-Server <OMServer[]>] [<CommonParameters>]

The -Id parameter is required.

If you use the Get-OMalert cmdlet without parameters, it will retrieve all of the available alerts as shown in the following example:

PowerCLI C:> Get-OMAlert

The output of the preceding command can be very long. This is why I have omitted the output. It might be better to filter the output to receive only the most important alerts. In the following example, we will retrieve only the Critical alerts. For this book, we select only the first alert and format the output in a list view:

PowerCLI C:> Get-OMAlert -Criticality 'Critical' | 
    Select-Object -First 1 | Format-List

The output of the preceding command is as follows:

WARNING: PowerCLI scripts should not use the 'Client' property.
    The property will be removed in a future release.
WARNING: PowerCLI scripts should not use the 'Uid' property.
    The property will be removed in a future release.
ExtensionData   : VMware.VimAutomation.VROps.Views.Alert
Resource        : VM1
Subtype         : Performance
AssignedUser    :
ControlState    : Open
Type            : Virtualization/Hypervisor Alerts
Status          : Active
Impact          : Risk
Criticality     : Critical
StartTime       : 2/2/2017 8:41:28 AM
UpdateTime      : 2/2/2017 8:46:28 AM
CancelTime      :
AlertDefinition : Virtual machine has continuous high CPU
                      usage causing stress
SuspendedUntil  :
Id              : 48dfb8ed-b95d-4c24-a39d-b5e398fcd57f
Name            : Virtual machine has continuous high CPU
                      usage causing stress
Client          : VMware.VimAutomation.vROps.Impl.V1.OMClientImpl
Uid             : /OMServer=admin@vROPs:443/OMAlert=48dfb8ed
                      -b95d-4c24-a39d-b5e398fcd57f/

As you can see in the preceding output, virtual machine VM1 has continuous high CPU usage causing stress. This might be an alert that needs action to be taken. We can solve this alert by increasing the amount of virtual CPUs of the virtual machine.

Retrieving alert definitions

Alert definitions are templates that contain a set of symptoms, recommendations, and actions. When a symptom is breached, an alert with the same name of the definition is raised. The Get-OMAlertDefinition cmdlet retrieves alert definitions from the specified vRealize Operations Manager server. The syntax of the Get-OMAlertDefinition cmdlet is as follows. The first parameter set is the default:

Get-OMAlertDefinition [-Impact <OMImpact[]>] [-Criticality
    <OMCriticality[]>] [-ResourceKind <String[]>] [-AdapterKind
    <String[]>] [-Type <OMAlertType[]>] [-SubType <OMAlertSubtype[]>]
    [[-Name] <String[]>] [-Server <OMServer[]>] [<CommonParameters>]

The second parameter set is required to retrieve alert definitions by ID:

Get-OMAlertDefinition -Id <String[]> [-Server <OMServer[]>] 
    [<CommonParameters>]

The -Id parameter is required.

Without parameters, the Get-OMAlertDefinition cmdlet returns 177 alert definitions in my lab environment. To show you how an alert definition object looks, we will retrieve only the first alert definition and format the output in a list view, using the following command:

PowerCLI C:> Get-OMAlertDefinition | Select-Object -First 1 |
    Format-List

The output of the preceding command is as follows:

WARNING: PowerCLI scripts should not use the 'Client' property.
    The property will be removed in a future release.
WARNING: PowerCLI scripts should not use the 'Uid' property.
    The property will be removed in a future release.
ExtensionData : VMware.VimAutomation.VROps.Views.AlertDefinition
Description   : No data received for Windows platform
AdapterKind   : EP Ops Adapter
ResourceKind  : Windows
Type          : Application Alerts
SubType       : Performance
Criticality   : Critical
Impact        : Health
WaitCycle     : 1
CancelCycle   : 1
Id            : AlertDefinition-EP Ops Adapter-Alert
                    -system-availability-Windows
Name          : No data received for Windows platform
Client        : VMware.VimAutomation.vROps.Impl.V1.OMClientImpl
Uid           : /[email protected]:443/ 
                    OMAlertDefinition=AlertDefinition-EP
                    Ops Adapter-Alert-system-availability-Windows/

As you can see in the preceding output, the type of the alert is Application Alerts, and the subtype is Performance. In the following section, Retrieving alert types , you will learn how to retrieve the available alert types. In the section, Retrieving alert subtypes , you will learn how to retrieve the available alert subtypes.

You can use the parameters of the Get-OMAlertDefinition cmdlet to filter the output by impact, criticality, resource kind, adapter kind, type, subtype, name, and Operations Manager server. The possible values for impact are:

  • Health
  • Risk
  • Efficiency
  • Unknown

The possible values for criticality are:

  • None
  • Information
  • Warning
  • Immediate
  • Critical
  • SymptomBased
  • Unknown

Retrieving alert types

Alert types are categories in which alerts can be divided. You can assign alerts of a certain type to a specific administrator. The Get-OMAlertType cmdlet retrieves alert types from the specified vRealize Operations Manager server. The syntax of the Get-OMAlertType cmdlet is as follows:

The first parameter set is the default. You can use this parameter set to retrieve all of the alert types or to retrieve alert types by name:

Get-OMAlertType [[-Name] <String[]>] [-Server <OMServer[]>]       
    [<CommonParameters>]

The second parameter set is to retrieve alert types by ID:

Get-OMAlertType -Id <String[]> [-Server <OMServer[]>]
    [<CommonParameters>]

The -Id parameter is required.

In the following example, we will retrieve all of the alert types, select only the name and description properties, and format the output in a list:

PowerCLI C:> Get-OMAlertType | Select-Object -Property
    Name,Description | Format-List

The output of the preceding command is as follows:

Name        : Application Alerts
Description : Alerts that indicate problems in application layer
Name        : Virtualization/Hypervisor Alerts
Description : Alerts that indicate problems in
              virtualization/hypervisor layer
Name        : Hardware (OSI) Alerts
Description : Alerts that indicate problems in hardware/operating
              system interface layer
Name        : Storage Alerts
Description : Alerts that indicate storage problems
Name        : Network Alerts
Description : Alerts that indicate network problems

As you can see in the preceding output, there are only five alert types.

Retrieving alert subtypes

Alert subtypes are subcategories in which alerts can be divided. You can assign alerts of a certain subtype to a particular administrator. The Get-OMAlertSubType cmdlet retrieves alert subtypes from the specified vRealize Operations Manager server. The syntax of the Get-OMAlertSubType cmdlet is as follows:

The first parameter set is the default. You can use this parameter set to retrieve all of the alert subtypes, alert subtypes by name, or by alert type:

Get-OMAlertSubType [[-Name] <String[]>] [-AlertType 
    <OMAlertType[]>] [-Server <OMServer[]>] [<CommonParameters>]

The second parameter set is to retrieve alert subtypes by ID:

Get-OMAlertSubType -Id <String[]> [-Server <OMServer[]>]
    [<CommonParameters>]

The -Id parameter is required.

Every alert type, from the preceding section, Retrieving alert types , has the same alert subtypes. However, every combination of alert type and alert subtype has a unique ID.

In the following example, we will retrieve all of the alert subtypes available for every alert type. We will show only the Name and Description properties. The Sort-Object -Unique command is used to remove duplicates from the output. The output is displayed in a list format:

PowerCLI C:> Get-OMAlertSubType | Select-Object 
    -Property Name,Description | Sort-Object -Property 
    Name,Description -Unique | Format-List

The output of the preceding command is as follows:

Name        : Availability
Description : Alerts that indicate the problems with resource
              availability
Name        : Capacity
Description : Alerts that indicate capacity planning problems
Name        : Compliance
Description : Alerts that indicate compliance problems
Name        : Configuration
Description : Alerts that indicate configuration problems
Name        : Performance
Description : Alerts that indicate performance problems

In the second example, we will retrieve all of the available subtypes and show the Name, Id, and AlertType properties using the following command:

PowerCLI C:> Get-OMAlertSubType | Select-Object
    -Property Name,Id,AlertType

The preceding command has the following output:

Name          Id                 AlertType
----          --                 ---------
Availability  Type:15 Subtype:18 Application Alerts
Performance   Type:15 Subtype:19 Application Alerts
Capacity      Type:15 Subtype:20 Application Alerts
Compliance    Type:15 Subtype:21 Application Alerts
Configuration Type:15 Subtype:22 Application Alerts
Availability  Type:16 Subtype:18 Virtualization/Hypervisor Alerts
Performance   Type:16 Subtype:19 Virtualization/Hypervisor Alerts
Capacity      Type:16 Subtype:20 Virtualization/Hypervisor Alerts
Compliance    Type:16 Subtype:21 Virtualization/Hypervisor Alerts
Configuration Type:16 Subtype:22 Virtualization/Hypervisor Alerts
Availability  Type:17 Subtype:18 Hardware (OSI) Alerts
Performance   Type:17 Subtype:19 Hardware (OSI) Alerts
Capacity      Type:17 Subtype:20 Hardware (OSI) Alerts
Compliance    Type:17 Subtype:21 Hardware (OSI) Alerts
Configuration Type:17 Subtype:22 Hardware (OSI) Alerts
Availability  Type:18 Subtype:18 Storage Alerts
Performance   Type:18 Subtype:19 Storage Alerts
Capacity      Type:18 Subtype:20 Storage Alerts
Compliance    Type:18 Subtype:21 Storage Alerts
Configuration Type:18 Subtype:22 Storage Alerts
Availability  Type:19 Subtype:18 Network Alerts
Performance   Type:19 Subtype:19 Network Alerts
Capacity      Type:19 Subtype:20 Network Alerts
Compliance    Type:19 Subtype:21 Network Alerts
Configuration Type:19 Subtype:22 Network Alerts

Modifying alerts

You can use the Set-OMAlert cmdlet to take or release ownership of an alert, suspend the alert by the time specified in minutes, or cancel an alert. The syntax of the Set-OMAlert cmdlet is as follows:

The first parameter set is required to take ownership of alerts:

Set-OMAlert -TakeOwnership [-Alert] <OMAlert[]> [-Server
    <OMServer[]>] [-WhatIf] [-Confirm] [<CommonParameters>]

The -TakeOwnership parameter is required.

The second parameter set is to release ownership of alerts:

Set-OMAlert -ReleaseOwnership [-Alert] <OMAlert[]>
    [-Server <OMServer[]>] [-WhatIf] [-Confirm] [<CommonParameters>]

The -ReleaseOwnership parameter is required.

The third parameter set is required to suspend alerts by the specified time in minutes:

Set-OMAlert -SuspendMinutes <Int32> [-Alert] <OMAlert[]>
    [-Server <OMServer[]>] [-WhatIf] [-Confirm] [<CommonParameters>]

The -SuspendMinutes parameter is required.

The fourth parameter set is required to cancel alerts:

Set-OMAlert -Cancel [-Alert] <OMAlert[]> [-Server
    <OMServer[]>] [-WhatIf] [-Confirm] [<CommonParameters>]

The -Cancel parameter is required.

In the first example, we will first retrieve all of the critical alerts, take ownership of them, display the Name, and AssignedUser property of the output objects:

PowerCLI C:> Get-OMAlert -Criticality Critical |
    Set-OMAlert -TakeOwnership | Select-Object -Property AssignedUser

The output of the preceding command is as follows:

Name                                       AssignedUser
----                                       ------------
Adapter instance Object is down            admin
Adapter instance Object is down            admin
Host has lost connection to vCenter Server admin
Adapter instance Object is down            admin

You can see in the preceding output, that the admin account took ownership of four alerts.

In the second example, we will release the ownership from the alerts we took ownership from in the preceding example:

PowerCLI C:> Get-OMAlert -Criticality Critical | Set-OMAlert
    -ReleaseOwnership | Select-Object -Property Name,AssignedUser

The preceding command has the following output:

Name                                       AssignedUser
----                                       ------------
Adapter instance Object is down
Adapter instance Object is down
Host has lost connection to vCenter Server
Adapter instance Object is down

As you can see in the preceding output, AssignedUser property is now empty.

In the third example, we will retrieve the alerts for the host with IP address 192.168.0.201 and suspend these alerts for 30 minutes. The command only outputs the time until the alert is suspended:

PowerCLI C:> Get-OMAlert -Resource 192.168.0.201 | Set-OMAlert
    -SuspendMinutes 30 | Select-Object -Property SuspendedUntil

The preceding command has the following output:

SuspendedUntil
--------------
2/2/2017 5:58:15 PM

Tip

If you want to cancel the suspension, you cannot use 0 as the value for the -SuspendMinutes parameter. The minimum value is 1.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.
Reset
18.217.203.172