guía de alertas - dell emc · emisión de alertas de vipr srm proporciona una vista consolidada y...

EMC® ViPR® SRMVersión 4.0.1.0

Guía de alertas01

Copyright © 2015-2016 EMC Corporation Todos los derechos reservados.

Publicado en Octubre de 2016

Dell considera que la información de este documento es precisa en el momento de su publicación. La información está sujeta a cambios sin previo

aviso.

LA INFORMACIÓN DE ESTA PUBLICACIÓN SE PROPORCIONA “TAL CUAL”. DELL NO SE HACE RESPONSABLE NI OFRECE GARANTÍA DE

NINGÚN TIPO CON RESPECTO A LA INFORMACIÓN DE ESTA PUBLICACIÓN Y, ESPECÍFICAMENTE, RENUNCIA A TODA GARANTÍA

IMPLÍCITA DE COMERCIABILIDAD O CAPACIDAD PARA UN PROPÓSITO DETERMINADO. EL USO, LA COPIA Y LA DISTRIBUCIÓN DE

CUALQUIER SOFTWARE DE DELL DESCRITO EN ESTA PUBLICACIÓN REQUIEREN LA LICENCIA DE SOFTWARE CORRESPONDIENTE.

Dell, EMC y otras marcas comerciales pertenecen a Dell Inc. o sus filiales. Las demás marcas comerciales pueden ser propiedad de sus respectivos

dueños. Publicado en México.

Dirección local de EMCEMC Argentina (Cono Sur) Tel. +54-11-4021-3622 http://www.emc.com/es-ar/index.htmEMC México Tel. +52-55-5080-3700 http://www.emc.com/es-mx/index.htmEMC Venezuela (Norte de Latinoamérica) Tel. +58-212-206-6911 http://www.emc.com/es-ve/index.htm

2 EMC ViPR SRM 4.0.1.0 Guía de alertas

7

9

Introducción de alertas 11

Funciones y conceptos de alertas en ViPR SRM 13Soluciones 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 ................................................................................. 17Tipos de alerta............................................................................................ 19Ciclo de vida de una alerta ..........................................................................19Eliminación de una alerta para que se vuelva INACTIVE .............................20

Informes de alertas y consola de usuario 23

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

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

Administrar alertas 41Acciones para la administración de alertas .................................................42Administrar alertas..................................................................................... 42Líneas de tiempo para la administración de alertas..................................... 44

Informes personalizados 47Adición de nuevas columnas....................................................................... 48Cambio del orden de clasificación recomendado en un informe.................. 48Filtrado de un informe ............................................................................... 50Cambio de un nombre de columna en un informe....................................... 50

Figuras

Tablas

Parte 1

Capítulo 1

Parte 2

Capítulo 2

Capítulo 3

Capítulo 4

CONTENIDO

EMC ViPR SRM 4.0.1.0 Guía de alertas 3

Agregar ID de evento de origen a los informes............................................ 51

Administración de alertas 53

Configuración de la infraestructura de alertas 55Configuración de alertas.............................................................................56Habilitación y deshabilitación de los adaptadores de emisión de alertas......57Preserve las personalizaciones de la definición de alerta durante unaactualización.............................................................................................. 58Configuración de un servidor SMTP .......................................................... 58Configuración de adaptadores de emisión de alertas para usar el cifrado y lacompresión.................................................................................................59

Administre y configure las definiciones de alerta 61Acerca de la configuración de las definiciones de alerta............................. 62Definiciones de alerta contextualizadas y no contextualizadas................... 62Acceso a las definiciones de alerta............................................................. 63Habilitación y deshabilitación de definiciones de alerta...............................64Modificación de definiciones de alertas...................................................... 64Adición de una acción de registro a una definición de alerta....................... 65Configuración de una definición de alerta .................................................. 67Contextualización de una definición de alerta............................................. 68Acerca de las definiciones de alertas de ESRS............................................70

Haga visibles las definiciones de alertas de ESRS.......................... 70

Notificaciones de alerta 73¿Qué son las notificaciones de alerta?........................................................74Acerca de las definiciones de alerta globales.............................................. 74Configurar notificaciones ...........................................................................76Modificación de los destinatarios, el asunto y el mensaje de una notificación................................................................................................................... 79Crear una plantilla de notificación............................................................... 79

Proceso de archivo de alertas 83Base 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 del proceso .............................................88

Monitoreo y solución de problemas 89Supervisión del estado de alerta................................................................. 90Configuraciones específicas de dispositivos................................................91Archivos de registro para monitorear.......................................................... 91Uso de un espía de eventos para solucionar problemas de las alertas......... 92Utilice el sondeo para solucionar problemas en una definición de alerta......94

Desarrollo de nuevas alertas 95

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

Parte 3

Capítulo 5

Capítulo 6

Capítulo 7

Capítulo 8

Capítulo 9

Parte 4

Capítulo 10

CONTENIDO


Flujo de proceso de alertas comunes ......................................................... 98Acerca de traps en ViPR SRM.................................................................... 99Acerca de Trap de alerta y Traps de borrado de alertas............................ 100¿Cómo se asignan las severidades de alerta?............................................100Descripción de los componentes de emisión de alertas.............................. 101

Crear alertas personalizadas 107Crear alertas desde SNMP traps ..............................................................108

Flujo de proceso para consolidar los eventos de SNMP trap enalertas.......................................................................................... 108Ejemplo de un trap consolidado en una alerta y borrado............... 109Creación de una alerta personalizada para un trap desde un origenexterno......................................................................................... 112

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

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

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

Creación de definiciones de alertas personalizadas 131Definiciones de alerta en la consola .......................................................... 132Componentes de una definición de alerta.................................................. 132Edición de una definición de alerta............................................................ 137Creación de definiciones de alerta.............................................................140Para obtener más información acerca de los componentes y las definicionesde alertas................................................................................................... 141Acerca de Trap de alerta y Traps de borrado de alertas............................. 141Adición de acciones de Trap de alerta y Trap de borrado de ViPR SRM ... 142Plantillas y cuadros agrupados.................................................................. 143Creación de carpetas de definición de alerta............................................. 143

Alertas de la base de datos y caché activo 145Base de datos de eventos..........................................................................146Caché activo............................................................................................. 146

Formatos y MIB 147Formato normalizado de Trap de alerta y Trap de borrado ....................... 148OID de formato de mensaje de trap y datos de eventos normalizados ...... 153Propiedades de alerta en una entrada de la base de datos ........................154SRM-ALERTS-MIB................................................................................... 159

Capítulo 11

Capítulo 12

Capítulo 13

Capítulo 14

CONTENIDO


Temas de desarrollo adicionales 169Creación de una captura de alerta manual ................................................ 170Script para generar alertas aleatorias........................................................ 170Receptor de condición de error como módulo independiente..................... 171

Receptor de condición de error como módulo independiente........ 171Configuración de receptor de condición de error..........................172

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

Capítulo 15

CONTENIDO


Informe All Alerts........................................................................................................ 27Informe Alert Details and Impact Analysis...................................................................28Informe Alerts Summary.............................................................................................29Informe High Impact Alerts.........................................................................................35Informe Top Devices with Critical Alerts..................................................................... 37Alertas para el informe Watched Devices ...................................................................38Nueva plantilla para las acciones de correo................................................................. 81Flujo de proceso común..............................................................................................98Flujo del proceso de emisión de alertas para eventos de SNMP trap......................... 108Filtrado en la definición de alerta detectada de cuello de botella Brocade.................. 111Definición de alertas de Brocade ............................................................................... 111Lista de definición de alertas de Brocade................................................................... 112Filtrado en la definición de alerta de cuello de botella borrado de Brocade.................112Flujo de proceso de alertas para los eventos recopilados por una escucha................. 114Filtrado en una definición de alerta de VNX............................................................... 115Definición de alerta VNX ........................................................................................... 116Informe detallado para el evento de VNX................................................................... 118Flujo de proceso de alerta para eventos de umbral de métrica.................................. 120Filtro para una definición de alerta de métrica recopilada...........................................121Acciones para una definición de alerta de métrica recopilada.................................... 122Filtrado en una definición de alerta............................................................................133Operador en una definición de alerta......................................................................... 134Comparador con dos rutas de resultado.................................................................... 134Acciones de una definición de alerta..........................................................................136Ejemplo de definición de alerta.................................................................................. 137

12345678910111213141516171819202122232425

FIGURAS


FIGURAS


Opciones de usuario para la administración de alertas................................................ 42Lista de tareas para configurar la consolidación de alertas ........................................ 56Usos recomendados de definiciones de alerta globales............................................... 74Ajustes 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 Trap de alerta...................................................................... 148Datos en los mensajes de Trap de borrado................................................................ 152Campos en una entrada de la base de datos de eventos ........................................... 154

123456789

TABLAS


TABLAS


PARTE 1

Introducción de alertas

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

Capítulo 1, "Funciones y conceptos de alertas en ViPR SRM"

Introducción de alertas 11

Introducción de alertas


CAPÍTULO 1

Funciones y conceptos de alertas en ViPR SRM

Los siguientes temas describen las funciones básicas y los conceptos del módulo deemisión de alertas, como se implementa para ViPR SRM.

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 Tipos de alerta.................................................................................................... 19l Ciclo de vida de una alerta ................................................................................. 19l Eliminación de una alerta para que se vuelva INACTIVE .................................... 20

Funciones y conceptos de alertas en ViPR SRM 13

Soluciones empresarialesEl módulo de emisión de alertas de ViPR SRM puede contribuir a la eficiencia de laorganización en el monitoreo y la administración de objetivos de almacenamiento dedatos y del estado de la infraestructura.

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

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 deemisión de alertas de ViPR SRM proporciona una vista consolidada ypersonalizable de todas las alertas en lo que respecta a estado y disponibilidad dela infraestructura, cruces del umbral de capacidad para todos los tipos dealmacenamiento y recursos, y el cumplimiento de acuerdos de nivel de servicio.

Administración de alertas eficiente

Los gerentes y administradores deben identificar qué alertas críticas son las quese está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 alclasificarlas mediante el filtrado de varios atributos, incluyendo propiedad,dispositivo o gravedad de las alertas. Las alertas que ya están afirmadas oconfirmadas por otros administradores pueden descender hasta la parte inferiorde la 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 alertas

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 alertas o dispositivos, los administradores desean obtenernotificaciones. ViPR SRM proporciona funciones de notificación completamenteconfigurables. 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 almacenamientocompleta

Cada SolutionPack viene con la normalización apropiada de las alertas que serecopilan desde los dispositivos de almacenamiento respectivos. Las alertas serecopilan para los dispositivos descubiertos y aparecen en los informes de alertasglobales, así como también en la Biblioteca de informes específica deldispositivo. La consolidación de alertas para cualquier tipo de dispositivo puedeactivarse o desactivarse 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 archivingautomá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 generanalertas.

l Los administradores pueden cambiar la asignación de la categoría de unaalerta y crear nuevas categorías de alerta. Las categorías proporcionan unaforma de clasificar el tipo de alerta. Algunos ejemplos son Availability,Performance o Security.

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 alertaspersonalizadas se normalizan y aparecen en las mismas tablas y están sujetasa las mismas reglas 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 necesariamentese convierten en alertas.

En ViPR SRM, un evento se refiere a una instancia cruda, 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 emisión de alertas. Las definiciones de alerta agregan lainformación a la base de datos de eventos, lo que permite que las alertas esténdisponibles para su inclusión en los informes de emisión de alertas.


¿Qué es una alerta? 15

Se proporcionan definiciones de alerta especializadas para otros tipos de acciones,como la adición de mensajes a los registros, la creación de traps a terceros y el envíode notificaciones por correo electrónico.

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

Consolidación de alertasLa consolidación de alertas 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 eventosaparecen juntos en el informe All Alerts. Los usuarios de la consola pueden filtrar,ordenar y administrar 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 las métricas recopiladas por losrecopiladores de ViPR SRM. Si los datos recopilados coinciden con lascondiciones en una definición de alerta, el evento se convierte en una alerta.

Eventos enviados a un puerto de escucha

Estos son los eventos que se originan fuera de ViPR SRM, por ejemplo, en undispositivo o una red. El origen envía el evento a un puerto de escucha de eventosde ViPR SRM. Los datos de eventos se normalizan en función de las reglas deconversión. Si los datos resultantes coinciden con las condiciones en unadefinición de alerta, esta se convierte en una alerta.

SNMP traps

Estos son los SNMP traps que se originan fuera de ViPR SRM, por ejemplo, en undispositivo o una red. El origen envía el trap a un receptor de condición de errorde ViPR SRM. Los datos de trap se normalizan en función de las reglas deconversión. Si los datos resultantes coinciden con las condiciones en unadefinición de alerta, esta se convierte en una alerta.

Eventos recopilados de un informe programado

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 almacenamientode un nivel de servicio en particular cae 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 seconvierte en una alerta.



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

En la mayoría de las instalaciones, el front-end de alertas es el front-end primario deViPR SRM. Los componentes de Front-end de alerta son los componentes para elusuario:

l Los informes de alertas, que proporcionan a los usuarios listas de alertas,funciones de administración interactiva y la funcionalidad de desglose de losdetalles de cada alerta.

l Las definiciones de alertas, que definen todas las condiciones que provocan que loseventos se conviertan en alertas de ViPR SRM. Las definiciones de alerta tambiéndefinen 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 alertas es el back-end primario de ViPR SRM. Contiene el conjunto deprocesos de soporte para la consolidación de alertas y la escritura de alertas en la basede datos de eventos.

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

La base de datos de eventos contiene dos tablas.

tabla genericevents_live

Esta tabla almacena todas las alertas ACTIVE. El informe All Alerts sobre laconsola y todos los informes que son versiones filtradas de aquel se basan en lasentradas en esta tabla.

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

tabla genericevents_archive

Esta tabla almacena las alertas INACTIVE hasta que se purgan del sistema.

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

Para obtener descripciones de las propiedades en las entradas de tabla, consulte Propiedades de alerta en una entrada de la 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 dealerta válida y ENABLED.

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

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

Punto de entrada

El punto de entrada es el filtro que define qué eventos maneja esta definición dealerta. El filtro funciona en los campos (propiedades) en los datos de evento.


Infraestructura de alertas 17

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, oun nombre 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 de uso frecuente es un comparador, el cual compara el valor de lamétrica del evento con un valor estático configurado en la definición de la alerta.Una técnica común en ViPR SRM es una cadena de comparadores, cada uno conun valor comparador diferente. Los resultados son una serie de traps SNMP quecrean traps Importantes, Principales, Menores y finalmente un trap de Borrado,todo en la misma propiedad.

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

Acciones

Las acciones definen lo que debe producirse como resultado del evento. Lasacciones más comunes utilizadas en definiciones de alerta de ViPR SRM son lassiguientes:

l Un Trap de alerta, que crea la alerta a partir de los datos del evento y laagrega a la base de datos, haciendo que esté disponible para los informes deemisión 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 dedispositivo, gravedad y otros campos de identificación.

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

Las siguientes acciones se utilizan en las definiciones de alerta de notificacionesglobales para enviar notificaciones después de que los eventos se convierten enalertas. Puede copiar y personalizar estas definiciones de alerta globales:

l La definición de alerta Alert Consolidation Email Notification utiliza la acciónMail para enviar correos electrónicos con información de alertas a losdestinatarios configurados.

l La acción SNMP Trap se utiliza en la definición de alerta Alert ConsolidationTrap Notification para enviar traps de información de alertas a los sistemas deotros fabricantes configurados.

¿Por qué debe prestar atención a las definiciones de alerta?La mayoría de las definiciones de alertas predeterminadas se encuentran inicialmenteen un 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 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 una nueva acción de registro para registrar datos de eventos antes de quese conviertan en una alerta.

l Configurar notificaciones de alertas por correo electrónico y de otros fabricantes.

Tipos de alertaLas alertas se clasifican en MOMENTARY o DURABLE.

Todas las alertas consolidadas, independientemente de cómo ingresen al sistema,ingresan a la base de datos en el estado ACTIVE y son del tipo MOMENTARY oDURABLE. 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 MOMENTARY

Las alertas MOMENTARY son las alertas que se producen una sola vez. Unejemplo es Administrator logging in to the system.

Las alertas MOMENTARY se borran automáticamente después de 7 días. A pesarde que las alertas MOMENTARY generalmente se asocian con las alertasinformativas, su gravedad puede ser cualquiera.

Tipo de alerta DURABLE

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

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

Ciclo de vida de una alertaEl estado de alerta es ACTIVE o INACTIVE.

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

ACTIVE

Una alerta ingresa al sistema como ACTIVE. Las alertas ACTIVE se almacenan enla tabla en vivo en la base de datos y aparecen en los informes Todas las alertasen la consola.

INACTIVE

Las alertas se convierten en INACTIVE de diversas maneras. (Consulte lasiguiente sección). En general, una alerta INACTIVE puede ser afrontada dealguna manera o considerada sin importancia y envejece. Las alertas INACTIVE noaparecen en los informes Todas las alertas. Están aún está disponibles para losinformes históricos y de tendencias.

(archivado)

Después de un período de tiempo configurable, las alertas INACTIVE setransfieren automáticamente a una tabla de archivo en la base de datos. Las


Tipos de alerta 19

alertas archivadas están aún disponibles para los informes históricos y detendencias.

(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.

Eliminación de una alerta para que se vuelva INACTIVEExisten varias maneras de eliminar o desactivar alertas de la base de datos y losinformes. Una alerta borrada es una alerta INACTIVE.

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

MOMENTARY

Una alerta MOMENTARY (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 sevuelve INACTIVE y ya no aparece en los informes de alertas.

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

Archiving automático

Si no se realiza ninguna acción en la alerta por un número configurable dedías, la alerta se vuelve INACTIVE y no va a aparecer en los informes dealertas. El valor predeterminado para el número de días es 7.

Por ejemplo, un host de VMware envía un evento informativo sobre el cambiode un servidor. Ningún usuario lleva a cabo ninguna acción en la alerta. Laalerta se vuelve INACTIVE automáticamente después de la cantidadpredeterminada de días.

DURABLE

Una alerta DURABLE se elimina de una de las siguientes maneras.

Evento de borrado

Se procesa otro evento que borra el evento existente. El evento de borradoestá asociado al evento original porque contiene un conjunto de valores decampo que coinciden, como el mismo dispositivo, la misma parte, el mismonombre del evento, la misma gravedad y así sucesivamente. La definición dealerta define 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 de SRM. La alerta está activahasta que otro SNMP trap captura un evento en la utilización de la memoria<60% en el mismo dispositivo. El segundo evento borra el primer evento y laalerta SRM cambia a INACTIVE.



Borrado forzado

Los permisos del administrador permiten la acción de borrado a la fuerza, sies necesario.

Los permisos de usuario no permiten que los usuarios borren manualmenteuna alerta DURABLE.


Eliminación de una alerta para que se vuelva INACTIVE 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.

Capítulo 2, "Exploración de los informes de alertas"

Capítulo 3, "Administrar alertas"

Capítulo 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 alertas de ViPR SRM.Obtenga más información acerca del contenido de los informes, cómo administrar lasalertas desde los informes y cómo personalizarlos.

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

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

cantidad de dispositivos principales ...................................................................36l Dispositivos críticos............................................................................................37

Exploración de los informes de alertas 25

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 los gráficos de barras de nivel de resumen, haga clic en una barra para abrirun informe tabular que enumere las alertas en la categoría resumida.

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

l La columna Device en los informes de alertas contiene vínculos al informe depágina de inicio del dispositivo.

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.

En instalaciones con una pequeña cantidad de alertas, puede reducir el intervalo deactualización a apenas 15 segundos.

Para bases de datos de eventos más grandes (con un número total de alertas activasde má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.

Nota

Las nuevas alertas que se originan en SNMP pueden tardar hasta cuatro minutos enaparecer en los informes de alertas. Esta demora es independiente de la configuracióndel intervalo de actualización.

Procedimiento

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

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.



Visualización de una lista consolidada de todas las alertasVea una lista consolidada de las alertas activas de varios orígenes de suinfraestructura; por ejemplo, de los dispositivos VMAX, VNX Block, VNX File, Brocadeo Cisco y desglose los detalles de las alertas.

En el informe All Alerts se muestra una lista de todas las alertas ACTIVE generadas apartir de diversos orígenes en la última semana, en un formato tabular. Este informemuestra información importante sobre la alerta, incluida la gravedad, si tieneconfirmación de un usuario, el usuario que ha reclamado propiedad, diversainformación de identificación sobre el origen de la alerta, la hora de creación de laalerta, y si es DURABLE o MOMENTARY. La columna Device contiene vínculos a laspáginas de inicio para el dispositivo.

Figura 1 Informe All Alerts

Inicialmente, las alertas aparecen en la tabla ordenadas por la gravedad y la hora en laque se crearon. Todas las alertas de nivel más alto de gravedad aparecen en primerlugar seguidas por gravedades menores y en el orden en el que se crearon, con laalerta más reciente en primer lugar.

En el informe All Alerts, haga clic en una fila para desglosar una alerta específica yobtener el informe Alert Details and Impact Analysis de una alerta de interés.


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

Figura 2 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 enuna fila 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 alertaespecífica, haga clic 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 filade la tabla 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.

El informe Dashboards > Operations > Alerts Summary es un tablero en el que semuestran resúmenes gráficos de todas las alertas en función de las siguientescaracterísticas:

l Gravedad como Critical, Major o Minor.

l Alert Occurrences by Severity.

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

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

l Tipos de dispositivo.

Haga clic en las barras en los informes para desglosar los detalles de una alertaespecífica.

Figura 3 Informe Alerts Summary

Procedimiento

1. En la consola, vaya a Dashboards > Operations > Alerts Summary.


Búsqueda de un resumen de todas las alertas 29

2. Para ver una versión más grande de cualquiera de los informes en el tablero,desplace el cursor sobre la esquina superior derecha del informe y haga clic enMake this element wider.

3. En cualquier informe del tablero, desglose los detalles de alertas y administre lasalertas:

a. Haga clic en una barra en un informe.

Esto hace que el informe All Alerts aparezca, filtrado por los atributos en labarra seleccionada.

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

c. Para mostrar más detalles acerca de una alerta específica, haga clic en la filade esa alerta. Se abre el informe Alert Details and Impact Analysis.

d. Para volver al tablero después de explorar en detalle los informes, haga clicen Alerts Summary, en la ruta de navegación situada en la parte superior dela ventana.

4. Examine el informe Alerts by Severity.

Este informe ayuda a determinar la cantidad de alertas de gravedad crítica,grave, menor o desconocida que están ACTIVE en el sistema para la semanaanterior.

Cada barra representa una gravedad diferente.



Nota

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

Consulte el Paso 3 para ver las opciones de administración de alertas y dedesglose.

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 dealertas ACTIVE 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. Examine el informe Alerts by Device Type.

El gráfico de barras de Alerts by Device Type ayuda a determinar la cantidadde alertas ACTIVE de cada tipo de dispositivo de la semana anterior.


Búsqueda de un resumen de todas las alertas 31

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


7. Examine el informe Alerts by Category.

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

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


8. Examine el informe 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.



No hay acciones de usuario disponibles aquí.

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

Utilice la pestaña Operations en la página de inicio de un dispositivo para solucionarlos problemas de un dispositivo, analizar las tendencias de alertas de un dispositivo over cómo la disponibilidad afecta las alertas.

Procedimiento

1. Vaya a la página de inicio de un dispositivo con uno de estos métodos:

l Haga clic en un vínculo activo en un informe, por ejemplo, los vínculos en lascolumnas Device o Serial Number en varios informes.

l Vaya directamente al informe del dispositivo, por ejemplo, desde Explore >All Devices > List of Devices > nombre_del_dispositivo.

Se abre una página de inicio del dispositivo con un conjunto de pestañas:

2. Haga clic en la pestaña Operations.

Nota

En algunos dispositivos, es posible que haya pestañas secundarias donde sepuede hacer clic.

El informe de alertas específicas del dispositivo muestra todas las alertasACTIVAS para el dispositivo.


Búsqueda de alertas para un dispositivo 33

3. Haga clic en una fila para mostrar todos los detalles de una alerta, incluido elmensaje de alerta detallado.

4. Haga clic con el botón secundario en una fila para administrar la alerta.

Visualización de alertas de alto impacto y cambio depalabras clave 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 esteinforme se muestran todas las alertas activas cuyo mensaje contiene frases que seconsideran de alto 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”,su fullmsg 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,ahora offline, fallido y muchas otras. Puede ver la lista de palabras clave en el filtro deinforme. También puede editar el filtro para agregar y eliminar palabras clave.

Figura 4 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 Mode.

b. Haga clic en la pestaña Filtering & Expansion.

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 enel cuadro de expresiones y seleccione Edit expression.


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

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

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

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

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

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

Visualización de dispositivos principales con alertas críticasy configuración de la cantidad de dispositivos principales

Limite la búsqueda de alertas críticas en su ambiente utilizando el informe TopDevices with Critical Alerts. Configure la cantidad de dispositivos principales quedesea que aparezca en el informe.

En el informe Top Devices with Critical Alerts se muestran los dispositivos quegeneraron la mayor cantidad de alertas críticas ACTIVE en la última semana en ungráfico de barras. Este informe ayuda a determinar qué dispositivos requieren atenciónsegún la cantidad de alertas críticas generadas por estos.

Cada barra representa un dispositivo. El tipo de dispositivo y el nombre del dispositivose enumeran en la barra de la izquierda. La cantidad de alertas críticas y el porcentajedel total se muestran a la derecha de la barra.

La cantidad de dispositivos (barras) es configurable.



Figura 5 Informe Top Devices with Critical Alerts

Procedimiento

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

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

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 campoNumber of Sections.

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

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

3. Para mostrar los detalles de las alertas críticas de un dispositivo en un formatode tabla, haga clic en una barra.

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

4. Si tiene la función de administrador, puede hacer clic con el botón secundariosobre el texto de una fila de la tabla para administrar una alerta. Por ejemplo,elija Acknowledge o Take ownership 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.


Dispositivos críticos 37

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

Nota

A pesar de que la visualización predeterminada muestra la última semana de lasalertas, las alertas que se produjeron antes de marcar el dispositivo como crítico no semuestran en 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 6 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ápreparada para copiar y pegar:

a. Haga clic en Administration > Centralized Management > PhysicalOverview.

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 dispositivodeseados al archivo.

g. Haga clic en Save.



2. Use este método para seleccionar nombres de dispositivos individuales de unalista generada:

a. Navegue hacia Administration > Centralized Management > DataEnrichment.

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

a. Haga clic en Register a new module.

b. En la lista que aparece, seleccione el servidor Primary Backend, lacategoría Event-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 PrimaryBackend.

d. Expanda la barra de dispositivo crítico.

e. En la tabla, haga clic en la primera fila de la columna Device Name paraexponer un cuadro desplegable y presione la tecla Retroceso para borrar lafrase predeterminada.

La lista desplegable ahora debería mostrar los nombres de dispositivo,ordenados alfabé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, acontinuación, seleccione el nombre del dispositivo deseado.

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

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

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 semarcó como crítico aparecen en el informe.

2. Si tiene la función de administrador, puede hacer clic con el botón secundario enuna descripción de alerta del informe y elegir una acción de administración,como Acknowledge 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.


Visualización del informe Watched Devices y desglosamiento en detalles 39

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

Administrar alertas

Los siguientes temas describen las acciones disponibles para los usuarios yadministradores para la administración de alertas.

l Acciones para la administración de alertas ........................................................ 42l Administrar alertas............................................................................................. 42l Líneas de tiempo para la administración de alertas............................................. 44

Administrar alertas 41

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. Los administradores puedenasignar alertas a otros usuarios y forzar el cierre de alertas.

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

Acción Descripción

Acknowledge Marque la alerta confirmada.

l Cuando se confirma una alerta de tipo MOMENTARY, elestado de la alerta cambia de ACTIVE a INACTIVE. Ya no se

informan las alertas INACTIVE ni en el informe All Alerts nien el subconjunto de informes relacionado.

l Cuando se confirma una alerta de tipo DURABLE, esta

permanece ACTIVE y permanece dentro del informe AllAlerts y dentro del subconjunto de informes relacionado conYes en la columna ACK. Además, automáticamente se asigna

la propiedad al usuario que la confirmó.

Un-Acknowledge Confirmación de la versión sin afectar al propietario.

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

necesario liberar la propiedad con Release ownership, cerrarsesión, iniciar sesión nuevamente y luego tomar propiedad. Unaalerta específica no puede tener más de un propietario a la vez.

Release Ownership 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

Assign Establecer el campo de propietario a otro usuario.

Force Close Establecer cualquier alerta como INACTIVE.

Administrar alertasLas acciones de administración de alertas están disponibles en el informe All Alerts oen cualquier variación filtrada del informe All Alerts.

Procedimiento

1. En la consola, vaya a Operations > Alerts > All Alerts o a cualquier versiónfiltrada del informe.

Administrar alertas


Por ejemplo, Dashboards > Operations > Alerts Summary > Alerts bySeverity > Critical es una versión filtrada del informe All Alerts para unagravedad específica.

2. Haga clic con el botón secundario en una fila de la alerta y elija una acción en elmenú.

Por ejemplo, seleccione Acknowledge.

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

Nota

Si el sistema muestra No Actions Available cuando hace clic con el botónsecundario, significa que su cuenta de inicio de sesión no tiene los privilegiosadecuados y, por lo tanto, no puede administrar las alertas.

3. Después de una o más actualizaciones, los valores en las columnas Ack y Ownerreflejan sus acciones.

Administrar alertas

Administrar alertas 43

Líneas de tiempo para la administración de alertasLa administración de alertas normalmente consiste en el monitoreo de la lista dealertas y en el trabajo con cada alerta de manera adecuada, de modo que esta quedeINACTIVE y desaparezca 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 alertasACTIVE 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 INACTIVE.

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

Monitoreo eficienteEl siguiente programa de monitoreo en dos pasos ayuda a administrar las alertas demanera eficiente:

1. Los administradores y usuarios pueden usar el informe Operations > Alerts >Unassigned Alerts para tomar o asignar la propiedad de las alertas.

2. Los usuarios pueden ver su lista de alertas asignadas en el informe Operations >Alerts > All Alerts .

l Puede crear una lista personal de alertas asignadas aplicando un filtro en lacolumna Owner igual a su nombre de usuario.

l Pueden hacer que las alertas críticas aparezcan en la parte superior de su listapersonal haciendo clic en la columna Severity para cambiar el método deordenación.

Línea de tiempo para las alertas MOMENTARYEn el caso de las alertas MOMENTARY, la acción Acknowledge establece la alertacomo INACTIVE. En el caso de las alertas MOMENTÁNEAS, si no se realiza ningunaacción después de 7 días, las alertas se vuelven INACTIVE.

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 INACTIVE y desaparece del informedespués de una determinada cantidad de tiempo (unmáximo de 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 deusuario.

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

Administrar alertas


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 enla alerta y elige Acknowledge.

d. La alerta se vuelve INACTIVE y desaparece del informedespués de una determinada cantidad de tiempo (unmáximo de 2 horas).

3. Si los usuarios no realizan ninguna acción sobre la alerta durante 7 días, la alerta sevuelve INACTIVE y desaparece del informe.

Línea de tiempo para las alertas DURABLEPara las alertas DURABLE, 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 TakeOwnership o Acknowledge. En el caso de una alerta duradera, unaconfirmación también establece 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 comoINACTIVE.

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

Administrar alertas

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

Administrar alertas


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 ylimitar el contenido del informe mediante la aplicación de filtros.

l Adición de nuevas columnas...............................................................................48l Cambio del orden de clasificación recomendado en un informe..........................48l Filtrado de un informe ....................................................................................... 50l Cambio de un nombre de columna en un informe............................................... 50l Agregar ID de evento de origen a los informes....................................................51

Informes personalizados 47

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 enel informe 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.

Todos los campos de la base de datos de eventos están disponibles para mostrarsecomo una columna. Esto incluye todos los campos definidos por el sistema y definidospor el usuario, y las propiedades de administración de grupos (Platform, Business Unit,Customer y Location).

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

Procedimiento

1. Seleccione el botón Customize Table Columns situado en la esquina superiorderecha del informe.

2. En el cuadro de diálogo Table Customization que aparece, para cada columnaque desee mostrar en el informe, seleccione Display the column en la listadesplegable.

Las columnas aparecen en la tabla en el mismo orden que en esta lista.

3. De manera opcional, reorganice el orden de las columnas arrastrando losnombres de campo a una nueva posición en la lista.

4. 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 uninforme

Los 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. Elorden preestablecido 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,seguidas por severidades menores y en el orden en el que se crearon, con la alerta másreciente primero.

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 paraobtener instrucciones.

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 TableColumns.

b. En el cuadro de diálogo Table Customization que aparece, arrastre lascolumnas hacia el área Sorted columns y seleccione Ascending oDescending.

En la siguiente imagen, el usuario configura un orden por Owner yComponent Type.

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 enel ícono Sort nuevamente.


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

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 hacerun cambio 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 esacolumna no está disponible para filtrar.

2. En el cuadro emergente que aparece, ingrese el valor de filtro que representalas filas que 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 dedatos.

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 enEDIT MODE.

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 paraexponer los campos 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.



Agregar ID de evento de origen a los informesEl ID de evento que aparece en el informe Alert Details es un ID de evento de ViPRSRM. Este ID es diferente de cualquier ID de evento generado por el origen del evento.Puede agregar el ID de evento de origen a los informes.

El campo systemdefined1 en la base de datos de eventos almacena un ID de eventoque proviene del origen del evento. Si el origen no envía ID de evento, el camposystemdefined1 está en blanco.

El siguiente procedimiento describe cómo usar el modo de edición para agregar el IDde evento de origen al informe Alert Details, visible para todos los usuarios. Tambiénpuede utilizar el procedimiento descrito en Adición de nuevas columnas en la página48, mediante la selección de la columna systemdefined1.

Procedimiento

1. Haga clic en Edit Mode.

2. En el árbol de navegación en el modo de edición, vaya a Operations > Alerts >All Alerts > Alert Details Expansion On Alert Name > Alert Details andImpact Analysis > Alert Details.

3. Para agregar el nuevo campo a los campos del encabezado, haga clic en lapestaña Report Configuration.

4. Expanda Description and Properties.

5. En Displayed Properties, haga clic en Add property.

6. Desplácese al final de la lista de propiedades para configurar la nueva propiedad.

a. En el primer campo, escriba systemdefined1.

b. En el segundo campo, seleccione Custom.

c. En el tercer campo, escriba una etiqueta para la propiedad, como SourceEvent ID.

d. Para especificar la posición del campo, desplace el cursor sobre las flechas yarrastre la fila a la posición deseada.

7. Para agregar el nuevo campo a la tabla, haga clic en Report Details: PestañaTable.

8. Haga clic en + Property.


Agregar ID de evento de origen a los informes 51

9. Desplácese al final de la lista de propiedades para configurar la nueva propiedad.

a. En Column Name, escriba una etiqueta para la columna, por ejemplo, SourceEvent ID.

b. Para Property, escriba systemdefined1.

c. Para especificar el orden de la columna, desplace el cursor sobre la barraazul y arrastre la fila a la posición deseada.


11. Haga clic en BROWSE MODE.

Resultados

La siguiente imagen muestra el nuevo campo en el encabezado y en la tabla.



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.

Capítulo 5, "Configuración de la infraestructura de alertas"

Capítulo 6, "Administre y configure las definiciones de alerta"

Capítulo 7, "Notificaciones de alerta"

Capítulo 8, "Proceso de archivo de alertas"

Capítulo 9, "Monitoreo y solución de problemas"

Administración de alertas 53

Administración de alertas


CAPÍTULO 5

Configuración de la infraestructura de alertas

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

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

actualización...................................................................................................... 58l Configuración de un servidor SMTP ..................................................................58l Configuración de adaptadores de emisión de alertas para usar el cifrado y la

compresión........................................................................................................ 59

Configuración de la infraestructura de alertas 55

Configuración de alertasLas funciones de emisión de alertas se incluyen con la licencia de ViPR SRM principal yse instalan como parte de vApp de ViPR SRM. Existen algunas tareas de configuraciónque se deben llevar a cabo después de la instalación.

La instalación de ViPR SRM realiza lo siguiente en relación con el módulo de emisiónde alertas:

l Instala el back-end de alertas en el servidor de back-end primario de ViPR SRM.Para el balanceo de carga, puede tener múltiples Back-ends de alertas, pero cadauno requiere sus propios Front-end de alerta.

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

La siguiente tabla resume las tareas de configuración necesarias para implementar lacreación de informes de alertas consolidadas de ViPR SRM.

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

Tarea Descripción Procedimiento

Configure losdispositivos para enviareventos y traps a ViPRSRM

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

Para obtener instruccionesespecíficas de dispositivos,consulte el capítulo deSolutionPack correspondienteen la Guía de SolutionPack deEMC ViPR SRM, disponible enel Índice de documentación deViPR SRM 4.0.

Habilite y configure lasdefiniciones de alertas

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

Consulte Administre yconfigure las definiciones dealerta en la página 61.

(Opcional) Configurelas definiciones dealertas denotificaciones globales

Para enviar notificaciones porcorreo electrónico o traps de otrosfabricantes, configure lasdefiniciones de alerta globales.

Consulte Notificaciones dealerta en la página 73.

Configurar el servidorSMTP (si aún no sehizo)

Para que el módulo de emisión dealertas envíe notificaciones porcorreo electrónico, se debeconfigurar un servidor SMTP. Estamisma configuración maneja correos

Consulte Configuración de unservidor SMTP en la página58.



https://community.emc.com/docs/DOC-52237


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

Tarea Descripción Procedimiento

electrónicos de informescalendarizados.

(Opcional) Configurelos componentes deemisión de alertas

Todos los procesos que contribuyencon la consolidación de alertas seinstalan con configuracionespredeterminadas. En la mayoría delos casos, las configuracionespredeterminadas son adecuadas yno son necesarias configuracionesadicionales.

Consulte Descripción de loscomponentes de emisión dealertas en la página 101 y Editar archivos deconfiguración del proceso enla página 88.

(Opcional) Configurelos adaptadores para elcifrado y la compresión

De manera opcional, configure losadaptadores de emisión de alertaspara utilizar la compresión y elcifrado al comunicarse con el back-end de alertas.

Consulte Configuración deadaptadores de emisión dealertas para usar el cifrado yla compresión en la página59.

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

Los adaptadores de emisión de alertas deben estar habilitados para que funcionen lasdefiniciones de alertas.

Los adaptadores de emisión de alertas son procesos que se ejecutan en el back-end dealertas. Participan en el proceso de normalización de ciertos tipos de alertas. Sonespecí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 deViPR SRM. Deben permanecer habilitados para que la consolidación de alertasfuncione. En condiciones normales, no hay ningún motivo para deshabilitarlos.

Procedimiento

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

2. En la lista de adaptadores situada en el panel derecho, use la columna State afin de garantizar 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.


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

Preserve las personalizaciones de la definición de alertadurante una 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 incluyenpasos para copiar y guardar las definiciones de alerta personalizadas antes de laactualización y volver a aplicar las personalizaciones manualmente después de laactualizació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.

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 futurasactualizaciones.

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 >Local Manager > Alert definitions.

2. Examine los nombres de carpeta de SolutionPack para buscar los nombressimilares. Por ejemplo, busque dos nombres de carpeta que contengan el mismonombre de SolutionPack.

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

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

Configuración de un servidor SMTPConfigure un servidor SMTP para habilitar las funciones de correo electrónico en elproducto.

Procedimiento

1. Haga clic en Administration > Modules > Alerting.

2. Desde el anuncio, haga clic en Global Settings.

3. Configure los campos de SMTP.


Ha configurado correctamente las variables de SMTP en el servidor de back-end (alertas). En una configuración de un servidor, esta configuración se aplicatambién al servidor de front-end.

5. En una configuración con más de un servidor, establezca las variables de SMTPen cada servidor de front-end.



Nota

Este paso se requiere en una aplicación virtual de 4 VM, o si la instalaciónincluye más de un front-end.

a. En el servidor de back-end, copie las variables de SMTPen /opt/APG/bin/apg.properties.

b. En cada servidor de front-end, pegue las variables en /opt/APG/bin/apg.properties.

6. Reinicie el servidor Tomcat.

a. Vaya a Administration > Centralized Management > Logical Overview >Miscellaneous > Web Servers.

b. Haga clic en un servidor Tomcat.

c. Haga clic en Restart.

Configuración de adaptadores de emisión de alertas parausar el cifrado y la compresión

Los adaptadores de emisión de alertas pueden configurarse para utilizar la compresióny el cifrado al comunicarse con el back-end de alertas. Puede configurar el cifrado y lacompresión manualmente mediante el ingreso de parámetros o puede usar un archivode configuración. Siga los pasos a continuación para configurar el cifrado y lacompresión mediante un archivo de configuración.

Antes de comenzar

Cree un archivo negotiation-connector.xml con las siguientes líneas:

<?xml version="1.0" encoding="UTF-8"?>

<config xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" x mlns="http://www.watch4net.com/APG/ChannelNegotiationConnector">

<host>localhost</host>

<port>2020</port>

<buffer-size>32768</buffer-size>

<retry-count>10</retry-count>

<retry-timeout>5000</retry-timeout>

<connect-timeout>60000</connect-timeout>

<write-timeout>5000</write-timeout>

<drop-control-fields>true</drop-control-fields>

<capabilities>encryption(@active=forced) compression(@active=forced)</capabilities>

</config>


Configuración de adaptadores de emisión de alertas para usar el cifrado y la compresión 59

Procedimiento

1. Inicie sesión en la consola y vaya a Administration > Modules > Alerting >Local Manager > Adapters > APG Values Socket Listener.

2. En la lista desplegable Configuration type, seleccione Configuration file.

3. En Negotiation configuration file, haga clic en Choose File y agregue elarchivo negotiation-connector.xml que ha creado.




CAPÍTULO 6

Administre y configure las definiciones de alerta

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

l Acerca de la configuración de las definiciones de alerta..................................... 62l Definiciones de alerta contextualizadas y no contextualizadas...........................62l Acceso a las definiciones de alerta..................................................................... 63l Habilitación y deshabilitación de definiciones de alerta...................................... 64l Modificación de definiciones de alertas..............................................................64l Adición de una acción de registro a una definición de alerta...............................65l Configuración de una definición de alerta ..........................................................67l Contextualización de una definición de alerta.....................................................68l Acerca de las definiciones de alertas de ESRS................................................... 70

Administre y configure las definiciones de alerta 61

Acerca de la configuración de las definiciones de alertaUna definición de alerta define las acciones que se deben realizar cuando un eventocumple las condiciones definidas. En ocasiones, las condiciones son configurables.

La interfaz de front-end de alertas presenta las partes configurables de una definiciónde alerta como campos que se pueden configurar fácilmente. Por ejemplo, aquí seencuentra el formulario para configurar los umbrales de utilización para una alertarelacionada con los puertos del switch.

Una definición de alerta debe estar HABILITADA para que se produzcan las accionesespecificadas.

Definiciones de alerta contextualizadas y nocontextualizadas

Las definiciones de alertas contextualizadas permiten más de un conjunto de valoresde configuración. Los contextos con nombres diferentes se pueden configurar demanera diferente.

Las definiciones de alertas contextualizadas proporcionan las siguientes ventajas:

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

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 opuede conservar los valores instalados en el contexto predeterminado y crear uncontexto nuevo para los valores personalizados.



Al configurar una definición de alerta contextualizada, debe seleccionar el contextopara el cual proporcionará valores. Puede crear nuevos contextos y asignar nombres anuevos contextos.

Las definiciones de alertas no contextualizadas pueden tener solo un conjunto devalores de configuración.

Acceso a las definiciones de alertaPuede configurar y activar o desactivar las definiciones de alerta. También puede veruna representación gráfica de la definición de alerta, modificarla (por ejemplo, agregaro eliminar acciones, o cambiar el filtro) y agregar nuevas definiciones de alertas.

Procedimiento

1. Haga clic en Administration > Modules > Alerting > Local Manager > Alertdefinitions.

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 onombres de 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 unadefinición de alerta y elija una de las siguientes acciones.

Edit Proporciona una vista gráfica de los componentes de ladefinición de alerta, con acceso a cada componente. Puedeagregar, eliminar y cambiar la configuración de loscomponentes. Use esta opción para agregar o eliminarcomponentes, como acciones o comparadores.

Configure Proporciona acceso a los cuadros de diálogo de configuraciónde cada componente de la definición de alerta. Use esta opciónpara cambiar la configuración de un componente, como losdestinatarios de correo electrónico en acciones de correo o losvalores de umbral en comparadores.

Probe No disponible. Los sondeos se implementan como un botón deprueba cuando se configura una definición de alerta.

Enable/Disable

Habilita o deshabilita la definición de alerta.

Delete Elimina la definición de alerta del sistema.


Acceso a las definiciones de alerta 63

Nota

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

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

Habilitación y deshabilitación de definiciones de alertaMuchas definiciones de alerta se instalan en el estado deshabilitado. Debe habilitarlassi desea 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.

Modificación de definiciones de alertasLos administradores pueden cambiar las definiciones de alertas predeterminadas paraque satisfagan las necesidades de la instalación.

Entre los cambios más comunes, se incluyen:

l Cambiar los valores de los comparadores.

l Adición de acciones de registro.

Nota

No agregue la acción de evento de ESRS a ninguna definición de alerta.

l Configuración de notificaciones.



l Contextualizar una configuración de definiciones de alertas

Adición de una acción de registro a una definición de alertaLas definiciones de alerta predeterminadas incluyen la acción de Trap de alerta deSNMP para convertir eventos en alertas y escribirlas en la base de datos de eventos.Puede agregar una acción adicional para escribir el evento entrante en un archivo deregistro.

Nota

No agregue la acción de evento de ESRS a ninguna definición de alerta. La acción deevento de ESRS es solo para uso de EMC.

Suponga que desea usar un archivo de registro a fin de recopilar ciertos eventos paraun análisis posterior. Por ejemplo, desea registrar los eventos filtrados por la definiciónde alerta Backend Processing Delay en la carpeta EMC M&R Health.Procedimiento

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

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.

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


Adición de una acción de registro a una definición de alerta 65

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ónpara la 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.Puede cambiar los valores completados.

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

Para nuestro ejemplo, escriba: Process Delay Log.

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

d. Para Entry, se aceptan variables. El formato de una variable esPROP.'nombredepropiedad', donde nombredepropiedad es un campo en losdatos que se envían a la definición de alerta. Consulte Formato normalizadode Trap de alerta y Trap de borrado en la página 148 para conocer nombresde propiedad utilizados en los traps. nombredepropiedad no se limita a laspropiedades de traps. Por ejemplo, en el caso de una alerta de umbral, otraspropiedades o métricas recopiladas por un recopilador se utilizan en ladefinición de alerta y están disponible para utilizarse aquí, incluso si dichapropiedad no está en el MIB de Trap de alerta.

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 aCondition met 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ímboloLog y suelte 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 anddisable.

Configuración de una definición de alertaLa acción Configure le permite cambiar el filtro y los ajustes configurables en unadefinición de alerta; agregar nuevos contextos y configurarlos, si es necesario; yprobar o sondear los resultados de la definición de alerta.

Por ejemplo, las definiciones de alerta a menudo comparan los valores en un eventocon una configuración de umbral. Un filtro define qué eventos se deben considerar. Siuna definición de alerta está contextualizada, puede definir distintos filtros o valoresde umbral y denominarlos.

Nota

No todas las definiciones de alerta se contextualizan.

Procedimiento

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

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

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

l Si la alerta está contextualizada, observará uno o más contextos connombre, con los valores y nombres de parámetros configurables de cadacontexto. De forma predeterminada, un contexto se denomina Default.


Configuración de una definición de alerta 67

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 de cualquiera de los contextos existentes, incluidos elcontexto Default o cualquier otro contexto con nombre.

l Cree un contexto nuevo de la siguiente manera:

a. Haga clic en Add.

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

c. Escriba los valores en el nuevo contexto.

l Para cada contexto, elija Enable o Disable. Cuando se habilitan varioscontextos, los eventos entrantes se procesan varias veces, una vez paracada contexto habilitado.

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


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

Contextualización de una definición de alertaPuede agregar contextualización a componentes de una definición de alerta yestablecer los valores para el contexto predeterminado.

En este procedimiento se describe cómo agregar contextualización a un componentede una definición de alerta. Se trata de un proceso que se lleva a cabo una sola vez yque configura un componente y un parámetro para contextualización. A partir deentonces, los usuarios pueden agregar contextos adicionales haciendo clic con elbotón secundario en la definición de alerta y seleccionando Configure.

Muchos de los componentes de la definición de alerta, incluidos todos loscomparadores de umbral, se contextualizan de manera inmediata. Los administradorespueden usar este procedimiento para contextualizar aquellos que no estáncontextualizados.



Nota

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

Procedimiento

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

2. Haga doble clic en el componente de la definición de alerta que deseacontextualizar.

Aparecerá un cuadro de diálogo de configuración para el componente.

3. Haga clic en la flecha pequeña hacia abajo que aparece junto al elementoconfigurable, como un parámetro o un filtro, y seleccione Define configuration.

Esta es la flecha de un filtro:

Aparece un conjunto de campos de configuración de contexto.

4. Complete los campos:

l Para Configuration item key label, escriba un nombre para este parámetroque el usuario ve en la ventana de configuration.

l De manera opcional, para ordenar los parámetros, seleccione el orden en queaparecerán los parámetros en la ventana de configuración.

l Para Configuration item key, ingrese una clave que se use para identificarde manera exclusiva el contexto y hacer referencia al contexto en otroscontextos dentro de la misma definición de alerta. Por ejemplo, unadefinición de alerta puede tener tres acciones de registro para diferentescondiciones. Mediante una clave, puede configurar el componente de acciónde registro una vez y, luego, hacer referencia a él en los demás componentesseleccionando Configuration Reference al configurar el segundo y el tercercomponente.

l Para el último campo, escriba la configuración predeterminada que apareceen el campo cuando el usuario agrega un contexto.

5. Haga clic en Aceptar.

6. Repita los pasos 3 y 4 para parámetros adicionales del componente.


Contextualización de una definición de alerta 69

7. Haga clic en la opción Save que aparece debajo del pizarrón de definiciones dealertas.

8. Como práctica recomendada, agregue el primer contexto.

De lo contrario, el componente permanecerá sin configurar.

a. Vuelva a la lista de definiciones de alertas, haga clic en la definición de alertay seleccione Configure.

b. Haga clic en Add.

c. Proporcione un nombre para el contexto. Una práctica recomendada esasignar el nombre Default al primer contexto.

d. Haga clic en Save.

Resultados

La alerta ahora aparecerá en la lista de definiciones de alertas con un ícono que indicaque está contextualizada. Los usuarios pueden configurarla para agregar contextosadicionales y para habilitar o deshabilitar los contextos.

Acerca de las definiciones de alertas de ESRSNo cambie ni reconfigure las definiciones de alertas del soporte remoto seguro deEMC (ESRS).

SolutionPack for EMC M&R Health incluye una función opcional que envía alertassobre ciertas condiciones de estado a EMC. La función se instala y se configuradurante la instalación de SolutionPack for EMC M&R Health, mediante la pregunta debloques de emisión de alertas.

Nota

A menos que configure los ajustes de ESRS en la pregunta de bloques de emisión dealertas, no se enviará ninguna información a EMC.

Hay un conjunto de definiciones de alertas de ESRS asociado con esta función. Tengaen cuenta lo siguiente:

l De manera predeterminada, las definiciones de alertas de ESRS están ocultas.Consulte la sección siguiente para hacerlas visibles.

l No cambie ni reconfigure las definiciones de alertas de ESRS.

l No agregue la acción de evento de ESRS (que se usa en las definiciones de alertasde ESRS) a otras definiciones de alertas.

l Los comandos de definición de alerta Enable y Disable no se aplican a lasdefiniciones de ESRS. Las definiciones de ESRS no siempre se habilitan al instalarlos bloques de alertas de SolutionPack for EMC M&R Health, y siempre estándeshabilitadas en el caso contrario.

Haga visibles las definiciones de alertas de ESRSDe manera opcional, puede hacer visibles las definiciones de alertas de ESRS paraverlas.

Procedimiento

1. Vaya a Administration > Modules > Alerting > Alert Definitions.

2. En el área de anuncios de la página de alertas, haga clic en User Settings.



3. Active la casilla de verificación Display Hidden Definitions.


Las definiciones de alertas de ESRS aparecen en el árbol. Son solo para fines devisualización. No las modifique.


Haga visibles las definiciones de alertas de ESRS 71

CAPÍTULO 7


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

l ¿Qué son las notificaciones de alerta?............................................................... 74l Acerca de las definiciones de alerta globales...................................................... 74l Configurar notificaciones .................................................................................. 76l Modificación de los destinatarios, el asunto y el mensaje de una notificación .... 79l Crear una plantilla de notificación.......................................................................79

Notificaciones de alerta 73

¿Qué son las notificaciones de alerta?Una notificación de alerta envía comunicaciones configuradas acerca de las alertas.

ViPR SRM incluye las siguientes definiciones de alerta globales para fines denotificación:

l Alert Consolidation Email Notification: envía un correo electrónico a una listaconfigurada de destinatarios cada vez que se producen las condiciones de alertaconfiguradas.

l Alert Consolidation Trap Notification: envía un SNMP trap a un terceroconfigurado cada vez que ocurren las condiciones de alerta configuradas.

De manera inmediata, estas definiciones son muy generales, y envían notificacionespor todas las alertas de nivel de gravedad 1, 2, 3 o 4. Se recomienda considerar estasdos definiciones de alerta como plantillas, y copiarlas y modificarlas para satisfacer losrequisitos de notificación de su instalación. Puede modificar las copias para adecuarlasa requisitos de notificación individuales muy específicos.

Por ejemplo, es posible configurar filtros y listas de destinatarios para enviarnotificaciones acerca de conjuntos definidos de plataformas a conjuntos específicosde destinatarios.

Si planea crear muchas definiciones de alerta del mismo tipo, considere la posibilidadde crear una plantilla para almacenar la información común. Por ejemplo, una plantillade correo podría almacenar el asunto y el mensaje, y solo se tendría que modificar lalista de direcciones en cada definición de alerta.

Acerca de las definiciones de alerta globalesViPR SRM viene con un conjunto de definiciones de alerta globales con filtros muygenerales, que emiten notificaciones para una amplia variedad de alertas.

Por lo general, se recomienda no activar las definiciones globales como vieneninstaladas. Las definiciones de alerta globales podrían generar más notificaciones delas que son necesarias para una instalación.

El proceso recomendado es copiar las definiciones de alerta globales y modificar lascopias para definir condiciones más específicas que cumplan con sus requisitosespecíficos. A continuación, habilite las copias.

La siguiente tabla describe las definiciones de alerta globales y presenta los elementosque debe considerar adaptar para situaciones específicas de interés.

Tabla 3 Usos recomendados de definiciones de alerta globales

Nombre de la definiciónde alerta

Descripción Consideraciones

Alert Consolidation EmailNotification

Genera una notificación porcorreo electrónico para unalista específica dedestinatarios por todos loseventos con gravedad de 1, 2,3 o 4 en los que lasdefiniciones de alertas esténactivadas.

Lo predeterminado es que seenvíe un correo electrónicopara cada alerta Crítica,Importante, Menor yDesconocida.Considere crear copias de ladefinición de alerta global yeditar los filtros en las copias



Tabla 3 Usos recomendados de definiciones de alerta globales (continuación)



para limitar las notificacionespor correo electrónico a unsubconjunto de alertas, comosolo las alertas críticas y lasmás importantes, o solo lasalertas de ciertos orígenes deinterés.

Para especificar losdestinatarios, configure losparámetros de notificación decorreo electrónico en lasdefiniciones de alerta.

Alert Consolidation TrapNotification

Genera una notificación Trapal puerto 162 (el conocidopuerto de SNMP trap) en unhost específico para todos loseventos con gravedad de 1, 2,3 o 4 en los que lasdefiniciones de alertas esténactivadas.

Está predeterminado que seenvíe una alerta a unaaplicación remota de SNMPpara cada alerta Critical,Major, Minor y Unknown.Considere crear copias de ladefinición de alerta global yeditar los filtros en las copiaspara limitar las notificacionesde trap a un subconjunto dealertas, como solo las alertascríticas y las más importantes,o solo las alertas de ciertosorígenes de interés.

Configure los parámetros dedirección IP de host receptoren la definición de alerta.

File System Utilization Genera acciones de registro yacciones de correoelectrónico para cualquiersistema de archivos encualquier Host monitoreadocuya métrica de utilizaciónactual sea superior al 90%.

Si otras definiciones dealertas de SolutionPackactivas generan alertas decapacidad de archivos queaparecen en los informes dealertas, es posible que nonecesite esta definición dealerta.Está predeterminado que seenvíen acciones de correoelectrónico y acciones deregistro. Considere laposibilidad de copiar estadefinición de alerta y, acontinuación, eliminar una delas acciones (correoelectrónico o registro) de lacopia.


Acerca de las definiciones de alerta globales 75

Tabla 3 Usos recomendados de definiciones de alerta globales (continuación)



Configure la ubicación delarchivo de registro y losparámetros de notificación decorreo electrónico en ladefinición de alerta.

Configurar notificacionesUtilice este procedimiento para configurar notificaciones de trap de otros fabricanteso por correo electrónico.

A continuación, se incluye un resumen:

1. Cree una nueva definición de alerta copiando y pegando la definición AlertConsolidation Email Notification o la definición Alert Consolidation TrapNotification.

2. Edite la copia para definir las condiciones deseadas.

a. En el componente Filter Entry, asegúrese de que la primera frase especifiqueAdapterName is Mail Forwarder Adapter. Este adaptador se requiere para lasnotificaciones de trap y por correo electrónico.

b. En el componente Filter Entry, altere frases de filtro adicionales según seanecesario, en función de sus requisitos.

c. En el componente Action, configure los parámetros según sea necesario parasatisfacer sus requisitos.

3. Guarde y habilite la nueva definición de alerta.4. Para las notificaciones de correo electrónico, asegúrese de que el servidor SMTP

esté configurado en el front-end de alertas. Consulte Configuración de un servidorSMTP en la página 58.

Procedimiento

1. Para copiar una definición de alerta global:

a. Vaya aAdministration > Modules > Alerting > Alert definitions.b. De manera opcional, cree una carpeta para almacenar nuevas alertas de

notificación. Consulte Creación de carpetas de definición de alerta en lapágina 143.

c. En el panel izquierdo, seleccione la definición de alerta para copiar.Las definiciones de alerta globales están al final de la lista.



d. Haga clic en el ícono Copy, en la parte superior del árbol de navegación.

e. Seleccione la carpeta donde desea pegar la copia y haga clic en el íconoPaste.

Para almacenar la copia con el original, haga clic en la carpeta de nivelsuperior.

f. Escriba un nombre para la copia en el cuadro de diálogo que aparece y hagaclic en Ok.

2. Para definir las condiciones para esta notificación, edite el filtro de la siguientemanera:

a. En el panel derecho, haga clic con el botón secundario en la definición dealerta y seleccione Edit.

b. Haga doble clic en el símbolo Filtered Entry.

c. En la sección Filter, asegúrese de que adapterName sea Mail ForwarderAdapter.

Si no es así, debe cambiarlo. Haga clic en el bloque que contiene el nombredel adaptador, elija Edit Expression y cambie el nombre. El adaptador dereenviador de correo se requiere para las notificaciones de correoelectrónico y trap.

d. Haga clic con el botón secundario en el segundo bloque del filtro y seleccionelas opciones pertinentes para cambiar o agregar frases adicionales al filtro.

Por ejemplo, cambie el segundo bloque para filtrar solo las alertas degravedad 1.

e. Haga clic en Ok.


Configurar notificaciones 77

3. Para configurar los parámetros de notificación:

a. En la definición de alerta, haga doble clic en el componente de color verde.

b. En la sección Parameters, configure cada parámetro según sea necesario:

Nota

La flecha hacia abajo que precede a los cuadros de texto de parámetro seutiliza para contextualizar la alerta. Consulte Contextualización de unadefinición de alerta en la página 68 para obtener más información.

Utilice las siguientes pautas para configurar la notificación de correoelectrónico o trap.

Acción denotificación

Parámetro

Descripción

Correo To Destinatarios de correo electrónico.Se requiere al menos una dirección de correo electrónico.Separe las diversas direcciones con coma.

Subject Asunto del correo electrónico.Utilice el valor preconfigurado o modifíquelo para satisfacer susnecesidades.

Message Mensaje de correo electrónico.Utilice el valor preconfigurado o modifíquelo para satisfacer susnecesidades.

El asunto y el mensaje pueden incluir valores de la alerta con lasiguiente sintaxis:

PROP.'fieldname'

Trap Host Host receptor.

Port Puerto receptor.

Community Comunidad de SNMP en el mensaje.

Generic ID ID genérico de SNMP en el mensaje.

Enterprisespecific ID

ID de empresa de SNMP en el mensaje.

Trapcontent

Mensaje de trap para enviar a otros fabricantes.Utilice el valor preconfigurado.

Si cambia el contenido de trap, ya no coincidirá con el archivoMIB para traps de otros fabricantes proporcionado en elapéndice de esta guía.

c. Haga clic en Test Action para verificar la configuración.

Espere una respuesta.



Si falla una acción de correo, compruebe que esté configurado un servidorSMTP en el front-end de alertas. Para obtener más información, consulte Configuración de un servidor SMTP en la página 58.

Si falla una acción de trap, compruebe que los parámetros Host y Port seancorrectos para el proceso de escucha de SNMP receptor de otrosfabricantes.

d. Haga clic en Ok.

4. Haga clic en Save y, a continuación, haga clic en Save and enable o Save anddisable.

Modificación de los destinatarios, el asunto y el mensaje deuna notificació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

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

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

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

Aparece un conjunto de barras azules. Cada barra representa un componente dela definición de alerta. Para configurar los parámetros de cada componente, useesta interfaz.

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ónde notificació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ónde notificació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.

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


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

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 listasde destinatarios de correo electrónico diferentes.

Procedimiento

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

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

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

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 editarlos valores completados en las acciones de correo individuales sies necesario.En To, proporcione direcciones de correo electrónico. Separe lasdiversas direcciones con coma.

En Subject y Message, se aceptan variables. El formato de unavariable es PROP.'propertyname', donde propertyname es uncampo en el archivo MIB de captura de alertas de ViPR SRM.Consulte Formato normalizado de Trap de alerta y Trap deborrado en la página 148 para obtener la lista de nombres depropiedad.

4. Haga clic en Create.

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



Figura 7 Nueva plantilla para las acciones de correo


Crear una plantilla de notificación 81

CAPÍTULO 8

Proceso de archivo de alertas

Los siguientes temas describen el proceso de archiving de alertas de ViPR SRM y susparámetros configurables.

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 del proceso .................................................... 88

Proceso de archivo 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 que las alertas permanecen en la base de datos es limitado y administrado. Elciclo de vida de las alertas tiene como consecuencia la administración de espacioautomá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 datosde eventos. 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 dealerta en una entrada de la base de datos en la página 154.

Se actualiza la alerta existenteUna alerta existente se actualiza solo cuando se realizan acciones de usuario en laalerta. Las acciones de usuario incluyen confirmar, cancelar confirmación, asignar,tomar propiedad, liberar propiedad o forzar el cierre.

Una misma alerta se produce nuevamenteEs 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.

Cuando la misma alerta se produce de nuevo, una nueva alerta se escribe en la tablaactiva, la instancia anterior de esa alerta se cierra y se marca como INACTIVA.

La alerta existente se desmarca (se hace INACTIVA)Las siguientes propiedades de una alerta se ven afectadas cuando se borra 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 4 Ajustes de configuración del proceso de transferencia

proceso::instancia

Nombrede archivo

Elemento 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 paracancelar una alerta después de que se confirme porerror.

Las alertas que no se tocaron (ignoradas) se cierran automáticamente y se envíana la tabla de archivoAdemás del ciclo activo de actualización y borrado descrito anteriormente, tambiénhay un ciclo activo sin cambios inactivo para manejar las alertas que no se borrandentro de un plazo determinado.

En el caso de alertas MOMENTÁNEAS, si una alerta todavía aparece en la tabla activadespués de un número configurable de días, se transfiere de la tablagenericevents_live a la tabla de archiving.

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 5 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 dearchiving 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 cerrary trasladar 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 del sistema totalmente medianteel proceso de vencimiento.

El proceso de vencimiento es configurable.

Tabla 6 Ajustes de configuración del proceso de vencimiento

proceso::instancia

Nombrede archivo

Atributos

Escritorgenérico enlí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 enel rendimiento de back-end al ajustar este valor deatributo.

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.



Tabla 6 Ajustes de configuración del proceso de vencimiento

proceso::instancia

Nombrede archivo

Atributos

El ejemplo muestra la configuración inmediata de atributos.Configura el proceso de vencimiento para ejecutarse una vezal día y retener alertas durante 30 días después de que seabren. Después de eso, se depuran 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 laalerta.

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 alerta en una entrada de la 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 seencuentra dentro 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 laconsola. 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 horade la siguiente manera:


Propiedades de las alertas que afectan el ciclo de vida 87

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

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

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

Antes de comenzar

Se requieren permisos del administrador.

Los archivos de configuración que controlan los procesos de ViPR SRM son archivosde texto 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 el proceso :: instancia 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ónpara editar.

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 Configuraciones específicas de dispositivos....................................................... 91l Archivos de registro para monitorear..................................................................91l Uso de un espía de eventos para solucionar problemas de las alertas.................92l Utilice el sondeo para solucionar problemas en una definición de alerta............. 94

Monitoreo y solución de problemas 89

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

Procedimiento

1. Para investigar el estado del back-end de alertas:

a. Vaya a Biblioteca de informes > EMC M&R Health > Logical Summary >Backends.

b. Desplace el cursor sobre la esquina superior derecha del informe de mapa depuntos problemáticos Backends y haga clic en el ícono Make this elementwider.

Ahora puede ver los nombres en los bloques del mapa de puntosproblemáticos.

c. En la sección Alerting, haga clic en el bloque Alerting-Backend.

d. Desplácese hacia abajo para ver los siguientes informes de estado para elbloque Alerting-Backend:

l Availability (%), CPU Usage (%), Memory Usage (%) y Memory Used

l El informe Alert Data enumera más componentes.

e. Para comprobar las tendencias de disponibilidad y volumen de datos de losprocesos del adaptador, haga clic en Adapters.

2. Para investigar el estado de los procesos de consolidación de alertas:

a. Vaya a Biblioteca de informes > EMC M&R Health > Logical Summary >Collectors.

b. Desplace el cursor sobre la esquina superior derecha del informe de mapa depuntos problemáticos Collectors y haga clic en el ícono Make this elementwider.

Ahora puede ver los nombres en los bloques del mapa de puntosproblemáticos.



c. En la sección Event Processing Managers , haga clic en el bloque Alert-Consolidation.

d. Desplácese hacia abajo para ver los siguientes informes de estado para elbloque Alert Consolidation:

l Availability (%), CPU Usage (%), Memory Usage (%) y Memory Used

l El informe Trap Receiver muestra las métricas de procesamiento detraps.

Configuraciones específicas de dispositivosLos dispositivos que generan eventos o SNMP traps deben configurarse para enviaresos eventos o traps al puerto de escucha de eventos de ViPR SRM o al receptor decondición de error de SNMP trap.

Se requiere esta configuración en cada dispositivo que deba participar en laconsolidación de alertas. Se incluyen instrucciones específicas de dispositivos en loscapítulos de SolutionPacks correspondientes de la Guía de SolutionPack de EMC ViPRSRM, disponible en el Índice de documentación de ViPR SRM 4.0.

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 ysolucionar problemas que este tenga.

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

Para obtener acceso a los archivos de registro en la consola, vaya a Administration >Centralized Management > Logical Overview > Events > nombre_del_proceso,expanda la barra azul denominada Log Files en el panel derecho, seleccione un nombrede archivo y haga clic en Download.

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

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


Configuraciones específicas de dispositivos 91


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 loseventos a medida que pasan por componentes espiados.

Un espía de eventos puede ayudar a depurar los eventos que fluyen a través delsistema. Al espiar un proceso, puede verificar los valores en los datos de eventodespués de que el 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-modules install event-processing-utils-1.2u1-linux-x64.pkg e instale el contenidodel 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és de 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 asignaun nombre a ese componente; para ello, agregue la palabra SPY al atributodata.

Por ejemplo, puede espiar el puerto de escucha de eventos mediante laadición de SPY al elemento para ALERT-EVENT-LISTENER, como se indicaa 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ónService Status 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 hagaclic en la barra 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 depropiedad de 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) .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 =


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

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

yes (OCCURRENCE,STRING) eventtype = MOMENTARY (OCCURRENCE,STRING) certainty = 100 (OCCURRENCE,STRING) severity = 4 (OCCURRENCE,STRING)

Utilice el sondeo para solucionar problemas en unadefinición de alerta

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 pruebasnuevas. El sondeo ayuda a crear definiciones de alerta complejas.

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



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.

Capítulo 10, "Información general acerca del proceso de consolidación de alertas "

Capítulo 11, "Crear alertas personalizadas"

Capítulo 12, "Creación de definiciones de alertas personalizadas"

Capítulo 13, "Alertas de la base de datos y caché activo"

Capítulo 14, "Formatos y MIB"

Capítulo 15, "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 aplicana todas las alertas, independientemente del origen del evento que las cause.

l Flujo de proceso de alertas comunes .................................................................98l Acerca de traps en ViPR SRM............................................................................99l Acerca de Trap de alerta y Traps de borrado de alertas.................................... 100l ¿Cómo se asignan las severidades de alerta?................................................... 100l Descripción de los componentes de emisión de alertas......................................101

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 escuchade evento, el receptor de condición de error, o directamente en el Back-end de alertascomo alertas de umbral o las alertas sobre los informes calendarizados. Cada uno deestos flujos específicos se describe más adelante. El resultado de cada uno de ellos esel mismo: un evento normalizado.

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

Figura 8 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 conlos datos de eventos. Las definiciones de alerta se almacenan en el front-end dealertas. Puede ver, editar y crear nuevas definiciones de alertas en la Consola deadministración de 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. Por lo general, la acciónes un Trap de alerta para convertir el evento en una alerta de ViPR SRM. Otrasacciones incluyen acciones de registro o acciones personalizadas potencialmente.

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

l Enviar el trap a host local en el puerto 2041

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


l Contener un mensaje que se adhiera al formato de ViPR SRM, como se muestraen todas las definiciones de alerta predeterminadas. Consulte Formatonormalizado de Trap de alerta y Trap de borrado en la página 148.

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 emisiónde alertas de ViPR SRM.

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 quelos datos ya se normalizaron, y no es necesario reformatearlos. El procesador deregistro envía el evento en el Modificador clave 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 eventos infiere valores de datos adicionales, porejemplo, categoría y propiedades relacionadas con grupos, como la plataforma, launidad de negocios, el cliente y la ubicación, y agrega el evento a la caché activa.

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. Ahora el evento es una alertade ViPR SRM.

9. El front-end primario de ViPR SRM accede a la base de datos de eventos paragenerar los informes de emisión de alertas.

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

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

Recepción de capturas como eventos (capturas de evento)Los traps de eventos son aquellos recibidos 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. Los traps de eventos se normalizan en el modelode alerta de ViPR SRM y se envían al back-end de emisión de alertas para suprocesamiento. Consulte Formato normalizado de Trap de alerta y Trap de borrado enla página 148 para conocer el formato normalizado requerido.

Envío de capturas de alerta para agregar una alerta en la base de datos (capturasde alerta)Alerting Backend crea las capturas de alerta para eventos que se normalizan. El trapde alerta debe insertarse en los datos de evento de la base de datos de eventos (tablagenericevents_live). Alerting Backend crea esta captura y envía el evento al Receptorde 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.

Envío de capturas a un sistema de otros fabricantes (capturas de otrosfabricantes)Los traps de otros fabricantes son aquellos que se envían desde ViPR SRM a otrosistema. Puede configurar estos traps mediante la definición de alerta global AlertConsolidation Trap Notification.


Acerca de traps en ViPR SRM 99

Por lo general, se utilizan traps de otros fabricantes para enviar las alertas de ViPRSRM a una herramienta de administración de alertas centralizada. Puede proporcionarel SRM-ALERTS-MIB a otros fabricantes. Consulte SRM-ALERTS-MIB en la página159.

Acerca de Trap de alerta y Traps de borrado de alertasEl Trap de alerta es el mecanismo para agregar un evento en la base de datos deeventos de ViPR SRM. El Trap de borrado de alertas borra un trap de alerta emitidoanteriormente.

Cuando decimos "trap de alerta" en ViPR SRM, nos referimos al trap que se envía alreceptor de condición de error con un mensaje en un formato predefinido que setransforma y se escribe en la base de datos de eventos.

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

Para agregar las acciones de Trap de alerta y Trap de borrado a nuevas definiciones dealertas, copie las configuraciones de las definiciones de alerta existentes. Asegúresede conservar las siguientes características:

l Utilice el host local como la dirección IP y el puerto 2041, que es el puerto dereceptor de condición de error de SNMP trap predeterminado para que ViPR SRMenvíe el trap al receptor de condición de error.

l Copie el contenido del trap de una definición de alerta existente y modifíquelasegún corresponda para asegurarse de que contenga los campos obligatorios y elformato para la entrada de base de datos de generic_events que se creará.

Consulte Formato normalizado de Trap de alerta y Trap de borrado en la página 148para obtener información sobre el orden de campos, descripciones y ejemplos.

¿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úmeroentero o 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 enumeradosutilizados para 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



Num SNMP ENUM se traduce a este valor en la base de datos e informes

4 null UNKNOWN

5 info INFORMATIONAL

Descripción de los componentes de emisión de alertasEn esta sección se proporcionan definiciones de referencia para todos loscomponentes y los procesos en el subsistema de alertas de ViPR SRM.

Front-end de alertas

El front-end de alertas existe en el front-end de M&R y se accede a él en laconsola utilizando Administration > Modules > Alerting. El front-end de alertascontiene las definiciones de alerta y sus dependencias. Este componenteinteractúa con uno o más back-ends de alertas.

Back-end de alertas

El back-end de alertas recibe datos y alertas sobre los datos. Puede tenermúltiples back-ends de alertas en distintos servidores para distribuir la carga.Cada back-end de alertas contiene configuraciones de alertas, como definiciones,adaptadores y otras dependencias 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 derendimiento enviados por un administrador recopilador a través de un conector decaché. Puede recibir eventos y flujos desde un Administrador de procesos deevento por medio de un Escritor genérico de eventos. También puede recibirinformes para emitir alertas desde el front-end de ViPR SRM o de otrosfabricantes.

Para acceder a los archivos de registro y de configuración del back-end dealertas, inicie sesión en la consola y vaya a Administration > CentralizedManagement > Logical Overview > Backends > AlertingBackend::nombredelainstancia.

Definición de alerta

Una definición de alerta incluye un filtro que define los eventos a los que se aplicala definición. Un evento debe coincidir con un filtro en una definición de alertaválida y que esté habilitada para actuar sobre ella, incluyendo la escritura en labase de datos.

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 el registro ola acción de Trap de alerta que obtiene el evento escrito en la base de datos deeventos. Si una definición de alerta no incluye una acción de Trap de alerta, loseventos manejados por esa definición de alerta no llegan a la base de datos y noaparecen en los informes.

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étricasa fin de determinar qué acción debe ser realizada, si es necesario.

Cada SolutionPack agrega su propio conjunto adecuado de definiciones de alertadurante la instalación del SolutionPack. Las definiciones personalizadas tambiénson posibles.


Descripción de los componentes de emisión de alertas 101

Para ver, personalizar y crear definiciones de alerta, inicie sesión en la consola yvaya a Administration > Modules > Alerting > Local Manager > Alertdefinitions.

Adaptadores.

Un evento es una estructura básica que incluye un registro de fecha y hora,nombre de evento, nombre de parte, nombre de dispositivo, etc. Los adaptadorestoman cualquier dato y lo transforman en ese modelo.

El formato de datos de evento es el mismo que el formato de Trap de alerta, yaque utiliza solo un subconjunto de los campos que utiliza un Trap de alerta. El Trapde alerta acepta datos desde el evento utilizando el formatoPROP.'fieldname'.

ViPR SRM se instala 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 los siguientes:

Adaptador de reenviador de correo

Este adaptador escucha en un conector (puerto 2012) en busca de eventosentrantes. Este adaptador se utiliza al enviar alertas como traps anotificaciones de otros fabricantes o al enviar alertas como mensajes decorreo electrónico.

Adaptador de escucha de conexión de valores de APG

Este adaptador escucha en el puerto 2010 en busca de valores del conectoren el archivo collecting.xml. Los datos tienen las propiedades deadapterName, que contiene el nombre de este adaptador y adapterType, quecontiene el RVSocketListener.

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 APG Report Data

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ás de cualquier valor creado mediante las fórmulas de front-end.

Receptor de condición de error

Un receptor de condición de error predeterminado se instala 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 dosfunciones en 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



se normaliza y, a continuación, se pasa por el back-end de alertas. El back-end de alertas hace coincidir el evento normalizado con una definición dealerta, y el evento 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.

Traps de alerta de definiciones de alerta

Para que un evento se escriba en la base de datos de eventos y se conviertaen una alerta de ViPR SRM, el evento debe coincidir con un filtro en unadefinición de 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ómoingresaron originalmente 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 losenvía al componente siguiente, el procesador de eventos de registro.

Para ver los archivos de configuración de receptor de condición de error(incluyendo todos los archivos MIB y de reglas instalados por SolutionPacks),inicie sesión en la consola 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 enesa página, describe la configuración predeterminada del receptor de condición deerror instalado y el formato de los archivos de reglas requerido.

Escucha de eventos genéricos

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 escuchade eventos genéricos los recopila. El puerto de escucha genérico de eventosescucha los eventos en un conector TCP usando el puerto 2040 y reenviando loseventos al procesador 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 enla consola y vaya a Administration > Centralized Management > LogicalOverview > 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. ViPRSRM utiliza el marcador de propiedades de eventos para resolver categorías de



evento e información de dispositivos para los datos de eventos, como se indica acontinuación:

l Categoría es una forma de clasificar eventos. Los usuarios de informespueden, a continuación, ordenar en una columna de categoría o aplicar unfiltro para limitar 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 un filtro de marcado de propiedad en la dirección IP en unevento para consultar la base de datos de ViPR SRM y obtener los valorespara el dispositivo y devtype asociados con la dirección IP. Este procesocompleta el archivo ip-to-devices.csv y hace que los informes deeventos sean más utilizables y significativos.

l Dispositivo crítico es una forma de identificar eventos de dispositivos que losusuarios consideran críticos. ViPR SRM incluye las alertas del informe dedispositivos críticos que enumera 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 38.

El marcador de propiedades de eventos también se utiliza para enriquecer losdatos de alertas con las siguientes propiedades de administración de grupos. Lasreglas de etiquetado para estas propiedades se editan utilizando la interfaz deadministración de grupos, y el informe All Alerts incluye botones para filtrarfácilmente los informes según los valores del grupo.

l La propiedad Platform clasifica los dispositivos en grupos de la plataforma,con el fin de filtrar los informes por plataforma. Un conjunto estándar dereglas de etiquetado viene preinstalado. Los usuarios pueden crear reglasadicionales de etiquetado para grupos adicionales.

l Las propiedades Business Unit, Customer y Location clasifican los dispositivosde acuerdo con los requisitos definidos por el usuario, con el fin de filtrar losinformes según esos valores de grupo.

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 losdatos requeridos 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 escontrolado por un conjunto de archivos XML que contiene reglas. Hay una reglade raíz, y, a continuación, se evalúan reglas posteriores en una cadena hasta quese alcanza una regla final. Cada SolutionPack instala reglas adecuadas para sudispositivo. Por ejemplo:



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 SolutionPack de VNX instala un archivo de reglas que mapea eventosgenéricos enviados desde el VNX para el formato de datos de evento.

Puede crear nuevos archivos de reglas. Como mejor práctica, no edite losarchivos existentes, debido a los riesgos de que se sobrescriban durante unaactualización. Para personalizar o agregar reglas nuevas para un dispositivo queya tiene reglas configuradas por un SolutionPack, cree un archivo que solo tengasus reglas nuevas y colóquelo en la cadena de archivos de reglas o copie el archivoexistente y cámbiele el nombre antes de editarlo.

La Guía del Administrador de procesador de registro de eventosdescribe laarquitectura de procesamiento de los archivos de reglas. Esta guía contiene unareferencia de reglas detallada. Allí están las reglas de análisis, marcado ycoincidencia, además de un conjunto de reglas básicas.

Para acceder a la configuración del procesador de registro de eventos y archivosde reglas y la documentación asociada, inicie sesión en la consola y vaya aAdministration > Centralized Management > Logical Overview > Events >Event-Log-Processor :: Alert Consolidation.

Escritor de eventos genéricos

El escritor de evento serializa todos los eventos que vienen en él y los envía alback-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 unadaptador diferente en el front-end de alertas que actúa sobre los eventosrecibidos.

Para acceder a estos archivos, inicie sesión en la consola y vaya aAdministration > Centralized Management > Logical Overview > Events >Generic-Event-Writer :: Alert Consolidation.

Escritor genérico en línea

Este componente es responsable de la inserción y actualización de datos en labase de datos.

Los archivos de configuración de este componente contienen los siguientes tiposde información relacionados con el almacén de datos:

l Los parámetros que se utilizan para conservar la base de datos, por ejemplo:Un URI, nombre de usuario y contraseña para la base de datos.

l Período de retención en 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 formatocorrecto.

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 alertas de ViPR SRM. Existencuatro orígenes para las alertas personalizadas.

l Crear alertas desde SNMP traps ..................................................................... 108l Crear alertas de eventos que se envían a una escucha ..................................... 113l Crear alertas de métricas recopiladas .............................................................. 120l Creación de alertas desde los informes calendarizados .................................... 123

Crear alertas personalizadas 107

Crear alertas desde SNMP trapsLos SNMP traps enviados desde dispositivos, redes u otros orígenes pueden ser elorigen de 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 lasdefiniciones de alerta, debe haber pares de definiciones para traps y Traps de borradosubsiguientes. Para obtener más información, consulte la sección de Ejemplos queaparece a continuación.

La siguiente figura muestra cómo los SNMP traps de dispositivos externos senormalizan en el sistema de emisión de alertas.

Figura 9 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 eventosnormalizados 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 en condiciones operacionales que coincidan con los datos deeventos.



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 emisión de alertas de ViPR SRM. Los SolutionPackspara estos dispositivos 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 eneste archivo son específicas para el MIB del dispositivo. El procesador de registroutiliza las reglas para mapear los datos de trap en el formato de eventonormalizado.

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 dealerta para convertirse en una alerta de ViPR SRM.

l valores de categoría (opcionales): Un SolutionPack puede especificar unacategoría de identificación para cada evento mediante la inserción de líneas dentrodelevent-category.csvarchivo de configuración para el Tagger de propiedaddel evento.

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 Switch FC Brocade de SolutionPack.

Supongamos que un puerto de switch Brocade experimenta un cuello de botella ygenera un trap de detección de cuello de botella denominado BdTrap. Si el switchBrocade está configurado adecuadamente, envía este trap al puerto 2041 en elservidor de back-end de 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 > TrapReceiver: Alert Consolidation, uno de los archivos de configuración se llamaconf/BD-MIB.xml. Aquí se muestran las definiciones de bdTrap y bdClearTrap enese 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 }


Ejemplo de un trap consolidado en una alerta y borrado 109

bdClearTrap NOTIFICATION-TYPE OBJECTS { 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 deevento transmite los datos al Back-end de alerta, donde el adaptador de laconfiguración de alerta pasa a través de los filtros en las definiciones de alertasactivadas.

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. Lasiguiente cifra muestra el filtro en esta definición de alerta.

Figura 10 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 11 Definición de alertas de Brocade

Tenga en cuenta lo siguiente acerca de esta definición:

l No hay ninguna operación. Esta definición de alerta lleva a cabo la acción encualquier evento que coincida con el filtro.

l La acción asociada con el bdTrap es otro trap, es decir, un Trap de alerta. El Trapde alerta inserta la información del trap original, que fue normalizada en campos dedatos de ViPR SRM por el procesador de registro, en el mensaje de 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 creadorecientemente en el puerto 2041 y lo reenvía a la cadena de procesamiento de alertas.El Modificador clave agrega un ID único y el marcador de propiedad agrega una


Ejemplo de un trap consolidado en una alerta y borrado 111

categoría, tipo de dispositivo y otros valores. El evento está escrito en la base de datosde eventos, donde está disponible para la creación de informes.

La alerta es DURABLE y permanece ACTIVE 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, gravedad y así sucesivamente, que identifiquen al trap más reciente comouna actualización del anterior. Sin embargo, sería un trap de borrado.

Ya vimos la definición de bdClearTrap en el MIB anteriormente. 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 12 Lista de definición de alertas de Brocade

La siguiente representación muestra el filtrado para la definición de alerta de borradodel cuello de botella.

Figura 13 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 INACTIVE.

Creación de una alerta personalizada para un trap desde un origen externoSiga estos pasos para incorporar un trap enviado al receptor de condición de errordesde un origen externo en los informes de alertas de ViPR SRM.

Procedimiento

1. Configure el origen del trap para enviar el trap al back-end primario de ViPRSRM, puerto 2041.

2. Asegúrese de que la descripción de MIB para el trap esté disponible.

a. Vaya a Administration > Centralized Management > Logical Overview >Events > Trap Receiver: 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 enUpload para agregar un nuevo archivo MIB que contiene la descripción deeste.

3. Agregue reglas para traducir los datos de trap entrantes en datos de eventonormalizados de ViPR SRM.

a. Para obtener información sobre las reglas y cómo crearlas, vaya aAdministration > Centralized Management > Logical Overview > Events >Trap Receiver: Alert Consolidation y haga clic en el enlace situado enDocumentation.

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 dereglas existente (un archivo .xml). Alternativamente, haga clic en Uploadpara agregar un nuevo archivo de reglas.

4. Opcionalmente, asigne el valor category al evento.

El campo de datos category es una etiqueta descriptiva asignada a las alertaspara ayudar a identificar el tipo de alerta. Category es una columna en losinformes de alertas y los usuarios pueden ordenar los elementos en esacolumna. Puede asignar un valor category a la alerta en el archivo deconfiguración que se describe aquí o en el mensaje de Trap de alerta.

Se entrega un conjunto de valores de categoría estándares con ViPR SRM.Puede agregar una nueva categoría.

Para ver o agregar nuevos valores de categoría o para configurar la categoría deun evento 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 trap.

b. Incluya una acción de Captura de alertas.

6. Habilite la nueva definición de alerta.

7. Repita todos los pasos anteriores para un Trap 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 puedenser el origen de alertas.


Crear alertas de eventos que se envían a una escucha 113

El flujo de proceso para eventos externos se envía al puerto de escucha deeventos

Una 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 enel flujo 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.

Figura 14 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-endprimario.

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 alertaactivada con un filtro y condiciones operacionales que coincidan con los datos deeventos.

6. Si la definición de alerta incluye una acción de Trap de alerta, el evento se reenvíaal receptor de condición de error, donde el flujo de procesamiento de alertascomunes asume el control.

Algunos SolutionPacks, como VNX, utilizan este método para agregar alertas en elsistema de emisión de alertas de ViPR SRM. Los SolutionPacks para estos dispositivosinstalan los siguientes archivos de soporte en las ubicaciones correspondientes en lainfraestructura:



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.Las reglas en este archivo son específicas para el dispositivo y el procesador deregistro las utiliza para mapear los datos de eventos en el formato de eventosnormalizados. En algunos casos, se aplican las reglas comunes y no se requierenreglas específicas del dispositivo especiales. El componente de receptor decondición de error tiene archivos 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 unacategoría de 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 cerca de alcanzar su capacidadmá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 2041 en elservidor de back-end de ViPR SRM. El puerto de escucha de eventos genéricosretoma el evento en el puerto 2040 y lo envía al procesador de registro, que normalizalos datos de eventos VNX en el formato de alerta adecuado. En el caso de eventos deVNX, el mapeo es directo y no se necesita ningún archivo adicional de reglas deprocesador de registro. Los datos de eventos, a continuación, se enrutan al Back-endde alerta, donde el adaptador de configuración de alerta los envía a través de los filtrosen las definiciones de alerta.

El evento coincide con la definición de alerta llamada Entrada de espacio libre delgrupo RAID, que se ha instalado por el SolutionPack de VNX. La siguienterepresentación muestra el filtro en esta definición de alerta.

Figura 15 Filtrado 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 115

Figura 16 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 Free Space.

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 gravedades decrecientes desencadena accionesde trap que anulan las acciones anteriores.

l El último trap es un trap de borrado.

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 deTrap de alerta. El valor 1 en el séptimo campo de datos hace que el alerta seaCRITICAL.

El receptor de condición de error de SNMP retoma el evento en el puerto 2041 y sehace cargo el proceso de emisión de alertas comunes. El informe All Alerts muestra elevento como una alerta crítica.

Al hacer clic en la fila en el informe All Alerts se muestran todos los detalles acerca deesta alerta.


Ejemplo de un evento externo consolidado en una alerta y borrado 117

Figura 17 Informe detallado para el evento de 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 parael procesador de registro. Las reglas de este archivo son específicas deldispositivo, y el procesador de registro las utiliza para mapear los datos deeventos en el formato de eventos normalizados. En algunos casos, no serequieren reglas especiales.Para crear y cargar el archivo de reglas:



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 dereglas:

l Para abrir la documentación en la que se describe el formato y uso delarchivo de reglas, desplácese hasta el encabezado Documentation yhaga clic en APG-Event-Log-Processor.pdf.

l Para abrir un archivo de reglas existente y ver ejemplos, expandaConfiguration files, seleccione cualquier archivo cuyo nombre contengarules y haga clic en Edit 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 lasinstrucciones.

3. Opcionalmente, asigne el valor category al evento.

El campo de datos category es una etiqueta descriptiva asignada a las alertaspara ayudar a identificar el tipo de alerta. Category es una columna en losinformes de alertas y los usuarios pueden ordenar los elementos en esacolumna. Puede asignar un valor category a la alerta en el archivo deconfiguración que se describe aquí o en el mensaje de Trap de alerta.

Se entrega un conjunto de valores de categoría estándares con ViPR SRM.Puede agregar una nueva categoría.

Para ver o agregar nuevos valores de categoría o para configurar la categoría deun evento 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 propiedadde eventos ya aplicó el filtro source = VMAX*. El filtro de las definicionesde alerta lo perfecciona aún más.

b. Una acción de Trap de alerta.

c. Una acción de Trap de borrado.

Nota

Solo las alertas DURADERAS necesitan una acción de Trap de borrado.

5. Habilite la definición de alerta.


Creación de una alerta personalizada a partir de un evento externo 119

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, comocapacidad, disponibilidad o latencia. El recopilador de ViPR SRM envía métricas alback-end de emisión de alertas. Si existe una definición de alerta válida, el evento secrea y se transfiere al flujo de alertas.

La siguiente figura muestra cómo se captura y normaliza un evento en el sistema dealertas.

Figura 18 Flujo de proceso de alerta para eventos de umbral de métrica

1. Los recopiladores de ViPR SRM envían métricas al back-end de emisión de alertasen el puerto 2010. Todo el flujo de métricas recopiladas mediante el Back-end dealerta.

2. El Back-end de alerta busca una definición de alerta que incluya al menos elnombre del 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.



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.

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 dealta utilización de CPU mediante el filtrado de la métrica de CPUTimePercentage quese recopila mediante el recopilador APG_HEALTH. Este es el filtro:Figura 19 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 Importantesy Menores. Estos son los comparadores y las acciones. Las acciones de trap asignanlos campos de datos recopilados en el mensaje trap. Ninguna otra regla de conversiónes obligatoria. Los recopiladores envían los datos en el formato correcto.


Ejemplo de métrica recopilada que se consolidó en una alerta 121

Figura 20 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 laparte inferior 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 unaalerta Menor. 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 basadasen métricas recopiladas, debe estar familiarizado con los recopiladores y las métricasque estos 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 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 informecalendarizado.

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 adaptadorde datos 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 programadoEn este ejemplo, se crea una alerta con los datos del informe ViPR SRMServersSummary y una de las definiciones de alerta de ejemplo.

Supongamos que consulta con frecuencia el informe Biblioteca de informes > EMCM&R Health > Servers Summary para monitorear el estado del servidor.Actualmente, supervisa la utilización de CPU y el uso de memoria para detectar signosde servidores sobrecargados. Decide que sería conveniente utilizar alertas a fin derastrear 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óncalendarizada en la pestaña Alert.

3. Vaya a My Reports > Scheduled reports > nombre_del_informe, haga clic con elbotón secundario 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. Lasolicitud de inicio agrega y habilita el adaptador. Para comprobar el estado deladaptador, navegue hacia Administration > Modules > Alerting > LocalManager > Adapter.Cada ejecución de un informe programado para la emisión de alertas genera unaversión XML del informe.

4. Abra la versión XML del informe a fin de obtener valores de cadena del nombredel informe y los nombres de métricas.


Creación de alertas desde los informes calendarizados 123

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 loscaracteres de espacio.

e. En el elemento <table><header>, observe los valores <th>. Estos son losnombres de mé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 caracteresde espacio.

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"/> </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 yluego escribe información en un archivo de registro.

El adaptador APG Report Data analiza el informe XML y genera datos de alertasde este. La definición de alerta filtra los datos generados de las alertas y actúasobre estos.

Una definición de alerta simple para nuestro caso de uso contiene solo un filtrode punto de entrada y una acción de registro. Crea entradas de cada vez que seejecuta el 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 delinforme y que 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


Ejemplo de una alerta de una métrica de informe programado 125

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 deruta y el período de retención de las entradas del archivo de registro, son loselementos de configuración del componente de acción del registro.

6. Inicie el informe calendarizado nuevamente y, a continuación, vaya hasta eldestino de 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 siguientedefinición de alerta:

Administration > Modules > Alerting > Alert definitions > Examples > Alert onAPG Report .En el ejemplo de Alert on APG Report se incluyen los comparadores queprueban valores específicos y escriben entradas de registro únicamente cuandolos valores superan los umbrales.

Análisis de datos de informeEl adaptador de datos del informe APG analiza los datos en los informescalendarizados que recibe.

El adaptador de datos del informe APG genera datos de alertas de los informescalendarizados. Los datos y las propiedades relacionadas dependen del tipo deinforme.

Cada punto de datos en un informe, como un punto en un gráfico o en la fila de unatabla con una columna de valor, tiene como consecuencia una línea de datos quepuede ser evaluada por una definición de alerta.

Propiedades comunesCada línea de salida de datos de alerta por el adaptador de datos del informe APGtiene las siguientes propiedades.



registro de fecha y horavalornombreNombre de informe

Las propiedades mostradas con sus valores desde el encabezado del informe seincluyen con las líneas de datos de alerta desde el informe. Si se trata de un informemixto, las líneas de alertas de los datos de cada informe secundario tienen estaspropiedades comunes, aunque normalmente las propiedades se utilizan solo en losinformes individuales 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 propiedadesadicionales; sus nombres de columna se utilizan como los nombres de propiedad. Elnombre es lo que 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 seconvierte en 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 detiempo que abarca el informe. Se recomienda no utilizar estos tipos de informepara alertas basadas 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íodode informe.

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 valorde la métrica y su nombre, según el contenido de la leyenda, utilizando el valor dela propiedad 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.


Análisis de datos de informe 127

l Se agrega la propiedad del mínimo de base, que es el valor mínimo registrado parala mé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 programadoSiga 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 deseaalertar y haga clic en Tools > Schedule this report.

b. En la pestaña Scheduling, defina con qué frecuencia y cuándo se debeejecutar este 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 deadaptadores, utilice la tabla situada en el panel derecho para asegurarse deque 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 elcaso de 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 demétricas a partir de los datos de métricas de entrada.

c. Para que la alerta aparezca en los informes de alertas, incluya las accionesde alerta de Captura de alertas y Captura de borrado de SNMP en las rutasde resultado. Otras acciones también son válidas, como registro, correoelectrónico o notificaciones 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 generao borra 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 programado 129

CAPÍTULO 12

Creación de definiciones de alertaspersonalizadas

Los siguientes temas describen los requisitos para las definiciones de alertas de ViPRSRM y cómo crearlas.

l Definiciones de alerta en la consola ..................................................................132l Componentes de una definición de alerta..........................................................132l Edición de una definición de alerta.................................................................... 137l Creación de definiciones de alerta.................................................................... 140l Para obtener más información acerca de los componentes y las definiciones de

alertas............................................................................................................... 141l Acerca de Trap de alerta y Traps de borrado de alertas.....................................141l Adición de acciones de Trap de alerta y Trap de borrado de ViPR SRM ........... 142l Plantillas y cuadros agrupados.......................................................................... 143l Creación de carpetas de definición de alerta.....................................................143

Creación de definiciones de alertas personalizadas 131

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, configurary crear 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ónde cada 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 deconsola generar alertas en base a los valores informados o computados en losinformes. Se requiere una definición de alerta que filtre en el informecalendarizado.

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 SNMPtraps desde dispositivos de otros fabricantes.

Componentes de 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 maneja esta definición dealerta. El filtro funciona en los campos (propiedades) en los datos de evento.

Nota

En este punto en el proceso de emisión de alertas, los datos de eventos se normalizanen un formato estándar, pero el evento aún no está en ninguna base de datos. Por lotanto, es posible que el asistente de filtrado no pueda indicarle todos los valoresválidos. Para escribir un filtro, puede ser necesario investigar el origen del evento y susreglas de normalización.

Este es un ejemplo de un filtro de punto de entrada para la definición de alertaBackend Processing Delay en la carpeta EMC M&R Health. El origen de esta alertaes la métrica denominada ProcessingDelay recopilada por el recopilador APG_Health.

Creación de definiciones de alertas personalizadas


Figura 21 Filtrado en una definición de alerta

Un filtro de alerta normalmente incluye una prueba para el origen del evento. Lasiguiente tabla muestra algunos nombres de campo utilizados con frecuencia parafiltrar en los orígenes de eventos en ViPR SRM.

Tipo deevento

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_fieldSource='Cisco%' & ( sourcedomainname=='cieLinkDown' | sourcedomainname=='cieLinkUp')

eventos deinformescalendarizados

source=='report_name' reportName=='apgreport'

OperacionesLas operaciones evalúan los datos entrantes para ver si deben ir al próximocomponente o 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ón siguiente Para obtener más Información

Esta es una operación de ventana de tiempo que calcula un promedio.


Componentes de una definición de alerta 133

Figura 22 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 enViPR SRM es una cadena de comparadores, cada uno con un valor comparadordiferente. Los resultados son una serie de traps SNMP que crean trapsimportantes, principales, menores y finalmente un trap de borrado, todo en lamisma propiedad y en 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 23 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 basede datos 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 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.

Nota

l No agregue la acción de evento de ESRS a ninguna definición de alerta. La acciónde evento de ESRS es solo para uso de EMC.

l La acción Send to SAM es para uso de los clientes que tienen instalada la suite deaplicaciones EMC Service Assurance Suite.

Este es un conjunto de comparadores, cada uno asociado con dos rutas de resultado.El contenido de la alerta Trap en cada acción es muy similar. La diferencia sería lagravedad que está definida en el contenido del trap.


Componentes de una definición de alerta 135

Figura 24 Acciones de una definición de alerta

Ejemplo: Combinación de todos los elementosEsta 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 gravedad y los Traps de borradocorrespondientes.



Figura 25 Ejemplo de definición de alerta

Este es el Porcentaje de alerta de espacio libre del sistema de archivos en lacarpeta EMC M&R Health, en caso de que desee explorar como están configuradostodos los componentes.

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

Editando definiciones de alertas, puede cambiar el filtro o puede agregar acciones uoperaciones a la definición de alerta o eliminarlas.

Nota

No agregue la acción de evento de ESRS a ninguna definición de alerta. La acción deevento de ESRS es solo para uso de EMC.

Procedimiento

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

2. Expanda los nodos hasta que la definición de alerta que desea editar aparezcaen la tabla situada en el panel derecho.

3. En el panel derecho, haga clic con el botón secundario en la definición de alertay seleccione Edit.

Aparecerá una representación gráfica de la definición de alerta en el pizarrón,con una lista expandible de los componentes disponibles a la derecha.


Edición de una definición de alerta 137

4. Para reconfigurar un componente existente:

a. Coloque el cursor sobre el componente hasta que aparezca un menú deíconos pequeños sobre el componente y haga clic en Edit(ícono del lápiz).

Por ejemplo, para refinar el filtro en la entrada filtrada, coloque el cursorsobre el componente de la entrada de filtrado en la definición de alerta.

b. Realice cambios en la configuración de un componente desde el cuadro dediálogo que aparece.

c. Haga clic en OK para guardar los cambios y salir del cuadro de diálogo.

5. Para agregar un componente nuevo:

a. En la lista de componentes que se muestra a la derecha, haga clic en el tipode componente que desea agregar.

El tipo se expande para mostrar todos los componentes disponibles en esacategoría. Por ejemplo, haga clic en Action para mostrar todos loscomponentes de acción.



b. Arrastre de la lista al pizarrón el símbolo del componente deseado.

Por ejemplo, para agregar una acción de notificación por correo electrónico,haga clic en el objeto Mail.

c. Complete el cuadro de diálogo de configuración que aparece al soltar elelemento arrastrado y haga clic en OK.

Para reconfigurar el componente más adelante, coloque el cursor sobre elsímbolo y haga clic en el ícono Edit que aparece.

d. Agregue el nuevo componente al flujo de la definición de alerta arrastrandouna línea entre los puntos de conexión de los símbolos.

l Comience a arrastrar el elemento desde un punto de conexión de salida.

l Arrastre el elemento a un punto de conexión de entrada.

Los puntos de conexión de salida aparecen a la derecha de un símbolo. Lospuntos de conexión de entrada aparecen a la izquierda.

En el siguiente ejemplo, se conecta el punto de salida "Condition not met" deun comparador con la acción Mail. (La definición de alerta envía un correoelectrónico cuando no se cumple la condición).


Edición de una definición de alerta 139

6. Haga clic en Save desde la parte inferior del pizarrón para guardar todos loscambios realizados en la definición de alerta.

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.

Se abre un espacio en blanco con los componentes enumerados a la derecha.

3. Arrastre un componente Entry Point al espacio en blanco y configúrelo.

Al soltar el método de arrastre, se abre un cuadro de diálogo para configurar elcomponente.

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 a una base de datos, por lo que la lista de propiedades y valoresconocidos se crea en el tiempo de ejecución. Por este motivo, es normal notener sugerencias al usar de inmediato el asistente después de iniciar el AlertingBackend.

4. En la lista de componentes que se muestra a la derecha, expanda el tipo decomponente con el que desee trabajar a continuación.

5. Arrastre un componente al espacio en blanco y configúrelo.

Para reordenar los componentes más adelante, arrástrelos.

6. Siga arrastrando componentes y configurándolos, y termine con un componenteAction.

7. Conecte los componentes para definir el flujo de procesamiento para unaentrada, que es capturada por el filtro de punto de entrada.

Cada componente tiene conectores, que son cuadrados amarillos. Para vincularlos componentes, haga clic en un conector de salida en el lado derecho de uncomponente y arrástrelo hacia un conector de entrada a la izquierda de otrocomponente. Cuando el conector de entrada se vuelve verde, suelte el métodode arrastrar.

Nota

Para eliminar una conexión, arrastre la línea lejos del punto de conector deentrada y suéltela. Desaparecerá la línea de conexión.

No existe un límite en la cantidad de objetos que se pueden enlazar a la mismasalida.

8. Cuando haya terminado de agregar componentes, haga clic en Save.

9. En Name, escriba un nombre para la definición de alerta.

10. En Description, escriba una descripción para la definición de alerta.



11. Haga clic en Save and enable o Save and disable.

Para obtener más información acerca de los componentes ylas definiciones de alertas

Más recursos están disponibles para el aprendizaje sobre las definiciones de alerta.

Técnicas para la creación de definiciones de alertasPuede 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 enel panel derecho 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 alertas en lascarpetas de SolutionPack.

Referencia de componentesPara 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, incluyendotodas las operaciones y todas las condiciones y cómo usarlos.

Acerca de Trap de alerta y Traps de borrado de alertasEl Trap de alerta es el mecanismo para agregar un evento en la base de datos deeventos de ViPR SRM. El Trap de borrado de alertas borra un trap de alerta emitidoanteriormente.

Cuando decimos "trap de alerta" en ViPR SRM, nos referimos al trap que se envía alreceptor de condición de error con un mensaje en un formato predefinido que setransforma y se escribe en la base de datos de eventos.

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

Para agregar las acciones de Trap de alerta y Trap de borrado a nuevas definiciones dealertas, copie las configuraciones de las definiciones de alerta existentes. Asegúresede conservar las siguientes características:

l Utilice el host local como la dirección IP y el puerto 2041, que es el puerto dereceptor de condición de error de SNMP trap predeterminado para que ViPR SRMenvíe el trap al receptor de condición de error.

l Copie el contenido del trap de una definición de alerta existente y modifíquelasegún corresponda para asegurarse de que contenga los campos obligatorios y elformato para la entrada de base de datos de generic_events que se creará.

Consulte Formato normalizado de Trap de alerta y Trap de borrado en la página 148para obtener información sobre el orden de campos, descripciones y ejemplos.


Para obtener más información acerca de los componentes y las definiciones de alertas 141

Adición de acciones de Trap de alerta y Trap de borrado deViPR SRM

Para escribir una alerta en la base de datos de eventos de ViPR SRM, use una acciónde Trap de alerta 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 debenagregar las acciones de Captura de alertas y Captura de borrado a los resultados.

Procedimiento

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

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

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

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ónpara la acción.

4. Para configurar la acción, copie los detalles de una definición de alertapredeterminada y, a continuación, cámbiela según sea necesario.

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

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

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

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

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

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

d. En Port, Community, Generic ID y Enterprise specific ID, copie estosdetalles de una de las definiciones de alerta existentes.

e. En Entry:

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

l Separe cada campo utilizando una coma. No use una coma dentro de unvalor de campo.



l Para omitir un campo, utilice el valor null como marcador de posiciónpara ese valor de campo.

l Los primeros 11 campos son obligatorios para crear informes precisos.Estos campos se utilizan en los informes de alertas; por ello, esimportante que todas las entradas contengan valores para estos campos.Los campos subsiguientes son opcionales.

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

l El formato de una variable es PROP.'nombredepropiedad', dondenombredepropiedad es un campo en los datos de eventos de ViPR SRM.

5. Haga clic en Ok.

6. 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 unsí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.

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

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

Plantillas y cuadros agrupadosViPR SRM incluye funciones que pueden ahorrar tiempo y proporcionar coherenciacuando se trabaja con las definiciones de alerta.

Plantillas

Una plantilla ahorra tiempo, ya que completa los campos de configuración de uncomponente de acción. ViPR SRM viene con algunas plantillas predefinidas, yusted puede crear una plantilla propia.

Cuadros agrupados

Esta función le permite dividir un conjunto de componentes para su uso endiversas definiciones de alerta. Por ejemplo, puede crear un objeto que representeun conjunto de operaciones y condiciones. Puede crear el conjunto de una vezcomo un cuadro agrupado y luego arrastrar el cuadro agrupado a diversasdefiniciones de alerta.

Para obtener más información acerca de las plantillas y los cuadros agrupados, hagaclic en 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.


Plantillas y cuadros agrupados 143

Procedimiento

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

2. En el panel izquierdo, arriba del árbol de navegación, haga clic en el íconoCreate a new 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 folderen la parte 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 lacarpeta representa.

9. Haga clic en Save and disable.

La carpeta nueva y la definición de alerta de marcador de posición aparecen enel á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 eliminarla definición de marcador de posición. Una carpeta sin definiciones de alertadesaparecerá.



CAPÍTULO 13

Alertas de la base de datos y caché activo

Los siguientes temas describen la base de datos de eventos. Consulte Propiedades dealerta en una entrada de la base de datos en la página 154 para conocer el formato deuna alerta en la base de datos.

l Base de datos de eventos................................................................................. 146l Caché activo.....................................................................................................146

Alertas de la base de datos y caché activo 145










Caché activoEl caché activo es una copia exacta de la tabla genericevents_live que se conserva enla memoria.

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.

Alertas de la base de datos y caché activo


CAPÍTULO 14

Formatos y MIB

Este capítulo muestra el formato de una alerta normalizada, el formato de una alertaen la base de datos de eventos y la MIB que refleja el formato de las notificaciones detrap a un receptor de condición de error de otros fabricantes.

l Formato normalizado de Trap de alerta y Trap de borrado ............................... 148l OID de formato de mensaje de trap y datos de eventos normalizados ..............153l Propiedades de alerta en una entrada de la base de datos ............................... 154l SRM-ALERTS-MIB...........................................................................................159

Formatos y MIB 147

Formato normalizado de Trap de alerta y Trap de borradoLos datos de eventos se normalizan en un formato común que se convierte en elmensaje del Trap de alerta. Las entradas del Trap de alerta y del Trap de borrado deViPR SRM deben contener datos en el orden esperado y deben utilizar el valor NULLpara 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 deSNMP Trap.

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.Consulte las notas en la siguiente tabla. En general, utilizar la variable siempre quesea posible es una mejor práctica.

l El formato de una variable es PROP.'nombredepropiedad', dondenombredepropiedad es un campo en los datos de eventos de ViPR SRM.

Explicaciones y orden de campos para el Trap de alerta de ViPR SRMLa siguiente tabla describe los datos en el campo de entrada del Trap de alerta de ViPRSRM. Los pedidos son importantes. Para omitir un elemento de datos, utilice el valorliteral null.

Tabla 7 Datos en un mensaje de Trap de alerta

Nombre delcampo

Descripción Valor

0 device Requerido. El dispositivo enel que ocurrió el evento.Una combinación de loscampos device (0), parttype(3), part (2) y eventname(19) identifica de formaúnica una alerta.

PROP.'device'Aunque se puede proporcionar un valorliteral, utilizar la variable PROP es unamejor práctica para pasar el valor desdeel evento de origen.

1 devtype Requerido. El tipo deservicio.

PROP.'devtype'Aunque se puede proporcionar un valorliteral, utilizar la variable PROP es unamejor práctica para pasar el valor desdeel evento de origen.

2 part Puede ser nulo.Una combinación de loscampos device (0), parttype(3), part (2) y eventname

PROP.'part' o asignar un valor, o nulo.

Formatos y MIB


Tabla 7 Datos en un mensaje de Trap de alerta (continuación)

Nombre delcampo

Descripción Valor

(19) identifica de formaúnica una alerta.

3 parttype Puede ser nulo.Una combinación de loscampos device (0),parttype(3), part (2) yeventname (19) identifica deforma única una alerta.

PROP.'parttype' o asignar un valor, onulo.

4 sourceeventtype

Asigna el evento comoDURADERO oMOMENTÁNEO. Si está sinasignar, de manerapredeterminada seclasificará comoMOMENTARY.Los eventosMOMENTÁNEOS se puedenborrar mediante la accióndel usuario, mientras que loseventos DURADEROS estándestinados a ser borradossolo cuando se procesa otroevento que borra el eventooriginal.

Las alertasMOMENTÁNEAS se borranautomáticamente despuésde 7 días si no se realizaninguna acción del usuario.

Uno de los siguientes literales:

DURABLEMOMENTARY

5 value Un campo versátil quepuede contener cualquiervalor. Por lo general, este esun valor de métrica o estadoque se transmite desde elevento de origen. Si lasreglas de traducciónproporcionadas alprocesador de registrosiguen las mejores prácticas,los detalles adicionalessobre el valor aparecen en eltexto del evento o en elcampo fullmsg.

Para transmitir en un valor desde elevento de origen, utilice el valor literalsiguiente:VALUE

6 severity Por lo general, se normalizala gravedad a nivel delevento. La mejor práctica es

PROP.'severity' o asignar un valor aquí.

Puede usar la cantidad o el valor SNMPENUM que se muestra en la tabla

Formatos y MIB

Formato normalizado de Trap de alerta y Trap de borrado 149


Nombre delcampo

Descripción Valor

pasar a ese valor utilizandoPROP.'severity'Si queda sin asignarmediante la normalización yaquí, la gravedad pasa a suvalor predeterminado, quees 4 (nulo) y aparece en losinformes como UNKNOWN.

siguiente. Estos valores se traducencomo se muestra en los informes.

Num SNMPENUM

translates to

1 critical CRITICAL

2 error MAJOR

3 warning MINOR

4 null UNKNOWN


7 fullmsg Opcional. El mensaje fácil deusar asociado con esteevento.

El mensaje puede incluir:

l Puntuación, excepto comas.

l El literal VALUE.

l Variables en el formulario dePROP.'nombredecampo'

8 Source El origen de datos para laalerta, como un nombrerecopilador, un puerto deescucha de eventos, unnombre MIB o un nombre deinforme.

PROP.'source'

9 OpenedAt El registro de fecha y horacuando ocurrió la alerta porprimera vez.

El valor literal TMST es el único valor

válido.La marca de registro de fecha y hora seasigna cuando se produce la alerta porprimera vez, y este campo (openedat)sigue siendo coherente para la duraciónde la alerta, incluso si se actualiza laalerta.

10 category Una clasificación del evento. PROP.'category' o asignar un valor.

11 sourceip La dirección IP del origen dela alerta.

PROP.'sourceip'

12 sourcedomainname

El nombre de dominio delorigen de la alerta.

PROP.'sourcedomainname'

13 userdefined1 Campos definidos por elusuario.

PROP.'userdefinedn' si el archivo

de configuración de reglas deprocesador de registro para este tipo deevento asigna valores a estos campos.De lo contrario, proporcione los valoresdefinidos por el usuario aquí.

14 userdefined2

15 userdefined3

16 userdefined4

Formatos y MIB



Nombre delcampo

Descripción Valor

17 Ejemplos:

Contact: adminDept: IT

userdefined5

18 userdefined6

19 eventname Pretende describir laactividad del componenteque es el origen del evento.Para las alertaspredeterminadasproporcionadas porSolutionPacks, una mejorpráctica es una sola palabrapara el evento, comoinactivo, desconectado,afectado.Una combinación de loscampos device (0),parttype(3), part (2) yeventname (19) identifica deforma única una alerta.

PROP.'eventname' o asignar un valor

20 eventstate Requerido. Asigna si se tratade una Trap de alerta(ACTIVO) o una Trap deborrado (INACTIVO).

Para mensajes de Trap de alerta, utiliceel valor literal ACTIVE.

Para mensajes de Trap de borrado,utilice el valor literal INACTIVE.

21 eventdisplayname

Igual que eventname, peroen un formato legible.

Por ejemplo, si eventname esHighUtilization, a continuación,

eventdisplayname podría ser HighUtilization, con un espacio adicional

para mejorar la legibilidad.

22 systemdefined1

Contiene el nombre de lamétrica o el código deevento desde el origen delevento.

23 systemdefined2

Reservado para uso futuro.

Requisitos para un Trap de borradoUn Trap de borrado utiliza el mismo formato de mensaje que el Trap de alerta. Estasson reglas adicionales para un Trap de borrado:

l Debe contener valores que coincidan con el Trap de alerta en los siguientescampos. De manera opcional, se pueden incluir otros campos.

Formatos y MIB

Formato normalizado de Trap de alerta y Trap de borrado 151

Tabla 8 Datos en los mensajes de Trap de borrado

Nombredel campo

Valor obligatorio para el Trap de borrado

0 dispositivo Igual que los valores utilizados para el Trap de alerta asociada. Un mejorpráctica sería utilizar las variables de la siguiente manera:PROP.'device',PROP.'devtype',PROP.'part',PROP.'parttype'

1 devtype

2 part

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 DURABLE con una gravedadMAJOR.

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).

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 Trapde borrado 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 8 en lapágina 152) son los mismos valores que se utilizan en la entrada de Trap de alerta.

Formatos y MIB


Ejemplo 2 Ejemplos (continuación)

l El valor NULL se utiliza para todos los campos omitidos.

l El valor para eventstate es INACTIVE.

OID de formato de mensaje de trap y datos de eventosnormalizados

El proceso de normalización transforma los datos de eventos en un formato aceptablepara la creación de una alerta de ViPR SRM. Los datos de eventos normalizados y elmensaje de SNMP trap enviados desde el back-end de alertas al receptor de condiciónde error utilizan el mismo formato.

A modo de referencia, este es el formato de datos de eventos normalizados para crearalertas de ViPR SRM. Para cada propiedad en el trap, hay un OID específico como semuestra 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" /> <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"/>

Formatos y MIB

OID de formato de mensaje de trap y datos de eventos normalizados 153

<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"/> 

Propiedades de alerta en una entrada de la base de datosLa siguiente tabla describe las propiedades en una entrada de alerta en la base dedatos de eventos

Ambas tablas en la base de datos de eventos utilizan la misma definición de tabla. Lasdescripciones de campos que aparecen a continuación se aplican a ambas tablas debase de 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 nuncadebe estar en blanco. Estos campos forman una clave única para la fila del evento.

Tabla 9 Campos en una entrada de la base de datos de eventos

Campo Tipo Null

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, se debeestablecer una coincidencia con este índice.La mejor práctica utilizada por la mayoría de lasimplementaciones de alerta de SolutionPack esgenerar el 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.

Formatos y MIB

Tabla 9 Campos en una entrada de la base de datos de eventos (continuación)

Campo Tipo Null

Clave Descripción

parttype varchar(256) SÍ MUL El tipo de la parte en el que ocurrió la alerta.En la interfaz del usuario, este es el campoComponent Type.

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 del usuario, este es el campoComponent.

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 del usuario, este es el campoComponent Type.

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 del usuario, este es el campoComponent.

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ásinformación acerca de 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.

Formatos y MIB

Propiedades de alerta en una entrada de la base de datos 155


Campo Tipo Null

Clave Descripción

valor varchar(64) SÍ El valor de la métrica o el atributo que haprovocado la alerta.

active tinyint(1) SÍ MUL Un valor TRUE (1) indica que esta alerta estáactualmente activa en el sistema. Este es uncampo mantenido por el sistema.

timestamp int(11) SÍ El registro de fecha y hora de la entrada másreciente de una alerta. Este es un campomantenido por el sistema.

closedat int(11) SÍ MUL La fecha y hora cuando se cerró la alerta (sevolvió inactiva).

duration int(11) SÍ MUL La duración entre que la alerta estuvo ACTIVAhasta que estuvo INACTIVA. Este es un campomantenido por 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 es mantenido por el sistema en enrespuesta a las acciones del usuario en la consola.

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 dejasin asignar, se establece de manerapredeterminada como 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 gravedad 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 translates to

1 critical CRITICAL

2 error MAJOR

3 warning MINOR

Formatos y MIB



Campo Tipo Null

Clave Descripción

Num SNMP ENUM translates to

4 null UNKNOWN


impact bigint(20) SÍ Impacto de la alerta. No se está usandoactualmente en ViPR SRM.

certainty float SÍ El grado de certeza de la alerta. No se estáusando actualmente en ViPR SRM.

inmaintenance

tinyint(1) SÍ Un valor SÍ (1) indica que el dispositivo en el quese produce esta alerta actualmente está enmantenimiento. No se está usando actualmente enViPR SRM.

troubleticketid

varchar(64) SÍ No se está usando actualmente en ViPR SRM.Puede utilizarse con fines de integración con unsistema de administración de vales de otrosfabricantes como el ID de la alerta en un sistemaexterno.

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 parael uso futuro de la Plataforma M&R ySolutionPack.

systemdefined2


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 accionesde registro, correo electrónico o Trap de alerta.

Formatos y MIB

Propiedades de alerta en una entrada de la base de datos 157


Campo Tipo Null

Clave Descripción

userdefined2

varchar(512) SÍ Campos personalizados que se pueden utilizarpara los propósitos específicos del cliente.Se puede utilizar en cualquier momento en unTrap de 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 utilizarpara los propósitos específicos del cliente.Se puede utilizar en un trap de alerta, peronecesita configuració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Í

userdefined16

varchar(512) SÍ

userdefined17

varchar(512) SÍ

userdefined18

varchar(512) SÍ

userdefined19

varchar(512) SÍ

userdefined20

varchar(512) SÍ

enterprise varchar(512) SÍ

Formatos y MIB



Campo Tipo Null

Clave Descripción

generic varchar(512) SÍ

SRM-ALERTS-MIBEl SRM-ALERTS-MIB describe el formato de una notificación de alerta reenviada porla definición de alerta Alert Consolidation Trap Notification a un receptor de condiciónde error de otros fabricantes. Puede proporcionar este MIB a los otros fabricantes.

-------------------------------------------------------------------------------- Copyright (c) 2016, EMC Corporation. All rights reserved---- This software contains the intellectual property of EMC Corporation-- or is licensed to EMC Corporation from third parties. -- This software is protected, without limitation, by copyright law and-- international treaties.-- Use of this software and the intellectual property contained therein-- is expressly limited to the terms and conditions of the License-- Agreement under which it is provided by or on behalf of EMC. ----The information in this software is subject to change without notice--and should not be construed as a commitment by EMC Corporation.----EMC Corporation assumes no responsibility for the use or reliability--of this software.---------------------------------------------------------------------------------- SRM-ALERTS-MIB 1.00-- History:-- 1.00 27/05/2016 Creation.---- This MIB should be used by external trap receivers for receiving SRM Alerts as traps.------------------------------------------------------------------------------

SRM-ALERTS-MIBDEFINITIONS ::= BEGINIMPORTS OBJECT-TYPE FROM RFC-1212 enterprises FROM RFC1155-SMI TRAP-TYPE FROM RFC-1215;

-- Type Definitions

watch4net OBJECT IDENTIFIER ::= { enterprises 11970 }alerting OBJECT IDENTIFIER ::= { watch4net 1 }

Formatos y MIB

SRM-ALERTS-MIB 159

alertEvent OBJECT IDENTIFIER ::= { alerting 1 }alertEventTrap OBJECT IDENTIFIER ::= { alertEvent 2 }

-- Objects definitions

id OBJECT-TYPE SYNTAX OCTET STRING ACCESS read-only STATUS mandatory DESCRIPTION "The ID of the alert." ::= { alertEventTrap 1 }

name OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..255)) ACCESS read-only STATUS mandatory DESCRIPTION "The unique name of an alert. The Alert correlation unique index. Generated like {device}_{parttype}_{part}_{eventname}." ::= { alertEventTrap 2 }

openedat OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..64)) ACCESS read-only STATUS mandatory DESCRIPTION "The date and time when the alert first occurs." ::= { alertEventTrap 3 }

count OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..64)) ACCESS read-only STATUS mandatory DESCRIPTION "Number of times an alert has occurred." ::= { alertEventTrap 4 }

eventstate OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..64)) ACCESS read-only STATUS mandatory DESCRIPTION "The mandatory state of the alert, (ACTIVE or INACTIVE)." ::= { alertEventTrap 5 }

source OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..64)) ACCESS read-only STATUS mandatory DESCRIPTION "The source of the alert." ::= { alertEventTrap 6 }

parttype OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..64)) ACCESS read-only STATUS mandatory DESCRIPTION "The part type that the alert occurred on." ::= { alertEventTrap 7 }

part OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..64)) ACCESS read-only STATUS mandatory

Formatos y MIB


DESCRIPTION "The part that the alert occurred on." ::= { alertEventTrap 8 }

eventname OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..64)) ACCESS read-only STATUS mandatory DESCRIPTION "The name of the alert." ::= { alertEventTrap 9 }

parttypedisplayname OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..64)) ACCESS read-only STATUS mandatory DESCRIPTION "The display-ready part type that the alert occurred on." ::= { alertEventTrap 10 }

partdisplayname OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..64)) ACCESS read-only STATUS mandatory DESCRIPTION "The display-ready part that the alert occurred on." ::= { alertEventTrap 11 }

eventdisplayname OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..64)) ACCESS read-only STATUS mandatory DESCRIPTION "The display-ready name of the alert." ::= { alertEventTrap 12 }

fullmsg OBJECT-TYPE SYNTAX OCTET STRING ACCESS read-only STATUS mandatory DESCRIPTION "A message used to describe more information about the alert." ::= { alertEventTrap 13 }

devtype OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..64)) ACCESS read-only STATUS mandatory DESCRIPTION "The device type that the alert occurred on." ::= { alertEventTrap 14 }

device OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..64)) ACCESS read-only STATUS mandatory DESCRIPTION "The device that the alert occurred on." ::= { alertEventTrap 15 }

sourceip OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..64)) ACCESS read-only STATUS mandatory DESCRIPTION

Formatos y MIB

SRM-ALERTS-MIB 161

"The IP of the source of the alert." ::= { alertEventTrap 16 }

sourcedomainname OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..64)) ACCESS read-only STATUS mandatory DESCRIPTION "The domain name of the source of the alert." ::= { alertEventTrap 17 }

sourceeventtype OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..64)) ACCESS read-only STATUS mandatory DESCRIPTION "The event type from the source of the alert." ::= { alertEventTrap 18 }

value OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..64)) ACCESS read-only STATUS mandatory DESCRIPTION "The value of the metric or attribute that caused the alert." ::= { alertEventTrap 19 }

active OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..64)) ACCESS read-only STATUS mandatory DESCRIPTION "A (1) value indicates this alert is currently active on the system." ::= { alertEventTrap 20 }

timestamp OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..64)) ACCESS read-only STATUS mandatory DESCRIPTION "The timestamp of the lastest entry of an alert." ::= { alertEventTrap 21 }

closedat OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..64)) ACCESS read-only STATUS mandatory DESCRIPTION "The date-time when the alert was closed." ::= { alertEventTrap 22 }

duration OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..64)) ACCESS read-only STATUS mandatory DESCRIPTION "The duration between when the alert was ACTIVE to INACTIVE." ::= { alertEventTrap 23 }

lastchangedat OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..64)) ACCESS read-only

Formatos y MIB


STATUS mandatory DESCRIPTION "The date and time when an alert was last updated." ::= { alertEventTrap 24 }

isroot OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..64)) ACCESS read-only STATUS mandatory DESCRIPTION "A (1) value indicates this alert is has no known deeper underlying cause." ::= { alertEventTrap 25 }

isproblem OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..64)) ACCESS read-only STATUS mandatory DESCRIPTION "A (1) value indicates this alert was discovered via Codebook Correlation." ::= { alertEventTrap 26 }

acknowledged OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..64)) ACCESS read-only STATUS mandatory DESCRIPTION "A (1) value indicates that the alert has been acknowledged by a user." ::= { alertEventTrap 27 }

eventtype OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..64)) ACCESS read-only STATUS mandatory DESCRIPTION "The type of event, (MOMENTARY, DURABLE)." ::= { alertEventTrap 28 }

category OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..64)) ACCESS read-only STATUS mandatory DESCRIPTION "The category of the alert." ::= { alertEventTrap 29 }

eventtext OBJECT-TYPE SYNTAX OCTET STRING ACCESS read-only STATUS mandatory DESCRIPTION "A description of the alert" ::= { alertEventTrap 30 }

severity OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..64)) ACCESS read-only STATUS mandatory DESCRIPTION "The severity of the alert - CRITICAL(1), MAJOR(2), MINOR(3), UNKNOWN(4), INFORMATIONAL(5)." ::= { alertEventTrap 31 }

impact OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..64))

Formatos y MIB

SRM-ALERTS-MIB 163

ACCESS read-only STATUS mandatory DESCRIPTION "The impact of the alert." ::= { alertEventTrap 32}

certainty OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..64)) ACCESS read-only STATUS mandatory DESCRIPTION "The certainty of the alert." ::= { alertEventTrap 33 }

inmaintenance OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..64)) ACCESS read-only STATUS mandatory DESCRIPTION "A (1) value indicates the device this alert occurs on is currently undergoing maintenance" ::= { alertEventTrap 34 }

troubleticketid OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..64)) ACCESS read-only STATUS mandatory DESCRIPTION "The ID of this alerting in an external ticket management system." ::= { alertEventTrap 35 }

owner OBJECT-TYPE SYNTAX OCTET STRING (SIZE(0..64)) ACCESS read-only STATUS mandatory DESCRIPTION "The current owner of the alert." ::= { alertEventTrap 36 }

systemdefined1 OBJECT-TYPE SYNTAX OCTET STRING ACCESS read-only STATUS mandatory DESCRIPTION "A custom field that is reserved for M&R Platform and SolutionPack use." ::= { alertEventTrap 37 }



systemdefined4 OBJECT-TYPE

Formatos y MIB


SYNTAX OCTET STRING ACCESS read-only STATUS mandatory DESCRIPTION "A custom field that is reserved for M&R Platform and SolutionPack use." ::= { alertEventTrap 40 }


userdefined1 OBJECT-TYPE SYNTAX OCTET STRING ACCESS read-only STATUS mandatory DESCRIPTION "A custom field that can be modified by the system administrator." ::= { alertEventTrap 42 }





userdefined6 OBJECT-TYPE SYNTAX OCTET STRING ACCESS read-only STATUS mandatory DESCRIPTION "A custom field that can be modified by the

Formatos y MIB

SRM-ALERTS-MIB 165

system administrator." ::= { alertEventTrap 47 }








userdefined14 OBJECT-TYPE SYNTAX OCTET STRING

Formatos y MIB


ACCESS read-only STATUS mandatory DESCRIPTION "A custom field that can be modified by the system administrator." ::= { alertEventTrap 55 }







-- Trap Definitions ------------------------------------------------------------alertEventTrapMessage TRAP-TYPE ENTERPRISE alertEventTrap VARIABLES { id, name,

Formatos y MIB

SRM-ALERTS-MIB 167

openedat, count, eventstate, source, parttype, part, eventname, parttypedisplayname, partdisplayname, eventdisplayname, fullmsg, devtype, device, sourceip, sourcedomainname, sourceeventtype, value, active, timestamp, closedat, duration, lastchangedat, isroot, isproblem, acknowledged, eventtype, category, eventtext, severity, impact, certainty, inmaintenance, troubleticketid, owner, systemdefined1, systemdefined2, systemdefined3, systemdefined4, systemdefined5, userdefined1, userdefined2, userdefined3, userdefined4, userdefined5, userdefined6, userdefined7, userdefined8, userdefined9, userdefined10, userdefined11, userdefined12, userdefined13, userdefined14, userdefined15, userdefined16, userdefined17, userdefined18, userdefined19, userdefined20 } DESCRIPTION "Trap for alerts." ::= 1

END

Formatos y MIB


CAPÍTULO 15

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 ........................................................170l Script para generar alertas aleatorias................................................................170l Receptor de condición de error como módulo independiente.............................171l Filtro de informe para alertas activas en comparación a alertas inactivas..........174

Temas de desarrollo adicionales 169

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 loscampos mediante los OID.

3. Revise el archivo de registro de consolidación de alertas para ver el contenidode la alerta.

4. Utilice una consulta de base de datos para buscar la entrada en la base de datosde eventos.

Script para generar alertas aleatoriasEl siguiente script proporciona una manera de generar rápidamente las alertas confines de 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 pararecibir y enviar Traps de SNMP.

El receptor de Trap es capaz de recibir traps mediante cualquiera de los protocolosSNMP (hasta v3 incluido). Es capaz de reenviar traps en el mismo formato que serecibieron o transformarlos en eventos para manejarlos por el gerente deprocesamiento de eventos. Por lo tanto, este componente se utiliza para recibir yprocesar los traps, o simplemente para 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 enlos archivos 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ónpersonalizada de este elemento de procesamiento y debe estar ubicado en elsiguiente directorio:

<APG_BASE>/Event-Processing/Trap-Receiver/<INSTANCE>/conf/


Receptor de condición de error como módulo independiente 171

4. Para que se ejecute correctamente, es posible que este elemento deprocesamiento deba ejecutarse como usuario raíz.

a. Edite el archivo unix-service.properties de la instancia Event-Processing-Manager que controla el receptor de condición de error.

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,el receptor predeterminado es 0.0.0.0:162 y el reenviador predeterminado es laprimera interfaz disponible. Se admiten direcciones IPv6, utilizando el formato[IPv6 address]: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 especificartodos los 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 delmotor del agente. Por ejemplo, si su agente está usando "0x70707071727374"como motor, entonces el ID del motor debe ser "pppqrst".

<outgoing-v3-params>

Establece los parámetros de v3 para los traps v3 reenviados. Está configurado dela misma 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.


Configuración de receptor de condición de error 173

<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.

<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 llevara cabo 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.Utilice este elemento para convertir OID si no se encuentran en ninguno delos archivos 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 aalertas inactivas

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.


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

guía de alertas - dell emc · emisión de alertas de vipr srm proporciona una vista consolidada y...

Documents