Création et utilisation des perspectives d'application

L'assistant de création de PA est un moyen interactif et simple de créer une PA. Il comporte trois étapes :

1. Sélectionner un plan directeur dans les cas d'utilisation courants.
2. Spécifier le modèle de l'application en sélectionnant les balises et les valeurs pour identifier les services ou les nœuds finaux à inclure.
3. Fournir les informations finales pour terminer la création.

Chacune de ces étapes est brièvement expliquée à côté des captures d'écran. À tout moment, vous pouvez passer en mode avancé en cliquant sur le bouton « Passer en mode avancé ».

L'écran de la première étape est présenté comme suit. La création d'un AP commence par la sélection d'un des modèles :

• Services ou nœuds finaux : la façon la plus simple de créer une PA consiste à sélectionner directement la collection de services ou de nœuds finaux.
• Un parcours utilisateur critique : similaire au modèle précédent, mais avec des paramètres par défaut pour une utilisation avec la fonctionnalité SLI / SLO. Ce plan directeur sera amélioré à l'avenir pour une intégration SLI/SLO plus profonde.
• Environnement ou région : sélectionner les services en fonction d'un environnement (par exemple, « production » ou « staging », qui peuvent être indiqués par la agent.zone balise ) ou d'une région (par exemple, « US East »).
• Un client ou un locataire important : en utilisant des balises personnalisées ou les informations du paramètre « HTTP », il est possible de créer un point d'accès (AP) dédié à votre client ou locataire important.
• Kubernetes ou « Container » : une approche axée sur la plateforme permettant de définir l'ensemble des services qui composent un point d'accès (AP).
• Attributs de requête : un point d'accès basé sur les attributs de requête (par exemple, les en-têtes HTTP, les paramètres de requête).
• Technologie : ensemble de services reposant sur une technologie (par exemple, MySQL, toutes les bases de données) ou le nom d'une application.
• Balises personnalisées : vous pouvez ajouter vos propres métadonnées sous forme de balises personnalisées via le SDK; les données de ces balises personnalisées définissent l'ensemble des services ou des points de terminaison.

Une fois le plan sélectionné, la fiche de recette est mise à jour pour afficher des informations sur le modèle ainsi que des conseils pour la création de l'AP. Sélectionnez « Suivant » pour passer à la deuxième étape.

La deuxième étape comporte deux critères permettant de spécifier les sources de données qui forment la PA. Le premier critère concerne le menu de sélection des balises et le générateur de requêtes. Le deuxième critère concerne le choix des services en aval à inclure. Une fois les critères sélectionnés ou mis à jour, la fenêtre d'aperçu affiche les services sélectionnés sur la base des données de la dernière heure. Cela vous permet d'affiner votre sélection de manière interactive en apportant des modifications et en voyant immédiatement le résultat. Ces deux critères ne nécessitent pas beaucoup d'explications.

Le générateur de requêtes est similaire à celui présenté dans Unbounded Analytics. Chaque plan directeur comporte un ensemble organisé de menus et de balises associées spécifiques au menu. Cela simplifie la sélection d'une balise. Vous pouvez utiliser plusieurs filtres pour spécifier une perspective d'application. La fenêtre d'aperçu répertorie tous les services qui correspondent aux filtres.

Les services en aval constituent l'autre critère de mise à jour de la fenêtre d'aperçu, car ils déterminent quelles informations supplémentaires sont collectées dans le cadre de l'AP. Il existe trois options :

• Pas de services en aval : n'incluez que les services qui correspondent à vos filtres ( l 'ensemble de base). Vous n'incluez aucun service dépendant. Cette approche s'avère utile lorsque vous considérez les services comme des boîtes noires, par exemple les services qui correspondent à des API tierces ou à des intégrations externes.
• Services de base de données et de messagerie situés immédiatement en aval : inclure l'ensemble de base et l'étendre aux services de base de données et de messagerie avec lesquels cet ensemble interagit directement. Vous voyez chaque service ainsi que ses bases de données et ses systèmes de messagerie directement associés, mais aucune autre dépendance. Utilisez cette option lorsque vous avez besoin de savoir comment les services stockent les données ou échangent des messages, par exemple lorsque vous gérez un ensemble de microservices et leurs dépendances directes en matière d'infrastructure.
• Tous les services en aval : inclure l'ensemble de la chaîne de dépendances de bout en bout pour l'ensemble de base. Le système détecte et ajoute automatiquement tous les services en aval associés à chaque niveau. Vous bénéficiez d'une vue d'ensemble complète du flux des requêtes entre les services, les bases de données et les systèmes de messagerie. Utilisez cette option lorsque vous avez besoin d'une visibilité complète sur l'ensemble de la topologie de l'application, notamment pour l'analyse des causes profondes et le dépannage d'interactions complexes entre les services. Lorsque vous sélectionnez « Tous les services en aval », la portée s'étend au-delà de l'ensemble de base filtré pour inclure toutes les dépendances en aval.

Une seule de ces options peut être sélectionnée à la fois.

La figure suivante est un exemple de création d'un point d'accès basé sur un espace de nom Kubernetes . « Tous les services en aval » est sélectionné pour que cette PA puisse fournir à la fois la vue opaque pour surveiller l'expérience d'un client et la vue de bout en bout pour l'identification et la résolution des incidents.

Si l'utilisateur « Instana » fait partie d'un groupe doté du rôle « Contributor », les nouveaux points d'accès ne peuvent être créés que dans le cadre prédéfini du filtre de contribution. Pour plus d'informations sur la définition du filtre de contribution, voir Applications. Si l'utilisateur Instana appartient à plusieurs groupes avec le rôle de contributeur, la liste des filtres de contribution s'affiche. Sélectionnez un filtre dans la liste.

Cliquez sur « Suivant » pour passer à la troisième étape.

La troisième et dernière étape s'affiche comme suit: le nom de l'AP est ajouté et la vue de tableau de bord par défaut est sélectionnée. La vue de tableau de bord par défaut peut être modifiée à tout moment en sélectionnant simplement un menu. Les informations de la fenêtre d'aperçu sont également affichées pour indiquer les services qui ont été sélectionnés. Ceci est illustré dans la figure comme suit.

Le plan directeur « Services ou nœuds finaux » peut être utilisé pour sélectionner plusieurs éléments. Certaines fonctions méritent d'être soulignées.

Dans la figure suivante, l'utilisateur a sélectionné trois services différents dans le menu Services. Comme ces services sont reliés par l'opérateur OR booléen et non par AND l'opérateur, tous les services sont inclus dans l'AP.

Pour sélectionner plusieurs points de terminaison, vous devez d'abord choisir un service, puis sélectionner plusieurs points de terminaison de ce service. Dans la figure suivante, où trois noeuds finaux sont sélectionnés dans le service de panier.

À tout moment, vous pouvez passer du mode assistant simple au mode avancé en cliquant sur le bouton. Dans l'exemple de l'étape 2, lorsque vous sélectionnez le mode avancé, l'écran suivant s'affiche. Toutes les données que vous avez saisies précédemment sont reportées dans cette vue. L'inverse est également vrai : ces données ne sont pas perdues si vous sélectionnez le « Mode simple ».

Si l'utilisateur « Instana » fait partie d'un groupe doté du rôle « Contributor », les nouveaux points d'accès ne peuvent être créés que dans le cadre prédéfini du filtre de contribution. Pour plus d'informations sur la définition du filtre de contribution, voir Applications. Si l'utilisateur Instana appartient à plusieurs groupes avec le rôle de contributeur, la liste des filtres de contribution s'affiche. Sélectionnez un filtre dans la liste.

Les perspectives d'application existantes peuvent être mises à jour ou supprimées. Notez qu'une fois qu'une perspective d'application est mise à jour, la nouvelle configuration ne s'applique qu'aux nouveaux appels entrants après la modification. Les appels et les services qui étaient inclus dans l'application avant la modification ne sont pas affectés.

1. Dans la barre latérale, cliquez sur Applications, puis sélectionnez la perspective d'application.
2. Sélectionnez l'onglet « Configuration ».

Un maximum de 50 candidatures est autorisé par appel à projets. Cette restriction s'applique séparément aux « applications sources » et aux « applications cibles ». Par conséquent, un appel peut être associé à un maximum de 50 perspectives d'application source et de 50 perspectives d'application de destination. Si un appel dépasse cette limite, seules les 50 premières perspectives d'application de chaque type sont associées à l'appel.

Si un appel est associé à un nombre élevé de perspectives d'application, cela indique généralement un problème lié à une mauvaise configuration des applications. Une erreur de configuration courante consiste à utiliser par inadvertance l'opérateur OR logique « AND » au lieu de « OR AND » dans les expressions de filtrage des balises.

Par exemple, si vous créez une perspective d'application avec le filtre service.name = "service-a" OR agent.zone = "prod", celle-ci correspond à tous les appels vers service-a dans n'importe quelle zone, ainsi qu'à tous les appels vers n'importe quel service dans la prod zone. Cette configuration pourrait, sans le vouloir, inclure beaucoup plus de services que prévu.

Une approche plus ciblée consiste à utiliser service.name = "service-a" AND agent.zone = "prod", si vous souhaitez surveiller uniquement les processus service-a s'exécutant dans la prod zone.

Vérifiez régulièrement les configurations de perspective de votre application afin de vous assurer qu'elles sont correctement délimitées et qu'elles ne sont pas trop générales. Des paramètres mal configurés ou des paramètres trop généraux peuvent entraîner des problèmes de performances et des résultats de surveillance prêtant à confusion.

Si votre vue d'application n'affiche pas les mêmes appels qu'un filtre correspondant dans Analytics, cette différence est due à la distinction entre majuscules et minuscules appliquée aux filtres de balises. Pour assurer la compatibilité ascendante avec les définitions d'application existantes, les filtres de balises dans les configurations d'application sont appliqués selon des règles de sensibilité à la casse différentes de celles utilisées dans Call Analytics.

• Analyse des appels : filtres insensibles à la casse

  Dans la vue « Analyse des appels », la plupart des filtres ne tiennent pas compte de la casse, à l'exception des identifiants et de la partie « clé » de certaines données de type clé-valeur.

• Perspective d'application : filtres tenant compte de la casse

  Du point de vue de l'application, la plupart des filtres sont sensibles à la casse. Les valeurs de filtrage doivent correspondre exactement à la casse des valeurs réelles. Une différence de casse entraîne l'exclusion des appels.

Exemple : si vous tracez des appels dont le chemin d' HTTP est v1/myApp, ces appels apparaîtront dans la vue « Calls Analytics » lorsque vous appliquerez un filtre sur HTTP > Call Http Path = v1/myapp (en minuscules a). Mais lorsque vous définissez une perspective d'application avec ce filtre de balises, ces mêmes appels ne sont pas inclus dans l'application. Pour les intégrer à l'application, vous devez définir le filtre en respectant exactement la même casse que la valeur réelle HTTP > Call Http Path = v1/myApp (majuscules A).