Advanced Analytics Meilleures pratiques

Les performances du tableau de bord de Netskope Advanced Analytics dépendent en grande partie de l'efficacité des requêtes sous-jacentes. Chaque widget d'un tableau de bord exécute une requête dans la base de données, et le temps nécessaire au traitement de ces requêtes a un impact direct sur les performances globales. 

Pour garantir des performances optimales, il est essentiel de tenir compte de plusieurs facteurs lors de la conception des tableaux de bord et des widgets. Cette rubrique présente les meilleures pratiques pour créer des widgets et des tableaux de bord efficaces dans Netskope Advanced Analytics.

Lignes directrices générales

Avant d'utiliser Netskope Advance Analytics, prenez en compte les points clés suivants. Ces lignes directrices et conseils généraux vous aideront à créer, exécuter et exporter des tableaux de bord efficaces.

Pour chaque tableau de bord

• Il n'y a pas de limite stricte pour le nombre de widgets, mais il est fortement recommandé de créer moins de 15 widgets par tableau de bord.

Pour chaque widget du tableau de bord

• Prend en charge jusqu'à 5000 lignes et 200 colonnes pour les résultats de requête pivotés ou non pivotés.

• Pour des raisons de performance du navigateur, il est recommandé de ne pas dépasser 20 colonnes.

Pour chaque requête backend déclenchée à partir d'Explore, de widgets ou de tableaux de bord (y compris les rapports planifiés et non planifiés)

• Aucune garantie n'est donnée quant au temps de traitement des données. Plus vous demandez de données, plus le temps de traitement des données peut être long.

• Les enrichissements de données, tels que (mais sans s'y limiter) le contrôle RBAC, la recherche d'informations sur les groupes d'utilisateurs, la recherche de géolocalisation et les informations sur les applications (par exemple, CCI, CCL), augmentent également le temps de traitement des requêtes au niveau du backend.

Pour les rapports générés

• Query results exceeding 11 MB cannot be delivered to scheduled or ad-hoc report recipients. Keep your maximum PDF size for email delivery is ~11 MB.

• L'option Tous les résultats n'est pas garantie dans tous les cas. Même s'il est disponible, utilisez-le avec prudence lorsque vous téléchargez ou planifiez un rapport avec tous les résultats. Certaines requêtes peuvent générer de très grands ensembles de données, contenant potentiellement des milliers, voire des millions de lignes, qui peuvent dépasser les limites de la plupart des tableurs.

Optimisez le volume de données pour la performance

• Commencez par le nombre minimum de champs nécessaires à votre analyse.

• Appliquez des filtres pour réduire la taille des résultats de la requête.

• Ajustez les politiques de votre produit Netskope afin de ne capturer que les événements nécessitant une attention ou un audit.

Adopter une stratégie du grossier au fin pour les widgets

• Lorsque vous concevez des widgets, commencez par des champs de haut niveau afin d'obtenir une vue d'ensemble des données. Évitez d'utiliser des champs trop détaillés tels que l'URL, le référent ou le nom de l'objet, car ils peuvent masquer des informations essentielles.

Regrouper efficacement les données

• Pour les champs de type numérique et de type horodatage, utilisez toujours la granularité la plus fine qui réponde à vos besoins. Par exemple, utilisez des champs de type horodatage, tels que des horodatages mensuels, hebdomadaires ou quotidiens, plutôt qu'une précision de second niveau, à moins que vous n'en ayez vraiment besoin.

Limiter les colonnes dans les vues de tableaux

• Lorsque vous créez des widgets de vue de tableau, veillez à ce que le nombre de colonnes soit inférieur à 20, qu'il s'agisse de colonnes pivot ou de champs sélectionnés, afin de garantir des performances et une convivialité optimales.

Les enrichissements de données coûtent cher

• Si le filtrage des données par groupe d'utilisateurs, RBAC ou géolocalisation peut réduire la taille des résultats des requêtes, l'extraction et l'association de ces informations entraînent des frais généraux supplémentaires pour le traitement des données. Les fonctions avancées, telles que les résultats fusionnés, les champs personnalisés et les calculs de tableaux, entraînent également une surcharge de traitement des données. Équilibrer les besoins d'enrichissement et les considérations de performance.

• Utilisez Advanced Analytics comme un outil d'analyse, plutôt que comme un exportateur de données brutes.

Fonctionnalités avancées

Les fonctions avancées, telles que les résultats fusionnés, les champs personnalisés et les calculs de tableaux, consomment davantage de ressources du backend et augmentent de manière significative le temps de traitement des données. Plus les fonctionnalités de traitement post-requête sont nombreuses, plus le chargement du tableau de bord prend du temps.

Strategies

Cette section s'applique à tous les tableaux de bord et aux widgets sous-jacents.

Le volume de données a le plus grand impact sur les performances

La quantité de données extraites peut affecter de manière significative le temps de traitement des données. Il s'agit notamment de

• Sélection d'un trop grand nombre de champs

• Récupération d'un nombre excessif d'enregistrements dans les résultats de la requête

• Interroger des enregistrements (filtrés ou non filtrés) à partir d'un ensemble de données trop volumineux

Atténuer les effets des éléments ci-dessus et améliorer les performances :

• Select Des champs judicieusement choisis :
  Choisissez les champs qui sont essentiels pour transmettre un message unique et clair. Commencez par ne sélectionner que le nombre minimum de champs nécessaires pour atteindre vos objectifs d'analyse.

• Utilisez les filtres de manière efficace :
  Appliquez des filtres pour limiter la taille des résultats de la recherche et veillez à ce qu'elle corresponde aux seuils recommandés dans la section " Lignes directrices générales". En outre, envisagez de définir des valeurs de filtre par défaut sur votre tableau de bord afin de rationaliser les requêtes.

• Ajustez les politiques des produits Netskope de manière réfléchie :
  Configurez les politiques des produits Netskope pour qu'elles se concentrent sur les événements qui requièrent une attention ou un audit, plutôt que d'enregistrer toutes les données sans discernement.

Limiter le nombre de widgets dans un tableau de bord unique

Chaque widget d'un tableau de bord exécute une requête SQL qui prend du temps à s'exécuter dans la base de données sous-jacente. En d'autres termes, la présence d'un trop grand nombre de widgets sur un même tableau de bord augmente le temps de chargement global, car toutes les requêtes doivent être exécutées pour charger complètement les données de chaque widget. Pour des performances optimales, il est recommandé de limiter le nombre de widgets sur un tableau de bord à moins de 15.

Limiter le nombre de colonnes dans un widget Table View

Les widgets qui génèrent des résultats de requête avec un trop grand nombre de colonnes dans une vue de tableau augmentent non seulement le temps de traitement des données en arrière-plan, mais dégradent également les performances du navigateur, ce qui peut entraîner une certaine lenteur. En outre, une vue de tableau comportant plus de 20 colonnes peut devenir difficile à analyser et à interpréter efficacement, car l'excès de détails peut masquer des informations essentielles. En fait, la plupart des widgets de visualisation pris en charge par Advanced Analytics sont conçus pour gérer efficacement jusqu'à 2 ou 3 colonnes. Pour améliorer les performances et la convivialité, envisagez de limiter le nombre de colonnes ou de répartir l'ensemble des données sur plusieurs widgets ou tableaux de bord. En outre, soyez prudent lorsque vous pivotez des données, car l'utilisation de champs inappropriés pour le pivotement peut augmenter de manière significative le nombre de colonnes et avoir un impact négatif sur les performances.

Exemple 1 : Incidents DLP (Prévention des pertes de données) - Grossier ou fin - Qu'est-ce qui est le plus intéressant ?

Imaginez que vous enquêtiez sur des incidents DLP (Prévention des pertes de données) survenus au cours des 7 derniers jours. Un tableau contenant des champs tels que Utilisateur, Type d'alerte, Application, Site et Nom d'objet fournit une vue détaillée. Cependant, il peut être difficile de répondre à des questions critiques telles que le nombre d'incidents encore ouverts, les applications les plus touchées ou les politiques qui ont déclenché le plus d'incidents dans un tableau unique et complet. Pour relever ces défis, au lieu de s'appuyer sur une seule vue de table, la meilleure pratique consiste à créer trois widgets avec le nombre minimum de champs nécessaires, comme indiqué ci-dessous :

DLP Incidents by Status:

• Filtrer en réglant le type d'alerte sur DLP (Prévention des pertes de données)

• Select DLP (Prévention des pertes de données) Dimension de l'état de l'incident

• Select # DLP (Prévention des pertes de données) Mesure des incidents

DLP Incidents by Applications:

• Filtrer en réglant le type d'alerte sur DLP (Prévention des pertes de données)

• Select Dimensions de l'application

• Select # DLP (Prévention des pertes de données) Mesure des incidents

DLP Incidents by Policies:

• Filtrer en réglant le type d'alerte sur DLP (Prévention des pertes de données)

• Select Dimension du nom de la politique

• Select # DLP (Prévention des pertes de données) Mesure des incidents

Les trois widgets mentionnés ci-dessus représentent l'approche utilisée pour concevoir les tableaux de bord intégrés tels que le tableau de bord de suivi de l'état des incidents DLP (Prévention des pertes de données).

Le rapport ci-dessous montre qu'une vue de tableau unique avec trop de champs peine à transmettre efficacement toutes les informations en même temps.

Le rapport DLP (Prévention des pertes de données) Incidents par statut ci-dessous illustre le nombre d'événements encore en cours.

Le rapport DLP (Prévention des pertes de données) Incidents par applications ci-dessous illustre l'application qui déclenche le plus d'incidents DLP (Prévention des pertes de données).

Le rapport DLP (Prévention des pertes de données) Incidents par politiques ci-dessous illustre la politique qui déclenche le plus d'incidents DLP (Prévention des pertes de données).

Exemple 2 : Quel produit Netskope capture le plus grand nombre d'incidents DLP (Prévention des pertes de données) - Comment répartir les données ?

Dans la collection Incident Event données, vous pouvez analyser la distribution des produits Netskope par rapport aux incidents DLP (Prévention des pertes de données) en sélectionnant le champ Application pivoté avec le champ Méthode d'accès, puis en mesurant avec # DLP (Prévention des pertes de données) Incidents. Cependant, il n'est pas recommandé de faire pivoter vos données par application, car votre organisation peut avoir des dizaines, voire des centaines d'applications uniques, ce qui se traduit par un ensemble de données excessivement vaste et peu maniable.

La mesure du nombre d'incidents DLP (Prévention des pertes de données) en sélectionnant l'Application pivotée avec la Méthode d'accès donne une vue claire comme indiqué ci-dessous.

Mesurer le nombre d'incidents DLP (Prévention des pertes de données) en sélectionnant Méthode d'accès pivotée avec Application peut donner lieu à une visualisation difficile à interpréter. Notez la longueur excessive de la barre de défilement horizontale et l'avertissement "Column limit reached", qui indique que les données dépassent la capacité d'affichage du système.

Choisissez des champs efficaces lors de la création de widgets

Lors de l'analyse des données dans Advanced Analytics, l'adoption d'une stratégie grossière à fine en sélectionnant les champs contenant des informations de haut niveau au début est essentielle pour obtenir des informations exploitables. Au lieu de vous fier à des champs fragmentés comme l'URL, le référent ou le nom de l'objet, qui fournissent trop de détails, concentrez-vous sur des champs comme l'application, le type d'événement ou la catégorie d'application. Ces champs permettent non seulement d'obtenir une vue plus structurée et plus intuitive de vos données, mais aussi de réduire considérablement le nombre de résultats des requêtes en regroupant les données homogènes. Cette optimisation minimise les traitements inutiles, ce qui permet d'accélérer les performances des requêtes et d'améliorer l'efficacité de l'enquête workflow. En donnant la priorité aux champs de haut niveau, vous garantissez des résultats précis et complets, regroupés à partir de valeurs de champs descriptives, tout en améliorant l'efficacité du système.

Exemple 3 : Événements d'alerte DLP (Prévention des pertes de données) pour une application en nuage - Utiliser l'URL ou le nom de l'application ?

Un cas d'utilisation courant de la collection Alertes données est l'analyse des applications en nuage qui déclenchent le plus d'alertes DLP (Prévention des pertes de données) dans votre organisation. Dans l'événement Alerts, les champs URL et Application fournissent des informations sémantiques sur l'application cloud source. Cependant, l'utilisation du champ URL dans les rapports aboutit souvent à des données fragmentées, car les URL sont souvent composées d'ID ou de noms d'hôtes sans signification, générés de manière aléatoire et utilisés à des fins d'équilibrage de la charge. Pour analyser efficacement les événements, donnez la priorité aux champs qui fournissent des informations de haut niveau. Dans ce cas, le choix de l'application au lieu de l'URL permet d'obtenir des informations plus claires et plus exploitables.

Par exemple, sélectionnez les champs ci-dessous dans la collection de données "Alertes" pour observer les événements DLP (Prévention des pertes de données) liés aux applications en nuage :

• Ajoutez le champ "Type d'alerte" dans le groupe de champs "Alerte".

• Ajoutez "Application" dans le groupe de champs "Application".

• Ajoutez "URL" dans le groupe de champs "Application".

• Ajoutez "Type de trafic" dans le groupe de champs "Général".

• Mesure '#Alerts

Dans cet exemple, le champ URL varie en fonction des alertes, ce qui peut compliquer les analyses sommaires et gonfler le nombre d'enregistrements dans les résultats de la requête. En excluant le champ URL, vous pouvez générer un ensemble de résultats plus concis et plus significatif comme ci-dessous, en remarquant que les filtres appliqués et l'ensemble de données source interrogé sont les mêmes pour les exemples ci-dessus et ci-dessous :

Exemple 4 : Nombre d'octets téléchargés par utilisateur - Dimension ou mesure ?

Dans la collecte de données sur les événements de réseau, vous remarquerez peut-être que certains champs existent à la fois en tant que dimensions et mesures, tels que les octets téléchargés, les octets téléchargés, les paquets envoyés et les paquets reçus, entre autres.

Les principales différences entre ces deux types de champs sont les suivantes :

• Dimension: Représente la valeur d'un seul enregistrement individuel

• Measure: Représente un résultat agrégé calculé à partir de plusieurs enregistrements.

Par exemple, si vous avez besoin d'observer le nombre total d'octets téléchargés par utilisateur au cours des sept derniers jours, la mesure Somme - Octets téléchargés regroupera automatiquement les données pour chaque utilisateur en fonction de l'intervalle de temps sélectionné.

Vous pouvez toujours approfondir les lignes individuelles en cliquant sur les champs de mesure tels que # Alertes, # Compte, # Octets téléchargés, ou # Constatations pour une analyse plus détaillée si nécessaire. Il est essentiel de choisir les champs appropriés dès le départ, non seulement pour réduire les informations fragmentées, mais aussi pour créer des rapports plus convaincants qui fournissent des informations claires sur les données tout en minimisant le temps de traitement des données.

Regrouper les données de manière efficace

Dans certains cas, vous pouvez avoir besoin d'observer des distributions ou des histogrammes basés sur des champs de type numérique ou des champs de type horodatage. Vous trouverez ci-dessous quelques bonnes pratiques pour l'analyse des données avec ces types de champs :

• For numeric-type dimension:
  Divisez les données en catégories plutôt que de les sélectionner directement, ce qui permet de regrouper les données par valeurs brutes. Cette approche améliore l'analyse des données en fournissant des modèles et des tendances plus clairs, ce qui facilite l'interprétation et l'obtention d'informations.

• For the timestamp-type dimension:
  La plupart des collections de données prises en charge dans Advanced Analytics fournissent des horodatages d'événements avec différents niveaux de granularité. Les cas d'utilisation les plus courants sont l'observation des alertes mensuelles des utilisateurs, des incidents DLP (Prévention des pertes de données) hebdomadaires ou des octets téléchargés quotidiennement par utilisateur. Pour analyser efficacement les données, commencez toujours par l'horodatage le plus grossier qui réponde à vos besoins. L'utilisation d'un horodatage avec une précision de second niveau peut augmenter de manière significative le nombre de lignes dans les résultats de la requête, ce qui dégrade les performances de la requête.

Exemple 5 : CCL/CCI vs. # Application

En ce qui concerne les événements liés aux applications, le Netskope Cloud Confidence Index (CCI) est un indice qui permet d'évaluer l'aptitude des applications en nuage à être utilisées par les entreprises, en tenant compte de la sécurité, de l'auditabilité et de la continuité des activités de l'application. Chaque application se voit attribuer une note de 0 à 100 et, en fonction de cette note, est classée dans l'un des cinq niveaux de confiance dans le nuage (Cloud Confidence Levels, CCL). Pour mieux comprendre les niveaux de risque des applications en nuage utilisées dans votre organisation, vous pouvez tracer un histogramme ou un diagramme circulaire en utilisant la mesure # Applications avec la dimension CCL comme ci-dessous :

Dans certains cas, vous pouvez souhaiter obtenir une vue plus détaillée en divisant le site CCI en plages plus fines. Toutefois, l'utilisation directe de la dimension CCI avec la mesure du nombre de demandes peut conduire à des résultats fragmentés, comme le montre le tableau ci-dessous :

Au lieu de sélectionner directement la dimension CCI, utilisez les champs personnalisés pour regrouper les données en classant le champ CCI par catégories, ce qui permet d'obtenir des résultats plus lisibles.

Exemple 6 : Tendances journalières des événements d'application par CCL

Étendons le cas d'utilisation mentionné ci-dessus en incorporant un champ d'horodatage pour observer les tendances quotidiennes. En sélectionnant le champ Date de l'événement, en pivotant sur le niveau de confiance dans les nuages (CCL) et en mesurant le nombre d'alertes, nous pouvons tracer un graphique à zones empilées qui fournit des informations sur les points suivants :

• Le volume quotidien d'événements de demande

• La proportion d'événements pour chaque LCC

• Tendances des données au cours des 14 derniers jours

Le graphique à aires empilées pourrait simplifier l'observation, en permettant d'interpréter si les événements de demande à faible ou à faible degré de confiance augmentent ou diminuent au fil du temps. Vous avez remarqué que de telles tendances ne peuvent être visualisées efficacement que lorsque les données sont agrégées de manière significative. Si un champ de type horodatage inapproprié, tel que l'horodatage de l'événement, est utilisé, les résultats agrégés pivotés par le CCL deviendront clairsemés et fragmentés, ce qui rendra le graphique difficile à analyser.

Utilisez la date de l'événement comme axe horizontal du graphique : Les résultats de la requête sont effectivement agrégés et comptés sur une base quotidienne, ce qui facilite l'observation des tendances quotidiennes pour les 14 derniers jours de données.

Utilisez l'horodatage de l'événement comme axe horizontal du diagramme de zone : Les résultats de la requête deviennent épars, fragmentés et difficiles à interpréter pour identifier les tendances. De plus, il atteint facilement les limites de lignes, ce qui rend difficile l'analyse des données des 14 derniers jours.

Comportement du filtre de temps de l'événement de transaction

La plateforme Advanced Analytics renvoie des données pour les 55 dernières minutes mais pas pour la dernière heure, malgré des plages de données qui se chevauchent. Cela se produit pour les ensembles de données Transaction Events. Les requêtes portant sur les "55 dernières minutes" renvoient des données, mais pas les requêtes portant sur les "1 dernières heures", en raison du comportement du filtre temporel.

Le filtre « dernière heure » tronque à l'heure complète précédente (par exemple, 11h00-12h00), contrairement à une fenêtre glissante de 60 minutes. Cette logique de filtrage temporel est intentionnelle.

Navigateurs Web pris en charge

• Netskope recommande d'utiliser des navigateurs de niveau 1 pour des performances et des fonctionnalités optimales : Chrome, Firefox, Edge et Safari.
• Internet Explorer 11 (IE11) n'est plus pris en charge pour l'utilisation d'Advanced Analytics, et il est recommandé de migrer vers Microsoft Edge ou un autre navigateur pris en charge au niveau 1 pour une meilleure expérience.

Permissions

• L'accès aux fonctions et aux données d'Advanced Analytics est régi par les rôles et les autorisations attribués par les administrateurs de votre locataire.
• Les utilisateurs devront disposer des autorisations appropriées pour consulter les rapports, explorer les données, créer du contenu et effectuer d'autres actions au sein d'Advanced Analytics.
• Il est essentiel de comprendre et de configurer les autorisations des utilisateurs et l'accès au contenu pour garantir une expérience utilisateur sûre et efficace.
  • Par exemple, un utilisateur doit avoir le droit d'afficher périphérique sur la page de l'interface utilisateur du locataire pour pouvoir accéder à la collection de données du client périphérique sur le site Advanced Analytics. 

Traitement des données (client et backend)

Le chargement simultané de quantités excessives de données peut ralentir votre navigateur, voire le faire planter (erreur de mémoire saturée) en raison de limitations matérielles. Cela inclut (mais n'est pas limité à) la génération de résultats avec un grand nombre de lignes, la sélection d'un nombre excessif de colonnes, ou l'ajout de nombreux champs personnalisés. Ces problèmes de collision ne relèvent pas de l'assistance d'Advanced Analytics.

Pour Google Chrome, si vous rencontrez des messages d'erreur tels que « Aw, Snap ! », consultez la section Résoudre les erreurs de connexion et de chargement dans Chrome afin d'isoler d'abord le problème côté client.