Trabajando con Alertas en SCOM desde el punto de vista del operador

 

Es muy común que después de desplegar SCOM, especialmente si nunca antes se ha trabajado con un sistema de monitorización experto, los operadores tengan algún problema en su día a día gestionando las alertas, usualmente estos problemas vienen dados principalmente por no establecer previamente un criterio consensuado por todo el equipo encargado de la monitorización con respecto a como gestionar las alertas.

¿De donde vienen las alertas?

Lo primero y mas importante que tenemos que entender es que SCOM no es sistema orientado a las alertas si no a la monitorización de estados de salud, las alertas son un medio, no el fin.

Si dentro de la consola pulsáis sobre cualquier elemento en rojo, veréis un menú que se llama explorador de salud.

image

Dentro del explorador veis como esta la salud de todos los elementos monitorizados organizados jerárquicamente a partir del objeto que seleccionasteis.

image

Cada uno de los elementos que veis en el explorador recoge su estado de lo que denominamos un “monitor” o bien representa el estado de varios monitores agregados.

Si pulsáis sobre uno de ellos podréis acceder a las propiedades del monitor.

image

Dentro de las propiedades del monitor tenéis la configuración de la alerta, no todos los monitores tienen por que emitir alertas:

image

Así que tenemos que entender que toda alerta viene de un monitor que ha cambiado de estado.

Nota: En realidad las alertas pueden también venir de conectores con otros sistemas de monitorización o de procesos de orquestación, pero eso es otra historia.

Si damos por resuelta/cerrada una alerta que no hemos resuelto, tener de seguro que si el problema sigue pasando el monitor seguirá en rojo y no tendremos de nuevo una alerta hasta que el monitor se reevalué.

Algunos monitores como es el caso del que os estoy enseñando son capaces de resolver ellos solos las alertas, pero no deis esto por supuesto.

Por tanto, la regla mas importante del trabajo con alertas en SCOM es que  NUNCA deis por resuelta una alerta por quitárosla de encima sin haber resuelto el problema y sin revisar los monitores, haciéndolo escondes el problema durante un lapso de tiempo para tener que volver a el mas tarde lo que es frustrante, además haces que la consola de alertas no represente fielmente el estado de los monitores lo que es desconcertante.

¿Como puedo organizar las alertas?

En SCOM existen por defecto dos estados para las alertas, lo cual es claramente insuficiente:

image

Os recomiendo que como mínimo creéis dos mas, aunque podéis establecer los que queráis según vuestro criterio.

image

Como decía, yo suelo crear los estados “En resolución” y “conocido”, notar que el numero o ID es cualquiera libre de los 255 que podéis escoger y que no tiene importancia cual seleccionéis.

En las propiedades de cada alerta hay dos campos que son muy importantes para organizarnos:

image

El campo dueño nos permite indicar quien tiene que trabajar sobre la alerta o quien esta trabajando sobre ella, el campo estado nos facilita un medio de comunicar al equipo si el tema ya esta controlado.

De esta forma nos podemos crear un pequeño esquema de como podemos trabajar en equipo con las alertas de SCOM:

SCOM_Alertas

 

Os recomiendo que personalicéis las columnas de la vista general de alertas a través del menú de la misma de forma que se muestre el dueño de las alertas:

image

image

Ahora de un solo vistazo cualquier compañero que mire las alertas sabe que yo me estoy encargando de esta y que ya estoy en ello.

¿Como puedo crearme una vista con mis alertas?

El mejor sitio es “My Workspace” espacio que ves tanto en la consola de siempre como en la consola web.

image

Crea una vista de alertas

Configura las propiedades de la vista como ves en la siguiente imagen pero con tus parámetros.

image

image

¿Que hago entonces con las alertas con las que no estoy de acuerdo o que no se ajustan a nuestros criterios?

Una cosa buena de SCOM es que cada vez que cargamos un management pack introducimos en el sistema un montón de conocimiento, varemos y reglas ya parametrizadas.

Esto nos quita mucho trabajo y hace el sistema muy potente, sin embargo a veces un management pack puede decir por ejemplo que se nos avise cada vez que una unidad de disco tiene menos del 10% de espacio libre y puede que siguiendo con el ejemplo tengamos algunos servidores donde sabemos que esta condición se da y que no queremos que se nos avise pues conocemos el problema y no lo vamos a solucionar porque para este servidor no es un problema.

En estas situaciones emprender una guerra con SCOM por dar por resuelta la incidencia del espacio en disco es una perdida de tiempo y dejar la alerta no nos ayudara tampoco, cada X tiempo SCOM limpiara solo las alertas antiguas y la alerta volverá otra vez a salir.

La solución es realmente muy simple, solo tenemos que indicarle a SCOM lo que consideramos un problema y lo que no.

La siguiente vez que salga la alerta nos iremos a su monitor de la forma que os he enseñado antes, siguiendo con el ejemplo aquí tenéis el monitor de espacio libre en disco.

image

Nos vamos a la tab de “Overrides”

image

Ahora viene algo muy importante, cada vez que hagáis un override tenéis que pensar muy bien en hacerlo para el menor ámbito posible.

En nuestro caso solo queremos modificar cuando se nos avisa del espacio en disco libre de un disco en concreto de un servidor en concreto, así que seleccionamos la opción que nos permite crear el override limitándolo a ese ámbito que será “For a specific object of class: Windows Server 2008 Logical Disk”

Ahora nos saldrán todos los discos duros monitorizados por SCOM, seleccionar el que nos preocupe.

image

Ahora nos aparecen todos los parámetros del monitor que podemos modificar para este objeto concreto.

Como nosotros no queremos que se nos avise al 10% si no al 5% lo modificamos:

image

Fijaos que abajo del todo en la pantalla nos dice que el override se guardara en el default management pack, mi consejo es que nunca los guardéis ahí y que os creéis un management pack propio por cada uno que importéis para guardar este tipo de cambios.

Insisto en que hay que ser muy cuidadoso con los overrides, hacerlos sin criterio puede implicar que el día que pase algo de verdad no seremos avisados.

¿Como puedo saber todos los overrides que se han hecho?

En los informes tienes uno que te permite ver los overrides que hay activos para cada management pack.

image

Conclusiones:

  • No cierres las alertas sin resolverlas de verdad, si no puedes trabajar ahora con ellas, cámbialas el estado y asígnalas un dueño.
  • Si la alerta no es correcta no la cierres ni ignores, haz un override para que no de mas trabajo ni a ti ni a tus compañeros
  • Ten criterio y piensa dos veces los overrides antes de hacerlos
  • Se consciente de mirar siempre los monitores de salud antes de dar por resuelta una alerta, si algún monitor sigue en rojo, recalcula la salud del mismo desde su menú, si sigue rojo, es que el problema sigue ahí.

Espero que este post os haya sido de alguna ayuda.

Un saludo a todos.

Crossposting from blogs.technet.com/dmatey

2 comentarios en “Trabajando con Alertas en SCOM desde el punto de vista del operador”

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *