31.1. Configurer le webhook Alertmanager ServiceNow

Durée estimée : 2 heures

Propriétaire du composant opérationnel : TS

Ce document contient les instructions permettant de configurer le webhook Alertmanager ServiceNow et de créer des alertes dans l'instance active du système de gestion des tickets ServiceNow.

31.1.1. Avant de commencer

Avant de configurer le webhook ServiceNow, procédez comme suit :

  1. Créez manuellement le secret midserver-secret.
  2. Suivez les étapes du runbook TS-R0012 pour configurer correctement le secret.
  3. Vérifiez que yq est installé sur le système.

    root@bootstrapper:~# yq --version
    yq (https://github.com/mikefarah/yq/) version v4.40.4
    
  4. Pour obtenir les autorisations nécessaires pour accéder aux objets dans l'espace de noms obs-system et gérer l'application ServiceNow, demandez à votre administrateur de sécurité de vous accorder les rôles suivants :

    • Débogueur d'observabilité (observability-admin-debugger pour le cluster d'administrateur racine et observability-system-debugger pour les clusters d'administrateur d'organisation et système)
    • Lecteur Grafana (grafana-viewer)
    • Administrateur ServiceNow (system-service-now-admin)

    Pour en savoir plus sur ces rôles, consultez Rôles d'opérateur d'infrastructure.

31.1.2. Configurer le webhook

Pour configurer le webhook Alertmanager ServiceNow :

  1. Vous pouvez configurer le webhook ServiceNow dans une organisation.

    Si vous souhaitez configurer le webhook ServiceNow dans le cluster système d'une organisation, demandez à votre opérateur d'infrastructure (IO) d'exécuter le runbook OPA-R0005 avec les informations suivantes :

    • La valeur de la variable d'environnement IO_GROUP correspond au groupe d'utilisateurs auquel appartient votre utilisateur.
    • La valeur de la variable d'environnement CONSTRAINT_NAME est restrict-system-project-namespace-resources.
  2. Créez un compte de service ServiceNow pour créer des incidents en fonction des alertes d'une organisation :

    1. Ouvrez l'URL de l'interface Web ServiceNow :

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

      Remplacez GDC_URL par l'URL de votre organisation dans Google Distributed Cloud (GDC) air-gapped.

      Utilisez toujours gdchservices comme nom de l'organisation informatique du centre d'opérations.

    2. Sélectionnez Tous > Administration des utilisateurs > Utilisateurs.

    3. Cliquez sur New (Nouveau).

    4. Dans la nouvelle fenêtre, saisissez les valeurs suivantes :

      • Dans le champ ID utilisateur, saisissez SVC_ALERT_ORG.
      • Dans le champ Prénom, saisissez SVC_ALERT_ORG.
      • Cochez la case Web service access only (Accès au service Web uniquement).

      Remplacez ORG par le nom de votre organisation. Lorsque vous effectuez cette étape dans le cluster d'administrateur racine, utilisez la valeur root pour le nom ORG.

    5. Cliquez sur Envoyer.

      Le nouvel enregistrement utilisateur apparaît dans la liste des comptes ServiceNow.

  3. Ajoutez le rôle itil au compte de service :

    1. Ouvrez la fiche utilisateur dans la liste.

    2. Cliquez sur l'onglet Rôles, puis sur le bouton Modifier….

    3. Sélectionnez le rôle itil dans le menu Collection.

    4. Cliquez sur le bouton Ajouter () pour déplacer le rôle vers le menu Liste des rôles.

    5. Cliquez sur Enregistrer.

  4. Définissez le mot de passe du compte de service ServiceNow :

    1. Ouvrez la fiche utilisateur dans la liste.

    2. Cliquez sur Définir un mot de passe, puis sur Générer.

    3. Copiez le mot de passe affiché dans la fenêtre et stockez-le dans un endroit sûr.

    4. Cliquez sur Enregistrer le mot de passe et fermez la fenêtre.

  5. Ouvrez l'interface de ligne de commande.

  6. Définissez les variables d'environnement suivantes :

    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
    

    Remplacez les éléments suivants :

    • ORGANIZATION : nom de votre organisation
    • SERVICENOW_INSTANCE_URL : URL de l'interface Web ServiceNow, par exemple https://support.gdchservices.GDC_URL.
    • SERVICENOW_USERNAME : nom d'utilisateur du compte de service ServiceNow
    • SERVICENOW_PASSWORD : mot de passe du compte de service ServiceNow
    • SERVICENOW_AUTORESOLVE : "true" si vous souhaitez résoudre automatiquement les incidents ServiceNow une fois que l'alerte correspondante cesse de se déclencher, sinon "false"
    • SERVICENOW_AUTORESOLVE_REOPEN_DURATION : durée pendant laquelle un incident ServiceNow résolu peut être rouvert si la même alerte se déclenche à nouveau. Exemples : "5m", "30s", "24h", etc.
  7. Exécutez la commande suivante :

    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. Suivez les étapes ci-dessous pour configurer le webhook ServiceNow dans un cluster :

Cluster d'administrateur racine

  1. Définissez les variables d'environnement suivantes :

    export ROOT_KUBECONFIG=PATH_TO_ROOT_ADMIN_KUBECONFIG
    

    Remplacez les éléments suivants :

    • PATH_TO_ROOT_ADMIN_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur racine
  2. Recherchez le déploiement du webhook :

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

    Le résultat doit afficher l'état READY et ressembler à l'exemple suivant :

    NAME                                          READY   UP-TO-DATE   AVAILABLE   AGE
    mon-alertmanager-servicenow-webhook-backend   1/1     1            1           8h
    
  3. Vérifiez si le fichier YAML configmap existe :

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

    Le résultat doit ressembler à l'exemple suivant :

    NAME                                         DATA   AGE
    mon-alertmanager-servicenow-webhookbackend   1      8h
    
  4. Vérifiez si le fichier YAML Secret existe :

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

    Le résultat doit ressembler à l'exemple suivant :

    NAME                                          TYPE     DATA   AGE
    mon-alertmanager-servicenow-webhook-backend   Opaque   2      8h
    
  5. Configurez le fichier YAML configmap :

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

    Résultat attendu :

    subcomponentoverride.lcm.private.gdc.goog/mon-alertmanager-servicenow-webhook created
    
  6. Configurez la mise en réseau :

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

    Résultat attendu :

    subcomponentoverride.lcm.private.gdc.goog/ts-networking created
    
  7. Redémarrez le déploiement du webhook :

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

    Le résultat confirme la réussite de l'opération, comme dans l'exemple suivant :

    deployment.apps/mon-alertmanager-servicenow-webhook-backend restarted
    
  8. Redémarrez le déploiement du webhook de la pile de surveillance secondaire :

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

    Le résultat confirme la réussite de l'opération, comme dans l'exemple suivant :

    deployment.apps/alertmanager-servicenow-webhook restarted
    
  9. Vérifiez les journaux du déploiement alertmanager-servicenow-webhook pour valider la configuration :

    kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" logs deployment/mon-alertmanager-servicenow-webhook-backend -n mon-system
    
  10. Si les journaux contiennent la chaîne listening on: :9877, la configuration est terminée. Sinon, demandez de l'aide pour résoudre le problème.

  11. Recherchez le déploiement du webhook :

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

    Le résultat doit afficher l'état READY et ressembler à l'exemple suivant :

    NAME                                          READY   UP-TO-DATE   AVAILABLE   AGE
    meta-alertmanager-servicenow-webhook          1/1     1            1           8h
    
  12. Vérifiez si le fichier YAML configmap existe :

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

    Le résultat doit ressembler à l'exemple suivant :

    NAME                                         DATA   AGE
    meta-alertmanager-servicenow-webhook         1      8h
    
  13. Vérifiez si le fichier YAML Secret existe :

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

    Le résultat doit ressembler à l'exemple suivant :

    NAME                                          TYPE     DATA   AGE
    meta-alertmanager-servicenow-webhook          Opaque   2      8h
    
  14. Configurez le fichier YAML configmap :

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

    Résultat attendu :

    subcomponentoverride.lcm.private.gdc.goog/meta-alertmanager-servicenow-webhook created
    
  15. Redémarrez le déploiement du webhook :

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

    Le résultat confirme la réussite de l'opération, comme dans l'exemple suivant :

    deployment.apps/meta-alertmanager-servicenow-webhook restarted
    
  16. Redémarrez le déploiement du webhook de la pile de surveillance secondaire :

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

    Le résultat confirme la réussite de l'opération, comme dans l'exemple suivant :

    deployment.apps/meta-alertmanager-servicenow-webhook restarted
    
  17. Vérifiez les journaux du déploiement meta-alertmanager-servicenow-webhook pour valider la configuration :

    kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" logs deployment/meta-alertmanager-servicenow-webhook -n mon-system
    
  18. Si les journaux contiennent la chaîne listening on: :9877, la configuration est terminée. Sinon, demandez de l'aide pour résoudre le problème.

Cluster d'infrastructure d'organisation

  1. Définissez les variables d'environnement suivantes :

    export ROOT_KUBECONFIG=PATH_TO_ROOT_KUBECONFIG
    export INFRA_KUBECONFIG=PATH_TO_INFRA_KUBECONFIG
    

    Remplacez les éléments suivants :

    • PATH_TO_ROOT_ADMIN_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'administrateur racine
    • PATH_TO_INFRA_KUBECONFIG : chemin d'accès au fichier kubeconfig du cluster d'infrastructure
  2. Recherchez le déploiement du webhook :

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

    Le résultat doit afficher l'état READY et ressembler à l'exemple suivant :

    NAME                                          READY   UP-TO-DATE   AVAILABLE   AGE
    mon-alertmanager-servicenow-webhook-backend   1/1     1            1           8h
    
  3. Vérifiez si le fichier YAML configmap existe :

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

    Le résultat doit ressembler à l'exemple suivant :

    NAME                                         DATA   AGE
    mon-alertmanager-servicenow-webhookbackend   1      8h
    
  4. Vérifiez si le fichier YAML Secret existe :

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

    Le résultat doit ressembler à l'exemple suivant :

    NAME                                          TYPE     DATA   AGE
    mon-alertmanager-servicenow-webhook-backend   Opaque   2      8h
    
  5. Configurez le fichier YAML configmap :

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

    Résultat attendu :

    subcomponentoverride.lcm.private.gdc.goog/mon-alertmanager-servicenow-webhook created
    
  6. Configurez la mise en réseau :

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

    Résultat attendu :

    subcomponentoverride.lcm.private.gdc.goog/ts-networking created
    
  7. Redémarrez le déploiement du webhook :

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

    Le résultat confirme la réussite de l'opération, comme dans l'exemple suivant :

    deployment.apps/mon-alertmanager-servicenow-webhook-backend restarted
    
  8. Redémarrez le déploiement du webhook de la pile de surveillance secondaire :

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

    Le résultat confirme la réussite de l'opération, comme dans l'exemple suivant :

    deployment.apps/alertmanager-servicenow-webhook restarted
    
  9. Vérifiez les journaux du déploiement alertmanager-servicenow-webhook pour valider la configuration :

    kubectl --kubeconfig "${INFRA_KUBECONFIG:?}" logs deployment/mon-alertmanager-servicenow-webhook-backend -n mon-system
    
  10. Si les journaux contiennent la chaîne listening on: :9877, la configuration est terminée. Sinon, demandez de l'aide pour résoudre le problème.

  11. Recherchez le déploiement du webhook :

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

    Le résultat doit afficher l'état READY et ressembler à l'exemple suivant :

    NAME                                          READY   UP-TO-DATE   AVAILABLE   AGE
    meta-alertmanager-servicenow-webhook          1/1     1            1           8h
    
  12. Vérifiez si le fichier YAML configmap existe :

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

    Le résultat doit ressembler à l'exemple suivant :

    NAME                                         DATA   AGE
    meta-alertmanager-servicenow-webhook         1      8h
    
  13. Vérifiez si le fichier YAML Secret existe :

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

    Le résultat doit ressembler à l'exemple suivant :

    NAME                                          TYPE     DATA   AGE
    meta-alertmanager-servicenow-webhook          Opaque   2      8h
    
  14. Configurez le fichier YAML configmap :

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

    Résultat attendu :

    subcomponentoverride.lcm.private.gdc.goog/meta-alertmanager-servicenow-webhook created
    
  15. Redémarrez le déploiement du webhook :

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

    Le résultat confirme la réussite de l'opération, comme dans l'exemple suivant :

    deployment.apps/meta-alertmanager-servicenow-webhook restarted
    
  16. Redémarrez le déploiement du webhook de la pile de surveillance secondaire :

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

    Le résultat confirme la réussite de l'opération, comme dans l'exemple suivant :

    deployment.apps/meta-alertmanager-servicenow-webhook restarted
    
  17. Vérifiez les journaux du déploiement meta-alertmanager-servicenow-webhook pour valider la configuration :

    kubectl --kubeconfig "${INFRA_KUBECONFIG:?}" logs deployment/meta-alertmanager-servicenow-webhook -n mon-system
    
  18. Si les journaux contiennent la chaîne listening on: :9877, la configuration est terminée. Sinon, demandez de l'aide pour résoudre le problème.

31.1.3. Vérifier la configuration

Suivez ces étapes pour vérifier que la configuration a réussi :

  1. Ouvrez l'URL de l'interface Web ServiceNow :

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

    Remplacez GDC_URL par l'URL de votre organisation dans Google Distributed Cloud (GDC) air-gapped.

  2. Accédez à la page Service Desk > Incidents.

  3. Vérifiez qu'il existe un incident avec la brève description IgnoreThisAlwaysFiringAlert pour chaque organisation de l'univers GDC.

  4. Vérifiez que les champs suivants sont renseignés dans l'incident :

    • Nombre
    • Priorité
    • Appelant
    • Code du composant
    • ID de zone
    • État de l'incident
    • ID de l'organisation
    • ID de zone
    • Brève description
    • Description (elle doit contenir une empreinte digitale)