Maîtrise des coûts

Après avoir commencé à utiliser IBM® Cloud Logs, vous pourriez vous rendre compte que vous devez ajuster la façon dont les données sont traitées par IBM Cloud Logs afin de contrôler les coûts.

Vous pouvez configurer IBM Cloud Logs ou ajuster les données qui sont ingérées par IBM Cloud Logs pour contrôler votre coût d'utilisation.

Choisir le meilleur plan de service

Examinez les plans de service et les tarifs disponibles. Le coût du pipeline de données dans lequel vous prévoyez de stocker les données influe sur le coût total.

Pensez également à la durée de conservation de vos données pour une recherche rapide sur Informations de priorité. Vous pouvez configurer votre instance IBM Cloud Logs de manière à ce que vos données soient sauvegardées dans Informations de priorité pendant une période plus courte.

Les données sont facturées par le service par gigaoctets ingérés. Vous pouvez configurer des mesures d'utilisation des données pour surveiller votre utilisation des données. Les mesures d'utilisation des données requièrent la configuration d'un seau de mesures.

Configuration de l'optimiseur de TCO

Par défaut, lorsqu'une instance IBM Cloud Logs est créée, toutes les données sont acheminées vers le pipeline de données Informations de priorité. Bien que cette filière permette la recherche la plus rapide, c'est la filière la plus coûteuse.

Pour contrôler les coûts, vous voulez optimiser le pipeline où les données sont envoyées.

En définissant le pipeline de données en fonction de l'importance des données pour votre entreprise, le TCO Optimizer peut vous aider à améliorer l'analyse et l'alerte en temps réel et à gérer les coûts.

Pour plus d'informations sur la configuration de l'optimiseur de TCO, voir Configuration de l'optimiseur de TCO.

Utilisation des politiques de TCO

La manière dont les journaux sont associés aux pipelines est déterminée par les politiques. Les politiques sont appliquées sur des combinaisons d'applications, de sous-systèmes et de sévérité des journaux au fur et à mesure de l'ingestion des journaux. Les journaux sont affectés au pipeline TCO approprié en fonction du contenu de la politique.

Vous devez avoir configuré un seau de données IBM Cloud Object Storage avant de créer une politique.

Comprendre l'ingestion de données

Pour comprendre comment maîtriser vos coûts lorsque vous utilisez IBM Cloud Logs, vous devez comprendre comment les données sont ingérées par le service.

IBM Cloud Logs ingère des données provenant de sources multiples et ces données sont traitées dans un ordre spécifique :

  1. Les journaux sont envoyés par la source.

    • Les journaux opérationnels sont envoyés par l'intermédiaire d'un agent ou d'un appel API REST.
    • Les journaux de la plate-forme et les événements de suivi des activités sont envoyés par IBM Cloud.

  2. IBM Cloud Logs ingère (reçoit) les données.

  3. IBM Cloud Logs des règles d'analyse sont appliquées aux données ingérées.

  4. Les politiques de TCO sont appliquées et les données sont affectées au pipeline de données approprié ou supprimées, en fonction de la politique.

Un journal est considéré comme ingéré à des fins de facturation une fois que les règles d'analyse et les politiques de CTP ont été appliquées. Les journaux qui sont bloqués avant d'être envoyés aux pipelines de données ne sont pas facturés et ne sont pas conservés.

Contrôle des données ingérées

En plus de contrôler les pipelines de données où vos données sont conservées dans IBM Cloud Logs, vous pouvez contrôler les données qui sont ingérées par IBM Cloud Logs.

Utilisation des règles d'analyse syntaxique

Vous pouvez utiliser la règle d'analyse en bloc pour filtrer les journaux entrants sur la base d'une expression RegEx. Pour plus d'informations sur la configuration d'une règle d'analyse en bloc, voir Blocage des données du journal.

Vous n'êtes pas limité au blocage des lignes de journal complètes. Les champs des lignes de journal dont vous n'avez pas besoin peuvent être supprimés à l'aide de règles d'analyse. Pour plus d'informations sur la suppression de champs, voir Suppression de champs dans les journaux à l'aide de la règle Supprimer les champs.

Filtrer et restructurer les données envoyées par l'intermédiaire du Agent de journalisation

Si vous envoyez des journaux opérationnels à IBM Cloud Logs en utilisant Agent de journalisation, vous pouvez analyser et restructurer les données du journal pour en assurer la cohérence et pour supprimer les données dont vous n'avez pas besoin dans IBM Cloud Logs.

  • Vous pouvez utiliser le filtre grep Fluent Bit avec l'option d'exclusion.

  • Vous pouvez utiliser le filtre de modification Fluent Bit pour supprimer les champs dont vous n'avez pas besoin.

  • Lors de l'installation du site Agent de journalisation, utilisez l'option excludeLogSourcePaths lors de l'installation avec le diagramme de barre ou l'option Exclude_Path du plug-in tail (installations Linux et Windows) pour ne pas envoyer de journaux à partir d'emplacements spécifiques.

  • Vous pouvez utiliser des scripts Lua pour filtrer et modifier les données envoyées à IBM Cloud Logs avant leur ingestion.

S'assurer que les données d'enregistrement sont bien structurées

Lorsque vous modifiez des données d'enregistrement, vous devez vous assurer que les données envoyées à IBM Cloud Logs sont bien formatées afin que IBM Cloud Logs puisse les traiter correctement.

  • Les journaux doivent être envoyés au format JSON ou un filtre est utilisé avec Agent de journalisation pour convertir le contenu au format JSON.

  • Étant donné que les politiques de TCO utilisent les informations de gravité contenues dans les données d'enregistrement pour affecter les enregistrements au pipeline de données approprié, il est préférable, pour une affectation cohérente, de s'assurer que les données d'enregistrement contiennent une valeur level, loglevel ou severity appropriée, plutôt que de laisser les valeurs Agent de journalisation ou IBM Cloud Logs indiquer la gravité.

  • Pour les journaux provenant de sources autres que Kubernetes, les lignes de journaux doivent comporter les champs application et subsystemName. Ces champs sont également utilisés par le traitement TCO.

  • Les journaux doivent également contenir des horodatages au format UTC. Il est également possible de configurer le site Agent de journalisation pour qu'il décale l'horodatage avant d'envoyer les journaux. Voir les informations sur Time_Offset et Time_System_Timezone dans la documentation Fluent Bit.

  • Les champs qui seront fréquemment utilisés dans les recherches (par exemple, http_error_code) doivent être extraits dans des clés distinctes, plutôt que d'être inclus dans la ligne de journal.