Importancia de la monitorización
La monitorización proactiva del sistema SAP es una de las responsabilidades core de SAP BASIS. Permite detectar problemas antes de que impacten a usuarios, identificar tendencias que indican degradación gradual del rendimiento, y proporciona datos para optimización y dimensionamiento futuro.
Un sistema SAP no monitorizados adecuadamente es como conducir un coche sin mirar el velocímetro o los indicadores del motor. Los problemas pueden escalar hasta causar crashes completos del sistema, pérdida de datos o indisponibilidad prolongada que podría haberse evitado con detección temprana.
Filosofía de monitorización
La monitorización efectiva combina checks automatizados que alertan sobre problemas críticos con revisiones manuales periódicas que identifican tendencias y anomalías sutiles que las alertas automáticas pueden perder.
La monitorización debe ser multinivel: sistema operativo (CPU, memoria, disco, red), base de datos (espacio, performance, locks), aplicación SAP (work processes, memoria SAP, buffers), y negocio (tiempos de respuesta de transacciones críticas, throughput de procesos batch).
Los umbrales de alerta deben calibrarse cuidadosamente. Alertas demasiado sensibles generan fatiga de alertas donde el equipo ignora notificaciones porque la mayoría son falsos positivos. Alertas insuficientes permiten que problemas graves pasen desapercibidos.
Transacción ST06 - Monitorización del sistema operativo
ST06 proporciona una vista detallada del rendimiento del sistema operativo sobre el que ejecuta SAP. Es la primera transacción a verificar cuando hay problemas de performance o estabilidad.
La vista de CPU muestra utilización actual y histórica. Una CPU consistentemente por encima del 80-90% indica subdimensionamiento o procesos ineficientes consumiendo recursos excesivos. ST06 identifica los top consumers de CPU permitiendo identificar culpables.
La monitorización de memoria muestra RAM total, memoria utilizada, y swap usage. Si el sistema está utilizando swap intensivamente, indica que la memoria física es insuficiente y el rendimiento se degradará significativamente porque acceder swap en disco es órdenes de magnitud más lento que RAM.
Los filesystems monitorizados muestran espacio utilizado y disponible. Filesystems llenos pueden causar crashes del sistema SAP. Particularmente críticos son /usr/sap (sistema SAP), el filesystem de la base de datos, y /usr/sap/trans (transportes). Alertas deben activarse cuando filesystems alcanzan 85-90% de capacidad.
La actividad de disco (disk I/O) muestra operaciones de lectura/escritura por segundo y tiempos de respuesta. Tiempos de respuesta de disco superiores a 10-15ms consistentemente indican almacenamiento saturado o mal performante que impactará negativamente todo el sistema.
Transacción ST02 - Monitorización de buffers SAP
ST02 monitoriza los buffers de memoria de SAP que cachean datos frecuentemente accedidos para evitar consultas repetidas a la base de datos. Una configuración óptima de buffers es crítica para el rendimiento.
El table buffer mantiene en memoria contenidos de tablas de base de datos. El ratio de hit debe ser superior al 95%. Un ratio bajo indica que el buffer es demasiado pequeño o que hay problema de configuración que causa que objetos no se cacheen adecuadamente.
El program buffer almacena programas ABAP compilados. Si este buffer es insuficiente, SAP debe recargar programas repetidamente desde base de datos, degradando performance significativamente.
Los swaps mostrados en ST02 indican cuántas veces objetos fueron expulsados del buffer para hacer espacio a otros objetos. Números altos de swaps sugieren que el buffer es demasiado pequeño para la carga de trabajo y debe incrementarse mediante ajuste de parámetros.
El análisis de buffers de ST02 debe revisarse periódicamente, no solo cuando hay problemas. Las tendencias de utilización de buffers informan decisiones de dimensionamiento y optimización.
Transacciones SM50/SM66 - Monitorización de work processes
SM50 muestra el estado actual de work processes de la instancia actual. Cada línea representa un work process: su tipo (diálogo, background, update), estado actual (running, waiting, stopped), qué transacción está ejecutando, y el usuario que la invocó.
SM66 proporciona vista global de work processes de todas las instancias del sistema simultáneamente. Invaluable en sistemas distribuidos con múltiples servidores de aplicación para obtener visión completa del sistema.
El estado "running" es normal para work processes activamente procesando. Si un work process permanece en "running" durante periodos muy largos (horas), puede indicar un loop infinito o proceso bloqueado que debe investigarse.
El estado "stopped" puede indicar problemas. Si múltiples work processes están stopped, el sistema puede tener problemas serios. Un work process stopped individual puede deberse a fallo del proceso que el dispatcher reiniciará automáticamente.
La columna de tiempo muestra cuánto tiempo el work process ha estado en su estado actual. Esto identifica transacciones de larga ejecución que pueden estar causando problemas de performance o bloqueando otros procesos.
Los administradores pueden terminar work processes problemáticos desde SM50/SM66 como último recurso. Sin embargo, esto debe hacerse con cuidado porque puede corromper datos si el proceso estaba en medio de una transacción crítica.
Transacción ST03 - Análisis de workload
ST03 analiza la carga de trabajo del sistema SAP proporcionando estadísticas detalladas sobre uso de recursos, tiempos de respuesta, throughput de transacciones y patrones de uso.
Los tiempos de respuesta por tipo de transacción identifican qué transacciones son lentas. SAP recomienda que el tiempo promedio de respuesta de transacciones de diálogo sea inferior a 1 segundo. Tiempos consistentemente superiores requieren investigación.
El análisis de throughput muestra cuántas transacciones, llamadas RFC, y operaciones de base de datos se procesan. Esto permite identificar picos de carga y planificar capacidad futura.
El desglose de tiempo de respuesta en componentes (tiempo de base de datos, tiempo de CPU, tiempo de espera) identifica dónde están los cuellos de botella. Si el tiempo de base de datos es dominante, el problema está en queries SQL ineficientes o dimensionamiento de base de datos.
Los usuarios top consumers identifican usuarios que consumen recursos desproporcionados. Pueden estar ejecutando transacciones ineficientes, reportes pesados, o procesos batch desde sesiones de diálogo (práctica no recomendada).
Transacción DB02 - Monitorización de base de datos
DB02 monitoriza el espacio de la base de datos: tamaño total, espacio utilizado, espacio libre, y crecimiento histórico. Permite proyectar cuándo la base de datos se quedará sin espacio y planificar expansión proactivamente.
El análisis de tablas muestra las tablas más grandes del sistema. Tablas que crecen rápidamente pueden indicar problemas: logs no archivados, datos temporales no limpiados, o procesos de negocio generando volúmenes inesperados de datos.
Los tablespaces de base de datos deben tener espacio libre suficiente. Un tablespace lleno puede causar fallos de transacciones y en casos extremos, corrupción de base de datos. La expansión de tablespaces debe planificarse antes de alcanzar 85-90% de utilización.
DB02 también proporciona acceso a estadísticas de base de datos que el optimizador de queries utiliza para generar planes de ejecución eficientes. Estadísticas desactualizadas pueden causar degradación severa de performance de queries.
Transacción SM21 - Log del sistema
SM21 muestra el log del sistema SAP que registra todos los eventos significativos: arranques y paradas de sistema, errores de configuración, problemas de autorización, fallos de comunicación, y otros eventos operativos.
Los errores críticos en SM21 requieren investigación inmediata. Pueden indicar problemas de configuración, fallos de hardware, problemas de red, o bugs en el sistema SAP.
Los warnings frecuentemente pueden ignorarse pero patterns de warnings similares repetidos indican problemas subyacentes que eventualmente causarán fallos si no se corrigen.
El log puede filtrarse por severidad, usuario, transacción, o mensaje específico facilitando investigación de problemas particulares. Los filtros son esenciales porque el log completo puede contener millones de entradas.
Transacción SM37 - Monitorización de jobs batch
SM37 gestiona y monitoriza jobs batch programados. Los administradores BASIS revisan diariamente SM37 para verificar que todos los jobs críticos de negocio completaron exitosamente.
Los jobs con estado "finished" completaron exitosamente. Jobs con estado "cancelled" o "aborted" fallaron y requieren investigación. El job log proporciona detalles del error.
Algunos jobs son críticos para operaciones de negocio: cierre contable de fin de mes, procesamiento de nómina, interfaces con sistemas externos, replicación de datos. Fallos de estos jobs deben escalarse inmediatamente.
Los jobs de housekeeping del sistema SAP (limpieza de logs antiguos, reorganización de tablas, recolección de estadísticas de base de datos) deben ejecutarse regularmente. Si estos jobs fallan repetidamente, pueden causar degradación gradual del sistema.
Transacción RZ20 - CCMS Monitoring
RZ20 es el sistema de monitorización centralizado de SAP (CCMS - Computing Center Management System). Proporciona un framework para definir monitores de métricas específicas y generar alertas cuando umbrales se exceden.
Los monitores estándar de SAP cubren aspectos críticos: disponibilidad de instancias, utilización de memoria, espacio en base de datos, performance de backups, estado de colas de transporte, y muchos otros aspectos.
Los monitores pueden configurarse para enviar alertas mediante email, SNMP traps, o integraciones con herramientas de monitorización empresariales cuando se detectan problemas.
Las organizaciones pueden crear monitores custom para aspectos específicos de su entorno: disponibilidad de interfaces críticas, throughput de procesos de negocio específicos, o cualquier métrica importante para sus operaciones.
Monitorización de backups
La verificación diaria de que los backups completaron exitosamente es crítica. Un sistema sin backups recientes es vulnerable a pérdida catastrófica de datos si ocurre un fallo.
Los logs de backup de base de datos deben revisarse para confirmar que los backups completos, incrementales y de logs de transacción finalizaron sin errores. El tamaño del backup debe ser consistente con expectativas.
Los backups de filesystems SAP también requieren verificación. Perder los directorios SAP sin backup puede causar días de trabajo de recuperación incluso si la base de datos está respaldada.
Las pruebas periódicas de restauración validan que los backups son realmente recuperables. Backups que nunca se han probado pueden fallar cuando se necesitan urgentemente, convirtiendo un problema recuperable en desastre.
Monitorización de performance de transacciones
Las transacciones de negocio críticas deben monitorizarse específicamente. Si la creación de pedidos de venta en SD tarda habitualmente 2 segundos pero de repente tarda 10 segundos, algo está mal incluso si no hay alertas técnicas del sistema.
SAP Solution Manager proporciona End-to-End Trace que monitoriza transacciones de negocio específicas desde la perspectiva del usuario, detectando degradación de performance antes de que usuarios se quejen.
Los synthetic transactions son scripts que ejecutan transacciones críticas periódicamente y alertan si fallan o se vuelven lentas. Proporcionan monitorización proactiva de disponibilidad desde perspectiva de usuario.
Alertas y notificaciones
Las alertas automáticas permiten respuesta rápida a problemas críticos. Sin alertas, los administradores deben revisar manualmente múltiples transacciones esperando detectar problemas, lo cual es ineficiente y propenso a perder eventos importantes.
Las alertas deben priorizarse: críticas (requieren acción inmediata 24/7), altas (requieren acción dentro de horas laborales), y warnings (para investigación en siguiente oportunidad).
Los procedimientos de escalado definen quién recibe alertas y cuándo. Las alertas críticas fuera de horario laboral deben llegar a personal de guardia inmediatamente mediante SMS o llamada telefónica, no solo email.
La documentación de alertas debe incluir runbooks: qué significa cada alerta, cómo investigar la causa raíz, y cómo resolver el problema. Esto permite que cualquier miembro del equipo responda efectivamente incluso a alertas que no han visto previamente.
Dashboards y reportes
Los dashboards visuales proporcionan vista rápida de la salud del sistema. En lugar de revisar múltiples transacciones, un dashboard bien diseñado muestra todas las métricas críticas en una pantalla.
Los reportes periódicos (diarios, semanales, mensuales) documentan tendencias de utilización, incidentes ocurridos, cambios de configuración aplicados, y métricas de performance. Son valiosos para planning de capacidad, justificación de inversiones en infraestructura, y reportes a management.
Las herramientas de visualización modernas (Grafana, Kibana, SAP Solution Manager) pueden conectarse a datos de monitorización SAP y presentarlos de forma más intuitiva que las transacciones SAP estándar.
Monitorización de integraciones
Las integraciones entre sistemas SAP y aplicaciones externas deben monitorizarse activamente. Los IDocs atascados, llamadas RFC fallidas, o servicios web inaccesibles pueden interrumpir procesos de negocio críticos.
Las transacciones específicas de integración (WE02 para IDocs, SM58 para RFC asíncronos, SXMB_MONI para PI/PO) deben revisarse regularmente para detectar errores de comunicación.
Las alertas sobre integraciones fallidas permiten respuesta rápida antes de que acumulaciones de errores causen problemas mayores o pérdida de datos.
Monitorización en cloud
Los sistemas SAP en cloud tienen consideraciones adicionales de monitorización. Las herramientas nativas del proveedor cloud (CloudWatch en AWS, Azure Monitor, Cloud Monitoring en GCP) proporcionan métricas de infraestructura.
La integración entre herramientas cloud y monitorización SAP proporciona vista unificada desde infraestructura hasta aplicación, facilitando correlación de problemas entre capas.
Los costes cloud deben monitorizarse como métrica adicional. El consumo de recursos en cloud impacta directamente costes operativos, por lo que spikes inesperados de utilización requieren investigación tanto por impacto en costes como por potenciales problemas técnicos.
Rutinas de monitorización diaria
Los administradores BASIS típicamente ejecutan una rutina de monitorización matinal verificando: todos los sistemas SAP están up, no hay alertas críticas en RZ20, los backups nocturnos completaron exitosamente, los jobs batch críticos finalizaron correctamente, no hay errores críticos en SM21, y la utilización de recursos está en rangos normales.
Esta revisión matinal toma típicamente 15-30 minutos pero es crítica para detectar problemas que ocurrieron durante la noche antes de que afecten el inicio de la jornada laboral.
Las revisiones semanales más profundas analizan tendencias: crecimiento de base de datos, evolución de tiempos de respuesta, patterns de utilización de recursos. Esto permite planificación proactiva de capacidad y optimización.
SAP Solution Manager para monitorización
SAP Solution Manager proporciona capacidades de monitorización centralizada para landscapes SAP completos. Permite monitorizar múltiples sistemas SAP desde una única interfaz.
Los monitores técnicos de Solution Manager detectan problemas antes de que se conviertan críticos. El sistema de alertas integrado notifica automáticamente al equipo BASIS de problemas detectados.
Los dashboards de Solution Manager proporcionan vista ejecutiva de la salud del landscape completo, útil para reportar a management sobre disponibilidad y performance del entorno SAP.
Documentación de incidentes
Todos los incidentes detectados mediante monitorización deben documentarse: qué problema se detectó, cómo se detectó, qué investigación se realizó, qué acción correctiva se tomó, y qué se puede hacer para prevenir recurrencia.
Esta documentación construye una base de conocimiento que acelera resolución de problemas futuros similares y proporciona datos para análisis de causa raíz de problemas recurrentes.
Temas relacionados
Para profundizar en monitorización de sistemas SAP, consulta:
Análisis de dumps y errores para investigar problemas detectados por monitorización.
Parametrización del sistema para ajustar configuración basándose en observaciones de monitorización.
Tareas diarias de un BASIS para la rutina completa de operaciones incluyendo monitorización.
Dimensionamiento para planificar capacidad basándose en datos de monitorización.