Dónde guarda Solaris sus registros y cómo usar fmadm/fmdump para fallos de hardware y de software

Qué es

Solaris guarda la mayoría de los mensajes de registro de todo el sistema en /var/adm/messages; dmesg muestra las últimas 200 entradas de syslog de ese archivo y de sus copias rotadas, en orden cronológico. Aparte de esto, la salida estándar y la de error (stdout/stderr) del método de inicio de cada instancia de servicio SMF se guarda en un archivo de registro propio de la instancia, dentro de /var/svc/log/; la ruta exacta es la que informa svcs -l <fmri>. Y de forma también independiente, la Fault Management Architecture (FMA), formada por fmd y sus herramientas de administración fmadm y fmdump, diagnostica fallos de hardware y algunos de software: convierte la telemetría en bruto en un fallo diagnosticado con un UUID, una lista de sospechosos y una acción sugerida.

Por qué importa

FMA existe porque un único evento de hardware (un módulo DIMM que falla, un disco que empieza a notificar errores) puede generar muchos informes de error en bruto. Los motores de diagnóstico de FMA los correlacionan en un solo registro de fallo, en lugar de dejar que el administrador lea muchas líneas de registro y adivine. Es un modelo mental distinto al de Linux, donde para el mismo fin suelen usarse de forma dispersa los registros del kernel y herramientas independientes de cada fabricante.

Cómo aplicarlo

• Listar los componentes que fallan actualmente: fmadm faulty muestra los componentes que FMA ha diagnosticado como averiados, defectuosos o marcados de otro modo, junto con el UUID del diagnóstico para poder referenciarlo. Requiere la autorización solaris.fm.read (perfil de derechos "Fault Information" o "Fault Management", o el rol root); aquí también pueden aparecer servicios SMF que han pasado a maintenance.
• Ver el historial completo de diagnósticos, no solo los fallos actuales: fmdump a secas imprime el registro de fallos (una línea por evento de diagnóstico, incluidos los registros rotados); añade -v para obtener el detalle de cada evento. fmdump -e muestra en su lugar la telemetría de errores en bruto (ereports), que tiene un formato privado y no está pensada para procesarse en scripts. Leer estos registros normalmente requiere el rol root.
• Consultar un evento concreto por su UUID: fmdump -u <uuid> -v imprime el diagnóstico completo de ese evento, útil cuando un servicio o una alerta de monitorización ya te ha dado un UUID.
• Ante el fallo de un servicio SMF, empieza con svcs -x (véase el artículo sobre SMF de esta serie), que indica la ruta del registro; lee ese archivo en /var/svc/log/ para ver la salida de error del propio servicio, independiente de lo que FMA haya diagnosticado.
• Para revisar rápidamente los mensajes del kernel y los generales del sistema, usa dmesg, y lee /var/adm/messages directamente si necesitas más de las últimas 200 entradas o entradas que dmesg ya no alcanza por haberse rotado.

Trampas

• Buscar solo en /var/adm/messages cuando falla un servicio: la salida del método de inicio del servicio está en su archivo dedicado en /var/svc/log/, no en el registro de mensajes del sistema.
• Tratar fmadm faulty como el historial completo de fallos: muestra los fallos actuales, no los resueltos; usa fmdump para ver la cronología completa, incluidos los fallos que ya se han reparado o sustituido.
• Suponer que todo problema de hardware produce un fallo en FMA: algunas condiciones siguen apareciendo solo como mensajes en bruto en /var/adm/messages, en especial en hardware no soportado o virtualizado, donde faltan los módulos de diagnóstico específicos de la plataforma.