Поделиться через

Практическое руководство. Подключение разных источников данных

  • Статья

Внимание

Начиная с 20 сентября 2023 г. вы не сможете создавать новые ресурсы помощника по метрикам. Служба помощника по метрикам отменяется 1 октября 2026 года.

Внимание

Корпорация Майкрософт рекомендует использовать самый безопасный поток проверки подлинности. Некоторые потоки проверки подлинности, описанные в этой статье, требуют очень высокого уровня доверия к приложению и несут риски, которые не присутствуют в других более безопасных потоках. Этот поток следует использовать только в том случае, если другие более безопасные потоки, такие как управляемые удостоверения, не являются жизнеспособными.

Используйте эту статью для поиска параметров и требований для подключения различных типов источников данных к Помощнику по метрикам ИИ Azure. Дополнительные сведения об использовании данных с Помощником по метрикам см. в статье Подключение данных.

Поддерживаемые типы аутентификации

Типы аутентификации Description
Базовая Вам необходимо предоставлять основные параметры для доступа к источникам данных. Например, вы можете использовать строку подключения или пароль. Администраторы канала данных могут просматривать эти учетные данные.
Управляемое удостоверение Azure Управляемые удостоверения для ресурсов Azure — это функция идентификатора Microsoft Entra. Он предоставляет службы Azure с автоматически управляемым удостоверением в идентификаторе Microsoft Entra. Удостоверение можно использовать для проверки подлинности в любой службе, поддерживающей проверку подлинности Microsoft Entra.
Строка подключения Azure SQL Сохраните строку подключения Azure SQL как сущность учетных данных в Помощнике по метрикам и используйте ее напрямую каждый раз при импорте данных метрик. Только администраторы сущности учетных данных могут просматривать эти учетные данные, но авторизованные зрители могут создавать каналы данных без сведений об этих учетных данных.
Общий ключ Azure Data Lake Storage 2-го поколения Сохраните ключ учетной записи озера данных как сущность учетных данных в Помощнике по метрикам и используйте его напрямую каждый раз при импорте данных метрик. Только администраторы сущности учетных данных могут просматривать эти учетные данные, но авторизованные зрители могут создавать каналы данных без сведений об этих учетных данных.
Субъект-служба Сохраните субъект-службу как сущность учетных данных в Помощнике по метрикам и используйте его напрямую каждый раз при импорте данных метрик. Только администраторы сущности учетных данных могут просматривать эти учетные данные, но авторизованные зрители могут создавать каналы данных без сведений об этих учетных данных.
Субъект-служба из хранилища ключей Сохраните субъект-службу в хранилище ключей как сущность учетных данных в Помощнике по метрикам и используйте его каждый раз при импорте данных метрик. Только администраторы сущности учетных данных могут просматривать эти учетные данные, но зрители могут создавать каналы данных без сведений об этих учетных данных.

Источники данных и соответствующие типы проверки подлинности

Источники данных Типы аутентификации
Application Insights Базовая
Хранилище BLOB-объектов Azure (JSON) Базовая
Управляемое удостоверение
Azure Cosmos DB (SQL) Базовая
Azure Data Explorer (Kusto) Базовая
Управляемое удостоверение
Субъект-служба
Субъект-служба из хранилища ключей
Azure Data Lake Storage 2-го поколения Базовая
Общий ключ Data Lake Storage 2-го поколения
Субъект-служба
Субъект-служба из хранилища ключей
Центры событий Azure Базовая
Журналы Azure Monitor Базовая
Субъект-служба
Субъект-служба из хранилища ключей
База данных SQL Azure / SQL Server Базовая
Управляемое удостоверение
Субъект-служба
Субъект-служба из хранилища ключей
Строка подключения Azure SQL
Хранилище таблиц Azure Базовая
InfluxDB (InfluxQL) Базовая
MongoDB Базовая
MySQL Базовая
PostgreSQL Базовая

В следующих разделах описываются параметры, необходимые для всех типов проверки подлинности в сценариях с различными источниками данных.

Application Insights

  • Идентификатор приложения можно использовать для обозначения этого приложения при использовании API Application Insights. Чтобы получить идентификатор приложения, выполните следующие действия.

    1. В ресурсе Application Insights щелкните Доступ через API.

      Снимок экрана: получение идентификатора приложения из ресурса Application Insights.

    2. Скопируйте созданный идентификатор приложения в поле Идентификатор приложения в Помощнике по метрикам.

  • Ключ API. Приложения используют ключи API за пределами браузера для доступа к этому ресурсу. Чтобы получить ключ API, выполните следующие действия:

    1. В ресурсе Application Insights щелкните Доступ через API.

    2. Выберите Создание ключа API.

    3. Введите краткое описание, установите флажок Читать телеметрию и нажмите кнопку Создать ключ.

      Снимок экрана: получение ключа API на портале Azure.

      Внимание

      Скопируйте и сохраните этот ключ API. Он больше не будет показан. Если ключ будет утерян, понадобится создать новый.

    4. Скопируйте ключ API в поле Ключ API в Помощнике по метрикам.

  • Запрос. Журналы Application Insights построены на базе Azure Data Explorer, поэтому для работы с журналом Azure Monitor используется такой же язык запросов Kusto. В качестве основного источника информации о создании запросов к Application Insights используйте документацию по языку запросов Kusto.

    Пример запроса:

    [TableName] | where [TimestampColumn] >= datetime(@IntervalStart) and [TimestampColumn] < datetime(@IntervalEnd);

    Более конкретные примеры см. в учебнике по написанию запросов.

Хранилище BLOB-объектов Azure (JSON)

  • Строка подключения. Для хранилища BLOB-объектов Azure (JSON) поддерживается два типа проверки подлинности:

    • Базовый. Дополнительные сведения о получении строки этого типа см. в разделе Настройка строк подключения службы хранилища Azure. Также строку подключения можно найти на портале Azure для ресурса хранилища BLOB-объектов Azure в разделе Параметры>Ключи доступа.

    • Управляемое удостоверение. Управляемые удостоверения для ресурсов Azure используются для авторизации доступа к данным BLOB-объектов и очередей. Эта функция использует учетные данные Microsoft Entra из приложений, работающих на виртуальных машинах Azure, приложениях-функциях, масштабируемых наборах виртуальных машин и других службах.

      Вы можете создать управляемое удостоверение для ресурса хранилища BLOB-объектов Azure на портале Azure. В разделе Управление доступом (IAM) выберите Назначение ролей и затем щелкните Добавить. Предлагается следующий тип роли: Модуль чтения данных BLOB-объектов хранилища. Дополнительные сведения см. в разделе Использование управляемого удостоверения для доступа к службе хранилища Azure.

      Снимок экрана: управляемое удостоверение для BLOB-объекта.

  • Контейнер. Помощник по метрикам ожидает, что данные временных рядов хранятся в виде файлов BLOB-объектов (один большой двоичный объект на отметку времени) в одном контейнере. Это поле имени контейнера.

  • Шаблон BLOB-объекта. Помощник по метрикам использует путь для поиска JSON-файла в хранилище BLOB-объектов. Пример шаблона файла BLOB-объекта, который используется для поиска JSON-файла в хранилище BLOB-объектов: %Y/%m/FileName_%Y-%m-%d-%h-%M.json. Атрибут %Y/%m определяет путь. Если в пути содержится атрибут %d, его можно добавить после %m. Если имя JSON-файла задано по дате, также можно использовать %Y-%m-%d-%h-%M.json.

    Поддерживаются следующие параметры:

    • %Y — это год в формате yyyy.
    • %m — это месяц в формате MM.
    • %d — это день в формате dd.
    • %h — это час в формате HH.
    • %M — это минута в формате mm.

    Например, в следующем наборе данных шаблон BLOB-объекта должен иметь вид %Y/%m/%d/00/JsonFormatV2.json.

    Снимок экрана: шаблон BLOB-объекта.

  • Версия формата JSON: определяет схему данных в файлах JSON. Помощник по метрикам поддерживает следующие версии. Вы можете указать одну из них в поле:

    • версия 1

      Принимаются только имена и значения метрик. Например:

      {"count":11, "revenue":1.23}

    • версия 2

      Также принимаются измерения метрик и метка времени. Например:

      [
  {"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}
]

    Для каждого JSON-файла допускается только одна метка времени.

Azure Cosmos DB (SQL)

  • Строка подключения: строка подключения для доступа к экземпляру Azure Cosmos DB. Ее можно найти в ресурсе Azure Cosmos DB на портале Azure в разделе Ключи. Дополнительные сведения см. в разделе Безопасный доступ к данным в Azure Cosmos DB.

  • База данных. База данных для запроса. Чтобы найти базу данных, на портале Azure, перейдите в раздел Контейнеры и выберите Обзор.

  • Идентификатор коллекции: идентификатор коллекции для запроса. Чтобы найти идентификатор коллекции, на портале Azure, перейдите в раздел Контейнеры и выберите Обзор.

  • SQL-запрос. SQL-запрос, позволяющий получать и формулировать данные в многомерные данные временных рядов. В запросе можно использовать переменные @IntervalStart и @IntervalEnd. Они должны иметь следующий формат: yyyy-MM-ddTHH:mm:ssZ.

    Пример запроса:

    SELECT [TimestampColumn], [DimensionColumn], [MetricColumn] FROM [TableName] WHERE [TimestampColumn] >= @IntervalStart and [TimestampColumn] < @IntervalEnd

    Дополнительные сведения см. в учебнике по написанию запросов.

Azure Data Explorer (Kusto)

  • Строка подключения. Azure Data Explorer (Kusto) поддерживает четыре типа проверки подлинности: базовый, субъект-служба, субъект-служба из хранилища ключей и управляемое удостоверение. Источник данных в строке подключения должен указываться в формате URI (начинаться с "https"). URI можно найти на портале Azure.

    • Базовый: помощник по метрикам поддерживает доступ к Azure Data Explorer (Kusto) с помощью проверки подлинности приложения Microsoft Entra. Необходимо создать и зарегистрировать приложение Microsoft Entra, а затем авторизовать его для доступа к базе данных Azure Data Explorer. Дополнительные сведения см. в статье "Создание регистрации приложений Microsoft Entra" в Azure Data Explorer. Пример строки подключения:

      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>

    • Субъект-служба — это конкретный экземпляр, созданный из объекта приложения. Субъект-служба наследует определенные свойства от этого объекта приложения. Объект субъекта-службы определяет, какие действия приложение фактически может выполнять в определенном клиенте, кто имеет доступ к приложению и к каким ресурсам приложение может получить доступ. Использование субъекта-службы в Помощнике по метрикам:

      1. Создайте регистрацию приложения Microsoft Entra. Дополнительные сведения см. в статье "Создание регистрации приложений Microsoft Entra" в Azure Data Explorer.

      2. Настройте разрешения базы данных Azure Data Explorer. Дополнительные сведения см. в разделе Управление разрешениями базы данных Azure Data Explorer.

      3. Создайте сущность учетных данных в Помощнике по метрикам. Дополнительные сведения о создании сущности учетных данных в Помощнике по метрикам см. здесь. Созданную сущность можно будет выбрать при добавлении канала данных для типа проверки подлинности субъекта-службы.

      Пример строки подключения:

      Data Source=<URI Server>;Initial Catalog=<Database>

    • Субъект-служба из хранилища ключей. Azure Key Vault позволяет безопасно хранить значения криптографических ключей и секретов, которые используют облачные приложения и службы. С помощью хранилища ключей можно зашифровать эти значения ключей и секретов. Сначала необходимо создать субъект-службу, а затем сохранить его в хранилище ключей. Дополнительные сведения см. в разделе Создание сущности учетных данных для субъекта-службы из хранилища ключей, где описывается подробная процедура по установке субъекта-службы из хранилища ключей. Пример строки подключения:

      Data Source=<URI Server>;Initial Catalog=<Database>

    • Управляемое удостоверение. Управляемые удостоверения для ресурсов Azure используются для авторизации доступа к данным BLOB-объектов и очередей. Управляемое удостоверение использует учетные данные Microsoft Entra из приложений, работающих на виртуальных машинах Azure, приложениях-функциях, масштабируемых наборах виртуальных машин и других службах. С помощью управляемого удостоверения для ресурсов Azure и проверки подлинности Microsoft Entra можно избежать хранения учетных данных с приложениями, работающими в облаке. Дополнительные сведения см. в разделе Авторизация с помощью управляемого удостоверения.

      Вы можете создать управляемое удостоверение для Azure Data Explorer (Kusto) на портале Azure. Выберите "Добавить разрешения>". Предлагается следующий тип роли: администратор/зритель.

      Снимок экрана: управляемое удостоверение для Kusto.

      Пример строки подключения:

      Data Source=<URI Server>;Initial Catalog=<Database>

  • Запрос. См. раздел Язык запросов Kusto, чтобы получить и сформулировать данные в многомерные временные ряды данных. В запросе можно использовать переменные @IntervalStart и @IntervalEnd. Они должны иметь следующий формат: yyyy-MM-ddTHH:mm:ssZ.

    Пример запроса:

    [TableName] | where [TimestampColumn] >= datetime(@IntervalStart) and [TimestampColumn] < datetime(@IntervalEnd);

    Дополнительные сведения см. в учебнике по написанию запросов.

Azure Data Lake Storage 2-го поколения

  • Имя учетной записи. Azure Data Lake Storage 2-го поколения поддерживает следующие типы проверки подлинности: базовый, общий ключ Data Lake Storage 2-го поколения, субъект-служба и субъект-служба из хранилища ключей.

    • Базовый. Имя учетной записи Azure Data Lake Storage 2-го поколения. Его можно найти в ресурсе учетной записи хранения Azure (Azure Data Lake Storage 2-го поколения) в разделе Ключи доступа.

    • Общий ключ Azure Data Lake Storage 2-го поколения. Сначала указывается ключ учетной записи для доступа к Azure Data Lake Storage 2-го поколения (совпадает с ключом учетном записи для базовой проверки подлинности). Его можно найти в ресурсе учетной записи хранения Azure (Azure Data Lake Storage 2-го поколения) в разделе Ключи доступа. Затем создается сущность учетной записи для типа общего ключа Azure Data Lake Storage 2-го поколения и указывается ключ учетной записи.

      Это то же имя учетной записи, что и для базовой проверки подлинности.

    • Субъект-служба. Субъект-служба представляет собой конкретный экземпляр, созданный из объекта приложения и наследующий определенные свойства от этого объекта приложения. Субъект-служба создается в каждом клиенте, где используется приложение, и ссылается на глобальный уникальный объект приложения. Объект субъекта-службы определяет, какие действия приложение фактически может выполнять в определенном клиенте, кто имеет доступ к приложению и к каким ресурсам приложение может получить доступ.

      Это то же имя учетной записи, что и для базовой проверки подлинности.

      Шаг 1. Создание и регистрация приложения Microsoft Entra, а затем авторизовать его для доступа к базе данных. Дополнительные сведения см. в разделе "Создание регистрации приложения Microsoft Entra".

      Шаг 2. Назначьте роли.

      1. На портале Azure перейдите в службу Учетные записи хранения.

      2. Выберите учетную запись Azure Data Lake Storage 2-го поколения, которая будет использоваться с этой регистрацией приложения.

      3. Выберите Управление доступом (IAM).

      4. Щелкните +Добавить, а затем выберите Добавить назначение ролей в меню.

      5. Задайте для поля Select имя приложения Microsoft Entra и задайте роль участнику данных BLOB-объектов хранилища. Затем выберите Сохранить.

      Снимок экрана: шаги по назначению ролей.

      Шаг 3. Создайте сущность учетных данных в Помощнике по метрикам. Созданную сущность можно будет выбрать при добавлении канала данных для типа проверки подлинности субъекта-службы.

    • Субъект-служба из хранилища ключей. Хранилище ключей позволяет безопасно хранить значения криптографических ключей и секретов, которые используют облачные приложения и службы. С помощью хранилища ключей можно зашифровать эти значения ключей и секретов. Сначала создайте субъект-службу, а затем сохраните его в хранилище ключей. Дополнительные сведения см. в разделе Создание сущности учетных данных для субъекта-службы из хранилища ключей. Это то же имя учетной записи, что и для базовой проверки подлинности.

  • Ключ учетной записи (требуется только для базовой проверки подлинности). Укажите ключ учетной записи для доступа к Azure Data Lake Storage 2-го поколения. Его можно найти в ресурсе учетной записи хранения Azure (Azure Data Lake Storage 2-го поколения) в разделе Ключи доступа.

  • Имя файловой системы (контейнер). Помощник по метрикам ожидает, что данные временных рядов хранятся в виде файлов BLOB-объектов (один большой двоичный объект на отметку времени) в одном контейнере. Это поле имени контейнера. Его можно найти в экземпляре учетной записи хранения Azure (Azure Data Lake Storage 2-го поколения). В разделе Data Lake Storage выберите Контейнеры, чтобы найти имя контейнера.

  • Шаблон каталога. Это шаблон каталога для файла большого двоичного объекта. Поддерживаются следующие параметры:

    • %Y — это год в формате yyyy.
    • %m — это месяц в формате MM.
    • %d — это день в формате dd.
    • %h — это час в формате HH.
    • %M — это минута в формате mm.

    Пример запроса для ежедневной метрики: %Y/%m/%d.

    Пример запроса для почасовой метрики: %Y/%m/%d/%h.

  • Шаблон файла. Помощник по метрикам использует путь для поиска JSON-файла в хранилище BLOB-объектов. Пример шаблона файла BLOB-объекта, который используется для поиска JSON-файла в хранилище BLOB-объектов: %Y/%m/FileName_%Y-%m-%d-%h-%M.json. Атрибут %Y/%m определяет путь. Если в пути содержится атрибут %d, его можно добавить после %m.

    Поддерживаются следующие параметры:

    • %Y — это год в формате yyyy.
    • %m — это месяц в формате MM.
    • %d — это день в формате dd.
    • %h — это час в формате HH.
    • %M — это минута в формате mm.

    Помощник по метрикам поддерживает схему данных в JSON-файлах, как показано в следующем примере:

    [
   {"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

  • Ограничения. При интеграции необходимо учитывать следующие ограничения.

    • Интеграция Помощника по метрикам с Центрами событий в настоящее время поддерживает не более трех активных каналов данных в одном экземпляре Помощника по метрикам общедоступной предварительной версии.

    • Помощник по метрикам всегда начинает использовать сообщения с наиболее поздним смещением, в том числе при повторной активации приостановленного канала данных.

      • Сообщения за период приостановки канала данных будут утрачены.
      • При создании канала данных время начала приема его данных устанавливается в соответствии с текущей отметкой времени в формате UTC. Это время предназначено исключительно для справки.

    • Для каждой группы потребителей можно использовать только один канал данных. Чтобы повторно использовать группу потребителей из другого удаленного канала данных, необходимо подождать не менее десяти минут после удаления.

    • После создания канала данных изменить строку подключения и группу потребителей нельзя.

    • Для сообщений Центров событий поддерживается только формат JSON, а значения JSON не могут быть вложенными объектами JSON. Элемент верхнего уровня может быть объектом JSON или массивом JSON.

      Ниже показаны допустимые сообщения:

      Один объект JSON:

      {
"metric_1": 234, 
"metric_2": 344, 
"dimension_1": "name_1", 
"dimension_2": "name_2"
}

      Массив JSON:

      [
    {
        "timestamp": "2020-12-12T12:00:00", "temperature": 12.4,
        "location": "outdoor"
    },
    {
        "timestamp": "2020-12-12T12:00:00", "temperature": 24.8,
        "location": "indoor"
    }
]

  • Строка подключения. Перейдите в экземпляр Центров событий. Затем добавьте новую политику или выберите существующую политику общего доступа. Скопируйте строку подключения во всплывающей панели. Снимок экрана: Центры событий.

    Снимок экрана: политики общего доступа.

    Вот пример строки подключения:

    Endpoint=<Server>;SharedAccessKeyName=<SharedAccessKeyName>;SharedAccessKey=<SharedAccess Key>;EntityPath=<EntityPath>

  • Группа потребителей. Группа потребителей — это представление всего центра событий (состояние, позиция или смещение). Найти ее можно в меню Группы потребителей экземпляра Центров событий Azure. Группа потребителей может обслуживать только один канал данных. Для каждого канала данных необходимо создавать новую группу потребителей.

  • Отметка времени (необязательно). Помощник по метрикам использует отметку времени Центров событий в качестве отметки времени для события, если источник данных пользователя не содержит поле отметки времени. Поле отметки времени является необязательным. Если не выбран столбец отметки времени, служба использует в качестве отметки время, проведенное в очереди.

    Поле отметки времени должно иметь один из двух следующих форматов:

    • YYYY-MM-DDTHH:MM:SSZ
    • Количество секунд или миллисекунд из эпохи 1970-01-01T00:00:00Z.

    Отметка времени остается привязанной к степени детализации. Например, если отметка времени имеет значение 2019-01-01T00:03:00Z, степень детализации составляет 5 минут, а Помощник по метрикам привязывает ее к 2019-01-01T00:00:00Z. Если отметка времени события имеет значение 2019-01-01T00:10:00Z, Помощник по времени использует ее напрямую без привязки.

Журналы Azure Monitor

Журналы Azure Monitor поддерживают следующие типы проверки подлинности: базовый, субъект-служба и субъект-служба из хранилища ключей.

  • Базовый. Вам необходимо заполнить поля Идентификатор арендатора, Идентификатор клиента, Секрет клиента и Идентификатор рабочей области. Сведения о получении значения полей Идентификатор арендатора, Идентификатор клиента и Секрет клиента см. в разделе Регистрация приложения или веб-API. Идентификатор рабочей области можно найти на портале Azure.

    Снимок экрана: получение идентификатора рабочей области на портале Azure.

  • Субъект-служба. Субъект-служба представляет собой конкретный экземпляр, созданный из объекта приложения и наследующий определенные свойства от этого объекта приложения. Субъект-служба создается в каждом клиенте, где используется приложение, и ссылается на глобальный уникальный объект приложения. Объект субъекта-службы определяет, какие действия приложение фактически может выполнять в определенном клиенте, кто имеет доступ к приложению и к каким ресурсам приложение может получить доступ.

    Шаг 1. Создание и регистрация приложения Microsoft Entra, а затем авторизовать его для доступа к базе данных. Дополнительные сведения см. в разделе "Создание регистрации приложения Microsoft Entra".

    Шаг 2. Назначьте роли.

    1. На портале Azure перейдите в службу Учетные записи хранения.

    2. Выберите Управление доступом (IAM).

    3. Щелкните +Добавить, а затем выберите Добавить назначение ролей в меню.

    4. Задайте для поля Select имя приложения Microsoft Entra и задайте роль участнику данных BLOB-объектов хранилища. Затем выберите Сохранить.

      Снимок экрана: назначение ролей.

    Шаг 3. Создайте сущность учетных данных в Помощнике по метрикам. Созданную сущность можно будет выбрать при добавлении канала данных для типа проверки подлинности субъекта-службы.

  • Субъект-служба из хранилища ключей. Хранилище ключей позволяет безопасно хранить значения криптографических ключей и секретов, которые используют облачные приложения и службы. С помощью хранилища ключей можно зашифровать эти значения ключей и секретов. Сначала создайте субъект-службу, а затем сохраните его в хранилище ключей. Дополнительные сведения см. в разделе Создание сущности учетных данных для субъекта-службы из хранилища ключей.

  • Запрос. Задайте запрос. Дополнительные сведения см. в разделе Запросы журналов в Azure Monitor.

    Пример запроса:

    [TableName]
| where [TimestampColumn] >= datetime(@IntervalStart) and [TimestampColumn] < datetime(@IntervalEnd)
| summarize [count_per_dimension]=count() by [Dimension]

    Дополнительные сведения см. в учебнике по написанию запросов.

База данных SQL Azure | SQL Server

  • Строка подключения. База данных SQL Azure SQL Server поддерживают следующие типы проверки подлинности: управляемое удостоверение, строка подключения SQL Azure, субъект-служба и субъект-служба из хранилища ключей.

    • Базовый. Помощник по метрикам принимает строку подключения в стиле ADO.NET для источника данных SQL Server. Пример строки подключения:

      Data Source=<Server>;Initial Catalog=<db-name>;User ID=<user-name>;Password=<password>

    • Управляемое удостоверение. Управляемые удостоверения для ресурсов Azure используются для авторизации доступа к данным BLOB-объектов и очередей. Для этого используются учетные данные Microsoft Entra из приложений, работающих на виртуальных машинах Azure, приложения-функции, масштабируемые наборы виртуальных машин и другие службы. С помощью управляемого удостоверения для ресурсов Azure и проверки подлинности Microsoft Entra можно избежать хранения учетных данных с приложениями, работающими в облаке. Чтобы использовать управляемое удостоверение, выполните следующие действия:

    1. Включить управляемое удостоверение, назначаемое системой, можно одним щелчком мыши. На портале Azure для рабочей области Помощника по метрикам выберите Параметры>Удостоверение>Назначаемое системой. Задайте статус Вкл.

      Снимок экрана: установка статуса

    2. Включите проверку подлинности Microsoft Entra. В портал Azure для источника данных перейдите в раздел "Параметры>администратора Active Directory". Выберите "Задать администратора" и выберите учетную запись пользователя Microsoft Entra, чтобы сделать администратора сервера. Затем щелкните Выбрать.

      Снимок экрана: установка администратора.

    3. Включите управляемое удостоверение в Помощнике по метрикам. Запрос можно изменить в средстве управления базой данных или на портале Azure.

      Средство управления. В средстве управления базой данных в поле проверки подлинности выберите Active Directory — универсальная с поддержкой MFA. В поле "Имя пользователя" введите имя учетной записи Microsoft Entra, заданной администратором сервера на шаге 2. Например, это может быть test@contoso.com.

      Снимок экрана: настройка сведений о подключении.

      Портал Azure. Откройте редактор запросов своей базы данных SQL и выполните вход с использованием учетной записи администратора. Снимок экрана: изменение запроса на портале Azure.

      Затем выполните следующие команды в окне запроса (обратите внимание, что это те же команды, что и при использовании средства управления):

      CREATE USER [MI Name] FROM EXTERNAL PROVIDER
ALTER ROLE db_datareader ADD MEMBER [MI Name]

      Примечание.

      MI Name — это имя управляемого удостоверения в Помощнике по метрикам (для субъекта службы его необходимо заменить именем субъекта-службы). Дополнительные сведения см.в разделе Авторизация с помощью управляемого удостоверения.

      Вот пример строки подключения:

      Data Source=<Server>;Initial Catalog=<Database>

    • Строка подключения SQL Azure:

      Вот пример строки подключения:

      Data Source=<Server>;Initial Catalog=<Database>;User ID=<user-name>;Password=<password>

    • Субъект-служба. Субъект-служба представляет собой конкретный экземпляр, созданный из объекта приложения и наследующий определенные свойства от этого объекта приложения. Субъект-служба создается в каждом клиенте, где используется приложение, и ссылается на глобальный уникальный объект приложения. Объект субъекта-службы определяет, какие действия приложение фактически может выполнять в определенном клиенте, кто имеет доступ к приложению и к каким ресурсам приложение может получить доступ.

      Шаг 1. Создание и регистрация приложения Microsoft Entra, а затем авторизовать его для доступа к базе данных. Дополнительные сведения см. в разделе "Создание регистрации приложения Microsoft Entra".

      Шаг 2. Выполните действия, описанные ранее в разделе, посвященном использованию управляемого удостоверения в SQL Server.

      Шаг 3. Создайте сущность учетных данных в Помощнике по метрикам. Созданную сущность можно будет выбрать при добавлении канала данных для типа проверки подлинности субъекта-службы.

      Вот пример строки подключения:

      Data Source=<Server>;Initial Catalog=<Database>

    • Субъект-служба из хранилища ключей. Хранилище ключей позволяет безопасно хранить значения криптографических ключей и секретов, которые используют облачные приложения и службы. С помощью хранилища ключей можно зашифровать эти значения ключей и секретов. Сначала создайте субъект-службу, а затем сохраните его в хранилище ключей. Дополнительные сведения см. в разделе Создание сущности учетных данных для субъекта-службы из хранилища ключей. Строку подключения также можно найти в ресурсе SQL Server Azure в разделе Параметры>Строки подключения.

      Пример строки подключения:

      Data Source=<Server>;Initial Catalog=<Database>

  • Запрос. Используйте SQL-запрос, позволяющий получать и формулировать данные в многомерные данные временных рядов. Чтобы получить ожидаемое значение метрик в интервале, в запросе можно использовать @IntervalStart и @IntervalEnd. Они должны иметь следующий формат: yyyy-MM-ddTHH:mm:ssZ.

    Пример запроса:

    SELECT [TimestampColumn], [DimensionColumn], [MetricColumn] FROM [TableName] WHERE [TimestampColumn] >= @IntervalStart and [TimestampColumn] < @IntervalEnd

Хранилище таблиц Azure

  • Строка подключения. Создайте подписанный URL-адрес (SAS) и укажите его здесь. Самый простой способ создать подписанный URL-адрес — на портале Azure. В разделе Параметры перейдите к учетной записи хранения, к которой требуется получить доступ. Выберите Подписанный URL-адрес. Установите флажки Таблица и Объект, а затем нажмите Создать SAS и строку подключения. В рабочей области Помощника по метрикам скопируйте подписанный URL-адрес службы таблиц и вставьте его в текстовое поле.

    Снимок экрана: создание подписанного URL-адреса в хранилище таблиц Azure.

  • Имя таблицы. Укажите таблицу для запроса. Ее можно найти в экземпляре учетной записи хранения Azure. Выберите Таблицы в разделе Служба таблиц.

  • Запрос. Чтобы получить ожидаемое значение метрик в интервале, в запросе можно использовать @IntervalStart и @IntervalEnd. Они должны иметь следующий формат: yyyy-MM-ddTHH:mm:ssZ.

    Пример запроса:

    PartitionKey ge '@IntervalStart' and PartitionKey lt '@IntervalEnd'

    Дополнительные сведения см. в учебнике по написанию запросов.

InfluxDB (InfluxQL)

  • Строка подключения. Строка подключения для доступа к InfluxDB.

  • База данных. База данных для запроса.

  • Запрос. Запрос, позволяющий получать и формулировать данные в многомерные данные временных рядов для приема.

    Пример запроса:

    SELECT [TimestampColumn], [DimensionColumn], [MetricColumn] FROM [TableName] WHERE [TimestampColumn] >= @IntervalStart and [TimestampColumn] < @IntervalEnd

Дополнительные сведения см. в учебнике по написанию запросов.

  • Имя пользователя. Необязательный параметр для проверки подлинности.
  • Пароль. Необязательный параметр для проверки подлинности.

MongoDB

  • Строка подключения. Строка подключения для доступа к MongoDB.

  • База данных. База данных для запроса.

  • Запрос. Команда, позволяющая получать и формулировать данные в многомерные данные временных рядов для приема. Для проверки команды используйте db.runCommand().

    Пример запроса:

    {"find": "[TableName]","filter": { [Timestamp]: { $gte: ISODate(@IntervalStart) , $lt: ISODate(@IntervalEnd) }},"singleBatch": true}

MySQL

  • Строка подключения. Строка подключения для доступа к базе данных MySQL.

  • Запрос. Запрос, позволяющий получать и формулировать данные в многомерные данные временных рядов для приема.

    Пример запроса:

    SELECT [TimestampColumn], [DimensionColumn], [MetricColumn] FROM [TableName] WHERE [TimestampColumn] >= @IntervalStart and [TimestampColumn]< @IntervalEnd

    Дополнительные сведения см. в учебнике по написанию запросов.

PostgreSQL

  • Строка подключения. Строка подключения для доступа к базе данных PostgreSQL.

  • Запрос. Запрос, позволяющий получать и формулировать данные в многомерные данные временных рядов для приема.

    Пример запроса:

    SELECT [TimestampColumn], [DimensionColumn], [MetricColumn] FROM [TableName] WHERE [TimestampColumn] >= @IntervalStart and [TimestampColumn] < @IntervalEnd

    Дополнительные сведения см. в учебнике по написанию запросов.

Следующие шаги