Guide pratique : Connecter différentes sources de données

Article
09/20/2024

Important

Depuis le 20 septembre 2023, vous ne pouvez plus créer de ressources Metrics Advisor. Le service Metrics Advisor sera mis hors service le 1er octobre 2026.

Important

Microsoft vous recommande d’utiliser le flux d’authentification le plus sécurisé disponible. Certains flux d’authentification décrits dans cet article demandent d’avoir une très grande confiance en l’application et comporte des risques qui ne sont pas présents dans d’autres flux plus sécurisés. Vous ne devez utiliser ce flux que si d’autres flux plus sécurisés, tels que les identités managées, ne sont pas viables.

Utilisez cet article pour rechercher les paramètres et les exigences relatifs à la connexion de différents types de sources de données à Azure AI Metrics Advisor. Pour en savoir plus sur l’utilisation de vos données avec Metrics Advisor, consultez Intégrer vos données.

Types d’authentification pris en charge

Types d’authentification	Description
De base	Vous devez fournir des paramètres de base pour accéder aux sources de données. Par exemple, vous pouvez utiliser une chaîne de connexion ou un mot de passe. Les administrateurs du flux de données peuvent afficher ces informations d’identification.
Identité managée Azure	Les identités managées pour les ressources Azure sont une fonctionnalité de Microsoft Entra ID. Elle fournit aux services Azure une identité automatiquement managée dans Microsoft Entra ID. Vous pouvez utiliser cette identité pour authentifier tous les services qui prennent en charge l’authentification Microsoft Entra.
Chaîne de connexion Azure SQL	Stockez votre chaîne de connexion Azure SQL en tant qu’entité d’informations d’identification dans Metrics Advisor et utilisez-la directement chaque fois que vous importez des données de mesures. Seuls les administrateurs de l’entité d’informations d’identification peuvent voir ces informations d’identification, mais les lecteurs autorisés peuvent créer des flux de données sans avoir besoin de connaître les détails des informations d’identification.
Clé partagée Azure Data Lake Storage Gen2	Stockez votre clé de compte de lac de données en tant qu’entité d’informations d’identification dans Metrics Advisor et utilisez-la directement chaque fois que vous importez des données de mesures. Seuls les administrateurs de l’entité d’informations d’identification peuvent voir ces informations d’identification, mais les lecteurs autorisés peuvent créer des flux de données sans avoir besoin de connaître les détails des informations d’identification.
Principal du service	Stockez votre principal de service en tant qu’entité d’informations d’identification dans Metrics Advisor, et utilisez celle-ci directement chaque fois que vous importez des données de mesures. Seuls les administrateurs de l’entité d’informations d’identification peuvent voir les informations d’identification, mais les lecteurs autorisés peuvent créer des flux de données sans avoir besoin de connaître les détails des informations d’identification.
Principal de service du coffre de clés	Stockez votre principal de service dans coffre de clés en tant qu’entité d’informations d’identification dans Metrics Advisor, et utilisez celle-ci directement chaque fois que vous importez des données de mesures. Seuls les administrateurs d’une entité d’informations d’identification peuvent voir les informations d’identification, mais les lecteurs peuvent créer des flux de données sans avoir besoin de connaître les détails des informations d’identification.

Sources de données et types d’authentification correspondants

Sources de données	Types d’authentification
Application Insights	De base
Stockage Blob Azure (JSON)	De base Identité managée
Azure Cosmos DB (SQL)	De base
Azure Data Explorer (Kusto)	De base Identité managée Principal du service Principal de service du coffre de clés
Azure Data Lake Storage Gen2	De base Clé partagée Data Lake Storage Gen2 Principal du service Principal de service du coffre de clés
Azure Event Hubs	De base
Journaux Azure Monitor	De base Principal du service Principal de service du coffre de clés
Azure SQL Database / SQL Server	De base Identité managée Principal du service Principal de service du coffre de clés Chaîne de connexion Azure SQL
Stockage de tables Azure	De base
InfluxDB (InfluxQL)	De base
MongoDB	De base
MySQL	De base
PostgreSQL	De base

Les sections suivantes spécifient les paramètres requis pour tous les types d’authentification dans différents scénarios de source de données.

Application Insights

ID d’application : Il est utilisé pour identifier cette application lorsque vous utilisez l’API Application Insights. Pour obtenir l’ID d’application, suivez ces étapes :
1. À partir de votre ressource Application Insights, sélectionnez Accès API.
2. Copiez l’ID d’application généré dans le champ ID d’application dans Metrics Advisor.
Clé API : Les clés API sont utilisées par les applications en dehors du navigateur pour accéder à cette ressource. Pour obtenir la clé API, procédez comme suit :
1. À partir de la ressource Application Insights, sélectionnez Accès API.
2. Sélectionnez Créer une clé API.
3. Entrez une brève description, sélectionnez l’option Lire les données de télémétrie, puis sélectionnez Générer la clé.
  
  Important
  
  Copiez et enregistrez cette clé API. Elle ne vous sera plus jamais montrée. Si vous perdez cette clé, vous devez en créer une autre.
4. Copiez la clé API dans le champ Clé API dans Metrics Advisor.
Requête : Les journaux Application Insights reposent sur Azure Data Explorer ; les requêtes des journaux d’activité Azure Monitor utilisent une version du même langage de requête Kusto. La documentation du langage de requête Kusto doit constituer votre principale référence pour écrire une requête par rapport à Application Insights.

Exemple de requête :
```
[TableName] | where [TimestampColumn] >= datetime(@IntervalStart) and [TimestampColumn] < datetime(@IntervalEnd);
```
Vous pouvez également vous référer à Tutoriel : Écrire une requête valide pour des exemples plus spécifiques.

Stockage Blob Azure (JSON)

Chaîne de connexion : Il existe deux types d’authentification pour Stockage Blob Azure (JSON) :
- De base : Consultez Configurer des chaînes de connexion Stockage Azure pour plus d’informations sur la récupération de cette chaîne. Vous pouvez également vous rendre sur le portail Azure, accéder à votre ressource Stockage Blob Azure et trouver la chaîne de connexion directement dans Paramètres>Clés d’accès.
- Identité managée : Les identités managées pour les ressources Azure peuvent autoriser l’accès aux données de blob et de file d’attente. Cette fonctionnalité utilise les informations d’identification Microsoft Entra des applications qui s’exécutent dans les machines virtuelles Azure, les applications de fonction, les groupes de machines virtuelles identiques et d’autres services.
  
  Vous pouvez créer une identité managée dans le portail Azure pour votre ressource Stockage Blob Azure. Dans Contrôle d’accès (IAM) , sélectionnez Attributions de rôle, puis sélectionnez Ajouter. Un type de rôle suggéré est : Lecteur des données BLOB du stockage. Pour plus d’informations, consultez Utiliser une identité managée pour accéder à Stockage Azure.
Conteneur : Metrics Advisor s’attend à ce que les données de séries chronologiques soient stockées sous forme de fichiers blob (un blob par timestamp), sous un seul conteneur. Il s’agit du champ nom du conteneur.
Modèle de blob : Metrics Advisor utilise un chemin d’accès pour trouver le fichier JSON dans Stockage Blob. Voici un exemple de modèle de fichier blob, qui est utilisé pour trouver le fichier JSON dans Stockage Blob :%Y/%m/FileName_%Y-%m-%d-%h-%M.json. %Y/%m est le chemin d’accès et, si vous avez %d dans votre chemin d’accès, vous pouvez l’ajouter après %m. Si votre fichier JSON est nommé par date, vous pouvez également utiliser %Y-%m-%d-%h-%M.json.

Les paramètres suivants sont pris en charge :
- %Y est l’année au format yyyy.
- %m est le mois au format MM.
- %d est le jour au format dd.
- %h est l’heure au format HH.
- %M est la minute au format mm.
Par exemple, dans le jeu de données suivant, le modèle de blob doit être %Y/%m/%d/00/JsonFormatV2.json.
Version du format JSON : Définit le schéma de données dans les fichiers JSON. Metrics Advisor prend en charge les versions suivantes. Vous pouvez en choisir une pour remplir le champ :
- v1
  
  Seuls Nom et Valeur des mesures sont acceptés. Exemple :
```
{"count":11, "revenue":1.23}
```
- v2
  
  Les Dimensions et timestamp des mesures sont également acceptés. Exemple :
```
[
  {"date": "2018-01-01T00:00:00Z", "market":"en-us", "count":11, "revenue":1.23},
  {"date": "2018-01-01T00:00:00Z", "market":"zh-cn", "count":22, "revenue":4.56}
]
```
Un seul timestamp est autorisé par fichier JSON.

Azure Cosmos DB (SQL)

Chaîne de connexion : La chaîne de connexion pour accéder à votre instance Azure Cosmos DB. Elle se trouve dans la ressource Azure Cosmos DB dans le portail Azure, dans Clés. Pour plus d’informations, consultez Sécuriser l’accès aux données dans Azure Cosmos DB.
Base de données : La base de données à interroger. Dans le portail Azure, sous Conteneurs, cliquez sur Parcourir pour rechercher la base de données.
ID de la collection : ID de collection sur lequel effectuer la requête. Dans le portail Azure, sous Conteneurs, cliquez sur Parcourir pour rechercher l’ID de collection.
Requête SQL : Une requête SQL permettant d’obtenir et de formuler des données dans des données de séries chronologiques multidimensionnelles. Vous pouvez utiliser les variables @IntervalStart et @IntervalEnd dans votre requête. Elles doivent utiliser le format suivant : yyyy-MM-ddTHH:mm:ssZ.

Exemple de requête :
```
SELECT [TimestampColumn], [DimensionColumn], [MetricColumn] FROM [TableName] WHERE [TimestampColumn] >= @IntervalStart and [TimestampColumn] < @IntervalEnd    
```
Pour plus d’informations, référez-vous au tutoriel sur l’écriture d’une requête valide.

Azure Data Explorer (Kusto)

Chaîne de connexion : Il existe quatre types d’authentification pour Azure Data Explorer (Kusto), à savoir les types de base, principal de service, principal de service du coffre de clés et identité managée. La source de données dans la chaîne de connexion doit être au format URI (commence par « https »). Vous pouvez trouver l’URI sur le portail Azure.
- De base : Metrics Advisor prend en charge l’accès à Azure Data Explorer (Kusto) à l’aide de l’authentification d’application Microsoft Entra. Vous devez créer et inscrire une application Microsoft Entra, puis l’autoriser à accéder à une base de données Azure Data Explorer. Pour plus d’informations, consultez Créer une inscription d’application Microsoft Entra dans Azure Data Explorer. Voici un exemple de chaîne de connexion :
```
Data Source=<URI Server>;Initial Catalog=<Database>;AAD Federated Security=True;Application Client ID=<Application Client ID>;Application Key=<Application Key>;Authority ID=<Tenant ID>
```
- Principal de service : Un principal de service est une instance concrète créée à partir de l’objet d’application. Le principal de service hérite de certaines propriétés de cet objet d’application. L’objet principal de service définit ce que l’application peut réellement faire dans le locataire spécifique, qui peut accéder à l’application, ainsi que les ressources auxquelles l’application peut accéder. Pour utiliser un principal de service dans Metrics Advisor :
  1. Créer l’inscription d’application Microsoft Entra. Pour plus d’informations, consultez Créer une inscription d’application Microsoft Entra dans Azure Data Explorer.
  2. Gérez les autorisations de base de données Azure Data Explorer. Pour plus d’informations, consultez Gérer les autorisations de base de données d’Azure Data Explorer.
  3. Créez une entité d’informations d’identification dans Metrics Advisor. Découvrez comment créer une entité d’informations d’identification dans Metrics Advisor afin de pouvoir choisir cette entité lorsque vous ajoutez un flux de données pour le type d’authentification du principal de service.
  Voici un exemple de chaîne de connexion :
```
Data Source=<URI Server>;Initial Catalog=<Database>
```
- Principal de service du coffre de clés : Azure Key Vault permet de protéger les clés de chiffrement et les valeurs secrètes utilisées par les applications et services cloud. Key Vault vous permet de chiffrer les clés et les valeurs secrètes. Vous devez d’abord créer un principal de service, puis le stocker dans le coffre de clés. Pour plus d’informations, consultez Créer une entité d’informations d’identification pour le principal de service du coffre de clés pour suivre la procédure détaillée de définition du principal de service du coffre de clés. Voici un exemple de chaîne de connexion :
```
Data Source=<URI Server>;Initial Catalog=<Database>
```
- Identité managée : L’identité managée pour les ressources Azure peut autoriser l’accès aux données de blob et de file d’attente. L’identité managée utilise les informations d’identification Microsoft Entra des applications qui s’exécutent dans les machines virtuelles Azure, les applications de fonction, les groupes de machines virtuelles identiques et d’autres services. En utilisant une identité managée pour ressources Azure et l’authentification Microsoft Entra, vous pouvez éviter de stocker des informations d’identification avec les applications qui s’exécutent dans le cloud. Découvrez comment autoriser avec une identité managée.
  
  Vous pouvez créer une identité managée dans le portail Azure pour votre instance Azure Data Explorer (Kusto). Sélectionnez Autorisations>Ajouter. Le type de rôle suggéré est : administrateur/lecteur.
  
  Voici un exemple de chaîne de connexion :
```
Data Source=<URI Server>;Initial Catalog=<Database>
```
Requête : Pour obtenir et formuler des données dans des données de séries chronologiques multidimensionnelles, consultez Langage de la requête Kusto. Vous pouvez utiliser les variables @IntervalStart et @IntervalEnd dans votre requête. Elles doivent utiliser le format suivant : yyyy-MM-ddTHH:mm:ssZ.

Exemple de requête :
```
[TableName] | where [TimestampColumn] >= datetime(@IntervalStart) and [TimestampColumn] < datetime(@IntervalEnd);    
```
Pour plus d’informations, référez-vous au tutoriel sur l’écriture d’une requête valide.

Azure Data Lake Storage Gen2

Nom du compte : Les types d’authentification pour Azure Data Lake Storage Gen2 sont les types de base, clé partagée Azure Data Lake Storage Gen2, principal de service et principal de service du coffre de clés.
- De base : Le nom de compte de votre compte Azure Data Lake Storage Gen2. Vous pouvez le trouver dans votre ressource de compte de stockage Azure (Azure Data Lake Storage Gen2), dans Clés d’accès.
- Clé partagée Azure Data Lake Storage Gen2 : Tout d’abord, vous spécifiez la clé de compte pour accéder à votre compte Azure Data Lake Storage Gen2 (il s’agit de la même clé de compte que celle du type d’authentification de base). Vous pouvez le trouver dans votre ressource de compte de stockage Azure (Azure Data Lake Storage Gen2), dans Clés d’accès. Ensuite, vous créez une entité d’informations d’identification pour le type de clé partagée Azure Data Lake Storage Gen2, et vous renseignez la clé de compte.
  
  Le nom du compte est le même que le type d’authentification de base.
- Principal de service : Un principal de service est une instance concrète créée à partir de l’objet d’application, et il hérite de certaines propriétés de cet objet d’application. Un principal de service est créé dans chaque locataire dans lequel l’application est utilisée, et il fait référence à l’objet application global unique. L’objet principal de service définit ce que l’application peut réellement faire dans le locataire spécifique, qui peut accéder à l’application, ainsi que les ressources auxquelles l’application peut accéder.
  
  Le nom du compte est le même que le type d’authentification de base.
  
  Étape 1 : Créez et inscrivez une application Microsoft Entra, puis autorisez-la à accéder à la base de données. Pour plus d’informations, consultez Créer une inscription d’application Microsoft Entra.
  
  Étape 2 : Attribuez des rôles.
  1. Dans le portail Azure, accédez au service Comptes de stockage.
  2. Sélectionnez le compte Azure Data Lake Storage Gen2 à utiliser avec cette inscription d’application.
  3. Sélectionnez Contrôle d’accès (IAM) .
  4. Sélectionnez + Ajouter, puis sélectionnez Ajouter une attribution de rôle à partir du menu.
  5. Définissez le champ Sélectionner sur le nom de l’application Microsoft Entra, puis définissez le rôle sur Contributeur aux données Blob du stockage. Ensuite, sélectionnez Enregistrer.
  Étape 3 : Créez une entité d’informations d’identification dans Metrics Advisor, afin de pouvoir choisir cette entité lorsque vous ajoutez un flux de données pour le type d’authentification du principal de service.
- Principal de service du coffre de clés : Key Vault permet de protéger les clés de chiffrement et les valeurs secrètes utilisées par les applications et services cloud. Key Vault vous permet de chiffrer les clés et les valeurs secrètes. Créez d’abord un principal de service, puis stockez-le dans un coffre de clés. Pour plus d’informations, consultez Créer une entité d’informations d’identification pour le principal de service du coffre de clés. Le nom du compte est le même que le type d’authentification de base.
Clé de compte (nécessaire uniquement pour le type d’authentification de base) : Spécifiez la clé de compte pour accéder à votre compte Azure Data Lake Storage Gen2. Vous pouvez le trouver dans votre ressource de compte de stockage Azure (Azure Data Lake Storage Gen2), dans Clés d’accès.
Nom du système de fichiers (conteneur) : Pour Metrics Advisor, vous stockez vos données de séries chronologiques sous forme de fichiers blob (un blob par timestamp) ,sous un seul conteneur. Il s’agit du champ nom du conteneur. Vous pouvez le trouver dans votre instance de compte de stockage Azure (Azure Data Lake Storage Gen2). Dans Data Lake Storage, sélectionnez Conteneurs, et vous verrez le nom du conteneur.
Modèle de répertoire : Il s’agit du modèle de répertoire du fichier blob. Les paramètres suivants sont pris en charge :
- %Y est l’année au format yyyy.
- %m est le mois au format MM.
- %d est le jour au format dd.
- %h est l’heure au format HH.
- %M est la minute au format mm.
Exemple de requête pour une métrique quotidienne : %Y/%m/%d.

Exemple de requête pour une métrique horaire : %Y/%m/%d/%h.
Modèle de fichier : Metrics Advisor utilise un chemin d’accès pour trouver le fichier JSON dans Stockage Blob. Voici un exemple de modèle de fichier blob, qui est utilisé pour trouver le fichier JSON dans Stockage Blob :%Y/%m/FileName_%Y-%m-%d-%h-%M.json. %Y/%m est le chemin d’accès et, si vous avez %d dans votre chemin d’accès, vous pouvez l’ajouter après %m.

Les paramètres suivants sont pris en charge :
- %Y est l’année au format yyyy.
- %m est le mois au format MM.
- %d est le jour au format dd.
- %h est l’heure au format HH.
- %M est la minute au format mm.
Metrics Advisor prend en charge le schéma de données dans les fichiers JSON, comme dans l’exemple suivant :
```
[
   {"date": "2018-01-01T00:00:00Z", "market":"en-us", "count":11, "revenue":1.23},
   {"date": "2018-01-01T00:00:00Z", "market":"zh-cn", "count":22, "revenue":4.56}
]
```

Azure Event Hubs

Limites : Tenez compte des limites suivantes de l’intégration.
- L’intégration de Metrics Advisor à Event Hubs ne prend pas en charge actuellement plus de trois flux de données actifs dans une instance Metrics Advisor en préversion publique.
- Metrics Advisor commencera toujours à consommer les messages du dernier décalage, y compris lors de la réactivation d’un flux de données interrompu.
  - Les messages générés pendant la période de pause du flux de données seront perdus.
  - L’heure de début de l’ingestion du flux de données est automatiquement définie sur le timestamp UTC actuel, lors de la création du flux de données. Cette heure est uniquement utilisée à titre de référence.
- Un seul flux de données peut être utilisé par groupe de consommateurs. Pour réutiliser un groupe de consommateurs d’un autre flux de données supprimé, vous devez attendre au moins dix minutes après la suppression.
- La chaîne de connexion et le groupe de consommateurs ne peuvent pas être modifiés après la création du flux de données.
- Pour les messages Event Hubs, seul le format JSON est pris en charge, et les valeurs JSON ne peuvent pas être un objet JSON imbriqué. L’élément de niveau supérieur peut être un objet JSON ou un tableau JSON.
  
  Les messages valides sont les suivants :
  
  Objet JSON unique :
```
{
"metric_1": 234, 
"metric_2": 344, 
"dimension_1": "name_1", 
"dimension_2": "name_2"
}
```
  Tableau JSON :
```
[
    {
        "timestamp": "2020-12-12T12:00:00", "temperature": 12.4,
        "location": "outdoor"
    },
    {
        "timestamp": "2020-12-12T12:00:00", "temperature": 24.8,
        "location": "indoor"
    }
]
```
Chaîne de connexion : Accédez à l’instance d’Event Hubs. Ajoutez ensuite une nouvelle stratégie ou choisissez une stratégie d’accès partagé existante. Copiez la chaîne de connexion dans le panneau contextuel.

Voici un exemple de chaîne de connexion :
```
Endpoint=<Server>;SharedAccessKeyName=<SharedAccessKeyName>;SharedAccessKey=<SharedAccess Key>;EntityPath=<EntityPath>
```
Groupe de consommateurs : Un groupe de consommateurs est une vue (état, position ou décalage) d’un Event Hub dans sa totalité. Vous le trouvez dans le menu Groupes de consommateurs d’une instance d’Azure Event Hubs. Un groupe de consommateurs peut uniquement servir un flux de données. Créez un nouveau groupe de consommateurs pour chaque flux de données.
Timestamp (facultatif) : Metrics Advisor utilise le timestamp d’Event Hubs comme timestamp de l’événement, si la source de données utilisateur ne contient pas de champ de timestamp. Le champ de timestamp est facultatif. Si aucune colonne de timestamp n’est sélectionnée, le service utilise l’heure de mise en file d’attente comme timestamp.

Le champ de timestamp doit correspondre à l’un de ces deux formats :
- YYYY-MM-DDTHH:MM:SSZ
- Nombre de secondes ou de millisecondes à partir de l’époque 1970-01-01T00:00:00Z.
Le timestamp est aligné à gauche sur la granularité. Par exemple, si le timestamp est 2019-01-01T00:03:00Z, la granularité est de 5 minutes, puis Metrics Advisor aligne le timestamp sur 2019-01-01T00:00:00Z. Si le timestamp de l’événement est 2019-01-01T00:10:00Z, Metrics Advisor utilise le timestamp directement, sans aucun alignement.

Journaux Azure Monitor

Les journaux d’activité Azure Monitor proposent les types d’authentification suivants : de base, principal de service et principal de service du coffre de clés.

De base : Vous devez renseigner les champs ID de locataire, ID client, Clé secrète client et ID d’espace de travail. Pour obtenir l’ID de locataire, l’ID client et la clé secrète client, consultez Inscrire une application ou une API web. Vous trouverez l’ID d’espace de travail sur le portail Azure.
Principal de service : Un principal de service est une instance concrète créée à partir de l’objet d’application, et il hérite de certaines propriétés de cet objet d’application. Un principal de service est créé dans chaque locataire dans lequel l’application est utilisée, et il fait référence à l’objet application global unique. L’objet principal de service définit ce que l’application peut réellement faire dans le locataire spécifique, qui peut accéder à l’application, ainsi que les ressources auxquelles l’application peut accéder.

Étape 1 : Créez et inscrivez une application Microsoft Entra, puis autorisez-la à accéder à une base de données. Pour plus d’informations, consultez Créer une inscription d’application Microsoft Entra.

Étape 2 : Attribuez des rôles.
1. Dans le portail Azure, accédez au service Comptes de stockage.
2. Sélectionnez Contrôle d’accès (IAM) .
3. Sélectionnez + Ajouter, puis sélectionnez Ajouter une attribution de rôle à partir du menu.
4. Définissez le champ Sélectionner sur le nom de l’application Microsoft Entra, puis définissez le rôle sur Contributeur aux données Blob du stockage. Ensuite, sélectionnez Enregistrer.
Étape 3 : Créez une entité d’informations d’identification dans Metrics Advisor, afin de pouvoir choisir cette entité lorsque vous ajoutez un flux de données pour le type d’authentification du principal de service.
Principal de service du coffre de clés : Key Vault permet de protéger les clés de chiffrement et les valeurs secrètes utilisées par les applications et services cloud. Key Vault vous permet de chiffrer les clés et les valeurs secrètes. Créez d’abord un principal de service, puis stockez-le dans un coffre de clés. Pour plus d’informations, consultez Créer une entité d’informations d’identification pour le principal de service du coffre de clés.
Requête : Spécifiez la requête. Pour plus d’informations, consultez Requêtes de journal dans Azure Monitor.

Exemple de requête :
```
[TableName]
| where [TimestampColumn] >= datetime(@IntervalStart) and [TimestampColumn] < datetime(@IntervalEnd)
| summarize [count_per_dimension]=count() by [Dimension]
```
Pour plus d’informations, référez-vous au tutoriel sur l’écriture d’une requête valide.

Azure SQL Database | SQL Server

Chaîne de connexion : Les types d’authentification pour Azure SQL Database et SQL Server sont les types de base, identité managée, chaîne de connexion Azure SQL, principal de service et principal de service du coffre de clés.
- De base : Metrics Advisor accepte une chaîne de connexion de style ADO.NET pour une source de données SQL Server. Voici un exemple de chaîne de connexion :
```
Data Source=<Server>;Initial Catalog=<db-name>;User ID=<user-name>;Password=<password>
```
- Identité managée : L’identité managée pour les ressources Azure peut autoriser l’accès aux données de blob et de file d’attente. Pour ce faire, elle utilise les informations d’identification Microsoft Entra des applications qui s’exécutent dans les machines virtuelles Azure, les applications de fonction, les groupes de machines virtuelles identiques et d’autres services. En utilisant une identité managée pour ressources Azure et l’authentification Microsoft Entra, vous pouvez éviter de stocker des informations d’identification avec les applications qui s’exécutent dans le cloud. Pour activer votre entité managée, procédez comme suit :
1. L’activation d’une identité managée affectée par le système s’effectue en un seul clic. Dans le portail Azure, pour votre espace de travail Metrics Advisor, allez dans Paramètres>Identité>Système attribué. Définissez ensuite l’état comme activé.
2. Activez l’authentification Microsoft Entra. Dans le portail Azure, pour votre source de données, accédez à Paramètres>Administrateur Active Directory. Sélectionnez Définir un administrateur et sélectionnez un compte d’utilisateur Microsoft Entra à désigner comme administrateur du serveur. Ensuite, choisissez Sélectionner.
3. Activez l’identité managée dans Metrics Advisor. Vous pouvez modifier une requête dans l’outil de gestion de la base de données ou dans le portail Azure.
  
  Outil de gestion : Dans votre outil de gestion de la base de données, sélectionnez Active Directory – Authentification universelle avec MFA dans le champ d’authentification. Dans le champ Nom d’utilisateur, entrez le nom du compte Microsoft Entra que vous avez défini en tant qu’administrateur du serveur, à l’étape 2. Par exemple, ce peut être test@contoso.com.
  
  Portail Azure : Dans votre base de données SQL, sélectionnez Éditeur de requête et connectez-vous au compte administrateur.
  
  Ensuite, dans la fenêtre de requête, exécutez la commande suivante (notez qu’il s’agit de la même que pour la méthode utilisant l’outil de gestion) :
```
CREATE USER [MI Name] FROM EXTERNAL PROVIDER
ALTER ROLE db_datareader ADD MEMBER [MI Name]
```
  Notes
  
  Le MI Name est le nom de l’identité managée dans Metrics Advisor (pour le principal de service, il doit être remplacé par le nom de principal du service). Pour plus d’informations, consultez Autoriser avec une identité managée.
  
  Voici un exemple de chaîne de connexion :
```
Data Source=<Server>;Initial Catalog=<Database>
```
- Chaîne de connexion Azure SQL :
  
  Voici un exemple de chaîne de connexion :
```
Data Source=<Server>;Initial Catalog=<Database>;User ID=<user-name>;Password=<password>
```
- Principal de service : Un principal de service est une instance concrète créée à partir de l’objet d’application, et il hérite de certaines propriétés de cet objet d’application. Un principal de service est créé dans chaque locataire dans lequel l’application est utilisée, et il fait référence à l’objet application global unique. L’objet principal de service définit ce que l’application peut réellement faire dans le locataire spécifique, qui peut accéder à l’application, ainsi que les ressources auxquelles l’application peut accéder.
  
  Étape 1 : Créez et inscrivez une application Microsoft Entra, puis autorisez-la à accéder à une base de données. Pour plus d’informations, consultez Créer une inscription d’application Microsoft Entra.
  
  Étape 2 : Suivez les étapes décrites précédemment, dans la section Identité managée dans SQL Server.
  
  Étape 3 : Créez une entité d’informations d’identification dans Metrics Advisor, afin de pouvoir choisir cette entité lorsque vous ajoutez un flux de données pour le type d’authentification du principal de service.
  
  Voici un exemple de chaîne de connexion :
```
Data Source=<Server>;Initial Catalog=<Database>
```
- Principal de service du coffre de clés : Key Vault permet de protéger les clés de chiffrement et les valeurs secrètes utilisées par les applications et services cloud. Key Vault vous permet de chiffrer les clés et les valeurs secrètes. Créez d’abord un principal de service, puis stockez-le dans un coffre de clés. Pour plus d’informations, consultez Créer une entité d’informations d’identification pour le principal de service du coffre de clés. Vous pouvez également trouver votre chaîne de connexion dans votre ressource Azure SQL Server, dans Paramètres>Chaînes de connexion.
  
  Voici un exemple de chaîne de connexion :
```
Data Source=<Server>;Initial Catalog=<Database>
```
Requête : Utilisez une requête SQL pour obtenir et formuler des données dans des données de séries chronologiques multidimensionnelles. Vous pouvez utiliser @IntervalStart et @IntervalEnd dans votre requête pour vous aider à obtenir une valeur de métrique attendue dans un intervalle. Elles doivent utiliser le format suivant : yyyy-MM-ddTHH:mm:ssZ.

Exemple de requête :
```
SELECT [TimestampColumn], [DimensionColumn], [MetricColumn] FROM [TableName] WHERE [TimestampColumn] >= @IntervalStart and [TimestampColumn] < @IntervalEnd    
```

Stockage de tables Azure

Chaîne de connexion : Créez une URL de signature d’accès partagé (SAP) et renseignez-la ici. Le moyen le plus simple de générer une URL SAP consiste à utiliser le portail Azure. Tout d’abord, sous Paramètres, allez sur le compte de stockage auquel vous voulez accéder. Sélectionnez ensuite Signature d’accès partagé. Cochez les cases Table et Objet, puis sélectionnez Générer la signature d’accès partagé et la chaîne de connexion. Dans l’espace de travail Metrics Advisor, copiez et collez l’URL SAP du service de table dans la zone de texte.
Nom de la table : Spécifiez une table à interroger. Vous pouvez le trouver dans votre instance de compte de stockage Azure. Dans la section Service de table, sélectionnez Tables.
Requête : Vous pouvez utiliser @IntervalStart et @IntervalEnd dans votre requête pour vous aider à obtenir une valeur de métrique attendue dans un intervalle. Elles doivent utiliser le format suivant : yyyy-MM-ddTHH:mm:ssZ.

Exemple de requête :
```
PartitionKey ge '@IntervalStart' and PartitionKey lt '@IntervalEnd'
```
Pour plus d’informations, consultez le tutoriel sur l’écriture d’une requête valide.

InfluxDB (InfluxQL)

Chaîne de connexion : La chaîne de connexion pour accéder à InfluxDB.
Base de données : La base de données à interroger.
Requête : Une requête SQL permettant d’obtenir et de formuler des données dans des données de séries chronologiques multidimensionnelles pour ingestion.

Exemple de requête :
```
SELECT [TimestampColumn], [DimensionColumn], [MetricColumn] FROM [TableName] WHERE [TimestampColumn] >= @IntervalStart and [TimestampColumn] < @IntervalEnd
```

Pour plus d’informations, référez-vous au tutoriel sur l’écriture d’une requête valide.

Nom d’utilisateur : Facultatif pour l’authentification.
Mot de passe : Facultatif pour l’authentification.

MongoDB

Chaîne de connexion : La chaîne de connexion pour accéder à MongoDB.
Base de données : La base de données à interroger.
Requête : Une commande permettant d’obtenir et de formuler des données dans des données de séries chronologiques multidimensionnelles pour ingestion. Vérifiez la commande sur db.runCommand().

Exemple de requête :
```
{"find": "[TableName]","filter": { [Timestamp]: { $gte: ISODate(@IntervalStart) , $lt: ISODate(@IntervalEnd) }},"singleBatch": true}
```

MySQL

Chaîne de connexion : La chaîne de connexion pour accéder à une base de données MySQL.
Requête : Une requête SQL permettant d’obtenir et de formuler des données dans des données de séries chronologiques multidimensionnelles pour ingestion.

Exemple de requête :
```
SELECT [TimestampColumn], [DimensionColumn], [MetricColumn] FROM [TableName] WHERE [TimestampColumn] >= @IntervalStart and [TimestampColumn]< @IntervalEnd
```
Pour plus d’informations, référez-vous au tutoriel sur l’écriture d’une requête valide.

PostgreSQL

Chaîne de connexion : La chaîne de connexion pour accéder à une base de données PostgreSQL.
Requête : Une requête SQL permettant d’obtenir et de formuler des données dans des données de séries chronologiques multidimensionnelles pour ingestion.

Exemple de requête :
```
SELECT [TimestampColumn], [DimensionColumn], [MetricColumn] FROM [TableName] WHERE [TimestampColumn] >= @IntervalStart and [TimestampColumn] < @IntervalEnd
```
Pour plus d’informations, référez-vous au tutoriel sur l’écriture d’une requête valide.

Étapes suivantes

En attendant que vos données de mesures soient ingérées dans le système, découvrez comment gérer des configurations de flux de données.
Lorsque vos données de mesures sont ingérées, vous pouvez configurer les métriques et ajuster la configuration de détection.

Partager via