31.1. Configurar o webhook do Alertmanager ServiceNow

Tempo estimado para a conclusão: 2 horas

Proprietário do componente operável: TS

Este documento contém as instruções para configurar o webhook do Alertmanager ServiceNow e criar alertas na instância ativa do sistema de tíquetes do ServiceNow.

31.1.1. Antes de começar

Antes de configurar o webhook do ServiceNow, siga estas etapas:

  1. Crie manualmente o secret midserver-secret.
  2. Siga as etapas no runbook TS-R0012 para configurar o segredo corretamente.
  3. Verifique se o yq está instalado no sistema.

    root@bootstrapper:~# yq --version
    yq (https://github.com/mikefarah/yq/) version v4.40.4
    
  4. Para ter as permissões necessárias para acessar objetos no namespace obs-system e gerenciar o aplicativo ServiceNow, peça ao administrador de segurança para conceder a você os seguintes papéis:

    • Debugger de observabilidade (observability-admin-debugger para o cluster de administrador raiz e observability-system-debugger para os clusters de administrador da organização e do sistema)
    • Leitor do Grafana (grafana-viewer)
    • Administrador do ServiceNow (system-service-now-admin)

    Para mais informações sobre esses papéis, consulte Papéis de operador de infraestrutura.

31.1.2. Configurar o webhook

Siga estas etapas para configurar o webhook do ServiceNow do Alertmanager:

  1. É possível configurar o webhook do ServiceNow em uma organização.

    Se você quiser configurar o webhook do ServiceNow no cluster do sistema de uma organização, peça ao operador de infraestrutura (IO) para executar o runbook OPA-R0005 com as seguintes informações:

    • O valor da variável de ambiente IO_GROUP é o grupo de usuários a que seu usuário pertence.
    • O valor da variável de ambiente CONSTRAINT_NAME é restrict-system-project-namespace-resources.
  2. Crie uma conta de serviço do ServiceNow para criar incidentes com base nos alertas de uma organização:

    1. Abra o URL da interface da Web do ServiceNow:

      https://support.gdchservices.GDC_URL/navpage.do
      

      Substitua GDC_URL pelo URL da sua organização no Google Distributed Cloud (GDC) isolado por air-gap.

      Sempre use gdchservices como o nome da organização de TI da Central de operações.

    2. Selecione Todos > Administração de usuários > Usuários.

    3. Clique em Novo.

    4. Na nova janela, insira os seguintes valores:

      • No campo ID do usuário, insira SVC_ALERT_ORG.
      • No campo Nome, digite SVC_ALERT_ORG.
      • Marque a caixa de seleção Acesso somente ao serviço da Web.

      Substitua ORG pelo nome da sua organização. Ao realizar esta etapa no cluster de administrador raiz, use o valor root para o nome ORG.

    5. Clique em Enviar.

      O novo registro de usuário aparece na lista de contas do ServiceNow.

  3. Adicione o papel itil à conta de serviço:

    1. Abra o registro do usuário na lista.

    2. Clique na guia Funções e no botão Editar....

    3. Selecione o papel itil no menu Coleção.

    4. Clique no botão Adicionar () para mover a função para o menu Lista de funções.

    5. Clique em Salvar.

  4. Defina a senha da conta de serviço do ServiceNow:

    1. Abra o registro do usuário na lista.

    2. Clique em Definir senha e em Gerar.

    3. Copie a senha exibida na janela e armazene-a em um local seguro.

    4. Clique em Salvar senha e feche a janela.

  5. Abra a interface de linha de comando.

  6. Configure as variáveis de ambiente a seguir:

    export ORG=ORGANIZATION
    export SERVICENOW_INSTANCE_URL=SERVICENOW_INSTANCE_URL
    export SERVICENOW_USERNAME=SERVICENOW_USERNAME
    export SERVICENOW_PASSWORD=SERVICENOW_PASSWORD
    export SERVICENOW_AUTORESOLVE=SERVICENOW_AUTORESOLVE
    export SERVICENOW_AUTORESOLVE_REOPEN_DURATION=SERVICENOW_AUTORESOLVE_REOPEN_DURATION
    

    Substitua:

    • ORGANIZATION: o nome da organização
    • SERVICENOW_INSTANCE_URL: o URL da interface da Web do ServiceNow, por exemplo, https://support.gdchservices.GDC_URL.
    • SERVICENOW_USERNAME: o nome de usuário da conta de serviço do ServiceNow.
    • SERVICENOW_PASSWORD: a senha da conta de serviço do ServiceNow.
    • SERVICENOW_AUTORESOLVE: "true" se você quiser resolver automaticamente os incidentes do ServiceNow quando o alerta correspondente parar de ser acionado. Caso contrário, "false".
    • SERVICENOW_AUTORESOLVE_REOPEN_DURATION: a duração em que um incidente resolvido do ServiceNow pode ser reaberto se o mesmo alerta for acionado novamente. Exemplos: "5m", "30s", "24h" etc.
  7. Execute este comando:

    cat << EOF > ~/mon-alertmanager-servicenow-webhook-subcomponentoverride.yaml
    apiVersion: lcm.private.gdc.goog/v1
    kind: SubcomponentOverride
    metadata:
      name: mon-alertmanager-servicenow-webhook
    spec:
      subComponentRef: "mon-alertmanager-servicenow-webhook"
      backend:
        operableParameters:
          servicenowCredentials:
            instanceName: ${SERVICENOW_INSTANCE_URL:?}
            username: ${SERVICENOW_USERNAME:?}
            password: ${SERVICENOW_PASSWORD:?}
          serviceNowSettings:
            autoResolve: ${SERVICENOW_AUTORESOLVE:?}
            autoResolveReopenDuration: ${SERVICENOW_AUTORESOLVE_REOPEN_DURATION:?}
    EOF
    cat << EOF > ~/meta-alertmanager-servicenow-webhook-subcomponentoverride.yaml
    apiVersion: lcm.private.gdc.goog/v1
    kind: SubcomponentOverride
    metadata:
      name: meta-alertmanager-servicenow-webhook
    spec:
      subComponentRef: "mon-meta-monitoring"
      backend:
        operableParameters:
          servicenowCredentials:
            instanceName: ${SERVICENOW_INSTANCE_URL:?}
            username: ${SERVICENOW_USERNAME:?}
            password: ${SERVICENOW_PASSWORD:?}
          serviceNowSettings:
            autoResolve: ${SERVICENOW_AUTORESOLVE:?}
            autoResolveReopenDuration: ${SERVICENOW_AUTORESOLVE_REOPEN_DURATION:?}
    EOF
    cat << EOF > ~/ts-networking-subcomponentoverride.yaml
    apiVersion: lcm.private.gdc.goog/v1
    kind: SubcomponentOverride
    metadata:
      name: ts-networking
    spec:
      subComponentRef: "ts-networking"
      backend:
        operableParameters:
          serviceNowEndpoint: ${SERVICENOW_INSTANCE_URL:?}
    EOF
    
  8. Siga as etapas abaixo para configurar o webhook do ServiceNow em um cluster:

Cluster de administrador raiz

  1. Configure as variáveis de ambiente a seguir:

    export ROOT_KUBECONFIG=PATH_TO_ROOT_ADMIN_KUBECONFIG
    

    Substitua:

    • PATH_TO_ROOT_ADMIN_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador raiz
  2. Encontre a implantação do webhook:

    kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" get deployment mon-alertmanager-servicenow-webhook-backend -n mon-system
    

    A saída precisa mostrar um status READY e ser semelhante a este exemplo:

    NAME                                          READY   UP-TO-DATE   AVAILABLE   AGE
    mon-alertmanager-servicenow-webhook-backend   1/1     1            1           8h
    
  3. Verifique se o arquivo YAML configmap existe:

    kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" get configmap/mon-alertmanager-servicenow-webhook-backend -n mon-system
    

    A saída será semelhante ao exemplo a seguir:

    NAME                                         DATA   AGE
    mon-alertmanager-servicenow-webhookbackend   1      8h
    
  4. Verifique se o arquivo YAML Secret existe:

    kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" get secret/mon-alertmanager-servicenow-webhook-backend -n mon-system
    

    A saída será semelhante ao exemplo a seguir:

    NAME                                          TYPE     DATA   AGE
    mon-alertmanager-servicenow-webhook-backend   Opaque   2      8h
    
  5. Configure o arquivo YAML configmap:

    kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" apply -n root -f ~/mon-alertmanager-servicenow-webhook-subcomponentoverride.yaml
    

    Saída esperada:

    subcomponentoverride.lcm.private.gdc.goog/mon-alertmanager-servicenow-webhook created
    
  6. Configure a rede:

    kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" apply -n root -f ~/ts-networking-subcomponentoverride.yaml
    

    Saída esperada:

    subcomponentoverride.lcm.private.gdc.goog/ts-networking created
    
  7. Reinicie a implantação do webhook:

    kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" rollout restart deployment/mon-alertmanager-servicenow-webhook-backend -n mon-system
    

    A saída verifica o sucesso, como mostrado no exemplo a seguir:

    deployment.apps/mon-alertmanager-servicenow-webhook-backend restarted
    
  8. Reinicie a implantação do webhook da pilha de monitoramento secundária:

    kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" rollout restart deployment/meta-alertmanager-servicenow-webhook -n obs-system
    

    A saída verifica o sucesso, como mostrado no exemplo a seguir:

    deployment.apps/alertmanager-servicenow-webhook restarted
    
  9. Verifique os registros da implantação do alertmanager-servicenow-webhook para validar a configuração:

    kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" logs deployment/mon-alertmanager-servicenow-webhook-backend -n mon-system
    
  10. Se os registros contiverem a string listening on: :9877, a configuração estará concluída. Caso contrário, peça ajuda para resolver o problema.

  11. Encontre a implantação do webhook:

    kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" get deployment meta-alertmanager-servicenow-webhook -n mon-system
    

    A saída precisa mostrar um status READY e ser semelhante a este exemplo:

    NAME                                          READY   UP-TO-DATE   AVAILABLE   AGE
    meta-alertmanager-servicenow-webhook          1/1     1            1           8h
    
  12. Verifique se o arquivo YAML configmap existe:

    kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" get configmap/meta-alertmanager-servicenow-webhook -n mon-system
    

    A saída será semelhante ao exemplo a seguir:

    NAME                                         DATA   AGE
    meta-alertmanager-servicenow-webhook         1      8h
    
  13. Verifique se o arquivo YAML Secret existe:

    kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" get secret/meta-alertmanager-servicenow-webhook -n mon-system
    

    A saída será semelhante ao exemplo a seguir:

    NAME                                          TYPE     DATA   AGE
    meta-alertmanager-servicenow-webhook          Opaque   2      8h
    
  14. Configure o arquivo YAML configmap:

    kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" apply -n ${ORG:?} -f ~/meta-alertmanager-servicenow-webhook-subcomponentoverride.yaml
    

    Saída esperada:

    subcomponentoverride.lcm.private.gdc.goog/meta-alertmanager-servicenow-webhook created
    
  15. Reinicie a implantação do webhook:

    kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" rollout restart deployment/meta-alertmanager-servicenow-webhook -n mon-system
    

    A saída verifica o sucesso, como mostrado no exemplo a seguir:

    deployment.apps/meta-alertmanager-servicenow-webhook restarted
    
  16. Reinicie a implantação do webhook da pilha de monitoramento secundária:

    kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" rollout restart deployment/meta-alertmanager-servicenow-webhook -n obs-system
    

    A saída verifica o sucesso, como mostrado no exemplo a seguir:

    deployment.apps/meta-alertmanager-servicenow-webhook restarted
    
  17. Verifique os registros da implantação do meta-alertmanager-servicenow-webhook para validar a configuração:

    kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" logs deployment/meta-alertmanager-servicenow-webhook -n mon-system
    
  18. Se os registros contiverem a string listening on: :9877, a configuração estará concluída. Caso contrário, peça ajuda para resolver o problema.

Cluster de infraestrutura da organização

  1. Configure as variáveis de ambiente a seguir:

    export ROOT_KUBECONFIG=PATH_TO_ROOT_KUBECONFIG
    export INFRA_KUBECONFIG=PATH_TO_INFRA_KUBECONFIG
    

    Substitua:

    • PATH_TO_ROOT_ADMIN_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de administrador raiz
    • PATH_TO_INFRA_KUBECONFIG: o caminho do arquivo kubeconfig do cluster de infraestrutura
  2. Encontre a implantação do webhook:

    kubectl --kubeconfig "${INFRA_KUBECONFIG:?}" get deployment mon-alertmanager-servicenow-webhook-backend -n mon-system
    

    A saída precisa mostrar um status READY e ser semelhante a este exemplo:

    NAME                                          READY   UP-TO-DATE   AVAILABLE   AGE
    mon-alertmanager-servicenow-webhook-backend   1/1     1            1           8h
    
  3. Verifique se o arquivo YAML configmap existe:

    kubectl --kubeconfig "${INFRA_KUBECONFIG:?}" get configmap/mon-alertmanager-servicenow-webhook-backend -n mon-system
    

    A saída será semelhante ao exemplo a seguir:

    NAME                                         DATA   AGE
    mon-alertmanager-servicenow-webhookbackend   1      8h
    
  4. Verifique se o arquivo YAML Secret existe:

    kubectl --kubeconfig "${INFRA_KUBECONFIG:?}" get secret/mon-alertmanager-servicenow-webhook-backend -n mon-system
    

    A saída será semelhante ao exemplo a seguir:

    NAME                                          TYPE     DATA   AGE
    mon-alertmanager-servicenow-webhook-backend   Opaque   2      8h
    
  5. Configure o arquivo YAML configmap:

    kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" apply -n ${ORG:?} -f ~/mon-alertmanager-servicenow-webhook-subcomponentoverride.yaml
    

    Saída esperada:

    subcomponentoverride.lcm.private.gdc.goog/mon-alertmanager-servicenow-webhook created
    
  6. Configure a rede:

    kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" apply -n ${ORG:?} -f ~/ts-networking-subcomponentoverride.yaml
    

    Saída esperada:

    subcomponentoverride.lcm.private.gdc.goog/ts-networking created
    
  7. Reinicie a implantação do webhook:

    kubectl --kubeconfig "${INFRA_KUBECONFIG:?}" rollout restart deployment/mon-alertmanager-servicenow-webhook-backend -n mon-system
    

    A saída verifica o sucesso, como mostrado no exemplo a seguir:

    deployment.apps/mon-alertmanager-servicenow-webhook-backend restarted
    
  8. Reinicie a implantação do webhook da pilha de monitoramento secundária:

    kubectl --kubeconfig "${INFRA_KUBECONFIG:?}" rollout restart deployment/meta-alertmanager-servicenow-webhook -n obs-system
    

    A saída verifica o sucesso, como mostrado no exemplo a seguir:

    deployment.apps/alertmanager-servicenow-webhook restarted
    
  9. Verifique os registros da implantação do alertmanager-servicenow-webhook para validar a configuração:

    kubectl --kubeconfig "${INFRA_KUBECONFIG:?}" logs deployment/mon-alertmanager-servicenow-webhook-backend -n mon-system
    
  10. Se os registros contiverem a string listening on: :9877, a configuração estará concluída. Caso contrário, peça ajuda para resolver o problema.

  11. Encontre a implantação do webhook:

    kubectl --kubeconfig "${INFRA_KUBECONFIG:?}" get deployment meta-alertmanager-servicenow-webhook -n mon-system
    

    A saída precisa mostrar um status READY e ser semelhante a este exemplo:

    NAME                                          READY   UP-TO-DATE   AVAILABLE   AGE
    meta-alertmanager-servicenow-webhook          1/1     1            1           8h
    
  12. Verifique se o arquivo YAML configmap existe:

    kubectl --kubeconfig "${INFRA_KUBECONFIG:?}" get configmap/meta-alertmanager-servicenow-webhook -n mon-system
    

    A saída será semelhante ao exemplo a seguir:

    NAME                                         DATA   AGE
    meta-alertmanager-servicenow-webhook         1      8h
    
  13. Verifique se o arquivo YAML Secret existe:

    kubectl --kubeconfig "${INFRA_KUBECONFIG:?}" get secret/meta-alertmanager-servicenow-webhook -n mon-system
    

    A saída será semelhante ao exemplo a seguir:

    NAME                                          TYPE     DATA   AGE
    meta-alertmanager-servicenow-webhook          Opaque   2      8h
    
  14. Configure o arquivo YAML configmap:

    kubectl --kubeconfig "${ROOT_ADMIN_KUBECONFIG:?}" apply -n ${ORG:?} -f ~/meta-alertmanager-servicenow-webhook-subcomponentoverride.yaml
    

    Saída esperada:

    subcomponentoverride.lcm.private.gdc.goog/meta-alertmanager-servicenow-webhook created
    
  15. Reinicie a implantação do webhook:

    kubectl --kubeconfig "${INFRA_KUBECONFIG:?}" rollout restart deployment/meta-alertmanager-servicenow-webhook -n mon-system
    

    A saída verifica o sucesso, como mostrado no exemplo a seguir:

    deployment.apps/meta-alertmanager-servicenow-webhook restarted
    
  16. Reinicie a implantação do webhook da pilha de monitoramento secundária:

    kubectl --kubeconfig "${INFRA_KUBECONFIG:?}" rollout restart deployment/meta-alertmanager-servicenow-webhook -n obs-system
    

    A saída verifica o sucesso, como mostrado no exemplo a seguir:

    deployment.apps/meta-alertmanager-servicenow-webhook restarted
    
  17. Verifique os registros da implantação do meta-alertmanager-servicenow-webhook para validar a configuração:

    kubectl --kubeconfig "${INFRA_KUBECONFIG:?}" logs deployment/meta-alertmanager-servicenow-webhook -n mon-system
    
  18. Se os registros contiverem a string listening on: :9877, a configuração estará concluída. Caso contrário, peça ajuda para resolver o problema.

31.1.3. Confirmar configuração

Siga estas etapas para verificar se a configuração foi concluída:

  1. Abra o URL da interface da Web do ServiceNow:

    https://support.gdchservices.GDC_URL/navpage.do
    

    Substitua GDC_URL pelo URL da sua organização no Google Distributed Cloud (GDC) isolado por air-gap.

  2. Acesse a página Service Desk > Incidentes.

  3. Verifique se há um incidente com a descrição resumida IgnoreThisAlwaysFiringAlert para cada organização no universo do GDC.

  4. Verifique se os seguintes campos estão preenchidos no incidente:

    • Número
    • Prioridade
    • Autor da chamada
    • Código do componente
    • ID da zona
    • Estado do incidente
    • ID da organização
    • ID da zona
    • Breve descrição
    • Descrição (precisa conter uma impressão digital)