Azure Change-Verarbeitung

  • Freigeben Version: Washingtondc
  • Aktualisiert 1. Februar 2024
  • 4 Minuten Lesedauer

    • Die Change-Verarbeitung Azure erfasst Informationen über die Ressourcen Microsoft Azure, die eine Änderung des Lebenszyklusstatus oder der Konfiguration erfahren haben. Anschließend werden die erfassten Informationen verwendet, um Configuration Management Database (CMDB)zu aktualisieren.

    Abbildung : 1. Übersicht über die Azure-Change-Verarbeitung
    Zeigt den Azure-Flow zur Change-Verarbeitung an.

    Die geplante Aufgabe „ Azure Prozessänderungen“ fragt die API für Ressourcenänderungen Azure ab und erfasst die Informationen zu Ressourcenänderungen. Während jedes Ausführungszyklus erfasst die regelmäßige Aufgabe Informationen über alle Ressourcen, die sich zwischen der letzten erfolgreichen Ausführung des Zeitplans und der aktuellen Ausführung des Zeitplans geändert haben. Nach dem Empfang der Change-Informationen verwendet die Change-Verarbeitung von Azure Antwortzuordnungen, um die Change-Informationen in der CMDBzu aktualisieren. Während der nächsten Erkennung löst Cloud-Discovery die entsprechenden Muster aus, sofern verfügbar, und füllt detaillierte Ressourceninformationen in CMDB.

    Standardmäßig wird die geplante Aufgabe Azure Changes verarbeiten alle 10 Minuten in ausgeführt. Aktualisieren Sie bei Bedarf die Ausführungshäufigkeit des Zeitplans entsprechend Ihren Anforderungen. Stellen Sie sicher, dass die neue Ausführungshäufigkeit innerhalb des folgenden Bereichs liegt:
    • Mindestwert: 1 Minute
    • Höchstwert: In der Eigenschaft sn_cmp.azure.change_enquiry.max_frequency_in_hours definierter Wert.
    Sie können die standardmäßige Ausführungshäufigkeit der geplanten Aufgabe Azure Changes verarbeiten reduzieren, um die Aktualisierungen von CMDB ] zu beschleunigen.

    Wenn Sie die Change-Verarbeitung Azure zum ersten Mal ausführen, kann dies bis zu vier Stunden dauern. Sie können den standardmäßigen maximalen Zeitplanausführungszeitraum ändern, indem Sie die Eigenschaft sn_cmp.azure.change_enquiry.max_frequency_in_hours festlegen. Wenn Sie den Ausführungszeitraum des Standardzeitplans verlängern möchten, stellen Sie sicher, dass genügend Worker-Knoten zum Ausführen des Zeitplans verfügbar sind.

    Während der Eventverarbeitung identifiziert der Cloud Event Scheduler die Domäne des Serviceaccounts und weist sie dem Event zu. Wenn beim Identifizieren der Domäne vor der Verarbeitung ein Fehler auftritt, kann das Event manchmal nicht zugewiesen werden und wird für alle Domänen sichtbar. Um zu verhindern, dass die fehlgeschlagenen Events für alle Domänen sichtbar sind, können Sie die Eigenschaft sn_cmp.error_events.default_domain auf die sys_id der Service Provider-Domäne festlegen, sodass die fehlgeschlagenen Events nur dem Domänenadministrator des Service Providers angezeigt werden.

    Hinweis:

    Azure Die Change-Verarbeitung kann Ressourcen-Change-Informationen nur aus den Servicekonten abrufen, die von discovery_admin oder sn_cmp.cloud_admin erstellt wurden.

    API-Pfad- und -Fehlerprotokolle

    Die Azure -Change-Verarbeitung verwendet einen MID-Server, um die Azure -Endpunkte aufzurufen und die Ressourcen-Change-Informationen zu erfassen. Sie protokolliert die API-Aufrufe und die Antwort in der Tabelle „CAPI-Pfade“ [sn_capi_api_trail].

    Die Tabelle „Nutzlastinformationen für Ressourcenänderungen“ [sn_cmp_resource_changes_payload_info] enthält die folgenden Statistiken zu den empfangenen Änderungen:
    • Gesamtanzahl: Anzahl der in der Change-Nutzlast empfangenen Changes.
    • Verarbeitete Anzahl: Anzahl der verarbeiteten Changes.
    • Anzahl übersprungen: Anzahl der übersprungenen Änderungen.
    • Fehleranzahl: Anzahl der Änderungen, die aufgrund eines Fehlers nicht verarbeitet werden konnten. Auf der Registerkarte „Event Trails“ des Datensatzes „Resource Changes Payload Info“ werden die folgenden Informationen zum fehlerhaften Change angezeigt:
      • Betroffene Nutzlast: Der Change, der bei der Azure-Change-Verarbeitung nicht verarbeitet werden konnte.
      • Change-Zeit: Zeitstempel des fehlgeschlagenen Change.
      • Change-Typ: Typ des Vorgangs, der zum Erfassen des Change in CMDBerforderlich ist.
      • Fehlerursache: Link zum Fehlerprotokoll.
      Azure Die Change-Verarbeitung zeichnet die fehlerhaften Änderungen in der Event-Pfadtabelle [sn_cmp_event_trail] auf.
    Hinweis:
    Nur discovery_admin oder sn_cmp.cloud_admin kann auf die Tabelle „Nutzlastinformationen für Ressourcenänderungen“ [sn_cmp_resource_changes_payload_info] zugreifen.

    Unterstützte Ressourcentypen und -änderungen Azure .

    Die Eigenschaft mid.cmp.azure.event.supported_resource_types speichert eine durch Kommas getrennte Liste aller Ressourcentypen Azure, für die die Change-Verarbeitung unterstützt wird.

    Tabelle : 1. Unterstützte Azure Ressourcentypen
    Ressourcentyp Unterstützte Ressourcenänderungen
    Microsoft.Compute/virtualMachine
    • computerName
    • osVersion
    • OsName
    • Powerstate
    Microsoft.Compute/Datenträger Datenträger: Fügen Sie einen Datenträger zu einem vorhandenen virtuellen Computer hinzu.
    • diskSizeGB
    • Caching
    • createVorgang
    • deleteVorgang
    • Lun
    • verwaltenDisk.id
    BS-Datenträger
    • Stufe
    • diskState
    Microsoft.Netzwerk/networkSecurityGroups
    • ipConfigurations[0].etag
    • virtualMachine.id
    • Primär
    • macAddress
    • resourceGuid
    Microsoft.Netzwerk/networkinterfaces networkInterfaces[0].id
    Microsoft.Netzwerk/publicIPAddresses
    • ipAddress
    • resourceGuid

    Weitere Informationen zum Hinzufügen von Unterstützung für einen Azure -Ressourcentyp finden Sie unter Fügen Sie Unterstützung für die Change-Verarbeitung für einen Ressourcentyp Azure hinzu.

    Vorteile der Change-Verarbeitung von Azure .

    Die Change-Verarbeitung von Azure bietet gegenüber der warnungsgesteuerten Erkennung von Microsoft Azure folgende Vorteile:
    • Verbesserte Leistung und geringere Wahrscheinlichkeit einer Azure API-Drosselung
    • Einfaches Setup
    Verbesserte Leistung und geringere Wahrscheinlichkeit einer Azure API-Drosselung
    Die warnungsgesteuerte Erkennung Microsoft Azure löst eine gezielte Erkennung für jede betroffene Ressource aus. Wenn Now Platform eine große Anzahl von Warnungen erhält, kann die gezielte Erkennung daher zu einer Drosselung der Azure -APIs führen. Dadurch kann die Leistung der Warnungsverarbeitung von Now Platform sinken. Im Gegensatz dazu löst die Change-Verarbeitung Azure keine gezielte Erkennung für jede betroffene Ressource aus. Stattdessen werden Antwortzuordnungen verwendet, um die CMDB anhand der verfügbaren Change-Informationen zu aktualisieren. Während der nächsten Erkennung löst Cloud-Discovery die entsprechenden Muster aus, sofern verfügbar, und füllt detaillierte Ressourceninformationen in CMDB. Daher verbessert die Change-Verarbeitung von Azure die Change-Verarbeitungsleistung von Now Platform und reduziert die Wahrscheinlichkeit einer API-Drosselung von Azure.
    Einfaches Setup
    Die warnungsgesteuerte Erkennung Microsoft Azure verwendet einen Webhook, um die Warnungen an Now Platformzu senden. Da die Cloud Azure Warnungen auf Abonnementebene generiert, benötigt die warnungsbasierte Erkennung von Microsoft Azure für jedes Abonnement, das Sie überwachen möchten, einen Webhook. Im Gegensatz dazu verwendet die Change-Verarbeitung Azure CAPI und MID-Server [], um mit der API für Ressourcenänderungen Azure zu interagieren. Die API kann Change-Informationen auf Verwaltungsgruppenebene bereitstellen. Daher macht die Change-Verarbeitung Azure Webhooks überflüssig und vereinfacht das Setup.

    Sie können die Azure-Change-Verarbeitung so konfigurieren, dass Informationen zu Ressourcenänderungen aus der Cloud Microsoft Azure abgerufen und zum Aktualisieren der Cloud CMDBverwendet werden.

    Wenn Sie die warnungsbasierte Erkennung von Microsoft Azure verwenden, können Sie zur Azure-Change-Verarbeitung migrieren, um die Leistung der Change-Verarbeitung von Now Platform zu verbessern und das vereinfachte Setup zu nutzen.