Compartir a través de

Perspectiva de Azure Well-Architected Framework en Log Analytics

  • Artículo

Well-Architected la funcionalidad y el rendimiento de la carga de trabajo de Framework deben supervisarse de diversas maneras y por diversos motivos. Las áreas de trabajo de Log Analytics de Azure Monitor son el receptor principal de registros y métricas para una gran parte de los datos de supervisión. Las áreas de trabajo admiten varias características de Azure Monitor, incluidas las consultas ad hoc, las visualizaciones y las alertas. Para conocer los principios generales de supervisión, consulte Guía de supervisión y diagnóstico. La guía presenta principios generales de supervisión. Identifica los diferentes tipos de datos. Identifica el análisis necesario que Admite Azure Monitor y también identifica los datos almacenados en el área de trabajo que habilitan el análisis.

En este artículo se da por supuesto que comprende los principios de diseño del sistema. También necesita un conocimiento práctico de las áreas de trabajo y las características de Log Analytics en Azure Monitor que rellenan los datos operativos de la carga de trabajo. Para obtener más información, vea Información general del área de trabajo de Log Analytics.

Importante

Cómo usar esta guía

Cada sección tiene una lista de comprobación de diseño que presenta áreas arquitectónicas de preocupación junto con estrategias de diseño localizadas en el ámbito de la tecnología.

También se incluyen recomendaciones sobre las funcionalidades tecnológicas o las topologías de implementación que pueden ayudar a materializar esas estrategias. Las recomendaciones no representan una lista exhaustiva de todas las configuraciones disponibles para las áreas de trabajo de Log Analytics y sus recursos relacionados de Azure Monitor. En su lugar, enumeran las recomendaciones clave asignadas a las perspectivas de diseño. Use las recomendaciones para crear la prueba de concepto, diseñar el entorno de supervisión de cargas de trabajo o optimizar la solución de supervisión de cargas de trabajo existente.

Ámbito de la tecnología

Esta guía se centra en las decisiones interrelacionadas para los siguientes recursos de Azure.

  • Áreas de trabajo de Log Analytics
  • Datos del registro operativo de la carga de trabajo
  • Configuración de diagnóstico en los recursos de Azure de la carga de trabajo

Confiabilidad

El propósito del pilar Confiabilidad es proporcionar funcionalidad continua mediante la creación de suficiente resistencia y la capacidad de recuperarse rápidamente de los errores.

Los principios de diseño de confiabilidad proporcionan una estrategia de diseño de alto nivel aplicada para componentes individuales, flujos del sistema y el sistema en su conjunto.

Las situaciones de confiabilidad que se deben tener en cuenta para las áreas de trabajo de Log Analytics son:

  • Disponibilidad del área de trabajo.
  • Protección de los datos recopilados en el caso excepcional de un error en un centro de datos o región de Azure.

Actualmente no hay ninguna característica estándar para la conmutación por error entre áreas de trabajo de diferentes regiones, pero hay estrategias para usar si tiene requisitos concretos para la disponibilidad o el cumplimiento.

Lista de comprobación de diseño para la confiabilidad

Inicie la estrategia de diseño en función de la lista de comprobación de revisión de diseño para confiabilidad y determine su relevancia para los requisitos empresariales, teniendo en cuenta las SKU y las características de las máquinas virtuales (VM) y sus dependencias. Amplíe la estrategia para incluir más enfoques según sea necesario.

  • Revise los límites de servicio de las áreas de trabajo de Log Analytics. La sección límites de servicio le ayuda a comprender las restricciones de recopilación y retención de datos y otros aspectos del servicio. Estos límites le ayudan a determinar cómo diseñar correctamente la estrategia de observabilidad de la carga de trabajo. Asegúrese de revisar los límites del servicio azure Monitor , ya que muchas de las funciones que se describen en ella, como las consultas, trabajan a mano con áreas de trabajo de Log Analytics.
  • Planee la resistencia y la recuperación del área de trabajo. Las áreas de trabajo de Log Analytics son regionales, sin compatibilidad integrada con la redundancia o replicación entre regiones. Además, las opciones de redundancia de zona de disponibilidad están limitadas. Por lo tanto, debe determinar los requisitos de confiabilidad de las áreas de trabajo y la estrategia para cumplir esos objetivos. Los requisitos pueden estipular que el área de trabajo debe ser resistente a errores del centro de datos o a errores regionales, o que podrían estipular que debe poder recuperar los datos en una nueva área de trabajo de una región de conmutación por error. Cada uno de estos escenarios requiere que se pongan en marcha recursos y procesos adicionales para que se realicen correctamente, por lo que se debe tener en cuenta cuidadosamente el equilibrio de los objetivos de confiabilidad con costos y complejidad.
  • Elija las regiones de implementación adecuadas para satisfacer los requisitos de confiabilidad. Implemente el área de trabajo de Log Analytics y los puntos de conexión de recopilación de datos (DCE) ubicados conjuntamente con los componentes de carga de trabajo que emiten datos operativos. La elección de la región adecuada en la que implementar el área de trabajo y los DCE deben estar informados por dónde se implementa la carga de trabajo. Es posible que tenga que sopesar la disponibilidad regional de determinadas funcionalidades de Log Analytics, como los clústeres dedicados, con otros factores más importantes para los requisitos de confiabilidad, costo y rendimiento de la carga de trabajo.
  • Asegúrese de que los sistemas de observabilidad estén en buen estado. Al igual que cualquier otro componente de la carga de trabajo, asegúrese de que los sistemas de supervisión y registro funcionan correctamente. Para ello, habilite las características que envían señales de datos de estado a los equipos de operaciones. Configure señales de datos de estado específicas de las áreas de trabajo de Log Analytics y los recursos asociados.

Recomendaciones de configuración para confiabilidad

Recomendación Prestación
No incluya las áreas de trabajo de Log Analytics en la ruta crítica de la carga de trabajo. Las áreas de trabajo son importantes para un sistema de observabilidad funcional, pero la funcionalidad de la carga de trabajo no debe depender de ellas. Mantener las áreas de trabajo y las funciones asociadas fuera de la ruta crítica de la carga de trabajo minimiza el riesgo de que el sistema de observabilidad afecte a la ejecución en tiempo de ejecución de la carga de trabajo.
Para admitir una alta durabilidad de los datos del área de trabajo, implemente áreas de trabajo de Log Analytics en una región que admita la resistencia de los datos. La resistencia de los datos solo es posible mediante la vinculación del área de trabajo a un clúster dedicado en la misma región. Cuando se usa un clúster dedicado, permite distribuir las áreas de trabajo asociadas entre zonas de disponibilidad, que ofrecen protección contra interrupciones del centro de datos. Si no recopila datos suficientes ahora para justificar un clúster dedicado, esta opción regional preferente admite el crecimiento futuro.
Elija la implementación del área de trabajo en función de la proximidad a la carga de trabajo.

Use puntos de conexión de recopilación de datos (DCE) en la misma región que el área de trabajo de Log Analytics.		 Implemente el área de trabajo en la misma región que las instancias de la carga de trabajo. Tener el área de trabajo y los DCE en la misma región que la carga de trabajo mitiga el riesgo de impactos por interrupciones en otras regiones.

Los DCE los usa el agente de Azure Monitor y la API de ingesta de registros para enviar datos operativos de carga de trabajo a un área de trabajo de Log Analytics. Es posible que necesite varios DCE aunque la implementación solo tenga una sola área de trabajo. Para obtener más información sobre cómo configurar los DCE para su entorno determinado, consulte Configuración de puntos de conexión de recopilación de datos en función de la implementación.<Br
Si la carga de trabajo se implementa en un diseño activo-activo, considere la posibilidad de usar varias áreas de trabajo y DCE distribuidas entre las regiones en las que se implementa la carga de trabajo.

La implementación de áreas de trabajo en varias regiones agrega complejidad al entorno. Equilibre los criterios detallados en Diseño de una arquitectura de área de trabajo de Log Analytics con los requisitos de disponibilidad.
Si necesita que el área de trabajo esté disponible en un error en una región o no recopile suficientes datos para un clúster dedicado, configure la recopilación de datos para enviar datos críticos a varias áreas de trabajo de diferentes regiones. Esta práctica también se conoce como multidifusión de registros.

Por ejemplo, configure dcR para varias áreas de trabajo para el agente de Azure Monitor que se ejecuta en máquinas virtuales. Configure varias opciones de diagnóstico para recopilar registros de recursos de los recursos de Azure y enviar los registros a varias áreas de trabajo.
De este modo, los datos operativos de la carga de trabajo están disponibles en el área de trabajo alternativa si se produce un error regional. Pero sepa que los recursos que dependen de los datos, como alertas y libros, no se replicarán automáticamente en las otras regiones. Considere la posibilidad de almacenar plantillas de Azure Resource Manager (ARM) para recursos de alerta críticos con configuración para el área de trabajo alternativa o implementarlas en todas las regiones, pero deshabilitarlas para evitar alertas redundantes. Ambas opciones admiten la habilitación rápida en un error regional.

Compensación: esta configuración da lugar a cargos de ingesta y retención duplicados, por lo que solo se usa para los datos críticos.
Si necesita que los datos estén protegidos en un centro de datos o en una región con errores, configure la exportación de datos desde el área de trabajo para guardar los datos en una ubicación alternativa.

Esta opción es similar a la anterior de multidifusión de los datos a diferentes áreas de trabajo. Pero esta opción cuesta menos porque los datos adicionales se escriben en el almacenamiento.

Use las opciones de redundancia de Azure Storage, incluido el almacenamiento con redundancia geográfica (GRS) y el almacenamiento con redundancia de zona geográfica (GZRS), para replicar aún más estos datos en otras regiones.

La exportación de datos no proporciona resistencia frente a incidentes que afectan a la canalización de ingesta regional.		 Aunque es posible que los datos históricos del registro operativo no se puedan consultar fácilmente en el estado exportado, garantiza que los datos sobrevivan a una interrupción regional prolongada y se puedan acceder y conservar durante un período prolongado.

Si necesita la exportación de tablas no compatibles con la exportación de datos, puede usar otros métodos de exportación de datos, incluidas Logic Apps, para proteger los datos.

Para que esta estrategia funcione como un plan de recuperación viable, debe tener procesos implementados para volver a configurar la configuración de diagnóstico de los recursos de Azure y en todos los agentes que proporcionan datos. También debe planear rehidratar manualmente los datos exportados en una nueva área de trabajo. Al igual que con la opción descrita anteriormente, también debe definir procesos para esos recursos que dependen de los datos, como alertas y libros.
En el caso de cargas de trabajo críticas que requieren alta disponibilidad, considere la posibilidad de implementar un modelo de área de trabajo federada que use varias áreas de trabajo para proporcionar alta disponibilidad si se produce un error regional. La misión crítica proporciona instrucciones de procedimientos recomendados prescriptivos para diseñar aplicaciones altamente confiables en Azure. La metodología de diseño incluye un modelo de área de trabajo federada con varias áreas de trabajo de Log Analytics para ofrecer alta disponibilidad si hay varios errores, incluido el error de una región de Azure.

Esta estrategia elimina los costos de salida entre regiones y sigue funcionando con un error de región. Pero requiere más complejidad que debe administrar con la configuración y los procesos descritos en Modelado de estado y observabilidad de cargas de trabajo críticas en Azure.
Use la infraestructura como código (IaC) para implementar y administrar las áreas de trabajo y las funciones asociadas. Al automatizar la mayor parte de la implementación y los mecanismos de resistencia y recuperación tan prácticos, garantiza que estas operaciones sean confiables. Ahorra tiempo crítico en los procesos de operaciones y minimiza el riesgo de error humano.

Asegúrese de que las funciones como las consultas de registro guardadas también se definen a través de iaC para recuperarlas en una nueva región si se requiere recuperación.
Diseñe DCR con un único principio de responsabilidad para simplificar las reglas de DCR.

Aunque se puede cargar un DCR con todas las entradas, reglas y destinos para los sistemas de origen, es preferible diseñar reglas centradas estrechamente que se basan en menos orígenes de datos. Use la composición de las asignaciones de reglas para llegar al ámbito de observabilidad deseado para el destino lógico.

Además, minimice la transformación en DCR.		 Cuando se usan DCR centrados estrechamente, se minimiza el riesgo de que una regla tenga un efecto más amplio. Limita el efecto solo al ámbito para el que se creó el DCR. Para más información, consulte Procedimientos recomendados para la creación y administración de reglas de recopilación de datos en Azure Monitor.

Aunque la transformación puede ser eficaz y necesaria en algunas situaciones, puede ser difícil probar y solucionar problemas del trabajo del lenguaje de consulta de palabras clave (KQL) que se está realizando. Cuando sea posible, minimice el riesgo de pérdida de datos al ingerir los datos sin procesar y controlar las transformaciones de bajada en el momento de la consulta.
Al establecer un límite diario o una directiva de retención, asegúrese de mantener los requisitos de confiabilidad mediante la ingesta y retención de los registros que necesita. Un límite diario detiene la recopilación de datos de un área de trabajo una vez alcanzada una cantidad especificada, lo que le ayuda a mantener el control sobre el volumen de ingesta. Pero solo use esta característica después de una planeación cuidadosa. Asegúrese de que el límite diario no se alcance con regularidad. Si esto sucede, el límite se establece demasiado restrictivamente. Debe volver a configurar el límite diario para que no se pierdan señales críticas procedentes de la carga de trabajo.

Del mismo modo, asegúrese de abordar cuidadosamente y cuidadosamente la reducción de la directiva de retención de datos para asegurarse de que no pierde accidentalmente los datos críticos.
Use La información del área de trabajo de Log Analytics para realizar un seguimiento del volumen de ingesta, los datos ingeridos frente al límite de datos, los orígenes de registro no responde y las consultas con errores entre otros datos. Cree alertas de estado de mantenimiento para notificarle de forma proactiva si un área de trabajo deja de estar disponible debido a un error regional o de un centro de datos. Esta estrategia garantiza que puede supervisar correctamente el estado de las áreas de trabajo y actuar proactivamente si el estado está en riesgo de degradarse. Al igual que cualquier otro componente de la carga de trabajo, es fundamental que conozca las métricas de estado y pueda identificar tendencias para mejorar la confiabilidad a lo largo del tiempo.

Azure Policy

Azure no ofrece directivas relacionadas con la confiabilidad de las áreas de trabajo de Log Analytics. Puede crear directivas personalizadas para crear barreras de cumplimiento en torno a las implementaciones del área de trabajo, como asegurarse de que las áreas de trabajo están asociadas a un clúster dedicado.

Aunque no está relacionado directamente con la confiabilidad de las áreas de trabajo de Log Analytics, hay directivas de Azure para casi todos los servicios disponibles. Las directivas garantizan que la configuración de diagnóstico esté habilitada para ese servicio y compruebe que los datos de registro del servicio fluyen a un área de trabajo de Log Analytics. Todos los servicios de la arquitectura de carga de trabajo deben enviar sus datos de registro a un área de trabajo de Log Analytics para sus propias necesidades de confiabilidad y las directivas pueden ayudar a aplicarlos. Del mismo modo, existen directivas para garantizar que las plataformas basadas en agentes, como las máquinas virtuales y Kubernetes, tengan instalado el agente.

Azure Advisor

Azure no ofrece recomendaciones de Azure Advisor relacionadas con la confiabilidad de las áreas de trabajo de Log Analytics.

Seguridad

El propósito del pilar seguridad es proporcionar garantías de confidencialidad, integridad y disponibilidad a la carga de trabajo.

Los principios de diseño de seguridad proporcionan una estrategia de diseño de alto nivel para lograr estos objetivos aplicando enfoques al diseño técnico en torno a la solución de supervisión y registro.

Lista de comprobación de diseño para seguridad

Inicie la estrategia de diseño en función de la lista de comprobación de revisión de diseño de Seguridad e identifique vulnerabilidades y controles para mejorar la posición de seguridad. Amplíe la estrategia para incluir más enfoques según sea necesario.

  • Revise los temas Línea base de seguridad de Azure Monitor y Administración del acceso a áreas de trabajo de Log Analytics. En estos temas se proporcionan instrucciones sobre los procedimientos recomendados de seguridad.
  • Implemente las áreas de trabajo con la segmentación como principio de piedra angular. Implemente la segmentación en los niveles de red, datos y acceso. La segmentación ayuda a garantizar que las áreas de trabajo están aisladas en el grado adecuado y están mejor protegidas contra el acceso no autorizado al mayor grado posible, a la vez que cumplen los requisitos empresariales de confiabilidad, optimización de costos, excelencia operativa y eficiencia del rendimiento.
  • Asegúrese de que puede auditar las actividades de lectura y escritura del área de trabajo y las identidades asociadas. Los atacantes pueden beneficiarse de la visualización de registros operativos. Una identidad en peligro puede provocar ataques por inyección de registros. Habilite la auditoría de las operaciones que se ejecutan desde Azure Portal o mediante interacciones de API y los usuarios asociados. Si no está configurado para auditar el área de trabajo, es posible que ponga a su organización en riesgo de incumplimiento de los requisitos de cumplimiento.
  • Implemente controles de red sólidos. Ayuda a proteger el acceso de red al área de trabajo y a los registros a través del aislamiento de red y las funciones de firewall. Los controles de red insuficientemente configurados podrían poner en riesgo el acceso a los actores no autorizados o malintencionados.
  • Determine qué tipos de datos necesitan inmutabilidad o retención a largo plazo. Los datos de registro deben tratarse con el mismo rigor que los datos de carga de trabajo dentro de los sistemas de producción. Incluya datos de registro en las prácticas de clasificación de datos para asegurarse de que está almacenando correctamente los datos de registro confidenciales según sus requisitos de cumplimiento.
  • Proteja los datos de registro en reposo a través del cifrado. La segmentación por sí sola no protegerá completamente la confidencialidad de los datos de registro. Si se produce un acceso sin procesar no autorizado, tener los datos de registro cifrados en reposo ayuda a evitar que los actores incorrectos usen esos datos fuera del área de trabajo.
  • Proteja los datos de registro confidenciales a través de ofuscación. Al igual que los datos de carga de trabajo que residen en sistemas de producción, debe tomar medidas adicionales para asegurarse de que la confidencialidad se conserva para la información confidencial que podría estar presente intencionada o involuntariamente en los registros operativos. Al usar métodos de ofuscación, le ayuda a ocultar los datos de registro confidenciales de los ojos no autorizados.

Recomendaciones de configuración para seguridad

Recomendación Prestación
Use claves administradas por el cliente si necesita su propia clave de cifrado para proteger los datos y las consultas guardadas en las áreas de trabajo.

Azure Monitor garantiza que todos los datos y las consultas guardadas se cifren en reposo mediante claves administradas por Microsoft (MMK). Si necesita su propia clave de cifrado y recopila suficientes datos para un clúster dedicado, use la clave administrada por el cliente. Puede cifrar los datos mediante su propia clave en Azure Key Vault, para controlar el ciclo de vida de la clave y la capacidad de revocar el acceso a los datos.

Si usa Microsoft Sentinel, asegúrese de que está familiarizado con las consideraciones de Configuración de la clave administrada por el cliente de Microsoft Sentinel.		 Esta estrategia le permite cifrar los datos mediante su propia clave en Azure Key Vault, para controlar el ciclo de vida de la clave y la capacidad de revocar el acceso a los datos.
Configure la auditoría de consultas de registro para realizar un seguimiento de las consultas que ejecutan los usuarios.

Configure los registros de auditoría de cada área de trabajo que se enviarán al área de trabajo local o consolide en un área de trabajo de seguridad dedicada si separa los datos operativos y de seguridad. Use la información del área de trabajo de Log Analytics para revisar periódicamente estos datos. Considere la posibilidad de crear reglas de alertas de consulta de registro para notificarle de forma proactiva si los usuarios no autorizados intentan ejecutar consultas.		 La auditoría de consultas de registro registra los detalles de cada ejecución de consulta en un área de trabajo. Trate estos datos de auditoría como datos de seguridad y proteja correctamente la tabla LAQueryLogs. Esta estrategia refuerza su posición de seguridad ayudando a garantizar que el acceso no autorizado se detecte inmediatamente si alguna vez ocurre.
Ayude a proteger el área de trabajo a través de las medidas de segmentación y redes privadas.

Use la funcionalidad private link para limitar las comunicaciones entre los orígenes de registro y las áreas de trabajo a redes privadas.		 Al usar private link, también le permite controlar qué redes virtuales pueden acceder a un área de trabajo determinada, lo que refuerza aún más la seguridad a través de la segmentación.
Use Microsoft Entra ID en lugar de claves de API para el acceso a la API del área de trabajo cuando esté disponible. El acceso basado en claves de API a las API de consulta no deja una pista de auditoría por cliente. Use el acceso basado en id. de Entra con ámbito suficiente para que pueda auditar correctamente el acceso mediante programación.
Configure el acceso para distintos tipos de datos en el área de trabajo necesaria para distintos roles de la organización.

Establezca el modo de control de acceso del área de trabajo en Usar permisos de recurso o área de trabajo. Este control de acceso permite a los propietarios de recursos usar el contexto de recursos para acceder a sus datos sin conceder acceso explícito al área de trabajo.

Use RBAC de nivel de tabla para los usuarios que requieren acceso a un conjunto de tablas en varios recursos.		 Esta configuración simplifica la configuración del área de trabajo y ayuda a garantizar que los usuarios no puedan acceder a los datos operativos que no deben.

Asigne el rol integrado adecuado para conceder permisos de área de trabajo a los administradores en el nivel de suscripción, grupo de recursos o área de trabajo en función de su ámbito de responsabilidades.

Los usuarios con permisos de tabla tienen acceso a todos los datos de la tabla independientemente de sus permisos de recursos.

Consulte Administración del acceso a áreas de trabajo de Log Analytics para obtener más información sobre las distintas opciones para conceder acceso a los datos del área de trabajo.
Exporte los registros que requieren retención a largo plazo o inmutabilidad.

Use la exportación de datos para enviar datos a una cuenta de Azure Storage con directivas de inmutabilidad para ayudar a protegerse contra la manipulación de datos. No todos los tipos de registro tienen la misma relevancia para el cumplimiento, la auditoría o la seguridad, por lo que determinan los tipos de datos específicos que se deben exportar.		 Puede recopilar datos de auditoría en el área de trabajo sujetos a normativas que requieran su retención a largo plazo. Los datos de un área de trabajo de Log Analytics no se pueden modificar, pero se pueden purgar. Exportar una copia de los datos operativos con fines de retención le permite crear una solución que cumpla los requisitos de cumplimiento.
Determine una estrategia para filtrar u ofuscar datos confidenciales en el área de trabajo.

Es posible que recopile datos que incluyan información confidencial. Filtre los registros que no se deben recopilar mediante la configuración del origen de datos concreto. Use una transformación si solo se deben quitar u ofuscar columnas concretas de los datos.

Si tiene estándares que requieren que los datos originales no se modifican, puede usar el literal "h" en las consultas KQL para ofuscar los resultados de la consulta mostrados en los libros.		 Ofuscar o filtrar datos confidenciales en el área de trabajo le ayuda a mantener la confidencialidad de la información confidencial. En muchos casos, los requisitos de cumplimiento dictan las formas en que puede controlar la información confidencial. Esta estrategia le ayuda a cumplir los requisitos de forma proactiva.

Azure Policy

Azure ofrece directivas relacionadas con la seguridad de las áreas de trabajo de Log Analytics para ayudar a aplicar la posición de seguridad deseada. Algunos ejemplos de estas directivas son:

Azure también ofrece numerosas directivas para ayudar a aplicar la configuración de vínculo privado, como las áreas de trabajo de Log Analytics, deben bloquear la ingesta de registros y realizar consultas desde redes públicas o incluso configurar la solución a través de directivas de DINE, como Configure Azure Monitor Private Link Scope para usar zonas DNS privadas.

Azure Advisor

Azure no ofrece recomendaciones de Azure Advisor relacionadas con la seguridad de las áreas de trabajo de Log Analytics.

Optimización de costos

La optimización de costos se centra en detectar patrones de gasto, priorizar las inversiones en áreas críticas y optimizar en otros usuarios para satisfacer el presupuesto de la organización mientras cumple los requisitos empresariales.

Los principios de diseño de optimización de costos proporcionan una estrategia de diseño de alto nivel para lograr esos objetivos empresariales. También le ayudan a compensar los inconvenientes según sea necesario en el diseño técnico relacionado con la solución de supervisión y registro.

Para más información sobre cómo se calculan los cargos de datos para las áreas de trabajo de Log Analytics, consulte Cálculos y opciones de costos de los registros de Azure Monitor.

Lista de comprobación de diseño para la optimización de costos

Inicie la estrategia de diseño en función de la lista de comprobación de revisión de diseño para la optimización de costos para las inversiones y ajuste el diseño para que la carga de trabajo esté alineada con el presupuesto asignado para la carga de trabajo. El diseño debe usar las funcionalidades adecuadas de Azure, supervisar las inversiones y encontrar oportunidades para optimizar con el tiempo.

  • Realizar ejercicios de modelado de costos. Estos exercizes le ayudan a comprender los costos actuales del área de trabajo y a prever los costos en relación con el crecimiento del área de trabajo. Analice las tendencias de crecimiento de la carga de trabajo y asegúrese de comprender los planes de expansión de la carga de trabajo para predecir correctamente los costos futuros de registro operativo.
  • Elija el modelo de facturación adecuado. Use el modelo de costos para determinar el mejor modelo de facturación para su escenario. La forma en que usa las áreas de trabajo actualmente y cómo planea usarlas a medida que evoluciona la carga de trabajo determina si un modelo de nivel de pago por uso o un modelo de nivel de compromiso es la mejor opción para su escenario.

    Recuerde que puede elegir diferentes modelos de facturación para cada área de trabajo y puede combinar los costos del área de trabajo en determinados casos, por lo que puede ser granular en el análisis y la toma de decisiones.
  • Recopile solo la cantidad correcta de datos de registro. Realice análisis programados periódicamente de la configuración de diagnóstico en los recursos, la configuración de reglas de recopilación de datos y el registro de código de aplicación personalizado para asegurarse de que no recopila datos de registro innecesarios.
  • Trate los entornos que no son de producción de forma diferente a la producción. Revise los entornos que no son de producción para asegurarse de que ha configurado correctamente las directivas de retención y la configuración de diagnóstico. A menudo, estos pueden ser significativamente menos sólidos que la producción, especialmente para entornos de desarrollo/pruebas o espacio aislado.

Recomendaciones de configuración para la optimización de costos

Recomendación Prestación
Configure el plan de tarifa para la cantidad de datos que normalmente recopila cada área de trabajo de Log Analytics. De forma predeterminada, las áreas de trabajo de Log Analytics usan precios de pago por uso sin volumen de datos mínimo. Si recopila suficientes datos, puede reducir significativamente el costo mediante un nivel de compromiso, lo que le permite confirmar un mínimo diario de datos recopilados a cambio de una tasa más baja. Si recopila suficientes datos entre áreas de trabajo de una sola región, puede vincularlos a un clúster dedicado y combinar su volumen recopilado mediante los precios del clúster.

Para más información sobre los niveles de compromiso y las instrucciones sobre cómo determinar cuál es más adecuado para el nivel de uso, consulte Cálculos y opciones de costos de los registros de Azure Monitor. Para ver los costos estimados del uso en distintos planes de tarifa, consulte Uso y costos estimados.
Configurar la retención y el archivado de datos. Hay un cargo por conservar los datos en un área de trabajo de Log Analytics más allá del valor predeterminado de 31 días. Es de 90 días si Microsoft Sentinel está habilitado en el área de trabajo y 90 días para los datos de Application Insights. Tenga en cuenta sus requisitos particulares para disponer de datos fácilmente disponibles para consultas de registros. Puede reducir significativamente el costo configurando registros archivados. Los registros archivados le permiten conservar los datos durante hasta siete años y seguir accediendo a ellos ocasionalmente. Para acceder a los datos, use trabajos de búsqueda o restaure un conjunto de datos en el área de trabajo.
Si usa Microsoft Sentinel para analizar los registros de seguridad, considere la posibilidad de emplear un área de trabajo independiente para almacenar esos registros. Cuando se usa un área de trabajo dedicada para los datos de registro que usa siEM, puede ayudarle a controlar los costos. Las áreas de trabajo que usa Microsoft Sentinel están sujetas a precios de Microsoft Sentinel. Los requisitos de seguridad dictan los tipos de registros necesarios para incluirse en la solución SIEM. Es posible que pueda excluir los registros operativos, que se cobrarán en los precios estándar de Log Analytics si están en un área de trabajo independiente.
Configurar las tablas usadas para la depuración, la solución de problemas y la auditoría como registros básicos. Las tablas de un área de trabajo de Log Analytics configurada para los registros básicos tienen un costo de ingesta menor, pero, a cambio, las características son limitadas y existe un cargo por las consultas de registro. Si consulta estas tablas con poca frecuencia y no las usa para alertas, este costo de consulta puede ser más que compensado por el costo reducido de ingestión.
Limite la recopilación de datos de orígenes de datos para el área de trabajo. El factor principal para el costo de Azure Monitor es la cantidad de datos que se recopilan en el área de trabajo de Log Analytics. Asegúrese de que no recopile más datos de los que necesita para evaluar el estado y el rendimiento de los servicios y las aplicaciones. Para cada recurso, seleccione las categorías adecuadas para la configuración de diagnóstico que configure para proporcionar la cantidad de datos operativos que necesita. Le ayuda a administrar correctamente la carga de trabajo y no a administrar los datos omitidos.

Puede haber un equilibrio entre el costo y los requisitos de supervisión. Por ejemplo, es posible que pueda detectar un problema de rendimiento más rápidamente con una alta frecuencia de muestreo, pero es posible que desee una tasa de muestreo más baja para ahorrar costos. La mayoría de los entornos tienen varios orígenes de datos con diferentes tipos de recopilación, por lo que debe equilibrar sus requisitos concretos con los objetivos de costo para cada uno. Consulte Optimización de costos en Azure Monitor para obtener recomendaciones sobre cómo configurar la recopilación para distintos orígenes de datos.
Analice periódicamente los datos de uso del área de trabajo para identificar tendencias y anomalías.

Use la información sobre el área de trabajo de Log Analytics para revisar periódicamente la cantidad de datos recopilados en su área de trabajo. Analice aún más la recopilación de datos mediante métodos de Análisis del uso en el área de trabajo de Log Analytics para determinar si hay otras configuraciones que pueden reducir aún más el uso.		 Al ayudarle a comprender la cantidad de datos recopilados por diferentes orígenes, identifica anomalías y tendencias ascendentes en la recopilación de datos que podrían dar lugar a un exceso de costos. Esta consideración es importante al agregar un nuevo conjunto de orígenes de datos a la carga de trabajo. Por ejemplo, si agrega un nuevo conjunto de máquinas virtuales, habilite la nueva configuración de diagnóstico de Azure en un servicio o cambie los niveles de registro de la aplicación.
Creación de una alerta cuando la recopilación de datos es mayor. Para evitar facturas inesperadas, debería recibir una notificación proactiva cada vez que experimente un uso excesivo. La notificación le permite solucionar posibles anomalías antes del final del período de facturación.
Considerar un límite diario como medida preventiva para asegurarse de que no se excede un presupuesto determinado. Un límite diario desactiva la recopilación de datos en un área de trabajo de Log Analytics durante el resto del día después de alcanzar el límite configurado. No use esta práctica como método para reducir los costos como se describe en Cuándo usar un límite diario, sino para evitar la ingesta descontrolada debido a una configuración incorrecta o abuso.

Si establece un límite diario, cree una alerta cuando se alcance el límite. Asegúrese de crear también una regla de alerta cuando se alcance algún porcentaje. Por ejemplo, puede establecer una regla de alerta para cuando se alcance la capacidad del 90 %. Esta alerta le ofrece la oportunidad de investigar y abordar la causa del aumento de los datos antes de que el límite cierre la recopilación de datos críticos de la carga de trabajo.

Azure Policy

Azure no ofrece directivas relacionadas con la optimización de costos de las áreas de trabajo de Log Analytics. Puede crear directivas personalizadas para crear barreras de cumplimiento en torno a las implementaciones del área de trabajo, como asegurarse de que las áreas de trabajo contengan la configuración de retención correcta.

Azure Advisor

Azure Advisor realiza recomendaciones para mover tablas específicas de un área de trabajo al plan de datos de registro básico de bajo costo para las tablas que reciben un volumen de ingesta relativamente alto. Comprenda las limitaciones mediante el uso de registros básicos antes de cambiar. Para obtener más información, vea ¿Cuándo debo usar registros básicos?. Azure Advisor también puede recomendar cambiar el plan de compromiso de tarifa para todo el área de trabajo en función del volumen de uso general.

Excelencia operativa

La excelencia operativa se centra principalmente en los procedimientos para las prácticas de desarrollo, la observabilidad y la administración de versiones.

Los principios de diseño de excelencia operativa proporcionan una estrategia de diseño de alto nivel para lograr esos objetivos hacia los requisitos operativos de la carga de trabajo.

Lista de comprobación de diseño para la excelencia operativa

Inicie la estrategia de diseño en función de la lista de comprobación de revisión de diseño para la excelencia operativa para definir procesos de observabilidad, pruebas e implementación relacionados con las áreas de trabajo de Log Analytics.

  • Use la infraestructura como código (IaC) para todas las funciones relacionadas con las áreas de trabajo de Log Analytics de la carga de trabajo. Minimice el riesgo de error humano que puede producirse con la administración manual y el funcionamiento de la recopilación de registros, la ingesta, el almacenamiento y las funciones de consulta, incluidas las consultas guardadas y los paquetes de consultas, mediante la automatización de tantas de esas funciones como sea posible a través del código. Además, incluya alertas que notifiquen los cambios de estado de mantenimiento y la configuración de la configuración de diagnóstico para los recursos que envían registros a las áreas de trabajo en el código iaC. Incluya el código con el otro código relacionado con la carga de trabajo para asegurarse de que las prácticas de implementación seguras se mantienen para la administración de las áreas de trabajo.
  • Asegúrese de que las áreas de trabajo estén en buen estado y reciba una notificación cuando surjan problemas. Al igual que cualquier otro componente de la carga de trabajo, las áreas de trabajo pueden encontrar problemas. Los problemas pueden costar tiempo y recursos valiosos para solucionar problemas y resolverlos y, posiblemente, dejar que el equipo no tenga en cuenta el estado de la carga de trabajo de producción. La capacidad de supervisar de forma proactiva las áreas de trabajo y mitigar posibles problemas ayuda a los equipos de operaciones a minimizar el tiempo que dedican a solucionar problemas y solucionarlos.
  • Separe la producción de las cargas de trabajo que no son de producción. Evite la complejidad innecesaria que puede provocar un trabajo adicional para un equipo de operaciones mediante el uso de áreas de trabajo diferentes para el entorno de producción que los que usan los entornos que no son de producción. Los datos entrantes también pueden provocar confusión, ya que es posible que las actividades de prueba parezcan ser eventos en producción.
  • Preferir las herramientas y funciones integradas en soluciones que no son de Microsoft Use herramientas integradas para ampliar la funcionalidad de los sistemas de supervisión y registro. Es posible que tenga que poner en marcha configuraciones adicionales para admitir requisitos como la capacidad de recuperación o la soberanía de datos que no están disponibles de fábrica con áreas de trabajo de Log Analytics. En estos casos, siempre que sea práctico, use herramientas nativas de Azure o Microsoft para mantener el número de herramientas que su organización debe admitir en un mínimo.
  • Tratar las áreas de trabajo como componentes estáticos en lugar de efímeros Al igual que otros tipos de almacenes de datos, las áreas de trabajo no deben tenerse en cuenta entre los componentes efímeros de la carga de trabajo. En general, Well-Architected Framework favorece la infraestructura inmutable y la capacidad de reemplazar rápidamente y fácilmente los recursos de la carga de trabajo como parte de las implementaciones. Pero la pérdida de datos del área de trabajo puede ser grave e irreversible. Por este motivo, deje las áreas de trabajo fuera de los paquetes de implementación que reemplacen la infraestructura durante las actualizaciones y solo realice actualizaciones en contexto en las áreas de trabajo.
  • Asegúrese de que el personal de operaciones está entrenado en Lenguaje de consulta Kusto Entrenamiento del personal para crear o modificar consultas cuando sea necesario. Si los operadores no pueden escribir o modificar consultas, puede ralentizar la solución de problemas crítica u otras funciones, ya que los operadores deben confiar en otros equipos para que funcionen para ellas.

Recomendaciones de configuración para la excelencia operativa

Recomendación Prestación
Diseñe una estrategia de área de trabajo para satisfacer sus requisitos empresariales.

Consulte Diseño de una arquitectura de área de trabajo de Log Analytics para obtener instrucciones sobre cómo diseñar una estrategia para las áreas de trabajo de Log Analytics. Incluya cuántos crear y dónde colocarlos.

Si necesita que la carga de trabajo use una oferta de equipo de plataforma centralizada, asegúrese de establecer todo el acceso operativo necesario. Además, construya alertas para asegurarse de que se cumplen las necesidades de observabilidad de la carga de trabajo.		 Un único o al menos un número mínimo de áreas de trabajo maximiza la eficacia operativa de la carga de trabajo. Limita la distribución de los datos operativos y de seguridad, aumenta la visibilidad de posibles problemas, facilita la identificación de patrones y minimiza los requisitos de mantenimiento.

Es posible que tenga requisitos para varias áreas de trabajo, como varios inquilinos, o que necesite áreas de trabajo en varias regiones para admitir los requisitos de disponibilidad. Por lo tanto, asegúrese de que tiene los procesos adecuados para administrar esta mayor complejidad.
Use la infraestructura como código (IaC) para implementar y administrar las áreas de trabajo y las funciones asociadas. Use la infraestructura como código (IaC) para definir los detalles de las áreas de trabajo en plantillas de ARM, Azure BICEP o Terraform. Permite usar los procesos de DevOps existentes para implementar nuevas áreas de trabajo y Azure Policy para aplicar su configuración.

Colocar todo el código iaC con el código de la aplicación ayuda a garantizar que se mantienen los procedimientos de implementación seguros para todas las implementaciones.
Use la información del área de trabajo de Log Analytics para realizar un seguimiento del estado y el rendimiento de las áreas de trabajo de Log Analytics y crear alertas significativas y accionables para recibir notificaciones proactivas de problemas operativos.

En el artículo Información sobre el área de trabajo de Log Analytics se proporciona una vista unificada del uso, el rendimiento, el estado, los agentes, las consultas y los registros de cambios de todas las áreas de trabajo.

Cada área de trabajo tiene una tabla de operaciones que registra actividades importantes que afectan al área de trabajo.		 Revise la información que proporciona Log Analytics insights con regularidad para realizar un seguimiento del estado y el funcionamiento de cada una de las áreas de trabajo. Al usar esta información, le permite crear visualizaciones fáciles de entender, como paneles o informes que las operaciones y las partes interesadas pueden usar para realizar un seguimiento del estado de las áreas de trabajo.

Cree reglas de alertas basadas en esta tabla para recibir notificaciones proactivas cuando se produzca un problema operativo. Puede usar alertas recomendadas para el área de trabajo para simplificar cómo se crean las reglas de alerta más críticas.
Practique la mejora continua revisando con frecuencia la configuración de diagnóstico de Azure en los recursos, las reglas de recopilación de datos y los detalles del registro de aplicaciones.

Asegúrese de optimizar la estrategia de recopilación de registros a través de revisiones frecuentes de la configuración de recursos. Desde el punto de vista operativo, busque reducir el ruido de los registros centrándose en esos registros que proporcionan información útil sobre el estado de mantenimiento de un recurso.		 Mediante la optimización de esta manera, permite a los operadores investigar y solucionar problemas cuando surjan o realizar otras tareas rutinarias, improvisadas o de emergencia.

Cuando haya nuevas categorías de diagnóstico disponibles para un tipo de recurso, revise los tipos de registros que se emiten con esta categoría para comprender si habilitarlas puede ayudarle a optimizar la estrategia de recopilación. Por ejemplo, una nueva categoría podría ser un subconjunto de un conjunto mayor de actividades que se están capturando. El nuevo subconjunto puede permitirle reducir el volumen de registros que entran centrándose en las actividades que son importantes para que las operaciones realicen un seguimiento.

Azure Policy y Azure Advisor

Azure no ofrece ninguna directiva ni recomendaciones de Azure Advisor relacionadas con la excelencia operativa de las áreas de trabajo de Log Analytics.

Eficiencia del rendimiento

La eficiencia del rendimiento consiste en mantener la experiencia del usuario incluso cuando hay un aumento de la carga mediante la administración de la capacidad. La estrategia incluye el escalado de recursos, la identificación y optimización de posibles cuellos de botella y la optimización para lograr un rendimiento máximo.

Los principios de diseño de eficiencia del rendimiento proporcionan una estrategia de diseño de alto nivel para lograr esos objetivos de capacidad con respecto al uso esperado.

Lista de comprobación de diseño para la eficiencia del rendimiento

Inicie la estrategia de diseño en función de la lista de comprobación de revisión de diseño para mejorar la eficiencia del rendimiento para definir una línea base para las áreas de trabajo de Log Analytics y las funciones asociadas.

  • Familiarícese con los aspectos básicos de la latencia de ingesta de datos de registro en Azure Monitor. Hay varios factores que contribuyen a la latencia al ingerir registros en las áreas de trabajo. Muchos de estos factores son inherentes a la plataforma de Azure Monitor. Comprender los factores y el comportamiento de latencia normal pueden ayudarle a establecer las expectativas adecuadas en los equipos de operaciones de carga de trabajo.
  • Separe las cargas de trabajo de producción y no producción. Las áreas de trabajo específicas de producción mitigan cualquier sobrecarga que puedan presentar los sistemas que no son de producción. Reduce la superficie general de las áreas de trabajo, lo que requiere menos recursos para controlar el procesamiento de datos de registro.
  • Elija las regiones de implementación adecuadas para satisfacer los requisitos de rendimiento. Implemente el área de trabajo de Log Analytics y los puntos de conexión de recopilación de datos (DCE) cerca de la carga de trabajo. La elección de la región adecuada en la que implementar el área de trabajo y los DCE deben estar informados por dónde se implementa la carga de trabajo. Es posible que tenga que sopesar las ventajas de rendimiento de implementar las áreas de trabajo y los DCE en la misma región que la carga de trabajo en los requisitos de confiabilidad si ya ha implementado la carga de trabajo en una región que no puede admitir esos requisitos para los datos de registro.

Recomendaciones de configuración para la eficiencia del rendimiento

Recomendación Prestación
Configure la auditoría de consultas de registro y use la información sobre el área de trabajo de Log Analytics para identificar consultas lentas e ineficaces.

La auditoría de consultas de registro almacena el tiempo de proceso necesario para ejecutar cada consulta y el tiempo hasta que se devuelven los resultados. La Información sobre el área de trabajo de Log Analytics usa estos datos para enumerar consultas potencialmente ineficaces en el área de trabajo. Considere la posibilidad de volver a escribir estas consultas para mejorar su rendimiento. Consulte Optimización de consultas de registro en Azure Monitor para obtener instrucciones sobre cómo optimizar las consultas de registro.		 Las consultas optimizadas devuelven resultados más rápidos y usan menos recursos en el back-end, lo que hace que los procesos que dependen de esas consultas también sean más eficaces.
Descripción de los límites de servicio para las áreas de trabajo de Log Analytics.

En determinadas implementaciones de tráfico elevado, puede encontrarse con límites de servicio que afectan al rendimiento y al diseño de área de trabajo o carga de trabajo. Por ejemplo, la API de consulta limita el número de registros y volúmenes de datos devueltos por una consulta. La API de ingesta de registros limita el tamaño de cada llamada API.

Para obtener una lista completa de los límites y límites de áreas de trabajo de Azure Monitor y Log Analytics específicos del propio área de trabajo, consulte Límites de servicio de Azure Monitor.		 Comprender los límites que podrían afectar al rendimiento del área de trabajo le ayuda a diseñar adecuadamente para mitigarlos. Puede decidir usar varias áreas de trabajo para evitar alcanzar los límites asociados a una sola área de trabajo.

Sopesa las decisiones de diseño para mitigar los límites de servicio frente a los requisitos y objetivos de otros pilares.
Cree DCR específicos de los tipos de origen de datos dentro de uno o varios ámbitos de observabilidad definidos. Cree DCR independientes para el rendimiento y los eventos para optimizar el uso del proceso de procesamiento de back-end. Cuando se usan DCR independientes para el rendimiento y los eventos, ayuda a mitigar el agotamiento de recursos de back-end. Al tener DCR que combinan eventos de rendimiento, obliga a todas las máquinas virtuales asociadas a transferir, procesar y ejecutar configuraciones que podrían no ser aplicables según el software instalado. Es posible que se produzca un consumo excesivo de recursos de proceso y errores en el procesamiento de una configuración y que el agente de Azure Monitor (AMA) deje de responder.

Azure Policy y Azure Advisor

Azure no ofrece ninguna directiva ni recomendaciones de Azure Advisor relacionadas con el rendimiento de las áreas de trabajo de Log Analytics.

Paso siguiente