Compartir por


Migración al agente de Azure Monitor desde el agente de Log Analytics

Agente de Azure Monitor (AMA) reemplaza al agente de Log Analytics, también conocido como el Agente de supervisión de Microsoft (MMA) y OMS, en máquinas Windows y Linux en entornos de Azure y no de Azure, nubes locales y de terceros. El agente presenta un método simplificado y flexible de configuración de la recopilación de datos mediante Reglas de recopilación de datos (DCR). En este artículo se proporcionan instrucciones sobre cómo implementar una migración correcta desde el agente de Log Analytics al agente de Azure Monitor.

La migración es una tarea compleja. Comience a planear la migración al agente de Azure Monitor mediante la información de este artículo como guía.

Importante

El agente de Log Analytics se retiró el 31 de agosto de 2024. Este desuso no se aplica al agente de MMA conectado exclusivamente a una instalación de SCOM local.

Puede esperar lo siguiente cuando use el agente de MMA u OMS después del 31 de agosto de 2024.

  • Carga de datos: los servicios de ingesta en la nube reducirán gradualmente la compatibilidad con los agentes de MMA, lo que puede provocar una disminución del soporte técnico y posibles problemas de compatibilidad para los agentes de MMA a lo largo del tiempo. La ingesta de MMA no se modificará hasta el 1 de febrero de 2025.
  • Instalación: se quitará la capacidad de instalar los agentes heredados de Azure Portal y se quitarán las directivas de instalación de los agentes antiguos. Todavía puede instalar la extensión de agentes de MMA, así como realizar instalaciones sin conexión.
  • Soporte técnico al cliente: no podrá obtener soporte técnico para problemas del agente antiguo.
  • Compatibilidad con el sistema operativo: no se agregará compatibilidad con las nuevas distribuciones de Linux o Windows, incluidos los Service Packs, después del desuso de los agentes heredados.
  • El agente de Log Analytics puede coexistir con el agente de Azure Monitor. Espere ver datos duplicados si ambos agentes recopilan los mismos datos.

 

Ventajas

Con el agente de Azure Monitor, obtendrás ventajas inmediatas, como se muestra a continuación:

Diagrama de un resumen de las ventajas del agente de Azure Monitor. Esto se describe con más detalle a continuación.

  • Ahorro de costes mediante reglas de recopilación de datos:
    • Habilita la recopilación de datos de destino y granular para una máquina o subconjuntos de máquinas, en comparación con el enfoque "todo o nada" de los agentes heredados.
    • Permite filtrar reglas y transformaciones de datos para reducir el volumen de datos general que se carga, lo que reduce significativamente los costos de ingesta y almacenamiento.
  • Seguridad y rendimiento
    • Seguridad mejorada mediante identidad administrada y tokens de Microsoft Entra (para clientes).
    • Mayor rendimiento de eventos que es un 25 % mejor que los agentes heredados de Log Analytics (MMA/OMS).
  • Administración más sencilla, esto incluye la solución de problemas eficaz:
    • Admite cargas de datos en varios destinos (varias áreas de trabajo de Log Analytics, es decir, el hospedaje múltiple en Windows y Linux), lo que incluye la recopilación de datos entre regiones y entre inquilinos (mediante Azure LightHouse).
    • Configuración de agentes centralizada "en la nube" a escala empresarial durante todo el ciclo de vida de recopilación de datos, desde la incorporación hasta la implementación, las actualizaciones y los cambios a lo largo del tiempo.
    • Todos los cambios en la configuración se implementan automáticamente en todos los agentes, sin necesidad de una implementación del lado cliente.
    • Mayor transparencia y control de más funcionalidades y servicios, como Microsoft Sentinel, Defender for Cloud y VM Insights.
  • Un único agente que atiende todas las necesidades de recopilación de datos en servidores y dispositivos admitidos. Un único agente es el objetivo, aunque el agente de Azure Monitor converge actualmente con los agentes de Log Analytics.

Antes de empezar

  • Compruebe los requisitos previos para instalar el agente de Azure Monitor. Para supervisar servidores que no sean de Azure o locales, debe instalar el agente de Azure Arc. El agente de Arc hace que los servidores locales estén visibles para Azure como un recurso al que puede dirigirse. No incurrirá en ningún costo adicional por instalar el agente de Azure Arc.

  • Comprobar que el agente de Azure Monitor puede satisfacer todas sus necesidades. El agente de Azure Monitor posee disponibilidad general (GA) para la recopilación de datos y esta se usa por parte de varias características de Azure Monitor y otros servicios de Azure.

  • Compruebe que tenga los permisos necesarios para instalar el agente de Azure Monitor. Debe tener los permisos necesarios para instalar el agente en las máquinas que desea supervisar. Para obtener más información, consulte Permisos necesarios para instalar el agente de Azure Monitor.

Guía de alto nivel

Use las instrucciones siguientes para planear y ejecutar la migración:

  • Comprenda los agentes y cuántos tiene que migrar.
  • Comprenda cómo usa las áreas de trabajo.
  • Comprenda qué soluciones, conclusiones y recopilaciones de datos están configuradas.
  • Configure las recopilaciones de datos y valide las recopilaciones.
  • Comprenda las dependencias y los servicios adicionales.
  • Quite los agentes heredados.

El libro Asistente para la migración del agente de Azure Monitor es una solución de Azure Monitor basada en libros que puede ayudarle en cada uno de los pasos descritos anteriormente. En esta guía se hace referencia al libro y a otras herramientas en cada fase del proceso de migración. Para obtener más información, consulte el libro del asistente para la migración del agente de Azure Monitor.

Descripción de los agentes

Use el generador de DCR para convertir la configuración del agente heredado en reglas de recopilación de datos automáticamente.1 Para poder entender a sus agentes, revise las siguientes preguntas:

Pregunta Acciones
¿Cuántos agentes tiene que migrar? Comprenda el número de agentes que tiene que migrar.
¿Tiene algún agente que se implemente fuera de Azure?

¿Estos agentes se implementan en su propio centro de datos o en otro entorno en la nube?

En el caso de los servidores que están fuera de Azure, primero debe implementar el agente de Azure ARC Connected Machine. Para obtener más información, consulte Introducción al agente de Azure Connected Machine.
¿Usa System Center Operations Manager (SCOM) ?

¿Cuál es su plan previsto para SCOM de ahora en adelante?

Si planea seguir usando SCOM, empiece a evaluar la instancia administrada de SCOM. Para obtener más información, consulte Instancia administrada de SCOM.
¿Cómo implementa los agentes hoy en día? Si usa métodos automatizados para implementar el agente heredado, tenga en cuenta cuándo detener esas implementaciones automatizadas para nuevos servidores y empiece a centrarse en la implementación del nuevo agente. Detener la implementación automatizada para nuevos servidores le ayuda a asegurarse de que no se sigue agregando elementos al esfuerzo de migración y le permite centrarse en el inventario existente de agentes que se van a migrar.

El libro de Asistente de migración del agente de Azure Monitor puede ayudarle a comprender cuántos agentes tiene que migrar. Para obtener más información, consulte Libro de Asistente de migración del agente de Azure Monitor: Agentes.|

Comprender las áreas de trabajo, las soluciones, las conclusiones y las recopilaciones de datos

Antes de la migración, comprenda cómo se usan las áreas de trabajo de Log Analytics. Compruebe si todas están en uso y qué agentes envían su telemetría a qué áreas de trabajo. Muchas áreas de trabajo se crean con el tiempo y puede estar poco claro qué áreas de trabajo están en uso, qué áreas de trabajo se usan para recopilar telemetría y desde qué servidores. La migración es una buena oportunidad para limpiar y consolidar las áreas de trabajo.

Al examinar las áreas de trabajo, tenga en cuenta qué soluciones están configuradas. Esta información es importante para comprender qué datos va a recopilar y cómo se usan.

El libro de Asistente de migración del agente de Azure Monitor puede ayudarle a comprender qué áreas de trabajo tiene y las soluciones implementadas en cada área de trabajo, y cuándo usó la solución por última vez. Cada solución tiene una recomendación de migración. Para obtener más información, consulte el Libro de Asistente de migración del agente de Azure Monitor: Áreas de trabajo.

También puede usar el libro Auditoría del área de trabajo de Azure Monitor para ayudarle a comprender las áreas de trabajo. Para usar el libro Auditoría del área de trabajo de Azure Monitor, copie el libro del repositorio de GitHub e impórtelo en el área de trabajo de Log Analytics.

Este libro recopila todas las áreas de trabajo de Log Analytics y muestra lo siguiente para cada área de trabajo:

  • Todos los orígenes de datos que envían datos al área de trabajo.
  • Los agentes que envían latidos al área de trabajo.
  • Los recursos que envían datos al área de trabajo.
  • Cualquier recurso de Application Insights que envíe datos al área de trabajo.

Para obtener más información, consulte el Libro de Auditoría del área de trabajo de Azure Monitor.

Configuración de las colecciones de datos y validación de las recopilaciones

Al configurar las recopilaciones de datos, tenga en cuenta los pasos siguientes:

  • Identifique un grupo piloto de servidores que pueda usar para este proceso. Use los servidores piloto para validar los datos antes de implementarlos a gran escala.

  • Use el generador de configuración de DCR para transformar las recopilaciones de datos configuradas en el área de trabajo e implementarlas como reglas de recopilación de datos en el entorno. Para obtener más información sobre el generador de configuración de DCR, consulte Generador de configuración de DCR.

  • Migre VM Insights o Azure Monitor para máquinas virtuales al agente de Azure Monitor. Valide las colecciones de datos migradas para el grupo piloto de servidores en comparación con lo que se recopiló antes de la migración. Para evitar la ingesta doble, puede deshabilitar la recopilación de datos de agentes antiguos durante la fase de prueba sin desinstalar los agentes aún, quitando las configuraciones del área de trabajo de los agentes antiguos. Para obtener más información, consulte Orígenes de datos del agente de Log Analytics en Azure Monitor.

  • Valide los nuevos datos para asegurarse de que no haya brechas. Compare los datos ingeridos por los datos del agente heredado con el agente de Azure Monitor. Use KQL para comparar datos equivalentes de cada agente en función del tipo de agente.

  • Planee la implementación a gran escala mediante Azure Policy. Use directivas integradas para implementar extensiones y asociaciones DCR a gran escala. El uso de directivas también garantiza la implementación automática de extensiones y asociaciones DCR para máquinas nuevas. Para obtener más información sobre la implementación a gran escala, consulte Administración del agente de Azure Monitor: uso de directivas de Azure.

Comprenda las dependencias y los servicios adicionales

Antes de la migración, es importante comprender cómo se ven afectados los otros servicios.

Service Impacto
Administración de actualizaciones Si usa Update Management en Azure Automation, debe migrar al Administrador de actualizaciones de Azure.

El Administrador de actualizaciones de Azure tiene su propio agente y se desacopla del agente de Azure Monitor.

Update Management quedará en desuso a finales de agosto de 2024. Se recomienda migrar al Administrador de actualizaciones de Azure.

Para obtener más información, consulte Pasar del Administrador de actualizaciones de Automation al Administrador de actualizaciones de Azure.

El libro de Asistente de migración de AMA muestra qué máquinas usa hoy la solución de administración de actualizaciones y cómo migrarlas. Para obtener más información, consulte Libro de Asistente de migración del agente de Azure Monitor: administración de actualizaciones.

Change Tracking e Inventario Si usa Seguimiento de cambios e inventario, debe migrar a Azure Automation.

Seguimiento de cambios e inventario también forma parte de Azure Automation. Aunque el agente de Azure Monitor tiene una solución de Seguimiento de cambios e inventario, debe crear una regla de recopilación de datos. Para obtener más información, consulte Administración del Seguimiento de cambios e inventario mediante el Agente de Azure Monitor.

Defender for Cloud Si usa Defender for Cloud para el servicio o Defender para servidores y tiene P2 habilitado o tiene previsto habilitar P2 para los servidores, cambie la implementación del agente en Defender for Cloud de la implementación del agente heredada a un examen sin agente.

Si usa Defender for Cloud para recopilar eventos de seguridad, cree una regla de recopilación de datos personalizada para recopilar esos eventos.

Microsoft Sentinel Si usa Microsoft Sentinel, las soluciones que usaban el agente heredado se han convertido en soluciones basadas en el agente de Azure Monitor y se pueden actualizar.

Eliminación de los agentes heredados

Como parte del planeamiento de la migración, planee quitar el agente heredado una vez completada la migración para evitar la duplicación de la recopilación de datos.

Si no necesita conservar el MMA en ninguna de las máquinas, use la herramienta Detección y eliminación de MMA para quitar el agente a gran escala. Para obtener más información sobre la herramienta Detección y eliminación de MMA, consulte Herramienta de Detección y eliminación de MMA.

Sin embargo, si usa System Center Operations Manager (SCOM), mantenga el agente MMA implementado en las máquinas que seguirá administrando con System Center Operations Manager.

Existe un módulo de administración de SCOM y puede ayudarle a quitar las configuraciones del área de trabajo a gran escala mientras conserva la configuración del grupo de administración de SCOM. Para obtener más información sobre el módulo de administración de SCOM, consulte Módulo de administración de SCOM.

Problemas conocidos de migración

  • Registros de IIS: cuando la recopilación de registros de IIS está habilitada, es posible que AMA no rellene la columna sSiteName de la tabla W3CIISLog. Este campo se recopila de forma predeterminada cuando la recopilación de registros de IIS está habilitada para el agente heredado. Si necesita recopilar el campo sSiteName mediante AMA, habilite el campo en el registro Service Name (s-sitename) W3C de IIS. Para conocer los pasos para habilitar este campo, consulte Seleccionar campos W3C para registrar.
  • Solución de SQL Assessment: ahora forma parte de la valoración de procedimientos recomendados de SQL. Las directivas de implementación requieren un área de trabajo de Log Analytics por suscripción, que no es el procedimiento recomendado por el equipo de AMA.
  • Microsoft Defender para la nube: se mueve a una solución sin agente. Algunas características no estarán listas para la fecha de desuso. Los clientes deben mantenerse en MMA para las máquinas que usan la supervisión de la integridad de los archivos (FIM), las recomendaciones de detección de Endpoint Protection, las recomendaciones de configuración incorrecta del sistema operativo (Azure Security Benchmark (ASB) y los controles de aplicaciones adaptables.
  • Update Management se está trasladando a una solución sin agente, pero no estará lista por la fecha de amortización de MMA. Los clientes que usan Update Management deben permanecer en MMA hasta que el nuevo servicio Automated Update Manager esté listo.

Pasos siguientes