Executar jobs de análise no Cloud Deploy

Com o Cloud Deploy, é possível analisar a performance dos aplicativos implantados usando a plataforma e as métricas de monitoramento que você preferir. É possível usar os resultados dessas análises para realizar ações, como reverter automaticamente a implantação.

O Cloud Deploy é compatível com o Google Cloud Observability e pode ser estendido para oferecer suporte a outras plataformas de monitoramento, como Datadog ou Prometheus.

Embora o Cloud Deploy ofereça verificação de implantação, que pode ser usada para executar contêineres arbitrários para validar uma implantação, a análise permite usar dados de telemetria do Google Cloud Observability ou do serviço de monitoramento de sua escolha para avaliar o desempenho dos seus aplicativos ao longo do tempo.

É possível executar jobs de análise em qualquer ambiente de destino (por exemplo, de teste ou de produção).

Provedores de métricas compatíveis

O Cloud Deploy oferece suporte à análise usando métricas fornecidas de uma das seguintes maneiras:

  • Integração direta com as políticas de alertas da Google Cloud Observability, com base em telemetria e registros na Google Cloud Observability

  • Integração com sistemas de métricas que não são do Google (por exemplo, Prometheus ou Datadog)

    Esse tipo de análise personalizada exige que sua organização forneça um contêiner com funcionalidade para oferecer suporte ao sistema de métricas específico.

    O Google Cloud oferece uma integração de amostra com o Datadog.

Como funciona a análise do Cloud Deploy

Nesta seção, descrevemos como a análise do Cloud Deploy funciona usando políticas de alerta do Google Cloud Observability. Se a organização criar um contêiner personalizado para usar um provedor de métricas diferente, parte dessa funcionalidade será processada pelo contêiner personalizado.

  • Configure as métricas no sistema de métricas de sua escolha.

    O Cloud Deploy é compatível com o Google Cloud Observability sem personalização. Você também pode usar o provedor de métricas de sua escolha criando um contêiner personalizado para processar a telemetria.

    Saiba mais.

  • Configurar uma política de alertas

    Se você estiver usando o Google Cloud Observability para coletar telemetria, use uma política de alertas para detectar quando essa telemetria indicar um problema.

    Se você estiver usando outro provedor de métricas, os alertas serão de responsabilidade dessa ferramenta ou do seu contêiner personalizado.

  • Configurar um job de análise

    Isso consiste em uma seção analysis no arquivo de configuração do pipeline de entrega.

    O job de análise consiste em uma ou mais verificações, e cada uma delas avalia o comportamento do aplicativo implantado com base em registros ou métricas da Google Cloud Observability ou do seu provedor de métricas. O job de análise é executado por um período especificado.

  • implantar o aplicativo

    O job de análise é executado depois do job de implantação e do job de verificação, se a versão incluir um, mas antes de qualquer job pós-implantação, se a versão incluir algum.

  • O job de análise é executado

    Depois que o aplicativo é implantado (e depois que um job de verificação é concluído, se houver um), o provedor de métricas coleta telemetria sobre o aplicativo em execução. O job de análise aguarda o período configurado (o duration). Se um alerta for acionado (se você estiver usando o Google Cloud Observability como provedor de métricas) ou se o contêiner personalizado retornar um código de saída diferente de zero, o job de análise e o lançamento vão falhar.

    Se nenhuma das verificações determinar que há um problema, a análise será concluída após o término da duração, e o lançamento será bem-sucedido.

Usar a análise com automações

É possível especificar automações para usar com seus jobs de análise.

Por exemplo, se você quiser executar uma análise no seu aplicativo depois que ele for implantado em staging e promover automaticamente a versão para prod se a análise for concluída sem alertas, use uma automação do promoteReleaseRule.

Ou, se quiser reverter automaticamente um lançamento caso um job de análise encontre um problema em prod, use uma automação repairRolloutRule.

Não é necessário usar automações para aproveitar os benefícios dos trabalhos de análise.

Análise personalizada

A análise do Cloud Deploy é compatível com alertas e métricas do Google Cloud Observability. Mas também é possível usar a análise do Cloud Deploy com provedores de métricas que não são doGoogle Cloud.

A configuração para análise personalizada é semelhante à de uma análise padrão, exceto que cada verificação na análise inclui uma tarefa que faz referência a um contêiner fornecido por você, os comandos a serem executados nesse contêiner e as variáveis de ambiente aplicáveis a serem transmitidas para ele. Cada verificação nessa análise personalizada também inclui uma frequência, ou seja, a frequência com que a verificação é executada.

Saiba mais.

Como usar a análise com um canário

Um uso típico da análise do Cloud Deploy é com uma estratégia de implantação canário. Com o canary, é possível usar métricas do Google Cloud Observability ou do provedor de sua escolha para determinar se um lançamento vai avançar para a próxima fase.

Você também pode usar uma automação do advanceRolloutRule com a análise. Por exemplo, na fase canário antes de stable, você pode incluir um job de análise para garantir o tempo de atividade e usar a automação para avançar ou não o lançamento para stable, dependendo dos resultados dessa análise.

Se você usar uma implantação canário personalizada ou personalizada e automatizada, configure jobs de análise na configuração de cada fase que você quer analisar.

Saiba mais sobre as implantações canário.

Estados de execução de jobs de análise

Confira a seguir os estados possíveis de uma execução de job de análise:

  • IN_PROGRESS

    A análise começou e ainda está em execução. O lançamento vai continuar IN_PROGRESS, a menos que você o cancele.

  • FAILED

    O job de análise detectou um alerta do Google Cloud Observability ou recebeu um código de saída diferente de zero de um contêiner personalizado. O estado do lançamento agora é FAILED. Mas se você ignorar ou tentar novamente o job de análise, o estado do lançamento será atualizado para IN_PROGRESS.

  • SUCCEEDED

    A análise foi concluída (o duration expirou) e não recebeu indicações de métricas desfavoráveis. O estado do lançamento muda para SUCCEEDED depois que todas as outras fases e jobs são concluídos.

A seguir