Migrer le flux de travail de collecte d'objets du principal de service vers le principal de ressource

Conditions requises pour la migration de la collection d'objets

Extrayez la liste de toutes les règles de collection d'objets LIVE et HISTORIC_LIVE de votre location ou compartiment, y compris les détails suivants :

• OCID de la règle de collecte d'objets
• OCID du compartiment.
• Espace de noms du stockage d'objets

Voir Documentation sur l'API de liste.

Pour les étapes de migration :

• Si l'espace de noms du stockage d'objets est identique à l'espace de noms de la location où existe la règle de collecte d'objets, voir Étapes de migration pour la même collection d'objets de location.

• Si l'espace de noms du stockage d'objets diffère de l'espace de noms de la location, voir Étapes de migration pour la collecte d'objets interlocation.

Étapes de migration pour la collection d'objets de la même location

1. Créer un groupe dynamique nommé <Dynamic_Group> avec la règle de correspondance suivante. Voir Créer un groupe dynamique.

   ALL {resource.type='loganalyticsobjectcollectionrule'}

2. Ajoutez les énoncés de politique suivants :

   allow DYNAMIC-GROUP <Dynamic_Group> to read buckets in compartment/tenancy
   allow DYNAMIC-GROUP <Dynamic_Group> to read objects in compartment/tenancy
   allow DYNAMIC-GROUP <Dynamic_Group> to manage cloudevents-rules in compartment/tenancy
   allow DYNAMIC-GROUP <Dynamic_Group> to inspect compartments in tenancy
   allow DYNAMIC-GROUP <Dynamic_Group> to use tag-namespaces in tenancy where all {target.tag-namespace.name = /oracle-tags/}
   allow resource loganalyticsvrp LogAnalyticsVirtualResource to {BUCKET_READ} in tenancy

3. Après la création réussie du groupe dynamique et la modification des politiques, suivez Valider la migration de la collection d'objets. La suppression des politiques basées sur le principal de service existantes sans validation réussie peut entraîner une perte de données.

Étapes de migration pour la collecte d'objets interlocation

Laissez Guest_Tenant faire référence au locataire à partir duquel les journaux doivent être collectés et Bucket_Compartment être le compartiment de Guest_Tenant contenant le seau de stockage d'objets. Laissez Host_Tenant faire référence au locataire abonné à Oracle Log Analytics, où existe la collection d'objets.

1. Créez un groupe dynamique nommé <Dynamic_Group> dans Host_Tenant avec la règle de correspondance suivante. Notez son OCID. Voir Créer un groupe dynamique.

   ALL {resource.type='loganalyticsobjectcollectionrule'}

2. Ajoutez les énoncés de politique suivants dans Host_Tenant :

   endorse group <Host_User_Group> to {OBJECT_INSPECT, OBJECT_READ} in compartment <Bucket_Compartment>
    endorse DYNAMIC-GROUP <Dynamic_Group> to read buckets in compartment <Bucket_Compartment>
    endorse DYNAMIC-GROUP <Dynamic_Group> to read objects in compartment <Bucket_Compartment>
    endorse DYNAMIC-GROUP <Dynamic_Group> to manage cloudevents-rules in compartment <Bucket_Compartment>
    endorse DYNAMIC-GROUP <Dynamic_Group> to inspect compartments in tenancy <Guest_Tenant>
    endorse DYNAMIC-GROUP <Dynamic_Group> to use tag-namespaces in tenancy <Guest_Tenant> where all {target.tag-namespace.name = /oracle-tags /}

3. Ajoutez les énoncés de politique suivants dans Guest_Tenant :

   define DYNAMIC-GROUP <Dynamic_Group> as <Dynamic_Group_OCID>
   admit group <Host_User_Group> of tenancy <Host_Tenant> to {OBJECT_INSPECT, OBJECT_READ} in compartment <Bucket_Compartment>
   admit DYNAMIC-GROUP <Dynamic_Group> of tenancy <Host_Tenant> to read buckets in compartment <Bucket_Compartment>
   admit DYNAMIC-GROUP <Dynamic_Group> of tenancy <Host_Tenant> to read objects in compartment <Bucket_Compartment>
   admit DYNAMIC-GROUP <Dynamic_Group> of tenancy <Host_Tenant> to manage cloudevents-rules in compartment <Bucket_Compartment>
   admit DYNAMIC-GROUP <Dynamic_Group> of tenancy <Host_Tenant> to inspect compartments in compartment <Bucket_Compartment>
   admit DYNAMIC-GROUP <Dynamic_Group> of tenancy <Host_Tenant> to use tag-namespaces in tenancy where all {target.tag-namespace.name = /oracle-tags /}

4. Après la création réussie du groupe dynamique et la modification des politiques, suivez Valider la migration de la collecte d'objets. La suppression des politiques basées sur le principal de service existantes sans validation réussie peut entraîner une perte de données.

Valider la migration de la collection d'objets

Autorisez environ 1 heure à ce que les modifications de politique prennent effet avant d'effectuer cette validation.

La fonction Erreurs de traitement d'Oracle Log Analytics peut être utilisée pour valider la migration du flux de collecte d'objets des politiques basées sur le principal de service vers les politiques basées sur le principal de ressource.

1. Naviguez jusqu'à Explorateur de mesures : Allez à la console OCI. Cliquez sur l'icône du menu de navigation, cliquez sur Observabilité et gestion, puis sur Explorateur de mesures sous Surveillance.
2. Voir les mesures :
   1. Sélectionnez l'intervalle de temps Last 24 hours.
   2. Sélectionnez le compartiment dans lequel existe la règle de collecte d'objets.
   3. Sélectionnez l'espace de noms de mesure oci_logging_analytics.
   4. Sélectionnez le nom de la mesure ProcessingErrors.

      Par défaut, l'intervalle est 1 minute.

   5. Sélectionnez la statistique Sum.
   6. Sélectionnez le nom de dimension collectionType et la valeur de dimension ObjectCollection.
   7. Cliquez sur le bouton Dimension supplémentaire.
   8. Sélectionnez le nom de dimension errorType et la valeur de dimension NotAuthorizedOrNotFound_RP_ObjectStorage_Read.
   9. Cliquez sur Mettre à jour le graphique.

3. Valider les mesures :

   • Initialement, certains points de données sont présents pour cette mesure (section A dans l'image ci-dessous), indiquant que les objets sont traités à l'aide de politiques basées sur le principal de service.

   • Une fois les modifications apportées à la politique prises en compte, il ne devrait pas y avoir de points de données dans la mesure au-delà de ce point de temps particulier (section B dans l'image ci-dessous), et le graphique devrait passer à 0, indiquant que les politiques basées sur le principal de ressource fonctionnent correctement et que la validation est réussie.

   • Si des points de données sont disponibles après 1 heure de modification des politiques, il se peut que certaines politiques soient manquantes et que la validation ait échoué.

   • Par exemple :

     
     
     
     
     

     À 08:39 UTC, les changements de politique sont reflétés, et aucun point de données n'est disponible après ce temps. Ce modèle doit être observé pour une validation réussie.

   • Si la validation échoue, attendez 1 heure de plus et essayez de réexécuter les étapes de validation. Si la validation continue d'échouer, effectuez une vérification croisée des politiques et du groupe dynamique. Pour obtenir de l'aide supplémentaire, communiquez avec Oracle Support.
   • Une fois la validation réussie, suivez Élimination post-migration pour la collecte d'objets.

Nettoyage après migration pour la collection d'objets

Vous pouvez supprimer de la location où existe le seau de stockage d'objets des politiques similaires aux politiques basées sur le principal de service suivantes :

allow service loganalytics to read buckets in compartment/tenancy
allow service loganalytics to read objects in compartment/tenancy
allow service loganalytics to manage cloudevents-rules in compartment/tenancy
allow service loganalytics to inspect compartments in tenancy
allow service loganalytics to use tag-namespaces in tenancy where all {target.tag-namespace.name = /oracle-tags/}