Encaminhar eventos de alerta do Firebase para o Workflows

Console

1. No Console do Google Cloud, na página do seletor de projetos, selecione ou crie um projeto do Google Cloud.

   Acessar o seletor de projetos

2. Ative as APIs Eventarc, Eventarc Publishing, Workflows e Workflow Executions.

   Ative as APIs

3. Se aplicável, ative a API relacionada aos eventos diretos. Por exemplo, para eventos Firebase Alerts , ative a APIFirebase Alerts .

4. Se você ainda não tiver uma, crie uma conta de serviço gerenciada pelo usuário e conceda a ela os papéis e as permissões necessários para que o Eventarc gerencie eventos de um fluxo de trabalho de destino.

   1. No console do Google Cloud, acesse a página Contas de serviço.

      Acessar a página "Contas de serviço"

   2. Selecione o projeto.

   3. No campo Nome da conta de serviço, insira um nome. O Console do Google Cloud preenche o campo ID da conta de serviço com base nesse nome.

      No campo Descrição da conta de serviço, insira uma descrição. Por exemplo, Service account for event trigger.

   4. Clique em Criar e continuar.

   5. Para fornecer o acesso apropriado, na lista Selecionar um papel, escolha os papéis necessários do Identity and Access Management (IAM) para conceder à sua conta de serviço. Para mais informações, consulte Papéis e permissões para destinos do Workflows.

      Para papéis adicionais, clique em add Adicionar outro papel e adicione cada papel adicional.

   6. Clique em Continuar.

   7. Para concluir a criação da conta de serviço, clique em Concluído.

gcloud

1. In the Google Cloud console, activate Cloud Shell.

   Activate Cloud Shell

   At the bottom of the Google Cloud console, a Cloud Shell session starts and displays a command-line prompt. Cloud Shell is a shell environment with the Google Cloud CLI already installed and with values already set for your current project. It can take a few seconds for the session to initialize.

2. Ative as APIs Eventarc, Eventarc Publishing, Workflows e Workflow Executions:

   gcloud services enable eventarc.googleapis.com \
       eventarcpublishing.googleapis.com \
       workflows.googleapis.com \
       workflowexecutions.googleapis.com

3. Se aplicável, ative a API relacionada aos eventos diretos. Por exemplo, para eventos Firebase Alerts , ative firestore.googleapis.com.

4. Se você ainda não tiver uma, crie uma conta de serviço gerenciada pelo usuário e conceda a ela os papéis e as permissões necessários para que o Eventarc possa gerenciar eventos de um fluxo de trabalho de destino.

   1. Crie a conta de serviço:

      gcloud iam service-accounts create SERVICE_ACCOUNT_NAME

      Substitua SERVICE_ACCOUNT_NAME pelo nome da conta de serviço. Ele precisa ter entre 6 e 30 caracteres e pode conter letras minúsculas, caracteres alfanuméricos e traços. Depois de criar uma conta de serviço, não é possível alterar o nome dela.

   2. Conceda os papéis ou as permissões necessários do Identity and Access Management (IAM). Para mais informações, consulte Papéis e permissões para destinos do Workflows.

Console

1. No Console do Google Cloud, acesse a página Gatilhos do Eventarc.

   Acessar gatilhos

2. Clique em add_box Criar gatilho.
3. Digite um Nome de gatilho.

   Esse é o ID do gatilho e precisa começar com uma letra. Ele pode conter até 63 letras minúsculas, números ou hífens.

4. Em Tipo de gatilho, selecione Fontes do Google.
5. Na lista Provedor de eventos, selecione Firebase Alerts.

   O nome do provedor de eventos usado na documentação do Google Cloud associada pode não ter o prefixo Cloud ou Google Cloud. Por exemplo, no console, o Memorystore para Redis é chamado de Google Cloud Memorystore para Redis.

6. Na lista Tipo de evento, nos eventos Diretos, selecione um tipo de evento.
7. Para especificar a codificação do payload do evento, na lista Tipo de conteúdo de dados do evento, selecione application/json ou application/protobuf.

   Um payload de evento formatado em JSON é maior que um formatado em Protobuf. Isso pode afetar a confiabilidade dependendo do destino do evento e dos limites do tamanho do evento. Saiba mais em Problemas conhecidos.

8. Na lista Região, selecione global (global).

   Saiba mais em Locais do Eventarc.

9. No campo Atributo 1, o ID do recurso alerttype atua como um filtro de evento. Selecione um operador para esse filtro:
   • Igual
   • Padrão de caminho

     Para mais informações, consulte Entender os padrões de caminho.

10. No campo Valor do atributo 1, digite uma das seguintes opções:
    • appDistribution.inAppFeedback: o evento é enviado quando um testador envia feedback no app para um determinado app.
    • appDistribution.newTesterIosDevice: o evento é enviado quando um novo dispositivo testador do iOS está registrado para um determinado app.
    • billing.planAutomatedUpdate: o evento é enviado quando o plano de faturamento de um projeto do Firebase é atualizado automaticamente. Por exemplo, quando é feito o downgrade de um plano devido a problemas de pagamento
    • billing.planUpdate: o evento é enviado quando o plano de faturamento de um projeto do Firebase é modificado por um usuário. por exemplo, quando uma conta de faturamento é anexada ou desanexada de um projeto
    • crashlytics.missingSymbolFile: o evento é enviado quando o Firebase Crashlytics determina que não tem os símbolos de depuração adequados para simbolizar um relatório de erros recebido.
    • crashlytics.newAnrIssue: o evento é enviado quando um app tem um novo erro de "O app não está respondendo" (ANR, na sigla em inglês), e não a nenhum evento subsequente e idêntico.
    • crashlytics.newFatalIssue: o evento é enviado quando um app tem uma nova falha fatal (não para qualquer evento subsequente e idêntico).
    • crashlytics.newNonfatalIssue: o evento é enviado quando um app tem um novo erro não fatal (não para eventos idênticos e subsequentes).
    • crashlytics.regression: o evento é enviado quando ocorre uma falha no app devido a um problema marcado como fechado em uma versão anterior do app
    • crashlytics.stabilityDigest: o evento é enviado quando há uma notificação dos principais problemas em alta no Crashlytics.
    • crashlytics.velocity: o evento é enviado quando um único problema é responsável por causar uma falha em um número significativo de sessões do app.
    • performance.threshold: o evento é enviado quando o desempenho de uma métrica ultrapassa o limite definido.
11. Se preferir, filtre eventos para um ID específico do app do Firebase. Clique em add Adicionar filtro e especifique o appid.
12. Selecione a conta de serviço que vai invocar seu serviço ou fluxo de trabalho.

    ou crie uma nova conta de serviço.

    Ele especifica o e-mail da conta de serviço do Identity and Access Management (IAM) associado ao gatilho e aos quais você já concedeu papéis específicos exigidos pelo Eventarc.

13. Na lista Destino do evento, selecione Workflows.
14. Selecione um fluxo de trabalho.
    

    Esse é o nome do fluxo de trabalho para o qual transmitir eventos. Os eventos de uma execução de fluxo de trabalho são transformados e transmitidos para o fluxo de trabalho como argumentos de ambiente de execução.

    Para mais informações, consulte Criar um gatilho para os Workflows.

15. Clique em Criar.

Depois que um gatilho é criado, os filtros da origem de eventos não podem ser modificados. Crie um novo gatilho e exclua o antigo. Para mais informações, consulte Gerenciar acionadores.

gcloud

gcloud eventarc triggers create TRIGGER \
    --location=global \
    --destination-workflow=DESTINATION_WORKFLOW  \
    --destination-workflow-location=DESTINATION_WORKFLOW_LOCATION \
    --event-filters="type=google.firebase.firebasealerts.alerts.v1.published" \
    --event-filters="alerttype=ALERT_TYPE" \
    --event-data-content-type="EVENT_DATA_CONTENT_TYPE" \
    --service-account="MY_SERVICE_ACCOUNT@PROJECT_ID.iam.gserviceaccount.com"

Substitua:

• TRIGGER: o ID do gatilho ou um identificador totalmente qualificado.
• DESTINATION_WORKFLOW: o ID do fluxo de trabalho implantado que recebe os eventos do gatilho. O fluxo de trabalho pode estar em qualquer um dos locais compatíveis com o Workflows e não precisa estar no mesmo local do gatilho. No entanto, o fluxo de trabalho precisa estar no mesmo projeto que o gatilho.
• DESTINATION_WORKFLOW_LOCATION (opcional): o local em que o fluxo de trabalho de destino está implantado. Se não for especificado, presumirá que o fluxo de trabalho está no mesmo local que o gatilho.
• ALERT_TYPE: o tipo de alerta do Firebase, que pode ser um dos seguintes valores:
  • appDistribution.inAppFeedback: o evento é enviado quando um testador envia feedback no app para um determinado app.
  • appDistribution.newTesterIosDevice: o evento é enviado quando um novo dispositivo testador do iOS está registrado para um determinado app.
  • billing.planAutomatedUpdate: o evento é enviado quando o plano de faturamento de um projeto do Firebase é atualizado automaticamente. Por exemplo, quando é feito o downgrade de um plano devido a problemas de pagamento
  • billing.planUpdate: o evento é enviado quando o plano de faturamento de um projeto do Firebase é modificado por um usuário. por exemplo, quando uma conta de faturamento é anexada ou desanexada de um projeto
  • crashlytics.missingSymbolFile: o evento é enviado quando o Firebase Crashlytics determina que não tem os símbolos de depuração adequados para simbolizar um relatório de erros recebido.
  • crashlytics.newAnrIssue: o evento é enviado quando um app tem um novo erro de "O app não está respondendo" (ANR, na sigla em inglês), e não a nenhum evento subsequente e idêntico.
  • crashlytics.newFatalIssue: o evento é enviado quando um app tem uma nova falha fatal (não para qualquer evento subsequente e idêntico).
  • crashlytics.newNonfatalIssue: o evento é enviado quando um app tem um novo erro não fatal (não para eventos idênticos e subsequentes).
  • crashlytics.regression: o evento é enviado quando ocorre uma falha no app devido a um problema marcado como fechado em uma versão anterior do app
  • crashlytics.stabilityDigest: o evento é enviado quando há uma notificação dos principais problemas em alta no Crashlytics.
  • crashlytics.velocity: o evento é enviado quando um único problema é responsável por causar uma falha em um número significativo de sessões do app.
  • performance.threshold: o evento é enviado quando o desempenho de uma métrica ultrapassa o limite definido.
  O operador de ALERT_TYPE precisa ser um dos seguintes:
  • Igual, por exemplo, --event-filters="alerttype=appDistribution.inAppFeedback"
  • Padrão de caminho, por exemplo, --event-filters-path-pattern="alerttype=appDistribution." ou --event-filters-path-pattern="alerttype=crashlytics.new".

    Para mais informações, consulte Entender os padrões de caminho.

• EVENT_DATA_CONTENT_TYPE: (opcional) a codificação do payload do evento. Os valores podem ser application/json ou application/protobuf. A codificação padrão é application/json.

  Um payload de evento formatado em JSON é maior do que um formatado em Protobuf. Isso pode afetar a confiabilidade dependendo do destino do evento e dos limites dele no tamanho. Saiba mais em Problemas conhecidos.

• SERVICE_ACCOUNT_NAME: o nome da conta de serviço do IAM que você criou para a qual você concedeu papéis específicos exigidos pelos fluxos de trabalho.
• PROJECT_ID: o ID do projeto do Google Cloud

Observações:

• A sinalização --location precisa ser global. Saiba mais em Locais do Eventarc.
• Estas flags são necessárias:
  • --event-filters="type=google.firebase.firebasealerts.alerts.v1.published"
  • --event-filters="alerttype=ALERT_TYPE" ou --event-filters-path-pattern="alerttype=ALERT_TYPE"
• Após a criação de um gatilho, o tipo do filtro de evento não pode ser alterado. Para um tipo de evento diferente, crie um novo gatilho.
• Opcionalmente, é possível filtrar eventos de um ID de app específico do Firebase usando a flag --event-filters="appid=APP_ID" e especificando uma correspondência exata.
• --service-account: o e-mail da conta de serviço do IAM que o gatilho do Eventarc usará para invocar as execuções de fluxo de trabalho. Recomendamos o uso de uma conta de serviço com os privilégios mínimos necessários para acessar os recursos necessários. Para saber mais sobre contas de serviço, consulte Criar e gerenciar contas de serviço.
• Por padrão, as assinaturas do Pub/Sub criadas para o Eventarc são mantidas independentemente da atividade e não expiram. Para mudar a duração da inatividade, consulte Propriedades da assinatura.

Exemplo:

gcloud eventarc triggers create firealerts-workflows-trigger \
    --location=global \
    --destination-workflow=my-workflow \
    --destination-workflow-location=europe-west4 \
    --event-filters="type=google.firebase.firebasealerts.alerts.v1.published" \
    --event-filters="alerttype=crashlytics.velocity" \
    --service-account="${SERVICE_ACCOUNT_NAME}@${PROJECT_ID}.iam.gserviceaccount.com"

Esse comando cria um gatilho chamado firealerts-workflows-trigger para o evento identificado como google.firebase.firebasealerts.alerts.v1.published e para um tipo de alerta crashlytics.velocity.

Terraform

É possível criar um gatilho para um fluxo de trabalho usando o Terraform. Para mais detalhes, acesse Como acionar um fluxo de trabalho usando o Eventarc e o Terraform.

Console

1. No Console do Google Cloud, acesse a página Gatilhos do Eventarc.

   Acessar gatilhos

   Confira nesta página os gatilhos em todos os locais e os detalhes como nomes, regiões, provedores de eventos, destinos e muito mais.

2. Para filtrar os gatilhos, siga estas etapas:

   1. Clique em filter_list Filtrar ou no campo Filtrar gatilhos.
   2. Na lista Propriedades, selecione uma opção para filtrar os gatilhos.

   É possível selecionar uma única propriedade ou usar o operador lógico OR para adicionar mais propriedades.

3. Para classificar gatilhos, ao lado de qualquer cabeçalho de coluna com suporte, clique em arrow_upward Ordenar.

gcloud

Execute o comando a seguir para listar os gatilhos:

gcloud eventarc triggers list --location=-

Esse comando lista os gatilhos em todos os locais e inclui detalhes como nomes, tipos, destinos e status.