Hola a todos, y bienvenidos de nuevo.
Ahora, en el video de hoy, vamos a hablar sobre el registro centralizado.
Ahora, en el entorno de producción, tener un registro centralizado es extremadamente importante.
En caso contrario, si no lo tienes y se produce alguna incidencia, puede ser cualquier incidencia
relacionada con la fiabilidad, seguridad, etc. Cuando ocurre un incidente, se ha observado que el equipo tendrá que saltar
a través de múltiples cuentas, múltiples servidores para obtener el archivo de registro que puede brindar detalles relacionados con ese incidente específico.
En ocasiones también se ha observado que debido al espacio en disco que estaba lleno en ese servidor, nunca se generaba
el archivo de registro.
Entonces, para superar esos problemas, es importante que haya configurado el registro centralizado.
Y en el video de hoy vamos a ver este tipo de arquitectura ahora en general en las organizaciones, específicamente
en estas etapas donde siguen la arquitectura basada en múltiples cuentas.
El monitoreo de registros es una de las cosas más importantes de las que tendrá que encargarse.
Ahora, digamos que en este diagrama hay tres cuentas de ocho lugares ahora en su lugar.
Muchos de los servicios generan su propio conjunto de archivos de registro.
La nube genera su archivo de registro y lo guía para generar el archivo de registro.
Si tiene un conjunto de dos instancias fáciles, habrá registros, luego habrá registros
relacionados con la configuración, etc. Así que esta es una parte y lo mismo se aplica a otras cuentas también.
Ahora, en general, muchas organizaciones, lo que hacen cuando tienen una solución de monitoreo centralizada
como Splunk, asocian Splunk con todas y cada una de las cuentas individuales para obtener los registros de todos y cada uno de los
servicios individuales.
Entonces, Splunk primero se conecta a la cuenta de desarrollo, obtiene los registros del rastro de la nube.
El servicio de guardia es de dos instancias y así sucesivamente, lo mismo para la puesta en escena, lo mismo para la producción y así sucesivamente.
Entonces, aunque esto parece ser un buen punto de partida, pero cuando tiene cientos de cuentas de bases
de datos, esta no es la mejor de las arquitecturas que se pueden usar.
Ahora, una de las arquitecturas recomendadas para el registro es tener una cuenta de registro centralizada.
Entonces, lo que realmente sucede aquí es que cada cuenta individual.
Entonces en este caso tienes una cuenta, tienes una cuenta, B, etc. Cada cuenta está configurada para enviar sus archivos
de registro a una cuenta de registro central.
Entonces, en la cuenta, es posible que tenga un servicio en la nube habilitado, la nube enviará los registros a la cuenta de la cuenta de registro
central.
Tendremos un servicio de configuración habilitado nuevamente que se enviará a la cuenta de registro central y a su herramienta de monitoreo de
registro como Splunk.
Esta herramienta de monitoreo de registro se asociará con una sola cuenta, en este caso la cuenta de registro
del centro, y obtendrá todos los datos desde aquí.
Entonces, de esta manera, incluso si tiene 100 cuentas de base de datos, se vuelve mucho más simple porque todas esas cuentas
enviarán los registros a una cuenta de registro central aquí.
Ahora, cuando tiene una arquitectura basada en registro, hay ciertas consideraciones que deberá
tener en cuenta.
La primera consideración es que tendrá que definir un requisito de retención de registros y las políticas de ciclo de vida desde
el principio.
Ahora, generalmente en organizaciones más grandes, el tamaño del registro sería de terabytes.
Entonces, ¿necesita todos los terabytes de datos en su depósito S3 o también puede moverlos a Glacier?
Porque si almacena tantos datos en S3, su factura también será enorme.
Muchas de las organizaciones tienen un requisito de retención de registros.
Por ejemplo, durante los primeros tres meses los registros serán cubo necesario.
Después de tres meses, todos los troncos irán al glaciar y así sucesivamente.
Entonces, todo eso depende nuevamente de las políticas de retención de registros en su organización si necesita incorporar herramientas
y funciones para automatizar las políticas de ciclo de vida.
Entonces, en caso de que esté usando S3, esto es mucho más sencillo.
La tercera parte importante es que debe automatizar la instalación y configuración del envío de registros.
Imagine, por ejemplo, supongamos que lanza diez nuevas instancias fáciles de usar.
Ahora, después de ese SC, se lanzan dos instancias.
También debe asegurarse de que todas esas instancias fáciles de usar envíen inmediatamente todos los registros
a la cuenta de registro centralizada.
Entonces, tal vez en el ejército mismo podría tener su agente Splunk o un agente de registro preconfigurado.
Entonces, cada vez que se inicia la instancia, el agente seguirá adelante y comenzará a enviar los registros a la cuenta central.
Y la cuarta consideración es asegurarse de que la solución admita entornos híbridos para satisfacer las necesidades.
No es necesario que todas las cuentas estén basadas en una base de datos.
Puede pasar.
Algunas cuentas se basan en una arquitectura híbrida, tal vez Azure, tal vez un entorno local, tal vez
ocho, etc.
Por lo tanto, debe asegurarse de que su arquitectura de registro también admita este tipo de entornos híbridos.
Entonces, hagamos una cosa antes de continuar.
Veamos una demostración rápida sobre esta arquitectura de registro centralizado.
Ahora, para la demostración de hoy, tengo dos cuentas en dos tipos diferentes que se están ejecutando.
Nos referiremos a la primera cuenta como una cuenta de registro central, y la segunda cuenta es básicamente la cuenta
de producción.
Y de manera similar a la arquitectura que discutimos, la cuenta de producción enviará los datos
a una cuenta de registro central.
Así que sigamos adelante y analicemos.
Ahora, en esa cuenta de registro, abramos rápidamente los tres servicios.
Ahora, dentro de aquí, tengo llamadas de un cubo S3, escape, registros centrales, seguimiento de la nube.
Ahora, por el nombre en sí, podemos identificar que este depósito también alojará los registros en la nube de
otras cuentas.
Ahora, si abre este cubo, tiene una carpeta de registros.
Y en esta etapa hay una cuenta que agrega los datos a este depósito S3, y esta cuenta termina con cuatro,
siete, seis tres.
Y si miras aquí, no es la misma cuenta.
Entonces, actualmente el número de cuenta de esta cuenta de dirección donde se encuentra este depósito es 9364.
Pero esta es una cuenta completamente diferente.
Entonces, esta cuenta 4763 básicamente se ejecuta en un tipo diferente.
Si son cuatro, siete, seis tres.
Y nuestro servicio en la nube desde esta cuenta de producción envía todos sus registros a nuestra cuenta de registro central.
Entonces, si desea ver la configuración de un rastro en la nube, abramos rápidamente un rastro aquí.
Si ve la ubicación del rastro, el escape tendrá registros centrales, rastro en la nube, que no es más que este depósito
específico en una cuadrícula de cuenta de registro.
Esa es la descripción general de alto nivel sobre el registro centralizado.
Ahora algunos puntos más importantes que debemos tener en cuenta.
La primera es que podemos hacer uso de múltiples servicios administrados para crear una solución de registro centralizada.
Puede utilizar la nube del servicio Elasticsearch, los registros de observación, las cinasas e incluso el depósito S3 para alojar estos
registros centralizados.
Junto con eso, una parte más importante que debemos notar es que las formas en que puede configurar el registro centralizado para cada
servicio, como seguimiento de carga, VPC, registros de flujo, servicio de guardia, etc. difiere
Cada servicio tiene una forma diferente en la que puede usarlo para enviar los registros a una cuenta de registro central.
Algunas de las formas son bastante sencillas.
Algunas de las formas requieren un poco más de pasos para configurarse.
Esa es la descripción general de alto nivel y esto concluirá el video de hoy.