Exemples de mise à profit de la fonctionnalité de partitionnement de journal
Selon vos besoins, vous pouvez utiliser un jeu de journaux différent pour différents secteurs d'activité ou pour différents services que vous exécutez. Voici quelques cas d'utilisation courants de la fonctionnalité de partitionnement des journaux.
Rubriques :
Il n'y a pas de bonne façon de définir vos jeux de journaux de partitionnement. Vous pouvez contacter le support technique Oracle pour obtenir de l'aide afin de déterminer ce qui convient le mieux à votre cas d'emploi.
Utilisation finale : Plusieurs lignes d'activité
Votre cas d'emploi peut comporter plusieurs secteurs d'activité (LOB) où l'utilisateur Log Analytics analyse généralement les journaux pour un seul LOB à la fois et effectue parfois des recherches sur plusieurs LOB ou sur tous les LOB.
Dans ce scénario, si chaque objet LOB a toujours moins 6 To de journaux par jour, il convient d'utiliser une chaîne d'ensemble de journaux alignée sur les secteurs d'activité. Par exemple, les ensembles de journaux tels que HR, Global IT, Finances, Expédition, Commandes et Sécurité.
Si un seul objet LOB peut atteindre plus de 6 To par jour d'inclusion de journal, les ensembles de journaux peuvent être définis en fonction d'un aspect secondaire tel que le type de fonction d'un objet LOB d'où proviennent les journaux. Par exemple, si le LOB Global IT s'attend à ce que 20 To de journaux soient ingérés par jour, plutôt que d'utiliser Global IT comme jeu de journaux, il peut être préférable d'utiliser GIT-Database, GIT-Mail, GIT-Support comme valeurs de jeu de journaux.
La clé de la sélection des ensembles de journaux consiste à s'aligner sur la façon dont les données sont généralement analysées. Si les journaux GIT-Mail sont généralement analysés seuls sans mélange d'autres journaux, cet ensemble de journaux est approprié. Si vous pouvez toujours combiner GIT-Database et GIT-Support dans la même recherche, il n'est pas approprié de les définir en tant qu'ensembles de journaux différents.
Utilisation finale : redimensionnement du service en fonction des clients
Le cas d'utilisation peut impliquer l'exécution d'un produit cloud évolutif horizontalement qui évolue en fonction du nombre de clients.
Par exemple, si l'utilisation de votre service cloud par chaque client nécessite un ensemble de calculs, de bases de données et de réseaux, ces clients peuvent organiser vos ensembles de journaux à l'aide d'un nom de client ou d'un identificateur de client. Ces informations doivent être accessibles et compréhensibles pour l'utilisateur qui recherche un client spécifique dans les journaux. Dans ce cas, si vous avez des clients C1, C2, C3, il s'agit des chaînes d'ensemble de journaux que vous utilisez pour les journaux de chaque client.
En règle générale, lors du débogage d'un problème, l'équipe des opérations recherche dans les journaux un client spécifique dans le cadre du support. Cependant, il arrive qu'ils analysent également les journaux de plusieurs clients ou de tous les clients. Dans de tels cas, même si la plupart des journaux sont segmentés par les clients, il peut également y avoir des journaux communs à tous les clients. Par exemple, une base de données de facturation centrale peut être commune. Vous pouvez ensuite combiner des ensembles de journaux en fonction des noms de client et disposer d'un ensemble de journaux pour CentralDB.