Überblick über Connector Hub

Mit dem Connector Hub-Service können Sie Daten zwischen Services in Oracle Cloud Infrastructure übertragen.

Connector Hub ist eine Cloud-Nachrichtenbusplattform, die beim Verschieben von Daten zwischen Oracle Cloud Infrastructure-Services einen zentralen Einblick für das Beschreiben, Ausführen und Überwachen von Interaktionen bietet. Connector Hub wird früher als Service Connector Hub bezeichnet.

Tipp

Sehen Sie sich ein Einführungsvideo zum Service an.
Datenverschiebung zwischen Services in Oracle Cloud Infrastructure.

Unterstützte Ziele für jede Quelle

Im Folgenden werden unterstützte Ziele für jede Quelle aufgeführt.

Die Loggingaufgabe wird nur von der Loggingquelle unterstützt. Die Functions-Aufgabe wird unterstützt, mit Ausnahme von Sternchen (*).

Quelle Ziel
Functions Loganalyse Monitoring Benachrichtigungen Object Storage Streaming
Protokollierung
Überwachung - - -
Warteschlange - - ✔*
Streaming - ✔*

*Die Aufgabe "Funktionen" wird für diese Kombination aus Quelle und Ziel nicht unterstützt.

Funktionsweise von Connector Hub

Connector Hub orchestriert das Verschieben von Daten zwischen Services in Oracle Cloud Infrastructure.

Daten werden mit Connectors verschoben. Ein Connector gibt den Quellservice an, der die zu verschiebenden Daten enthält, optionale Aufgaben sowie den Zielservice, an den die Daten nach Abschluss der Aufgaben übermittelt werden. Eine optionale Aufgabe kann eine Funktionsaufgabe sein, mit der Daten aus der Quelle verarbeitet werden, oder eine Logfilteraufgabe, mit der Logdaten aus der Quelle gefiltert werden.

Geschwindigkeit der Datenverschiebung

Der Connector liest Daten, sobald sie verfügbar sind. Die Übermittlung an den Zielservice kann durch Aggregation oder Pufferung verzögert werden. Beispiel: Metrikdatenpunkte müssen zuerst aggregiert werden.

Während Connectors kontinuierlich ausgeführt werden, werden Daten durch einzelne Verschiebevorgänge sequenziell verschoben. Die Datenmenge und die Geschwindigkeit jedes Verschiebevorgangs hängen von der Connector-Konfiguration (Quelle, Aufgabe und Ziel) und den relevanten Servicelimits ab. Relevante Servicelimits werden durch die für Quelle, Aufgabe und Ziel ausgewählten Services sowie durch die Limits für Connector Hub bestimmt.

Beispiel 1: Logging-Quelle, Notifications-Ziel (keine Aufgabe)

Beispiel 1: Logging-Quelle, Notifications-Ziel (keine Aufgabe).

Callouts für Beispiel 1
Zahl Beschreibung
1 Connector Hub liest Logdaten aus Logging.
2 Connector Hub schreibt die Logdaten in den Notifications-Zielservice.
3 Notifications sendet Nachrichten an alle Abonnements im konfigurierten Thema.

Bei jedem Verschiebevorgang werden Daten aus den Logquellen in das Thema verschoben, unter Beachtung der Servicelimits und mit einer Geschwindigkeit, die von den Abonnementtypen im ausgewählten Thema abhängig ist. In diesem Szenario kann es ein paar Minuten dauern, bis die Logquellen bei einem einzelnen Verschiebevorgang verschoben wurden.

Beispiel 2: Streaming-Quelle, Functions-Aufgabe, Object Storage-Ziel

Beispiel 2: Streaming-Quelle, Functions-Aufgabe, Object Storage-Ziel.
Callouts für Beispiel 2
Zahl Beschreibung
1 Connector Hub liest Streamdaten aus Streaming.
2 Connector Hub löst die Aufgabe theFunctions für die benutzerdefinierte Verarbeitung von Streamdaten aus.
3 Die Aufgabe gibt verarbeitete Daten an Connector Hub zurück.
4 Connector Hub schreibt die Streamdaten in den Object Storage-Zielservice.
5 Object Storage schreibt die Streamdaten in einen Bucket.

Bei jedem Verschiebevorgang werden Daten aus dem ausgewählten Stream in die Funktionsaufgabe und dann in den Bucket verschoben, unter Beachtung der Servicelimits und abhängig von der Größe jedes Batches. Die Batchgröße wird in den Aufgaben- und Zieleinstellungen für dieses Szenario konfiguriert. Sobald Connector Hub die Streamdaten aus dem Streaming-Service empfängt, wird ein einzelner Übertragungsvorgang einen Batch dieser Streamdaten gemäß der Batchgrößenkonfiguration der Aufgabe in die Funktionsaufgabe verschieben und den verarbeiteten Batch schließlich gemäß der Batchgrößenkonfiguration des Ziels in den Bucket verschieben. Die in diesem Szenario für den Empfang, die Verarbeitung und das Verschieben eines Streams erforderlich ist, beträgt abhängig von den Batchgrößenkonfigurationen der Aufgabe und des Ziels bis zu 17 Minuten.

Bereitstellungsdetails

Hinweis

Informationen zur Funktionsverarbeitung von Nachrichten aus Queues finden Sie unter Fehlerbehandlung bei der Verarbeitung von Queues.

Connector Hub folgt "mindestens einmal" Lieferung. Das heißt, wenn Daten in Ziele verschoben werden, stellen Connectors jeden Datenbatch mindestens einmal bereit.*

Wenn ein Verschiebevorgang nicht erfolgreich verläuft, wiederholt der Connector diesen Vorgang. Der Connector verschiebt nachfolgende Datenbatches erst, wenn der Wiederholungsvorgang erfolgreich war.

Wenn der Verschiebevorgang weiter nach dem Aufbewahrungszeitraum der Quelle verläuft, wird dieser Datenbatch nicht zugestellt.

*Die maximale Nachrichtengröße für das Notifications-Ziel beträgt 128 KB. Jede Nachricht, die die maximale Größe überschreitet, wird gelöscht.

Informationen zum Aufbewahrungszeitraum der Connector Hub-Quelle finden Sie in der zugehörigen Dokumentation unter Aufbewahrungszeitraum: Streamingquelle.

Bei bestimmten Fehlerbedingungen wird ein Connector, der kontinuierlich ausfällt, vom Serviceteam bei Oracle Cloud Infrastructure automatisch deaktiviert. Ein solcher langfristiger kontinuierlicher Fehler kann auf eine ungültige Konfiguration der Quelle oder des Ziels des Connectors hinweisen.

Batcheinstellungen

Ein Batch ist eine Liste von Einträgen, die von der Connector-Quelle oder dem Aufgabenservice empfangen werden.

Batcheinstellungen sind nur für die Functions-Aufgabe, das Functions-Ziel oder das Object Storage-Ziel eines Connectors verfügbar.

Wenn Batcheinstellungen verfügbar sind, können Sie Batches nach Größe und Zeit begrenzen. Beim Erreichen des ersten Limits wird ein Flush von Daten am Ziel ausgelöst. Beispiel: Wenn Sie den Grenzwert für die Batchgröße auf 1 MB und den Grenzwert für die Batchzeit auf 10 Sekunden festlegen, sendet der Connector einen Datenbatch an das Ziel, sobald die erste Bedingung eintritt: Entweder werden 1 MB aus der Quelle abgerufen, oder es sind 10 Sekunden vergangen.

Lange fehlgeschlagene Connectors werden deaktiviert

Warnmeldungen, gefolgt von einer automatischen Deaktivierung, treten für Connectors auf, die aufgrund der folgenden Bedingungen kontinuierlich ausfallen:

Nach vier aufeinanderfolgenden Tagen dieser Fehlerbedingungen sendet Connector Hub eine Warnungs-Ankündigung, die auf die Möglichkeit einer zukünftigen Deaktivierung und die Bereitstellung von Informationen zur Fehlerbehebung hinweist.

Nach sieben aufeinanderfolgenden Tagen dieser Fehlerbedingungen deaktiviert Connector Hub den Connector automatisch und sendet eine Ankündigung, in der die Deaktivierung angegeben ist.

Sie können einen deaktivierten Connector beheben, ihn in eine gültige Konfiguration aktualisieren und dann reaktivieren. Vergewissern Sie sich, dass der neu reaktivierte Connector Daten wie erwartet verschiebt, indem Sie den Zielservice prüfen. Um Details zum Datenfluss von der Quelle eines Connectors zum Ziel abzurufen, aktivieren Sie Logs für den Connector.

Connector Hub-Konzepte

Die folgenden Konzepte sind für die Arbeit mit Connector Hub wichtig.

Connector

Die Definition der zu verschiebenden Daten. Ein Connector gibt einen Quellservice, einen Zielservice und optionale Aufgaben an.

Quelle

Der Service, der die Daten enthält, die gemäß den angegebenen Aufgaben verschoben werden sollen, z.B. Logging.

Ziel

Der Service, der gemäß den angegebenen Aufgaben Daten von der Quelle empfängt. Die Daten werden von bestimmten Zielservices verarbeitet, gespeichert oder bereitgestellt. Der Functions-Service verarbeitet die empfangenen Daten. Die Services Log Analytics, Monitoring, Object Storage und Streaming speichern die Daten, und der Notifications-Service stellt die Daten sicher.

Aufgabe

Optionale Filterung, die auf die Daten angewendet wird, bevor sie aus dem Quellservice in den Zielservice verschoben werden.

Trigger

Die Bedingung, die erfüllt sein muss, damit ein Connector ausgeführt wird. Derzeit ist der Trigger kontinuierlich, d.h. Connectors werden kontinuierlich ausgeführt.

Datenfluss

Wenn ein Connector ausgeführt wird, empfängt er Daten vom Quellservice, führt optionale Aufgaben für die Daten aus (wie das Filtern) und verschiebt die Daten dann in den Zielservice.

Im Folgenden werden die unterstützten Ziele und optionalen Aufgaben für jede verfügbare Quelle zusammen mit einer Beschreibung der Ziele aufgeführt.

Beispiele finden Sie unter Connector-Hub-Szenarios.

Loggingquelle

Wählen Sie eine Loggingquelle aus, um Logdaten aus dem Logging-Service zu übertragen.

Beispiele für Connectors, die Loggingquellen verwenden, finden Sie unter Szenario: Dimensionen für ein Monitoringziel erstellen und anderen Szenarios unter Connector Hub-Szenarios.

Alle Ziele werden von einem Connector unterstützt, der mit einer Loggingquelle und einer optionalen Aufgabe (Functions oder Logging) definiert ist.

Diese Abbildung zeigt die Ziele, die von einem Connector unterstützt werden, der mit einer Logging-Quelle und einer optionalen Aufgabe definiert ist.

Callouts für Logging-Quelle
Zahl Beschreibung
1 Connector Hub liest Logdaten aus Logging.
2 Optional: Bei entsprechender Konfiguration löst Connector Hub eine der folgenden Aufgaben aus:
  • Funktionsaufgabe für die benutzerdefinierte Verarbeitung von Logdaten.
  • Logfilteraufgabe (Logging-Service) zum Filtern von Logdaten.
3 Die Aufgabe gibt verarbeitete Daten an Connector Hub zurück.
4 Connector Hub schreibt die Logdaten in einen Zielservice.

Beispiel für einen Connector, der Logging als Quelle verwendet, mit Functions als Aufgabe: Szenario: Logdaten an eine Autonomous Database senden.

Der Aufbewahrungszeitraum für die Loggingquelle in Connector Hub beträgt 24 Stunden. Weitere Informationen zur Lieferung finden Sie unter Lieferdetails.

Wenn die erste Ausführung eines neuen Connectors erfolgreich ist, werden Logdaten aus der Erstellungszeit des Connectors verschoben. Wenn die erste Ausführung fehlschlägt (z.B. bei fehlenden Policys), verschiebt der Connector nach der Auflösung Logdaten aus der Connector-Erstellungszeit oder 24 Stunden vor der aktuellen Uhrzeit, je nachdem, was später ist.

Bei jeder späteren Ausführung werden die nächsten Logdaten verschoben. Wenn eine spätere Ausführung nicht erfolgreich verläuft und die Auflösung innerhalb des 24-Stunden-Aufbewahrungszeitraums erfolgt, verschiebt der Connector die nächsten Logdaten. Wenn eine spätere Ausführung nicht erfolgreich verläuft und die Lösung außerhalb des 24-Stunden-Aufbewahrungszeitraums erfolgt, verschiebt der Connector die neuesten Logdaten, und alle zwischen der nicht erfolgreichen Ausführung generierten Daten werden nicht zugestellt.

Monitoring-Quelle

Wählen Sie eine Monitoringquelle aus, um Metrikdatenpunkte aus dem Monitoring-Service zu übertragen.

Ein Beispiel für einen Connector mit einer Monitoringquelle finden Sie unter Szenario: Metriken an Object Storage senden.

Die folgenden Ziele werden von einem Connector unterstützt, der mit einer Monitoringquelle und einer (optional) Functions-Aufgabe definiert ist: Functions, Object Storage und Streaming.

Diese Abbildung zeigt die Ziele, die von einem Connector unterstützt werden, der mit einer Monitoring-Quelle und einer optionalen Aufgabe definiert ist.

Callouts für Monitoring-Quelle
Zahl Beschreibung
1 Connector Hub liest Metrikdaten aus Monitoring.
2 Optional: Bei entsprechender Konfiguration löst Connector Hub die folgende Aufgabe aus:
  • Funktionsaufgabe für die benutzerdefinierte Verarbeitung von Metrikdaten.
3 Die Aufgabe gibt verarbeitete Daten an Connector Hub zurück.
4 Connector Hub schreibt die Metrikdaten in einen Zielservice.

Der Aufbewahrungszeitraum für die Monitoringquelle in Connector Hub beträgt 24 Stunden. Weitere Informationen zur Lieferung finden Sie unter Lieferdetails.

Queuequelle

Wählen Sie die Queuequelle aus, um Nachrichten vom Queue-Service zu übertragen.

Die folgenden Ziele werden von einem Connector unterstützt, der mit einer Queuequelle und einer (optional) Functions-Aufgabe definiert ist:

Diese Abbildung zeigt die Ziele, die von einem Connector unterstützt werden, der mit einer Queue-Quelle und einer optionalen Aufgabe definiert ist.

Callouts für Queuequelle
Zahl Beschreibung
1 Connector Hub liest Nachrichten aus Queue.
2 Optional: Bei entsprechender Konfiguration löst Connector Hub die folgende Aufgabe aus:
  • Funktionsaufgabe für die benutzerdefinierte Verarbeitung von Nachrichten.
3 Die Aufgabe gibt verarbeitete Daten an Connector Hub zurück.
4

Connector Hub schreibt die Nachrichten in einen Zielservice und löscht die übertragenen Nachrichten automatisch aus der Queue.

Ein Szenario mit einer Zielfunktion finden Sie unter Szenario: Queuenachrichten an eine Funktion senden.

Der Aufbewahrungszeitraum für die Queuequelle in Connector Hub hängt von der Queuekonfiguration ab. Siehe Queue erstellen. Weitere Informationen zur Lieferung finden Sie unter Lieferdetails.

Streamingquelle

Wählen Sie die Streamingquelle aus, um Streamdaten aus dem Streaming-Service zu übertragen.

Die folgenden Ziele werden von einem Connector unterstützt, der mit einer Streamingquelle und einer (optional) Functions-Aufgabe definiert ist:

  • Functions

  • Loganalyse

  • Benachrichtigungen*

    Das Notifications-Ziel (in der Abbildung mit einem Sternchen gekennzeichnet) wird unterstützt, es sei denn, Sie verwenden die Functions-Aufgabe.

  • Object Storage

  • Streaming
Diese Abbildung zeigt die Ziele, die von einem Connector unterstützt werden, der mit einer Streamingquelle und einer optionalen Aufgabe definiert ist.
Callouts für Streaming-Quelle
Zahl Beschreibung
1 Connector Hub liest Streamdaten aus Streaming.
2 Optional: Bei entsprechender Konfiguration löst Connector Hub die folgende Aufgabe aus:
  • Funktionsaufgabe für die benutzerdefinierte Verarbeitung von Streamdaten.
3 Die Aufgabe gibt verarbeitete Daten an Connector Hub zurück.
4 Connector Hub schreibt die Streamdaten in einen Zielservice.

Der Aufbewahrungszeitraum für die Streamingquelle in Connector Hub ist vom Kunden definiert. Siehe Limits für Streaming-Ressourcen. Weitere Informationen zur Lieferung finden Sie unter Lieferdetails.

Zusammen mit dem Aufbewahrungszeitraum bestimmt die Leseposition der Streamingquelle, wo im Stream Daten verschoben werden sollen.

  • Letzte Leseposition: Startet das Lesen von Nachrichten, die nach dem Erstellen des Connectors veröffentlicht wurden.
    • Wenn die erste Ausführung eines neuen Connectors mit dieser Konfiguration erfolgreich ist, werden Daten aus der Erstellungszeit des Connectors verschoben. Wenn die erste Ausführung nicht erfolgreich verläuft (z.B. bei fehlenden Policys), verschiebt der Connector entweder Daten aus der Erstellungszeit des Connectors oder, wenn die Erstellungszeit außerhalb des Aufbewahrungszeitraums liegt, die ältesten verfügbaren Daten im Stream. Beispiel: Ein Connector, der um 10 Uhr für einen Stream mit einem zweistündigen Aufbewahrungszeitraum erstellt wurde. Wenn fehlerhafte Ausführungen um 11 Uhr aufgelöst werden, verschiebt der Connector Daten ab 10 Uhr. Wenn nicht erfolgreiche Ausführungen um 1 Uhr aufgelöst werden, verschiebt der Connector die ältesten verfügbaren Daten im Stream.
    • Später werden Daten von der nächsten Position im Stream verschoben. Wenn eine spätere Ausführung nicht erfolgreich verläuft, verschiebt der Connector Daten je nach Aufbewahrungszeitraum des Streams von der nächsten Position im Stream oder den ältesten verfügbaren Daten im Stream.
  • Leseposition Horizont abschneiden: Beginnt mit dem Lesen der ältesten verfügbaren Nachricht im Stream.
    • Wenn die erste Ausführung eines neuen Connectors mit dieser Konfiguration erfolgreich ist, werden Daten aus den ältesten verfügbaren Daten im Stream verschoben. Wenn die erste Ausführung nicht erfolgreich verläuft (z.B. bei fehlenden Policys), verschiebt der Connector nach der Auflösung die ältesten verfügbaren Daten im Stream, unabhängig vom Aufbewahrungszeitraum des Streams.
    • Später werden Daten von der nächsten Position im Stream verschoben. Wenn eine spätere Ausführung nicht erfolgreich verläuft, verschiebt der Connector Daten je nach Aufbewahrungszeitraum des Streams von der nächsten Position im Stream oder den ältesten verfügbaren Daten im Stream.

Ziele

Erfahren Sie, wann jedes verfügbare Ziel verwendet werden soll.

  • Functions: Senden Sie Daten an eine Funktion.
  • Logging Analytics: Senden Sie Daten an eine Loggruppe.
  • Monitoring: Senden Sie Metrikdatenpunkte an den Monitoring-Service.
  • Notifications: Senden Sie Daten an ein Thema.
  • Object Storage: Senden Sie Daten an einen Bucket.
  • Streaming: Senden Sie Daten an einen Stream.

Verfügbarkeit

Der Connector Hub-Service ist in allen kommerziellen Oracle Cloud Infrastructure-Regionen verfügbar. Eine Liste der verfügbaren Regionen sowie der zugehörigen Standorte, Regions-IDs, Regionsschlüssel und Availability-Domains finden Sie unter Regionen und Availability-Domains.

Ressourcen-IDs

Die meisten Oracle Cloud Infrastructure-Ressourcentypen verfügen über eine eindeutige, von Oracle zugewiesene ID, die als Oracle Cloud-ID (OCID) bezeichnet wird. Informationen zum OCID-Format und zu weiteren Möglichkeiten zur Identifizierung Ihrer Ressourcen finden Sie unter Ressourcen-IDs.

Möglichkeiten für den Zugriff auf Connector Hub

Auf Oracle Cloud Infrastructure (OCI) können Sie über die Konsole (eine browserbasierte Schnittstelle), die REST-API oder die OCI-CLI zugreifen. Anweisungen zur Verwendung der Konsole, der API und der CLI sind in den Themen in dieser Dokumentation enthalten. Eine Liste der verfügbaren SDKs finden Sie unter Softwareentwicklungs-Kits und Befehlszeilenschnittstelle.

Um auf die Konsole zuzugreifen, müssen Sie einen unterstützten Browser verwenden. Um zur Anmeldeseite der Konsole zu wechseln, öffnen Sie das Navigationsmenü oben auf dieser Seite, und wählen Sie Infrastrukturkonsole aus. Dort werden Sie aufgefordert, Ihren Cloud-Mandanten, Benutzernamen und Ihr Kennwort einzugeben.

Konsole: Um über die Konsole auf Connector Hub zuzugreifen, müssen Sie einen unterstützten Browser verwenden. Um zur Anmeldeseite der Konsole zu wechseln, öffnen Sie das Navigationsmenü oben auf dieser Seite, und wählen Sie Infrastrukturkonsole aus. Dort werden Sie aufgefordert, Ihren Cloud-Mandanten, Benutzernamen und Ihr Kennwort einzugeben. Öffnen Sie das Navigationsmenü , und wählen Sie Analysen und KI aus. Wählen Sie unter Messaging die Option Connector-Hub aus.

Sie können auch über die folgenden Services in der Konsole auf Connector Hub zugreifen:

  • Logging: Öffnen Sie das Navigationsmenü , und wählen Sie Beobachtbarkeit und Management aus. Wählen Sie unter Logging die Option Logs aus.
  • Streaming: Öffnen Sie das Navigationsmenü , und wählen Sie Analysen und KI aus. Wählen Sie unter Messaging die Option Streaming aus.

API: Um über die API auf Connector Hub zuzugreifen, verwenden Sie die Connector Hub-API.

CLI: Siehe Befehlszeilenreferenz für Connector Hub.

Authentifizierung und Autorisierung

Jeder Service in Oracle Cloud Infrastructure kann zur Authentifizierung und Autorisierung für alle Schnittstellen (Konsole, SDK oder CLI und REST-API) in IAM integriert werden.

Ein Administrator in einer Organisation muss Gruppen , Compartments und Policys einrichten, die steuern, welche Benutzer auf Services und Ressourcen sowie den Zugriffstyp zugreifen können. Beispiel: Die Policys steuern, wer neue Benutzer erstellen, das Cloud-Netzwerk erstellen und verwalten, Instanzen erstellen, Buckets erstellen, Objekte herunterladen kann usw. Weitere Informationen finden Sie unter Identitätsdomains verwalten. Einzelheiten zum Schreiben von Policys für die einzelnen Services finden Sie in der Policy-Referenz.

Wenn Sie ein regulärer Benutzer sind (nicht ein Administrator), der die Oracle Cloud Infrastructure-Ressourcen verwenden muss, für die das Unternehmen verantwortlich ist, bitten Sie einen Administrator, eine Benutzer-ID für Sie einzurichten. Der Administrator kann festlegen, welche Compartments Sie verwenden können.

Informationen zur Fehlerbehebung finden Sie unter Fehlerbehebung für Connectors.

Zugriff auf Connector Hub

Administratoren: Allgemeine Policys für den Zugriff auf Connector Hub finden Sie unter IAM-Policys.

Zugriff auf Quell-, Aufgaben- und Zielservices

Hinweis

Stellen Sie sicher, dass alle von Ihnen erstellten Policys den Unternehmensrichtlinien entsprechen. Automatisch erstellte Policys bleiben erhalten, wenn Connectors gelöscht werden. Als Best Practice sollten Sie zugehörige Policys löschen, wenn Sie den Connector löschen.

Um Daten zu verschieben, muss der Connector die Autorisierung für den Zugriff auf die angegebenen Ressourcen in den Quell--, Aufgaben-- und Ziel-Services erhalten. Einige Ressourcen sind ohne Policys zugänglich.

Standard-Policys mit der erforderlichen Autorisierung werden angeboten, wenn Sie einen Connector mit der Konsole definieren. Diese Policys sind auf den Kontext des Connectors begrenzt. Sie können entweder die Standard-Policys akzeptieren oder sicherstellen, dass Sie über die richtigen Autorisierungen in benutzerdefinierten Policys für den Benutzer- und Servicezugriff verfügen.

Standard-Policys

In diesem Abschnitt wird beschrieben, wie Sie einen Connector in der Konsole erstellen oder aktualisieren.

Hinweis

Um Standard-Policys für einen vorhandenen Connector zu akzeptieren, bearbeiten Sie einfach den Connector. Die Standard-Policys werden immer dann angeboten, wenn Sie einen Connector erstellen oder bearbeiten. Die einzige Ausnahme ist, wenn die exakte Policy bereits in IAM vorhanden ist. In diesem Fall werden die Standard-Policy nicht angeboten.
Functions (Aufgabe oder Ziel)

Gilt, wenn der Connector eine Funktionsaufgabe angibt oder Functions als Zielservice auswählt.

Wo diese Policy erstellt wird: In dem Compartment, in dem sich die Funktion befindet. Die Funktion wird für die Aufgabe oder das Ziel ausgewählt, wenn Sie den Connector erstellen oder aktualisieren.

Allow any-user to use fn-function in compartment id <target_function_compartment_ocid> where all {request.principal.type='serviceconnector', request.principal.compartment.id='<serviceconnector_compartment_ocid>'} Allow any-user to use fn-invocation in compartment id <target_function_compartment_ocid> where all {request.principal.type='serviceconnector', request.principal.compartment.id='<serviceconnector_compartment_OCID>'}

Im Folgenden wird die Policy mit Zeilenumbrüchen zur Klarheit hinzugefügt.

Allow any-user to use fn-function in compartment id <target_function_compartment_ocid>
    where all {
        request.principal.type='serviceconnector',     
        request.principal.compartment.id='<serviceconnector_compartment_ocid>'
    }
Allow any-user to use fn-invocation in compartment id <target_function_compartment_ocid>
    where all {
        request.principal.type='serviceconnector',     
        request.principal.compartment.id='<serviceconnector_compartment_OCID>'
    }
Logging (Quelle oder Aufgabe)

Es werden keine Standard-Policys angeboten. Um einen Connector zu erstellen oder zu bearbeiten, der Logs für die Quelle oder Aufgabe angibt, benötigen Sie Lesezugriff auf die angegebenen Logs. Weitere Informationen finden Sie unter Erforderliche Berechtigungen für die Arbeit mit Logs und Loggruppen.

Logging Analytics (Ziel)

Gilt, wenn der Connector Log Analytics als Zielservice angibt.

Wo diese Policy erstellt wird: In dem Compartment, in dem sich die Loggruppe befindet. Die Loggruppe wird für das Ziel ausgewählt oder eingegeben, wenn Sie den Connector erstellen oder aktualisieren.

Allow any-user to use loganalytics-log-group in compartment id <target_log_group_compartment_OCID> where all {request.principal.type='serviceconnector', target.loganalytics-log-group.id=<log_group_OCID>, request.principal.compartment.id=<serviceconnector_compartment_OCID>}

Im Folgenden wird die Richtlinie mit Zeilenumbrüchen zur Klarheit hinzugefügt.

Allow any-user to use loganalytics-log-group in compartment id <target_log_group_compartment_OCID> 
    where all {
        request.principal.type='serviceconnector', 
        target.loganalytics-log-group.id=<log_group_OCID>, 
        request.principal.compartment.id=<serviceconnector_compartment_OCID>
    }
Monitoring (Quelle)

Gilt, wenn der Connector Monitoring als Quellservice angibt.

Wo diese Policy erstellt wird: In dem Compartment, in dem sich der Metrik-Namespace befindet. Der Metrik-Namespace wird für das Ziel ausgewählt oder eingegeben, wenn Sie den Connector erstellen oder aktualisieren.

Allow any-user to read metrics in tenancy where all {request.principal.type = 'serviceconnector', request.principal.compartment.id = '<compartment_OCID>', target.compartment.id in ('<compartment1_OCID>', '<compartment2_OCID>', '<compartment3_OCID>')}

Im Folgenden wird die Richtlinie mit Zeilenumbrüchen zur Klarheit hinzugefügt.

Allow any-user to read metrics in tenancy 
    where all 
        {
            request.principal.type = 'serviceconnector', 
            request.principal.compartment.id = '<compartment_OCID>', 
            target.compartment.id in ('<compartment1_OCID>', '<compartment2_OCID>', '<compartment3_OCID>')
        }
Monitoring (Ziel)

Gilt, wenn der Connector Monitoring als Zielservice angibt.

Wo diese Policy erstellt wird: In dem Compartment, in dem sich der Metrik-Namespace befindet. Der Metrik-Namespace wird für das Ziel ausgewählt oder eingegeben, wenn Sie den Connector erstellen oder aktualisieren.

Allow any-user to use metrics in compartment id <target_metric_compartment_OCID> where all {request.principal.type='serviceconnector', target.metrics.namespace='<metric_namespace>', request.principal.compartment.id='<serviceconnector_compartment_OCID>'}

Im Folgenden wird die Richtlinie mit Zeilenumbrüchen zur Klarheit hinzugefügt.

Allow any-user to use metrics in compartment id <target_metric_compartment_OCID>
    where all 
        {
            request.principal.type='serviceconnector', 
            target.metrics.namespace='<metric_namespace>', 
            request.principal.compartment.id='<serviceconnector_compartment_OCID>'
        }
Notifications (Ziel)

Gilt, wenn der Connector Notifications als Zielservice angibt.

Wo diese Policy erstellt wird: In dem Compartment, in dem sich das Thema befindet. Das Thema wird für das Ziel ausgewählt, wenn Sie den Connector erstellen oder aktualisieren.

Allow any-user to use ons-topics in compartment id <target_topic_compartment_OCID> where all {request.principal.type= 'serviceconnector', request.principal.compartment.id='<serviceconnector_compartment_OCID>'}

Im Folgenden wird die Richtlinie mit Zeilenumbrüchen zur Klarheit hinzugefügt.

Allow any-user to use ons-topics in compartment id <target_topic_compartment_OCID>
    where all {
        request.principal.type= 'serviceconnector',
        request.principal.compartment.id='<serviceconnector_compartment_OCID>'
    }
Object Storage (Ziel)

Gilt, wenn der Connector Object Storage als Zielservice angibt.

Wo diese Policy erstellt wird: In dem Compartment, in dem sich der Bucket befindet. Der Bucket wird für das Ziel ausgewählt, wenn Sie den Connector erstellen oder aktualisieren.

Allow any-user to manage objects in compartment id <target_bucket_compartment_OCID> where all {request.principal.type='serviceconnector', target.bucket.name='<bucket_name>', request.principal.compartment.id='<serviceconnector_compartment_OCID>'}

Im Folgenden wird die Richtlinie mit Zeilenumbrüchen zur Klarheit hinzugefügt.

Allow any-user to manage objects in compartment id <target_bucket_compartment_OCID> 
    where all {
        request.principal.type='serviceconnector',
        target.bucket.name='<bucket_name>',          
        request.principal.compartment.id='<serviceconnector_compartment_OCID>'
    }
Warteschlange (Quelle)

Gilt, wenn der Connector Queue als Quellservice angibt.

Wo diese Policy erstellt wird: In dem Compartment, in dem die Queue gespeichert ist. Die Queue wird für die Quelle ausgewählt, wenn Sie einen Connector erstellen oder bearbeiten.

Allow any-user to { QUEUE_READ , QUEUE_CONSUME } in compartment id <queue_compartment_OCID> where all {request.principal.type='serviceconnector', target.queue.id='<queue_OCID>', request.principal.compartment.id='<serviceconnector_compartment_OCID>'}

Im Folgenden wird die Richtlinie mit Zeilenumbrüchen zur Klarheit hinzugefügt.

Allow any-user to { QUEUE_READ , QUEUE_CONSUME } in compartment id <queue_compartment_OCID>
    where all {
        request.principal.type='serviceconnector',
        target.queue.id='<queue_OCID>',
        request.principal.compartment.id='<serviceconnector_compartment_OCID>'
    }
Streaming (Quelle)

Gilt, wenn der Connector Streaming als Quellservice angibt.

Wo diese Policy erstellt wird: In dem Compartment, in dem sich der Stream befindet. Der Stream wird für die Quelle ausgewählt, wenn Sie den Connector erstellen oder aktualisieren.

Allow any-user to {STREAM_READ, STREAM_CONSUME} in compartment id <source_stream_compartment_OCID> where all {request.principal.type='serviceconnector', target.stream.id='<stream_OCID>', request.principal.compartment.id='<serviceconnector_compartment_OCID>'}

Im Folgenden wird die Richtlinie mit Zeilenumbrüchen zur Klarheit hinzugefügt.

Allow any-user to {STREAM_READ, STREAM_CONSUME} in compartment id <source_stream_compartment_OCID>
    where all {
        request.principal.type='serviceconnector',
        target.stream.id='<stream_OCID>',
        request.principal.compartment.id='<serviceconnector_compartment_OCID>'
    }
Streaming (Ziel)

Gilt, wenn der Connector Streaming als Zielservice angibt.

Wo diese Policy erstellt wird: In dem Compartment, in dem sich der Stream befindet. Der Stream wird für das Ziel ausgewählt, wenn Sie den Connector erstellen oder aktualisieren.

Allow any-user to use stream-push in compartment id <target_stream_compartment_OCID> where all {request.principal.type='serviceconnector', target.stream.id='<stream_OCID>', request.principal.compartment.id='<serviceconnector_compartment_OCID>'}

Im Folgenden wird die Richtlinie mit Zeilenumbrüchen zur Klarheit hinzugefügt.

Allow any-user to use stream-push in compartment id <target_stream_compartment_OCID>
    where all {
        request.principal.type='serviceconnector',
        target.stream.id='<stream_OCID>',
        request.principal.compartment.id='<serviceconnector_compartment_OCID>'
    }

Wenn Sie gruppenbasierte Policys auf den Zugriff auf eine Ressource (Service) in einem Connector prüfen, referenzieren Sie die Standard-Policy, die für diesen Service in diesem Kontext angeboten wird (siehe vorheriger Abschnitt), oder lesen Sie die Policy-Details für den Service unter Policy-Referenz.

Hinweis

Um Standard-Policys für einen vorhandenen Connector zu akzeptieren, bearbeiten Sie einfach den Connector. Die Standard-Policys werden immer dann angeboten, wenn Sie einen Connector erstellen oder bearbeiten. Die einzige Ausnahme ist, wenn die exakte Policy bereits in IAM vorhanden ist. In diesem Fall werden die Standard-Policy nicht angeboten.

Informationen zur Fehlerbehebung finden Sie unter Fehlerbehebung für Connectors.

Benutzerdefinierte Policys

Schreiben Sie Policys mit dynamischen Gruppen für den Zugriff auf Connectors und zugehörige Ressourcen.

Hinweis

Stellen Sie sicher, dass alle von Ihnen erstellten Policys den Unternehmensrichtlinien entsprechen. Wenn Sie benutzerdefinierte Policys schreiben, verwenden Sie die Standard-Policys als Basis.

Alternativ zur Akzeptierung der Standard-Policys (die das Thema all-users enthalten) können Sie benutzerdefinierte Policys mit schmaleren Zugriffsrechten mit dynamischen Gruppen erstellen.

Dynamische Gruppe

Erstellen Sie eine dynamische Gruppe für die benutzerdefinierten Policys.

  1. Dynamische Gruppe erstellen.

    Anweisungen finden Sie unter Dynamische Gruppen verwalten.

  2. Definieren Sie für diese neue dynamische Gruppe die folgende Übereinstimmungsregel.

    All {resource.type = 'serviceconnector', resource.compartment.id = '<serviceconnector_compartment_OCID>'}

    Verwenden Sie diese dynamische Gruppe für benutzerdefinierte Policys.

Functions (Aufgabe oder Ziel)

Erstellen Sie benutzerdefinierte Policys für eine dynamische Gruppe, um auf eine Funktion (Functions-Service) zuzugreifen, die eine Aufgabe oder ein Ziel eines Connectors ist.

Diese Policys gelten für die zuvor erstellte dynamische Gruppe.

Policy 1:

Allow dynamic-group <dynamic-group-name> to use fn-function in compartment id <function_compartment_ocid>
                        

Policy 2:

Allow dynamic-group <dynamic-group-name> to use fn-invocation in compartment id <function_compartment_ocid>
                        
Log Analytics (Ziel)

Erstellen Sie eine benutzerdefinierte Policy für eine dynamische Gruppe, um auf eine Loggruppe (Log Analytics-Service) zuzugreifen, die ein Ziel eines Connectors ist.

Diese Policy gilt für die zuvor erstellte dynamische Gruppe.

Allow dynamic-group <dynamic-group-name> to use loganalytics-log-group in compartment id <log_group_compartment_ocid> where target.loganalytics-log-group.id='<log_group_ocid>'

Im Folgenden wird die Policy mit Zeilenumbrüchen zur Klarheit hinzugefügt.

Allow dynamic-group <dynamic-group-name> to use loganalytics-log-group in compartment id <log_group_compartment_ocid> 
    where target.loganalytics-log-group.id='<log_group_ocid>'
Monitoring (Quelle)

Erstellen Sie eine benutzerdefinierte Policy für eine dynamische Gruppe, um auf eine Metrik (Monitoring-Service) zuzugreifen, die eine Quelle eines Connectors ist.

Diese Policy gilt für die zuvor erstellte dynamische Gruppe.

Allow dynamic-group <dynamic-group-name> to read metrics in compartment id <metric_compartment_ocid> where target.compartment.id in ('compartment1_OCID', 'compartment2_OCID', 'compartment3_OCID')

Im Folgenden wird die Policy mit Zeilenumbrüchen zur Klarheit hinzugefügt.

Allow dynamic-group <dynamic-group-name> to read metrics in compartment id <metric_compartment_ocid> 
    where target.compartment.id in ('<compartment1_OCID>', '<compartment2_OCID>', '<compartment3_OCID>')
Monitoring (Ziel)

Erstellen Sie eine benutzerdefinierte Policy für eine dynamische Gruppe, um auf eine Metrik (Monitoring-Service) zuzugreifen, die ein Ziel eines Connectors ist.

Diese Policy gilt für die zuvor erstellte dynamische Gruppe.

Allow dynamic-group <dynamic-group-name> to use metrics in compartment id <metric_compartment_ocid> where target.metrics.namespace='<metric_namespace>'

Im Folgenden wird die Policy mit Zeilenumbrüchen zur Klarheit hinzugefügt.

Allow dynamic-group <dynamic-group-name> to use metrics in compartment id <metric_compartment_ocid> 
    where target.metrics.namespace='<metric_namespace>'
Notifications (Ziel)

Erstellen Sie eine benutzerdefinierte Policy für eine dynamische Gruppe, um auf ein Thema (Benachrichtigungen) zuzugreifen, das ein Ziel eines Connectors ist.

Diese Policy gilt für die zuvor erstellte dynamische Gruppe.

Allow dynamic-group <dynamic-group-name> to use ons-topics in compartment id <topic_compartment_ocid>
                        
Object Storage (Ziel)

Erstellen Sie eine benutzerdefinierte Policy für eine dynamische Gruppe, um auf einen Bucket (Object Storage-Service) zuzugreifen, der ein Ziel eines Connectors ist.

Diese Policy gilt für die zuvor erstellte dynamische Gruppe.

Allow dynamic-group <dynamic-group-name> to manage objects in compartment id <bucket_compartment_ocid> where target.bucket.name='<bucket_name>'

Im Folgenden wird die Policy mit Zeilenumbrüchen zur Klarheit hinzugefügt.

Allow dynamic-group <dynamic-group-name> to manage objects in compartment id <bucket_compartment_ocid> 
    where target.bucket.name='<bucket_name>'
Warteschlange (Quelle)

Erstellen Sie benutzerdefinierte Policys für eine dynamische Gruppe, um auf eine Queue (Queueservice) zuzugreifen, die eine Quelle eines Connectors ist.

Diese Policys gelten für die zuvor erstellte dynamische Gruppe.

Allow dynamic-group <dynamic-group-name> to { QUEUE_READ , QUEUE_CONSUME } in compartment id <queue_compartment_ocid> where target.queue.id='<queue_ocid>'

Im Folgenden wird die Policy mit Zeilenumbrüchen zur Klarheit hinzugefügt.

Allow dynamic-group <dynamic-group-name> to { QUEUE_READ , QUEUE_CONSUME } in compartment id <queue_compartment_ocid>
    where target.queue.id='<queue_ocid>'
Streaming (Quelle)

Erstellen Sie benutzerdefinierte Policys für eine dynamische Gruppe, um auf einen Stream (Streaming-Service) zuzugreifen, der eine Quelle eines Connectors ist.

Diese Policys gelten für die zuvor erstellte dynamische Gruppe.

Allow dynamic-group <dynamic-group-name> to {STREAM_READ, STREAM_CONSUME} in compartment id <stream_compartment_ocid> where target.stream.id='<stream_ocid>'

Im Folgenden wird die Policy mit Zeilenumbrüchen zur Klarheit hinzugefügt.

Allow dynamic-group <dynamic-group-name> to {STREAM_READ, STREAM_CONSUME} in compartment id <stream_compartment_ocid>  
    where target.stream.id='<stream_ocid>'
Streaming (Ziel)

Erstellen Sie benutzerdefinierte Policys für eine dynamische Gruppe, um auf einen Stream (Streaming-Service) zuzugreifen, der ein Ziel eines Connectors ist.

Diese Policys gelten für die zuvor erstellte dynamische Gruppe.

Allow dynamic-group <dynamic-group-name> to use stream-push in compartment id <stream_compartment_ocid> where target.stream.id='<stream_ocid>'

Im Folgenden wird die Policy mit Zeilenumbrüchen zur Klarheit hinzugefügt.

Allow dynamic-group <dynamic-group-name> to use stream-push in compartment id <stream_compartment_ocid> 
    where target.stream.id='<stream_ocid>'

Deaktivierte Connectors

Bei bestimmten Fehlerbedingungen wird ein Connector, der kontinuierlich ausfällt, vom Serviceteam bei Oracle Cloud Infrastructure automatisch deaktiviert. Ein solcher langfristiger kontinuierlicher Fehler kann auf eine ungültige Konfiguration der Quelle oder des Ziels des Connectors hinweisen. Weitere Informationen finden Sie unter Deaktivierung für unbekannte Gründe.

Sicherheit

Informationen zur Sicherheit für Connector Hub.

Gewähren Sie Zugriff auf Connectors. Siehe Connector Hub sichern.