✒️SAP BASIS / Uso de herramientas locales de monitoreo Por Fernando Escola

Uso de herramientas locales de monitoreo

1. ¿Por qué es fundamental el monitoreo? Los procesos de negocio modernos dependen de múltiples componentes (producidos por SAP o terceros). Una falla o una baja gradual en el rendimiento de cualquiera de ellos impacta directamente en la productividad general. Por ello, el administrador de sistemas tiene la responsabilidad de realizar un monitoreo regular para:

• Prevenir errores antes de que ocurran.
• Solucionar problemas de forma eficiente una vez reportados.
• Encontrar la causa raíz mediante opciones de monitoreo local.

2. Objetivos y Métodos

• ¿Para qué? Para garantizar que los procesos de negocio se ejecuten de forma eficiente y asegurar la estabilidad y seguridad del sistema.
• ¿Cómo? De manera centralizada (abarcando varios sistemas), mediante el uso de alertas automáticas en caso de errores y proporcionando información detallada para el diagnóstico.

3. Ejemplo práctico: El riesgo de no monitorear El texto describe un escenario donde un sistema de archivos llega al 100% de su capacidad.

• Consecuencia: Al no haber espacio, la base de datos no puede expandir sus tablas. Cuando un usuario intenta realizar una transacción, el sistema desactiva las actualizaciones para evitar más errores.
• Impacto final: Las sesiones de los usuarios se bloquean (aparece el "reloj de arena") y el sistema SAP queda inutilizable.
• Conclusión del ejemplo: Si el administrador hubiera monitoreado el espacio en disco regularmente, habría tomado medidas a tiempo, evitando la caída total del sistema.

Arquitectura de Monitoreo Local (CCMS)

Esta arquitectura utiliza Proveedores de Datos (Data Suppliers) que vienen integrados para los componentes más importantes del sistema SAP. Su principal ventaja es que pueden utilizarse de inmediato sin necesidad de configuración adicional.

Componentes que se monitorean automáticamente:

• Servidores donde se ejecuta el sistema SAP.
• Bases de datos.
• Instancias de SAP (servidores de aplicación) y sus servicios.
• Componentes externos al sistema.

Tipos de Proveedores de Datos

Los proveedores se inician automáticamente al arrancar el sistema o cuando son requeridos, y se dividen en dos categorías según cómo se activan:

1. Proveedores de Datos Pasivos (Passive Data Suppliers):
   • Son iniciados por la propia arquitectura de monitoreo.
   • No tienen autonomía para arrancar por sí mismos.
   • También se les denomina "métodos de recolección de datos".
2. Proveedores de Datos Activos (Active Data Suppliers):
   • Son iniciados por la aplicación monitoreada y no por la arquitectura de monitoreo.
   • Tienen un comportamiento de inicio autónomo en relación con el sistema de control.

Funcionamiento Técnico

• Segmento de Monitoreo: Los proveedores escriben los valores de los objetos monitoreados en un segmento de la memoria compartida.
• Infraestructura: El proceso consta de tres etapas fundamentales:
  1. Recolección de datos.
  2. Almacenamiento de datos.
  3. Análisis de datos.

1. Recolección y Almacenamiento de Datos

• Recolectores de datos (Data Collectors): Son programas especiales (escritos en ABAP, C/C++ o Java) que monitorean subáreas específicas de un sistema SAP a intervalos regulares.
• Segmento de monitoreo local: Es el área de la memoria principal (memoria compartida) donde los recolectores almacenan la información.
• Gestión de la memoria: Los datos en la memoria principal se sobrescriben continuamente para ahorrar espacio. No obstante, se pueden guardar datos históricos en tablas de base de datos para análisis posteriores.
• Extensibilidad: El sistema permite integrar componentes propios mediante recolectores programados por el usuario.

2. Especificaciones por Instancia

• Cada instancia de un sistema SAP que cuente con el componente SAP_BASIS posee su propio segmento de monitoreo.
• El número de segmentos es igual al número de instancias, independientemente de si estas se ejecutan en el mismo hardware o no.

3. Reacción y Análisis de Problemas

• Método de Reacción Automática: Si el sistema identifica un problema, puede ejecutar acciones automáticas predefinidas, como enviar una notificación a la persona responsable.
• Métodos de Análisis: Herramientas diseñadas para clarificar y profundizar en las causas de las alertas.

4. Herramientas de Visualización y Gestión

Para analizar la información contenida en los segmentos de monitoreo, se dispone de:

• SAP Management Console (MC / MMC): Funciones de visualización gráfica.
• Línea de comandos: Herramientas técnicas como dpmon o msmon.
• Monitor de Alertas (Transacción RZ20): Utilizado en sistemas basados en ABAP para visualizar y analizar alertas de forma local o centralizada.
• Productos ALM (Application Lifecycle Management): Las métricas pueden transferirse a soluciones más robustas como SAP Solution Manager, SAP Focused RUN o SAP Cloud ALM para una gestión integral de la infraestructura.

Monitoreo de la consola de administración SAP

1. Monitoreo del Estado del Sistema

La SAP MC organiza la información en una estructura de árbol que permite visualizar alertas basadas en umbrales predefinidos. El área de monitoreo se divide en dos secciones fundamentales:

• Alertas Abiertas (Open Alerts): Muestra los incidentes más graves que han ocurrido en el sistema. Incluye los KPIs relevantes, sus valores y el momento del suceso.
  • Nota: Esta vista no necesariamente refleja el estado actual, sino el histórico de alertas pendientes.
• Estado Actual (Current Status): Refleja los datos reportados en tiempo real para cada elemento. Muestra los valores de los KPIs y la hora exacta de la última medición.

2. Gestión y Personalización de Alertas

• Reconocimiento: Para sistemas con backend ABAP, las alertas se gestionan y reconocen a través de la Bandeja de Entrada de Alertas (Alert Inbox).
• Ordenamiento: La tabla de resultados permite organizar la información por nombre de la alerta, tiempo o siguiendo la estructura del árbol de monitoreo.
• Configuración de Umbrales: Si los niveles predefinidos no se ajustan a las necesidades del entorno, pueden modificarse. En sistemas ABAP, esto se realiza específicamente mediante la transacción RZ20.

3. Monitoreo de Componentes Específicos

La consola permite profundizar en la operación de diversos servicios técnicos:

• ICM (Internet Communication Manager): Proporciona detalles sobre la lista de hilos (worker threads), conexiones existentes, objetos en caché y la lista de servidores proxy.
• Base de Datos: Se identifica en el árbol (generalmente en color azul). Al autenticarse, permite ver el tipo de servidor, el host de la instancia, el proveedor de la base de datos y el SAPSID.
• Otros Componentes: También ofrece visibilidad sobre el SAP Web Dispatcher, el servidor de Enqueue y el servidor de Mensajes.

La operación del monitor de alertas

. El Monitor de Alertas (Transacción RZ20)

El Monitor de Alertas es la herramienta central para supervisar sistemas SAP y no-SAP, bases de datos y hosts. Su función principal es reducir la carga de trabajo del administrador al filtrar la información y mostrar solo los errores relevantes mediante una estructura de árbol.

• Indicadores Visuales: Las alertas utilizan un sistema de colores y valores numéricos:
  • Amarillo: Advertencia.
  • Rojo: Problema/Error.
  • Valor numérico: Indica el grado de gravedad del error.
• Propagación de Alertas: Las alertas más graves se transmiten hacia arriba en la jerarquía del árbol. Si un nodo raíz no muestra alerta, significa que toda su rama inferior está libre de errores.

2. Métodos de Respuesta ante Alertas

El sistema permite automatizar o agilizar la resolución de problemas mediante dos tipos de métodos:

• Métodos de Análisis: Se activan manualmente al hacer doble clic sobre una alerta. El monitor inicia una herramienta específica para diagnosticar el problema (por ejemplo, lleva al administrador directamente a la gestión de trabajos si un proceso falló).
• Métodos de Reacción Automática: Se ejecutan instantáneamente cuando ocurre la alerta, sin intervención humana. Ejemplos comunes son el envío de correos electrónicos, mensajes SMS o la ejecución de comandos del sistema operativo.

3. Estructura del Árbol de Monitoreo (MTE)

Cada nodo en el árbol de monitoreo se denomina MTE (Monitoring Tree Element). La jerarquía se organiza de la siguiente manera:

1. Atributos de Monitoreo (Nivel Hojas): Son los elementos en el nivel más bajo donde se recolectan los valores reales (ej. % de uso de CPU, tasa de aciertos en el buffer, uso de Swap). Aquí es donde se configuran los valores de umbral que disparan las alertas.
2. Objetos de Monitoreo: Agrupan atributos relacionados de manera lógica (ej. el objeto "Buffer de programa" agrupa los atributos de "hit rate" y "swap").
3. Nodos Superiores: Agrupan los objetos para ofrecer una visión clara por área temática (Sistema Operativo, Base de Datos, etc.).

4. Organización de los Monitores

Para facilitar la gestión, SAP organiza las vistas de monitoreo en tres niveles:

• Conjunto de Monitores (Monitor Set): Una colección de monitores para un producto o escenario específico (ej. un conjunto para SAP CRM).
• Definición de Monitor: Es la selección específica de objetos y atributos que se desean examinar. Es el "plano" de lo que el administrador verá.
• Monitor: Es la visualización final de los datos solicitados según su definición.

5. Mejores Prácticas y Configuración

• Plantillas Preconfiguradas: SAP entrega conjuntos de monitores listos para usar (como Availability and Performance Overview). Se recomienda empezar con estos y luego personalizarlos.
• Ajuste de Umbrales: Aunque vienen valores por defecto, el administrador puede ajustar individualmente los umbrales de cada atributo para que se adapten a las necesidades específicas de su entorno de IT.
• Vistas de Alertas: El monitor permite alternar entre ver los "mensajes de problema actuales" o las "alertas abiertas" (aquellas que aún no han sido analizadas o reconocidas).

El Procesamiento de alertas

1. Vistas Principales del Monitor

El sistema ofrece dos perspectivas fundamentales para gestionar el estado del sistema:

• Estado actual del sistema (Current system status): Muestra los datos y el rendimiento en tiempo real. Si un problema ya se resolvió, el indicador aparecerá en verde.
• Alertas abiertas (Open alerts): Registra problemas que ocurrieron (incluso si ya no están presentes) y que aún no han sido gestionados o "completados" por el administrador. En esta vista, los problemas se muestran en rojo.

2. Flujo de Trabajo para Procesar Alertas

Para gestionar una alerta de manera efectiva, se debe seguir este procedimiento secuencial:

1. Selección del MTE: Dentro del árbol de monitoreo, se elige el elemento de monitoreo (Monitoring Tree Element) específico que presenta la alerta.
2. Desplegar Alertas: Al hacer doble clic en un MTE (o en la raíz del árbol para ver todo el conjunto), se abre el Navegador de Alertas (Alert Browser), que lista las alertas ordenadas por prioridad (rojas y amarillas).
3. Análisis: Se selecciona la alerta individual y se utiliza el botón "Iniciar Método de Análisis". Esto ejecuta automáticamente herramientas integradas (transacciones, funciones o URLs) diseñadas para diagnosticar ese problema específico sin que el usuario deba conocer la herramienta técnica de antemano.
4. Resolución y Cierre: Una vez analizado y solucionado el problema:
   • Se utiliza la tecla F3 (Atrás) para volver a la lista.
   • Se selecciona "Completar Alertas" (Complete Alerts). Esto elimina la alerta de la lista de "Abiertas" y la mueve a una tabla de base de datos histórica.

3. Gestión del Historial

• Limpieza de la vista: El objetivo es procesar todas las alertas hasta que la lista de "Alertas Abiertas" esté vacía. De este modo, el monitor solo mostrará incidencias nuevas.
• Consulta de registros pasados: Si es necesario revisar una alerta ya gestionada, se debe seleccionar la opción "Mostrar historial de alertas" (Show alert history). En esta vista, las alertas procesadas aparecerán con el estado "Hecho" (Done).

La utilización de la infraestructura de CCMS herramienta central de monitoreo del sistema

1. Concepto de Monitoreo Central (CEN)

La infraestructura de CCMS permite configurar un Sistema de Monitoreo Central (CEN) para supervisar todo el entorno tecnológico desde un único punto.

• Capacidad: Una sola instancia central puede monitorear entornos de hasta 100 componentes.
• Objetivo: Evitar que el administrador deba iniciar sesión en cada servidor individualmente, permitiendo una visualización "de un vistazo" y notificaciones automáticas ante errores.
• Sistemas compatibles: Puede integrar sistemas SAP (como ECC o S/4HANA), componentes SAP sin SAP_BASIS y sistemas No-SAP.

2. Funcionamiento y Recolección de Datos

• Segmento de Monitoreo: Cada componente del entorno recolecta sus propios datos y los almacena localmente en un área de su memoria principal denominada "segmento de monitoreo" (cuyo tamaño es configurable).
• Mecanismos de conexión:
  • Sistemas con SAP_BASIS: La infraestructura existe de forma automática.
  • Sistemas sin SAP_BASIS: Se utiliza el servicio de inicio de SAP (sapstartsrv) para establecer la conexión.
• Acceso y Análisis: El sistema central recopila los datos de estos segmentos. Ante un error, el administrador puede saltar directamente desde el CEN al sistema afectado a través de una conexión RFC para resolver el problema.

3. Recomendaciones de Arquitectura

Para garantizar la eficiencia y el rendimiento, el material sugiere:

• Selección del CEN: El sistema elegido como monitor central debe tener el nivel de release más alto posible y ofrecer alta disponibilidad.
• Carga de Trabajo: En entornos grandes, se recomienda dedicar un sistema separado exclusivamente para tareas centrales como el monitoreo, la Administración Central de Usuarios (CUA) y el controlador de dominio de transporte. Esto evita impactar el rendimiento de los sistemas productivos, ya que la recolección de datos es descentralizada y el impacto en el CEN es insignificante.

4. Evolución de las Herramientas

Aunque CCMS es una opción válida, el manual recomienda considerar infraestructuras de monitoreo modernas dentro de SAP Application Lifecycle Management (ALM), tales como:

• SAP Solution Manager
• SAP Focused RUN
• SAP Cloud ALM (dependiendo de las necesidades específicas del entorno).

Monitorear, Analizar, Probar y Resolver problemas usando Programas de línea de comando de SAP

1. Introducción a las Herramientas de OS

SAP proporciona un conjunto de ejecutables que residen en el sistema operativo (comúnmente en la ruta /usr/sap/SYS/exe/run). Estas herramientas permiten administrar el sistema cuando las transacciones estándar de SAP GUI no están disponibles o el sistema sufre una paralización.

• Usuario: Se deben ejecutar con el usuario administrador del sistema operativo (habitualmente <sid>adm).
• Estado: Algunas no tienen documentación oficial o están destinadas principalmente al Soporte de SAP, por lo que requieren precaución y conocimientos técnicos previos.

2. Diccionario de Herramientas Principales

A continuación, se detallan los programas más relevantes y sus funciones:

• dpmon: El monitor del Dispatcher. Es esencial para ver el estado de los work processes en modo texto. Permite detener procesos, generar dump stacks y crear snapshots.
• icmon: Monitor para el Internet Communication Manager (ICM). Similar a la transacción SMICM.
• wdispmon: Herramienta de monitoreo para el SAP Web Dispatcher.
• gwmon: Monitor del SAP Gateway. Alternativa a la transacción SMGW.
• msmon / msprot: Utilidades para monitorear y probar el Message Server.
• lgtst: Programa de prueba para verificar los grupos de inicio de sesión de SAP.
• esmon / es2mon: Monitores específicos para el Enqueue Server y sus servidores de replicación.

3. Sintaxis y Ejecución

Para iniciar estos programas, generalmente se requiere referenciar el perfil de la instancia correspondiente. La sintaxis típica es: saprogram pf=[ruta_al_perfil]

Ejemplos:

• Para el Message Server: msmon pf=/usr/sap/S4D/SYS/profile/S4D_ASCS10_s4dhost
• Para el Dispatcher: dpmon pf=/usr/sap/S4D/SYS/profile/S4D_D11_s4dhost

4. Casos de Uso Críticos

El uso de la línea de comandos es preferible o necesario en los siguientes escenarios:

• Fallo del Sistema: Si el sistema está paralizado y no puedes entrar por SAP GUI para usar la SM50 o SM66.
• Gateway Independiente: Cuando se usa un gateway externo donde la transacción SMGW no tiene alcance.
• Pérdida de Accesos: Si se olvida la contraseña de administración web para el ICM o el Web Dispatcher.
• Pruebas de Carga: Para verificar si la configuración del sistema soporta la cantidad de solicitudes entrantes.
• Administración de Enqueue: Para gestionar el servidor de replicación a nivel de OS.

5. Referencias Técnicas (Notas SAP)

Para profundizar en el uso de estas herramientas, el material destaca las siguientes notas:

• 42074: Uso del monitor del dispatcher (dpmon).
• 64016: Uso del monitor del SAP Gateway (GWMON).
• 64015: Descripción del programa de prueba lgtst.

Iniciar Edición