
Arquitectura de monitoreo
1. El propósito de la infraestructura de monitoreo
Como administradores de SAP se debe garantizar una buena performance del sistema, por lo tanto se debe monitorear el sistema y tomar acciones preventivas de ser necesario.
¿Por qué?
- Para asegurar procesamiento eficiente
- Para asegurar seguridad y estabilidad de sistema.
¿Cómo?
- De forma central y cross-system
- Con alertas ante eventuales errores
- Con ayuda que provee información detallada cross-system
¿Con qué herramientas?
- Con la infraestructura de monitoreo de alertas CCMS y txs especiales conectadas a este.
En los landscapes muchos componentes están involucrados en un proceso de negocio estos deben ser monitoreados, por posibles errores que se presentar, como acciones preventivas.
Ejemplo: el sistema de archivos donde está la BD está al 100% ocupado, un usuario ingresa más datos a la misma tabla, entonces falla el insert, y también el error en la BD hace que el proceso de actualización sea desactivado. Todas las sesiones se quedan colgadas, el sistema sap se bloquea por completo, si se hubiera monitoreado esto a tiempo se pudo haber evitado este Downtime o interrupción de sistema. El monitoreo se debe hacer de forma eficiente ya que el admin no puede entrar a consultar todos los procesos. Debe ser de un vistazo todo el landscape
2. El sistema central de monitoreo
Se realiza por medio de la tx RZ20
El segmento de monitoreo se almacena a nivel de archivo (DIR_LOGGIN, AL*) durante el apagado de una instancia y periódicamente cada 30 min luego es cargado en la memoria compartida durante el reinicio del sistema.
La infraestructura debe ser instalada en cada componente que será monitoreado esto es automático desde sap basis 4.0 en adelante. Esta parte de la memoria se denomina segmento de monitoreo y se puede configurar su tamaño. El sistema seleccionado de landscape debe ser el mayor versión y de más alta disponibilidad.
En landscapes grandes se recomienda tener un sistema para monitoreo, el solution manager es una buena opción para esto.
Solution manager no requiere licencia adicional y se utiliza para muchas funciones de soporte al landscape para las instalaciones actuales es prerrequisito contar con este.
Desde el punto de vista de performance esta se puede ver afectada ya que se hace de forma descentralizada. Se ve todo el landsape, si ocurre un error el admin salta del sistema central al monitoreado (por rfc) al componente relevante para corregir el error.
3. El monitor de alertas CCMS
Muestra los datos en un contexto orientad a procesos, si el sistema identifica un error, puede ejecutar una acción programada, como informar al responsable.
Muestra los datos en forma de árbol, cada nodo se denomina MTE o elemento de árbol de monitoreo, las hojas se conocen como atributos de monitoreo.
Los valores umbrales son almacenados para cada atributo de monitor y se pueden ajustar en caso de ser necesario.
4. Sets de monitores
Se pueden crear los monitores con lo que requerimos visualizar y monitorear
Se asignan los valores de umbrales y estos darán alertas de color amarillo y rojo depende de cómo se configure, amarillo es que se acerca al umbral y rojo más critico.
- Estado actual Current status: muestra el monitor con los últimos datos reportados.
- Alertas abiertas: Muestra el monitor con el histórico de alertas
Ejemplo si en la noche ocurrió un error que ya no pasa, en la vista estado actual sera en verde, pero en la vista de alertas abiertas estará en amarillo o rojo.
Si se selecciona complete alerts, las alertas ya procesadas se eliminan y se almacenan en la BD. Si se requiere ver selecciona show alert history en navegador de alertas, las que están completas aparecen como DONE.