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:
- Erstellen Sie das Secret
midserver-secretmanuell. - Folgen Sie der Anleitung im TS-R0012-Runbook, um das Secret richtig einzurichten.
Prüfen Sie, ob
yqauf dem System installiert ist.root@bootstrapper:~# yq --version yq (https://github.com/mikefarah/yq/) version v4.40.4Bitten Sie Ihren Sicherheitsadministrator, Ihnen die folgenden Rollen zuzuweisen, um die Berechtigungen zu erhalten, die Sie für den Zugriff auf Objekte im Namespace
obs-systemund die Verwaltung der ServiceNow-Anwendung benötigen:- Observability Debugger (
observability-admin-debuggerfür den Root-Administratorcluster undobservability-system-debuggerfü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.
- Observability Debugger (
31.1.2. Webhook einrichten
So konfigurieren Sie den Alertmanager-ServiceNow-Webhook:
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_GROUPist die Nutzergruppe, zu der Ihr Nutzer gehört. - Der Wert für die Umgebungsvariable
CONSTRAINT_NAMEistrestrict-system-project-namespace-resources.
- Der Wert für die Umgebungsvariable
Erstellen Sie ein ServiceNow-Dienstkonto, um die Vorfälle basierend auf den Benachrichtigungen einer Organisation zu erstellen:
Öffnen Sie die URL der ServiceNow-Weboberfläche:
https://support.gdchservices.GDC_URL/navpage.doErsetzen Sie
GDC_URLdurch die URL Ihrer Organisation in Google Distributed Cloud (GDC) Air-Gapped.Verwenden Sie immer
gdchservicesals Namen der IT-Organisation im Operations Center.Wählen Sie Alle > Nutzerverwaltung > Nutzer aus.
Klicken Sie auf Neu.
Geben Sie im neuen Fenster die folgenden Werte ein:
- Geben Sie im Feld Nutzer-ID
SVC_ALERT_ORGein. - Geben Sie im Feld Vorname
SVC_ALERT_ORGein. - Klicken Sie das Kästchen Nur Zugriff auf Webdienste an.
Ersetzen Sie
ORGdurch den Namen Ihrer Organisation. Wenn Sie diesen Schritt im Administratorcluster des Stammverzeichnisses ausführen, verwenden Sie den Wertrootfür den NamenORG.- Geben Sie im Feld Nutzer-ID
Klicken Sie auf Senden.
Der neue Nutzerdatensatz wird in der Liste der ServiceNow-Konten angezeigt.
Fügen Sie dem Dienstkonto die Rolle
itilhinzu.Öffnen Sie den Nutzerdatensatz aus der Liste.
Klicken Sie auf den Tab Rollen und dann auf die Schaltfläche Bearbeiten….
Wählen Sie im Menü Sammlung die Rolle
itilaus.Klicken Sie auf die Schaltfläche Hinzufügen , um die Rolle in das Menü Rollenliste zu verschieben.
Klicken Sie auf Speichern.
Legen Sie das Passwort für das ServiceNow-Dienstkonto fest:
Öffnen Sie den Nutzerdatensatz aus der Liste.
Klicken Sie auf Passwort festlegen und dann auf Generieren.
Kopieren Sie das im Fenster angezeigte Passwort und bewahren Sie es an einem sicheren Ort auf.
Klicken Sie auf Passwort speichern und schließen Sie das Fenster.
Öffnen Sie die Befehlszeilenschnittstelle.
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_DURATIONErsetzen Sie Folgendes:
ORGANIZATION: der Name Ihrer OrganisationSERVICENOW_INSTANCE_URL: die URL der ServiceNow-Weboberfläche, z. B.https://support.gdchservices.GDC_URL.SERVICENOW_USERNAME: der Nutzername des ServiceNow-DienstkontosSERVICENOW_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.
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:?} EOFFühren Sie die folgenden Schritte aus, um den ServiceNow-Webhook in einem Cluster zu konfigurieren:
Root-Administratorcluster
Legen Sie die folgenden Umgebungsvariablen fest:
export ROOT_KUBECONFIG=PATH_TO_ROOT_ADMIN_KUBECONFIGErsetzen Sie Folgendes:
PATH_TO_ROOT_ADMIN_KUBECONFIG: der Pfad der kubeconfig-Datei für den Administratorcluster auf Stammebene
Suchen Sie die Webhook-Bereitstellung:
kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" get deployment mon-alertmanager-servicenow-webhook-backend -n mon-systemDie Ausgabe muss den Status
READYenthalten und wie das folgende Beispiel aussehen:NAME READY UP-TO-DATE AVAILABLE AGE mon-alertmanager-servicenow-webhook-backend 1/1 1 1 8hPrüfen Sie, ob die
configmap-YAML-Datei vorhanden ist:kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" get configmap/mon-alertmanager-servicenow-webhook-backend -n mon-systemDie Ausgabe muss wie im folgenden Beispiel aussehen:
NAME DATA AGE mon-alertmanager-servicenow-webhookbackend 1 8hPrüfen Sie, ob die
Secret-YAML-Datei vorhanden ist:kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" get secret/mon-alertmanager-servicenow-webhook-backend -n mon-systemDie Ausgabe muss wie im folgenden Beispiel aussehen:
NAME TYPE DATA AGE mon-alertmanager-servicenow-webhook-backend Opaque 2 8hKonfigurieren Sie die
configmap-YAML-Datei:kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" apply -n root -f ~/mon-alertmanager-servicenow-webhook-subcomponentoverride.yamlErwartete Ausgabe:
subcomponentoverride.lcm.private.gdc.goog/mon-alertmanager-servicenow-webhook createdNetzwerk konfigurieren:
kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" apply -n root -f ~/ts-networking-subcomponentoverride.yamlErwartete Ausgabe:
subcomponentoverride.lcm.private.gdc.goog/ts-networking createdStarten Sie die Webhook-Bereitstellung neu:
kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" rollout restart deployment/mon-alertmanager-servicenow-webhook-backend -n mon-systemDie Ausgabe bestätigt den Erfolg, wie im folgenden Beispiel zu sehen ist:
deployment.apps/mon-alertmanager-servicenow-webhook-backend restartedStarten Sie die Webhook-Bereitstellung des sekundären Monitoring-Stacks neu:
kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" rollout restart deployment/meta-alertmanager-servicenow-webhook -n obs-systemDie Ausgabe bestätigt den Erfolg, wie im folgenden Beispiel zu sehen ist:
deployment.apps/alertmanager-servicenow-webhook restartedPrü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-systemWenn die Logs den String
listening on: :9877enthalten, ist die Konfiguration abgeschlossen. Andernfalls bitten Sie um Hilfe bei der Fehlerbehebung.Suchen Sie die Webhook-Bereitstellung:
kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" get deployment meta-alertmanager-servicenow-webhook -n mon-systemDie Ausgabe muss den Status
READYenthalten und wie das folgende Beispiel aussehen:NAME READY UP-TO-DATE AVAILABLE AGE meta-alertmanager-servicenow-webhook 1/1 1 1 8hPrüfen Sie, ob die
configmap-YAML-Datei vorhanden ist:kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" get configmap/meta-alertmanager-servicenow-webhook -n mon-systemDie Ausgabe muss wie im folgenden Beispiel aussehen:
NAME DATA AGE meta-alertmanager-servicenow-webhook 1 8hPrüfen Sie, ob die
Secret-YAML-Datei vorhanden ist:kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" get secret/meta-alertmanager-servicenow-webhook -n mon-systemDie Ausgabe muss wie im folgenden Beispiel aussehen:
NAME TYPE DATA AGE meta-alertmanager-servicenow-webhook Opaque 2 8hKonfigurieren Sie die
configmap-YAML-Datei:kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" apply -n ${ORG:?} -f ~/meta-alertmanager-servicenow-webhook-subcomponentoverride.yamlErwartete Ausgabe:
subcomponentoverride.lcm.private.gdc.goog/meta-alertmanager-servicenow-webhook createdStarten Sie die Webhook-Bereitstellung neu:
kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" rollout restart deployment/meta-alertmanager-servicenow-webhook -n mon-systemDie Ausgabe bestätigt den Erfolg, wie im folgenden Beispiel zu sehen ist:
deployment.apps/meta-alertmanager-servicenow-webhook restartedStarten Sie die Webhook-Bereitstellung des sekundären Monitoring-Stacks neu:
kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" rollout restart deployment/meta-alertmanager-servicenow-webhook -n obs-systemDie Ausgabe bestätigt den Erfolg, wie im folgenden Beispiel zu sehen ist:
deployment.apps/meta-alertmanager-servicenow-webhook restartedPrü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-systemWenn die Logs den String
listening on: :9877enthalten, ist die Konfiguration abgeschlossen. Andernfalls bitten Sie um Hilfe bei der Fehlerbehebung.
Cluster für die Infrastruktur der Organisation
Legen Sie die folgenden Umgebungsvariablen fest:
export ROOT_KUBECONFIG=PATH_TO_ROOT_KUBECONFIG export INFRA_KUBECONFIG=PATH_TO_INFRA_KUBECONFIGErsetzen Sie Folgendes:
PATH_TO_ROOT_ADMIN_KUBECONFIG: der Pfad der kubeconfig-Datei für den Administratorcluster auf StammebenePATH_TO_INFRA_KUBECONFIG: der Pfad der kubeconfig-Datei für den Infrastrukturcluster
Suchen Sie die Webhook-Bereitstellung:
kubectl --kubeconfig "${INFRA_KUBECONFIG:?}" get deployment mon-alertmanager-servicenow-webhook-backend -n mon-systemDie Ausgabe muss den Status
READYenthalten und wie das folgende Beispiel aussehen:NAME READY UP-TO-DATE AVAILABLE AGE mon-alertmanager-servicenow-webhook-backend 1/1 1 1 8hPrüfen Sie, ob die
configmap-YAML-Datei vorhanden ist:kubectl --kubeconfig "${INFRA_KUBECONFIG:?}" get configmap/mon-alertmanager-servicenow-webhook-backend -n mon-systemDie Ausgabe muss wie im folgenden Beispiel aussehen:
NAME DATA AGE mon-alertmanager-servicenow-webhookbackend 1 8hPrüfen Sie, ob die
Secret-YAML-Datei vorhanden ist:kubectl --kubeconfig "${INFRA_KUBECONFIG:?}" get secret/mon-alertmanager-servicenow-webhook-backend -n mon-systemDie Ausgabe muss wie im folgenden Beispiel aussehen:
NAME TYPE DATA AGE mon-alertmanager-servicenow-webhook-backend Opaque 2 8hKonfigurieren Sie die
configmap-YAML-Datei:kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" apply -n ${ORG:?} -f ~/mon-alertmanager-servicenow-webhook-subcomponentoverride.yamlErwartete Ausgabe:
subcomponentoverride.lcm.private.gdc.goog/mon-alertmanager-servicenow-webhook createdNetzwerk konfigurieren:
kubectl --kubeconfig "${ROOT_KUBECONFIG:?}" apply -n ${ORG:?} -f ~/ts-networking-subcomponentoverride.yamlErwartete Ausgabe:
subcomponentoverride.lcm.private.gdc.goog/ts-networking createdStarten Sie die Webhook-Bereitstellung neu:
kubectl --kubeconfig "${INFRA_KUBECONFIG:?}" rollout restart deployment/mon-alertmanager-servicenow-webhook-backend -n mon-systemDie Ausgabe bestätigt den Erfolg, wie im folgenden Beispiel zu sehen ist:
deployment.apps/mon-alertmanager-servicenow-webhook-backend restartedStarten Sie die Webhook-Bereitstellung des sekundären Monitoring-Stacks neu:
kubectl --kubeconfig "${INFRA_KUBECONFIG:?}" rollout restart deployment/meta-alertmanager-servicenow-webhook -n obs-systemDie Ausgabe bestätigt den Erfolg, wie im folgenden Beispiel zu sehen ist:
deployment.apps/alertmanager-servicenow-webhook restartedPrü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-systemWenn die Logs den String
listening on: :9877enthalten, ist die Konfiguration abgeschlossen. Andernfalls bitten Sie um Hilfe bei der Fehlerbehebung.Suchen Sie die Webhook-Bereitstellung:
kubectl --kubeconfig "${INFRA_KUBECONFIG:?}" get deployment meta-alertmanager-servicenow-webhook -n mon-systemDie Ausgabe muss den Status
READYenthalten und wie das folgende Beispiel aussehen:NAME READY UP-TO-DATE AVAILABLE AGE meta-alertmanager-servicenow-webhook 1/1 1 1 8hPrüfen Sie, ob die
configmap-YAML-Datei vorhanden ist:kubectl --kubeconfig "${INFRA_KUBECONFIG:?}" get configmap/meta-alertmanager-servicenow-webhook -n mon-systemDie Ausgabe muss wie im folgenden Beispiel aussehen:
NAME DATA AGE meta-alertmanager-servicenow-webhook 1 8hPrüfen Sie, ob die
Secret-YAML-Datei vorhanden ist:kubectl --kubeconfig "${INFRA_KUBECONFIG:?}" get secret/meta-alertmanager-servicenow-webhook -n mon-systemDie Ausgabe muss wie im folgenden Beispiel aussehen:
NAME TYPE DATA AGE meta-alertmanager-servicenow-webhook Opaque 2 8hKonfigurieren Sie die
configmap-YAML-Datei:kubectl --kubeconfig "${ROOT_ADMIN_KUBECONFIG:?}" apply -n ${ORG:?} -f ~/meta-alertmanager-servicenow-webhook-subcomponentoverride.yamlErwartete Ausgabe:
subcomponentoverride.lcm.private.gdc.goog/meta-alertmanager-servicenow-webhook createdStarten Sie die Webhook-Bereitstellung neu:
kubectl --kubeconfig "${INFRA_KUBECONFIG:?}" rollout restart deployment/meta-alertmanager-servicenow-webhook -n mon-systemDie Ausgabe bestätigt den Erfolg, wie im folgenden Beispiel zu sehen ist:
deployment.apps/meta-alertmanager-servicenow-webhook restartedStarten Sie die Webhook-Bereitstellung des sekundären Monitoring-Stacks neu:
kubectl --kubeconfig "${INFRA_KUBECONFIG:?}" rollout restart deployment/meta-alertmanager-servicenow-webhook -n obs-systemDie Ausgabe bestätigt den Erfolg, wie im folgenden Beispiel zu sehen ist:
deployment.apps/meta-alertmanager-servicenow-webhook restartedPrü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-systemWenn die Logs den String
listening on: :9877enthalten, 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:
Öffnen Sie die URL der ServiceNow-Weboberfläche:
https://support.gdchservices.GDC_URL/navpage.doErsetzen Sie
GDC_URLdurch die URL Ihrer Organisation in Google Distributed Cloud (GDC) Air-Gapped.Rufen Sie die Seite Service Desk > Vorfälle auf.
Prüfen Sie, ob es für jede Organisation im GDC-Universum einen Vorfall mit der Kurzbeschreibung
IgnoreThisAlwaysFiringAlertgibt.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)