Présentation des métriques d'ingestion

Compatible avec :

Google SecOps fournit des métriques d'ingestion détaillées pour offrir une visibilité sur l'état, le volume et l'état de traitement de votre pipeline de données de sécurité. Il est essentiel de surveiller ces métriques pour s'assurer que les données circulent correctement, identifier les problèmes potentiels et optimiser votre déploiement Google SecOps.

Pourquoi les métriques d'ingestion sont-elles importantes ?

  • Surveillance de l'état : suivez l'état de vos flux de données et de vos agents de collecte.
  • Dépannage : diagnostiquez rapidement les problèmes tels que les pertes de données, les erreurs d'analyse ou les problèmes de connectivité.
  • Suivi du volume : comprenez la quantité de données ingérées à partir de différentes sources, ce qui est utile pour la planification de la capacité et la gestion des coûts.
  • Insights sur la normalisation : surveillez le taux de réussite de l'analyse des journaux dans le modèle de données unifié (UDM).
  • Alertes : configurez des notifications pour les anomalies dans le flux de données, les erreurs ou les modifications de volume.

Où accéder aux métriques d'ingestion ?

  • Google Cloud Monitoring:

    • Intègre les métriques Google SecOps dans Cloud Monitoring, ce qui vous permet de créer des tableaux de bord et de configurer des règles d'alerte en fonction de seuils pour des métriques telles que le nombre de journaux ingérés, leur taille et les événements de normalisation.
    • Les métriques sont disponibles sous des préfixes tels que Chronicle Collector et Chronicle Log Type.
    • Référence : Utiliser Cloud Monitoring pour obtenir des insights sur l'ingestion

  • Health Hub Google SecOps:

    • Le Health Hub fournit une vue centralisée dans la plate-forme Google SecOps pour surveiller l'état des sources de données, les volumes d'ingestion et l'état de l'analyse. Il met en évidence les erreurs et fournit des liens pour approfondir l'analyse.
    • Référence : Utiliser le Health Hub

  • BigQuery Export:

Catégories et champs de métriques clés

Les métriques d'ingestion sont divisées en différents composants du pipeline d'ingestion (par exemple, Forwarder, API d'ingestion, Normalizer, Feeds). Voici quelques champs clés que vous rencontrerez :

  • Métriques de volume :

    • log_count : nombre d'entrées de journal brutes reçues ou traitées.
    • log_volume : taille totale des journaux reçus ou traités (en octets).
    • event_count : nombre d'événements UDM générés après l'analyse.

  • Métriques de normalisation :

    • state: résultat du processus de normalisation des journaux (par exemple, parsed, failed_parsing, failed_validation).
    • total_events : nombre d'événements UDM validés.
    • total_error_events : nombre d'événements dont l'analyse ou la validation a échoué.
    • drop_reason_code : raison pour laquelle un journal ou un événement a été supprimé.

  • État et performances :

    • last_heartbeat_time: indique la dernière fois qu'un collecteur ou un flux était actif.
    • drop_count : nombre de journaux supprimés par un composant.
    • cpu_used, memory_used, disk_used : utilisation des ressources pour les composants sur site tels que l'agent Bindplane ou l'ancien Forwarder.
    • latency_count: métriques liées au temps écoulé entre l'ingestion et la normalisation.

  • Métriques de quota (API d'ingestion) :

    • quota_rejected_long_term_log_volume: volume de journaux rejetés en raison du dépassement des limites de quota.

Présentation des dimensions

Les métriques sont généralement divisées par dimensions, ce qui vous permet de filtrer et de regrouper les données :

  • component: partie du pipeline d'ingestion à laquelle la métrique fait référence (par exemple, Forwarder, Ingestion API, Normalizer, Out-of-Band Processor).
  • log_type : type de source de journal (par exemple, WINDOWS_DNS, CS_EDR).
  • collector_id / feed_id : identifiant unique de l'instance de collecteur ou du flux de données spécifique.
  • namespace : permet d'organiser les journaux, souvent utilisé dans l'ingestion d'API.

Remarque : Comme indiqué dans le schéma des métriques d'ingestion, les métriques d'ingestion agrégées doivent être traitées comme des indicateurs de volume approximatif plutôt que comme des nombres exacts pour une période donnée.

Écarts entre le volume de journaux bruts et le volume de journaux du tableau de bord

Le ingestion.log_volume total indiqué dans les tableaux de bord Google SecOps (par exemple, lorsque vous interrogez ingestion.component = "Ingestion API") peut différer considérablement du volume total de journaux bruts stockés dans votre instance. L'interface Google SecOps n'affiche pas de compteur d'ingestion cumulé depuis la provisionnement de votre instance. Étant donné que chaque outil de création de rapports applique une période d'analyse maximale, vous ne pouvez pas calculer de total cumulé une fois que votre instance est plus ancienne que la limite de conservation de l'outil.

Ces différences sont dues aux raisons suivantes :

  • Différentes périodes et limites de période d'analyse :

    • Stockage des journaux bruts : conserve les données conformément à la règle de conservation configurée pour votre instance. Votre instance peut avoir ingéré des journaux sur plusieurs années depuis son provisionnement.
    • Tableaux de bord Google SecOps : calcule ingestion.log_volume uniquement pour la période sélectionnée, jusqu'à une limite de période d'analyse maximale de 365 jours (ou jusqu'à 24 mois dans Cloud Monitoring pour les instances Bring Your Own Project (BYOP)). Si votre instance a ingéré des données pendant plus de 365 jours, les requêtes du tableau de bord indiquent un total inférieur à votre volume d'ingestion historique cumulé.

  • Différentes sources de données et différents pipelines de collecte :

    • Stockage des journaux bruts : enregistre la taille directe en octets des lots de journaux bruts ingérés stockés dans Google SecOps.
    • Tableaux de bord Google SecOps : interrogez ingestion.log_volume à partir de la table ingestion_metrics, qui collecte la télémétrie de manière asynchrone à intervalles d'environ 5 minutes. Étant donné que ce pipeline de télémétrie peut subir une latence de collecte, un échantillonnage ou des baisses de métriques temporaires, les requêtes du tableau de bord fournissent un volume approximatif plutôt qu'un nombre exact d'octets.

Où calculer le volume d'ingestion et en quoi les valeurs diffèrent-elles ?

Étant donné que l'interface Google SecOps n'affiche pas de compteur d'ingestion cumulé depuis l'heure de début de l'instance, utilisez les emplacements suivants pour calculer le volume d'ingestion en fonction de la période dont vous avez besoin :

  • Tableaux de bord Google SecOps (jusqu'à 365 jours) :

    • Où calculer : ouvrez Tableaux de bord et rapports > Tableaux de bord, puis affichez le widget Débit dans le tableau de bord Principal ou Ingestion et état des données (y compris le graphique Ingestion - Débit (depuis le début)). Vous pouvez également exécuter une requête de tableau de bord personnalisée pour sum($event.ingestion.log_volume) filtrée par $event.ingestion.component = "Ingestion API".
    • Période maximale : les requêtes sont limitées à 365 jours maximum, même dans le graphique organisé Ingestion - Débit (depuis le début).
    • En quoi les valeurs diffèrent-elles ? : les tableaux de bord interrogent la table asynchrone ingestion_metrics, qui collecte la télémétrie à intervalles d'environ 5 minutes et peut subir une latence de collecte ou des baisses de métriques temporaires. Les valeurs sont approximatives et ne reflètent que les journaux ingérés via l'API d'ingestion au cours de la période sélectionnée, plutôt que les octets de journaux bruts depuis le début ou le volume facturé final.

  • Explorateur de métriques Cloud Monitoring (jusqu'à 24 mois pour les instances BYOP):

    • Où calculer : ouvrez Monitoring > Explorateur de métriques dans la Google Cloud console, puis exécutez une requête pour chronicle_googleapis_com:ingestion_log_bytes_count{monitored_resource="chronicle.googleapis.com/Collector"} (pour obtenir des instructions détaillées, consultez Afficher le volume d'ingestion facturé).
    • Période maximale : les requêtes sont limitées à 24 mois maximum, en fonction de la conservation des métriques Cloud Monitoring.
    • En quoi les valeurs diffèrent-elles ? : Cloud Monitoring interroge le nombre d'octets d'ingestion au niveau du collecteur sur la période sélectionnée. Les valeurs couvrent une période d'analyse plus longue que les tableaux de bord Google SecOps (jusqu'à 24 mois au lieu de 365 jours), mais elles ne reflètent pas un total depuis le début si votre instance a plus de 24 mois.

  • Exportation BigQuery (au-delà de 365 jours, en fonction de la conservation de votre ensemble de données) :

    • Où calculer : ouvrez votre projet BigQuery après avoir exporté la table ingestion_metrics, puis exécutez une requête pour SUM(log_volume) (ou total_size_bytes dans Looker et BigQuery) filtrée par component = "Ingestion API".
    • Période maximale : les requêtes sont limitées à la période de conservation configurée pour votre table BigQuery à partir du moment où vous avez activé l'exportation, plutôt qu'à la limite de 365 jours du tableau de bord.
    • En quoi les valeurs diffèrent-elles ? : BigQuery interroge la même table asynchrone ingestion_metrics que les tableaux de bord Google SecOps. Les valeurs correspondent aux requêtes du tableau de bord pour la même période, mais elles restent des indicateurs de télémétrie approximatifs plutôt que des octets de journaux bruts depuis le début ou le volume facturé final.

Utiliser les métriques d'ingestion

  • Dépannage : filtrez par log_type et state (par exemple, failed_parsing) dans les métriques Normalizer pour trouver les problèmes d'analyse. Vérifiez drop_count et drop_reason_code pour détecter les pertes de données.

  • Alertes : configurez des alertes dans Cloud Monitoring pour surveiller les baisses soudaines de log_count pour les sources de journaux critiques ou les taux élevés de total_error_events. Pour surveiller votre volume d'ingestion quotidien par rapport aux limites contractuelles, utilisez la métrique Taille totale des journaux ingérés (chronicle.googleapis.com/ingestion/log/bytes_count). N'utilisez pas la métrique chronicle.googleapis.com/ingestion/quota_limit pour les alertes de volume quotidien, pour les raisons suivantes :

    • La métrique quota_limit mesure la proximité des limites de backend dynamiques plutôt que le volume réel de données ingérées.
    • L'utilisation de quota_limit pour les alertes de volume quotidien peut entraîner de fausses alarmes lorsque les seuils de backend sont ajustés.

    Pour savoir comment configurer une règle d'alerte de volume quotidien, consultez Configurer un exemple de règle pour surveiller le volume d'ingestion quotidien.

  • Planification de la capacité : analysez les tendances log_volume dans BigQuery pour prévoir les besoins futurs.

  • Validation de la configuration : après avoir configuré une nouvelle source de données, vérifiez les métriques pour vous assurer que les données circulent et sont analysées comme prévu.

En surveillant et en comprenant régulièrement ces métriques d'ingestion, vous pouvez garantir un pipeline de données fiable et efficace pour votre instance Google SecOps.

Vous avez encore besoin d'aide ? Obtenez des réponses de membres de la communauté et de professionnels Google SecOps.