Olá a todos e bem-vindos de volta.
Agora, no vídeo de hoje, vamos discutir sobre o registro centralizado.
Agora em ambiente de produção, ter um log centralizado é extremamente importante.
Caso contrário, se você não tiver e ocorrer um incidente, pode ser qualquer incidente relacionado
à confiabilidade, segurança, etc. Quando ocorre um incidente, observou-se que a equipe terá que passar
por várias contas, vários servidores para buscar o arquivo de log que pode fornecer detalhes relacionados a esse incidente específico.
Algumas vezes também foi observado que devido ao espaço em disco que estava cheio naquele servidor, o arquivo
de log nunca foi gerado.
Portanto, para superar esses problemas, é importante que você tenha o log centralizado configurado.
E no vídeo de hoje vamos olhar para este tipo de arquitetura agora em geral nas organizações, especificamente
nestes estágios onde eles seguem a arquitetura baseada em várias contas.
O monitoramento de log é uma das coisas mais importantes que você terá que cuidar.
Agora, digamos que neste diagrama há três contas de oito posições agora em vigor.
Muitos dos serviços geram seu próprio conjunto de arquivos de log.
Cloud gera seu guia de arquivo de log para gerar o arquivo de log.
Se você tiver um conjunto de duas instâncias fáceis, haverá logs, haverá
logs relacionados à configuração etc. Portanto, esta é uma parte e o mesmo se aplica a outras contas também.
Agora, geralmente, muitas organizações, o que fazem quando têm uma solução de monitoramento
centralizada como o Splunk, associam o Splunk a cada conta individual para buscar os logs de todos os serviços
individuais.
Então o Splunk primeiro se conecta à conta de desenvolvimento, busca os logs da trilha na nuvem.
O dever de guarda é de duas instâncias e assim por diante, o mesmo para preparação, o mesmo para produção e assim por diante.
Portanto, embora isso pareça ser bom como ponto de partida, mas quando você tem centenas de contas de banco
de dados, essa não é a melhor das arquiteturas que podem ser usadas.
Agora, uma das arquiteturas recomendadas para registro em log é que você tem uma conta de registro centralizada.
Então o que realmente acontece aqui é que cada conta individual.
Então, neste caso, você tem uma conta, você tem uma conta, B, etc. Cada conta é configurada para enviar seus arquivos
de log para uma conta de log central.
Portanto, na conta, você pode ter uma nuvem habilitada para o serviço de nuvem que enviará os logs para a conta da conta de registro
central.
Teremos um serviço de configuração ativado novamente, ele será enviado para a conta de registro central e sua ferramenta de monitoramento de
registro como o Splunk.
Esta ferramenta de monitoramento de log será associada a apenas uma conta, neste caso a conta
de log do centro, e buscará todos os dados aqui.
Dessa forma, mesmo se você tiver 100 contas de banco de dados, fica muito mais simples porque todas essas
contas enviarão os logs para uma conta de log central aqui.
Agora, quando você tem uma arquitetura baseada em log, há certas considerações que você precisa
cuidar.
A primeira consideração é que você terá que definir um requisito de retenção de log e as políticas de ciclo de vida
desde o início.
Agora, geralmente em organizações maiores, o tamanho do log seria em terabytes.
Então, você precisa de todos os terabytes de dados em seu bucket do S3 ou também pode movê-los para o Glacier?
Porque se você armazenar tantos dados no S3, sua conta também será enorme.
Muitas das organizações têm um requisito de retenção de log.
Por exemplo, para os primeiros três meses os logs serão necessários bucket.
Após três meses, todas as toras irão para a geleira e assim por diante.
Portanto, tudo isso depende das políticas de retenção de log em sua organização novamente, se você precisar incorporar ferramentas
e recursos para automatizar as políticas de ciclo de vida.
Portanto, se você estiver usando o S3, isso é muito mais direto.
A terceira parte importante é que você precisa automatizar a instalação e configuração do envio de logs.
Imagine, por exemplo, digamos que você inicie dez novas instâncias fáceis de usar.
Agora, depois desse SC, duas instâncias são lançadas.
Você também precisa garantir que todas essas instâncias fáceis de acessar enviem imediatamente todos os logs
para a conta de log centralizada.
Então talvez no próprio exército você possa ter seu agente Splunk ou um agente de registro pré-configurado.
Assim, sempre que a instância for iniciada, o agente seguirá em frente e começará a enviar os logs para a conta central.
E a quarta consideração é garantir que a solução ofereça suporte a ambientes híbridos para atender às necessidades.
Não é necessário que todas as contas sejam baseadas em um banco de dados.
Pode acontecer.
Algumas contas são baseadas em arquitetura híbrida, talvez Azure, talvez no ambiente local, talvez oito e assim
por diante.
Portanto, você precisa garantir que sua arquitetura de log também suporte esse tipo de ambiente híbrido.
Então vamos fazer uma coisa antes de prosseguirmos.
Vamos fazer uma demonstração rápida sobre essa arquitetura de log centralizada.
Agora, para a demonstração de hoje, tenho duas contas em dois tipos diferentes em execução.
A primeira conta à qual nos referiremos como uma conta de registro central e a segunda conta é basicamente a conta
de produção.
E semelhante à arquitetura que estávamos discutindo, a conta de produção enviará os dados
para uma conta de registro central.
Então vamos em frente e olhar para dentro.
Agora, nessa conta de registro, vamos abrir rapidamente os três serviços.
Agora, aqui dentro, tenho chamadas de bucket do S3, escape, logs centrais, trilha de nuvem.
Agora, pelo próprio nome, podemos identificar que esse bucket hospedará os logs de nuvem de outras contas
também.
Agora, se você abrir esse bucket, terá uma pasta de logs.
E, neste estágio, há uma conta que está adicionando os dados a esse bucket do S3, e essa conta termina com
quatro, sete, seis, três.
E se você olhar aqui, não é a mesma conta.
Portanto, atualmente, o número da conta dessa conta de endereço onde esse bucket está é 9364.
Mas esta é uma conta completamente diferente.
Portanto, esta conta 4763 está basicamente sendo executada em um tipo diferente.
Se for quatro, sete, seis, três.
E nosso serviço de nuvem dessa conta de produção está enviando todos os seus logs para nossa conta de log central.
Então, se você examinar a configuração de uma trilha de nuvem, vamos abrir rapidamente uma trilha aqui.
Se você vir a fuga de localização da trilha, terá logs centrais, trilha na nuvem, que nada mais é que esse bucket
específico em uma grade de conta de registro.
Essa é a visão geral de alto nível sobre o registro centralizado.
Agora, alguns pontos mais importantes que precisamos observar.
A primeira é que podemos usar vários serviços gerenciados para criar uma solução de registro centralizada.
Você pode usar a nuvem de serviço do Elasticsearch, watch logs, kinases e até mesmo bucket do S3 para hospedar esses
logs centralizados.
Junto com isso, mais uma parte importante que precisamos observar que as maneiras pelas quais você pode configurar o registro centralizado
para cada serviço, como trilha de carga, VPC, logs de fluxo, serviço de guarda, etc. difere.
Cada serviço tem uma maneira diferente de usá-lo para enviar os logs para uma conta de log central.
Algumas das maneiras são bastante simples.
Algumas das formas requerem um pouco mais de passos para serem configuradas.
Essa é a visão geral de alto nível e isso concluirá o vídeo de hoje.