31.1. Alertmanager-ServiceNow-Webhook einrichten

Geschätzte Dauer: 2 Stunden

Eigentümer der betriebsbereiten Komponente: TS

Dieses Dokument enthält die Anleitung zum Konfigurieren des Alertmanager-ServiceNow-Webhooks, damit Sie Benachrichtigungen in der aktiven ServiceNow-Ticketing-Systeminstanz erstellen können.

31.1.1. Hinweise

Führen Sie vor dem Einrichten des ServiceNow-Webhooks die folgenden Schritte aus:

  1. Erstellen Sie das Secret midserver-secret manuell.
  2. Folgen Sie der Anleitung im TS-R0012-Runbook, um das Secret richtig einzurichten.
  3. Prüfen Sie, ob yq auf dem System installiert ist.

    root@bootstrapper:~# yq --version
    yq (https://github.com/mikefarah/yq/) version v4.40.4
    
  4. Bitten Sie Ihren Sicherheitsadministrator, Ihnen die folgenden Rollen zuzuweisen, um die Berechtigungen zu erhalten, die Sie für den Zugriff auf Objekte im Namespace obs-system und die Verwaltung der ServiceNow-Anwendung benötigen:

    • Observability Debugger (observability-admin-debugger für den Root-Administratorcluster und observability-system-debugger für den Organisationsadministrator- und Systemcluster)
    • Grafana-Betrachter (grafana-viewer)
    • ServiceNow-Administrator (system-service-now-admin)

    Weitere Informationen zu diesen Rollen finden Sie unter Rollen für Infrastrukturbetreiber.

31.1.2. Webhook einrichten

So konfigurieren Sie den Alertmanager-ServiceNow-Webhook:

  1. Sie können den ServiceNow-Webhook in einer Organisation konfigurieren.

    Wenn Sie den ServiceNow-Webhook im Systemcluster für eine Organisation konfigurieren möchten, bitten Sie Ihren Infrastructure Operator (IO), das Runbook OPA-R0005 mit den folgenden Informationen auszuführen:

    • Der Wert für die Umgebungsvariable IO_GROUP ist die Nutzergruppe, zu der Ihr Nutzer gehört.
    • Der Wert für die Umgebungsvariable CONSTRAINT_NAME ist restrict-system-project-namespace-resources.
  2. Erstellen Sie ein ServiceNow-Dienstkonto, um die Vorfälle basierend auf den Benachrichtigungen einer Organisation zu erstellen:

    1. Öffnen Sie die URL der ServiceNow-Weboberfläche:

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

      Ersetzen Sie GDC_URL durch die URL Ihrer Organisation in Google Distributed Cloud (GDC) Air-Gapped.

      Verwenden Sie immer gdchservices als Namen der IT-Organisation im Operations Center.

    2. Wählen Sie Alle > Nutzerverwaltung > Nutzer aus.

    3. Klicken Sie auf Neu.

    4. Geben Sie im neuen Fenster die folgenden Werte ein:

      • Geben Sie im Feld Nutzer-ID SVC_ALERT_ORG ein.
      • Geben Sie im Feld Vorname SVC_ALERT_ORG ein.
      • Klicken Sie das Kästchen Nur Zugriff auf Webdienste an.

      Ersetzen Sie ORG durch den Namen Ihrer Organisation. Wenn Sie diesen Schritt im Administratorcluster des Stammverzeichnisses ausführen, verwenden Sie den Wert root für den Namen ORG.

    5. Klicken Sie auf Senden.

      Der neue Nutzerdatensatz wird in der Liste der ServiceNow-Konten angezeigt.

  3. Fügen Sie dem Dienstkonto die Rolle itil hinzu.

    1. Öffnen Sie den Nutzerdatensatz aus der Liste.

    2. Klicken Sie auf den Tab Rollen und dann auf die Schaltfläche Bearbeiten….

    3. Wählen Sie im Menü Sammlung die Rolle itil aus.

    4. Klicken Sie auf die Schaltfläche Hinzufügen , um die Rolle in das Menü Rollenliste zu verschieben.

    5. Klicken Sie auf Speichern.

  4. Legen Sie das Passwort für das ServiceNow-Dienstkonto fest:

    1. Öffnen Sie den Nutzerdatensatz aus der Liste.

    2. Klicken Sie auf Passwort festlegen und dann auf Generieren.

    3. Kopieren Sie das im Fenster angezeigte Passwort und bewahren Sie es an einem sicheren Ort auf.

    4. Klicken Sie auf Passwort speichern und schließen Sie das Fenster.

  5. Öffnen Sie die Befehlszeilenschnittstelle.

  6. Legen Sie die folgenden Umgebungsvariablen fest:

    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
    

    Ersetzen Sie Folgendes:

    • ORGANIZATION: der Name Ihrer Organisation
    • SERVICENOW_INSTANCE_URL: die URL der ServiceNow-Weboberfläche, z. B. https://support.gdchservices.GDC_URL.
    • SERVICENOW_USERNAME: der Nutzername des ServiceNow-Dienstkontos
    • SERVICENOW_PASSWORD: das Passwort des ServiceNow-Dienstkontos.
    • SERVICENOW_AUTORESOLVE: „true“, wenn ServiceNow-Vorfälle automatisch geschlossen werden sollen, sobald die entsprechende Benachrichtigung nicht mehr ausgelöst wird, andernfalls „false“
    • SERVICENOW_AUTORESOLVE_REOPEN_DURATION: Die Dauer, innerhalb derer ein geschlossener ServiceNow-Vorfall wieder geöffnet werden kann, wenn dieselbe Benachrichtigung noch einmal ausgelöst wird. Beispiele: „5m“, „30s“, „24h“ usw.
  7. Führen Sie dazu diesen Befehl aus:

    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. Führen Sie die folgenden Schritte aus, um den ServiceNow-Webhook in einem Cluster zu konfigurieren:

Root-Administratorcluster

  1. Legen Sie die folgenden Umgebungsvariablen fest:

    export ROOT_KUBECONFIG=PATH_TO_ROOT_ADMIN_KUBECONFIG
    

    Ersetzen Sie Folgendes:

    • PATH_TO_ROOT_ADMIN_KUBECONFIG: der Pfad der kubeconfig-Datei für den Administratorcluster auf Stammebene
  2. Suchen Sie die Webhook-Bereitstellung:

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

    Die Ausgabe muss den Status READY enthalten und wie das folgende Beispiel aussehen:

    NAME                                          READY   UP-TO-DATE   AVAILABLE   AGE
    mon-alertmanager-servicenow-webhook-backend   1/1     1            1           8h
    
  3. Prüfen Sie, ob die configmap-YAML-Datei vorhanden ist:

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

    Die Ausgabe muss wie im folgenden Beispiel aussehen:

    NAME                                         DATA   AGE
    mon-alertmanager-servicenow-webhookbackend   1      8h
    
  4. Prüfen Sie, ob die Secret-YAML-Datei vorhanden ist:

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

    Die Ausgabe muss wie im folgenden Beispiel aussehen:

    NAME                                          TYPE     DATA   AGE
    mon-alertmanager-servicenow-webhook-backend   Opaque   2      8h
    
  5. Konfigurieren Sie die configmap-YAML-Datei:

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

    Erwartete Ausgabe:

    subcomponentoverride.lcm.private.gdc.goog/mon-alertmanager-servicenow-webhook created
    
  6. Netzwerk konfigurieren:

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

    Erwartete Ausgabe:

    subcomponentoverride.lcm.private.gdc.goog/ts-networking created
    
  7. Starten Sie die Webhook-Bereitstellung neu:

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

    Die Ausgabe bestätigt den Erfolg, wie im folgenden Beispiel zu sehen ist:

    deployment.apps/mon-alertmanager-servicenow-webhook-backend restarted
    
  8. Starten Sie die Webhook-Bereitstellung des sekundären Monitoring-Stacks neu:

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

    Die Ausgabe bestätigt den Erfolg, wie im folgenden Beispiel zu sehen ist:

    deployment.apps/alertmanager-servicenow-webhook restarted
    
  9. Prüfen Sie die Logs des alertmanager-servicenow-webhook-Deployments, um die Konfiguration zu validieren:

    kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" logs deployment/mon-alertmanager-servicenow-webhook-backend -n mon-system
    
  10. Wenn die Logs den String listening on: :9877 enthalten, ist die Konfiguration abgeschlossen. Andernfalls bitten Sie um Hilfe bei der Fehlerbehebung.

  11. Suchen Sie die Webhook-Bereitstellung:

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

    Die Ausgabe muss den Status READY enthalten und wie das folgende Beispiel aussehen:

    NAME                                          READY   UP-TO-DATE   AVAILABLE   AGE
    meta-alertmanager-servicenow-webhook          1/1     1            1           8h
    
  12. Prüfen Sie, ob die configmap-YAML-Datei vorhanden ist:

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

    Die Ausgabe muss wie im folgenden Beispiel aussehen:

    NAME                                         DATA   AGE
    meta-alertmanager-servicenow-webhook         1      8h
    
  13. Prüfen Sie, ob die Secret-YAML-Datei vorhanden ist:

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

    Die Ausgabe muss wie im folgenden Beispiel aussehen:

    NAME                                          TYPE     DATA   AGE
    meta-alertmanager-servicenow-webhook          Opaque   2      8h
    
  14. Konfigurieren Sie die configmap-YAML-Datei:

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

    Erwartete Ausgabe:

    subcomponentoverride.lcm.private.gdc.goog/meta-alertmanager-servicenow-webhook created
    
  15. Starten Sie die Webhook-Bereitstellung neu:

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

    Die Ausgabe bestätigt den Erfolg, wie im folgenden Beispiel zu sehen ist:

    deployment.apps/meta-alertmanager-servicenow-webhook restarted
    
  16. Starten Sie die Webhook-Bereitstellung des sekundären Monitoring-Stacks neu:

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

    Die Ausgabe bestätigt den Erfolg, wie im folgenden Beispiel zu sehen ist:

    deployment.apps/meta-alertmanager-servicenow-webhook restarted
    
  17. Prüfen Sie die Logs des meta-alertmanager-servicenow-webhook-Deployments, um die Konfiguration zu validieren:

    kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" logs deployment/meta-alertmanager-servicenow-webhook -n mon-system
    
  18. Wenn die Logs den String listening on: :9877 enthalten, ist die Konfiguration abgeschlossen. Andernfalls bitten Sie um Hilfe bei der Fehlerbehebung.

Cluster für die Infrastruktur der Organisation

  1. Legen Sie die folgenden Umgebungsvariablen fest:

    export ROOT_KUBECONFIG=PATH_TO_ROOT_KUBECONFIG
    export INFRA_KUBECONFIG=PATH_TO_INFRA_KUBECONFIG
    

    Ersetzen Sie Folgendes:

    • PATH_TO_ROOT_ADMIN_KUBECONFIG: der Pfad der kubeconfig-Datei für den Administratorcluster auf Stammebene
    • PATH_TO_INFRA_KUBECONFIG: der Pfad der kubeconfig-Datei für den Infrastrukturcluster
  2. Suchen Sie die Webhook-Bereitstellung:

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

    Die Ausgabe muss den Status READY enthalten und wie das folgende Beispiel aussehen:

    NAME                                          READY   UP-TO-DATE   AVAILABLE   AGE
    mon-alertmanager-servicenow-webhook-backend   1/1     1            1           8h
    
  3. Prüfen Sie, ob die configmap-YAML-Datei vorhanden ist:

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

    Die Ausgabe muss wie im folgenden Beispiel aussehen:

    NAME                                         DATA   AGE
    mon-alertmanager-servicenow-webhookbackend   1      8h
    
  4. Prüfen Sie, ob die Secret-YAML-Datei vorhanden ist:

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

    Die Ausgabe muss wie im folgenden Beispiel aussehen:

    NAME                                          TYPE     DATA   AGE
    mon-alertmanager-servicenow-webhook-backend   Opaque   2      8h
    
  5. Konfigurieren Sie die configmap-YAML-Datei:

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

    Erwartete Ausgabe:

    subcomponentoverride.lcm.private.gdc.goog/mon-alertmanager-servicenow-webhook created
    
  6. Netzwerk konfigurieren:

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

    Erwartete Ausgabe:

    subcomponentoverride.lcm.private.gdc.goog/ts-networking created
    
  7. Starten Sie die Webhook-Bereitstellung neu:

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

    Die Ausgabe bestätigt den Erfolg, wie im folgenden Beispiel zu sehen ist:

    deployment.apps/mon-alertmanager-servicenow-webhook-backend restarted
    
  8. Starten Sie die Webhook-Bereitstellung des sekundären Monitoring-Stacks neu:

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

    Die Ausgabe bestätigt den Erfolg, wie im folgenden Beispiel zu sehen ist:

    deployment.apps/alertmanager-servicenow-webhook restarted
    
  9. Prüfen Sie die Logs des alertmanager-servicenow-webhook-Deployments, um die Konfiguration zu validieren:

    kubectl --kubeconfig "${INFRA_KUBECONFIG:?}" logs deployment/mon-alertmanager-servicenow-webhook-backend -n mon-system
    
  10. Wenn die Logs den String listening on: :9877 enthalten, ist die Konfiguration abgeschlossen. Andernfalls bitten Sie um Hilfe bei der Fehlerbehebung.

  11. Suchen Sie die Webhook-Bereitstellung:

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

    Die Ausgabe muss den Status READY enthalten und wie das folgende Beispiel aussehen:

    NAME                                          READY   UP-TO-DATE   AVAILABLE   AGE
    meta-alertmanager-servicenow-webhook          1/1     1            1           8h
    
  12. Prüfen Sie, ob die configmap-YAML-Datei vorhanden ist:

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

    Die Ausgabe muss wie im folgenden Beispiel aussehen:

    NAME                                         DATA   AGE
    meta-alertmanager-servicenow-webhook         1      8h
    
  13. Prüfen Sie, ob die Secret-YAML-Datei vorhanden ist:

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

    Die Ausgabe muss wie im folgenden Beispiel aussehen:

    NAME                                          TYPE     DATA   AGE
    meta-alertmanager-servicenow-webhook          Opaque   2      8h
    
  14. Konfigurieren Sie die configmap-YAML-Datei:

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

    Erwartete Ausgabe:

    subcomponentoverride.lcm.private.gdc.goog/meta-alertmanager-servicenow-webhook created
    
  15. Starten Sie die Webhook-Bereitstellung neu:

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

    Die Ausgabe bestätigt den Erfolg, wie im folgenden Beispiel zu sehen ist:

    deployment.apps/meta-alertmanager-servicenow-webhook restarted
    
  16. Starten Sie die Webhook-Bereitstellung des sekundären Monitoring-Stacks neu:

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

    Die Ausgabe bestätigt den Erfolg, wie im folgenden Beispiel zu sehen ist:

    deployment.apps/meta-alertmanager-servicenow-webhook restarted
    
  17. Prüfen Sie die Logs des meta-alertmanager-servicenow-webhook-Deployments, um die Konfiguration zu validieren:

    kubectl --kubeconfig "${INFRA_KUBECONFIG:?}" logs deployment/meta-alertmanager-servicenow-webhook -n mon-system
    
  18. Wenn die Logs den String listening on: :9877 enthalten, ist die Konfiguration abgeschlossen. Andernfalls bitten Sie um Hilfe bei der Fehlerbehebung.

31.1.3. Konfiguration prüfen

So prüfen Sie, ob die Konfiguration erfolgreich war:

  1. Öffnen Sie die URL der ServiceNow-Weboberfläche:

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

    Ersetzen Sie GDC_URL durch die URL Ihrer Organisation in Google Distributed Cloud (GDC) Air-Gapped.

  2. Rufen Sie die Seite Service Desk > Vorfälle auf.

  3. Prüfen Sie, ob es für jede Organisation im GDC-Universum einen Vorfall mit der Kurzbeschreibung IgnoreThisAlwaysFiringAlert gibt.

  4. Prüfen Sie, ob die folgenden Felder im Vorfall ausgefüllt sind:

    • Zahl
    • Priorität
    • Anrufer
    • Komponentencode
    • Zonen-ID
    • Vorfallstatus
    • Organisations-ID
    • Zonen-ID
    • Kurzbeschreibung
    • Beschreibung (muss einen Fingerabdruck enthalten)