Аутентификация с использованием ключа API — Azure Cognitive Search

• 
  Статья
• 
  11/08/2022
• Чтение занимает 4 мин
• 
  

Когнитивный поиск предлагает проверку подлинности на основе ключей в качестве основной методологии проверки подлинности. Для входящих запросов к конечной точке службы поиска, такой как запросы, создающие или запрашивающие индекс, ключи API являются единственным общедоступным вариантом проверки подлинности. В ряде сценариев исходящих запросов, в частности тех, которые используют индексаторы, можно использовать Azure Active Directory удостоверения и роли.

Примечание

Управление доступом на основе ролей Azure (RBAC) для входящих запросов к конечной точке поиска теперь находится в предварительной версии. Эту предварительную версию можно использовать для дополнения или замены ключей API в запросах индекса поиска.

Использование ключей API в поиске

Ключи API создаются в момент создания службы. Передача допустимого ключа API в запрос считается подтверждением запроса от авторизованного клиента. Существует два типа ключей. Ключи администратора предоставляют разрешения на запись в службу, а также дают права на запрос системной информации. Ключи запроса содержат разрешения на чтение и могут использоваться приложениями для запроса определенного индекса.

При подключении к поисковой службе все запросы должны содержать доступный только для чтения ключ API, созданный специально для вашей службы.

• В решениях REST ключ API обычно указывается в заголовке запроса.

• В решениях .NET ключ часто указывается как параметр конфигурации, а затем передается как AzureKeyCredential.

Можно просматривать ключи API и управлять ими на портале Azure или с помощью PowerShell, Azure CLI или REST API.

Что представляет собой ключ API?

Ключ API — это уникальная строка, состоящая из случайно сгенерированных чисел и букв, которая передается при каждом запросе в службу поиска. Служба примет запрос, если и сам запрос, и ключ действительны.

Для доступа к службе поиска используются два типа ключей: ключи администратора (для чтения и записи) и ключи запроса (только для чтения).

Визуально нет никакой разницы между ключом администратора и ключом запроса. Оба ключа представляют собой строки из 32 случайно сгенерированных буквенно-цифровых символов. Если вы не знаете, какой тип ключа указан в приложении, вы можете проверить значения ключа на портале.

Примечание

В целях безопасности в URI запроса не рекомендуется передавать конфиденциальные данные, например api-key. В связи с этим Когнитивный поиск Azure принимает ключи запросов только в виде параметров api-key в строках запросов, и использовать такую схему рекомендуется только в том случае, если содержимое индекса должно быть общедоступным. Как правило, мы рекомендуем передавать api-key в заголовке запроса.

Поиск существующих ключей

Ключи доступа можно получить на портале или с помощью PowerShell, Azure CLI или REST API.

1. Войдите на портал Azure.

2. Выведите список служб поиска для вашей подписки.

3. Выберите службу и на странице обзора выберите Параметры>Ключи, чтобы просмотреть ключи администратора и ключи запросов.

Создание ключей запросов

Ключи запросов используются для доступа к документам только для чтения в индексе для операций, предназначенных для коллекции документов. Запросы поиска, фильтрации и предложений — это все операции, для которых используется ключ запроса. Для выполнения любой операции только для чтения, которая возвращает системные данные или определения объектов, такие как определение индекса или состояние индексатора, требуется ключ администратора.

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

1. Войдите на портал Azure.

2. Выведите список служб поиска для вашей подписки.

3. Выберите службу и на странице обзора выберите Параметры>Ключи.

4. Выберите Управление ключами запросов.

5. Используйте ключ запроса, уже созданный для вашей службы, или создайте до 50 новых ключей запросов. Ключ запроса по умолчанию не имеет имени, но для оптимизации управления можно назвать дополнительные ключи запросов.

Примечание

Пример кода, показывающий использование ключа запроса, можно найти в DotNetHowTo.

Повторное создание ключей администратора

Для каждой службы создается два административных ключа, поэтому вы можете менять первичный ключ, используя вторичный ключ для обеспечения непрерывности бизнес-процессов.

1. На странице Параметры>Ключи скопируйте вторичный ключ.
2. Во всех приложениях обновите параметры, добавив вторичный ключ в качестве ключа API.
3. Заново создайте первичный ключ.
4. Обновите все приложения, указав новый первичный ключ.

Если непреднамеренно повторно создать оба ключа одновременно, все клиентские запросы, использующие эти ключи, завершатся ошибкой HTTP 403 Forbidden. Однако содержимое не удаляется, и блокировка устанавливается не на постоянной основе.

Вы по-прежнему можете получить доступ к службе через портал или программным способом. Функциями управления можно пользоваться через идентификатор подписки, а не ключ API службы, и, таким образом, по-прежнему можно выполнять необходимые действия, даже если ваши ключи API отсутствуют.

После создания новых ключей через портал или уровень управления доступ к вашему содержимому (индексам, индексаторам, источникам данных, картам синонимов) восстанавливается после того, как вы получите новые ключи и предоставите эти ключи по запросам.

Обеспечение безопасности ключей API

Назначения ролей определяют, кто может считывать ключи и управлять ими. Просмотр и повторное создание ключей доступны для следующих ролей: владелец, участник, участник службы поиска. Роль читателя не имеет доступа к ключам API.

Администраторы подписки могут просматривать и повторно создавать все ключи API. В качестве меры предосторожности проверьте назначения ролей, чтобы понять, кто имеет доступ к ключам администратора.

1. Перейдите к странице своей службы поиска на портале Azure.
2. В области навигации слева выберите Управление доступом (IAM) , а затем вкладку Назначение ролей.
3. Настройте для параметра Область значение Этот ресурс, чтобы просмотреть назначенные роли для своей службы.

См. также

• Безопасность Когнитивного поиска Azure
• Управление доступом на основе ролей Azure в Когнитивном поиске Azure
• Управление с помощью PowerShell

Отправка HTTP-запросов к модулю Deployments — документация AI Cloud ML Space. Руководство пользователя

Отправка HTTP-запросов к модулю Deployments — документация AI Cloud ML Space. Руководство пользователя

После разворачивания образа можно отправлять запросы на хост.

Можно отправлять два типа запросов:

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

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

Важно

Если требуется получить ответ для одиночного запроса, который обрабатывается меньше минуты, используйте синхронные запросы.
В остальных случаях используйте асинхронные запросы.

REST API сервиса использует протокол HTTP для отправки данных и ответы в формате JSON.
HTTP-запросы можно отправить из консоли с помощью инструмента командной строки curl.
Для проверки корректности запросов с клиента на сервис и получения ответа от бэкенда рекомендуется использовать набор инструментов Postman.

Стандартный HTTP-запрос состоит из следующих частей:

• Конечная точка.
  URL, который клиент использует для связи с сервисом.

• Метод HTTP.
  Он сообщает сервису, какое действие хочет выполнить клиент.
  В примере ниже метод POST используется для создания ресурса на сервисе.
  Если ресурс существует, он переопределяется.

• Заголовок (header).
  Используется для передачи дополнительной информации между сервисом и клиентом.

• Тело.
  Данные, которые отправляются на сервис.

Отправка синхронного запроса через Postman

Рассмотрим как отправлять HTTP-запросы к модели.
Используем для этой цели Postman.

1. Скачайте и установите Postman.
   Если приложение уже установлено на вашем компьютере, переходите к шагу 2.

2. В интерфейсе Postman откройте вкладку Import.
   В открывшемся диалоговом окне выберите опцию Raw text.
   В поле ниже вставьте следующий текст.

   curl --location --request POST 'https://api.aicloud.sbercloud.ru/public/v2/service_auth' \
   --header 'Content-Type: application/json' \
   --data-raw '{
   "client_id": "user-xxxxx",
   "client_secret": "xxxxx"
   }'
   

   Где client_id, client_secret — это Long API Keys, которые находятся в параметрах разработчика.
   Подробнее см. Параметры разработчика.

   В интерфейсе программы это выглядит так:

3. Нажмите кнопку Continue → Import.

4. Для отправки запроса на авторизацию нажмите кнопку Send.
   В ответ придет access token, который можно использовать для отправки запросов к модели.

   Для отправки запроса к модели на сервис необходимо указать x-api-key, access_token и x-workspace-id в соответствующих полях.
   Обратите внимание на то, что x-api-key — это клиентский ключ доступа к API.
   Он индивидуален для каждого аккаунта пользователя.
   Его можно узнать несколькими способами:

   • Выполните в терминале Jupyter Notebook команду set для вывода всех переменных окружения пользователя.
     Используйте значение переменной GWAPI_KEY.

   • Перейдите в параметры разработчика.

   • Выполните в терминале Jupyter Notebook следующий блок:

     import os
     print(os.environ['GWAPI_KEY'])
     

   x-workspace-id — это идентификатор workspace.
   Он индивидуален для каждого workspace, созданного пользователем.
   Порядок получения идентификатора приведен в разделе Параметры разработчика.

   Нажмите кнопку Code на правой панели диалога для генерации кода запроса.

   Итоговый запрос может выглядеть следующим образом:

   curl --location --request POST 'https://api.aicloud.sbercloud.ru/public/v2/inference/v1/predict/{name}/{predict}/' \
   --header 'X-Api-Key: <your GWAPI key>' \
   --header 'authorization: <your access token>' \
   --header 'x-workspace-id: <your workspace id> \
   --header 'Content-Type: application/json' \
   --data-raw '{
   "instances": [
   {
   "text": "Hello world!"
   }
   ]
   }'
   

В ответ на запрос придет результат выполнения метода predict.

Отправка синхронного запроса с использованием ключа

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

Для ключей можно создать описание, нажав на значок плюса в столбце Описание.

В качестве примера можно выполнить Быстрый старт по работе с AutoML (базовый) до этапа отправки HTTP-запросов к модели на сервисе Deployments.

Для отправки запроса к деплою по ключу:

1. Нажмите Сгенерировать ключ.

2. Задайте описание ключа (например, тестовый ключ для проверки функции).

3. Нажмите Скопировать как cURL.

   В результате копирования получится запрос, имеющий следующий вид:

   curl 'https://mlspace.aicloud.sbercloud.ru/deployments/dgx2-inf/kfserving-1629374788/v1/models/kfserving-1629374788:predict' \
     -H 'content-type: application/json' \
     -H 'cookie: authservice_session=MTYzMjMRV2pZek4' \
     -H 'x-workspace-id: ee8cd85f-1886-4bbe-a2db-12ce69206a26' \
   --data-raw '{"key": "value"}'
   

4. Скопируйте требуемое значение ключа из карточки деплоя.
   Подробнее см. Карточка деплоя.

5. Замените значение cookie: authservice_session=MTYzMjMRV2pZek4 на x-api-key: 116708e901aa481a9c9d4200357ed31d, где 116708e901aa481a9c9d4200357ed31d — ключ, сгенерированный в шаге 1.

   В результате заголовок запроса примет следующий вид:

   curl 'https://mlspace.aicloud.sbercloud.ru/deployments/dgx2-inf/kfserving-1629374788/v1/models/kfserving-1629374788:predict' \
     -H 'content-type: application/json' \
     -H 'x-api-key: 116708e901aa481a9c9d4200357ed31d' \
     -H 'x-workspace-id: ee8cd85f-1886-4bbe-a2db-12ce69206a26' \
   --data-raw '{"key": "value"}'
   

6. Отправьте запрос.

После отправки запроса счетчик в поле Предсказания увеличится на 1.

Для удаления ключа:

1. Выберите ключ, который необходимо удалить, отметив чекбокс.

2. Нажмите на иконку в соответствующей строке списка.

3. В появившемся диалоговом окне подтвердите действие нажатием на кнопку Подтвердить.

Была ли эта статья полезной?

эффективных ключей запроса React | Блог Tkdodo

Фото Chunli JU

Последнее обновление: 23.04.2022

• #1: Практический запрос React
• #2: React Запрос. : Проверка состояния в React Query
• #5: Тестирование React Query
• #6: React Query и TypeScript
• #7: Использование WebSockets с React Query
• #8: Эффективные ключи React Query 9
• №10: React Query как менеджер состояний : Освоение мутаций в React Query
• #13: Автономный React Query
• #14: React Query и формы
• #15: Часто задаваемые вопросы по React Query
• #16: React Query и React Router
• #17: Заполнение кэша запросов

• 한국어
• Добавить перевод

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

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

Кэширование данных

Внутренне кэш запросов — это просто объект JavaScript, где ключи — это сериализованные ключи запросов, а значения — ваши данные запроса плюс метаинформация. Ключи хэшируются детерминированным образом, поэтому вы также можете использовать объекты (хотя на верхнем уровне ключи должны быть строками или массивами).

Самое главное, ключи должны быть уникальными для ваших запросов. Если React Query найдет запись для ключа в кеше, он будет использовать ее. Также имейте в виду, что вы не можете использовать один и тот же ключ для useQuery и useInfiniteQuery . В конце концов, есть только один Query Cache, и вы бы разделили данные между этими двумя. Это нехорошо, потому что бесконечные запросы имеют принципиально иную структуру, чем «обычные» запросы.

Dont-Mix-Keys

 
 1usequery (['todos'], fetchtodos) 
 
 2 
 
 3 // 🚨 Это не сработает 
 
 4UseInfinitequery (['todos'], fetchinfinitetodos) 
 
 5 
 3 
 5 
 3 
 
 6// ✅ вместо этого выберите что-нибудь другое 
 
 7useInfiniteQuery(['infiniteTodos'], fetchInfiniteTodos) 
 

Автоматическая повторная выборка

Запросы являются декларативными.

Это очень важная концепция, которую невозможно подчеркнуть в достаточной мере, а также то, что может занять некоторое время, чтобы «щелкнуть». Большинство людей думают о запросах, и особенно о повторной загрузке, императивным способом.

У меня есть запрос, он извлекает некоторые данные. Теперь нажимаю эту кнопку и хочу перепрошить, но с другими параметрами. Я видел много попыток, которые выглядят так:

императив-обновление

 
 1function Component() { 
 
 2 const { data, refetch } = useQuery(['todos'], fetchTodos) 
 
 3 
 
 4 // ❓ как передать параметры для повторной загрузки ❓ 
 
 5 return  refetch(???)} /> 
 
 6} 
 

Ответ: Нет.

refetch не для этого, а для с теми же параметрами .

Если у вас есть состояние , которое изменяет ваши данные, все, что вам нужно сделать, это поместить его в ключ запроса, потому что React Query автоматически запускает повторную выборку при изменении ключа. Поэтому, когда вы хотите применить свои фильтры, просто измените состояние клиента :

query-key-drives-the-query

 
 1function Component() { 
 
 2 const [filters, setFilters] = React.useState( ) 
 
 3 const {данные} = useQuery(['todos', фильтры], () => fetchTodos(фильтры)) 
 
 4 
 
 5 // ✅ установить локальное состояние и позволить ему «управлять» запросом передаст другой ключ запроса в React Query, что заставит его обновить.  У меня есть более подробный пример в № 1: Практический запрос React — относитесь к ключу запроса как к массиву зависимостей. 
 
 Взаимодействия вручную 
 
 Взаимодействия вручную с кэшем запросов — это то место, где структура ваших ключей запросов наиболее важна. Многие из этих методов взаимодействия, такие как invalidateQueries или setQueriesData, поддерживают фильтры запросов, которые позволяют вам нечетко сопоставлять ваши ключи запросов. 
 
 Эффективные ключи запроса React 
 
 Пожалуйста, обратите внимание, что эти пункты отражают мое личное мнение (как и все в этом блоге), так что не воспринимайте это как то, что вам абсолютно необходимо делать при работе с ключами запроса. Я обнаружил, что эти стратегии лучше всего работают, когда ваше приложение становится более сложным, и они также достаточно хорошо масштабируются. Вам определенно не нужно делать это для приложения Todo 😁. 
 
 Совместное размещение 
 
 Если вы еще не прочитали книгу Кента Доддса «Обслуживание посредством совместного размещения», прочтите ее.  Я не верю, что хранить все ваши ключи запросов по всему миру в  /src/utils/queryKeys.ts  улучшит ситуацию. Я храню свои ключи запросов рядом с соответствующими запросами, расположенными в каталоге функций, например: 
 
 
 1- src 
 
 2 - функции 
 
 3 - Профиль 
 
 4 - index.tsx 
 
 5 - query.ts 
 
 6 - Todos 
 
 7 - index.tsx 
 
 8 - query.ts 
 
 Файл  запросов  будет содержать все, что связано с React Query. Обычно я экспортирую только пользовательские хуки, поэтому фактические функции запросов, а также ключи запросов останутся локальными.
 Всегда используйте ключи массива 
 Да, ключи запроса тоже могут быть строкой, но для унификации мне нравится всегда использовать массивы. React Query в любом случае внутренне преобразует их в массив, поэтому:
 // ✅
 4useQuery(['todos'])
  Обновление : в React Query v4 все ключи должны быть массивами.
 Структура 
 Структурируйте свои ключи запросов от  наиболее общего  до  наиболее конкретного  с таким количеством уровней детализации, которое вы считаете нужным между ними. Вот как я бы структурировал список дел, который позволяет фильтровать списки, а также подробные представления:
 
 1['todos', 'list', { фильтры: 'all' }] 
 
 2['todos', 'list ', { фильтры: 'готово' }] 
 
 3['задачи', 'детали', 1] 
 
 4['задачи', 'детали', 2] 
 
 С помощью этой структуры я могу аннулировать все задачи связанные с  ['todos']  , все списки или все детали, а также настроить таргетинг на один конкретный список, если я знаю точный ключ. Обновления ответов на мутации
 с этим вы станете намного более гибким, потому что при необходимости вы можете настроить таргетинг на все списки: ) => {
 4 // ✅ обновить информацию о задаче
 5 queryClient.setQueryData([‘todos’, ‘detail’, newTodo.id], newTodo)
 6
 7 // ✅ обновить все списки, содержащие эту задачу
 8 queryClient.setQueriesData([‘todos’, ‘list’], (previous) =>
 9 previous.map((todo) = > (todo.id === newTodo.id ? newtodo : todo))
 10 )
 11 },
 12 })
 13}
 Это может не работать, если структура списков и деталей различаются много, так что в качестве альтернативы вы также можете, конечно, просто аннулировать все списки вместо этого:
 аннулировать все списки
 
 1 функция useUpdateTitle() { 
 
 2 return useMutation(updateTitle, { 
 
 3 onSuccess: (newTodo) => { 
 
 4 queryClient. setQueryData', ['tododetails'Data', ['tododetails'Data', , newTodo.id], newTodo) 
 
 5 
 
 6 // ✅ просто сделать недействительными все списки 
 
 7 queryClient.invalidateQueries(['todos', 'list']) 
 
 8 }, 
 
 9 0 }) 
 
 9 0 }) 
 10} 
 
 Если вы знаете, в каком списке вы сейчас находитесь, напр. читая фильтры из URL-адреса и, следовательно, создавая точный ключ запроса, вы также можете комбинировать эти два метода и вызывать  setQueryData  в вашем списке и сделать недействительными все остальные:
 Combine
 
 1function useUpdateTitle() { 
 
 2 // представьте пользовательский хук, который возвращает текущие фильтры, 
 
 3 // хранится в URL 
 
 4 const { фильтры } = useFilterParams() 
 
 5 
 
 6 return useMutation(updateTitle, { 
 
 7 onSuccess: (newTodo) => { 
 
 8 queryClient.setQueryData(['todos', 'detail', newTodo.id ], новыйTodo) 
 
 9 
 
 10 // ✅ мгновенно обновить список, в котором мы сейчас находимся 
 
 11 queryClient. setQueryData(['todos', 'list', {filters}], (previous) => 
 
 12 previous.map( (todo) => (todo.id === newTodo.id ? newtodo : todo)) 
 
 13 ) 
 
 14 
 
 15 // 🥳 сделать недействительными все списки, но не обновлять активный 
 
 16 queryClient.invalidateQueries({ 
 
 17 queryKey: ['todos', 'список'], 
 
 18 Refetchactive: False, 
 
 19}) 
 
 20}, 
 
 21}) 
 
 22} 
 
  Обновление : в V4,  Refetchactive  был заменен на  Refetchtype . В приведенном выше примере это будет  refetchType: 'none'  , потому что мы не хотим ничего обновлять.
 Использовать фабрики ключей запросов 
 В приведенных выше примерах вы можете видеть, что я много раз объявлял ключи запросов вручную. Это не только чревато ошибками, но и затрудняет внесение изменений в будущем, например, если вы обнаружите, что хотите добавить  еще  уровень детализации ваших ключей.
 Вот почему я рекомендую одну фабрику Query Key для каждой функции. Это всего лишь простой объект с записями и функциями, которые будут создавать ключи запроса, которые вы затем можете использовать в своих пользовательских хуках. Для приведенной выше структуры примера это будет выглядеть примерно так:
 query-key-factory
 
 1const todoKeys = { 
 
 2 all: ['todos'] as const, 
 
 3 lists: () => [ ...todoKeys.all, 'список'] как const, 
 
 4 список: (фильтры: строка) => [...todoKeys.lists(), { фильтры }] as const, 
 
 5 детали: () => [...todoKeys.all, 'detail'] as const, 
 
 6 detail: (id: number) => [...todoKeys.details(), id] as const, 
 
 7} 
 
 Это дает мне большую гибкость, так как каждый уровень основывается на над другим, но по-прежнему доступен независимо:
 examples
 
 1// 🕺 удалить все, что связано с функцией todos 
 
 2queryClient.removeQueries(todoKeys.all) 
 
 3 
 
 4 // 🚀 Допустить все списки 
 
 5queryclient.invalidatequeries (todokeys.lists ()) 
 
 6 
 
 7 // 🙌 предварительно предварительно предварительно.  , () => fetchTodo(id)) 
 
 На сегодня все. Не стесняйтесь обращаться ко мне в твиттере
 если у вас есть какие-либо вопросы, или просто оставьте комментарий ниже. ⬇️
 API запросов Insights | Документация New Relic 
 API запросов New Relic Insights — это REST API для выполнения запросов NRQL.
 Совет 
  Этот API больше не является предпочтительным способом запроса данных New Relic.  Пожалуйста, используйте для этого NerdGraph.
 Требования и рекомендации 
  Этот API больше не является предпочтительным способом запроса данных New Relic.  Для получения наилучших результатов следует использовать NerdGraph для запроса данных.
 Использование этого API может быть ограничено разрешениями пользователей, связанными с ролью.
 Чтобы добавить пользовательские данные в New Relic, вы должны использовать наши API для приема данных.
 Если ваша учетная запись размещает данные в центре обработки данных ЕС, убедитесь, что вы используете правильные конечные точки API для учетных записей региона ЕС.
 1. Зарегистрируйте ключ API 
 Чтобы использовать API запросов Insights, вам нужен ключ запроса. У вас может быть несколько ключей запроса, и любой ключ запроса можно использовать для инициации любого запроса API Insights. Если у вас есть несколько систем, запрашивающих Insights или разные места назначения данных, New Relic рекомендует использовать несколько ключей запросов для повышения безопасности данных.
 Из соображений безопасности ключи запроса нельзя изменить или прочитать с помощью API. Чтобы изменить или прочитать ключ запроса, используйте пользовательский интерфейс New Relic.
 Совет 
  Этот API больше не является предпочтительным способом запроса данных New Relic.  Пожалуйста, используйте для этого NerdGraph.
 Чтобы создать новый ключ запроса:
 Перейдите на страницу insights.newrelic.com > Управление данными > Ключи API  .
 Щелкните значок плюса рядом с заголовком  Ключи запроса .
 Введите краткое описание ключа.
 Выберите  Сохраните заметки  .
 2. Создайте запрос запроса API 
 При создании или редактировании ключа запроса вы увидите пример запроса curl, который можно использовать в качестве шаблона. Пример запроса не будет работать, если вы не будете следовать следующим правилам запросов:
 Строка запроса NRQL должна быть закодирована в URL-адресе.
 Строка запроса должна быть меньше 4000 байт.
 URL-адрес должен содержать действительный идентификатор учетной записи.
  X-Query-Key  должен содержать действительный ключ запроса.
  Content-Type  должен быть  application/json  .
 Linux 
 Вот пример curl:
 curl -H "Accept: application/json" -H "X-Query-Key:  YOUR_QUERY_KEY " "https://insights-api.newrelic.com/ v1/accounts/  YOUR_ACCOUNT_ID  /query?nrql=  YOUR_URL_ENCODED_QUERY  " 
 Microsoft Windows 
 Вы можете использовать  Powershell  для запроса событий через API:
 . com/v1/accounts/  YOUR_ACCOUNT_ID  /query?nrql=  YOUR_URL_ENCODED_QUERY  -Headers @{"X-Query-Key"="  YOUR_QUERY_KEY  "} -ContentType "application/json" -Method GET 
 3. Обработать возвращенный запрос JSON 
 API возвращает результаты в формате JSON. Существует ограничение в 2000 результатов на запрос.
 Структура данных JSON зависит от NRQL, который вы использовали в запросе: Различные комбинации  SELECT  операторов, предложений и функций возвращают соответствующий ответ. При написании кода для обработки JSON следует выполнить тестовый запуск запроса и изучить полученный JSON.
 Пример 
 API запросов Insights возвращает данные JSON. Вот пример запроса, его формат запроса и возвращенные данные:
  Исходный запрос NRQL: 
 
 SELECT count(appName) FROM PageView SINCE '2014-08-04 00:00:00+0500' 
 
  Запрос cURL-запроса (с URL-закодированным запросом NRQL)  :
 curl -H "Accept: application/json" -H "X-Query-Key:  YOUR_QUERY_KEY " "https://insights-api . newrelic.com/v1/accounts/  YOUR_ACCOUNT_ID  /query?nrql=SELECT+count%28appName%29+FROM+PageView+SINCE+%272014-08-04+00%3A00%3A00%2B0500%27" 
  Возвращенные данные JSON:
7 «
3 9 результаты»: [ 
 «количество»: 80275388
 «метаданные»: {
 «eventTypes»: [
 «PageView»
 «eventType»: «PageView»,
 «openEnded»: 3,
 «beginTime»: «2014-08-03T19:00:00Z»,
 «endTime»: «2017-01-18T23:18:41Z»,
 «beginTimeMillis=»: 1407092400000,
 «endTimeMillis»: 1484781521198,
 «rawSince»: «‘2014-08-04 00:00:00+0500′»,
 «rawUntil»: «`now`»,
 «rawCompareW» : «»,
 «CREADTIMEWINDOWS»: {
 «Browser»: {
 «BERINTIMEMILLIS»: 1483571921198,
 «EndtimeMillis»: 1484781521198,
 «.
 «содержимое»: [
 «функция»: «количество»,
 «атрибут»: «имя приложения»,
 «simple»: true
 Рекомендации по ограничению скорости 
 У нас есть ограничения на скорость запросов.
This entry was posted in Ключевые слова