Geração de registros de recursos no local com Blue Medora

Essa solução compõe uma série em duas partes sobre como estender o Cloud Logging e o Cloud Monitoring para incluir infraestrutura e apps no local.

  • Logging (esta solução): leia sobre a compatibilidade do Logging com a geração de registros de recursos locais.
  • Monitoring: leia sobre como o Monitoring oferece suporte ao monitoramento de recursos locais.

Use o Loggin e o Monitoring para monitorar e gerar registros dos recursos locais pelos motivos a seguir:

  • Você quer uma solução temporária enquanto migra a infraestrutura para o Google Cloud e quer registrar e monitorar seus recursos locais até que eles sejam desativados.
  • Talvez você tenha um ambiente de computação diversificado com várias nuvens e recursos locais.

Em ambos os casos, com a API do Loggin e do Monitoring e o BindPlane, é possível ter visibilidade de seus recursos locais. Essa solução destina-se a profissionais, gerentes e executivos de DevOps interessados em uma estratégia de monitoramento para recursos no Google Cloud e nos aplicativos e infraestrutura locais restantes.

Como ingerir registros com o Logging

É possível gerar registros no Logging usando a API de duas maneiras compatíveis:

  • Use a ferramenta BindPlane do Blue Medora para ingerir registros de origens locais ou de outras origens na nuvem.
  • Use a API Google Cloud diretamente do app ou usando um agente personalizado.

Como usar o BindPlane para ingerir registros do Logging

O diagrama a seguir mostra a arquitetura de como o BindPlane ingere registros e, em seguida, como esses registros são ingeridos no Logging.

Arquitetura de uso do Logging e do BindPlane para ingerir registros locais.

O BindPlane oferece um serviço integrado para ingerir registros locais no Logging. O BindPlane usa as APIs de registro por meio de um agente Fluentd para enviar registros para o Logging, que é semelhante à operação do agente do Logging. Para mais informações, leia sobre a arquitetura do BindPlane. Essa opção requer o menor esforço para implantar, porque requer configuração para configurar, em vez de desenvolvimento.

Vantagens:

  • Requer configuração, não desenvolvimento.
  • Incluído no custo de uso do Logging.
  • É uma configuração compatível com produtos e suporte do Logging.
  • Pode se estender para registros não fornecidos pela configuração padrão.

Desvantagens:

  • Requer o uso de uma ferramenta de terceiros.
  • Pode ser necessário fornecer a configuração do plug-in Fluentd se o plug-in de registro não for fornecido por padrão. A lista de registros fornecida está disponível em Fontes.

Como usar a API Logging

O diagrama a seguir mostra a arquitetura de como os registros são coletados por instrumentação e ingeridos no Logging.

Arquitetura de uso da API Logging para ingerir diretamente registros locais.

Usar as APIs diretamente significa que você precisa instrumentar seus aplicativos de modo a enviar registros diretamente à API ou desenvolver um agente personalizado para enviar registros a ela. Essa é a opção que requer o nível mais alto de esforço, porque exige um trabalho de desenvolvimento.

Vantagens:

  • Fornece flexibilidade porque a instrumentação pode ser implementada com as bibliotecas de geração de registros do cliente.

Desvantagens:

  • Requer uma solução separada para registros de infraestrutura, como um agente personalizado.
  • Requer instrumentação de código, o que pode significar maior custo para implementar.
  • Requer o uso de lotes e outras técnicas de ingestão escalonáveis para desempenho de ingestão adequado.
  • O suporte é fornecido apenas para a API de registro, não para o código personalizado.

Como usar o BindPlane

Essa solução abrange o uso da ferramenta BindPlane da Blue Medora para ingerir registros no Logging. Como está incluído no custo do Logging, o BindPlane não exige desenvolvimento e fornece uma solução compatível com produto.

Agentes, origens e destinos

O BindPlane tem os recursos a seguir:

  • Agentes: software usado para coletar registros, que geralmente é instalado no computador que produz os registros. Os agentes também enviam os registros para a API Logging.
  • Origens: configuração que especifica quais registros serão ingeridos, como syslogs, Apache e Kubernetes, e como analisá-los. Para mais informações, consulte os registros compatíveis com o BindPlane. Todos os registros incompatíveis podem ser ingeridos usando um Syslog input ou Tail input genérico. Para registros personalizados, especifique um Custom Input, que usa um bloco de configuração personalizado do Fluentd como entrada.
  • Destinos: os serviços de terceiros que o BindPlane encaminha os registros. No caso, o destino é a API Logging para gravar métricas no Logging.

Para informações mais detalhadas sobre agentes, origens e destinos, consulte os primeiros passos com o BindPlane.

Exemplo de caso de uso:

Por exemplo, a ExampleOrganization tem recursos implantados no Google Cloud, no Microsoft Azure e em recursos locais implantados com o vSphere. Com recursos em cada ambiente, a ExampleOrganization quer coletar registros para cada componente, independentemente de onde o componente é implantado. Enviar os registros de cada ambiente para o Logging usando agentes do BindPlane reúne todas os registros em um único local para centralizar a geração de relatório, monitoramento e propósitos operacionais.

Neste exemplo, o Logging é configurado como o destino para uma matriz de agentes, incluindo os do Google Cloud, do Microsoft Azure e do vSphere. Depois que os registros são gerados, eles são ingeridos no Logging pelo BindPlane.

Enviar registros do local para o Logging

Depois de configurar o BindPlane e começar a enviar registros, eles serão enviados para o Logging. Para ver, processar e exportar registros, acesse o Console do Google Cloud. Os registros são listados como os tipos de recurso generic_node ou generic_task. Para mais informações sobre os rótulos incluídos em cada tipo de recurso, consulte a lista de recursos do Logging.

O Cloud Logging é compatível com registros que não são próprios ao usar dois tipos de recurso:

  • Nó genérico: identifica uma máquina ou outro recurso computacional ao qual nenhum outro tipo de recurso é aplicável. Os valores do rótulo precisam identificar exclusivamente o nó.
  • Tarefa genérica: identifica um processo de app para o qual nenhum outro recurso é aplicável, como um processo programado por um sistema de orquestração personalizado. Os valores do rótulo precisam identificar exclusivamente a tarefa.

Ver registros no Logging

No Console do Cloud, o nó genérico aparece como um tipo de recurso na lista da página do Logging.

Lista de recursos no Logging

Os registros a seguir foram capturados como o tipo de recurso generic_node e aparecem no Logging.

Lista de registros no Logging.

A entrada de registro a seguir usa um formato de geração de registros estruturados, que é mais avançado para a pesquisa de registros, já que o payload do registro é armazenado como jsonPayload. O formato de geração de registros estruturados torna os registros mais acessíveis, porque é possível usar os campos no payload como parte da pesquisa. O agente de geração de registros do BindPlane fornece um mapeamento da entrada de registro original para o registro estruturado no Logging.

Entrada de registro no formato de geração de registros estruturados.

Conclusão

Com os registros disponíveis no Logging, você aproveita ao máximo os recursos dele. Os registros aparecem no Console do Cloud. Exporte registros com exportações do Logging e use-os para criar métricas e alertas no Monitoring usando métricas com base em registros.

A seguir