EMC ViPR SRM - Dell · Filtrado en la definición de alerta de cuello de botella borrado de...

EMC® ViPR® SRMVersión 3.7.0.0

Guía de alertas302-002-325

01

Copyright © 2015 EMC Corporation. Todos los derechos reservados. Publicado en México.

Publicado Octubre, 2015

EMC considera que la información de esta publicación es precisa en el momento de su publicación. La información está sujetaa cambios sin previo aviso.

La información de esta publicación se proporciona "tal cual". EMC Corporation no se hace responsable ni ofrece garantía deningún tipo con respecto a la información de esta publicación y, específicamente, renuncia a toda garantía implícita decomerciabilidad o capacidad para un propósito determinado.

EMC2, EMC y el logotipo de EMC son marcas registradas o marcas comerciales de EMC Corporation en los Estados Unidos o enotros países. Todas las otras marcas comerciales que aparecen aquí son propiedad de sus respectivos dueños.

Para consultar la documentación normativa más actualizada para su línea de productos, visite el sitio de soporte en línea deEMC (https://support.emc.com).

Dirección local de EMCEMC Argentina (Cono Sur) Tel. +54-11-4021-3622 www.argentina.emc.com EMC México Tel. +52-55-5080-3700 www.mexico.emc.com EMC Venezuela (Norte de Latinoamérica)Tel. +58-212-206-6911www.venezuela.emc.com

2 EMC ViPR SRM 3.7.0.0 Guía de alertas

7

9

Introducción de alertas 11

Características y conceptos de alertas en ViPR SRM 13

Soluciones empresariales ............................................................................ 14¿Qué es una alerta?.......................................................................................15Consolidación de alertas...............................................................................16Tipos de eventos .......................................................................................... 16Infraestructura de alertas.............................................................................. 17

Base de datos de eventos................................................................ 17Definiciones de alerta ...................................................................................17Ciclo de vida de alerta .................................................................................. 19Eliminación de una alerta para que se vuelva INACTIVA ................................ 20

Informes de alertas y consola de usuario 23

Exploración de los informes de alertas 25

Cambio de la frecuencia de actualización en los informes de alertas.............26Funciones de desglose en informes de alertas...............................................26Visualización de una lista consolidada de todas las alertas ..........................26Búsqueda de un resumen de todas las alertas ............................................. 29Búsqueda de alertas para un dispositivo ......................................................34Visualización de alertas y disponibilidad del dispositivo...............................36Visualización de alertas de alto impacto y cambio de palabras clave de altoimpacto.........................................................................................................37Visualización de dispositivos principales con alertas críticas y configuraciónde la cantidad de dispositivos principales ....................................................39Dispositivos críticos...................................................................................... 40

Cómo marcar un dispositivo como crítico......................................... 41Visualización del informe Watched Devices y desglosamiento endetalles............................................................................................42

Administre las alertas mediante el ciclo de vida de alerta 43

Acciones para la administración de alertas ...................................................44Administración de alertas..............................................................................44Líneas de tiempo para la administración de alertas.......................................46

Informes personalizados 49

Cambio de la frecuencia de actualización en los informes de alertas.............50Adición de nuevas columnas.........................................................................50Cambio del orden de clasificación recomendado en un informe.................... 51

Figuras

Tablas

Parte 1

Capítulo 1

Parte 2

Capítulo 2

Capítulo 3

Capítulo 4

CONTENIDO

EMC ViPR SRM 3.7.0.0 Guía de alertas 3

Filtrado de un informe .................................................................................. 52Cambio de un nombre de columna en un informe..........................................53

Administración de alertas 55

Configuración de la infraestructura de emisión de alertas 57

Configuración de alertas............................................................................... 58Habilitación y deshabilitación de los adaptadores de emisión de alertas...... 59Preserve las personalizaciones de la definición de alerta durante unaactualización.................................................................................................59

Administre y configure las definiciones de alerta 61

Acceso a las definiciones de alerta................................................................62Definiciones de alerta contextualizadas y no contextualizadas......................63Configuración de una definición de alerta .....................................................63Habilitación y deshabilitación de definiciones de alerta................................ 64Cambiar definiciones de alerta......................................................................64

Configuración de una definición de alerta ....................................... 64Edición de una definición de alerta.................................................. 65Cambio de los valores de umbral en una definición de alerta .......... 65Adición de un registro, correo o acción de SNMP de otros fabricantes auna definición de alerta................................................................... 67Agregar SNMP trap a terceros........................................................... 69

Acerca de las definiciones de alerta globales................................................ 71

Notificaciones de alerta 73

¿Qué son las notificaciones de alerta?...........................................................74Configuración de notificaciones predeterminadas por correoelectrónico ...................................................................................... 75

Notificación de alerta predeterminada ..........................................................75Configuración de notificaciones predeterminadas por correo electrónico ..... 76Modificación de los destinatarios, el asunto y el mensaje de una notificación..................................................................................................................... 77Adición de una acción de notificación a una definición de alerta .................. 77Crear una plantilla de notificación................................................................. 79

Proceso de archivado de alertas 83

Base de datos de eventos............................................................................. 84Ciclo de vida de una alerta............................................................................ 84Propiedades de las alertas que afectan el ciclo de vida................................. 87Editar archivos de configuración de proceso .................................................88

Monitoreo y solución de problemas 89

Supervisión del estado de alerta................................................................... 90Archivos de registro para monitorear.............................................................90Uso de un espía de eventos para solucionar problemas de las alertas...........90Utilice el sondeo para solucionar problemas en una definición de alerta.......92

Desarrollo de nuevas alertas 95

Parte 3

Capítulo 5

Capítulo 6

Capítulo 7

Capítulo 8

Capítulo 9

Parte 4

CONTENIDO


Información general acerca del proceso de consolidación de alertas97

Flujo de proceso de alertas comunes ............................................................98Formato de mensaje de evento y trap normalizado ....................................... 99Acerca de las capturas en ViPR SRM............................................................ 100Acerca de Trap de alerta y Traps de borrado de alertas................................ 101

Adición de acciones de Captura de alertas y Captura de borrado deViPR SRM ...................................................................................... 101Formato y descripciones de mensajes de Trap de alerta y Trap deborrado..........................................................................................102

¿Cómo se asignan las severidades de alerta?.............................................. 107Descripciones de los componentes de alertas.............................................108

Crear alertas personalizadas 113

Crear alertas desde SNMP traps ................................................................. 114Flujo de proceso para consolidar los eventos de SNMP trap en alertas...................................................................................................... 114Ejemplo de un trap consolidado en una alerta y borrado................ 115Creación de una alerta personalizada para una captura desde unorigen externo................................................................................118

Crear alertas de eventos que se envían a una escucha ............................... 119El flujo de proceso para eventos externos se envía al puerto deescucha de eventos....................................................................... 119Ejemplo de un evento externo consolidado en una alerta y borrado...................................................................................................... 121Creación de una alerta personalizada a partir de un evento externo...................................................................................................... 125

Crear alertas de métricas recopiladas .........................................................127Flujo de proceso de alertas: eventos de umbral de métrica.............127Ejemplo de métrica recopilada que se consolidó en una alerta.......128Creación de una alerta personalizada a partir de una métricarecopilada .....................................................................................129

Creación de alertas desde los informes calendarizados ..............................130Flujo de proceso para alertar sobre un informe calendarizado........ 130Ejemplo de una alerta de una métrica de informe calendarizado ... 130Análisis de datos de informe ......................................................... 133Creación de una alerta de informe calendarizado........................... 135

Crear definiciones de alerta personalizadas 137

Definiciones de alerta en la consola ........................................................... 138Componentes en una definición de alerta................................................... 138

Acerca de Trap de alerta y Traps de borrado de alertas................... 142Para obtener más información acerca de los componentes y definiciones dealerta.......................................................................................................... 142Creación de definiciones de alerta.............................................................. 143Acerca de Trap de alerta y Traps de borrado de alertas................................ 144

Adición de acciones de Captura de alertas y Captura de borrado deViPR SRM ...................................................................................... 144Formato y descripciones de mensajes de Trap de alerta y Trap deborrado..........................................................................................145

Plantillas y cuadros agrupados....................................................................150Creación de carpetas de definición de alerta............................................... 150Formato de mensaje de evento y trap normalizado ..................................... 151

Capítulo 10

Capítulo 11

Capítulo 12

CONTENIDO


Alertas de la base de datos y caché activo 153

Base de datos de eventos........................................................................... 154Caché activo............................................................................................... 154Propiedades de las alertas en una entrada de base de datos ..................... 154

Temas de desarrollo adicionales 161

Creación de una captura de alerta manual ..................................................162Script para generar alertas aleatorias.......................................................... 162Receptor de condición de error como módulo independiente...................... 163

Receptor de condición de error como módulo independiente......... 163Configuración de receptor de condición de error............................ 164

Filtro de informe para alertas activas en comparación a alertas inactivas.... 166

Configuraciones específicas de dispositivo 167

Configuraciones específicas del dispositivo 168

Configuración de switches Cisco para la consolidación de alertas............... 169Configuración de switches Brocade para la consolidación de alertas...........169Cómo configurar los arreglos VMAX para la consolidación de alertas de estado................................................................................................................... 170Cómo configurar los conjuntos VNX para la consolidación de alertas...........171

Capítulo 13

Capítulo 14

Apéndice A

CONTENIDO


Informe All Alerts........................................................................................................... 27Informe All Alerts (continuación)....................................................................................27Informe Alert Details and Impact Analysis...................................................................... 28Informe Alerts Summary................................................................................................ 29Informe High Impact Alerts.............................................................................................38Informe Top Devices with Critical Alerts......................................................................... 39Alertas para el informe Watched Devices ...................................................................... 41Notificaciones en una definición de alerta..................................................................... 74Filtro para la definición de alerta de notificación por correo electrónico de laconsolidación de alerta................................................................................................. 76Nueva plantilla para las acciones de correo................................................................... 81Flujo de proceso común.................................................................................................98Flujo del proceso de emisión de alertas para eventos de SNMP trap............................ 114Filtrado en la definición de alerta detectada de cuello de botella Brocade................... 116Definición de alerta de Brocade .................................................................................. 117Lista de definición de alertas de Brocade.....................................................................118Filtrado en la definición de alerta de cuello de botella borrado de Brocade.................. 118Flujo de proceso de alertas para los eventos recopilados por una escucha.................. 120Filtrar en una definición de alerta de VNX.....................................................................121Definición de alerta VNX ............................................................................................. 122Eventos VNX en el informe de todas las alertas............................................................124Informe detallado para el evento VNX.......................................................................... 125Flujo de proceso de alerta para eventos de umbral de métrica..................................... 127Filtro para una definición de alerta de métrica recopilada............................................ 128Acciones para una definición de alerta de métrica recopilada......................................129Filtrado en una definición de alerta..............................................................................139Operador en una definición de alerta...........................................................................140Comparador con dos rutas de resultado...................................................................... 140Acciones en una definición de alerta........................................................................... 141Ejemplo de definición de alerta................................................................................... 142

123456789

1011121314151617181920212223242526272829

FIGURAS


FIGURAS


Opciones de usuario para la administración de alertas..................................................44Lista de tareas para configurar la consolidación de alertas ........................................... 58Ajustes de configuración del proceso de transferencia...................................................85Ajustes de configuración del proceso de cierre automático............................................86Ajustes de configuración del proceso de vencimiento....................................................86Datos en un mensaje de alerta Trap............................................................................. 103Datos en los mensajes de Trap de borrado.................................................................. 106Datos en un mensaje de alerta Trap............................................................................. 146Datos en los mensajes de Trap de borrado.................................................................. 149Campos en una entrada de la base de datos de eventos .............................................155

12345678910

TABLAS


TABLAS


PARTE 1

Introducción de alertas

Esta introducción a conceptos de alertas está destinada a los usuarios, administradoresy desarrolladores.

Chapter 1, "Características y conceptos de alertas en ViPR SRM"

Introducción de alertas 11

Introducción de alertas


CAPÍTULO 1

Características y conceptos de alertas en ViPRSRM

Los siguientes temas describen las funciones básicas y conceptos del módulo deemisión de alertas.

l Soluciones empresariales .................................................................................... 14l ¿Qué es una alerta?...............................................................................................15l Consolidación de alertas.......................................................................................16l Tipos de eventos .................................................................................................. 16l Infraestructura de alertas...................................................................................... 17l Definiciones de alerta ...........................................................................................17l Ciclo de vida de alerta .......................................................................................... 19l Eliminación de una alerta para que se vuelva INACTIVA ........................................ 20

Características y conceptos de alertas en ViPR SRM 13

Soluciones empresarialesEl módulo de alertas de ViPR SRM puede contribuir a la eficiencia de la organización en elmonitoreo y administración de objetivos de almacenamiento de datos y estado de lainfraestructura.

Las funciones de las alertas ofrecen soluciones para los siguientes objetivos del negocio:

Consolidación de alertas

Los administradores de almacenamiento necesitan una vista consolidada de todoslos tipos y fuentes de alertas, incluidas, en especial, las alertas de estado de todoslos objetos compatibles en la infraestructura de almacenamiento. El módulo dealertas de ViPR SRM proporciona una vista consolidada y personalizable de todaslas alertas en lo que respecta a estado y disponibilidad de la infraestructura, crucesdel umbral de capacidad para todos los tipos de almacenamiento y recursos, y elcumplimiento de acuerdos de nivel de servicio.

Administración de alertas eficiente

Los gerentes y administradores deben identificar qué alertas críticas son las que seestán tratando activamente, quién las posee y cuáles son las que aún deben serresueltas o confirmadas. Las alertas de ViPR SRM pueden ser una herramienta deadministración para marcar las alertas como confirmadas o propias. Las alertasresueltas (inactivas) descienden en la lista automáticamente sin necesidad derealizar acción proactiva alguna.

Priorización y clasificación de alerta

Los administradores deben buscar entre cientos de alertas para encontrar las másimportantes. Las alertas de ViPR SRM le permiten administrar las alertas mediantesu clasificación, mediante el filtrado de varios atributos, incluyendo propiedad,dispositivo o severidad de las alertas. Las alertas que ya están afirmadas oconfirmadas por otros administradores pueden descender hasta la parte inferior dela lista. Un informe muestra solo las alertas de los dispositivos marcados comoimportantes.

Además de ver los informes de alertas consolidadas, los gerentes de tipos dedispositivos específicos o hasta dispositivos individuales pueden ver informes dealertas desde dispositivos específicos.

Investigación de alerta

Los administradores de almacenamiento necesitan una manera eficiente dedesglosar las causas de las alertas y otras condiciones que puedan influir enaspectos mayores.

Los usuarios pueden hacer clic en una fila en la mayoría de los informes de alertapara mostrar un informe con todos los detalles conocidos sobre una alertaespecífica.

Notificaciones de alerta

Para ciertos tipos de alerta o dispositivos, los administradores requierennotificaciones. ViPR SRM proporciona funciones de notificación configurables demanera completa. Las notificaciones pueden ser en forma de correo electrónico,SNMP traps a un sistema de terceros o la actividad de registro.

Recopilación de alertas inmediatas para la infraestructura de almacenamiento completa

Cada SolutionPack viene con la normalización apropiada de las alertas que serecopilan desde los dispositivos de almacenamiento respectivos. Las alertas se

Características y conceptos de alertas en ViPR SRM


recopilan para los dispositivos descubiertos y aparecen en los informes de alertasglobales, así como también en la biblioteca de informes específica del dispositivo.La consolidación de alertas para cualquier tipo de dispositivo puede activarse odesactivarse en la consola.

Administración de la base de datos de alerta simple y capacidad de archivadoautomático

ViPR SRM autoadministra la base de datos de las alertas, incluyendo el archivadoautomático y la depuración automática de los datos archivados. Los períodos detiempo para archivar y depurar son configurables.

Posibilidades de personalización

Las organizaciones pueden personalizar el sistema de alertas para satisfacer susnecesidades específicas. Las siguientes son algunas de las opciones depersonalización:

l Los administradores pueden cambiar o agregar a acciones de alerta, comoagregar o cambiar las notificaciones, registro y otras acciones.

l Los administradores pueden cambiar los valores de umbral que generan alertas.

l Los administradores pueden cambiar la asignación de la categoría de una alertay crear nuevas categorías de alerta. Las categorías proporcionan una forma declasificar el tipo de alerta. Algunos ejemplos son Disponibilidad, Rendimiento oSeguridad.

l Los usuarios pueden crear umbrales en ciertos campos de datos y generar unaalerta si se supera el umbral.

l Los usuarios pueden personalizar los informes, y diversos informes tienencampos que permiten el monitoreo personalizado.

l Los desarrolladores pueden definir alertas nuevas. Estas alertas personalizadasse normalizan y aparecen en las mismas tablas y están sujetas a las mismasreglas de administración que las alertas inmediatas.

Capacidad de recopilación de otros fabricantes

Los desarrolladores pueden utilizar el receptor de Trap de SNMP o el puerto deescucha de eventos para recopilar y normalizar las alertas desde cualquier origen.

¿Qué es una alerta?Todas las alertas comienzan como eventos, pero no todos los eventos necesariamente seconvierten en alertas.

En ViPR SRM, un evento se refiere a una aparición en crudo, de cualquier tipo, recibida ogenerada de cualquier manera.

Una alerta es una aparición que se normaliza en ViPR SRM y tiene una definición dealerta válida en el Front-end de alertas.

La definición de alerta controla si la alerta está escrita en la base de datos y,posteriormente, aparece en los informes de alertas. La mayoría de las definiciones dealerta incluyen la acción que les permite que la alerta se escriba en la base de datos,pero es posible que las definiciones de alerta incluyan solo acciones de registro, traps aterceros, o notificaciones por correo electrónico.

Solo las alertas que se escriben en la base de datos aparecen en los informes de alertasde ViPR SRM.


¿Qué es una alerta? 15

Consolidación de alertasAlerta de consolidación es la función de ViPR SRM que recopila eventos de variosorígenes y los normaliza en el mismo Formato. de modo que puedan aparecer juntos enlos mismos informes de alertas globales en la Consola de ViPR SRM.

Independientemente del tipo de dispositivo, del origen de evento, del tipo de evento ode si la alerta fue predefinida o es una alerta personalizada, todos los eventosnormalizados se manejan de la misma forma en ViPR SRM. Todos los eventos aparecenjuntos en el informe All Alerts. Los usuarios de la consola pueden filtrar, ordenar yadministrar todos esos eventos desde la misma interfaz y el mismo informe.

Tipos de eventosLa consolidación de alertas recopila y normaliza cuatro tipos de eventos.

Los tipos de eventos compatibles inmediatos son:

Eventos de umbral basados en la métrica

Estos eventos se generan en función de métricas recopiladas por los recopiladoresde ViPR SRM. Si los datos recopilados coinciden con las condiciones en unadefinición de alerta, el evento se convierte en una alerta.

Eventos que se envían a un puerto de escucha

Estos son eventos que se originan fuera de ViPR SRM, como en un dispositivo o unared. El origen envía el evento a un puerto de escucha de eventos de ViPR SRM. Losdatos de eventos se normalizan en función de las reglas de conversión. Si los datosresultantes coinciden con las condiciones en una definición de alerta, esta seconvierte en una alerta.

SNMP traps

Estos son los SNMP traps que se originan fuera de ViPR SRM, como en un dispositivoo una red. El origen envía el trap a un receptor de condición de error de ViPR SRM.Los datos de trap se normalizan en función de las reglas de conversión. Si los datosresultantes coinciden con las condiciones en una definición de alerta, esta seconvierte en una alerta.

Eventos recopilados desde un informe calendarizado

Un usuario de la consola puede crear una alerta en función de los valoresinformados o calculados en los informes. Por ejemplo, suponga que un usuariodesea recibir un correo electrónico cada vez que la capacidad de almacenamientopara un nivel de servicio en particular está por debajo de un umbral. Con funcionesen la interfaz de usuario, un usuario puede configurar una alerta que hagaexactamente eso. Si los datos resultantes coinciden con las condiciones en unadefinición de alerta, esta se convierte en una alerta.

Todos los tipos de eventos anteriores deben coincidir con un filtro en una definición dealerta activa para ser procesados como una alerta. Si una definición de alerta que filtrapara un evento en particular está desaparecida o desactivada, el evento no se convierteen una alerta.



Infraestructura de alertasEl módulo de alertas consta de varios componentes instalados en el Back-endend yFront-end de alerta y en una base de datos separada solo para las alertas.

En la mayoría de las instalaciones, el Front-end de alerta es el Front-end ViPR SRMprimario. Los componentes de Front-end de alerta son los componentes para el usuario:

l Los informes de alertas, que proporcionan a los usuarios listas de alertas, funcionesde administración interactiva y la funcionalidad de desglose de los detalles de cadaalerta.

l Las definiciones de alerta, que definen todas las condiciones que provocan loseventos para que se conviertan en alertas de ViPR SRM. Las definiciones de alertatambién definen las acciones que ocurren como resultado de la alerta, como unanotificación por correo electrónico o una escritura a la base de datos.

El Back-end de alerta es el Back-end primario de ViPR SRM. Contiene el conjunto deprocesos de soporte para la consolidación de alertas y para la escritura de alertas a labase de datos de eventos.

Base de datos de eventosLas áreas de almacenamiento de base de datos de eventos generan datos de Alerta paralos períodos de tiempo configurables.

La base de datos de eventos contiene dos tablas.

tabla genericevents_live

Esta tabla almacena todas las alertas ACTIVAS. El informe All Alerts sobre la consolay todos los informes que son versiones filtradas de aquel se basan en las entradasen esta tabla.

Una alerta ACTIVA es una cuya propiedad Active tiene el valor 1.

tabla genericevents_archive

Esta tabla almacena las alertas INACTIVAS hasta que se purgan del sistema. Losinformes de alertas históricos incluyen las entradas de esta tabla, además de las dela tabla genericevents_live.

Una alerta INACTIVA es una cuya propiedad Active tiene el valor 0.

Para obtener descripciones de las propiedades en las entradas de tabla, consulte Propiedades de las alertas en una entrada de base de datos en la página 154.

Definiciones de alertaPara que un evento pueda dar lugar a una acción, como una notificación por correoelectrónico o ser agregado a la base de datos, debe coincidir con una definición de alertaválida y HABILITADA.

Los SolutionPacks instalan definiciones de alertas predeterminadas correspondientes asu función y dispositivos. Puede crear definiciones de alerta personalizadas.

Una definición de alerta consta de los siguientes componentes:


Infraestructura de alertas 17

Punto de entrada

El punto de entrada es el filtro que define qué eventos se manejan mediante estadefinición de alerta. El filtro funciona en los campos (propiedades) en los datos deevento.

El filtro identifica los eventos mediante la coincidencia de valores en campos dedatos, como un nombre y campo MIB, o un nombre y una métrica recopiladora, o unnombre de evento y un tipo de dispositivo.

Si los datos en un evento no coinciden con ningún filtro en cualquier definición dealerta activada, no se produce ninguna acción adicional para manejar ese evento.No se convierte en una alerta.

Operaciones y condiciones

Las operaciones y condiciones son componentes opcionales en una definición dealerta. Las operaciones proporcionan una manera de manipular los datos demétricas en un evento. Las condiciones prueban los datos y proporcionanresultados alternativos para diferentes acciones.

Una condición comúnmente utilizada es un comparador, que compara el valor de lamétrica del evento contra un valor estático configurado en la definición de alerta.Una técnica común en ViPR SRM es una cadena de comparadores, cada uno utilizaun valor diferente de comparación. Los resultados son una serie de traps SNMP quecrean traps Importantes, Principales, Menores y finalmente un trap de Borrado, todoen la misma propiedad.

Al cambiar los valores del comparador, cambiará la definición de los niveles deseveridad.

Acciones

Las acciones definen lo que debe producirse como resultado del evento. Lasacciones de definición de alerta más común utilizadas en ViPR SRM son lassiguientes:

l Un Trap de alerta, que obtiene el evento en la base de datos de alertas y losinformes de alertas.

l Un Trap de borrado, que borra una alerta existente que tenga las mismascaracterísticas de identificación, como el mismo dispositivo, tipo de dispositivo,severidad y otros campos de identificación.

l Una acción de registro, que obtiene el evento escrito en un archivo de registro.

l Una notificación por correo electrónico, que envía un correo electrónico a lasdirecciones configuradas previamente.

l Un SNMP trap a un tercero, como otro sistema de administración. Además, estasse denominan notificaciones de trap.

¿Por qué debe prestar atención a las definiciones de alerta?Todas las definiciones de alertas predefinidas inicialmente están en estado desactivado.

Nota

Debe ACTIVAR al menos algunas definiciones de alerta antes de ver las alertas en losinformes de alertas.

Las siguientes son algunas razones por las cuales es posible que deba editardefiniciones de alerta:

l Agregar o cambiar las direcciones de correo electrónico en acciones de correoelectrónico existentes.



l Cambiar los valores comparadores enviados que generan alertas críticas,importantes, menores o de borrado.

l Configure la ubicación del archivo de registro y otros parámetros de administraciónde archivos en las acciones de registro existentes.

l Agregar nuevas acciones de correo electrónico, registros o Trap a las definiciones dealerta existentes.

Ciclo de vida de alertaLas alertas se clasifican en MOMENTÁNEAS o DURADERAS. El estado de alerta es ACTIVOo INACTIVO.

Todas las alertas consolidadas, independientemente de cómo ingresen al sistema,ingresan a la base de datos en el estado ACTIVO y son del tipo MOMENTÁNEAS oDURADERAS. El tipo de alerta se asigna en la parte del mensaje de la acción de alertaTrap en la definición de alerta.

Tipo de alerta MOMENTÁNEA

Este tipo se utiliza para hacer que una alerta esté disponible para borrarlamanualmente desde un usuario de consola. A pesar de que las alertasMOMENTÁNEAS generalmente se asocian con las alertas informativas, su severidadpuede ser cualquiera.

Tipo de alerta DURADERA

Este tipo se utiliza para hacer que una alerta continúe siendo ACTIVA hasta quellegue un evento de borrado desde el origen que la convierta en INACTIVA. Losusuarios de la consola no borran manualmente las alertas DURADERAS.

Una acción de borrado a la fuerza está disponible para los administradores.

Ciclo de vidaTodas las alertas, independientemente de cómo ingresaron al sistema, tienen elsiguiente ciclo de vida:

ACTIVA

Una alerta ingresa al sistema como ACTIVA. Las alertas ACTIVAS se almacenan en latabla en vivo en la base de datos y aparecen en los informes Todas las alertas en laconsola.

INACTIVA

Las alertas se convierten en INACTIVAS de diversas maneras. (Consulte la siguientesección). En general, una alerta INACTIVA puede ser afrontada de alguna manera oconsiderada sin importancia y envejece. Las alertas INACTIVAS no aparecen en losinformes Todas las alertas. Están aún está disponibles para los informes históricos yde tendencias.

(archivado)

Después de un período de tiempo configurable, las alertas INACTIVAS se transfierenautomáticamente a una tabla de archivo en la base de datos. Las alertas archivadasestán aún disponibles para los informes históricos y de tendencias.

(depurado)

Después de un período de tiempo configurable, las alertas en la tabla de archivo sedepuran automáticamente. Una alerta depurada ya no está disponible para losinformes históricos o análisis de tendencias.


Ciclo de vida de alerta 19

Eliminación de una alerta para que se vuelva INACTIVAExisten varias maneras de eliminar, o borrar, las alertas de la base de datos y losinformes. Una alerta borrada es una alerta INACTIVA.

Las alertas que se borran se marcan como INACTIVAS en la base de datos de eventos. Lasalertas INACTIVAS no aparecen en el informe All Alerts o en cualquiera de los informesque se filtran desde el informe All Alerts.

MOMENTÁNEA

Una alerta MOMENTÁNEA (informativa) desaparece ya sea manual oautomáticamente como se indica a continuación:

Confirmación manual

Un usuario de consola hace clic con el botón secundario en la alerta en uno delos informes de alertas y elige Acknowledge. Con esta acción, la alerta se vuelveINACTIVA y ya no aparece en los informes de alertas.

Por ejemplo, un host de VMware envía un evento informativo acerca de uncambio de servidor. Un usuario de consola hace clic con el botón secundario enla alerta en el informe All Alerts y elige Acknowledge. La alerta se vuelveINACTIVA.

Archivado automático

Si no se realiza ninguna acción en la alerta por un número configurable de días,la alerta se vuelve INACTIVA y no va a aparecer en los informes de alertas. Elvalor predeterminado para la cantidad de días es 7.

Por ejemplo, un host de VMware envía un evento informativo para un cambio deservidor. Ningún usuario lleva a cabo ninguna acción en la alerta. La alerta sevuelve INACTIVA automáticamente después de la cantidad predeterminada dedías.

DURADERO

Una alerta DURADERA se elimina automáticamente de una de las siguientesmaneras.

Nota

No es posible que los usuarios borren manualmente una alerta DURADERA.Los permisos del administrador permiten la acción de borrado a la fuerza, si esnecesario.

Evento de borrado

Se procesa otro evento que borra el evento existente. El evento de borrado estáasociado al evento original porque contiene un conjunto de valores de campoque coinciden, como el mismo dispositivo, la misma parte, el mismo nombredel evento, la misma severidad y así sucesivamente. La definición de alertadefine qué valores son eventos y cuales son acciones de borrado.

Por ejemplo, un SNMP trap captura un evento en la utilización de la memoria>80%. El evento se normaliza en una alerta SRM. La alerta está activa hasta queotro SNMP trap captura un evento en la utilización de la memoria <60% en elmismo dispositivo. El segundo evento borra el primer evento y la alerta SRMcambia a INACTIVA.



Archivado automático

Si no se realiza ninguna acción en la alerta por un número configurable de días,la alerta se vuelve INACTIVA y no va a aparecer en los informes de alertas. Elvalor predeterminado para la cantidad de días es 7.

Los cambios incluyen que un usuario realice alguna acción de administraciónen la alerta en la consola de, como tomar propiedad o reconocerla. Solo cuandono se produce ningún cambio para la cantidad de tiempo configurable la alertacambia a INACTIVA.

Por ejemplo, un SNMP trap captura un evento en la utilización de la memoria>80%. El evento se normaliza en una alerta SRM. La alerta permanece activadurante 5 días, y, a continuación, un usuario la reconoce. No se realiza ningunaacción adicional sobre la alerta. La alerta permanece activa por otra cantidadconfigurable de días y, a continuación, se vuelve INACTIVA.


Eliminación de una alerta para que se vuelva INACTIVA 21

PARTE 2

Informes de alertas y consola de usuario

Estos capítulos están destinados a los usuarios finales que usan los informes de alertaspara monitorear y administrar las alertas en la infraestructura de almacenamiento.

Chapter 2, "Exploración de los informes de alertas"

Chapter 3, "Administre las alertas mediante el ciclo de vida de alerta"

Chapter 4, "Informes personalizados"

Informes de alertas y consola de usuario 23

Informes de alertas y consola de usuario


CAPÍTULO 2

Exploración de los informes de alertas

Los siguientes temas describen algunos de los informes de alerta de ViPR SRM. Obtengamás información acerca del contenido de los informes, cómo administrar las alertasdesde los informes y cómo personalizarlos.

l Cambio de la frecuencia de actualización en los informes de alertas.....................26l Funciones de desglose en informes de alertas.......................................................26l Visualización de una lista consolidada de todas las alertas ..................................26l Búsqueda de un resumen de todas las alertas ..................................................... 29l Búsqueda de alertas para un dispositivo ..............................................................34l Visualización de alertas y disponibilidad del dispositivo.......................................36l Visualización de alertas de alto impacto y cambio de palabras clave de alto impacto

............................................................................................................................. 37l Visualización de dispositivos principales con alertas críticas y configuración de la

cantidad de dispositivos principales .................................................................... 39l Dispositivos críticos.............................................................................................. 40

Exploración de los informes de alertas 25

Cambio de la frecuencia de actualización en los informes dealertas

Los informes de alertas se instalan con un intervalo preconfigurado de actualizaciónautomática establecido en 60 segundos. Puede cambiar ese valor. Para deshabilitar laactualización automática, cambie la configuración a 0.

Para una pequeña cantidad de alertas, puede reducir el intervalo de actualización aapenas 15 segundos.

Para bases de datos de eventos más grandes (con un número total de alertas activas demás de cientos de miles), es posible que los informes de alertas tarden en cargarse.Además, si dichos informes tienen el intervalo de actualización automática configuradodemasiado bajo, los informes de alertas quedarán inutilizables. Puede aumentar elintervalo de actualización o deshabilitar la actualización automática.

Si la actualización automática está deshabilitada, siempre puede actualizarmanualmente con la función de actualización del navegador para actualizar el informesegún sea necesario.

Procedimiento

1. Vaya al informe cuya frecuencia de actualización desea cambiar y haga clic en EDITMODE.

2. Haga clic en la pestaña Report Details: Pestaña Table.

3. Desplácese hasta la parte inferior y expanda Display Options.

4. Cambie el valor en Refresh interval (secs).

Para deshabilitar la actualización automática, escriba 0.

5. Haga clic en Save.

6. Haga clic en BROWSE MODE para volver a la visualización del informe.

Funciones de desglose en informes de alertasA partir de los informes de resumen, puede desglosar en detalles de alerta individuales.

Los informes de alertas son compatibles con las siguientes funciones de desglose:

l Desde la barra de nivel de resumen y los gráficos circulares, haga clic en una barra oen una sección del gráfico circular para abrir un informe tabular que enumere lasalertas en la categoría resumida.

l De la mayoría de los informes tabulares, haga clic en una fila en la tabla para abrir uninforme detallado para una sola alerta.

Visualización de una lista consolidada de todas las alertasVea una lista consolidada de las alertas activas de varios orígenes de su infraestructura;por ejemplo, de los dispositivos VMAX, VNX Block, VNX File, Brocade o Cisco y desgloselos detalles de las alertas.

En el informe All Alerts se muestra una lista de todas las alertas ACTIVAS generadas apartir de diversos orígenes en la última semana, en un formato tabular. En este informese muestra información importante de la alerta, incluidos la severidad, el tiempo decreación, la categoría, la descripción y el origen. En el informe también se muestra el



dispositivo, tipo de dispositivo, objeto afectado y tipo de objeto para el cual se generó laalerta.

Figura 1 Informe All Alerts

Figura 2 Informe All Alerts (continuación)

Inicialmente, las alertas aparecen en la tabla ordenadas por la severidad y la hora en laque se crearon. Todas las alertas de nivel más alto de severidad aparecen en primer lugarseguidas por severidades menores y en el orden en el que se crearon, con la alerta másreciente en primer lugar.

En el informe All Alerts, puede desglosar una alerta específica y obtener el informe AlertDetails and Impact Analysis de una alerta de interés.


Visualización de una lista consolidada de todas las alertas 27

Figura 3 Informe Alert Details and Impact Analysis

Procedimiento

1. En la consola, navegue hacia Operations > Alerts > All Alerts.

2. Si tiene la función de administrador, puede hacer clic con el botón secundario en unafila de la tabla para administrar la alerta.

3. Para volver a ordenar el informe por los valores de una columna, haga clic en lasflechas situadas en el encabezado de columna.

4. Para abrir el informe Alert Details and Impact Analysis de una alerta específica, hagaclic en la fila de esa alerta.

5. Para administrar la alerta desde el informe Alert Details and Impact Analysis,desplácese hacia al final del informe, haga clic con el botón secundario en la fila de latabla y seleccione una acción.



Búsqueda de un resumen de todas las alertasVea un resumen de tablero detallado de las estadísticas de alertas. En el resumen detablero, desglose las alertas individuales.

Alerts Summary es un tablero en el que se muestran resúmenes gráficos de todas lasalertas en función de las siguientes características:

l Severidad como Critical, Major o Minor.

l Apariciones de alertas por severidad.

l Categoría de mensajes, como Availability, Capacity, Performance o Environment.

l Origen, por ejemplo, Host, PowerPath o Recopilador VPLEX.

l Tipos de dispositivo.

En este resumen del tablero, puede desglosar los detalles de una alerta específica.

Figura 4 Informe Alerts Summary

Procedimiento

1. En la consola, navegue hacia Operations > Alerts > Alerts Summary.

Aparece el tablero Alerts Summary.


Búsqueda de un resumen de todas las alertas 29

2. Desglose los detalles de alertas y administre las alertas en el tablero:

a. Para ver el conteo de alertas resumido en una barra, pase el mouse sobre esta.

En el mensaje de globo resultante se muestra el conteo de alertas que la barrarepresenta.

b. Para mostrar la lista de alertas resumidas en una barra, haga clic en la barra.

Esto hace que el informe All Alerts aparezca, filtrado por los atributos en la barraseleccionada.

c. Para confirmar o tomar propiedad de una alerta, haga clic con el botón secundarioen la alerta y elija una acción.

d. Para abrir el informe Alert Details and Impact Analysis de una alerta específica,haga clic en la fila de esa alerta.

3. Para volver al tablero después de explorar en detalle los informes, haga clic en AlertsSummary, en la ruta de navegación situada en la parte superior de la ventana.

4. Vuelva al tablero y haga clic en el título Alerts by Severity.

El gráfico de barras para Alerts by Severity ayuda a determinar la cantidad de alertasde severidad crítica, grave, menor o desconocida que están ACTIVAS en el sistemapara la semana anterior.

Cada barra representa una severidad diferente.



Nota

No se muestran las alertas de severidad informativa como parte de este informe.

Consulte el Paso 2 para ver las opciones de administración de alertas y de desglose.

5. Vuelva al tablero y haga clic en el título Alerts by Source.

El gráfico de barras para Alerts by Source ayuda a determinar la cantidad de alertasACTIVAS de cada origen de la semana anterior.

Cada barra representa un origen, como el Evento genérico de VMAX o el Eventogenérico de Brocade.


6. Vuelva al tablero y haga clic en el título Alerts by Device Type.



El gráfico de barras para Alerts by Device Type ayuda a determinar la cantidad dealertas ACTIVAS de cada tipo de dispositivo de la semana anterior.

Cada barra representa un tipo de dispositivo, como Array, Fabric Switch y Host.


7. Vuelva al tablero y haga clic en el título Alerts by Category.

El gráfico de barras para Alerts by Category ayuda a determinar las diversascategorías de alertas ACTIVAS que se generaron en la semana anterior.

Cada barra representa una categoría de alerta como Configuration, Operational, Error,Environmental, entre otras.


8. Vuelva al tablero y haga clic en el título Alert Occurrences by Severity.



En este informe se muestra la cantidad de veces que las alertas se produjerondurante la última semana. Una alerta pudo producirse muchas veces.

Cambiada a una visualización por hora, puede identificar las horas durante las cualesla mayoría de las alertas se produjo en un día. Para cambiar a por hora, haga clic enDisplay en la parte superior de la página, cambie Display 1 day values a Displayhourly values y haga clic en Apply.

No hay acciones de usuario disponibles aquí.

9. Puede identificar rápidamente la hora en la cual se produjo la mayoría de las alertasen un día; para ello, cambie el informe para que este muestre los conteos por hora.

a. Haga clic en Display en la parte superior de la página.

b. Cambie Display 1 day values a Display hourly values.

c. Haga clic en Aplicar.



Si pasa el mouse sobre una de las barras, se muestra el conteo de una horaespecífica del día.

Búsqueda de alertas para un dispositivoVea todas las alertas de un dispositivo específico de la infraestructura.

Utilice los informes de alertas de dispositivos específicos para solucionar los problemasde un dispositivo, analizar las tendencias de alertas de un dispositivo o ver cómo ladisponibilidad afecta las alertas.

Procedimiento

1. Vaya a Explore > device_type y, luego, navegue hacia un nombre de dispositivoespecífico. Ejemplos de device_type son Host, Network, Storage o StorageConnectivity > Switches.

En el informe se muestran detalles del dispositivo, seguido de los informes deresumen en un estilo de tablero.

2. En la lista Category, haga clic en Alerts.

Nota

Si Alerts no aparece en la lista, significa que el dispositivo no tiene ninguna alertapara informar.

Aparecen dos gráficos relacionados con las alertas:

l El gráfico Alert Summary lo ayuda a comprender la cantidad de alertas deseveridad crítica, grave, menor, desconocida o informativa para la semana



anterior del dispositivo seleccionado que están ACTIVAS en el sistema. Cadasección de la gráfica circular especifica la severidad.

l En Alert Trend se muestran las tendencias anteriores de todas las alertasentrantes de este dispositivo.

3. Examine el informe Summary.

a. Para mostrar el conteo de alertas de un nivel de severidad particular, desplace elmouse sobre la sección de la gráfica circular a fin de ver el mensaje de globo.

b. Para ver una lista tabular de todas las alertas de una severidad específica de estedispositivo, haga clic en esa sección de la gráfica circular.

Aparece un informe All Alerts, filtrado para este dispositivo y la severidad elegida.

c. Para administrar una alerta, haga clic con el botón secundario en esta y elija unaacción, como Acknowledge o Take Ownership.

d. Para abrir el informe Alert Details and Impact Analysis de una alerta específica,haga clic en la fila de esa alerta.

4. Para explorar las tendencias de alertas del dispositivo, examine el informe Trend.


Búsqueda de alertas para un dispositivo 35

El historial de alertas se muestra como un gráfico de tendencias y se basa en laseveridad. Cada severidad (crítica, grave, menor, desconocida, informativa) serepresenta con un color diferente. Este gráfico muestra la tendencia de todas lasalertas ACTIVAS e INACTIVAS generadas en la semana anterior del dispositivoseleccionado. En este gráfico, puede deducir la cantidad de alertas de un nivel deseveridad particular en un momento específico.

No hay acciones de usuario disponibles aquí.

Visualización de alertas y disponibilidad del dispositivoEl informe Availability Overlay para un dispositivo muestra las alertas en comparacióncon la disponibilidad del dispositivo.

En el informe Availability Overlay se muestra la superposición de apariciones de alertasen el gráfico de disponibilidad. Puede ver de un vistazo si una condición de alerta afectóla disponibilidad. No todos los tipos de dispositivo son compatibles con el informe desuperposición.

Procedimiento

1. Vaya a Explore > device_type y, luego, navegue hacia un nombre de dispositivoespecífico.

2. En la lista Category, haga clic en Availability & Performance.

3. Desplácese hacia abajo para localizar el informe Availability (%) y el informecomplementario Alerts.

Las alertas ACTIVAS se representan como barras superpuestas en las barras dedisponibilidad.

Nota

Cuando hay una gran cantidad de alertas, no todas las alertas están representadas enla superposición.



4. Coloque el mouse en una línea horizontal, en la superposición para ver el mensaje dealerta correspondiente.

5. Haga clic mientras se muestra el mensaje de información sobre herramientas para verel informe Alert Details de esa alerta.

6. Utilice la función Back del navegador para volver a los informes Availability y Alerts.

Visualización de alertas de alto impacto y cambio de palabrasclave de alto impacto

Vea todas las alertas que se consideran de alto impacto. Personalice las frases depalabras clave de alto impacto para satisfacer las necesidades de su ambiente.

Use el informe High Impact Alerts para ver todas las alertas importantes. En este informese muestran todas las alertas activas cuyo mensaje contiene frases que se consideran dealto impacto, generadas en la semana anterior.

El informe filtra las alertas activas en función de frases de palabras clave en el mensajede alerta (la propiedad fullmsg). Para que un mensaje se considere de “impacto alto”, sufullmsg debe incluir una de las frases de palabras clave en el filtro.

El informe listo para usar incluye palabras clave, como no listo, no está disponible, ahoraoffline, fallido y muchas otras. Puede ver la lista de palabras clave en el filtro de informe.También puede editar el filtro para agregar y eliminar palabras clave.


Visualización de alertas de alto impacto y cambio de palabras clave de alto impacto 37

Figura 5 Informe High Impact Alerts

Procedimiento

1. Para ver todas las alertas activas que son de alto impacto, vaya a Operations > Alerts >High Impact Alerts.

2. Para modificar las palabras clave que se filtran por fullmsg:

a. Haga clic en Edit.

b. Haga clic en la pestaña Filtro y expansión.

c. En el campo Filter, revise las palabras clave en las reglas de filtro.

d. Para agregar o eliminar palabras clave, haga clic con el botón secundario en elcuadro de expresiones y seleccione Edit expression.

e. En el cuadro de diálogo que aparece, agregue, modifique o elimine lasubexpersión. Después haga clic en Aceptar.



f. Haga clic en Save en la parte inferior de la pestaña Filtering and Expansion.

g. Haga clic en Browse para volver a la página de informes.

3. Si tiene la función de administrador, puede hacer clic con el botón secundario en unafila de la tabla para administrar una alerta. Por ejemplo, elija Acknowledge o Takeownership en el menú contextual.

4. Para abrir el informe Alert Details and Impact Analysis de una alerta específica, hagaclic en la fila de esa alerta.

Visualización de dispositivos principales con alertas críticas yconfiguración de la cantidad de dispositivos principales

Limite la búsqueda de alertas críticas en su ambiente utilizando el informe Top Deviceswith Critical Alerts. Configure la cantidad de dispositivos principales que desea queaparezca en el informe.

En el informe Top Devices with Critical Alerts se muestran los dispositivos que generaronla mayor cantidad de alertas críticas ACTIVAS en la última semana en un gráfico debarras. Este informe ayuda a determinar qué dispositivos requieren atención según lacantidad de alertas críticas generadas por estos.

Cada barra representa un dispositivo, con el tipo de dispositivo, el nombre deldispositivo y el porcentaje del total que se muestra en la barra. La cantidad dedispositivos que se muestra en el informe es configurable.

Figura 6 Informe Top Devices with Critical Alerts

Procedimiento

1. En la consola, navegue hacia Operations > Alerts > Top Devices with Critical Alerts.

2. Para cambiar la cantidad de dispositivos (número de barras) que figuran en elinforme:


Visualización de dispositivos principales con alertas críticas y configuración de la cantidad de dispositivos principales 39

a. Haga clic en Edit Mode.

b. Haga clic en la pestaña Report Details: TopN Graph.

c. En la sección Settings for TopN Graphs, cambie el valor en el campo Number ofSections.

d. Haga clic en Save en la parte inferior de la pestaña.

e. Haga clic en BROWSE MODE para volver al informe.

3. Pase el cursor del mouse sobre una barra para ver la cantidad de alertas críticasACTIVAS de ese dispositivo y la cantidad total de alertas críticas ACTIVAS del sistema.

4. Para mostrar los detalles de las alertas críticas de un dispositivo en un formatotabular, haga clic en una barra.

La tabla muestra solo las alertas críticas ACTIVAS del dispositivo seleccionado.

5. Si tiene la función de administrador, puede hacer clic con el botón secundario en unafila de la tabla para administrar una alerta. Por ejemplo, elija Acknowledge o Takeownership en el menú contextual.

Dispositivos críticosPuede crear un informe de alertas que contenga únicamente las alertas de losdispositivos que considere importantes y que necesiten un riguroso monitoreo.

Un dispositivo puede ser importante para un centro de datos o para una aplicación. Porlo tanto, cualquier alerta para dichos dispositivos se consideraría de gran importancia.Dichos dispositivos pueden marcarse como críticos y las alertas para esos dispositivosaparecen en el informe Alerts for Watched Devices.

El informe Alerts for Watched Devices muestra todas las alertas activas que se generandespués de configurar un dispositivo como crítico.

Nota

A pesar de que la visualización predeterminada muestra la última semana de las alertas,las alertas que se produjeron antes de marcar el dispositivo como crítico no se muestranen el informe.

El informe muestra todas las alertas que están asociadas a los dispositivos críticos,independientemente de su severidad.

El siguiente informe muestra las alertas para un arreglo VNX que se registró como undispositivo inspeccionado.



Figura 7 Alertas para el informe Watched Devices

Cómo marcar un dispositivo como críticoPuede marcar cualquier dispositivo como crítico con el objetivo de observar las alertasasociadas con ese dispositivo.

Procedimiento

1. Use este método si tiene una lista de nombres de dispositivo que ya está preparadapara copiar y pegar:

a. Haga clic en Administration > Centralized Management > Physical Overview.

b. Expanda el nombre de host Primary Backend.

c. Haga clic en Modules > Event-Processing > Event-Property-Tagger:Alert-Consolidation.

d. En el panel derecho, expanda Configuration Files.

e. Haga clic en Edit para el archivo conf/critical-device.csv.

f. En el editor de texto que se abre, agregue los nombres de dispositivo deseados alarchivo.

g. Haga clic en Save.

2. Use este método para seleccionar nombres de dispositivos individuales de una listagenerada:

a. Navegue hacia Administration > Centralized Management > Data Enrichment.

b. Si aún no lo ha hecho, registre el módulo Event-Processing-Manager, como seindica a continuación:

a. Haga clic en Register a new module.

b. En la lista que aparece, seleccione el servidor Primary Backend, la categoríaEvent-Processing y el módulo Event-Processing-Manager.

c. Haga clic en Registrar.

c. En la tabla Data Enrichment, haga clic en el nombre del servidor Primary Backend.


Cómo marcar un dispositivo como crítico 41

d. Expanda la barra de dispositivo crítico.

e. En la tabla, haga clic en la primera fila de la columna Device Name para exponerun cuadro desplegable y presione la tecla Retroceso para borrar la frasepredeterminada.

La lista desplegable ahora debería mostrar los nombres de dispositivo, ordenadosalfabéticamente.

f. Escriba los primeros caracteres del nombre del dispositivo que desea marcarcomo crítico, lo que genera una lista de valores de coincidencia, y, a continuación,seleccione el nombre del dispositivo deseado.

g. Para seleccionar otro dispositivo, haga clic con el botón secundario en el ícono dela primera columna y seleccione Insert before o Insert after.

h. En la nueva fila, seleccione otro nombre de dispositivo y escriba 1 en la columnaisproblem.

i. Cuando se complete la lista de dispositivos críticos, haga clic en Save.

j. En la pantalla Save Data Enrichment, haga clic en Update.

k. Ahora puede cerrar la pestaña del navegador Data Enrichment.

Visualización del informe Watched Devices y desglosamiento en detallesEn el informeAlerts for Watched Devices se muestran todas las alertas activas de losdispositivos que están configurados como críticos.

Procedimiento

1. Navegue hacia Operations > Alerts > Alerts for Watched Devices.

Nota

Recuerde que solo las alertas que se emiten después de que el dispositivo se marcócomo crítico aparecen en el informe.

2. Si tiene la función de administrador, puede hacer clic con el botón secundario en unadescripción de alerta del informe y elegir una acción de administración, comoAcknowledge o Take Ownership.

3. Para volver a ordenar el informe por los valores de una columna, haga clic en lasflechas situadas en el encabezado de columna.

4. Para desglosar una alerta específica, haga clic en la fila de la alerta.

Se abre el informe Alert Details and Impact Analysis en el que se muestran losdetalles de la alerta.



CAPÍTULO 3

Administre las alertas mediante el ciclo de vidade alerta

l Acciones para la administración de alertas ...........................................................44l Administración de alertas......................................................................................44l Líneas de tiempo para la administración de alertas...............................................46

Administre las alertas mediante el ciclo de vida de alerta 43

Acciones para la administración de alertasLos usuarios de la consola pueden marcar las alertas como confirmadas y tomarpropiedad de alertas. Estas acciones son formas convenientes y opcionales pararastrear, organizar y resolver problemas con las alertas.

Tabla 1 Opciones de usuario para la administración de alertas

Acción Descripción

Reconocimiento Marque la alerta confirmada.

l Cuando se confirma una alerta de tipo MOMENTÁNEA, elestado de la alerta cambia de ACTIVO a INACTIVO. Ya no se

informan las alertas INACTIVAS ni en el informe All Alerts ni enel subconjunto de informes relacionado.

l Cuando se confirma una alerta de tipo DURADERA, esta

permanece ACTIVA y permanece dentro del informe All Alerts ydentro del subconjunto de informes relacionado con Yes en la

columna ACK. Además, automáticamente se asigna lapropiedad al usuario que la confirmó.

Confirmación de laversión

Confirmación de la versión sin afectar al propietario.

Toma de propiedad Toma de propiedad de una alerta sin afectar la confirmación. Otrousuario con privilegios de administrador no puede tomar propiedadde una alerta cuya propiedad ya se asignó. Para ello, es necesario

Liberar la propiedad, cerrar sesión, iniciar sesión nuevamente yluego tomar propiedad. Una alerta específica no puede tener másde un propietario a la vez.

Liberación de lapropiedad

Libere la propiedad de una alerta confirmada para que otroadministrador pueda reclamar la propiedad de esta.

Los administradores tienen dos opciones de administración adicionales.

Acción Descripción

Asignar Establecer el campo de propietario a otro usuario.

Cierre forzado Establecer cualquier alerta como INACTIVA.

Administración de alertasLos usuarios pueden confirmar y tomar propiedad de una alerta.

Procedimiento

1. En la consola, navegue hacia:

l Operations > Alerts > All Alerts.

l Cualquiera de los informes que son versiones filtradas del informe All Alerts y, porlo tanto, incluyen las columnas Ack y Owner.

Administre las alertas mediante el ciclo de vida de alerta


Por ejemplo, el siguiente informe, en Explore > Storage > Storage Systems, es unaversión filtrada del informe All Alerts para un dispositivo y severidad específicos.

2. Desplace el mouse por las palabras en una fila de alerta hasta que el cursor cambie,haga clic con el botón secundario y elija una acción en el menú.

Nota

Si el sistema muestra No Actions Available cuando hace clic con el botón

secundario, significa que su cuenta de inicio de sesión no tiene privilegios deadministrador y, por lo tanto, no puede administrar las alertas.

Los valores de las columnas Ack y Owner no cambian inmediatamente. Si la acción serealiza correctamente, aparece por un momento un mensaje que indica que la acciónse realizó correctamente en la parte superior de la página.

3. Después de una cantidad adecuada de tiempo, use la función de actualización delnavegador para volver a mostrar la tabla.



Tiene que esperar varios minutos para que se descubran los nuevos valores de lacolumna.

Líneas de tiempo para la administración de alertasLa administración de alertas normalmente consiste en el monitoreo de la lista de alertasy en el trabajo con cada alerta de manera adecuada, de modo que esta quede INACTIVA ydesaparezca de la lista.

El informe principal para el monitoreo y la administración de alertas es el informeOperations > All Alerts. Este informe es una lista consolidada de todas las alertasACTIVAS actualmente recibidas en ViPR SRM. Suponiendo que el objetivo principal esmantener el informe All Allerts lo más breve posible, o vacío, los usuarios responsablesquerrán cambiar sus alertas a un estado INACTIVO.

En las siguientes secciones se describen posibles procesos para encargarse de lasalertas y cambiarlas a un estado INACTIVO.

Monitoreo eficienteEl siguiente programa de monitoreo en dos pasos puede encargarse de las alertas demanera eficiente:

1. Los administradores y usuarios pueden usar el informe Alerts > Unassigned Alerts yapropiarse de las alertas o reasignar la propiedad según corresponda.

2. Los usuarios pueden ver su lista de alertas asignadas mediante el uso del informeAlerts > All Alerts y el filtrado de la columna Owner por sus nombres de usuarios. Paraluego poder flotar sus alertas críticas a la parte superior de la lista, pueden ordenarsus listas mediante la columna Severity.

Línea de tiempo para las alertas MOMENTÁNEASEn el caso de las alertas MOMENTÁNEAS, la acción Acknowledge establece la alertacomo INACTIVA. A continuación, aparecerán líneas de tiempo típicas.

1. En primer lugar se produce la alerta.

2. Los usuarios evalúan la alerta y resuelven la situación de la siguiente manera:



Si la alerta nose consideraimportante:

a. El usuario hace clic con el botón secundario en la alerta yselecciona Acknowledge.

b. La alerta se vuelve INACTIVA y desaparece del informedespués de una determinada cantidad de tiempo (un máximode 2 horas).

Si la alertarequiere algúntipo de acción:

a. Se asigna un propietario a la alerta mediante cualquiera deestos métodos:

l Un administrador hace clic con el botón secundario en laalerta y elige Assign y proporciona un nombre de usuario.

l Un usuario hace clic con el botón secundario en la alerta yelige Take Ownership.

b. El usuario abre un vale de problemas en un sistema de otrosfabricantes o, de lo contrario, se encarga de solucionar elproblema.

c. Cuando se ha resuelto el problema o este no se consideraimportante, el usuario hace clic con el botón secundario en laalerta y elige Acknowledge.

d. La alerta se vuelve INACTIVA y desaparece del informedespués de una determinada cantidad de tiempo (un máximode 2 horas).

Línea de tiempo para las alertas DURADERASPara las alertas DURADERAS, el problema debe resolverse en el sistema remoto. Cuandose resuelve el problema, ocurre otro evento que borra la alerta original. Se presenta acontinuación una línea de tiempo típica.

1. En primer lugar se produce la alerta.

2. Se asigna un propietario a la alerta mediante cualquiera de estos métodos:

l Un administrador hace clic con el botón secundario en la alerta y elige Assign yproporciona un nombre de usuario.

l Un usuario hace clic con el botón secundario en la alerta y elige Take Ownership oAcknowledge. En el caso de una alerta duradera, una confirmación tambiénestablece automáticamente la propiedad.

3. El usuario toma acciones correctivas: ya sea abriendo un vale de problemas en unsistema de otros fabricantes o poniéndose en contacto con un administrador pararevisar los componentes de infraestructura afectados.

4. Cuando se resuelve la causa del problema en el componente afectado, se procesauna captura correspondiente o un evento, lo cual establece la alerta como INACTIVA.

5. La alerta desaparece del informe después de una determinada cantidad de tiempo(un máximo de 2 horas).


Líneas de tiempo para la administración de alertas 47

CAPÍTULO 4

Informes personalizados

Los usuarios de la consola podrían ser capaces de aumentar la eficiencia en laadministración y la investigación de las alertas personalizando los informes de alertas.Puede agregar nuevas columnas a un informe, cambiar el orden de clasificación y limitarel contenido del informe mediante la aplicación de filtros.

l Cambio de la frecuencia de actualización en los informes de alertas.....................50l Adición de nuevas columnas.................................................................................50l Cambio del orden de clasificación recomendado en un informe............................ 51l Filtrado de un informe .......................................................................................... 52l Cambio de un nombre de columna en un informe..................................................53

Informes personalizados 49

Cambio de la frecuencia de actualización en los informes dealertas

Los informes de alertas se instalan con un intervalo preconfigurado de actualizaciónautomática establecido en 60 segundos. Puede cambiar ese valor. Para deshabilitar laactualización automática, cambie la configuración a 0.

Para una pequeña cantidad de alertas, puede reducir el intervalo de actualización aapenas 15 segundos.

Para bases de datos de eventos más grandes (con un número total de alertas activas demás de cientos de miles), es posible que los informes de alertas tarden en cargarse.Además, si dichos informes tienen el intervalo de actualización automática configuradodemasiado bajo, los informes de alertas quedarán inutilizables. Puede aumentar elintervalo de actualización o deshabilitar la actualización automática.

Si la actualización automática está deshabilitada, siempre puede actualizarmanualmente con la función de actualización del navegador para actualizar el informesegún sea necesario.

Procedimiento

1. Vaya al informe cuya frecuencia de actualización desea cambiar y haga clic en EDITMODE.

2. Haga clic en la pestaña Report Details: Pestaña Table.

3. Desplácese hasta la parte inferior y expanda Display Options.

4. Cambie el valor en Refresh interval (secs).

Para deshabilitar la actualización automática, escriba 0.


6. Haga clic en BROWSE MODE para volver a la visualización del informe.

Adición de nuevas columnasUn usuario de la consola puede agregar una nueva columna a un informe de tabla.

Es posible que haya información útil disponible en la base de datos que no aparece en elinforme All Alerts predeterminado. Por ejemplo, su empresa podría usar uno de loscampos definidos por el usuario. Visualizar dicho campo en el informe All Alerts puedeayudarlo a administrar su infraestructura.

Este procedimiento cambia el informe para el usuario actual únicamente. Para hacer uncambio que todos los usuarios puedan ver, agregue la nueva columna en EDIT MODE.Consulte el sistema de ayuda del producto para obtener instrucciones.

Procedimiento

1. Seleccione el botón Customize Table Columns situado en la esquina superior derechadel informe.



2. En el cuadro de diálogo Table Customization que aparece, haga clic en la casilla deverificación junto a cada columna que desea mostrar en el informe.

3. Haga clic en Save and Apply.

La columna aparece en el informe con un nombre de columna predeterminado.

Cambio del orden de clasificación recomendado en un informeLos usuarios de la consola pueden cambiar el orden de clasificación predeterminado deun informe o cambiar temporalmente el orden de clasificación actual.

El orden de clasificación predeterminado de un informe se define en EDIT MODE. El ordenpreestablecido inicial de las alertas es por severidad y la hora en la que estas se crearon.Todas las alertas de un nivel más alto de severidad aparecen en primer lugar, seguidaspor severidades menores y en el orden en el que se crearon, con la alerta más recienteprimero.

Este procedimiento cambia las preferencias del informe para el usuario actualúnicamente. Para hacer un cambio que todos los usuarios puedan ver, cambie el ordende clasificación en EDIT MODE. Consulte el sistema de ayuda del producto para obtenerinstrucciones.

Procedimiento

1. Para cambiar el orden de clasificación predeterminado del usuario actual:

a. Posicione el mouse sobre la esquina superior derecha del informe hasta queaparezcan los íconos pequeños y haga clic en el ícono Customize Table Columns.

b. En el cuadro de diálogo Table Customization que aparece, arrastre las columnashacia el área Sorted columns y seleccione Ascending o Descending.

En la siguiente imagen, el usuario configura un orden por Owner y ComponentType.


Cambio del orden de clasificación recomendado en un informe 51

c. Haga clic en Save and Apply.

2. Para cambiar temporalmente el orden de clasificación solo para la visualizaciónactual pero para conservar el orden de clasificación predeterminados definido:

a.Elija la columna que desea ordenar y haga clic en el ícono Sort ( ) en elencabezado de esa columna.

Se reorganizan las filas de la tabla de acuerdo con los valores ascendente odescendente de esa columna.

b. Para cambiar de manera ascendente a descendente o viceversa, haga clic en elícono Sort nuevamente.

Filtrado de un informeUn usuario de la consola puede temporalmente limitar los resultados de un informeaplicando un filtro a una columna.

Puede hacer que un informe sea más útil limitando el contenido de las filas de interésactual.

Este procedimiento cambia el informe para el usuario actual únicamente. Para hacer uncambio más permanente que todos los usuarios puedan ver, aplique el filtro en EDITMODE. Consulte el sistema de ayuda del producto para obtener instrucciones.

Procedimiento

1.Haga clic en el ícono Filter ( ) en el encabezado de columna.

Si un encabezado de columna no contiene el ícono Filter, significa que esa columnano está disponible para filtrar.

2. En el cuadro emergente que aparece, ingrese el valor de filtro que representa las filasque desea incluir en el informe. Se excluyen todas las demás.

Los caracteres de expresión regular, como % o *, son válidos para el filtrado de datos.



3. Para implementar el filtro, presione Enter.

Observe que el color del ícono Filter cambia cuando se implementa un filtro en lacolumna.

4. Para cancelar el filtro, haga clic en el ícono Filter de la columna nuevamente yseleccione cancel filtering.

Cambio de un nombre de columna en un informePuede cambiar el encabezado de columna para cualquier columna de un informe en EDITMODE.

Procedimiento

1. Haga clic en EDIT MODE, situado en la parte superior de la página de informes.

2. Haga clic en la pestaña Report Details: Table.

3. Haga clic en la barra azul del nombre de columna que desea cambiar para exponer loscampos de esa columna.

4. En el campo Column Name, escriba el nuevo nombre.

5. Haga clic en Save en la parte inferior de la página.

6. Haga clic en BROWSE MODE en la parte superior de la página.


Cambio de un nombre de columna en un informe 53

PARTE 3

Administración de alertas

Estos capítulos están destinados a los administradores que instalarán, configurarán ymantendrán los módulos de ViPR SRM.

Chapter 5, "Configuración de la infraestructura de emisión de alertas"

Chapter 6, "Administre y configure las definiciones de alerta"

Chapter 7, "Notificaciones de alerta"

Chapter 8, "Proceso de archivado de alertas"

Chapter 9, "Monitoreo y solución de problemas"


Administración de alertas


CAPÍTULO 5

Configuración de la infraestructura de emisión dealertas

Estos temas describen cómo configurar una alerta consolidada en una instalación deViPR SRM.

l Configuración de alertas....................................................................................... 58l Habilitación y deshabilitación de los adaptadores de emisión de alertas.............. 59l Preserve las personalizaciones de la definición de alerta durante una actualización

............................................................................................................................. 59

Configuración de la infraestructura de emisión de alertas 57

Configuración de alertasLas funciones de Alertas se incluyen con la licencia de ViPR SRM de core y se instalancomo parte de vApp de ViPR SRM. Existen algunas tareas de configuración que se debenllevar a cabo después de la instalación.

La instalación se realiza como parte de la instalación de ViPR SRM. La instalación realizalo siguiente en relación con el módulo de emisión de alertas:

l Instala el Back-end de alerta, que contiene los procesos de consolidación de alertas,en el servidor de back-end primario de ViPR SRM. Para el balanceo de carga, puedetener múltiples Back-ends de alerta, pero cada uno requiere sus propios Front-end dealerta.

l Crea la base de datos de eventos en la misma instancia de base de datos de mysqlcomo la base de datos principal de ViPR SRM.

Se requieren las siguientes tareas para configurar y activar la consolidación de alertas.

Tabla 2 Lista de tareas para configurar la consolidación de alertas

Tarea Descripción Procedimiento

Activar definiciones dealerta

Antes de que se pueda generarcualquier alerta, se deben activar lasdefiniciones de alerta asociadas.Después de la instalación, todas lasdefiniciones de alerta estándesactivadas de manerapredeterminada.Cada SolutionPack instala unconjunto de definiciones de alertacorrespondientes a su dispositivo.Para cada SolutionPack nuevoinstalado, busque las definiciones dealerta correspondientes y decida sidesea activarlas.

Consulte Habilitación ydeshabilitación dedefiniciones de alerta en lapágina 64

Configure lasdefiniciones de alertasde notificacionesglobales

Ciertas definiciones de alertaglobales generan muchas de lasnotificaciones. Revíselas y edítelasantes de habilitarlas.

Consulte Acerca de lasdefiniciones de alertaglobales en la página 71

(Opcional) Configure loscomponentes deemisión de alertas

Todos los procesos de consolidaciónde alertas se instalan conconfiguraciones predeterminadas. Enla mayoría de los casos, lasconfiguraciones predeterminadas sonadecuadas y no son necesariasconfiguraciones adicionales.

Consulte Descripciones de loscomponentes de alertas en lapágina 108 y Editar archivosde configuración de proceso en la página 88

Configure losdispositivos para enviareventos y traps a ViPRSRM

Para que el módulo de emisión dealertas informe sobre los traps SNMPy eventos generados desdedispositivos externos, losdispositivos deben reenviar sus trapso eventos al Back-end de alerta.

Vea la documentación deSolutionPack para cadadispositivo.Consulte también Configuraciones específicas

Configuración de la infraestructura de emisión de alertas


Tabla 2 Lista de tareas para configurar la consolidación de alertas (continuación)

Tarea Descripción Procedimiento

del dispositivo en la página168.

Habilitación y deshabilitación de los adaptadores de emisión dealertas

Los adaptadores de emisión de alertas deben estar habilitados para que laconsolidación de alertas funcione.

Los adaptadores de emisión de alertas son procesos que se ejecutan en el campoAlerting Backend. Participan en el proceso de normalización de ciertos tipos de alertas.Son específicos de ViPR SRM y están preconfigurados para los requisitos de ViPR SRM.En condiciones normales, no hay ningún motivo para cambiar la configuración de losadaptadores instalados.

Aunque la consola de administración proporciona la funcionalidad para crear nuevosadaptadores y editar los existentes, estas acciones solo serán necesarias en unambiente de desarrollo a fin de admitir el procesamiento de un nuevo tipo de alerta.

Los adaptadores se habilitan de manera predeterminada mediante la instalación de ViPRSRM. Deben permanecer habilitados para que la consolidación de alertas funcione. Encondiciones normales, no hay ningún motivo para deshabilitarlos.

Procedimiento

1. Inicie sesión en la consola y vaya a Administration > Modules > Alerting > LocalManager > Adapters.

2. En la lista de adaptadores situada en el panel derecho, use la columna State a fin degarantizar que todos los adaptadores estén habilitados.

Una marca de verificación verde indica que están habilitados.

3. Si hay algún adaptador deshabilitado, haga clic con el botón secundario en él yseleccione Enable.

Preserve las personalizaciones de la definición de alerta duranteuna actualización

Si una actualización de SolutionPack incluye definiciones de alerta actualizadas, debevolver a aplicar las personalizaciones de las definiciones nuevas.

Antes de ViPR SRM 3.6, una actualización de SolutionPack que incluía definiciones dealerta modificadas reemplazaba las definiciones existentes, sobrescribiendo cualquierpersonalización. Las instrucciones de actualización para estas versiones incluyen pasospara copiar y guardar las definiciones de alerta personalizadas antes de la actualizacióny volver a aplicar las personalizaciones manualmente después de la actualización.

Desde ViPR SRM 3.6 y en adelante, cualquier actualización SolutionPack que incluyadefiniciones de alerta modificadas instala las definiciones más recientes en una carpetade nombre único. El resultado es que cuenta con ambos conjuntos de definiciones dealerta (las anteriores y las nuevas disponibles para su comparación.


Habilitación y deshabilitación de los adaptadores de emisión de alertas 59

La actualización a ViPR SRM 3.7 es el último momento en el que se requiere volver aaplicar las personalizaciones manualmente. La función contextualización de definiciónde alerta presentada en ViPR SRM 3.7 hará que sea posible cambiar las definiciones dealerta y preservar automáticamente sus personalizaciones para futuras actualizaciones.

Utilice el siguiente procedimiento después de actualizar un SolutionPack en ViPR SRM3.6 o 3.7.

Procedimiento

1. Después de la actualización, vaya a Administration > Modules > Alerting > LocalManager > Alert definitions.

2. Examine los nombres de carpeta de SolutionPack para buscar los nombres similares.Por ejemplo, busque dos nombres de carpeta que contengan el mismo nombre deSolutionPack.

3. Mediante el conjunto anterior de definiciones de alerta como referencia, vuelva aaplicar las personalizaciones para el conjunto más reciente.

4. Active las definiciones más recientes y desactive las anteriores.



CAPÍTULO 6

Administre y configure las definiciones de alerta

Los siguientes temas describen cómo administrar y configurar las definiciones de alerta.

l Acceso a las definiciones de alerta........................................................................62l Definiciones de alerta contextualizadas y no contextualizadas..............................63l Configuración de una definición de alerta .............................................................63l Habilitación y deshabilitación de definiciones de alerta........................................ 64l Cambiar definiciones de alerta..............................................................................64l Acerca de las definiciones de alerta globales........................................................ 71

Administre y configure las definiciones de alerta 61

Acceso a las definiciones de alertaPuede agregar una nueva definición de alerta y ver, modificar, habilitar y deshabilitardefiniciones de alerta.

Procedimiento

1. Haga clic en Administration > Modules > Alerting > Local Manager > Alert definitions.

2. Expanda las carpetas de definición de alerta hasta que aparezca el nombre de ladefinición de alerta.

En el panel derecho, la columna Type indica si las entradas son carpetas o nombresde definición de alerta.

Carpeta de definición de alerta

Definición de alerta contextualizada

Definición de alerta no contextualizada

3. En la tabla situada en el panel derecho, haga clic con el botón secundario en ladefinición de alerta y elija una de las siguientes acciones.

Edit Proporciona una vista gráfica de los componentes de la definiciónde alerta, con acceso a cada componente. Puede agregar, eliminar ycambiar la configuración de los componentes. Use esta opción paraagregar o quitar componentes, como acciones o comparadores.

Configurar Proporciona acceso a los cuadros de diálogo de configuración decada componente de la definición de alerta. Use esta opción paracambiar la configuración de un componente, como los destinatariosde correo electrónico en acciones de correo o los valores de umbralen comparadores.

Probe Inicia una prueba para comprobar el comportamiento de ladefinición de alerta.

Enable/Disable

Habilita o deshabilita la definición de alerta.

Delete Elimina la definición de alerta del sistema.

Nota

Si hace clic en una definición de alerta (en lugar de hacer clic con el botón secundarioen esta), la interfaz del usuario invoca la acción Edit o Configure, según la últimaelección que realizó con el menú contextual.

4. A fin de establecer la acción predeterminada (Configure o Edit) para su sesión actualcuando hace clic en una definición de alerta, seleccione la opción deseada una vezen el menú contextual.



Definiciones de alerta contextualizadas y no contextualizadasLas definiciones de alerta contextualizadas proporcionan ventajas cuando sepersonalizan los componentes con la configuración de usuario.

Las definiciones de alerta contextualizadas guardan valores de parámetros por separadode la definición de alerta y permiten más de un conjunto de valores.

l Si las actualizaciones futuras de SolutionPack cambian la definición de alerta, laconfiguración personalizada de los parámetros no se verá afectada.

l Puede definir varios contextos o conjuntos de valores para el mismo conjunto deparámetros configurados, y habilitar/deshabilitar los contextos por separado. Porejemplo, puede tener diferentes configuraciones para pruebas y producción o puedeconservar los valores instalados en el contexto predeterminado y crear un contextonuevo para los valores personalizados.

Las definiciones de alerta no contextualizadas guardan los valores de parámetros dentrode la definición de alerta. Si las actualizaciones futuras de SolutionPack cambian ladefinición de alerta, la configuración personalizada de los parámetros se sobrescribirá.Estas alertas pueden tener solo un conjunto de valores de configuración.

Nota

No es necesario contextualizar los componentes de acción, como capturas, registro ynotificaciones por correo electrónico. Dichas configuraciones no se sobrescriben.

Muchos de los componentes de la definición de alerta, incluidos todos los comparadoresde umbral, se contextualizan de manera inmediata. Los administradores puedencontextualizar aquellos que no están contextualizados.

Configuración de una definición de alertaPuede cambiar los ajustes configurables de una definición de alerta.

Procedimiento

1. Haga clic en Administration > Modules > Alerting > Alert Definitions.

2. En la tabla de definiciones de alerta, expanda las carpetas para buscar la definiciónde alerta que desea configurar.

3. Haga clic con el botón secundario en la definición de alerta y seleccione Configure.

Se muestran los parámetros configurables.

l Si la alerta está contextualizada, observará uno o más contextos con nombre, conlos valores y nombres de parámetros configurables de cada contexto. De manerainmediata, verá un contexto con el nombre Default.

l Si la alerta no está contextualizada, verá los parámetros configurables y laconfiguración actual.

4. Para una alerta contextualizada, puede hacer lo siguiente:

l Cambiar los valores en un contexto existente.

l Crear un contexto nuevo:

a. Haga clic en Add.

b. Asígnele un nombre al contexto nuevo y haga clic en OK.


Definiciones de alerta contextualizadas y no contextualizadas 63

c. Escriba los valores en el contexto nuevo.

d. Para cada contexto, elija Enable o Disable. Si se habilitan varios contextos, loseventos entrantes se procesan varias veces, una vez para cada contextohabilitado.

5. Para una alerta no contextualizada, cambie los valores en uno o varios campos.


Habilitación y deshabilitación de definiciones de alertaMuchas definiciones de alerta se instalan en el estado deshabilitado. Debe habilitarlas sidesea que los eventos definidos por los filtros generen alertas.

Procedimiento

1. Vaya a Administration > Modules > Local Manager > Alert definitions.

2. Expanda las carpetas para buscar las definiciones de alerta que desea habilitar odeshabilitar.

3. En el panel derecho, use la columna State a fin de determinar el estado de lasdefiniciones de alerta.

ColumnaState

Descripción

empty Es una carpeta. Haga clic en ella para ver el contenido.

La definición de alerta está habilitada.

La definición de alerta está deshabilitada.

La definición de alerta requiere cierta configuración antes de poder habilitarla.

Haga clic con el botón secundario en la fila y seleccione Configure.

4. Para habilitar o deshabilitar una definición de alerta, haga clic con el botónsecundario en la fila y seleccione Enable o Disable.

Cambiar definiciones de alertaPuede cambiar las definiciones de alerta predeterminadas para que satisfagan lasnecesidades de su instalación.

Configuración de una definición de alertaPuede cambiar los ajustes configurables de una definición de alerta.

Procedimiento



3. Haga clic con el botón secundario en la definición de alerta y seleccione Configure.

Se muestran los parámetros configurables.



l Si la alerta está contextualizada, observará uno o más contextos con nombre, conlos valores y nombres de parámetros configurables de cada contexto. De manerainmediata, verá un contexto con el nombre Default.

l Si la alerta no está contextualizada, verá los parámetros configurables y laconfiguración actual.

4. Para una alerta contextualizada, puede hacer lo siguiente:

l Cambiar los valores en un contexto existente.

l Crear un contexto nuevo:

a. Haga clic en Add.

b. Asígnele un nombre al contexto nuevo y haga clic en OK.

c. Escriba los valores en el contexto nuevo.

d. Para cada contexto, elija Enable o Disable. Si se habilitan varios contextos, loseventos entrantes se procesan varias veces, una vez para cada contextohabilitado.

5. Para una alerta no contextualizada, cambie los valores en uno o varios campos.


Edición de una definición de alertaPuede agregar componentes adicionales a una definición de alerta o cambiarlos.

Al editar definiciones de alerta, puede cambiar el filtro, agregar acciones u operaciones ala definición de alerta o eliminarlas.

Procedimiento



3. Haga clic con el botón secundario en la definición de alerta y seleccione Edit.

Aparece una representación gráfica de la definición de alerta.

4. Para cambiar un componente, coloque el cursor sobre el componente y haga clic en elícono de lápiz pequeño que aparece sobre el componente.

5. Para agregar un componente:

a. Haga clic en el tipo de componente a la derecha del pizarrón y, a continuación,arrastre un objeto gráfico hacia el pizarrón.

Por ejemplo, para agregar una acción de notificación, haga clic en Action en laderecha y arrastre el objeto Email.

b. Para configurar el nuevo componente, coloque el cursor sobre el componente yhaga clic en el ícono de lápiz pequeño que aparece sobre el componente.

Cambio de los valores de umbral en una definición de alertaPuede cambiar los valores en los componentes del comparador.

Los componentes del comparador a menudo se utilizan para asignar niveles deseveridad a los eventos. Por ejemplo, la definición de alerta Server CPU Utilization de lacarpeta EMC M&R Health contiene dos comparadores que prueban los umbrales para lasseveridades graves y leves, como se indica a continuación:


Edición de una definición de alerta 65

l Si la métrica CPUpercentage es mayor o igual que 70, se envía una captura de alertacon una severidad grave.

l Si la métrica CPUpercentage es mayor o igual que 30, se envía una captura de alertacon una severidad menor.

Suponga que desea aumentar dichos valores a 75 y 50, respectivamente.

Procedimiento

1. Inicie sesión en la consola y vaya a Administration > Modules > Alerting > LocalManager > Alert definitions.

2. Expanda las carpetas para buscar la definición de alerta, haga clic con el botónsecundario en ella y seleccione Configure.

Aparece la pantalla Configuration en la que se muestra una barra azul para cadacomponente configurable de la definición de alerta.

Nota

No se representa el filtro de punto de entrada. Para cambiar un filtro en una definiciónde alerta, utilice la opción Edit.

3. Haga clic en las barras azules de los dos comparadores para exponer los parámetrosdel componente.



4. Cambie los valores constantes.


Si la definición de alerta está habilitada, el cambio surte efecto de inmediato.

Adición de un registro, correo o acción de SNMP de otros fabricantes a unadefinición de alerta

Las definiciones de alerta inmediatas incluyen la acción de Captura de alertas de SNMPpara escribir en la base de datos de eventos. Puede agregar acciones adicionales acualquier definición de alerta.

Suponga que desea usar un archivo de registro a fin de recopilar ciertos eventos para unanálisis posterior. Por ejemplo, desea registrar los eventos filtrados por la definición dealerta Backend Processing Delay en la carpeta M&R Health.

Procedimiento

1. Inicie sesión en la consola y vaya a Administration > Modules > > Local Manager > Alertdefinitions.

2. Expanda las carpetas para buscar la definición de alerta, haga clic con el botónsecundario en ella y seleccione Edit.

Aparecen los símbolos gráficos de los componentes de la definición de alerta.


Adición de un registro, correo o acción de SNMP de otros fabricantes a una definición de alerta 67

3. En la derecha, haga clic en Action para exponer los símbolos de acción.

4. Arrastre y suelte el símbolo Log en el pizarrón.

Al soltar el método de arrastrar, aparece un cuadro de diálogo de configuración parala acción de registro.

5. Complete el cuadro de diálogo de configuración.

a. Para Template, deje en blanco o elija Log Template.

La plantilla es conveniente porque completa los campos de configuración. Puedecambiar los valores completados.

b. Para Name, escriba la frase para ver el símbolo Log en la presentación gráfica.

Para nuestro ejemplo, escriba: Process Delay Log.

c. Complete los campos restantes para configurar la ubicación, los parámetros deretención y el formato del archivo de registro.

d. Para Entry, se aceptan variables. El formato de una variable esPROP.'propertyname', donde propertyname es un campo en el archivo MIB decaptura de alertas de ViPR SRM. Consulte Formato y descripciones de mensajes deTrap de alerta y Trap de borrado en la página 102 para obtener la lista de nombresde propiedad.

6. Haga clic en Ok.



7. Adjunte la acción de registro al resultado correcto en la definición.

Nota

En nuestro caso de uso, deseamos que la acción de registro se adjunte a Conditionmet output del comparador.

a. Haga clic y arrastre desde Condition met output del comparador (un sólidocuadrado gris situado a la derecha del símbolo Comparator).

b. Arrastre hacia el cuadrado con contorno amarillo a la izquierda del símbolo Log ysuelte cuando el cuadrado amarillo se vuelve verde.

El cuadrado se torna gris después de una conexión correcta.

c. Haga clic en Save y, a continuación, elija Save and enable o Save and disable.

Agregar SNMP trap a tercerosPuede enviar contenidos de alerta a una aplicación de terceros mediante un SNMP trap.

Antes de comenzar

Debe conocer la información de destinatario SNMP de terceros: Dirección IP, puerto yComunidad.

Para enviar alertas desde ViPR SRM a otra aplicación, agregue una acción de SNMP trap ala definición de alerta y configure el trap para comunicarse con la de otros fabricantes.

Procedimiento

1. Inicie sesión en la consola y vaya a Administration > Modules > > Local Manager > Alertdefinitions.

2. Expanda las carpetas para encontrar la definición de alerta, haga clic con el botónsecundario en ella y seleccione Edit.

Aparecen los símbolos gráficos para los componentes de las alertas.


Agregar SNMP trap a terceros 69

3. En la derecha, haga clic enActionpara exponer los símbolos de acción.

4. Arrastre y suelte el símbolo de SNMP Trap en el pizarrón.

Cuando suelte el método de arrastrar, aparecerá un cuadro de diálogo deconfiguración para la acción de SNMP.


a. Para Host, deje en blanco o elija SNMP Notify plantilla.

La plantilla es conveniente debido a que completa los campos de configuración.Puede cambiar los valores completados.

b. Para Name, escriba una frase de identificación para mostrar en el símbolo deSNMP Trap en la muestra gráfica.

Para nuestro ejemplo, escriba Para aplicación externa.

c. Complete los campos restantes para configurar el trap. Host,Port yCommunity serefieren a los parámetros del extremo receptor.

d. Para el contenido de Trap, se aceptan variables. El formato para una variable esPROP.'propertyname', donde propertyname es un campo en la ViPR SRM Alerta TrapMIB. Consulte Formato y descripciones de mensajes de Trap de alerta y Trap deborrado en la página 102 para obtener la lista de nombres de propiedad.

6. Haga clic en Ok.



7. Adjunte la acción de SNMP para el resultado correcto en la definición.

a. Haga clic y arrastre desde la Condition met output del Comparador (un cuadradosólido gris a la derecha del símbolo comparador).

b. Arrastre hacia el cuadrado amarillo indicado en la izquierda del símbolo SNMPTrap y suelte cuando el cuadrado amarillo se vuelva verde.

El cuadrado verde se vuelve gris después de una conexión exitosa.

c. Haga clic en Save y, a continuación, elija si desea guardar y activar, o guardar ydesactivar esta definición de alerta.

Resultados

Observe que la Condition met output ahora tiene asociados dos traps a ella. El originales el valor de Trap de alerta predeterminado que obtiene la alerta en la base de datos deeventos. En el que acabamos de agregar, utilizamos una configuración diferente paraenviar información a una aplicación externa.

Acerca de las definiciones de alerta globalesViPR SRM viene con un conjunto de definiciones de alerta con filtros muy generales queemiten notificaciones para una amplia variedad de alertas.

Las definiciones de alerta globales podrían generar más notificaciones de las que sonnecesarias para una instalación. Comprenda qué hacen antes de habilitarlas.

Nombre de ladefinición dealerta

Descripción Consideraciones

Notificación deconsolidación dealerta por correoelectrónico

Genera una notificación porcorreo electrónico a una listaespecífica de destinatarios paratodos los eventos con severidadde 1, 2, 3 o 4.Debe configurar los parámetrosde notificación por correoelectrónico antes de poderactivar esta alerta.

Lo predeterminado es que se envíe uncorreo electrónico para cada alertaCrítica, Importante, Menor y Desconocida.Considere editar el filtro en estadefinición de alerta para limitar lasnotificaciones por correo electrónico a unsubconjunto de alertas, como solo lasalertas críticas y las más importantes.

Otra opción es agregar la acción de correoelectrónico a los resultados específicosen definiciones de alerta individuales yno activar esta definición de alerta global.


Acerca de las definiciones de alerta globales 71

Nombre de ladefinición dealerta

Descripción Consideraciones

Notificación deconsolidación dealerta trap

Genera una notificación Trap alpuerto 162 (el conocido puertode trap SNMP) en un hostespecífico para todos los eventoscon severidad de 1, 2, 3 o 4.Debe configurar la dirección IPdel host receptor antes de poderactivar esta alerta.

Está predeterminado que se envíe unaalerta a una aplicación remota de SNMPpara cada alerta Crítica, Importante,Menor y Desconocida.

Utilización desistema dearchivos

Genera acciones de registro yacciones de correo electrónicopara cualquier sistema dearchivos en cualquier Hostmonitoreado cuya métrica deutilización actual sea superior al90%.Debe configurar la ubicación delarchivo de registro y losparámetros de notificación porcorreo electrónico antes de poderactivar esta alerta.

Si otras definiciones de alertas deSolutionPack activas generan alertas decapacidad de archivos que aparecen enlos informes de alertas, es posible que nonecesite esta definición de alerta.Está predeterminado que se envíenacciones de correo electrónico y accionesde registro. Considere la eliminación deuno de ellos desde la definición de alerta.



CAPÍTULO 7


Los siguientes temas describen la característica de notificación por correo electrónico dealerta y cómo configurar los parámetros de notificación asociados con las alertas.

l ¿Qué son las notificaciones de alerta?...................................................................74l Notificación de alerta predeterminada ..................................................................75l Configuración de notificaciones predeterminadas por correo electrónico ............. 76l Modificación de los destinatarios, el asunto y el mensaje de una notificación ......77l Adición de una acción de notificación a una definición de alerta .......................... 77l Crear una plantilla de notificación......................................................................... 79

Notificaciones de alerta 73

¿Qué son las notificaciones de alerta?Una notificación de alerta envía un correo electrónico a una lista de destinatariosconfigurada cada vez que se produce la condición de alerta.

Para implementar las notificaciones de alertas específicas, edite la definición de alerta,agregando una acción de correo. Cualquier definición de alerta puede incluir una o másacciones de correo. Cada acción de correo tiene su propia configuración independiente.Por ejemplo, puede, enviar alertas de umbral críticas a un conjunto de administradores yalertas importantes o menores a otro conjunto.

Cada acción de correo tiene tres parámetros configurables. Estos son:

l Lista: deben ser direcciones de correo electrónico válidas, separadas con comas.

l Asunto: puede ser texto sin formato o variables de uso que representen los camposde datos en los datos de evento.

l Mensaje: puede ser texto sin formato o variables de uso que representen los camposde datos en los datos de eventos.

La siguiente figura muestra dos acciones de correo en una definición de alerta. Laprimera notificación ocurre cada vez que se produce la condición de alerta. La otra seproduce cuando se borra la alerta.

Figura 8 Notificaciones en una definición de alerta



Plantillas de correo electrónicoSi es necesario configurar muchas acciones similares de correo, ahorre tiempo utilizandouna plantilla. La plantilla asigna valores iniciales a los parámetros. Puede editar lasconfiguraciones individuales después de aplicar una plantilla.

ViPR SRM está instalado con una acción de Plantilla de correo electrónicopredeterminada. Puede crear varias plantillas adicionales según sea necesario.

Configuración de notificaciones predeterminadas por correo electrónicoSiga estos pasos para configurar la definición de alerta Alert Consolidation MailNotifications instalada con ViPR SRM.

Procedimiento

1. Inicie sesión en la consola y navegue hacia Administration > Modules > Alerting > Alertdefinitions.

2. En el panel derecho, haga clic en el encabezado de la columna Type.

3. Haga clic con el botón secundario en la fila Alert Consolidation Email Notification yseleccione Configure.

4. En el campo To, agregue una o varias direcciones de correo electrónico de losdestinatarios de la notificación.

Separe las diversas direcciones con coma.

5. (Opcional) Cambie los campos Subject y Message.


7. Haga clic con el botón secundario en la fila nuevamente y esta vez seleccione Enable.

8. (Opcional) Para cambiar el filtro de la definición de alerta a fin de que capture soloalertas importantes (para limitar las notificaciones):

a. Haga clic con el botón secundario en la fila y seleccione Edit.

b. Coloque el cursor sobre el símbolo Entry Point para ver el menú de acción y hagaclic en Edit (ícono de lápiz).

c. En el diagrama de filtro, haga clic con el botón secundario en el cuadro quecontiene las condiciones de severidad y seleccione Edit expression.

d. Editar la expresión para incluir solo severity=='1'.

e. Haga clic en OK.

9. Haga clic en Save y, a continuación, haga clic en Save and enable o Save and disable.

Notificación de alerta predeterminadaDebe analizar y quizás cambiar la definición de alerta de notificación por correoelectrónico de consolidación de alerta antes de activarla.

ViPR SRM se entrega con una definición de alerta genérica con el nombre AlertConsolidation Email Notification. Cuando está configurada y activa, esta definición dealerta envía notificaciones por correo electrónico para cada alerta que es procesada porel adaptador de consolidación de alertas y tiene una severidad crítica, importante omenor.

Este es el filtro:


Configuración de notificaciones predeterminadas por correo electrónico 75

Figura 9 Filtro para la definición de alerta de notificación por correo electrónico de la consolidaciónde alerta.

El filtro incluye casi todas las alertas. Por ejemplo, incluso si todas las definiciones dealerta de VMAX están desactivadas, aún recibiría un correo electrónico cuando seproduce una alerta VMAX si está definición de alerta está activada.

Antes de activar esta definición de alerta, considere lo siguiente:

l Debe configurar la definición de alerta para agregar como mínimo una dirección decorreo electrónico. Tenga en cuenta el volumen de los correos electrónicos quepodrían generarse cuando se activa esta definición de alerta.

l Considere la posibilidad de editar el filtro para incluir solo alertas críticas, o solocríticas e importantes.

l En lugar de activar esta definición, cree nuevas definiciones de alertas con los filtrosmás específicos. Por ejemplo, copie esta definición de alerta y agregue una fraseSource starts with Brocade para que el filtro identifique las alertas solo delos dispositivos de Brocade y provea las direcciones de correo electrónico de losadministradores interesados en el estado de Brocade.

l Otra alternativa es agregar al Componente de Acción de correo para resultadosespecíficos en definiciones de alerta individuales.

Configuración de notificaciones predeterminadas por correoelectrónico

Siga estos pasos para configurar la definición de alerta Alert Consolidation MailNotifications instalada con ViPR SRM.

Procedimiento


2. En el panel derecho, haga clic en el encabezado de la columna Type.

3. Haga clic con el botón secundario en la fila Alert Consolidation Email Notification yseleccione Configure.

4. En el campo To, agregue una o varias direcciones de correo electrónico de losdestinatarios de la notificación.

Separe las diversas direcciones con coma.

5. (Opcional) Cambie los campos Subject y Message.


7. Haga clic con el botón secundario en la fila nuevamente y esta vez seleccione Enable.

8. (Opcional) Para cambiar el filtro de la definición de alerta a fin de que capture soloalertas importantes (para limitar las notificaciones):



a. Haga clic con el botón secundario en la fila y seleccione Edit.

b. Coloque el cursor sobre el símbolo Entry Point para ver el menú de acción y hagaclic en Edit (ícono de lápiz).

c. En el diagrama de filtro, haga clic con el botón secundario en el cuadro quecontiene las condiciones de severidad y seleccione Edit expression.

d. Editar la expresión para incluir solo severity=='1'.

e. Haga clic en OK.

9. Haga clic en Save y, a continuación, haga clic en Save and enable o Save and disable.

Modificación de los destinatarios, el asunto y el mensaje de unanotificación

Para cambiar la lista de destinatarios, el asunto y el mensaje en una acción denotificación, reconfigure la definición de alerta.

Procedimiento


2. Expanda las carpetas hasta que la definición de alerta que desea configurar aparezcaen la tabla del panel derecho.

3. En la tabla, haga clic con el botón secundario en el nombre de definición y seleccioneConfigure.

Aparece un conjunto de barras azules. Cada barra representa un componente de ladefinición de alerta. Para configurar los parámetros de cada componente, use estainterfaz.

4. Haga clic en la barra azul del componente Mail Action.

Nota

Si no aparece una barra para Mail Action, la alerta no incluye una acción denotificación. En ese caso, edite la definición de alerta para agregar una acción denotificación.

5. Cambie el parámetro To para agregar, cambiar o eliminar direcciones de correoelectrónico válidas.

Use una coma para separar varias direcciones de correo electrónico. Una acción denotificación debe tener al menos un destinatario antes de poder habilitarla.

6. De manera opcional, cambie los campos Subject y Message.

El mensaje predeterminado incluye todos los datos de evento. Puede editar elmensaje.

7. Haga clic en Save y, a continuación, en Save and enable, o Save and disable.

Adición de una acción de notificación a una definición de alertaPuede agregar acciones de notificación a cualquier definición de alerta.

Puede adjuntar una Mail Action a uno o más de los resultados en una definición dealerta. Cada Mail Action puede tener un conjunto único de destinatarios, línea de asunto


Modificación de los destinatarios, el asunto y el mensaje de una notificación 77

y mensaje, o puede aplicar una plantilla que completa un conjunto preconfigurado devalores.

Por ejemplo, esta es la definición de alerta denominada EMC M&R Health > Tasks Statusoriginalmente instalada por SolutionPack.

Esta es la misma definición, cambiada para incluir una notificación de correo cuando secumplen las condiciones en el comparador. Cuando no se cumplen, se emite una capturade borrado (para borrar una captura de alerta anterior).

Utilice el siguiente procedimiento para agregar una notificación a una definición dealerta.

Procedimiento


2. Expanda las carpetas hasta que la definición que desea editar aparezca en la tablasituada en el panel derecho.

3. En la tabla, haga clic con el botón secundario en la definición de alerta y seleccioneEdit.

Aparece una representación gráfica de la definición de alerta. Puede agregar, cambiary eliminar componentes en esta interfaz.



4. En la columna de tipos de componente situada en el extremo derecho, haga clic enAction.

Aparecen los símbolos de todas las acciones disponibles.

5. Seleccione el símbolo Mail y arrástrelo hasta el pizarrón de la definición de alerta.

Cuando suelte el botón del mouse, aparecerá una pantalla de configuración.

Nota

Puede colocar el símbolo en cualquier lugar por ahora. La acción se asignará a unresultado específico más adelante.

6. Complete la pantalla de configuración:

a. Para Template, por lo general, seleccione un nombre de plantilla de la lista.

l Puede seleccionar None si desea un único conjunto de valores de parámetro.

l Se instala la plantilla Default Alert Email Template con el producto. Esta opcióncompleta los parámetros de Subject y Message con la informaciónpredeterminada de los datos de evento. Para comenzar, seleccione esta opcióny, a continuación, edite los valores de Subject y Message.

l Es posible que haya plantillas personalizadas adicionales en la lista. Puedeseleccionar cualquier plantilla de correo.

b. Para To, ingrese la lista de destinatarios. Use una coma para separar variasdirecciones de correo electrónico.

c. Agregue o edite los valores de Subject y Message.

d. Haga clic en OK.

7. Adjunte la acción de notificación a un resultado en la definición.

a. Haga clic y arrastre desde un indicador de resultado (un sólido cuadrado grissituado a la derecha de un símbolo).

b. Arrástrelo hacia el cuadrado con contorno amarillo a la izquierda del símbolo decorreo y suéltelo cuando el cuadrado amarillo se vuelve verde.


c. Haga clic en Save y, a continuación, en Save and enable, o Save and disable.

Crear una plantilla de notificaciónUna plantilla de notificación contiene valores de parámetro que reutilizará muchas vecesa medida que crea nuevas acciones de correo.

Las plantillas ahorran tiempo. Puede crear un conjunto de plantillas con todos losdetalles requeridos y luego completar las notificaciones rápidamente mediante laaplicación de la plantilla. Por ejemplo, puede crear un conjunto de plantillas con listas dedestinatarios de correo electrónico diferentes.

Procedimiento

1. Inicie sesión en la consola y navegue hacia Administration > Modules > Alerting > Localmanager > Templates.

2. En la parte superior del panel izquierdo, haga clic en el ícono (verde +) Create a newelement.


Crear una plantilla de notificación 79

3. En el panel derecho, complete los campos de una acción de correo, de la siguientemanera:

Familia Elija action.

Group Elija Mail.

Tipo Elija Mail action.

Nombre Escriba un nombre único para esta plantilla.

Descripción Opcional. Escriba una descripción para esta plantilla.

Parámetros Opcional. Escriba los valores de parámetro que desea que secompleten automáticamente al utilizar esta plantilla. Puede editar losvalores completados en las acciones de correo individuales si esnecesario.En To, proporcione direcciones de correo electrónico. Separe lasdiversas direcciones con coma.

En Subject y Message, se aceptan variables. El formato de una variablees PROP.'propertyname', donde propertyname es un campo en elarchivo MIB de captura de alertas de ViPR SRM. Consulte Formato ydescripciones de mensajes de Trap de alerta y Trap de borrado en lapágina 102 para obtener la lista de nombres de propiedad.

4. Haga clic en Create.

Esta es una plantilla de ejemplo denominada Brocade admins critical alerts.



Figura 10 Nueva plantilla para las acciones de correo


Crear una plantilla de notificación 81

CAPÍTULO 8

Proceso de archivado de alertas

Los siguientes temas describen el proceso de archivado de alertas y sus parámetrosconfigurables de ViPR SRM.

l Base de datos de eventos..................................................................................... 84l Ciclo de vida de una alerta.................................................................................... 84l Propiedades de las alertas que afectan el ciclo de vida......................................... 87l Editar archivos de configuración de proceso .........................................................88

Proceso de archivado de alertas 83










Ciclo de vida de una alertaLas alertas se transfieren desde la tabla genericevents_live a la tablagenericevents_archive y luego se purgan del sistema por completo.

El tiempo en el que las alertas permanecen en la base de datos es limitado yadministrado. El ciclo de vida de las alertas tiene como consecuencia la administraciónde espacio automática para la base de datos de eventos.

Una alerta nueva se agrega a la tabla en líneaLas alertas se escriben inicialmente en la tabla genericevents_live en la base de datos deeventos. La mayoría de las propiedades se transmiten desde el Back-end de alerta,según el contenido en el mensaje de Trap de alerta. Algunas propiedades se completanautomáticamente en el proceso de consolidación de alertas. Consulte Propiedades de lasalertas en una entrada de base de datos en la página 154.

Se actualiza la alerta existenteEs probable que se procesen los mismos datos de alerta a través del sistema variasveces. Por ejemplo, si un recopilador recopila métricas cada 15 minutos, los mismosdatos de alerta sobre una métrica se procesarán cada 15 minutos hasta que lascondiciones cambien. El módulo de emisión de alertas tiene un conteo cada vez que seproduce la misma alerta, pero no genera una nueva alerta cada vez. Las siguientespropiedades de una alerta se ven afectadas por alertas recurrentes:

count

Cuenta el número de veces que se procesa la misma alerta.

lastchangedat

Un registro de fecha y hora indica la última vez que la entrada de la alerta semodificó. Una periodicidad es solo una razón de que este campo pueda cambiar.

La alerta existente se desmarca (se hace INACTIVA)Las siguientes propiedades de una alerta se ven afectadas cuando se desmarca la alerta:



closedat

Un registro de fecha y hora que indica cuándo se ha borrado la alerta.

eventstate

Se cambia a INACTIVO cuando se cierra una alerta.

Activo

Cambió a 0 (falso).

La alerta INACTIVA se transfiere a la tabla de archivoUn proceso de salida elimina las alertas INACTIVAS de la tabla genericevents_live y lasagrega a la tabla genericevents_archive. Cuando se completa la propiedad de closedatde una alerta, la alerta es candidata para esta operación de transferencia.

El proceso de transferencia es configurable.

Tabla 3 Ajustes de configuración del proceso de transferencia

proceso::instancia Nombre dearchivo

Elementos y atributos

Escritor genérico enlínea::consolidaciónde alerta

conf/alert-event.xml

<moveout field="ClosedAt" period="2h" timeout="1h" unit="ms" />

Donde:

l periodes la frecuencia con la que se ejecuta el

proceso de transferencia.

l timeoutes la cantidad mínima de tiempo que una

alerta cerrada debe permanecer en la tabla activaantes de que se la transfiera a la tabla archivo.

La entrada de ejemplo muestra los ajustes deconfiguración predeterminados. El proceso detransferencia se ejecuta cada dos horas y transfiere lasalertas con el tiempo transcurrido entre el valor declosedat y la hora actual mayor a 1 hora.

Con estos ajustes, un usuario tiene una hora para cancelaruna alerta después de que se confirme por error.

Las alertas que no se tocaron (ignoradas) se cierran automáticamente y se envían a latabla de archivoAdemás del ciclo activo de actualización y borrado descrito anteriormente, también hayun ciclo activo sin cambios inactivo para manejar las alertas que no se borran dentro deun plazo determinado.

Independientemente del tipo de alerta (MOMENTÁNEA o DURADERA), si la alerta persisteen la tabla activa después de un número configurable de días, es transferida de la tablagenericevents_live a la tabla de archivo.

El proceso de cierre automático compara el registro de fecha y hora en la propiedad deopenedat con la hora actual y las alertas de archivo que no fueron borradas dentro delplazo de tiempo configurado.

El proceso de cierre automático es configurable.


Ciclo de vida de una alerta 85

Tabla 4 Ajustes de configuración del proceso de cierre automático

proceso::instancia

Nombre dearchivo

Atributos

Cachéactivo::Consolidación de alerta

conf/active-cache.xml

<auto-close period="1d" timeout="7d" />

Donde:

l period especifica la frecuencia con la que se ejecuta

el proceso de cierre automático.

l timeout Especifica la cantidad máxima de tiempo

que puede existir una alerta activa en la tabla activaantes de que se cierre y se transfiera a la tabla dearchivo automáticamente.

La entrada de ejemplo muestra los ajustes deconfiguración predeterminados. Configura el proceso decierre automático para ejecutarse una vez al día y cerrar ytrasladar a los archivos todas las alertas con elopenedat valor de registro de fecha y hora de más de 7

días de antigüedad.

La alerta vencida se depura desde la tabla de archivoLa alerta estará en la tabla genericevents_archive durante 30 días (de manerapredeterminada). Después de eso, la alerta se depura desde el sistema completamentepor el proceso de vencimiento.

El proceso de vencimiento es configurable.

Tabla 5 Ajustes de configuración del proceso de vencimiento

proceso::instancia

Nombre dearchivo

Atributos

Escritor genéricoenlínea::consolidación de alerta

conf/alert-event-archive.xml

<expiration field="OpenedAt" period="1d" timeout="30d" unit="ms" />

Donde:

l period especifica la frecuencia con la que se ejecuta el

proceso de vencimiento.

Nota

Este es un parámetro relacionado con el rendimiento. Sitiene un alto volumen de alertas, puede ver el cambio en elrendimiento de back-end al ajustar este valor de atributo.

l timeout especifica la cantidad del tiempo transcurrido

desde que se abrió la alerta que debe transcurrir antes dela alerta se depure desde el sistema.

El ejemplo muestra la configuración inmediata de atributos.Configura el proceso de vencimiento para ejecutarse una vez al



Tabla 5 Ajustes de configuración del proceso de vencimiento

proceso::instancia

Nombre dearchivo

Atributos

día y retener alertas durante 30 días después de que se abren.Después de eso, se purgan de los archivos.

Propiedades de las alertas que afectan el ciclo de vidaAlgunas propiedades de una alerta afectan su ciclo de vida, como el estado o el tipo dela alerta y cuánto tiempo tiene.

Todas las alertas tienen los mismos campos de datos o propiedades. La mayoría de laspropiedades de las alertas se originaron desde el origen de la alerta. Existenpropiedades adicionales que son asignadas por el proceso de consolidación de alerta yotras que son mantenidas por procesos del sistema durante el ciclo de vida de la alerta.

La siguiente lista describe las propiedades de alerta que influyen en el ciclo de vida delas alertas. Para obtener una descripción de todas las propiedades de una entrada en labase de datos, consulte Propiedades de las alertas en una entrada de base de datos enla página 154.

eventtype

Se asigna en la definición de alerta. Es DURADERA o MOMENTÁNEA.

active

Inicialmente está configurado en 1. Se puede configurar en 0 de la siguientemanera:

l Para las alertas MOMENTÁNEAS, active se cambia a 0 cuando un usuario deconsola realiza una acción de Acknowledge.

l Para las alertas DURADERAS, active se cambia a 0 cuando otro evento quecontiene las mismas propiedades de identificación que el original borra laalerta. El origen del borrado de la alerta podría ser una métrica que se encuentradentro de los valores aceptables, o un trap claro de SNMP.

reconocido

Indica si un usuario confirmó la alerta con la acción de administración en la consola.Los valores son:

l 0 para no reconocido; se muestra No en la consola.

l 1 para confirmado; se muestra Sí en la consola.

openedat

El registro de fecha y hora cuando la alerta ingresa el proceso de consolidación dealerta. El formato del registro de fecha y hora es Java.

closedat

Inicialmente es nulo. Esta propiedad se completa con un registro de fecha y hora dela siguiente manera:

l Para alertas MOMENTÁNEAS, se completa con el registro de fecha y hora actualcuando un usuario de consola realiza una acción de Acknowledge.


Propiedades de las alertas que afectan el ciclo de vida 87

l Para las alertas DURADERAS, se completa con el registro de fecha y hora actualcuando el Back-end de alerta envía el trap claro.

Editar archivos de configuración de procesoLos administradores pueden editar archivos de configuración para los procesos de alertadirectamente desde la consola.

Antes de comenzar

Se requieren permisos del administrador.

Los archivos de configuración que controlan los procesos de ViPR SRM son archivos detexto XML. Utilice el siguiente procedimiento para acceder a ellos y modificarlos.

Procedimiento

1. Vaya a Administration > Centralized Management > Logical Overview > Events.

Aparecerá una lista de procesos.

2. Haga clic en process :: instance que desea configurar.

3. En el panel derecho, expanda la barra azul llamada Configuration files.

4. Haga clic en el íconoEdit (lápiz) junto al nombre del archivo de configuración paraeditar.

5. Edite el archivo y luego haga clic en Save.



CAPÍTULO 9

Monitoreo y solución de problemas

Los siguientes temas describen cómo monitorear el módulo de emisión de alertas deViPR SRM y cómo analizar los problemas.

l Supervisión del estado de alerta........................................................................... 90l Archivos de registro para monitorear.....................................................................90l Uso de un espía de eventos para solucionar problemas de las alertas...................90l Utilice el sondeo para solucionar problemas en una definición de alerta...............92

Monitoreo y solución de problemas 89

Supervisión del estado de alertaEl SolutionPack for EMC M&R Health supervisa los indicadores clave de rendimiento delos componentes del sistema, incluidos los componentes de emisión de alertas.

Procedimiento

1. Para ver el uso de la CPU y la memoria, vaya a Report Library > EMC M&R Health >Stress > Components > Alerting > Alerting-Backend.

2. Para comprobar las tendencias de disponibilidad de Alerting Backend, expandaOverlay.

3. Para comprobar las tendencias de disponibilidad y volumen de datos de los procesosdel adaptador, expanda Alert Data.

4. Para ver el rendimiento y la disponibilidad de los procesos de la consolidación dealertas, vaya a Report Library > EMC M&R Health > Stress > Components > EventProcessing Managers > Alert Consolidation.

5. Para ver un informe del receptor de condición de error de SNMP y sus estadísticas deprocesamiento, desplácese hasta la parte inferior de la página del paso anterior.

Archivos de registro para monitorearUtilice los registros de consolidación de alertas desde el Administrador deprocesamiento de eventos para monitorear el módulo de emisión de alertas y solucionarproblemas que este tenga.

Buscar los archivos de registro para las palabras claveWarning,Error, oFatal.

Para obtener acceso a los archivos de registro en la consola, vaya a Administration >Centralized Management > Logical Overview > Events > process_name, expand the blue barlabeled Log Files en el panel derecho, seleccione un nombre de archivo y haga clicenDownload.

También puede encontrar los registros aquí en el servidor de back-end:

/opt/APG/Event-Processing/Event-Processing-Manager/Alert-Consolidation/logs

Uso de un espía de eventos para solucionar problemas de lasalertas

Un espía de eventos es una utilidad que registra los valores de propiedad de los eventosa medida que pasan por componentes espiados.

Un espía de eventos puede ayudar a depurar los eventos que fluyen a través del sistema.Al espiar un proceso, puede verificar los valores en los datos de evento después de queel componente procese el evento.

Para instalar y usar un Espía de eventos, realice los siguientes pasos.

Procedimiento

1. Para instalar la utilidad Espía de eventos, vaya a /opt/APG/bin/manage-modulesinstall event-processing-utils-1.2u1-linux-x64.pkg e instale el contenido del paquete.

2. Busque el archivo de configuración para cambiar:



a. Vaya a Administration > Centralized Management > Logical Overview > Events >Event-Processing-Manager::Alert-Consolidation.

b. En el panel derecho, haga clic en la barra azul de Configuration Files.

c. Haga clic en el archivo conf/processing.xml y, a continuación, en Edit.

3. Modifique el archivo de configuración:

a. Agregue la siguiente línea en un lugar adecuado del archivo, por ejemplo, despuésde la línea ALERT-LOG-PROCESSOR:

<processing-element name="SPY" config="Event-Processing-Utils/Default/conf/" type="Event-Spy"/>

b. Para cada componente que desea espiar, modifique el elemento que asigna unnombre a ese componente; para ello, agregue la palabra SPY al atributo data.

Por ejemplo, puede espiar el puerto de escucha de eventos mediante la adición deSPY al elemento para ALERT-EVENT-LISTENER, como se indica a continuación:

<processing-element name="ALERT-EVENT-LISTENER" config="Generic-Event-Listener/Alert-Consolidation/conf/alert-event-listener.xml" data="SPY ALERT-LOG-PROCESSOR" />

Puede espiar varios componentes, si lo desea.

c. Haga clic en Save.

d. En la página que aparece, desplácese hacia arriba para buscar la sección ServiceStatus y haga clic en Restart.

4. Para ver los resultados espiados:

a. En la misma página, contraiga la barra azul de Configuration Files y haga clic en labarra de Log Files.

b. Seleccione el archivo de registro más reciente y, a continuación, haga clic enDownload.

c. Abra el archivo descargado.

Ejemplo 1 Entrada de registro de ejemplo

A medida que se procesan eventos nuevos, comienza a ver mensajes de registrodetallados de los componentes espiados. Las entradas incluyen los valores de propiedadde cada evento procesado.

En el siguiente ejemplo se muestra una entrada de registro después de configurar elespía en el puerto de escucha de eventos.

INFO -- [2015-05-12 14:04:19 EDT] -- LogRule::log(): LogRule: END VPLEX SNMP FILE (99-Finalizer.xml:208): com.watch4net.events.common.data.GenericEvent snmpTrapOIDKey = 0 (OCCURRENCE,STRING) mib = SNMPv2-MIB (OCCURRENCE,STRING) snmpTrapOID = .1.3.6.1.4.1.1139.21.0.4 (OCCURRENCE,STRING)


Uso de un espía de eventos para solucionar problemas de las alertas 91

Ejemplo 1 Entrada de registro de ejemplo (continuación)

.1.3.6.1.4.1.1139.21.1.1.0 = FNM00141500208 (OCCURRENCE,STRING) .1.3.6.1.4.1.1139.21.1.2.0 = 0 (OCCURRENCE,STRING) .1.3.6.1.4.1.1139.21.1.3.0 = 0 (OCCURRENCE,STRING) .1.3.6.1.4.1.1139.21.1.4.0 = (OCCURRENCE,STRING) .1.3.6.1.4.1.1139.21.1.5.0 = This is the body of the testing callhome message (OCCURRENCE,STRING) Source = VPLEX-GenericEvent (OCCURRENCE,STRING) eventDescription = SNMP-VPLEX (OCCURRENCE,STRING) sourceIP = 10.247.143.119 (OCCURRENCE,STRING) generic = 6 (OCCURRENCE,INT) specific = 4 (OCCURRENCE,INT) enterprise = .1.3.6.1.4.1.1139.21 (OCCURRENCE,STRING) timestamp = 1431453859268 (OCCURRENCE,LONG) community = public (OCCURRENCE,STRING) sysUpTime = 0 (OCCURRENCE,LONG) agent = 10.247.143.119 (OCCURRENCE,STRING) id = 6148047510137995330 (OCCURRENCE,LONG) sourceip = 10.247.143.119 (OCCURRENCE,STRING) lastchangedat = 1431453859268 (OCCURRENCE,LONG) devtype = VirtualStorage (OCCURRENCE,STRING) active = yes (OCCURRENCE,STRING) eventtype = MOMENTARY (OCCURRENCE,STRING) certainty = 100 (OCCURRENCE,STRING) severity = 4 (OCCURRENCE,STRING)

Utilice el sondeo para solucionar problemas en una definición dealerta

El sondeo le ayuda a confirmar el comportamiento de una definición de alerta.

Un sondeo prueba los elementos en una definición de alerta en tiempo real para vercómo se evalúan los datos de cada componente. Los resultados se muestran porseparado para cada componente, lo que le permite analizar los resultados exactos encada etapa en la definición de alerta.



Un sondeo le permite cambiar el filtro u otros componentes configurables solo para elsondeo y comprobar los efectos de esos cambios. Todos los resultados aparecen en lamisma ventana con la definición de alerta, lo que facilita la edición y las pruebas nuevas.El sondeo ayuda a crear definiciones de alerta complejas.

Para obtener instrucciones sobre el uso del sondeo, consulte la Ayuda del producto.


Utilice el sondeo para solucionar problemas en una definición de alerta 93

PARTE 4

Desarrollo de nuevas alertas

Estos capítulos se han previsto para desarrolladores que crean nuevas alertas para lanormalización y consolidación en el módulo de emisión de alertas de ViPR SRM.

Chapter 10, "Información general acerca del proceso de consolidación de alertas "

Chapter 11, "Crear alertas personalizadas"

Chapter 12, "Crear definiciones de alerta personalizadas"

Chapter 13, "Alertas de la base de datos y caché activo"

Chapter 14, "Temas de desarrollo adicionales"

Desarrollo de nuevas alertas 95

Desarrollo de nuevas alertas


CAPÍTULO 10

Información general acerca del proceso deconsolidación de alertas

Los siguientes temas describen el proceso para normalizar y consolidar los eventos enalertas y obtener la escritura de las alertas en la base de datos. Estos puntos se aplican atodas las alertas, independientemente del origen del evento que las cause.

l Flujo de proceso de alertas comunes ....................................................................98l Formato de mensaje de evento y trap normalizado ............................................... 99l Acerca de las capturas en ViPR SRM.................................................................... 100l Acerca de Trap de alerta y Traps de borrado de alertas........................................ 101l ¿Cómo se asignan las severidades de alerta?...................................................... 107l Descripciones de los componentes de alertas.....................................................108

Información general acerca del proceso de consolidación de alertas 97

Flujo de proceso de alertas comunesIndependientemente de cómo ingresan los eventos en el sistema, alcanzaneventualmente el Back-end de alertas como un evento normalizado. El Back-end dealertas inicia el proceso para ubicar la alerta en la base de datos.

Los eventos ingresan al sistema de diversas maneras, mediante el puerto de escucha deevento, el receptor de condición de error, o directamente en el Back-end de alertas comoalertas de umbral o las alertas sobre los informes calendarizados. Cada uno de estosflujos específicos se describe más adelante. El resultado de cada uno de ellos es elmismo: un evento normalizado.

La siguiente representación muestra el flujo de proceso común después de que senormaliza un evento.

Figura 11 Flujo de proceso común

A continuación, se describe el flujo de procesamiento general. Cada componente sedescribe más detalladamente en las secciones siguientes.

1. Para cada evento que recibe, el Back-end de alertas busca una definición de alertaválida y habilitada con un filtro y en condiciones operacionales que coincidan con losdatos de eventos. Las definiciones de alerta se almacenan en el front-end de alertas.Puede ver, editar y crear nuevas definiciones de alerta en la consola administrativade ViPR SRM.

2. Si los datos de eventos no coinciden con las condiciones en cualquier definición dealerta activa, se omiten los datos de manera predeterminada.Si se encuentra una definición de alerta que coincida con el evento, el Back-end dealertas implementa las acciones en la definición de alerta. Las acciones puedenincluir notificaciones por correo electrónico, traps a un tercero, una acción deregistro, un Trap de alerta o acciones personalizadas potencialmente.

3. Si la definición de alerta incluye una acción de Trap de alerta, el evento se reenvía alreceptor de condición de error. La acción de Trap de alerta debe:

l Enviar el trap a host local en el puerto 2041

l Contener un mensaje que se ajuste a las MIB de Watch4Net

Información general acerca del proceso de consolidación de alertas


Nota

Si la definición de alerta no incluye una acción de Trap de alerta, el evento no seagrega a la base de datos de eventos y no se mostrará en los informes de alertas.

4. El receptor de Trap de SNMP retoma el evento en el puerto 2041 y lo envía alprocesador de registro.

5. El evento puede haber estado a través del procesador de registro, mientras se fuenormalizando. En este caso, sin embargo, el procesador de registro reconoce que losdatos ya se normalizaron y empaquetaron en el MIB correspondiente y no esnecesario reformatearlos. El procesador de registro envía el evento en el Modificadorclave de eventos.

6. El Modificador clave de eventos agrega un ID único a los datos y envía los datos almarcador de propiedad de eventos.

7. El marcador de propiedad de evento infiere los valores de datos adicionales, porejemplo, categoría, dispositivo y tipo de dispositivo, y agrega el evento al cachéactivo.

8. El Escritor genérico en línea administra la transferencia del caché activo en la tablagenericevents_live en la base de datos de eventos. El evento es ahora una alerta deViPR SRM.

9. El front-end primario de ViPR SRM accede a la base de datos de eventos para generarlos informes de alertas.

10. Los usuarios de la Consola ven y administran las alertas a través de los informes dealertas.

Formato de mensaje de evento y trap normalizadoEl proceso de normalización transforma los datos de eventos en un formulario aceptablepara el MIB de Watch4Net. Los datos de eventos normalizados y el mensaje de SNMPtrap enviados desde el back-end de alertas al escritor de evento utilizan el mismoformato.

Los datos de eventos deben cumplir con la Alerta Trap MIB Watch4net de MIB.

A modo de referencia, este es el formato de datos de eventos normalizados. Para cadapropiedad en el trap, hay un OID específico como se muestra a continuación.

<variablename-conversion from=".1.3.6.1.4.1.11970.1.1.2.0" to="_device" /> <variablename-conversion from=".1.3.6.1.4.1.11970.1.1.2.1" to="_devtype" /> <variablename-conversion from=".1.3.6.1.4.1.11970.1.1.2.2" to="_part" /> <variablename-conversion from=".1.3.6.1.4.1.11970.1.1.2.3" to="_parttype" /> <variablename-conversion from=".1.3.6.1.4.1.11970.1.1.2.4" to="_sourceeventtype" /> <variablename-conversion from=".1.3.6.1.4.1.11970.1.1.2.5" to="_value" /> <variablename-conversion from=".1.3.6.1.4.1.11970.1.1.2.6" to="_severity" /> <variablename-conversion from=".1.3.6.1.4.1.11970.1.1.2.7" to="_fullmsg" /> <variablename-conversion from=".1.3.6.1.4.1.11970.1.1.2.8" to="_Source" /> <variablename-conversion from=".1.3.6.1.4.1.11970.1.1.2.9" to="_OpenedAt" />


Formato de mensaje de evento y trap normalizado 99

<variablename-conversion from=".1.3.6.1.4.1.11970.1.1.2.10" to="_category"/> <variablename-conversion from=".1.3.6.1.4.1.11970.1.1.2.11" to="_sourceip"/> <variablename-conversion from=".1.3.6.1.4.1.11970.1.1.2.12" to="_sourcedomainname"/> <variablename-conversion from=".1.3.6.1.4.1.11970.1.1.2.13" to="_userdefined1"/> <variablename-conversion from=".1.3.6.1.4.1.11970.1.1.2.14" to="_userdefined2"/> <variablename-conversion from=".1.3.6.1.4.1.11970.1.1.2.15" to="_userdefined3"/> <variablename-conversion from=".1.3.6.1.4.1.11970.1.1.2.16" to="_userdefined4"/> <variablename-conversion from=".1.3.6.1.4.1.11970.1.1.2.17" to="_userdefined5"/> <variablename-conversion from=".1.3.6.1.4.1.11970.1.1.2.18" to="_userdefined6"/> <variablename-conversion from=".1.3.6.1.4.1.11970.1.1.2.19" to="_eventname"/> <variablename-conversion from=".1.3.6.1.4.1.11970.1.1.2.20" to="_eventstate"/> <variablename-conversion from=".1.3.6.1.4.1.11970.1.1.2.21" to="_eventdisplayname"/> <variablename-conversion from=".1.3.6.1.4.1.11970.1.1.2.22" to="_systemdefined1"/>  <variablename-conversion from=".1.3.6.1.4.1.11970.1.1.2.23" to="_systemdefined2"/> 

Acerca de las capturas en ViPR SRMExisten tres maneras posibles de utilizar capturas en el módulo de alertas.

Recepción de capturas como eventos (capturas de evento)Las capturas de eventos son aquellas recibidas por el receptor de condición de error desistemas de otros fabricantes. Por lo general, estas capturas indican un problema deestado en un dispositivo en particular. Las capturas de eventos se normalizan en elmodelo de alerta de ViPR SRM y se envían a Alerting Backend para su procesamiento.

Envío de capturas de alerta para agregar una alerta en la base de datos (capturas dealerta)Alerting Backend crea las capturas de alerta para eventos que se normalizan. Estoseventos requieren que se inserte una captura en la Base de datos de eventos(genericevents_live table). Alerting Backend crea esta captura y envía el evento alReceptor de condición de error. El Procesador de log reconoce las capturas de alerta y lasreenvía hasta la pila y dentro de la Base de datos de eventos.

Si utiliza el MIB correcto, puede enviar capturas de alerta al Receptor de condición deerror e incorporar sus propias alertas en la Base de datos de eventos. Puede comenzarcon la Plantilla de captura de alertas predeterminadas disponible en Alerting Frontendpara obtener contenido de capturas específico y un formato que se ajuste a MIB.

Envío de capturas a un sistema de otros fabricantes (capturas de otros fabricantes)Las capturas de otros fabricantes son aquellas que se envían desde ViPR SRM a otrosistema. Puede configurar estas capturas mediante la acción de SMNP Trap de AlertingFrontend. No hay ninguna diferencia entre las capturas de alerta y las capturas de otrosfabricantes, a excepción del destino de la información. Por lo general, se utilizan lascapturas de otros fabricantes porque el cliente tiene una herramienta de administraciónde alertas centralizada.

Acerca de Trap de alerta y Traps de borrado de alertasLa alerta Trap es el mecanismo para agregar un evento en la base de datos de eventos deViPR SRM. El Trap de borrado de alertas borra un trap de alerta emitido anteriormente.

El Trap de alerta y Trap de borrado de alertas son ViPR SRM. Cuando decimos "trap dealerta" en ViPR SRM, nos referimos al trap que se envía al escritor de evento genérico conun mensaje en un formato predefinido que se transforma y se escribe en la base de datosde eventos.

El Trap de borrado de alertas es un concepto similar que tiene un valor INACTIVO en elcampo eventstate. El trap de borrado de alertas es una manera de borrar una alerta enViPR SRM.

El módulo de alerta instalado incluye dos plantillas que facilitan la creación de lasacciones de Trap de alertas y Trap de borrado de alertas.

Las plantillas de Trap de alerta y Trap de borrado predeterminadas tienen las siguientescaracterísticas:

l Están configuradas previamente utilizando el host local como la dirección IP y elpuerto 2041, que es el puerto de receptor de trap SNMP predeterminado para queViPR SRM envíe el trap al escritor de evento. Por lo general, no necesita cambiar eso.

l Contienen los campos obligatorios para la entrada de la base de datos degeneric_events que se creará.

Adición de acciones de Captura de alertas y Captura de borrado de ViPR SRMPara escribir una alerta en la base de datos de eventos de ViPR SRM, use una acción deCaptura de alertas de SNMP en uno o más resultados en la definición de alerta. Esposible que también deba agregar la Captura de borrado de alertas para borrar la alertacuando sea necesario.

Esta tarea supone que creó una nueva definición de alerta y que ahora se deben agregarlas acciones de Captura de alertas y Captura de borrado a los resultados.

Procedimiento


Aparecen los símbolos gráficos de los componentes de la alertas.


3. Arrastre y suelte el símbolo SNMP Trap en el pizarrón.

Al soltar el método de arrastrar, aparece un cuadro de diálogo de configuración parala acción.


a. Para Template, elija una de las siguientes acciones:


Acerca de Trap de alerta y Traps de borrado de alertas 101

l Default Alert Trap Template para escribir la alerta en la base de datos deeventos.

l Default Clear Trap Template para borrar la alerta en la base de datos deeventos.

b. Para Name, escriba la frase que se visualizará en el símbolo de SNMP Trap, en larepresentación gráfica.

Por ejemplo, escriba Set Major Trap o Clear Major Trap.

c. Para Description, de manera opcional, escriba una descripción.

d. Para Host, por lo general, déjelo como localhost.

Esta es la dirección del servidor back-end primario. El valor puede ser localhostporque el front-end de alertas es una interfaz del usuario para el back-end.

Si envía una captura de otro origen, aquí debe especificar la dirección IP del back-end primario.

e. No cambie Port, Community, Generic ID o Enterprise specific ID.

5. Para Entry, deje tal como está en la plantilla o edite mediante las reglas de lasiguiente sección.

l Use el orden esperado de los campos, tal como se describe en la siguiente tabla.No cambie el orden de los campos.

l Separe cada campo con una coma. No use una coma dentro de un valor de campo.

l Para omitir un campo, utilice el valor null como marcador de posición para esevalor de campo.

l Los primeros 11 campos son obligatorios para crear informes precisos. Estoscampos se utilizan en los informes de alertas; por ello, es importante que todaslas entradas contengan valores para estos campos. Los campos subsiguientes sonopcionales.

l Para cualquier campo, utilice una variable o asigne el valor de forma explícita.Consulte las notas en la siguiente tabla.

l El formato de una variable es PROP.'propertyname', donde propertyname es uncampo en los datos de eventos de ViPR SRM.

6. Haga clic en Ok.

7. Adjunte la acción de Trap al resultado correcto en la definición.

a. Haga clic y arrastre desde un resultado situado en el lado derecho de un símbolo.

b. Arrástrelo hacia el cuadrado con contorno amarillo situado a la izquierda delsímbolo SNMP Trap y suéltelo cuando el cuadrado amarillo se vuelve verde.


c. Haga clic en Save y, a continuación, elija si desea guardar y habilitar, o guardar ydeshabilitar esta definición de alerta.

Formato y descripciones de mensajes de Trap de alerta y Trap de borradoLa entrada de Trap de alerta de ViPR SRM y Trap de borrado deben contener datos en elorden esperado y deben utilizar el valor NULL para omitir un campo de datos.



Reglas para la entrada de Trap de alerta y Trap de borradoUtilice estas reglas para el campo de entrada en el cuadro de diálogo de acción de SNMPTrap.

l Utilice el orden de campo obligatorio como se indica en la siguiente tabla.

l Separe cada campo utilizando una coma.

l Para omitir un campo, utilice el valor null como un marcador de posición para esevalor de campo.

l Algunos campos son obligatorios. Estos campos se utilizan para la indexación, parala asignación de nombre de manera exclusiva a una alerta y para filtros en losinformes de alerta.

l Para cualquier campo, utilice una variable o asigne el valor explícitamente. Consultelas notas en la siguiente tabla. En general, utilizar la variable siempre que seaposible es una mejor práctica.

l El formato para una variable es PROP.'propertyname', donde propertyname es uncampo en los datos de eventos deViPR SRM.

Orden de campo y explicaciones para la Trap de alerta de ViPR SRMLa siguiente tabla describe los datos en el campo de entrada de la alerta Trap de ViPRSRM. Los pedidos son importantes. Para omitir un elemento de datos, utilice el valorliteral null.

Tabla 6 Datos en un mensaje de alerta Trap

Nombre de campo Descripción Valor

0 device Requerido. Estoscampos se utilizan parala indexación eidentificación de laalerta y, por lo tanto, sedeben incluir. Loscampos proporcionaninformación sobre eldispositivo y el eventoque se produjo. Aunquepuede proporcionarvalores literales, utilizarlas variables PROP esuna mejor práctica parapasar en los valoresdesde el evento deorigen.

PROP.'device'

1 devtype PROP.'devtype'

2 Parte PROP.'part'

3 parttype PROP.'parttype'

4 sourceeventtype Asigne el evento comoDURADERO oMOMENTÁNEO. Si estásin asignar, de manerapredeterminada seclasificará comoMOMENTÁNEO.Los eventosMOMENTÁNEOS sepueden borrar mediante

Uno de los siguientes literales:

DURABLEMOMENTARY


Formato y descripciones de mensajes de Trap de alerta y Trap de borrado 103

Tabla 6 Datos en un mensaje de alerta Trap (continuación)


la acción del usuario,mientras que loseventos DURADEROSestán destinados a serborrados solo cuando seprocesa otro evento queborra el evento original.

5 value Un campo versátil quepuede contenercualquier valor. Por logeneral, este es un valorde métrica o estadopasado en el evento deorigen. Si las reglas detraducciónproporcionadas alprocesador de registrosiguen las mejoresprácticas, los detallesadicionales sobre elvalor aparecen en eltexto del evento o en elcampo fullmsg.

Para transmitir en un valor desde elevento de origen, utilice el literalsiguiente:VALUE

6 severity Opcional.Por lo general, senormaliza la severidad anivel del evento. Lamejor práctica es pasara ese valor utilizandoPROP.'severity'Si queda sin asignarmediante lanormalización y aquí, laseveridad pasa a suvalor predeterminado,que es 4 (nulo) yaparece en los informescomo UNKNOWN.

PROP.'severity' o asignar un valoraquí.

Puede usar la cantidad o el valorSNMP ENUM que se muestra en latabla siguiente. Estos valores setraducen como se muestra en losinformes.

Num SNMPENUM

se traduce en

1 critical CRITICAL

2 error MAJOR

3 warning MINOR

4 null UNKNOWN

5 info INFORMATIONAL

7 fullmsg Opcional. El mensajefácil de usar asociadocon este evento.

El mensaje puede incluir:

l Puntuación, excepto comas.

l El literal VALUE.

l Variables en el formulario dePROP.'fieldname'





8 Source El origen de datos parala alerta, como unnombre recopilador, unpuerto de escucha deeventos, un nombre MIBo un nombre de informe.

PROP.'source'

9 OpenedAt El registro de fecha yhora cuando ocurrió laalerta por primera vez.

El valor literal TMST es el único valor

válido.La marca de registro de fecha y horase asigna cuando se produce laalerta por primera vez, y este campo(openedat) sigue siendo consistentepara la duración de la alerta, inclusosi se actualiza la alerta.

10 category Una clasificación delevento.

PROP.'category' o asignar un valor.

11 sourceip La dirección IP delorigen de la alerta.

PROP.'sourceip'

12 sourcedomainname El nombre de dominiodel origen de la alerta.

PROP.'sourcedomainname'

13 userdefined1 Campos definidos por elusuario.

PROP.'userdefinedn' si el

archivo de configuración de reglasde procesador de registro para estetipo de evento asigna valores aestos campos. De lo contrario, seproporcionan los valores definidospor el usuario aquí.Ejemplos:

Contact: adminDept: IT

14 userdefined2

15 userdefined3

16 userdefined4

17 userdefined5

1-8 userdefined6

19 eventname Diseñado para describirla actividad delcomponente que es elorigen del evento. Paralas alertaspredeterminadasproporcionadas porSolutionPacks, unamejor práctica es unasola palabra para elevento, como inactivo,desconectado, afectado.

PROP.'eventname' o asignar unvalor

20 eventstate Requerido. Asigna si setrata de una Trap dealerta (ACTIVO) o una

Para mensajes de Trap de alerta,utilice el valor literal ACTIVE.

Para mensajes de Trap de borrado,utilice el valor literal INACTIVE.





Trap de borrado(INACTIVO).

21 eventdisplayname

22 systemdefined1 Reservado para usofuturo


Requisitos para un Trap de borradoUn Trap de borrado utiliza el mismo formato de mensaje que el Trap de alerta. Estas sonreglas adicionales para un Trap de borrado:

l Debe contener valores que coincidan con el Trap de alerta en los siguientes campos.De manera opcional, se pueden incluir otros campos.

Tabla 7 Datos en los mensajes de Trap de borrado

Nombre del campo Valor obligatorio para el Trap de borrado

0 dispositivo Igual que los valores utilizados para el Trap de alerta asociada. Unmejor práctica sería utilizar las variables de la siguiente manera:PROP.'device',PROP.'devtype',PROP.'part',PROP.'parttype'

1 devtype

2 Parte

3 parttype

9 openedat Utilice el valor literal TMST.

20

eventstate INACTIVE

l Asegúrese de utilizar el literal null para todos los campos omitidos.

Ejemplo 2 Ejemplos

Esta es una entrada de Trap de alerta para una alerta DURADERA con una severidadMAJOR.

PROP.'device',PROP.'devtype',PROP.'part',PROP.'parttype',DURABLE,VALUE,2,Backend PROP.'part' processing delay on server PROP.'device' is high (VALUE ms since last 5 minutes). Please verify server logs for more details. Performance of EMC M&R can be impacted.,PROP.'source',TMST,Performance,PROP.'ip',null,null,null,null,null,null,null,Backend error,ACTIVE

Tenga en cuenta lo siguiente acerca de esta entrada del Trap de alerta:

l El valor para fullmsg es muy largo e incluye referencias a tres variables(PROP.'part', PROP.'device' y VALUE).



Ejemplo 2 Ejemplos (continuación)

l La entrada omite sourcedomainname y los seis campos definidos por el usuario,utilizando NULL como marcadores de posición.

l El valor para eventname es Backend error.

l El valor para eventstate es ACTIVE.

Este es un Trap de borrado correspondiente para el Trap de alerta anterior. Este Trap deborrado contiene la cantidad mínima de campos que se requieren. Se podríaproporcionar más campos.

PROP.'device',PROP.'devtype',PROP.'part',PROP.'parttype',null,null,null,null,null,TMST,null,null,null,null,null,null,null,null,null,null,INACTIVE

Tenga en cuenta lo siguiente sobre la entrada de Trap de borrado anterior:

l Los valores de campos numerados 0, 1, 2, 3 y 9 (como se indica en la Tabla 7 en lapágina 106) son los mismos valores que se utilizan en la entrada de Trap de alerta.

l El valor NULL se utiliza para todos los campos omitidos.

l El valor para eventstate es INACTIVE.

¿Cómo se asignan las severidades de alerta?La severidad de alerta se asigna a cualquier alerta que se escriba en la base de datos.

La severidad se puede asignar en varios puntos en el proceso de consolidación dealertas.

1. Durante la normalización de alerta según lo especificado en los archivos de reglas.

2. En el Trap de alerta, ya sea pasando a través del valor PROP.'severity' (parapasar en el valor asignado durante la normalización) o mediante la utilización de unvalor constante en el mensaje de Trap de alerta. Puede usar ya sea el número enteroo el SNMP ENUM, según la siguiente tabla.

3. Si no hay severidad asignada en el Trap de alerta, se predetermina como 4(DESCONOCIDO).

La siguiente tabla muestra las severidades de alerta y los valores enumerados utilizadospara el Trap de alerta y la base de datos.

Num SNMP ENUM se traduce a este valor en la base de datos e informes

1 critical CRITICAL

2 error MAJOR

3 warning MINOR

4 null UNKNOWN



¿Cómo se asignan las severidades de alerta? 107

Descripciones de los componentes de alertasEn esta sección se proporcionan definiciones de referencia para todos los componentes ylos procesos en el subsistema de alertas de ViPR SRM.

Front-end de alerta

El Front-end de alertas existe en el Front-end de M&R y se accede a él en la consolautilizando Administration > Modules > Alerting. El Front-end de alertas contiene lasdefiniciones de alerta y sus dependencias. Este componente interactúa con uno omás back-ends de alertas.

Back-end de alertas

El Back-end de alertas recibe datos y alertas sobre los datos. Puede tener múltiplesBack-ends alertas en distintos servidores para distribuir la carga. Cada back-end dealertas contiene configuraciones de alertas, como definiciones, adaptadores y otrasdependencias que se establecen en el Front-end de alertas.

Un Back-end de alertas puede recibir datos de procesos de ViPR SRM o de otrosfabricantes. Por ejemplo, el back-end de alertas puede recibir datos de rendimientoenviados por un administrador recopilador a través de un conector de caché. Puederecibir eventos y flujos desde un Administrador de procesos de evento por medio deun Escritor genérico de eventos. También puede recibir informes para alertas desdeel Front-end de ViPR SRM o de otros fabricantes.

Para acceder a los archivos de registro y de configuración de Back-end de alertas,inicie sesión en la consola y vaya a Administration > Centralized Management >Logical Overview > Events > Alerting Backend::instanceName.

Definición de alerta

Una definición de alerta incluye un filtro que define los eventos a los que se aplica ladefinición. Un evento debe coincidir con un filtro en una definición de alerta válida yque esté habilitada para actuar sobre ella, incluyendo la escritura en la base dedatos.

Además del filtro, las definiciones de alerta incluyen acciones que describen cuáldebe ser el resultado de la condición de alerta. Las acciones incluyen notificacionespor correo electrónico, notificaciones de SNMP y una acción de Trap de alertaespecial que hace que el evento se escriba en la base de datos de eventos. Si unadefinición de alerta no incluye una acción de Trap de alerta, los eventos manejadospor esa definición de alerta no llegan a la base de datos y no aparecen en losinformes.

Los componentes opcionales adicionales en una definición de alerta son lasoperaciones y las condiciones que manipulan y evalúan los valores de las métricas afin de determinar qué acción debe ser realizada, si es necesario.

Cada SolutionPack agrega su propio conjunto de definiciones de alertacorrespondientes durante la instalación de SolutionPack. Las definicionespersonalizadas también son posibles.

Para ver, personalizar y crear definiciones de alerta, inicie sesión en la consola yvaya a Administration > Modules > Alerting > Local Manager > Alert definitions.



Adaptadores.

Un evento es una estructura básica que incluye un registro de fecha y hora, nombrede evento, nombre de parte, nombre de dispositivo, etc. Los adaptadores tomancualquier dato y lo transforman en ese modelo.

El formato de datos de evento es el mismo que el formato de Trap de alerta, ya queutiliza solo un subconjunto de los campos que utiliza un Trap de alerta. El Trap dealerta acepta datos desde el evento utilizando el formato PROP.'fieldname'.

ViPR SRM está instalado con un conjunto de adaptadores preconfigurados quemanejan los tipos de traducciones descritas en esta guía. La operación típica norequiere nuevos adaptadores ni cambios en la configuración de los adaptadoresinstalados.

Los adaptadores que se instalan con ViPR SRM son:

Adaptador de escucha de conexión de valores de APG

Este adaptador escucha en el puerto 2010 en busca de valores del conector enel archivo collecting.xml. Los datos tienen las propiedades de adapterName,que contiene el nombre de este adaptador y adapterType, que contiene elRVSocketListener.

Escucha métricas recopiladas y las traduce a los datos de eventos. Los datosdel evento incluyen campos que identifican el origen de los datos(adaptername y adapterType).

Adaptador de consolidación de alertas

Este adaptador escucha en un conector (puerto 2013) en busca de eventosinternos entrantes. Los datos resultantes tendrán las propiedades deadapterName, que contiene el nombre de este adaptador y adapterType, quecontiene el EventAdapter.

Adaptador de datos del informe de APG

Este adaptador acepta datos desde Informes exportados (calendarizados) ytraduce los datos en datos de eventos consolidados. Los datos resultantesincluyen adapterName = APGReportData y adapterType = Eventadapter, ademásde cualquier valor creado mediante las fórmulas de front-end.

Receptor de condición de error

Un receptor de condición de error predeterminado está instalado en /opt/APG/Event-Processing/Trap-Receiver/Alert-Consolidation en el servidor primario de back-end. El receptor de condición de error, en el puerto 2041, desempeña dos funcionesen el flujo de procesamiento de evento.

Traps de dispositivos externos

Una manera de ingresar los eventos al proceso de consolidación de alertas escomo un SNMP trap desde un dispositivo externo. La información en el trap senormaliza y, a continuación, se pasa por el back-end de alertas. El back-end dealertas hace coincidir el evento normalizado con una definición de alerta, y elevento ingresa al flujo de emisión de alertas comunes.

Si un dispositivo usa traps para consolidar alertas, SolutionPack para esedispositivo instala archivos MIB y archivos de reglas adecuados para ayudar atraducir el trap a una alerta. Estos archivos se almacenan como archivos deconfiguración para el receptor de condición de error.


Descripciones de los componentes de alertas 109

Traps de alerta de definiciones de alerta

Para que un evento se escriba en la base de datos de eventos y se convierta enuna alerta de ViPR SRM, el evento debe coincidir con un filtro en una definiciónde alerta activa que incluye una acción de Trap de alerta.

La acción de Trap de alerta se utiliza para cualquier tipo de evento en elproceso de consolidación de evento, independientemente de cómo ingresaronoriginalmente al proceso.

El receptor de condición de error escucha en busca de ambos tipos de trapsentrantes en el puerto 2041, los procesa de acuerdo con la configuración y los envíaal componente siguiente, el procesador de eventos de registro.

Para ver los archivos de configuración de receptor de condición de error (incluyendotodos los archivos MIB y de reglas instalados por SolutionPacks), inicie sesión en laconsola y vaya a Administration > Centralized Management > Logical Overview >Events > Trap Receiver - Alert Consolidation.

La Guía de administración de receptor de condición de error, también disponible en esapágina, describe la configuración predeterminada del receptor de condición de errorinstalado y el formato de los archivos de reglas requerido.

Escucha genérica de eventos

El puerto de escucha genérico de eventos recopila eventos que provienen deorígenes. Por ejemplo, VMAX genera sus propios eventos y el puerto de escuchagenérico de eventos los recopila. El puerto de escucha genérico de eventos escuchalos eventos en un conector TCP usando el puerto 2040 y reenviando los eventos alprocesador de registro de eventos.

Es poco frecuente que necesite modificar los archivos de configuración para elpuerto de escucha genérico del evento. Sin embargo, para verlos, inicie sesión en laconsola y vaya a Administration > Centralized Management > Logical Overview >Events > Generic-Event-Listener :: Alert Consolidation.

Modificador clave de eventos

Este componente crea una clave única para cada evento y asigna ese valor para elcampoid del evento.

Es poco frecuente que necesite modificar los archivos de configuración para elmodificador de clave de evento. Sin embargo, para verlos, inicie sesión en laconsola y vaya a Administration > Centralized Management > Logical Overview >Events > Event-Key-Modifier :: Alert Consolidation.

Marcador de propiedades de eventos

El marcador de propiedades de eventos puede agregar o cambiar datos en unevento, enriqueciendo los datos de eventos, mediante la obtención de datosadicionales de orígenes externos, como una base de datos o un archivo. ViPR SRMutiliza el marcador de propiedades de evento para resolver categorías de evento einformación de dispositivo para los datos de eventos, como se indica acontinuación:

l Categoría es una forma de clasificar eventos. Los usuarios de informes pueden,a continuación, ordenar en una columna de categoría o aplicar un filtro paralimitar un informe a una categoría específica. El archivo event-category.csv, que se incluye con los archivos de configuración, contieneasignaciones de categoría predeterminadas e incluye categorías de cadaSolutionPack.



l ViPR SRM aplica una propiedad de marcado de filtro en la dirección IP en unevento para consultar la base de datos de SRM y obtener los valores para eldispositivo y devtype asociados con la dirección IP. Este proceso completa elarchivo ip-to-devices.csv y hace que los informes de eventos sean másutilizables y significativos.

l Dispositivo crítico es una forma de identificar eventos desde dispositivos quelos usuarios consideran críticos. ViPR SRM incluye las alertas de informe dedispositivos críticos que enumeran estos eventos. El archivo ip-to-device.csv,que se incluye con los archivos de configuración, está vacío inicialmente. Lainterfaz de usuario en los informes de alertas proporciona una manera deagregar dispositivos críticos a esta lista. Consulte Cómo marcar un dispositivocomo crítico en la página 41.

Para ver los archivos de configuración del marcador de propiedades de eventos,inicie sesión en la consola y vaya a Administration > Centralized Management >Logical Overview > Events > Event-Property-Tagger :: Alert Consolidation.

La Guía de administración del marcador de propiedades de eventos, tambiéndisponible en la página, describe todas las funcionalidades del componente delmarcador de propiedades de eventos, en caso de que desee desarrollar funcionespersonalizadas de enriquecimiento de datos.

Procesador de registro de eventos

Este componente procesa todos los datos entrantes, independientemente de suorigen y convierte los datos en un formato de evento normalizado. Genera los datosrequeridos adicionales y luego envía los datos de eventos al componente demarcador de propiedades de eventos para mayor enriquecimiento.

El mapeo de los datos entrantes en el formato del evento normalizado es controladopor un conjunto de archivos XML que contiene reglas. Hay una regla de raíz, y, acontinuación, se evalúan reglas posteriores en una cadena hasta que se alcanzauna regla final. Cada SolutionPack instala reglas adecuadas para su dispositivo. Porejemplo:

l El SolutionPack de Brocade instala un archivo de reglas que mapea lainformación de Brocade SNMP MIB para el formato de datos de evento.

l El SolutionPack de VMAX instala un archivo de reglas que mapea eventosgenéricos enviados desde el VMAX al formato de datos de evento.

Puede crear nuevos archivos de reglas. Como mejor práctica, no edite los archivosexistentes, debido a los riesgos de que se sobrescriban durante una actualización.Para personalizar o agregar reglas nuevas para un dispositivo que ya tiene reglasconfiguradas por un SolutionPack, cree un archivo que solo tenga sus reglas nuevasy colóquelo en la cadena de archivos de reglas o copie el archivo existente ycámbiele el nombre antes de editarlo.

La Guía del Administrador de procesador de registro de eventosdescribe la arquitecturade procesamiento de los archivos de reglas. Esta guía contiene una referencia dereglas detallada. Allí están las reglas de análisis, marcado y coincidencia, ademásde un conjunto de reglas básicas.

Para acceder a la configuración del procesador de registro de eventos y archivos dereglas y la documentación asociada, inicie sesión en la consola y vaya aAdministration > Centralized Management > Logical Overview > Events > Event-Log-Processor :: Alert Consolidation.


Descripciones de los componentes de alertas 111

Escritor genérico de eventos

El escritor de evento serializa todos los eventos que vienen en él y los envía al back-end de alertas.

Los archivos de configuración de escritura genérica de evento especifican losnúmeros de puertos a utilizar. Cada número de puerto está asociado a un adaptadordiferente en el Front-end de alertas que actúa sobre los eventos recibidos.

Para acceder a estos archivos, inicie sesión en la consola y vaya a Administration >Centralized Management > Logical Overview > Events > Generic-Event-Writer :: AlertConsolidation.

Escritor genérico en línea

Este componente es responsable de la inserción y actualización de datos en la basede datos.

Los archivos de configuración de este componente contienen los siguientes tipos deinformación relacionados con el almacén de datos:

l Parámetros que se utilizan para conservar la base de datos, como: Un URI,nombre de usuario y contraseña para la base de datos.

l Período de retención en el plazo de días.

l Nombre de la tabla de la base de datos.

l Definiciones de mapeo que consisten en el campo nombre, tipo de datos ydescriptor de mapeo, que se utilizan para convertir los datos al formato correcto.

Para obtener acceso a los archivos de configuración de escritura genérica en vivo,inicie sesión en la consola y vaya a Administration > Centralized Management >Logical Overview > Events > Generic-Live-Writer :: Alert Consolidation.



CAPÍTULO 11

Crear alertas personalizadas

Los siguientes temas describen el proceso de creación de alertas personalizadas y laincorporación de estas en la base de datos e informes de alerta de ViPR SRM. Existencuatro orígenes para las alertas personalizadas.

l Crear alertas desde SNMP traps ..........................................................................114l Crear alertas de eventos que se envían a una escucha ....................................... 119l Crear alertas de métricas recopiladas .................................................................127l Creación de alertas desde los informes calendarizados ......................................130

Crear alertas personalizadas 113

Crear alertas desde SNMP trapsLos SNMP traps enviados desde dispositivos, redes u otros orígenes pueden ser el origende alertas.

Flujo de proceso para consolidar los eventos de SNMP trap en alertasUn evento podría ingresar al sistema como un SNMP trap enviado desde un dispositivoexterno.

Algunos ejemplos de dispositivos que envían SNMP traps a ViPR SRM incluyendispositivos VMAX, Brocade y Cisco. Un SNMP trap desde un origen externo se debeborrar mediante un Trap de borrado de SNMP desde el mismo origen. En las definicionesde alerta, debe haber pares de definiciones para traps y Traps de borrado subsiguientes.Para obtener más información, consulte la sección de Ejemplos que aparece acontinuación.

La siguiente figura muestra cómo se normalizan los SNMP traps desde dispositivosexternos en el sistema de emisión de alertas.

Figura 12 Flujo del proceso de emisión de alertas para eventos de SNMP trap

A continuación, se describe el flujo de procesamiento.

1. El origen externo envía un trap al puerto 2041 en el servidor de back-end primario.

2. Si el receptor de condición de error encuentra un MIB válido y el archivo de reglaspara el trap en sus archivos de configuración, se envía el evento al procesador deregistro para su normalización.

3. El procesador de registro mapea los datos en el formato de eventos de ViPR SRMmediante las reglas y los archivos MIB. Luego envía los datos de eventosnormalizado al escritor de eventos genéricos.

4. El escritor de eventos genéricos recopila y serializa todos los eventos. En este caso,envía el evento al puerto 2013, en el Back-end de alerta, donde escucha el adaptadorde consolidación de alertas.

5. El adaptador de consolidación de alertas comprueba la definición de alerta activadacon un filtro y en condiciones operacionales que coincidan con los datos de eventos.



6. Si la definición de alerta incluye una acción de alerta Trap, el evento se reenvía alreceptor de condición de error, donde el flujo de procesamiento de alerta comúnasume el control.

Los dispositivos como VMAX o switches Brocade utilizan este método para incorporarsus SNMP traps en el sistema de alertas de ViPR SRM. Los SolutionPacks para estosdispositivos instalan los siguientes archivos de soporte en las ubicacionescorrespondientes en la infraestructura:

l Archivo MIB (obligatorio): los MIB son específicos para el dispositivo de origen. ElSolutionPack instala el archivo de descripción de MIB en los archivos deconfiguración para el receptor de condición de error.

l archivo de reglas (obligatorio): se agregan los archivos de reglas al conjunto dearchivos de configuración para el receptor de condición de error. Las reglas en estearchivo son específicas para el MIB del dispositivo. El procesador de registro utilizalas reglas para mapear los datos de trap en el formato de evento normalizado.

l Definiciones de alerta (obligatorias): Las definiciones contienen los filtros queidentifican los nombres MIB y el origen del dispositivo cuyos traps se estánconsolidando. Un trap recibido debe coincidir con un filtro en una definición de alertapara convertirse en una alerta de ViPR SRM.

l valores de categoría (opcionales): Un SolutionPack puede especificar una categoríade identificación para cada evento mediante la inserción de líneas dentrodelevent-category.csvarchivo de configuración para el Tagger de propiedad delevento.

Ejemplo de un trap consolidado en una alerta y borradoObtenga información sobre cómo consolidar un trap en una alerta mediante un ejemplodesde el Seitch FC Brocade de SolutionPack.

Supongamos que un puerto de switch Brocade experimenta un cuello de botella y generaun trap de detección de cuello de botella denominado BdTrap. Si el switch Brocade estáconfigurado adecuadamente, envía esta trap a puerto 2041 en el servidor de back-endde ViPR SRM.

El receptor de condición de error retoma el trap y comprueba los archivos deconfiguración para un MIB que coincida con el trap.

En Administration > Centralized Management > Logical Overview > Events > Trap Receiver:Alert Consolidation, uno de los archivos de configuración se llama conf/BD-MIB.xml.Aquí se muestran las definiciones de bdTrap y bdClearTrap en ese archivo.

bdTrap NOTIFICATION-TYPE OBJECTS {userPortNumber, bdWinAvgTime, nBdType, bdThreshold, bdAggrStats, bdAbsoluteValue, swVfId, bdAvgFrameSize

} STATUS current DESCRIPTION "trap to be send for bottleneck detection." ::= { bdTraps 1 } bdClearTrap NOTIFICATION-TYPE OBJECTS {


Ejemplo de un trap consolidado en una alerta y borrado 115

userPortNumber, bdWinAvgTime, nBdType, bdThreshold, bdAggrStats, bdAbsoluteValue, swVfId, bdAvgFrameSize } STATUS current DESCRIPTION "trap to be send for bottleneck clearance." ::= { bdTraps 2 }END

En esa misma ubicación, otro archivo, conf/alert-consolidation-rules/brocade-alert-trap-rules.xml, define las reglas para traducir el bdTrap.

  <rule ip-address="*" oid=".1.3.6.1.4.1.1588.2.1.1.51.0.1" specific-id="*" generic-id="*" enterprise-id="*"> <handle destination="data"> <variablename-conversion from="nBdType" to="part" /> <constant-conversion key="attributename" value="swVfId" /> <constant-conversion key="severity" value="warning" /> <constant-conversion key="category" value="Performance" /> <constant-conversion key="Source" value="Brocade" /> <constant-conversion key="eventname" value="BottleneckDetected" /> <constant-conversion key="eventdisplayname" value="Bottleneck Detected" /> <constant-conversion key="sourcedomainname" value="bdTrap" /> <constant-conversion key="eventstate" value="ACTIVE" /> <constant-conversion key="devtype" value="FabricSwitch" /> <constant-conversion key="parttype" value="Port" /> </handle> </rule>

Nota

En el mismo archivo, hay otro elemento <rule> para una bdClearTrap.

El receptor de Trap determina que toda la información existe para la normalización deeste trap, de modo que reenvía el trap al procesador de registro. El procesador deregistro normaliza los datos y se enruta hacia el escritor de evento. El escritor de eventotransmite los datos al Back-end de alerta, donde el adaptador de la configuración dealerta pasa a través de los filtros en las definiciones de alertas activadas.

El evento coincide con el filtro en la definición de alerta con el nombreBrocadeBottleneck Detected, que se ha instalado por el Brocade de SolutionPack. La siguientecifra muestra el filtro en esta definición de alerta.

Figura 13 Filtrado en la definición de alerta detectada de cuello de botella Brocade.

Esta es la representación simbólica de la definición de alerta.

Figura 14 Definición de alerta de Brocade

Tenga en cuenta lo siguiente acerca de esta definición:

l No hay ninguna operación. Esta definición de alerta realiza la acción en cualquierevento que coincida con el filtro.

l La acción asociada con el bdTrap es otro trap: una alerta Trap. El Trap de alertainserta la información del trap original, que fue normalizada en campos de datos deViPR SRM por el procesador de registro, en el mensaje del Trap de alerta.

Esta es la configuración para el Trap de alerta:

Este trap envía un trap de alerta al host local en el puerto 2041.

El receptor de condición de error de SNMP retoma el Trap de Alerta creado recientementeen el puerto 2041 y lo reenvía a la cadena de procesamiento de alertas. El Modificadorclave agrega un ID único y el marcador de propiedad agrega una categoría, tipo dedispositivo y otros valores. El evento está escrito en la base de datos de eventos, dondeestá disponible para la creación de informes.

La alerta es DURADERA y permanece ACTIVA hasta que se reemplaza por otro trap quellega desde el dispositivo de Brocade que la borra. El trap que lo reemplaza deberíacontener los mismos valores de propiedades, como el dispositivo, devtype, parte,parttype, severidad y así sucesivamente, que identifiquen al trap más reciente como unaactualización del anterior. Sin embargo, sería un trap de borrado.


Ejemplo de un trap consolidado en una alerta y borrado 117

Observamos la definición bdClearTrap anteriormente en MIB. Hay una definición dealerta que coincide llamada Bottleneck Cleared, como puede ver en el árbol de ladefinición de alerta en la siguiente representación.Figura 15 Lista de definición de alertas de Brocade

La siguiente representación muestra el filtrado para la definición de alerta de borrado delcuello de botella.

Figura 16 Filtrado en la definición de alerta de cuello de botella borrado de Brocade

Cuando un bdClearTrap para el mismo puerto switch Brocade se procesa a través de laconsolidación de alertas, la alerta desde el bdTrap original se vuelve INACTIVA.

Creación de una alerta personalizada para una captura desde un origen externoSiga estos pasos para incorporar una captura enviada al receptor de condición de errordesde un origen externo en los informes de alertas de ViPR SRM.

Procedimiento

1. Configure el origen de la captura para enviarla al back-end primario de ViPR SRM,puerto 2041.

2. Asegúrese de que la descripción de MIB para la captura esté disponible.

a. Vaya a Administration > Centralized Management > Logical Overview > Events > TrapReceiver: Alert Consolidation.

b. En el panel derecho, haga clic en Configuration Files.

c. Seleccione un archivo MIB existente y haga clic en Edit o haga clic en Upload paraagregar un nuevo archivo MIB que contiene la descripción de este.

3. Agregue reglas para traducir los datos entrantes de captura en datos de eventonormalizados de ViPR SRM.

a. Para obtener información sobre las reglas y cómo crearlas, vaya a Administration >Centralized Management > Logical Overview > Events > Trap Receiver: AlertConsolidation y haga clic en el enlace situado en Documentation.



En la Guía de administración del receptor de condición de error se describen losrequisitos del archivo de reglas.

b. En la misma página de la consola, puede seleccionar un archivo de reglasexistente y hacer clic en Edit para agregar nuevas reglas a un archivo de reglasexistente (un archivo .xml). Alternativamente, haga clic en Upload para agregar unnuevo archivo de reglas.

4. Opcionalmente, asigne el valor category al evento.

El campo de datos category es una etiqueta descriptiva asignada a las alertas paraayudar a identificar el tipo de alerta. Category es una columna en los informes dealertas y los usuarios pueden ordenar los elementos de esa columna. Puede asignarun valor category a la alerta en el archivo de configuración que se describe aquí oen el mensaje de Captura de alertas.

Se entrega un conjunto de valores de categoría estándares con ViPR SRM. Puedeagregar una nueva categoría.

Para ver o agregar nuevos valores de categoría o para configurar la categoría de unevento específico:

a. Vaya a Administration > Centralized Management > Logical Overview > Events >Event-Property-Tagger::Alert-Consolidation.

b. En el panel derecho, haga clic en Configuration files.

c. Seleccione el archivo event-category.csv y haga clic en Edit.

d. Si realiza cambios, guarde el archivo.

5. Cree una nueva definición de alerta para el nuevo SNMP trap.

a. El filtro debe contener al menos el nombre de captura.

b. Incluya una acción de Captura de alertas.

6. Habilite la nueva definición de alerta.

7. Repita todos los pasos anteriores para una Captura de borrado correspondiente.

Crear alertas de eventos que se envían a una escuchaLos eventos que se envíen a la escucha de eventos desde orígenes externos pueden serel origen de alertas.

El flujo de proceso para eventos externos se envía al puerto de escucha de eventosUna alerta podría ingresar al sistema como un evento recopilado por el puerto deescucha de eventos genéricos.

Los eventos recopilados fluyen desde su origen original hasta el puerto de escucha deeventos genérico y, luego, mediante el escritor de eventos genérico para alcanzar elBack-end de alerta. Si existe una definición de alerta válida, el evento se transfiere en elflujo de alertas comunes.

La siguiente representación muestra cómo se normaliza un evento recopilado por unaescucha en el sistema de emisión de alertas.


Crear alertas de eventos que se envían a una escucha 119

Figura 17 Flujo de proceso de alertas para los eventos recopilados por una escucha

1. El origen externo envía un evento al puerto 2040 en el servidor de Back-end primario.

2. La Escucha genérica de eventos reenvía el evento al Procesador de registro.

3. El Procesador de registro mapea los datos en el formato de eventos de ViPR SRMmediante las reglas en un archivo de configuración de reglas. Luego envía los datosde eventos normalizados al Escritor genérico de eventos.

4. El Escritor genérico de eventos recopila y serializa todos los eventos. En este caso,envía el evento al puerto 2013, en el Back-end de alerta, donde escucha elAdaptador de consolidación de alertas.

5. El Adaptador de consolidación de alertas comprueba la definición de alerta activadacon un filtro y condiciones operacionales que coincidan con los datos de eventos.

6. Si la definición de alerta incluye una acción de Trap de alerta, el evento se reenvía alreceptor de condición de error, donde el flujo de procesamiento de alertas comunesasume el control.

Algunos SolutionPacks, como VNX, utilizan este método para agregar alertas en elsistema de alertas de ViPR SRM. Los SolutionPacks para estos dispositivos instalan lossiguientes archivos de soporte en las ubicaciones correspondientes en la infraestructura:

l reglas de archivos (opcionales): las reglas de archivos, si se proporcionan, sonañadidas al conjunto de archivos de configuración para el procesador de registro. Lasreglas en este archivo son específicas para el dispositivo y el procesador de registrolas utiliza para mapear los datos de eventos en el formato de eventos normalizados.En algunos casos, se aplican las reglas comunes y no se requieren reglas específicasdel dispositivo especiales. El componente de receptor de condición de error tienearchivos de reglas que se aplican a diversos dispositivos.

l definiciones de alerta (obligatoria): Las definiciones de alerta contienen filtros quecoinciden con los eventos desde los dispositivos. Un evento debe coincidir con unfiltro en una definición de alerta para convertirse en una alerta de ViPR SRM.

l valores de categoría (opcionales): Un SolutionPack puede especificar una categoríade identificación para cada evento mediante la inserción de líneas dentrodelevent-category.csvarchivo de configuración para el Marcador depropiedades de eventos.



Ejemplo de un evento externo consolidado en una alerta y borradoObtenga información sobre cómo consolidar un evento externo en una alerta de ViPRSRM mediante un ejemplo del SolutionPack de VNX.

Supongamos que un VNX tiene un componente RAID que se está acercando a sucapacidad máxima. El VNX genera el siguiente mensaje de evento y datos de evento:

FreeCapacity for Raid Group 1 is at 0.003547906%RAVNXBlock-RAIDGroupAPM00135132006RAIDGroup1RAID-51PercentageFreeCapacityGroup Percent Free Space

Si el VNX está configurado adecuadamente, envía este evento al puerto 2040 en elservidor de back-end de ViPR SRM. El puerto de escucha de eventos genéricos retoma elevento en el puerto 2040 y lo envía al procesador de registro, que normaliza los datos deeventos VNX en el formato de alerta adecuado. En el caso de eventos VNX, el mapeo esdirecto mediante las reglas del receptor de condición de error y no se necesita ningúnarchivo de reglas adicional de procesador de registro. Los datos de eventos, acontinuación, se enrutan al Back-end de alerta, donde el adaptador de configuración dealerta los envía a través de los filtros en las definiciones de alerta.

El evento coincide con la definición de alerta llamada Entrada de espacio libre del grupoRAID, que se ha instalado por el SolutionPack de VNX. La siguiente representaciónmuestra el filtro en esta definición de alerta.

Figura 18 Filtrar en una definición de alerta de VNX

La siguiente figura muestra la representación simbólica de la definición de alerta.


Ejemplo de un evento externo consolidado en una alerta y borrado 121

Figura 19 Definición de alerta VNX

Tenga en cuenta lo siguiente acerca de esta definición:

l La operación es una declaración de casos en el campo con el nombre Espacio libre.

l Los comparadores examinan el valor de dicho campo.

l La acción asociada con cada comparador es un Trap de alerta.

l Una cadena de comparadores con severidades decrecientes desencadena accionesde trap que anulan las acciones anteriores.

l El último trap es un trap de borrado. Fue creado usando la plantilla de Trap deborrado.

Suponiendo que el evento que estamos siguiendo cumple con el criterio del primercomparador, se realiza el Trap de alerta asociado con el primer comparador. La maneraen la que se configura el trap hace que sea un Trap de alerta. Esta es la configuración:



Este trap se envía al host local en el puerto 2041 y utiliza el formato de mensaje de Trapde alerta. El valor 1 en el séptimo campo de datos hace que el alerta sea CRÍTICA.

El receptor de condición de error de SNMP retoma el evento en el puerto 2041 y se hacecargo el proceso de emisión de alertas comunes. La siguiente representación muestra elevento como una alerta crítica en el informe All Alerts.


Ejemplo de un evento externo consolidado en una alerta y borrado 123

Figura 20 Eventos VNX en el informe de todas las alertas

Al hacer clic en la fila en el informe de todas las alertas se muestran todos los detallesacerca de esta alerta.



Figura 21 Informe detallado para el evento VNX

Creación de una alerta personalizada a partir de un evento externoSiga estos pasos para crear una alerta a partir de un evento que llega al puerto deescucha de eventos genéricos.

Procedimiento

1. Configure el origen para enviar eventos a la escucha de eventos en el back-endprimario, puerto 2040.

2. De manera opcional, cree y cargue un archivo de reglas.

Los archivos de reglas se agregan al conjunto de archivos de configuración para elprocesador de registro. Las reglas de este archivo son específicas del dispositivo, y elprocesador de registro las utiliza para mapear los datos de eventos en el formato deeventos normalizados. En algunos casos, no se requieren reglas especiales si lasreglas asociadas con el receptor de condición de error cubren el caso de uso.Para crear y cargar el archivo de reglas:


Creación de una alerta personalizada a partir de un evento externo 125

a. Vaya a Administration > Centralized Management > Logical Overview > Events >Event-Log-Processor::Alert-Consolidation.

b. En el panel derecho, obtenga información sobre un formato de archivo de reglas:

l Para abrir la documentación en la que se describe el formato y uso del archivode reglas, desplácese hasta el encabezado Documentation y haga clic en APG-Event-Log-Processor.pdf.

l Para abrir un archivo de reglas existente y ver ejemplos, expanda Configurationfiles, seleccione cualquier archivo cuyo nombre contenga rules y haga clic enEdit o Download.

c. Cree un archivo de reglas con cualquier editor de texto.

d. Para cargar el archivo de reglas, haga clic en Upload a File y siga las instrucciones.

3. Opcionalmente, asigne el valor category al evento.

El campo de datos category es una etiqueta descriptiva asignada a las alertas paraayudar a identificar el tipo de alerta. Category es una columna en los informes dealertas y los usuarios pueden ordenar los elementos en esa columna. Puede asignarun valor category a la alerta en el archivo de configuración que se describe aquí oen el mensaje de Captura de alertas.

Se entrega un conjunto de valores de categoría estándares con ViPR SRM. Puedeagregar una nueva categoría.

Para ver o agregar nuevos valores de categoría o para configurar la categoría de unevento específico:

a. Vaya a Administration > Centralized Management > Logical Overview > Events >Event-Property-Tagger::Alert-Consolidation.

b. En el panel derecho, haga clic en Configuration files.

c. Seleccione el archivo event-category.csv y haga clic en Edit.

d. Si realiza cambios, guarde el archivo.

4. Cree una definición de alerta que contenga al menos estos componentes:

a. Un filtro que define el evento con el cual coincide.

El marcador de propiedad de eventos también utiliza filtros. En el caso de lasdefiniciones de alerta preconfiguradas de VMAX, el marcador de propiedad deeventos ya aplicó el filtro source = VMAX*. El filtro de las definiciones de alertalo perfecciona aún más.

b. Una acción de Captura de alertas.

c. Una acción de Captura de borrado.

Nota

Solo las alertas DURADERAS necesitan una acción de Captura de borrado.

5. Habilite la definición de alerta.



Crear alertas de métricas recopiladasLos umbrales definidos en las métricas recopiladas por los recopiladores ViPR SRMpueden ser el origen de las alertas.

Flujo de proceso de alertas: eventos de umbral de métricaUna alerta podría ingresar al sistema como una métrica que se recopila mediante unrecopilador que cruza un valor de umbral definido.

Algunos ejemplos de alertas que se originan como una métrica recopilada que cruza unvalor de umbral son métricas de dispositivo, red y estado del servidor, como capacidad,disponibilidad o latencia. El recopilador de ViPR SRM envía métricas al back-end dealertas. Si existe una definición de alerta válida, el evento se crea y se transfiere en elflujo de alerta.

La siguiente figura muestra cómo se captura y normaliza un evento en el sistema dealertas.

Figura 22 Flujo de proceso de alerta para eventos de umbral de métrica

1. Los recopiladores de SRM ViPR envían métricas al Back-end de alerta en el puerto2010. Todo el flujo de métricas recopiladas mediante el Back-end de alerta.

2. El Back-end de alerta busca una definición de alerta que incluya al menos el nombredel recopilador y el nombre del campo de la métrica.

3. El Back-end de alerta lleva a cabo las operaciones, condiciones y acciones en ladefinición de alerta.

4. La definición de alerta contiene, por lo general, un componente de comparador quedefine un umbral para la métrica.

5. Cuando las condiciones en la definición de alerta conducen a una acción de Trap dealerta de SNMP, el Back-end de alerta reenvía el Trap de alerta al receptor decondición de error.

6. El flujo de proceso de emisión de alertas comunes se hace cargo en este punto.


Crear alertas de métricas recopiladas 127

Ejemplo de métrica recopilada que se consolidó en una alertaObtenga información sobre cómo consolidar una métrica recopilada en una alertamediante un ejemplo de M&R Health SolutionPack.

Obtenga información sobre cómo consolidar una métrica recopilada en una alertamediante un ejemplo de M&R Health SolutionPack.

Supongamos que un servidor M&R se está sobrecargando y comienza a experimentaruna alta utilización de CPU.

La definición de alerta con el nombre Server CPU Utilization captura apariciones de altautilización de CPU mediante el filtrado de la métrica de CPUTimePercentage que serecopila mediante el recopilador APG_HEALTH. Este es el filtro:Figura 23 Filtro para una definición de alerta de métrica recopilada

La definición de alerta incluye una operación (que no se muestra aquí) en la que serealiza un promedio de los tres valores de sondeo para usarlo como valor comparativo.

Dos comparadores definen las condiciones para crear y eliminar las alertas Importantes yMenores. Estos son los comparadores y las acciones. Las acciones de trap asignan loscampos de datos recopilados en el mensaje trap. Ninguna otra regla de conversión esobligatoria. Los recopiladores envían los datos en el formato correcto.



Figura 24 Acciones para una definición de alerta de métrica recopilada

Si edita los Comparadores, verá que la parte superior está configurada en >70 y la parteinferior en >30. Se produce una alerta principal cuando el de uso de la CPU es de >70%.Esa alerta se elimina cuando el uso cae por debajo del 70% y se produce una alertaMenor. La alerta Menor se borra cuando el uso es inferior al 30%.

Creación de una alerta personalizada a partir de una métrica recopiladaSiga estos pasos para crear una nueva alerta a partir de una métrica recopilada quesupera un umbral.

Las métricas recopiladas son específicas de SolutionPack. Para crear alertas basadas enmétricas recopiladas, debe estar familiarizado con los recopiladores y las métricas queestos recopilan.

Procedimiento

1. Cree una definición de alerta que contenga:

a. Un filtro que incluye al menos campos de nombre y origen, como se indica acontinuación:

l source=collector_namel name=metric_name

b. Comparadores o algún otro modo para indicar los valores de umbral.

c. Acciones de captura de alertas cuando se supera el umbral.


Creación de una alerta personalizada a partir de una métrica recopilada 129


Creación de alertas desde los informes calendarizadosLas métricas que aparecen en los informes pueden ser el origen de una alerta.

Flujo de proceso para alertar sobre un informe calendarizadoUna alerta podría ingresar al sistema como una métrica desde un informe calendarizado.

Puede configurar un informe para alertas utilizando el calendario, una herramienta deinforme. Los datos desde un informe calendarizado para alertas se convierten en elformulario XML y, a continuación, analizan los datos de alertas mediante el adaptador dedatos del informe de APG.

Los datos de alertas se envían al Back-end de alerta, donde se evalúan mediantedefiniciones de alerta. Este método de alertas depende de una definición de alerta quefiltra en el nombre del informe y uno o más nombres de métricas de informe. Ladefinición de alerta define las condiciones que generarán una alerta, como un valor quese supera.

Puede evaluar cualquier métrica que aparezca en el informe. También puede usar lasoperaciones en la definición de alerta para crear un nuevo valor de la métrica de losdatos en el informe y generar alertas sobre el valor calculado.

Ejemplo de una alerta de una métrica de informe calendarizadoEn este ejemplo, se crea una alerta con los datos del informe Servers Summary de ViPRSRM y una de las definiciones de alerta de ejemplo.

Supongamos que consulta con frecuencia el informe EMC M&R Health > ServersSummary para monitorear el estado del servidor. Actualmente, supervisa la utilización deCPU y el uso de memoria para detectar signos de servidores sobrecargados. Decide quesería conveniente utilizar alertas a fin de rastrear esas métricas.

Procedimiento

1. Desplácese hasta el informe que contiene las métricas necesarias.

2. Haga clic en Tools > Schedule this report y calendarice el informe:

a. Proporcione información de ejecución en la pestaña Schedule.

b. Solicite que la información de alertas se genere para cada ejecución calendarizadaen la pestaña Alert.

3. Navegue hacia My Reports > Scheduled reports > report_name, haga clic con el botónsecundario en el informe e inícielo.

La primera solicitud de ejecución del informe crea una instancia de un nuevoadaptador requerido, el adaptador APG Report Data, si aún no existe. La solicitud deinicio agrega y habilita el adaptador. Para comprobar el estado del adaptador,navegue hacia Administration > Modules > Alerting > Local Manager > Adapter.Cada ejecución de un informe calendarizado para alertas genera una versión XML delinforme.

4. Abra la versión XML del informe a fin de obtener valores de cadena del nombre delinforme y los nombres de métricas.

a. Vaya a Administration > Centralized Management > Logical Overview > Backends >Alerting Backend >



b. En el panel derecho, expanda Configuration Files.

c. Seleccione conf/alerting-contexts. xml y haga clic en Edit.

d. En la <table-element> de la línea 3, observe el atributo de nombre. Este es elnombre del informe que se utilizará en la definición de alerta.

Nota

Utilice el valor de nombre exactamente como aparece, incluidos los caracteres deespacio.

e. En el elemento <table><header>, observe los valores <th>. Estos son los nombres demétricas que se utilizarán en la definición de alerta.

Nota

Para los nombres de métricas, use el valor <th>, pero elimine los caracteres deespacio.

f. En el elemento <data>, observe los valores de métricas.

Servers\ Summary_2015-02-04_14h01.xml<?xml version="1.0"?><table-element xmlns="http://www.watch4net.com/APG/Web/XmlReport1" xmlns:xmime="http://www.w3.org/2005/05/xmlmime" name="Servers Summary" id="c7cc3392" type="entity"> <report-preferences paging="10"/> <table> <header> <th>Hostname</th> <th>IP Address</th> <th>O.S. Type</th> <th>O.S. Version</th> <th>EMC M&R Modules Installed</th> <th>CPU Utilization (%)</th> <th>Memory Usage (%)</th> <th>Swap Usage (%)</th> <th>Highest severity</th> </header>

<data> <tr id="ecf83800"> <ts>collector01</ts> <ts>192.168.1.21</ts> <ts>Linux</ts> <ts>3.10.0-123.20.1.el7.x86_64</ts> <tv numeric-value="6" state="undefined">6</tv> <tv numeric-value="2.61" state="ok">2.61</tv> <tv numeric-value="64.1" state="undefined">64.1</tv> <tv numeric-value="0.0" state="undefined">0.0</tv> <te reason="missing"/> </tr> <tr id="6b76ac45"> <ts>frontend01</ts> <ts>192.168.1.24</ts> <ts>Linux</ts> <ts>3.10.0-123.20.1.el7.x86_64</ts> <tv numeric-value="20" state="undefined">20</tv> <tv numeric-value="7.08" state="ok">7.08</tv> <tv numeric-value="19.8" state="undefined">19.8</tv> <tv numeric-value="0.0" state="undefined">0.0</tv> <te reason="missing"/>


Ejemplo de una alerta de una métrica de informe calendarizado 131

</tr> <tr id="ce5c0c47"> <ts>backend01</ts> <ts>192.168.1.22</ts> <ts>Linux</ts> <ts>3.10.0-123.20.1.el7.x86_64</ts> <tv numeric-value="9" state="undefined">9</tv> <tv numeric-value="3.47" state="ok">3.47</tv> <tv numeric-value="42.5" state="undefined">42.5</tv> <tv numeric-value="0.0" state="undefined">0.0</tv> <te reason="missing"/> </tr> <tr id="ce5c0c48"> <ts>backend02</ts> <ts>192.168.1.23</ts> <ts>Linux</ts> <ts>3.10.0-123.20.1.el7.x86_64</ts> <tv numeric-value="9" state="undefined">9</tv> <tv numeric-value="3.66" state="ok">3.66</tv> <tv numeric-value="40.1" state="undefined">40.1</tv> <tv numeric-value="0.0" state="undefined">0.0</tv> <te reason="missing"/> </tr> </data> </table></table-element>

5. Una definición de alerta filtra el nombre del informe y las métricas de interés y luegoescribe información en un archivo de registro.

El adaptador APG Report Data analiza el informe XML y genera datos de alertas deeste. La definición de alerta filtra los datos generados de las alertas y actúa sobreestos.

Una definición de alerta simple para nuestro caso de uso contiene solo un filtro depunto de entrada y una acción de registro. Crea entradas de cada vez que se ejecutael informe calendarizado.

a. Este es el filtro de la definición de alerta:

reportName=='Servers Summary'& (name=='CPUUtilization(%)' | name=='MemoryUsage(%)')

Nota

Observe que los caracteres de espacio se conservan en el nombre del informe yque se eliminaron en los nombres de métricas.

b. Este es el contenido de una entrada agregada por la acción de registro.

Device = PROP.'Hostname', IPAddress = PROP.'IPAddress', OS Type = PROP.'O.S.Type', OS Version =PROP.'O.S.Version' PROP.'name' = VALUE

Las propiedades disponibles son las propiedades, los valores y los atributosseleccionados en la página de configuración del informe del informe.

c. Las configuraciones adicionales del archivo de registro, como el nombre de ruta yel período de retención de las entradas del archivo de registro, son los elementosde configuración del componente de acción del registro.



6. Inicie el informe calendarizado nuevamente y, a continuación, vaya hasta el destinode archivo de registro configurado, y abra el archivo de registro.

El resultado del registro se ve así:

[17:22:06 CET] Device = collector01, IP Address = 192.168.1.21, OS Type = Linux, OS Version = 3.10.0-123.20.1.el7.x86_64 --> CPUUtilization(%) = 2.04[17:22:06 CET] Device = collector01, IP Address = 192.168.1.21, OS Type = Linux, OS Version = 3.10.0-123.20.1.el7.x86_64 --> MemoryUsage(%) = 68.7[17:22:06 CET] Device = backend02, IP Address = 192.168.1.23, OS Type = Linux, OS Version = 3.10.0-123.20.1.el7.x86_64 --> MemoryUsage(%) = 42.7[17:22:06 CET] Device = backend02, IP Address = 192.168.1.23, OS Type = Linux, OS Version = 3.10.0-123.20.1.el7.x86_64 --> CPUUtilization(%) = 3.04[17:22:06 CET] Device = backend01, IP Address = 192.168.1.22, OS Type = Linux, OS Version = 3.10.0-123.20.1.el7.x86_64 --> MemoryUsage(%) = 46.7[17:22:06 CET] Device = backend01, IP Address = 192.168.1.22, OS Type = Linux, OS Version = 3.10.0-123.20.1.el7.x86_64 --> CPUUtilization(%) = 3.18[17:22:06 CET] Device = frontend01, IP Address = 192.168.1.24, OS Type = Linux, OS Version = 3.10.0-123.20.1.el7.x86_64 --> MemoryUsage(%) = 26.3[17:22:06 CET] Device = frontend01, IP Address = 192.168.1.24, OS Type = Linux, OS Version = 3.10.0-123.20.1.el7.x86_64 --> CPUUtilization(%) = 8.59

7. Para obtener una definición de alerta más compleja, consulte la siguiente definiciónde alerta:

Administration > Modules > Alerting > Alert definitions > Examples > Alert on APGReport .En el ejemplo de Alert on APG Report se incluyen los comparadores que pruebanvalores específicos y escriben entradas de registro únicamente cuando los valoressuperan los umbrales.

Análisis de datos de informeEl adaptador de datos del informe APG analiza los datos en los informes calendarizadosque recibe.

El adaptador de datos del informe APG genera datos de alertas de los informescalendarizados. Los datos y las propiedades relacionadas dependen del tipo de informe.

Cada punto de datos en un informe, como un punto en un gráfico o en la fila de una tablacon una columna de valor, tiene como consecuencia una línea de datos que puede serevaluada por una definición de alerta.

Propiedades comunesCada línea de salida de datos de alerta por el adaptador de datos del informe APG tienelas siguientes propiedades.

registro de fecha y horavalornombreNombre de informe

Las propiedades mostradas con sus valores desde el encabezado del informe se incluyencon las líneas de datos de alerta desde el informe. Si se trata de un informe mixto, laslíneas de alertas de los datos de cada informe secundario tienen estas propiedades


Análisis de datos de informe 133

comunes, aunque normalmente las propiedades se utilizan solo en los informesindividuales para un único dispositivo.

TablasCada fila en la tabla de un informe se traduce en una línea de datos de alerta porcolumna de valor que puede ser evaluada por una definición de alerta.

l La columna de valor de la tabla se utiliza para la evaluación de la definición dealerta, a menos que se especifique algo más para la evaluación, como un campo enuna operación de cadena.

l El nombre de columna de la columna de valor se utiliza como el valor de propiedadde la propiedad nombre. El nombre es lo que el editor de informes denominó comocolumna.

l Los datos de otras columnas de tabla son ingresados como propiedades adicionales;sus nombres de columna se utilizan como los nombres de propiedad. El nombre es loque el editor de informes denominó como columna.

GráficosEn un gráfico de serie de tiempo estándar, cada registro de fecha y hora (punto en elgráfico) genera una línea de datos de alerta que se pueden evaluar. En un gráfico concuatro líneas (métricas), en cada registro de fecha y hora hay cuatro líneas de datos.

El valor del nombre de propiedad deriva de la leyenda, incluso si se oculta la leyenda talcomo sucede en los informes mixtos.

Para la barra horizontal y los gráficos circulares, cada categoría en el gráfico se convierteen una línea de datos de alerta que contiene la siguiente información:

l Valor relativo en porcentaje de la métrica en comparación con las otras categorías.

l Valor de la propiedad nombre, que es el nombre del informe.

l Registro de fecha y hora de cada línea de datos de alerta, que, para este tipo deinformes, corresponde a cuándo se generó el informe en lugar del período de tiempoque abarca el informe. Se recomienda no utilizar estos tipos de informe para alertasbasadas en tiempo.

l Propiedad de la sección para cada línea de datos de alerta, que corresponde a laleyenda para la categoría informada en los datos.

l AbsoluteValue es el valor absoluto de la métrica para la categoría para el período deinforme.

l TotalValue es la suma de los valores absolutos para cada categoría en el gráfico.

Gráficos de baseLos gráficos de base son como otros gráficos de series temporales con estascaracterísticas adicionales:

l Una línea de datos de alerta se crea para cada registro de fecha y hora con el valor dela métrica y su nombre, según el contenido de la leyenda, utilizando el valor de lapropiedad nombre.

l Se agrega la propiedad del valor de base, que es un promedio de la métrica en elmomento especificado durante el último mes.

l Se agrega la propiedad del mínimo de base, que es el valor mínimo registrado para lamétrica en el momento especificado durante el último mes.

l Se agrega la propiedad del máximo de base, que es el valor máximo registrado parala métrica en el momento especificado durante el último mes.

Puede usar una fórmula para variar la longitud de la base en lugar de utilizar el valorpredeterminado, que es las últimas cuatro semanas.



Creación de una alerta de informe calendarizadoSiga estos pasos para configurar las alertas a partir de los datos de un informecalendarizado.

Procedimiento

1. Calendarice el informe para la emisión de alertas:

a. En la consola, navegue hasta el informe que tenga la métrica que desea alertar yhaga clic en Tools > Schedule this report.

b. En la pestaña Scheduling, defina con qué frecuencia y cuándo se debe ejecutareste informe.

c. En la pestaña Alert, seleccione Local Manager.

d. Haga clic en Save.

2. Habilite el adaptador APG Report Data.

a. Vaya a Administration > Modules > Alerting > Local Manager > Adapters.

b. Busque el adaptador APG Report Data. Si se encuentra en la lista de adaptadores,utilice la tabla situada en el panel derecho para asegurarse de que estéhabilitado.

Si el adaptador no aparece, realice el siguiente paso.

3. (Paso único) Agregue el adaptador APG Report Data:

a. En la consola de usuario, vaya a My Reports > Scheduled Reports.

b. En el panel derecho, haga clic con el botón secundario en el informe quecalendarizó para la emisión de alertas y elija Launch now.

Esta acción agrega el adaptador APG Report Data a la lista de adaptadores en el casode que no esté ahí y lo habilita.

4. Cree una definición de alerta que incluya:

a. Un filtro que identifica el nombre del informe y una o varias métricas.

l 'reportname==report name'l 'name==metric name'

b. Condiciones que evalúan la métrica y definen las rutas de resultado.Opcionalmente, puede incluir operaciones que crean nuevos valores de métricas apartir de los datos de métricas de entrada.

c. Para que la alerta aparezca en los informes de alertas, incluya las acciones dealerta de Captura de alertas y Captura de borrado de SNMP en las rutas deresultado. Otras acciones también son válidas, como registro, correo electrónico onotificaciones de SNMP.


6. Vuelva a iniciar el informe o espere la siguiente ejecución calendarizada.

Cada vez que se ejecuta el informe, Alerting Backend recibe los datos, y genera oborra las alertas cuando se cumplen las condiciones en la definición de alerta.

Puede usar el sondeo para simular las condiciones y probar los resultados.


Creación de una alerta de informe calendarizado 135

CAPÍTULO 12

Crear definiciones de alerta personalizadas

Los siguientes temas describen los requisitos para las definiciones de alertas de ViPRSRM y cómo crearlas.

l Definiciones de alerta en la consola ................................................................... 138l Componentes en una definición de alerta........................................................... 138l Para obtener más información acerca de los componentes y definiciones de alerta

........................................................................................................................... 142l Creación de definiciones de alerta...................................................................... 143l Acerca de Trap de alerta y Traps de borrado de alertas........................................ 144l Plantillas y cuadros agrupados............................................................................150l Creación de carpetas de definición de alerta....................................................... 150l Formato de mensaje de evento y trap normalizado ............................................. 151

Crear definiciones de alerta personalizadas 137

Definiciones de alerta en la consolaUna definición de alerta contiene un conjunto de componentes configurables. El Front-end de alerta representa los componentes en una interfaz gráfica.

El Front-end de alerta proporciona una interfaz gráfica para ver, modificar, configurar ycrear definiciones de alerta. Para agregar un nuevo componente, arrastre y suelte unsímbolo gráfico. Para especificar las relaciones entre componentes y el flujo delprocesamiento, arrastre y suelte los conectores. Para ver o cambiar la configuración decada componente, utilice cuadros de diálogo asociados.

Las siguientes son algunas razones por las que es posible que necesite crear una nuevadefinición de alerta:

l La alerta sobre la función de informe calendarizado permite a los usuarios de consolagenerar alertas en base a los valores informados o computados en los informes. Serequiere una definición de alerta que filtre en el informe calendarizado.

l Los desarrolladores pueden crear nuevas definiciones de alerta para filtrar lasmétricas que no están incluidas en las definiciones de alerta inmediatas, pero estándisponibles en los traps inmediatos, los eventos o las métricas recopiladas.

l Los desarrolladores podrían desear capturar nuevos tipos de eventos o SNMP trapsdesde dispositivos de otros fabricantes.

Componentes en una definición de alertaUna definición de alerta contiene al menos un filtro de punto de entrada y una acción.Puede contener varios puntos de entrada y acciones, y operaciones opcionales ycondiciones que manipulan y evalúan los elementos de datos en los datos de eventos.

Punto de entradaEl punto de entrada es el filtro que define qué eventos se manejan mediante estadefinición de alerta. El filtro funciona en los campos (propiedades) en los datos deevento.

Nota

En este punto en el proceso de emisión de alertas, los datos de eventos se normalizan enun formato estándar, pero el evento aún no está en ninguna base de datos. Por lo tanto,es posible que el asistente de filtrado no pueda indicarle todos los valores válidos. Paraescribir un filtro, puede ser necesario investigar el origen del evento y sus reglas denormalización.

Este es un ejemplo de un filtro de punto de entrada para la definición de alerta BackendProcessing Delay en la carpeta EMC M&R Health. El origen de esta alerta es la métricadenominada ProcessingDelay recopilada por el recopilador APG_Health.



Figura 25 Filtrado en una definición de alerta

Un filtro de alerta normalmente incluye una prueba para el origen del evento. La siguientetabla muestra algunos nombres de campo utilizados con frecuencia para filtrar en losorígenes de eventos en ViPR SRM.

Tipo de evento Filtro de origen de evento Ejemplo

umbralesbasados enmétricas derecopiladores

source=='collector_name' source=='APG_HEALTH'

eventos delpuerto deescucha deeventos

source=='name_GenericEvent' Source=='VMAX-GenericEvent'

eventos de trapsSNMP

Source='vendor_in_MIB%' &( sourcedomainname==MIB_data_field

Source='Cisco%' & ( sourcedomainname=='cieLinkDown' | sourcedomainname=='cieLinkUp')

eventos de losinformescalendarizados

source=='report_name' reportName=='apgreport'

OperacionesLas operaciones evalúan los datos entrantes para ver si deben ir al próximo componenteo se descartan. Un gran conjunto de operaciones están disponibles, incluyendo asunto,aritmética, agregación, ventanas de tiempo, fecha, entre otros. Consulte la secciónsiguiente Para obtener más Información

Esta es una operación de ventana de tiempo que calcula un promedio.


Componentes en una definición de alerta 139

Figura 26 Operador en una definición de alerta

CondicionesLas condiciones le permiten configurar varios resultados en la misma definición dealerta. Cada resultado se basa en los efectos de una condición y, por lo general, habríadistintas acciones asociadas con estas. Hay dos tipos de condiciones disponibles.

l Los comparadores le permiten definir pruebas de valor. Una técnica común en ViPRSRM es una cadena de comparadores, cada uno con un valor comparador diferente.Los resultados son una serie de traps SNMP que crean traps importantes,principales, menores y finalmente un trap de borrado, todo en la misma propiedad yen la misma definición de alerta.

l Los Contadores le permiten contar las apariciones dentro de un rango de tiempoespecífico.

Este es un ejemplo de un comparador que utiliza las acciones de registro comoresultados. Los eventos procesados por esta definición de alerta no lo hacen en la basede datos de eventos debido a que falta la acción del Trap de alerta.

Figura 27 Comparador con dos rutas de resultado

AccionesSe encuentran disponibles las siguientes acciones:

l Un Trap de alerta de SNMP o un Trap de borrado, que obtiene el evento en la base dedatos de alertas o posteriormente lo borra.



l Una acción de registro, que escribe el evento en un archivo de registro.

l Una notificación de correo electrónico, que envía un correo electrónico a direccionesconfiguradas previamente.

l Un trap SNMP a un tercero, como otro sistema de administración.

Este es un conjunto de comparadores, cada uno asociado con dos rutas de resultado. Elcontenido de la alerta Trap en cada acción es muy similar. La diferencia sería la severidadque está definida en el contenido del trap.

Figura 28 Acciones en una definición de alerta

Ejemplo: Combinación de todas las herramientasEsta es una definición de alerta que contiene dos puntos de entrada para definir doscampos de datos y, luego, ejecuta varias operaciones para obtener un valor nuevo. Haytres pruebas condicionales en ese valor y las acciones de resultado son una serie deTraps de alerta con diferentes niveles de severidad y los Traps de borradocorrespondientes.


Componentes en una definición de alerta 141

Figura 29 Ejemplo de definición de alerta

Este es el Porcentaje de alerta de espacio libre del sistema de archivos en la carpetaEMC M&R Health, en caso de que desee explorar como están configurados todos loscomponentes.





Las plantillas de Trap de alerta y Trap de borrado predeterminadas tienen las siguientescaracterísticas:l Están configuradas previamente utilizando el host local como la dirección IP y el

puerto 2041, que es el puerto de receptor de trap SNMP predeterminado para queViPR SRM envíe el trap al escritor de evento. Por lo general, no necesita cambiar eso.


Para obtener más información acerca de los componentes ydefiniciones de alerta

Más recursos están disponibles para el aprendizaje sobre las definiciones de alerta.

Técnicas para la creación de definiciones de alertaPuede aprender técnicas para el desarrollo de definiciones de alerta mediante lavisualización de las existentes. En la consola, vaya a Administration > Modules > Alerting >



Local Manager > Alert Definitions. Haga clic en una definición de alerta en el panelderecho y seleccione Edit para abrirlo.

l Para las técnicas de alertas generales, busque en las definiciones de alerta en lacarpeta Examples.

l Para técnicas específicas de ViPR SRM, mire las definiciones de alerta en las carpetasde SolutionPack.

Referencia de componentePara obtener más información acerca de los componentes de definición de alerta, hagaclic en Help en el banner de la consola y, a continuación, busque la sección Alerting >Creating alert definitions > Alert definition reference.

La referencia contiene explicaciones de todos los tipos de componente, incluyendo todaslas operaciones y todas las condiciones y cómo usarlos.

Creación de definiciones de alertaPuede usar los ejemplos de definición de alerta para comenzar a crear definiciones dealerta.

Procedimiento

1. En la página de alertas, haga clic en Alert definitions.

2. Haga cli en el ícono New element situado encima del árbol.

3. Arrastre el Filtered Entry Point hacia el espacio en blanco y defínalo.

El filtro de punto de entrada funciona como lo hacen los filtros de informes en lainterfaz del usuario principal.

La diferencia entre usar un filtro en el Alerting Frontend y Backend radica en lassugerencias que se muestran en el asistente. El Alerting Backend no está vinculado auna base de datos, por lo que la lista de propiedades y valores conocidos se crea enel tiempo de ejecución. Por este motivo, es normal no tener sugerencias al usar deinmediato el asistente después de iniciar el Alerting Backend.

4. Expanda el tipo de componente con el que desea trabajar y arrástrelo hacia elpizarrón.

5. Defina el componente.

Cada componente tiene conectores, que son puntos de color rojo. Para enlazar loscomponentes, haga clic en un conector del primer componente y, luego, en elconector del componente al cual desea enlazarlo. Aparece una flecha de conexiónque vincula los componentes.

No existe un límite en la cantidad de objetos que se pueden enlazar a la mismasalida.

Para mover los componentes, arrástrelos.

6. Cuando haya terminado de crear la definición de alerta, haga clic en Save.

7. En Name, escriba un nombre para la definición de alerta.

8. En Description, escriba una descripción para la definición de alerta.

9. Haga clic en Save and enable o Save and disable.


Creación de definiciones de alerta 143





Las plantillas de Trap de alerta y Trap de borrado predeterminadas tienen las siguientescaracterísticas:

l Están configuradas previamente utilizando el host local como la dirección IP y elpuerto 2041, que es el puerto de receptor de trap SNMP predeterminado para queViPR SRM envíe el trap al escritor de evento. Por lo general, no necesita cambiar eso.


Adición de acciones de Captura de alertas y Captura de borrado de ViPR SRMPara escribir una alerta en la base de datos de eventos de ViPR SRM, use una acción deCaptura de alertas de SNMP en uno o más resultados en la definición de alerta. Esposible que también deba agregar la Captura de borrado de alertas para borrar la alertacuando sea necesario.

Esta tarea supone que creó una nueva definición de alerta y que ahora se deben agregarlas acciones de Captura de alertas y Captura de borrado a los resultados.

Procedimiento


Aparecen los símbolos gráficos de los componentes de la alertas.


3. Arrastre y suelte el símbolo SNMP Trap en el pizarrón.

Al soltar el método de arrastrar, aparece un cuadro de diálogo de configuración parala acción.


a. Para Template, elija una de las siguientes acciones:



l Default Alert Trap Template para escribir la alerta en la base de datos deeventos.

l Default Clear Trap Template para borrar la alerta en la base de datos deeventos.

b. Para Name, escriba la frase que se visualizará en el símbolo de SNMP Trap, en larepresentación gráfica.

Por ejemplo, escriba Set Major Trap o Clear Major Trap.

c. Para Description, de manera opcional, escriba una descripción.

d. Para Host, por lo general, déjelo como localhost.

Esta es la dirección del servidor back-end primario. El valor puede ser localhostporque el front-end de alertas es una interfaz del usuario para el back-end.

Si envía una captura de otro origen, aquí debe especificar la dirección IP del back-end primario.

e. No cambie Port, Community, Generic ID o Enterprise specific ID.

5. Para Entry, deje tal como está en la plantilla o edite mediante las reglas de lasiguiente sección.

l Use el orden esperado de los campos, tal como se describe en la siguiente tabla.No cambie el orden de los campos.

l Separe cada campo con una coma. No use una coma dentro de un valor de campo.

l Para omitir un campo, utilice el valor null como marcador de posición para esevalor de campo.

l Los primeros 11 campos son obligatorios para crear informes precisos. Estoscampos se utilizan en los informes de alertas; por ello, es importante que todaslas entradas contengan valores para estos campos. Los campos subsiguientes sonopcionales.

l Para cualquier campo, utilice una variable o asigne el valor de forma explícita.Consulte las notas en la siguiente tabla.

l El formato de una variable es PROP.'propertyname', donde propertyname es uncampo en los datos de eventos de ViPR SRM.

6. Haga clic en Ok.

7. Adjunte la acción de Trap al resultado correcto en la definición.

a. Haga clic y arrastre desde un resultado situado en el lado derecho de un símbolo.

b. Arrástrelo hacia el cuadrado con contorno amarillo situado a la izquierda delsímbolo SNMP Trap y suéltelo cuando el cuadrado amarillo se vuelve verde.


c. Haga clic en Save y, a continuación, elija si desea guardar y habilitar, o guardar ydeshabilitar esta definición de alerta.

Formato y descripciones de mensajes de Trap de alerta y Trap de borradoLa entrada de Trap de alerta de ViPR SRM y Trap de borrado deben contener datos en elorden esperado y deben utilizar el valor NULL para omitir un campo de datos.



Reglas para la entrada de Trap de alerta y Trap de borradoUtilice estas reglas para el campo de entrada en el cuadro de diálogo de acción de SNMPTrap.

l Utilice el orden de campo obligatorio como se indica en la siguiente tabla.

l Separe cada campo utilizando una coma.

l Para omitir un campo, utilice el valor null como un marcador de posición para esevalor de campo.

l Algunos campos son obligatorios. Estos campos se utilizan para la indexación, parala asignación de nombre de manera exclusiva a una alerta y para filtros en losinformes de alerta.

l Para cualquier campo, utilice una variable o asigne el valor explícitamente. Consultelas notas en la siguiente tabla. En general, utilizar la variable siempre que seaposible es una mejor práctica.

l El formato para una variable es PROP.'propertyname', donde propertyname es uncampo en los datos de eventos deViPR SRM.

Orden de campo y explicaciones para la Trap de alerta de ViPR SRMLa siguiente tabla describe los datos en el campo de entrada de la alerta Trap de ViPRSRM. Los pedidos son importantes. Para omitir un elemento de datos, utilice el valorliteral null.

Tabla 8 Datos en un mensaje de alerta Trap


0 device Requerido. Estoscampos se utilizan parala indexación eidentificación de laalerta y, por lo tanto, sedeben incluir. Loscampos proporcionaninformación sobre eldispositivo y el eventoque se produjo. Aunquepuede proporcionarvalores literales, utilizarlas variables PROP esuna mejor práctica parapasar en los valoresdesde el evento deorigen.

PROP.'device'

1 devtype PROP.'devtype'

2 Parte PROP.'part'

3 parttype PROP.'parttype'

4 sourceeventtype Asigne el evento comoDURADERO oMOMENTÁNEO. Si estásin asignar, de manerapredeterminada seclasificará comoMOMENTÁNEO.Los eventosMOMENTÁNEOS sepueden borrar mediante

Uno de los siguientes literales:

DURABLEMOMENTARY





la acción del usuario,mientras que loseventos DURADEROSestán destinados a serborrados solo cuando seprocesa otro evento queborra el evento original.

5 value Un campo versátil quepuede contenercualquier valor. Por logeneral, este es un valorde métrica o estadopasado en el evento deorigen. Si las reglas detraducciónproporcionadas alprocesador de registrosiguen las mejoresprácticas, los detallesadicionales sobre elvalor aparecen en eltexto del evento o en elcampo fullmsg.

Para transmitir en un valor desde elevento de origen, utilice el literalsiguiente:VALUE

6 severity Opcional.Por lo general, senormaliza la severidad anivel del evento. Lamejor práctica es pasara ese valor utilizandoPROP.'severity'Si queda sin asignarmediante lanormalización y aquí, laseveridad pasa a suvalor predeterminado,que es 4 (nulo) yaparece en los informescomo UNKNOWN.

PROP.'severity' o asignar un valoraquí.

Puede usar la cantidad o el valorSNMP ENUM que se muestra en latabla siguiente. Estos valores setraducen como se muestra en losinformes.

Num SNMPENUM

se traduce en

1 critical CRITICAL

2 error MAJOR

3 warning MINOR

4 null UNKNOWN


7 fullmsg Opcional. El mensajefácil de usar asociadocon este evento.

El mensaje puede incluir:

l Puntuación, excepto comas.

l El literal VALUE.

l Variables en el formulario dePROP.'fieldname'





8 Source El origen de datos parala alerta, como unnombre recopilador, unpuerto de escucha deeventos, un nombre MIBo un nombre de informe.

PROP.'source'

9 OpenedAt El registro de fecha yhora cuando ocurrió laalerta por primera vez.

El valor literal TMST es el único valor

válido.La marca de registro de fecha y horase asigna cuando se produce laalerta por primera vez, y este campo(openedat) sigue siendo consistentepara la duración de la alerta, inclusosi se actualiza la alerta.

10 category Una clasificación delevento.

PROP.'category' o asignar un valor.

11 sourceip La dirección IP delorigen de la alerta.

PROP.'sourceip'

12 sourcedomainname El nombre de dominiodel origen de la alerta.

PROP.'sourcedomainname'

13 userdefined1 Campos definidos por elusuario.

PROP.'userdefinedn' si el

archivo de configuración de reglasde procesador de registro para estetipo de evento asigna valores aestos campos. De lo contrario, seproporcionan los valores definidospor el usuario aquí.Ejemplos:

Contact: adminDept: IT

14 userdefined2

15 userdefined3

16 userdefined4

17 userdefined5

1-8 userdefined6

19 eventname Diseñado para describirla actividad delcomponente que es elorigen del evento. Paralas alertaspredeterminadasproporcionadas porSolutionPacks, unamejor práctica es unasola palabra para elevento, como inactivo,desconectado, afectado.

PROP.'eventname' o asignar unvalor

20 eventstate Requerido. Asigna si setrata de una Trap dealerta (ACTIVO) o una

Para mensajes de Trap de alerta,utilice el valor literal ACTIVE.

Para mensajes de Trap de borrado,utilice el valor literal INACTIVE.





Trap de borrado(INACTIVO).

21 eventdisplayname



Requisitos para un Trap de borradoUn Trap de borrado utiliza el mismo formato de mensaje que el Trap de alerta. Estas sonreglas adicionales para un Trap de borrado:

l Debe contener valores que coincidan con el Trap de alerta en los siguientes campos.De manera opcional, se pueden incluir otros campos.

Tabla 9 Datos en los mensajes de Trap de borrado

Nombre del campo Valor obligatorio para el Trap de borrado

0 dispositivo Igual que los valores utilizados para el Trap de alerta asociada. Unmejor práctica sería utilizar las variables de la siguiente manera:PROP.'device',PROP.'devtype',PROP.'part',PROP.'parttype'

1 devtype

2 Parte

3 parttype

9 openedat Utilice el valor literal TMST.

20

eventstate INACTIVE

l Asegúrese de utilizar el literal null para todos los campos omitidos.

Ejemplo 3 Ejemplos

Esta es una entrada de Trap de alerta para una alerta DURADERA con una severidadMAJOR.

PROP.'device',PROP.'devtype',PROP.'part',PROP.'parttype',DURABLE,VALUE,2,Backend PROP.'part' processing delay on server PROP.'device' is high (VALUE ms since last 5 minutes). Please verify server logs for more details. Performance of EMC M&R can be impacted.,PROP.'source',TMST,Performance,PROP.'ip',null,null,null,null,null,null,null,Backend error,ACTIVE

Tenga en cuenta lo siguiente acerca de esta entrada del Trap de alerta:

l El valor para fullmsg es muy largo e incluye referencias a tres variables(PROP.'part', PROP.'device' y VALUE).



Ejemplo 3 Ejemplos (continuación)

l La entrada omite sourcedomainname y los seis campos definidos por el usuario,utilizando NULL como marcadores de posición.

l El valor para eventname es Backend error.

l El valor para eventstate es ACTIVE.

Este es un Trap de borrado correspondiente para el Trap de alerta anterior. Este Trap deborrado contiene la cantidad mínima de campos que se requieren. Se podríaproporcionar más campos.

PROP.'device',PROP.'devtype',PROP.'part',PROP.'parttype',null,null,null,null,null,TMST,null,null,null,null,null,null,null,null,null,null,INACTIVE

Tenga en cuenta lo siguiente sobre la entrada de Trap de borrado anterior:

l Los valores de campos numerados 0, 1, 2, 3 y 9 (como se indica en la Tabla 9 en lapágina 149) son los mismos valores que se utilizan en la entrada de Trap de alerta.

l El valor NULL se utiliza para todos los campos omitidos.

l El valor para eventstate es INACTIVE.

Plantillas y cuadros agrupadosViPR SRM incluye funciones que pueden ahorrar tiempo y proporcionar consistenciacuando se trabaja con definiciones de alerta.

Plantillas

Una plantilla, ahorra tiempo completando los campos de configuración de uncomponente de acción. ViPR SRM viene con algunas plantillas predefinidas y ustedpuede crear las suyas.

Cuadros agrupados

Esta función le permite dividir un conjunto de componentes para su uso en diversasdefiniciones de alerta. Por ejemplo, puede crear un objeto que represente unconjunto de operaciones y condiciones. Puede crear el conjunto de una vez como uncuadro agrupado y luego arrastrar el cuadro agrupado a diversas definiciones dealerta.

Para obtener más información acerca de las plantillas y los cuadros agrupados, haga clicen Help en el área de anuncio en la consola.

Creación de carpetas de definición de alertaPuede crear una nueva carpeta de definición de alerta al crear una nueva definición dealerta.

Si es necesario, cree una definición de alerta de marcador de posición para crear unanueva carpeta. Debe haber al menos una definición de alerta en una carpeta parapreservar la carpeta.

Procedimiento

1. Inicie sesión en la consola y vaya a Administration > Modules > Alerting > LocalManager > Alert definitions.



2. En el panel izquierdo, arriba del árbol de navegación, haga clic en el ícono Create anew element.

3. Arrastre el símbolo de entrada Filtrado hacia el pizarrón.

4. Dele un nombre al componente de entrada Filtrado.

Por ejemplo, asígnele el nombre Temporal.

5. Haga clic en OK y, a continuación, en Save.

6. Escriba un nombre para la nueva definición de alerta.

Por ejemplo, escriba Marcador de posición.

7. Para la Carpeta, seleccione la carpeta principal debajo de la cual desea que sucarpeta se anide y, a continuación, seleccione Add new folder.

Nota

Para hacer que una nueva carpeta de nivel superior, seleccione Add new folder en laparte inferior de la lista de carpetas.

8. Escriba el nombre de la carpeta.

Asegúrese de usar un nombre descriptivo que se corresponda con lo que la carpetarepresenta.

9. Haga clic en Save and disable.

La carpeta nueva y la definición de alerta de marcador de posición aparecen en elárbol de navegación.

10. Agregue o copie definiciones en la nueva carpeta.

Nota

Debe agregar al menos una alerta adecuada a la nueva carpeta antes de eliminar ladefinición de marcador de posición. Una carpeta sin definiciones de alertadesaparecerá.

Formato de mensaje de evento y trap normalizadoEl proceso de normalización transforma los datos de eventos en un formulario aceptablepara el MIB de Watch4Net. Los datos de eventos normalizados y el mensaje de SNMPtrap enviados desde el back-end de alertas al escritor de evento utilizan el mismoformato.

Los datos de eventos deben cumplir con la Alerta Trap MIB Watch4net de MIB.

A modo de referencia, este es el formato de datos de eventos normalizados. Para cadapropiedad en el trap, hay un OID específico como se muestra a continuación.

<variablename-conversion from=".1.3.6.1.4.1.11970.1.1.2.0" to="_device" /> <variablename-conversion from=".1.3.6.1.4.1.11970.1.1.2.1" to="_devtype" /> <variablename-conversion from=".1.3.6.1.4.1.11970.1.1.2.2" to="_part" /> <variablename-conversion from=".1.3.6.1.4.1.11970.1.1.2.3" to="_parttype" /> <variablename-conversion from=".1.3.6.1.4.1.11970.1.1.2.4"


Formato de mensaje de evento y trap normalizado 151

to="_sourceeventtype" /> <variablename-conversion from=".1.3.6.1.4.1.11970.1.1.2.5" to="_value" /> <variablename-conversion from=".1.3.6.1.4.1.11970.1.1.2.6" to="_severity" /> <variablename-conversion from=".1.3.6.1.4.1.11970.1.1.2.7" to="_fullmsg" /> <variablename-conversion from=".1.3.6.1.4.1.11970.1.1.2.8" to="_Source" /> <variablename-conversion from=".1.3.6.1.4.1.11970.1.1.2.9" to="_OpenedAt" /> <variablename-conversion from=".1.3.6.1.4.1.11970.1.1.2.10" to="_category"/> <variablename-conversion from=".1.3.6.1.4.1.11970.1.1.2.11" to="_sourceip"/> <variablename-conversion from=".1.3.6.1.4.1.11970.1.1.2.12" to="_sourcedomainname"/> <variablename-conversion from=".1.3.6.1.4.1.11970.1.1.2.13" to="_userdefined1"/> <variablename-conversion from=".1.3.6.1.4.1.11970.1.1.2.14" to="_userdefined2"/> <variablename-conversion from=".1.3.6.1.4.1.11970.1.1.2.15" to="_userdefined3"/> <variablename-conversion from=".1.3.6.1.4.1.11970.1.1.2.16" to="_userdefined4"/> <variablename-conversion from=".1.3.6.1.4.1.11970.1.1.2.17" to="_userdefined5"/> <variablename-conversion from=".1.3.6.1.4.1.11970.1.1.2.18" to="_userdefined6"/> <variablename-conversion from=".1.3.6.1.4.1.11970.1.1.2.19" to="_eventname"/> <variablename-conversion from=".1.3.6.1.4.1.11970.1.1.2.20" to="_eventstate"/> <variablename-conversion from=".1.3.6.1.4.1.11970.1.1.2.21" to="_eventdisplayname"/> <variablename-conversion from=".1.3.6.1.4.1.11970.1.1.2.22" to="_systemdefined1"/>  <variablename-conversion from=".1.3.6.1.4.1.11970.1.1.2.23" to="_systemdefined2"/>

CAPÍTULO 13

Alertas de la base de datos y caché activo

Los siguientes temas describen la base de datos de eventos.

l Base de datos de eventos................................................................................... 154l Caché activo....................................................................................................... 154l Propiedades de las alertas en una entrada de base de datos ..............................154

Alertas de la base de datos y caché activo 153










Caché activoEl caché activo es una copia exacta de la tabla genericevents_live que se conserva en lamemoria.

El sistema de emisión de alertas utiliza el caché activo para reducir la cantidad detransacciones de base de datos requerida. El uso del caché activo es una técnica deimplementación que se produce automáticamente y no requiere ningún administradorespecífico o interacciones del desarrollador.

Propiedades de las alertas en una entrada de base de datosLa siguiente tabla describe las propiedades en una entrada de alerta en la base de datosde eventos

Ambas tablas en la base de datos de eventos utilizan la misma definición de tabla. Lasdescripciones de campo que aparecen a continuación se aplican a ambas tablas de basede datos.

En la siguiente tabla:

l En la columna Null, cualquier campo marcado como No nunca puede ser nulo.

l En la columna Clave, cualquier campo marcado como múltiple o primario nunca debeestar en blanco. Estos campos forman una clave única para la fila del evento.



Tabla 10 Campos en una entrada de la base de datos de eventos

Campo Tipo Nulo

Clave Descripción

id bigint(20) SÍ MUL El ID de la alerta como existe en la base de datos.Asignado por el modificador clave durante laconsolidación de alertas.

name varchar(896) NO PRI El nombre único, o el índice, de una entrada dealerta. Para desactivar una alerta activa debecoincidir con este índice.La mejor práctica utilizada por la mayoría de lasimplementaciones de alerta de SolutionPack esgenerar nombre como:

like {device}_{parttype}_{part}_{eventname}

La definición se define en el archivo 07-threshold-trap-rules.xml.

openedat int(11) NO PRI El registro de fecha y hora cuando ocurre la alertapor primera vez.

count int(11) SÍ Cuántas veces se produjo la misma alerta.

eventstate varchar(64) SÍ El estado actual de la alerta, con valores deACTIVE o INACTIVE. La base de datos mantiene

este campo en sincronización con el campoactive.

source varchar(64) SÍ MUL El origen de la alerta.

parttype varchar(256) SÍ MUL El tipo de la parte en el que ocurrió la alerta.En la interfaz de usuario, este es el tipo decomponente.

Este es un campo obligatorio en el Trap de alertadebido a que se utiliza en el índice de la alerta.Consulte el campo name, arriba.

Parte varchar(512) SÍ La parte en la que se produjo la alerta.En la interfaz de usuario, este es el componente.

Este es un campo obligatorio en el Trap de alertadebido a que se utiliza en el índice de la alerta.Consulte el campo name, arriba.

eventname varchar(128) SÍ MUL El nombre de la alertaEste es un campo obligatorio en el Trap de alertadebido a que se utiliza en el índice de la alerta.Consulte el campo name, arriba.

parttypedisplayname

varchar(256) SÍ MUL El tipo de parte listo para la visualización dondeocurrió la alerta. El valor proviene del proceso deconsolidación de alertas.En la interfaz de usuario, este es el tipo decomponente.


Propiedades de las alertas en una entrada de base de datos 155

Tabla 10 Campos en una entrada de la base de datos de eventos (continuación)

Campo Tipo Nulo

Clave Descripción

partdisplayname

varchar(512) SÍ La parte lista para mostrar donde ocurrió la alerta.El valor proviene del proceso de consolidación dealertas.En la interfaz de usuario, este es el componente.

eventdisplayname

varchar(128) SÍ El nombre listo para la visualización de la alerta. Elvalor proviene del proceso de consolidación dealertas.

fullmsg varchar(512) SÍ Un mensaje que se utiliza para describir más acercade la alerta.

devtype varchar(256) SÍ El tipo de dispositivo en el que ocurrió la alerta.

device varchar(512) SÍ El dispositivo en el que ocurrió la alerta.Este es un campo obligatorio en el Trap de alertadebido a que se utiliza en el índice de la alerta.Consulte el campo name, arriba.

sourceip varchar(64) SÍ La dirección IP del origen de la alerta.

sourcedomainname

varchar(64) SÍ El nombre de dominio del origen de la alerta.

sourceeventtype

varchar(64) SÍ El tipo de evento del origen de la alerta.

valor varchar(64) SÍ El valor de la métrica o el atributo que ocasionó laalerta.

active tinyint(1) SÍ MUL Un valor TRUE (1) indica que esta alerta estáactualmente activa en el sistema. Este es un campomantenido por el sistema.

timestamp int(11) SÍ El registro de fecha y hora de la entrada másreciente de una alerta. Este es un campo mantenidopor el sistema.

closedat int(11) SÍ MUL La fecha y hora cuando se cerró la alerta (se volvióinactiva).

duration int(11) SÍ MUL La duración entre que la alerta estuvo ACTIVA hastaque estuvo INACTIVA. Este es un campo mantenidopor el sistema.

lastchangedat

int(11) SÍ MUL La fecha y hora cuando una alerta se actualizó porúltima vez. Este es un campo mantenido por elsistema.

isroot tinyint(1) SÍ MUL Reservado para uso futuro.

isproblem tinyint(1) SÍ Reservado para uso futuro.

reconocimiento

tinyint(1) SÍ MUL Un valor SÍ (1) indica que la alerta ha sidoreconocida por un usuario.Este campo se mantiene por el sistema enrespuesta a las acciones del usuario en la consola.




Campo Tipo Nulo

Clave Descripción

eventtype varchar(64) SÍ El tipo de evento. Los valores son MOMENTARY o

DURABLE.

Se asigna el valor en el Trap de alerta. Si se deja sinasignar, se establece de manera predeterminadacomo MOMENTARY

category varchar(64) SÍ MUL La categoría de la alerta como asignada en el Trapde alerta o inferida desde los archivos deconfiguración del procesador de registro deeventos.

eventtext varchar(2048) SÍ Una descripción de la alerta.

severity tinyint(4) SÍ MUL La severidad de la alerta tal como se la asigna en elTrap de alerta. Si no se asigna en el trap de alerta,el valor predeterminado es 4.

Num SNMP ENUM Traducir a

1 critical CRITICAL

2 error MAJOR

3 warning MINOR

4 null UNKNOWN


Impact bigint(20) SÍ Impacto de la alerta. No se usa actualmente en ViPRSRM.

certainty float SÍ La seguridad de la alerta. No se usa actualmente enViPR SRM.

inmaintenance

tinyint(1) SÍ Un valor SÍ (1) indica que el dispositivo en el que seproduce esta alerta actualmente está enmantenimiento. No se usa actualmente en ViPRSRM.

troubleticketid

varchar(64) SÍ No se usa actualmente en ViPR SRM. Puedeutilizarse con fines de integración con un sistemade administración de ticket de otros fabricantescomo el ID de la alerta en un sistema externo.

owner varchar(64) SÍ El propietario actual de la alerta. Mantenido por elsistema en respuesta a las acciones del usuario enla consola.

systemdefined1

varchar(512) SÍ Un campo personalizado que está reservado para eluso futuro de la Plataforma M&R y SolutionPack.

systemdefined2





Campo Tipo Nulo

Clave Descripción

systemdefined3


systemdefined4


systemdefined5


userdefined1

varchar(512) SÍ Un campo personalizado que el administrador delsistema puede modificar.Se puede utilizar en cualquier momento enacciones de definición de alerta, como acciones deregistro, correo electrónico o Trap de alerta.

userdefined2

varchar(512) SÍ Campos personalizados que se pueden utilizar parapropósitos específicos del cliente.Se puede utilizar en cualquier momento en un Trapde alerta u otras acciones.

userdefined3

varchar(512) SÍ

userdefined4

varchar(512) SÍ

userdefined5

varchar(512) SÍ

userdefined6

varchar(512) SÍ

userdefined7

varchar(512) SÍ Campos personalizados que se pueden utilizar paralos propósitos específicos del cliente.Se puede utilizar en un trap de alerta, pero necesitaconfiguración adicional en los archivos dethreshold-alert-rules.xml y 00-Initializer.xml

userdefined8

varchar(512) SÍ

userdefined9

varchar(512) SÍ

userdefined10

varchar(512) SÍ

userdefined11

varchar(512) SÍ

userdefined12

varchar(512) SÍ

userdefined13

varchar(512) SÍ

userdefined14

varchar(512) SÍ

userdefined15

varchar(512) SÍ




Campo Tipo Nulo

Clave Descripción

userdefined16

varchar(512) SÍ

userdefined17

varchar(512) SÍ

userdefined18

varchar(512) SÍ

userdefined19

varchar(512) SÍ

userdefined20

varchar(512) SÍ

enterprise varchar(512) SÍ

generic varchar(512) SÍ



CAPÍTULO 14

Temas de desarrollo adicionales

Los siguientes temas describen las funciones adicionales disponibles para expandir lafuncionalidad de la consolidación de alertas.

l Creación de una captura de alerta manual ..........................................................162l Script para generar alertas aleatorias.................................................................. 162l Receptor de condición de error como módulo independiente.............................. 163l Filtro de informe para alertas activas en comparación a alertas inactivas............ 166

Temas de desarrollo adicionales 161

Creación de una captura de alerta manualPuede enviar manualmente una captura a la base de datos de eventos. Este procesoomite completamente el Alerting Backend y no requiere una definición de alerta.

Procedimiento

1. Inicie sesión en la línea de comandos del SO en el servidor back-end primario.

2. Use el comando snmptrap para enviar una captura que asigna valores a los camposmediante los OID.

3. Revise el archivo de registro de consolidación de alertas para ver el contenido de laalerta.

4. Utilice una consulta de base de datos para buscar la entrada en la base de datos deeventos.

Script para generar alertas aleatoriasEl siguiente script proporciona una manera de generar rápidamente las alertas con finesde prueba.

#Prior to running this, execute '/opt/emc/vmutils/bin/vmutils-manager.sh' and install 'net-snmp'#!/bin/bashfor i in {1..100}do /usr/bin/snmptrap -v 2c -c public localhost:2041 '' .1.3.6.1.4.1.11970.1.1.2.1 .1.3.6.1.4.1.11970.1.1.2.0 s 'device'$i .1.3.6.1.4.1.11970.1.1.2.1 s 'devtype'$i .1.3.6.1.4.1.11970.1.1.2.2 s 'part'$i .1.3.6.1.4.1.11970.1.1.2.3 s 'parttype'$i .1.3.6.1.4.1.11970.1.1.2.4 s 'MOMENTARY' .1.3.6.1.4.1.11970.1.1.2.5 s 'value'$i .1.3.6.1.4.1.11970.1.1.2.6 s ''$(( ( RANDOM % 5 ) + 1 )) .1.3.6.1.4.1.11970.1.1.2.7 s 'msg'$i .1.3.6.1.4.1.11970.1.1.2.8 s 'source'$i .1.3.6.1.4.1.11970.1.1.2.10 s 'category'$i .1.3.6.1.4.1.11970.1.1.2.11 s 'ip'$i .1.3.6.1.4.1.11970.1.1.2.12 s 'domain'$i .1.3.6.1.4.1.11970.1.1.2.19



s 'event'$idone

Receptor de condición de error como módulo independienteEl receptor de condición de error es un elemento de procesamiento diseñado para recibiry enviar Traps de SNMP.

El receptor de Trap es capaz de recibir traps mediante cualquiera de los protocolos SNMP(hasta v3 incluido). Es capaz de reenviar traps en el mismo formato que se recibieron otransformarlos en eventos para manejarlos por el gerente de procesamiento de eventos.Por lo tanto, este componente se utiliza para recibir y procesar los traps, o simplementepara reenviarlos a sus destinos eventuales.

Receptor de condición de error como módulo independienteEl receptor de condición de error se instala de manera predeterminada con laconsolidación de alertas, pero se puede usar también como un módulo independiente.

Se instala como cualquier otro módulo, mediante el administrador de módulos. Elnombre del paquete es trap-receiver.

Procedimiento

1. Ejecute el siguiente comando:

<APG_BASE>/bin/managemodules.sh install trap-receiver

2. Edite el siguiente archivo:

<APG_BASE>/Event-Processing/Event-Processing-Manager/<INSTANCE>/conf/processing.xml

3. Agregue la siguiente línea:

<processing-element name="Trap-Receiver"type="Trap-Receiver" config="Trap-Receiver/Default/conf/config.xml" {STREAM_NAME}={STREAM_HANDLE}... />

donde:

l STREAM_NAME es el nombre que se usará para hacer referencia a la cadena en losarchivos de reglas (es decir, "data").

l STREAM_HANDLE es el destino para el nombre del flujo (es decir, "GEW").

l Puede especificar varios pares de nombre = identificador; sin embargo, losnombres deben ser únicos.

l El archivo de configuración config.xml contiene la configuración personalizadade este elemento de procesamiento y debe estar ubicado en el siguientedirectorio:

<APG_BASE>/Event-Processing/Trap-Receiver/<INSTANCE>/conf/

4. Para que se ejecute correctamente, es posible que este elemento de procesamientodeba ejecutarse como usuario raíz.

a. Edite el archivo unix-service.properties de la instancia Event-Processing-Managerque controla el receptor de condición de error.


Receptor de condición de error como módulo independiente 163

b. Establezca la línea apg.user=root.

c. Actualice el servicio Event-Processing-Manager.

Configuración de receptor de condición de error

Archivo de configuración principalEl archivo de configuración predeterminado para este módulo es:

<APG_BASE>/Event-Processing/Trap-Receiver/<INSTANCE>/conf/config.xml

<?xml version="1.0" encoding="UTF-8"?><config xmlns="http://www.watch4net.com/Events/TrapReceiver" xmlns:xsi="http://www.w3.org/2001/XMLSchema"> <rules location="rules" /> <mibs location="mibs" /> <ipbind incoming="0.0.0.0:10162" outgoing="0.0.0.0" /><threads count="2" /><incoming-v3-params username="" authentication-protocol="" authentication-password="" encryption-protocol="" encryption-password="" engineID="" /><outgoing-v3-params username="" authentication-protocol="" authentication-password="" encryption-protocol="" encryption-password="" engineID="" /></config>

Los elementos son:

<reglas>

Obligatorio. El archivo de reglas o directorio para utilizar.

<mibs>

Obligatorio. El archivo MIB o directorio para utilizar. Al convertir un trap en unevento, el elemento de procesamiento utiliza los archivos MIB especificados paraconvertir OID a un formato legible para el hombre.

<ipbind>

La interfaz se utiliza para recibir traps y puertos, y para enviar traps. Si se omite, elreceptor predeterminado es 0.0.0.0:162 y el reenviador predeterminado es laprimera interfaz disponible. Se admiten direcciones IPv6, utilizando el formato [IPv6address]:port.

<hilos de ejecución>

Cantidad total de hilos de ejecución para procesar los traps.

<incoming-v3-params>

Se utiliza para la decodificación de traps v3. Si se utiliza, se deben especificar todoslos atributos. Protocolo de cifrado es uno de {"AES", "DES"}; protocolo deautenticación es uno de {"MD5", "SHA"}.

Si la contraseña de cifrado se deja en blanco, no se utiliza el cifrado. Si lacontraseña de autenticación se deja en blanco, no se usa la autenticación.

La ID del motor es una cadena de caracteres ASCII que corresponde al ID del motordel agente. Por ejemplo, si su agente está usando "0x70707071727374" comomotor, entonces el ID del motor debe ser "pppqrst".



<outgoing-v3-params>

Establece los parámetros de v3 para los traps v3 reenviados. Está configurado de lamisma manera que el elemento <incoming-v3-params>.

Configuración de reglasLa carpeta de reglas predeterminada se encuentra aquí:

<APG-BASE>/Event-Processing/Trap-Receiver/<INSTANCE>/conf/rules/Mediante la especificación de la carpeta donde se encuentran, se pueden especificararchivos de reglas múltiples. Diversos archivos se procesan en orden alfabético.

Utilice el siguiente archivo de reglas como una plantilla para la creación de una regla:

<?xml version="1.0" encoding="UTF-8"?><rules><rule ip-address="*" oid="*" specific-id="*" generic-id="*" enterprise-id="*"><handle destination="data"><variablename-conversion from=".1.3.6.1.2.1.1.1.0" to="new name" /></handle><forward destination="192.168.1.100:45678" /><break /></rule> <rule ip-address="192.168.1.1/24" oid=".1.3.6.4.1.4.*" specific-id="2" generic-id=”9”><handle destination="data" /><forward destination="10.128.2.32" /><break /></rule><rule><break /></rule></rules>

Los elementos son:

<regla>

Define una regla. Este elemento acepta los siguientes atributos opcionales que seutilizan como filtros. Si se omiten todos los filtros, la regla coincide con todo.

ip-address

Dirección IP, máscara de red o un comodín (*).

ID genérica

Número o comodín.

ID específica

Número o comodín.

OID

OID, comodín o comenzando con un OID terminado por un comodín.

ID empresarial

OID o comodín.

<envío>

Opcional. Especifique el destino deseado de los traps recibidos que coincidenmediante los filtros de la regla asociada. Si se utiliza, se requiere un destino en elformulario de ip_address o ip_address:port.


Configuración de receptor de condición de error 165

<gestionar>

Opcional. Especifique el flujo al que se debe enviar el evento generado a partir deeste trap. Este elemento también permite especificar las conversiones para llevar acabo en los datos de eventos:

<conversión de constante>

Utilice este elemento para agregar un valor al evento. Por ejemplo:

<constant-conversion key="source" value="TRAP-RECEIVER" />

<conversión de variableName>

Toma la clave de un {clave, valor} par del evento generado y lo convierte. Utiliceeste elemento para convertir OID si no se encuentran en ninguno de losarchivos MIB especificados). Por ejemplo:

<variablename-conversion from=".1.3.6.1.4.1.11970.1.0" to="sent-by" />

<break>

Opcional. Detiene todos los procesos posteriores en el trap para todas las reglas.

Filtro de informe para alertas activas en comparación a alertasinactivas

El filtro de informe determina si un informe incluye alertas activas o inactivas.

Para crear informes personalizados de emisión de alertas que muestren alertas activas,comience con el filtro desde los informes de All Alerts.

!eventSource=='ImpactAnalysis-GenericEvent'&active=='1'&#EVENTS-GENERIC:ALL

Esta es una representación gráfica del asistente de filtros:

Este es el significado de cada componente en el filtro anterior:

l La frase eventSource elimina los eventos de análisis de impacto.

l La frase activa incluye solo las alertas ACTIVAS. La propiedad ACTIVA es 1 paraactivas y 0 para inactivas.

l La frase variable nombra la base de datos.



APÉNDICE A

Configuraciones específicas de dispositivo

Los dispositivos que generan eventos o SNMP traps deben configurarse para enviar esoseventos o traps al puerto de escucha de eventos de ViPR SRM o al receptor de condiciónde error de SNMP.

Aquí se incluyen los procedimientos para los dispositivos seleccionados. Tambiénconsulte los capítulos correspondientes en la Guía de instalación de SolutionPack de ViPRSRM.

l Configuraciones específicas del dispositivo........................................................ 168

Configuraciones específicas de dispositivo 167

Configuraciones específicas del dispositivo

Los dispositivos que generan eventos o traps SNMP deben configurarse para enviar esoseventos o traps al puerto de escucha de eventos de ViPR SRM o al receptor de Trap deSNMP.



Configuración de switches Cisco para la consolidación de alertasUtilice este procedimiento para configurar el redireccionamiento de las capturas dealertas (SNMP v1) desde los switches Cisco FC hasta el módulo de alertas de ViPR SRM.

Procedimiento

1. Inicie sesión en el switch Cisco FC como administrador.

2. Para ingresar al modo de configuración global, escriba config en el indicador delterminal y presione Enter.

Por ejemplo:

# config

En la documentación de Cisco se suministra más información sobre el modo deconfiguración global.

3. Escriba el siguiente comando y presione Enter.

snmp-server host <trap_receiver_IP> traps <version> <community_string> udp-port <trap_listening_port>

donde:

elemento de sintaxis Entrada

<trap_receiver_IP> Dirección IP del receptor de condición de error de ViPR SRM:

l En una única instalación de vApp, use la dirección IP de ViPRSRM.

l En un ambiente distribuido, use la dirección IP de back-endde ViPR SRM.

<version> Versión 1

<community _string> Público

<trap_listening_port > 2041, que es el puerto del receptor de condición de error de ViPR

SRM.

Por ejemplo:

snmp-server host 10.247.24.190 traps version 1 public udpport 2041

4. Si tiene múltiples switches Cisco FC en su ambiente de almacenamiento, reitere esteprocedimiento en cada switch.

Configuración de switches Brocade para la consolidación dealertas

Utilice este producto para configurar el redireccionamiento de alertas trap (SNMP v1)desde los switches Brocade hasta el conjunto de aplicaciones.


Configuración de switches Cisco para la consolidación de alertas 169

Procedimiento

1. Inicie sesión en el switch Brocade FC como administrador.

2. Escriba lo siguiente:

snmpConfig ––set snmpv1

y, a continuación, presione Enter.

3. Cuando reciba la solicitud, escriba los siguientes detalles:

Opción Entrada

Comunidad [public]

Dirección IP del receptor de trap Dirección IP del receptor de condición de error de ViPR SRM:

l En una única instalación de vApp, use la dirección IP deViPR SRM.

l En un ambiente distribuido, use la dirección IP de back-end de ViPR SRM.

Nivel de severidad del receptor detrap

(0..5)

Puerto del receptor de trap 2041, que es el puerto del receptor de condición de error de

ViPR SRM.

4. Si tiene múltiples switches Brocade FC en su ambiente de almacenamiento, reitereeste procedimiento en cada switch.

Cómo configurar los arreglos VMAX para la consolidación dealertas de estado

Utilice este procedimiento para configurar el redireccionamiento de traps de alerta deestado (SNMP v1) desde arreglos VMAX hasta ViPR SRM. Las alertas de rendimientoVMAX se recopilan mediante la configuración de recopilación de datos dedescubrimiento.

Procedimiento

1. Inicie sesión como administrador en Solutions Enabler en el host proveedor delarreglo.

2. Edite el archivo daemon_options en el directorio C:\Program Files\EMC\SYMAPI\config\.

3. En la sección del parámetro llamada SNMP_TRAP_CLIENT_REGISTRATION:

a. No comente la siguiente línea:

storevntd:SNMP_TRAP_CLIENT_REGISTRATION

b. Agregue información al filtro de trap, utilizando la siguiente sintaxis:

<IP>,<port>,<filter>,<state>

Donde



l <IP> es la dirección IP para el receptor de condición de error de ViPR SRM, quees la dirección IP del host de back-end.

l <port> es el puerto del receptor de condición de error, 2041.

l <filter> es el nivel de filtrado para el redireccionamiento definido de trapen el archivo FCMGMT-MIB

l <state> es el valor ACTIVO

Por ejemplo:

10.31.90.148,2041,10,ACTIVO

4. En la sección de parámetro llamada LOG_EVENT_TARGETS, no comente la líneasiguiente:

storevntd:LOG_EVENT_TARGETS = snmp file

5. Para identificar los arreglos que deben enviar traps a ViPR SRM:

a. Tipee symcfg list.

b. Presione Enter.

6. Para cada arreglo que debe enviar traps de alerta a ViPR SRM:

a. Escriba symcfg list y presione Enter.

b. En la sección de parámetro, para LOG_SYMMETRIX_EVENTS, especifique lascategorías de evento correspondientes utilizando el siguiente formato:

sid=<SYM serial number>, <eventcategory 1>, <eventcategory 2>\

Por ejemplo:

SID = 000194900854, disco, dispositivo, pool de dispositivo, director, grupo de consistencia de srdf, sesión de srdf, enlace de srdf, sistema de srdf, procesador de servicio, ambiental, diagnóstico, suma de verificación, estado, eventos, subsistema de arreglo, grupos, optimizador.

7. Para volver a cargar los cambios en el archivo daemon_options:

a. Tipo stordaemon actionstorevntd -cmd reload.

b. Presione Enter.

8. Asegúrese de que storevntd Event Daemon se esté ejecutando en el host proveedor.

9. Si tiene múltiples hosts proveedores del arreglo VMAX en su ambiente dealmacenamiento, reitere este procedimiento en cada host proveedor del arreglo.

Cómo configurar los conjuntos VNX para la consolidación dealertas

La consolidación de alertas de VNX Block no requiere una configuración separada. Sigael procedimiento a continuación para configurar el direccionamiento de alertas dearchivos VNX a ViPR SRM.


Cómo configurar los conjuntos VNX para la consolidación de alertas 171

Procedimiento

1. Inicie sesión en Control Station como el usuario raíz.

2. Abra el archivo de configuración nas_mcd.cfg en el directorio /nas/sys/.

3. Habilite el servicio API de XML; para ello, elimine el comentario de la siguienteentrada:

daemon "XML API Server"executable "/nas/sbin/start_xml_api_server"optional yescanexit yesautorestart yesioaccess no

4. Para reiniciar el servicio XML-API, ingrese el siguiente comando y, a continuación,presione Enter.

# Inicio del servicio NAS

5. Si tiene múltiples arreglos VNX en su ambiente de almacenamiento, repita esteprocedimiento en cada arreglo VNX.



EMC ViPR SRM - Dell · Filtrado en la definición de alerta de cuello de botella borrado de...

Documents

Transcript of EMC ViPR SRM - Dell · Filtrado en la definición de alerta de cuello de botella borrado de...