Приказ Минцифры России от 01.11.2023 N 935 "Об утверждении требований к вычислительной мощности, используемой провайдером хостинга, для проведения уполномоченными государственными органами, осуществляющими оперативно-разыскную деятельность или обеспечение безопасности Российской Федерации, в случаях, установленных федеральными законами, мероприятий в целях реализации возложенных на них задач" (Зарегистрировано в Минюсте России 01.12.2023 N 76230)

МИНИСТЕРСТВО ЦИФРОВОГО РАЗВИТИЯ, СВЯЗИ
И МАССОВЫХ КОММУНИКАЦИЙ РОССИЙСКОЙ ФЕДЕРАЦИИ

ПРИКАЗ
от 1 ноября 2023 г. N 935

ОБ УТВЕРЖДЕНИИ ТРЕБОВАНИЙ
К ВЫЧИСЛИТЕЛЬНОЙ МОЩНОСТИ, ИСПОЛЬЗУЕМОЙ ПРОВАЙДЕРОМ
ХОСТИНГА, ДЛЯ ПРОВЕДЕНИЯ УПОЛНОМОЧЕННЫМИ ГОСУДАРСТВЕННЫМИ
ОРГАНАМИ, ОСУЩЕСТВЛЯЮЩИМИ ОПЕРАТИВНО-РАЗЫСКНУЮ ДЕЯТЕЛЬНОСТЬ
ИЛИ ОБЕСПЕЧЕНИЕ БЕЗОПАСНОСТИ РОССИЙСКОЙ ФЕДЕРАЦИИ,
В СЛУЧАЯХ, УСТАНОВЛЕННЫХ ФЕДЕРАЛЬНЫМИ ЗАКОНАМИ, МЕРОПРИЯТИЙ
В ЦЕЛЯХ РЕАЛИЗАЦИИ ВОЗЛОЖЕННЫХ НА НИХ ЗАДАЧ

В соответствии с частью 3 статьи 10.2-1 Федерального закона от 27 июля 2006 г. N 149-ФЗ "Об информации, информационных технологиях и о защите информации", пунктом 1 Положения о Министерстве цифрового развития, связи и массовых коммуникаций Российской Федерации, утвержденного постановлением Правительства Российской Федерации от 2 июня 2008 г. N 418, приказываю:

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

Министр
М.И.ШАДАЕВ

1. Требования к вычислительной мощности, используемой провайдером хостинга, для обеспечения выполнения установленных действий при проведении оперативно-разыскных мероприятий (далее соответственно - требования, ОРМ), разработаны в целях обеспечения устойчивого, безопасного и целостного функционирования на территории Российской Федерации информационно-телекоммуникационной сети "Интернет", а также создания условий для выполнения уполномоченными государственными органами, осуществляющими оперативно-разыскную деятельность или обеспечение безопасности Российской Федерации (далее - уполномоченные государственные органы), в случаях, установленных федеральными законами, возложенных на них задач с использованием технических средств ОРМ (далее - ТС ОРМ).

2. ТС ОРМ должны быть частью вычислительной мощности, используемой провайдером хостинга.

3. Состав и построение ТС ОРМ определяются с учетом особенностей построения информационных систем провайдеров хостинга (далее - ИС), перечнем предоставляемых информационных услуг и коммуникационных интернет-сервисов.

4. При построении ТС ОРМ провайдером хостинга должен быть использован один из следующих вариантов:

1) отдельный аппаратно-программный комплекс;

2) отдельный программный модуль в ИС;

3) комбинированный вариант, предусматривающий совместное использование элементов в соответствии с подпунктами 1 и 2 настоящего пункта.

5. Для каждого варианта построения ТС ОРМ провайдером хостинга должны реализовываться согласованные с уполномоченным государственным органом требования по информационной безопасности и защите от несанкционированного доступа к информации, связанной с проведением ОРМ, в соответствии с подпунктами 8 и 9 пункта 18 настоящих требований.

6. С использованием ТС ОРМ провайдера хостинга должны осуществляться поиск, обработка и передача на пульт управления уполномоченного государственного органа (далее - ПУ) информации, хранящейся в ИС и обрабатываемой с использованием вычислительной мощности провайдера хостинга, по запросу уполномоченного государственного органа или в автоматическом режиме.

7. С использованием ТС ОРМ провайдера хостинга должны обеспечиваться поиск согласованной с уполномоченным государственным органом, определяемым в порядке, установленном Правительством Российской Федерации в соответствии с частью 3 статьи 10.2-1 Федерального закона от 27 июля 2006 г. N 149-ФЗ "Об информации, информационных технологиях и о защите информации", информации, хранящейся в ИС и обрабатываемой с использованием ТС ОРМ провайдера хостинга согласно приложению N 1 к настоящим требованиям, а также поддерживать согласованную с уполномоченным государственным органом схему ее предоставления.

8. ТС ОРМ должно осуществлять взаимодействие по единому каналу передачи данных с ПУ.

9. Суммарная пропускная способность канала передачи данных между ТС ОРМ и ПУ должна соответствовать данным, приведенным в таблице N 1.

Таблица N 1.

10. Требования предъявляемые к ТС ОРМ в части обработки информации хранение, которой осуществляется в информационной системе провайдера хостинга приведены в приложении N 1 к настоящим требованиям.

11. Требования, предъявляемые к интерфейсу взаимодействия между ПУ и ТС ОРМ, приведены в приложении N 2 к настоящим требованиям.

12. Требования, предъявляемые к схеме представления информации, хранящейся в ИС (далее - схема данных), и выполнению запросов от ПУ приведены в приложении N 3 к настоящим требованиям.

13. Перечень типов данных являющихся стандартными для описания схемы данных (далее - базовые типы) приведен в приложении N 4 к настоящим требованиям.

14. Перечень типов данных являющихся служебными для описания схемы данных (далее - сервисные типы) приведен в приложении N 5 к настоящим требованиям.

15. Перечень входных объектов для задания параметров поиска приведен в приложении N 6 к настоящим требованиям.

16. Требования, предъявляемые к формату передачи данных на языке GraphQL по протоколу WebSocket, приведены в приложении N 7 к настоящим требованиям.

17. С использованием ТС ОРМ провайдера хостинга обеспечивается исполнение запросов о текущей конфигурации оборудования, системного и прикладного программного обеспечения (далее - ПО), а также их состояния согласно приложению N 8 к настоящим требованиям.

18. С использованием ТС ОРМ реализуются:

1) подключение к ПУ в соответствии техническими условиями, согласованными с уполномоченным государственным органом;

2) протокол взаимодействия ТС ОРМ с ПУ в соответствии с приложением N 2 к настоящим требованиям;

3) прием от ПУ поисковых запросов;

4) поиск информации, хранящейся в ИС, в соответствии с поступившими с ПУ поисковыми запросами. Для ТС ОРМ, осуществляющих поиск информации в ИС со среднесуточным объемом новых данных свыше 1 Гбайт, устанавливаются требования к поддерживаемым критериям поиска согласно пункту 21 приложения N 2 к настоящим требованиям;

5) передача от ТС ОРМ на ПУ данных в соответствии с поступившими с ПУ поисковыми запросами (в том числе постранично);

6) прием от ПУ критериев поиска и передачу на ПУ статистической, текстовой, мультимедийной, звуковой, графической и иной информации в исходном (декодированном) виде, хранящейся в ИС и отбираемой по критериям поиска, без дополнительной обработки (далее - неформатированные данные);

7) передача на ПУ схемы данных, в соответствии с поступившим с ПУ специальным запросом согласно приложению N 5 к настоящим требованиям;

8) защита от несанкционированного доступа со стороны производителей ТС ОРМ, неавторизованных пользователей, технического персонала, третьих лиц к хранящейся в ТС ОРМ информации и информации, непосредственно связанной с проведением ОРМ (информации, поступающей в ТС ОРМ с ПУ, и информации, подготовленной к передаче из ТС ОРМ в ПУ);

9) информирование ПУ о следующих попытках несанкционированного доступа к ТС ОРМ:

доступ к данным, связанным с проведением ОРМ, с использованием команд или сервисных программ;

резервное копирование данных, связанных с проведением ОРМ;

доступ к ТС ОРМ через интерфейсы, не предусмотренные для доступа к ним;

вскрытие корпуса технических средств ОРМ (для варианта исполнения ТС ОРМ в виде отдельного аппаратно-программного комплекса и для комбинированного варианта исполнения ТС ОРМ);

10) контроль работоспособности и загруженности ТС ОРМ;

11) контроль за соблюдением предоставленных прав доступа к хранящейся в ТС ОРМ информации;

12) круглосуточный удаленный доступ со стороны операторов ПУ к хранящейся в ИС информации по протоколу взаимодействия ПУ и ТС ОРМ, описанному в приложении N 2 к настоящим требованиям;

13) ведение в автоматическом режиме системных журналов, содержащих информацию о работе ТС ОРМ, а также связанных с проведением ОРМ данных:

о сеансах связи с ПУ, а также о попытках установления таких сеансов;

о поисковых запросах;

об ответах на поисковые запросы;

о текущей конфигурации ТС ОРМ, системного и прикладного ПО;

об изменениях в конфигурации ТС ОРМ, системного и прикладного ПО;

о сбоях в ТС ОРМ, системном и прикладном ПО;

об изменениях схемы данных;

об обращении и доступе обслуживающего технического персонала к ТС ОРМ;

14) доступ уполномоченного технического персонала для обслуживания ТС ОРМ в соответствии с установленными правами доступа;

15) доступ технического персонала к системным файлам и ПО, в соответствии с правами, установленными парольной системой доступа;

16) сохранность и доступность для дальнейшего использования ранее накопленных данных при модернизации ТС ОРМ;

17) автоматическое определение способа выполнения поисковых запросов (в режиме реального времени или в отложенном режиме согласно пункту 20 приложения N 2 к настоящим требованиям), поступивших с ПУ, в соответствии с заданными временными параметрами;

18) временное хранение результатов выполнения поисковых запросов в отложенном режиме с учетом заданных временных параметров (согласно пункту 21 настоящих требований).

19. Функционирование ТС ОРМ не должно оказывать влияние на работоспособность ИС провайдера хостинга.

20. ТС ОРМ не должны иметь иных интерфейсов взаимодействия кроме интерфейсов взаимодействия с ИС и ПУ.

21. Максимальное время предварительной обработки информации с момента ее поступления в ТС ОРМ до момента, когда она становится доступной для выполнения поисковых запросов с ПУ, и максимальное время выполнения поисковых запросов определено в ходе внедрения ТС ОРМ в информационную систему провайдера хостинга. ТС ОРМ провайдеров хостинга должны соблюдать согласованные с уполномоченным государственным органом временные параметры для определения способа выполнения поисковых запросов (в режиме реального времени или в отложенном режиме, пункт 20 приложения N 2 к настоящим требованиям) и максимального времени хранения результатов выполнения поисковых запросов в отложенном режиме должны.

22. Временные параметры, указанные в пункте 21 настоящих требований, могут корректироваться провайдером хостинга во время эксплуатации ТС ОРМ путем взаимодействия с уполномоченным государственным органом.

1. С использованием ТС ОРМ провайдера хостинга должна обрабатываться информация, указанная в пунктах 2 - 9 настоящих требований.

2. Сведения о пользователях и регистрационных данных, в том числе регистрационных и иных данных, изменениях и дополнениях регистрационных данных, внесенных пользователем:

сведения о пользователе, включая идентификатор пользователя в ИС провайдера хостинга;

информация о сетевом адресе, с которого осуществлена регистрация пользователя, с указанием времени регистрации;

информация, которая должна вноситься в ИС провайдера хостинга при регистрации пользователя:

дата и время регистрации пользователя;

номер договора, дата и время заключения договора на обслуживание пользователя провайдером хостинга (при наличии такой информации);

информация, внесенная пользователем (при наличии):

фамилия, имя, отчество (при наличии);

псевдоним пользователя;

дата рождения;

адрес регистрации по месту жительства (пребывания);

реквизиты документа, удостоверяющего личность;

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

дата и время последнего обновления пользователем регистрационной информации;

дата и время прекращения регистрации пользователя в ИС провайдера хостинга;

дополнительная информация о пользователе, фиксируемая ИС провайдера хостинга.

3. Сведения о добавлении (исключении) зарегистрированным пользователем связанных с ним других зарегистрированных идентификаторов:

дата и время;

наименование сервиса и идентификатор;

4. Сведения о фактах авторизации и выхода из ИС провайдера хостинга, прекращениях регистрации:

дата и время;

идентификатор пользователя ИС провайдера хостинга;

технические идентификаторы пользователя ИС провайдера хостинга, переданные в ИС провайдера хостинга в силу используемых коммуникационных протоколов:

IP-адрес и порт;

номера телефонов пользователя, являющегося абонентом (пользователем) услуг подвижной радиотелефонной связи;

адрес электронной почты;

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

иная фиксируемая техническая информация;

вид события;

5. Информация в ИС провайдера хостинга, классифицирующая:

виды информационных сервисов, предоставляемых провайдером хостинга для пользователей;

виды событий, регистрируемых ИС провайдера хостинга при взаимодействии ИС провайдера хостинга с пользователем;

типы информационных ресурсов, создаваемых пользователями в ИС провайдера хостинга;

типы пользователей, обслуживаемых ИС провайдера хостинга;

виды платежных услуг (платежных сервисов), используемых провайдером хостинга;

6. Информация, фиксируемая в ИС провайдера хостинга об оказанных пользователям услугах:

идентификатор пользователя ИС провайдера хостинга;

дата и время;

описание оказанной услуги;

техническая информация, связанная с оказанной услугой;

иная фиксируемая информация о оказанной услуге;

7. Информация о фактах взаимодействия пользователей сети "Интернет" с информационными ресурсами, созданными в ИС провайдера хостинга пользователями провайдера хостинга;

8 Информация о фактах приема, передачи и (или) обработки голосовой информации, текстовых сообщений, изображений, звуков, видео- или иных электронных сообщений пользователей ИС провайдеров хостинга (при наличии), фиксируемая информация об организации приема, передачи, доставки и (или) обработки электронных сообщений, осуществляемых с использованием технологий электронных платежных систем, в том числе информация о произведенных денежных операциях (с указанием информации о корреспонденте - идентификаторе платежной системы, валюты, суммы, оплачиваемой услуги или товаров (при наличии), об иных данных, указанных при проведении денежной операции), осуществленных транзакциях (с указанием идентификатора платежной системы, суммы прихода либо расхода, иных данных, указанных при осуществлении транзакции):

дата и время события;

идентификатор пользователя ИС провайдера хостинга;

технические идентификаторы пользователя ИС провайдера хостинга, переданные в ИС в силу используемых коммуникационных протоколов:

IP-адрес и порт;

номер телефона (MSISDN) подвижной станции пользователя;

адрес электронной почты;

наименование программы клиента;

иная фиксируемая техническая информация;

вид события;

местоположение пользователя в случае его фиксации ИС провайдера хостинга (широта и долгота, иное описание местоположения);

текст сообщения и иная служебная коммуникационная информации;

техническая информация о платеже: вид платежной услуги (платежного сервиса), идентификатор платежа в сервисе, иная фиксируемая информация о платеже.

9. ТС ОРМ провайдера хостинга должны обеспечивать хранение информации о пользователях услуг провайдера хостинга в течение трех лет, о фактах взаимодействия пользователей услуг провайдера хостинга с пользователями информационно-телекоммуникационной сети "Интернет" в течение одного года со дня окончания осуществления действий, а также предоставление указанной информации уполномоченному государственному органу посредством ТС ОРМ.

1. Интерфейсы взаимодействия ТС ОРМ с ПУ должны быть организованы по выделенным каналам связи.

2. В качестве набора протоколов передачи данных следует использовать набор протоколов TCP/IP.

3. Для организации линий (каналов) связи, соединяющих ТС ОРМ и ПУ, должен быть использован сетевой интерфейс первого уровня.

4. ТС ОРМ должны предусматривать возможность создания виртуальной сети VPN (Virtual Private Network) для туннелирования всего рабочего TCP/IP трафика между ТС ОРМ и ПУ.

5. Взаимодействие ТС ОРМ с оборудованием ПУ на транспортном уровне должно осуществляться по схеме "клиент - сервер":

1) в качестве "сервера" выступают ТС ОРМ;

2) в качестве "клиента" выступает оборудование ПУ.

6. При построении ТС ОРМ должны соблюдаться согласованные с уполномоченным государственным органом способы защиты линий (каналов) связи. ТС ОРМ должно соединяться с ПУ по протоколу TLS версии 1.2 или 1.3. При установлении соединения ТС ОРМ должны осуществлять взаимную аутентификацию с ПУ. В случае невозможности аутентифицировать одну из сторон TCP-соединение разрывается. Для аутентификации ТС ОРМ должны использовать сертификаты в формате X.509 согласованные с уполномоченным государственным органом.

7. Взаимодействие ТС ОРМ с ПУ должно осуществляться по единому каналу передачи данных, предназначенному для передачи:

1) от ПУ в ТС ОРМ поисковых запросов;

2) от ТС ОРМ на ПУ результатов выполнения поисковых запросов (в том числе постранично);

3) от ПУ в ТС ОРМ запросов на получение неформатированных данных (далее - запросы неформатированных данных);

4) от ТС ОРМ на ПУ ответов на запросы неформатированных данных;

5) от ПУ в ТС ОРМ специальных запросов согласно приложению N 5 к требованиям, утвержденным настоящим приказом, для получения схемы данных, статуса поисковых запросов в отложенном режиме согласно пункту 20 настоящего приложения и сигналов о функционировании ТС ОРМ согласно пункту 23 настоящего приложения;

6) от ТС ОРМ на ПУ текущей схемы данных, статуса поисковых запросов в отложенном режиме и сигналов о функционировании ТС ОРМ;

7) от ПУ в ТС ОРМ запросов о текущей конфигурации оборудования, системного и прикладного программного обеспечения ТС ОРМ, а также их состоянии (далее - запросы мониторинга);

8) от ТС ОРМ на ПУ ответов на запросы мониторинга.

8. Единый канал передачи данных создается для подключения к ТС ОРМ в виде ТСР-соединений. Посредством ТС ОРМ выполняется мониторинг порта подключения к ПУ на наличие ТСР-соединений.

9. Установление соединения ТС ОРМ с ПУ осуществляется по согласованному с уполномоченным государственным органом ТСР-порту с заданным временным интервалом.

10. Обмен данными в едином канале передачи данных на прикладном уровне должен осуществляться по протоколам HTTP 1.1 и WebSocket.

11. ТС ОРМ должны поддерживать четыре интерфейса (endpoints) взаимодействия с ПУ:

1) "/query" - для получения от ПУ поисковых запросов и специальных запросов (согласно приложению N 5 к настоящим требованиям) для получения схемы данных, управления поисковыми запросами в отложенном режиме, а также передачи на ПУ результатов выполнения данных запросов (в том числе постранично) в режиме реального времени согласно пункта 20 настоящего приложения.

2) "/subscription" - для получения от ПУ статуса выполнения поисковых запросов ТС ОРМ, которые выполняются в отложенном режиме (согласно пункта 20 настоящего приложения) и сигналов о функционировании ТС ОРМ согласно пункта 23 настоящего приложения.

3) "/download" - для получения от ПУ запросов неформатированных данных и передачи на ПУ результатов выполнения данных запросов.

4) "/metric" - для получения от ПУ запросов мониторинга и передачи на ПУ результатов выполнения данных запросов.

12. Обмен данными для конечных точек "/query", "/download" и "/metric" должен осуществляться по протоколу HTTP 1.1, для интерфейса "/subscription" - по протоколу WebSocket. ПУ и ТС ОРМ для интерфейса "/subscription" должны поддерживать сетевое соединение с помощью механизмов протокола WebSocket.

13. Для запросов ПУ и ответов ТС ОРМ для конечных интерфейсов "/query" и "/subscription" должна использоваться версия языка описания данных и запросов GraphQL, актуальная на день опубликования настоящих требований и (или) совместимая с ней. Для кодирования содержимого запросов и ответов должен применяться формат JSON.

14. Требования, предъявляемые к формату передачи данных на языке GraphQL по протоколу WebSocket для интерфейса "/subscription", приведены в приложении N 7 к настоящим требованиям.

15. Требования, предъявляемые к запросам мониторинга и формату их передачи по интерфейсу взаимодействия между ПУ и ТС ОРМ для интерфейса "/metric", приведены в приложении N 8 к настоящим требованиям.

16. Для запросов ПУ и ответов ТС ОРМ для интерфейса "/download" должны использоваться стандартные сообщения протокола HTTP 1.1. ТС ОРМ для данной интерфейса должны поддерживать механизм передачи данных по частям Chunked Transfer Coding и механизм частичных запросов Range Requests.

17. Если результаты выполнения поисковых запросов для конечных точек "/query" и "/subscription" содержат неформатированные данные (файлы), то ответ ТС ОРМ должен содержать вместо непосредственно неформатированных данных (файлов) соответствующие ссылки (HTTP URI в полном формате согласно RFC7230 http(s)://<IP-адрес или доменное имя ТС ОРМ >:<порт>/download/<уникальный путь к файлу>) для каждого файла для интерфейса "/download". ТС ОРМ должны формировать уникальную ссылку для каждого файла.

18. Для получения неформатированных данных, ссылки на которые содержатся в ответе ТС ОРМ на поисковый запрос, ТС ОРМ для каждого файла должен обеспечивать возможность получения на интерфейс "/download" отдельных (от поисковых запросов) запросов получения неформатированных данных (HTTP GET-запросы) от ПУ, содержащих ссылку на запрашиваемые данные.

19. Для получения текущей схемы данных согласно приложению N 3 к требованиям, утвержденным настоящим приказом, ТС ОРМ необходимо предусмотреть возможность получения запроса "getSchema" согласно приложению N 5 к требованиям, утвержденным настоящим приказом, на интерфейс "/query". В ответ ТС ОРМ должны направить схему данных, описанную на языке SDL GraphQL.

20. Поисковые запросы должны выполняться в ТС ОРМ в двух режимах: режиме реального времени и отложенном режиме (далее - отложенный поисковый запрос). Режим выполнения поисковых запросов определяется ТС ОРМ в соответствии с установленными временными параметрами согласно пункту 21 настоящих требований, а также с учетом характера (количества запрашиваемых полей и критериев поиска) запроса, количества данных, хранящихся в ИС, и производительностью ТС ОРМ. Все поисковые запросы от ПУ должны направляться на интерфейс "/query".

21. ТС ОРМ должны выполнять поисковые запросы в соответствии с критериями поиска, заданными на верхнем уровне запроса без вложенных объектов, согласно пункту 10 приложения N 3 к требованиям, утвержденным настоящим приказом, при следующих условиях:

по согласованию с уполномоченным государственным органом, если среднесуточный объем новых данных, поступающих в ИС, составляет от 1 до 10 Гбайт;

без согласования с уполномоченным государственным органом, если среднесуточный объем новых данных, поступающих в ИС, превышает 10 Гбайт.

22. В режиме реального времени ТС ОРМ должны поддерживать (не разрывать) сетевое соединение, по которому поступил запрос от ПУ, и результаты выполнения запроса должны передаваться от ТС ОРМ на ПУ по тому же сетевому соединению, не позднее установленных временных параметров согласно пункту 21 настоящих требований.

23. Отложенный поисковый запрос выполняется по следующему сценарию:

1) ПУ направляет поисковый запрос ТС ОРМ на интерфейс "/query";

2) ТС ОРМ принимают решение о выполнении запроса в отложенном режиме;

3) ТС ОРМ назначают поисковому запросу уникальный в рамках данной ТС ОРМ идентификатор;

4) ТС ОРМ возвращают ПУ идентификатор отложенного поискового запроса и информацию о том, что запрос выполняется в отложенном режиме;

5) ПУ отправляет запрос "statusOfflineRequest" (запрос Subscription языка GraphQL), содержащий полученный от ТС ОРМ идентификатор отложенного поискового запроса, на интерфейс "/subscription" по протоколу WebSocket (согласно приложению N 5 к настоящим требованиями). ТС ОРМ в непрерывном режиме (без дополнительных запросов от ПУ) уведомляют ПУ об изменениях статуса выполнения отложенного поискового запроса.

ТС ОРМ должны поддерживать следующие статусы выполнения отложенного запроса:

NOTSTARTED - запрос получен, но не запущен на выполнение;

RUNNING - запрос получен и в настоящее время выполняется;

READY - выполнение запроса завершено, результирующие данные готовы;

ABORTED - выполнение запроса прервано (на стороне сервера - ТС ОРМ);

CANCELED - запрос отменен клиентом (ПУ);

6) при получении от ТС ОРМ на ПУ уведомления о завершении выполнения отложенного поискового запроса (статус "READY"), ПУ направляет запрос "getOfflineRequest" согласно приложению N 5 к требованиям, утвержденным настоящим приказом, на интерфейс "/query" с указанием идентификатора запроса. ТС ОРМ должны осуществлять передачу на ПУ результатов выполнения отложенных запросов и запросов в режиме реального времени постранично, согласно подпункту 2 пункта 10 приложения N 3 к требованиям, утвержденным настоящим приказом;

7) в ответ на полученный запрос ТС ОРМ должны передавать на ПУ результаты выполнения отложенного поискового запроса в режиме реального времени в формате JSON. Структура результатов выполнения отложенного поискового запроса должна соответствовать структуре исходного поискового запроса, направленного ПУ на интерфейс "/query";

8) в момент выполнения отложенного запроса (от момента получения идентификатора запроса от ТС ОРМ до получения статуса выполнения запроса "READY") ПУ может прервать данную операцию, направив запрос "_cancelOfflineRequest" согласно приложению N 5 к требованиям, утвержденным настоящим приказом) на интерфейс "/query" с указанием идентификатора запроса. В ответ ТС ОРМ должны направить результат выполнения данного запроса.

ТС ОРМ должны удалять промежуточные результаты прерванного отложенного запроса.

24. ТС ОРМ должны хранить результаты выполнения отложенных запросов согласно пункту 21 настоящих требований и незамедлительно их удалять при получении запроса от ПУ.

Для удаления на ТС ОРМ результатов выполнения отложенного поискового запроса ПУ направляет запрос "_delOfflineRequest" согласно приложению N 5 к требованиям, утвержденным настоящим приказом, на интерфейс "/query" с указанием идентификатора запроса. В ответ ТС ОРМ направляют результат выполнения данного запроса.

25. ТС ОРМ должны поддерживать два вида постраничной передачи результатов выполнения поисковых запросов: со смещением и курсорную. По согласованию с уполномоченным государственным органом может быть реализован только один из видов постраничной передачи результатов.

26. ТС ОРМ должны осуществлять контроль функционирования собственных параметров и передачу на ПУ следующих сигналов:

1) "Перезапуск ПО" (RESTARTDB);

2) "Попытка несанкционированного доступа" (UNAUTHORIZEDACCESS);

3) "Критическая ошибка ПО, потеря данных, дальнейшая работа невозможна" (CRITICALERROR);

4) "Серьезная ошибка ПО, потеря данных, но дальнейшая работа возможна" (MAJORERROR);

5) "Незначительная ошибка ПО, данные не потеряны, дальнейшая работа возможна" (MINORERROR);

6) "Изменение схемы данных" (SCHEMACHANGED);

7) "Предупреждение о проблеме с контролируемыми параметрами (метриками)" (METRICALERTS). Для данного сигнала ТС ОРМ должны возвращать на ПУ дополнительную информацию о предупреждениях (согласно приложению N 5 к настоящим требованиями). ТС ОРМ должны осуществлять обработку контролируемых метрик и предупреждений о проблемах согласованные с уполномоченным государственным органом.

Для получения сигналов ПУ необходимо отправить запрос "_trap" (запрос Subscription языка GraphQL) на интерфейс "/subscription" по протоколу WebSocket согласно приложению N 5 к требованиям, утвержденным настоящим приказом. ТС ОРМ в непрерывном режиме (без дополнительных запросов от ПУ) отправляет ПУ сигналы сразу после их возникновения на ТС ОРМ. Если в момент получения запроса "_trap" на ТС ОРМ есть сигналы, которые не были отправлены ранее ПУ (по причине разрыва соединения или по иным причинам), то ТС ОРМ должны незамедлительно передать на ПУ все данные сигналы.

27. Все запросы мониторинга и неформатированных данных должны выполняться в режиме реального времени.

28. ТС ОРМ должны использовать следующие коды ошибок для языка GraphQL:

1. Данные, хранящиеся в информационной системе провайдера хостинга, должны быть описаны с помощью схемы данных на языке SDL GraphQL.

2. Схема данных должна полностью описывать данные, хранящиеся в ИС.

3. Произвольный тип данных в схеме данных (далее - тип "A") имеет связь с произвольным типом данных (далее - тип "B"), если тип "A" содержит поле типа "B" или поле, являющееся списком типа "B".

4. Произвольный тип "A" в схеме данных имеет двухстороннюю связь с произвольным типом "B", если тип "A" связан с типом "B" и тип "B" связан с типом "A".

5. Для схемы данных определяется перечень базовых типов. Базовый тип данных на языке GraphQL должен содержать информацию, которая должна быть доступна для поиска в ТС ОРМ по запросам ПУ. Перечень базовых типов отражает перечень идентифицирующих признаков объектов физического мира (в том числе, номер паспорта, номер телефона, банковские реквизиты, государственный регистрационный номер транспортного средства). Перечень базовых типов и их определения на языке GraphQL приведены в приложении N 4 к требованиям, утвержденным настоящим приказом.

6. Для схемы данных определяется перечень сервисных типов. Сервисный тип данных на языке GraphQL должен отражать информацию о схеме данных, или описывать HTTP URI для неформатированных данных, или предназначаться для получения статуса отложенных поисковых запросов или сигналов о функционировании ТС ОРМ. Перечень сервисных типов, их определения и запросы для доступа к информации на языке GraphQL приведены в приложении N 4 к требованиям, утвержденным настоящим приказом.

7. Пользовательский тип данных на языке GraphQL должен описывать данные, содержащиеся в ИС и отличные от данных, описываемых базовыми типами.

8. Схема данных в части базовых, пользовательских и сервисных типов должна удовлетворять следующим требованиям:

1) каждое поле пользовательского типа, которое отражает идентифицирующий признак объекта физического мира и будет доступно в качестве критерия поиска в ТС ОРМ по запросам ПУ, должно представляться базовым типом (или его списком);

2) поля пользовательского типа, которые представляют собой ссылки (HTTP URI) на неформатированные данные (файлы), должны представляться сервисным типом "Media", определенным в приложении N 5 к требованиям, утвержденным настоящим приказом;

3) остальные поля пользовательских типов (то есть за исключением указанных в подпунктах 1 и 2 настоящего пункта) должны описываться встроенными типами языка GraphQL или любыми другими пользовательскими типами, определенными в схеме данных;

4) для каждого пользовательского типа, имеющего хотя бы одно поле базового типа, или связанного с другим пользовательским типом, имеющим хотя бы одно поле базового типа, должны быть определены следующие объекты языка GraphQL: тип для представления результатов выполнения поисковых запросов и входной объект для задания параметров поиска (далее - входной объект);

5) тип для представления результатов выполнения поисковых запросов должен иметь следующую структуру:

Формат типа для представления результатов выполнения поисковых запросов должен быть следующим:

type {{UserTypeResult}} {
  cursor: String
  hasNextPage: Boolean
  result: [{{UserType}}!]
},

в котором:

{{UserTypeResult}} - произвольное имя типа для представления результатов выполнения поисковых запросов,

{{UserType}} - имя пользовательского типа, для которого определен тип {{UserTypeResult}};

6) каждый входной объект для пользовательского типа должен иметь следующую структуру:

Формат входного объекта для пользовательского типа:

input {{UserTypeFilterInput}} {
  and: [{{UserTypeFilterInput}}]
  or: [{{UserTypeFilterInput}}]
  not: {{UserTypeFilterInput}}
  {{baseField1}}: {{BaseFilterInput1}}
  ...
  {{baseFieldN}}: {{BaseFilterInputN}}
},

в котором:

{{UserTypeFiiterInput}} - произвольное имя входного объекта для пользовательского типа,

{{baseField1}...{{baseFieldN}} - поля пользовательского типа, представленные одним из базовых типов,

{{baseFilterInput1}}...{{baseFilterInputN}} - входные объекты для базовых типов, определенные в приложении N 6 к требованиям, утвержденным настоящим приказом;

7) все пользовательские типы, их поля и аргументы должны иметь описание на русском языке;

8) связь между двумя произвольными пользовательскими типами должна быть двухсторонней за исключением случаев, если один из пользовательских типов не имеет ни одного поля базового типа;

9) схема данных должна содержать все сервисные типы из перечня, определенного в приложении N 6 к настоящим требованиям.

9. Схема данных в части стандартных типов Query, Subscription (определяют доступные данные и параметры для поисковых запросов) языка GraphQL должна соответствовать следующим требованиям:

1) тип Query должен иметь поле "request" для задания поисковых запросов. Формат типа Query:

request: QueryMessage!

2) тип QueryMessage должен иметь следующую структуру:

Каждое поле типа QueryMessage, заданное списком пользовательского типа, должно иметь следующие аргументы:

filter - задает параметры поиска и представляется соответствующим входным объектом для данного пользовательского типа;

offset - задает начальное смещение для постраничной передачи результатов;

limit - задает максимальное количество элементов на одной странице при постраничной передаче результатов, но не более значения maxPageSize;

cursor - значение курсора при использовании курсорной постраничной передачи результатов.

Аргументы "offset" и "limit" должны использоваться для постраничной передачи результатов со смещением, аргументы limit и cursor - для курсорной постраничной передачи результатов.

Формат типа QueryMessage:

type QueryMessage {
  requestID: String!
  offline:  Boolean!
  maxPageSize: Int
  {{userType1}}(filter: {{UserTypeFilterInput1}}!, offset: Int, limit:
Int, cursor: String): {{UserTypeResult1}}!
  ...
  {{userTypeN}}(filter: {{UserTypeFilterInputN}}!, offset: Int, limit:
Int, cursor: String): {{UserTypeResultN}}!
},

в котором:

{{userType1}}...{{userTypeN}} - имена пользовательских типов, имеющих хотя бы одно поле базового типа;

{{UserTypeResult1}}...{{UserTypeResultN}} - Имена типов для представления результатов выполнения поисковых запросов, соответствующие пользовательским типам;

{{UserTypeFilterInput1}}...{{UserTypeFilterInputN}} - входные объекты, соответствующие пользовательским типам;

3) типы Query и Subscription должны также содержать все запросы, соответствующие сервисным типам, которые приведены в приложении N 5 к требованиям, утвержденным настоящим приказом.

10. На ТС ОРМ должны использоваться актуальные перечни базовых, сервисных типов и входных объектов для поиска.

11. Использование базовых, сервисных типов и входных объектов для задания параметров поиска, не приведенных в приложениях NN 4 - 6 к требованиям, утвержденным настоящим приказом, не допускается.

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

1) использование символа подчеркивания "_" в именах типов и их полей не допускается;

2) имена пользовательских типов пишутся с заглавной буквы и могут состоять из нескольких слов, написанных слитно без пробелов, при этом каждое слово с заглавной буквы;

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

1. В схеме данных для задания параметров поиска должны быть описаны входные объекты Input Objects на языке GraphQL для каждого пользовательского типа, имеющего не менее одного поля базового типа, или связанного с другим пользовательским типом, имеющего не менее одного поля базового типа.

2. Для описания входных объектов, соответствующих пользовательским типам, должны использоваться входные объекты для базовых типов, приведенные в настоящем приложении.

3. Каждый входной объект для базового типа должен содержать поля "and", "or" и "not" (соответствуют логическим функциям "И", "ИЛИ", "НЕ"), а также может содержать поля для функций, приведенных в таблице N 1 настоящего приложения. В случае применения числовой функций к множеству строк используется лексикографический порядок.

Таблица N 1.

4. Перечень входных объектов для базовых типов и доступные для них функции приведены в таблице N 2 настоящего приложения.

Таблица N 2.

1. ТС ОРМ и ПУ для передачи данных на языке GraphQL по протоколу WebSocket должны использовать подпротокол graphql-transport-ws.

2. ТС ОРМ и ПУ взаимодействую по протоколу WebSocket посредством сообщений. Для кодирования сообщений применяется формат JSON.

3. Все сообщения должны содержать поле "type", определяющее тип сообщения. Сообщение в зависимости от типа также может содержать дополнительные поля, в которых:

1) "id" - идентификатор запроса, использующийся для последующего определения ответов ТС ОРМ и привязки их к запросам ПУ;

2) "payload" - дополнительные данные для некоторых типов сообщений.

4. В любой момент времени ТС ОРМ должны позволять выполнять несколько запросов ПУ с уникальными идентификаторами. При этом передача сообщений, относящихся к различным запросам, может чередоваться.

5. ТС ОРМ должны закрывать соединение по протоколу WebSocket при возникновении критической ошибки (сбое в работе) и тем самым уведомлять ПУ о данной ситуации.

6. ПУ должен закрывать соединение по протоколу WebSocket с кодом 1000 и причиной закрытия "Normal Closure".

7. ПУ перед отправкой запросов на языке GraphQL должен открыть сессию (согласно подпункту 1 пункта 8 настоящего приложения) поверх протокола WebSocket.

8. ТС ОРМ и ПУ взаимодействуют по протоколу WebSocket с использованием следующих типов сообщений:

1) сообщение "ConnectionInit". Данное сообщение направляется ПУ в адрес ТС ОРМ для открытия сессии. ПУ может передавать дополнительную информацию о сессии в поле "payload". ТС ОРМ должны получить данное сообщение в течение заданного периода времени (определяется во время внедрения ТС ОРМ и согласовывается с уполномоченным государственным органом). В случае не поступления от ПУ в ТС ОРМ данного сообщения в течение заданного периода времени, ТС ОРМ должны закрыть соединение по протоколу WebSocket с кодом 4408 и причиной закрытия "Connection initialization timeout". В случае получения ТС ОРМ более одного сообщения "ConnectionInit", ТС ОРМ должны закрыть соединение по протоколу WebSocket с кодом 4429 и причиной закрытия "Too many initialization requests".

Формат сообщения "ConnectionInit" (поле "payload" опциональное):

    {
      "type": "connection_init",
      "payload": "string"
    }

2) сообщение "ConnectionAck". Данное сообщение подтверждает успешное создание сессии и направляется ТС ОРМ в адрес ПУ в ответ на сообщение "ConnectionInit". ТС ОРМ могут передавать дополнительную информацию о сессии в поле "payload". ПУ после получения данного сообщения может отправлять запросы на языке GraphQL с помощью сообщений "Subscribe" согласно подпункту 3 пункта 8 настоящего приложения.

Формат сообщения "ConnectionAck" (поле "payload" опциональное):

    {
      "type": "connection_ack",
      "payload": "string"
    }

3) сообщение "Subscribe". Данное сообщение направляется ПУ в адрес ТС ОРМ и должно содержать запрос на языке GraphQL в поле "query" поля "payload". Поле "id" должно содержать уникальный идентификатор запроса, формируемый ПУ. Если запрос с таким идентификатором уже выполняется, то ТС ОРМ должны закрыть соединение по протоколу WebSocket с кодом 4409 и причиной закрытия "Subscriber for <unique-operation-id> already exists". Разрешается повторное использование идентификатора после завершения выполнения запроса на стороне ТС ОРМ. В случае поступления от ПУ данного сообщения до получения сообщения "ConnectionAck", ТС ОРМ должны закрыть соединение по протоколу WebSocket с кодом 4401 и причиной закрытия "Unauthorized".

Формат сообщения "Subscribe" (поля "operationName", "variables", "extensions" опциональные):

    {
      "id": "",
      "type": "subscribe",
      "payload": {
        "operationName": "string",
        "query": "string",
        "variables": "string",
        "extensions": "string"
      }
    }

4) сообщение "Next". Данное сообщение направляется ТС ОРМ в адрес ПУ и содержит полные или частичные результаты выполнения запроса, ранее направленного ПУ в сообщении "Subscribe". Поле "id" должно содержать уникальный идентификатор запроса, ранее сформированный ПУ. Поле "payload" должно содержать результаты выполнения запроса в формате аналогичном для интерфейса "/query" согласно спецификации языка GraphQL.

Формат сообщения "Next:

    {
      "id": "",
      "type": "next",
      "payload": "ExecutionResult"
    }

5) сообщение "Error". Данное сообщение направляется ТС ОРМ в адрес ПУ и содержит информацию об ошибке в ходе выполнения запроса, ранее направленного ПУ в сообщении "Subscribe". Поле "id" должно содержать уникальный идентификатор запроса, ранее сформированный ПУ. Поле "payload" должно содержать информацию об ошибке в формате согласно спецификации языка GraphQL. В случае возникновения ошибки на начальном этапе выполнения запроса (в том числе, ошибки валидации запроса) либо в ходе выполнения запроса ТС ОРМ прекращают выполнение запроса и не направляют в сторону ПУ никаких сообщений.

Формат сообщения "Error":

    {
      "id": "",
      "type": "error",
      "payload": "GraphQLError"
    }

6) сообщение "Complete". Данное сообщение может направляться в обоих направлениях. Поле "id" должно содержать уникальный идентификатор запроса, ранее сформированный ПУ. Отправка данного сообщения ТС ОРМ в адрес ПУ означает завершение выполнения запроса с соответствующим идентификатором. В случае отправки ТС ОРМ сообщения "Error" до сообщения "Complete", данное сообщение не отправляется. Отправка данного сообщения ПУ в адрес ТС ОРМ означает, что ПУ прерывает выполнение запроса с соответствующим идентификатором и с данного момента не принимает результаты его выполнения.

Формат сообщения "Complete:

    {
      "id": "",
      "type": "complete"
    }

9. Получение ПУ или ТС ОРМ иных сообщений, отличных от указанных в пункте 8 настоящего приложения, должно приводить к закрытию соединения по протоколу WebSocket с кодом 4400 и причиной закрытия, содержащей описание ошибки в типе или формате сообщения.

1. ТС ОРМ должны предусматривать возможность получения ПУ следующей информации о структуре и функционировании ТС ОРМ по запросу ПУ:

1) о структуре и составе ТС ОРМ, составе и состоянии интерфейса взаимодействия ТС ОРМ с ПУ;

2) об установленном в ТС ОРМ общесистемном ПО, перечне и состоянии программных модулей в составе ПО ТС ОРМ;

3) о точках подключения ТС ОРМ к ИС и интерфейсах ввода информации в ТС ОРМ.

2. ТС ОРМ по запросу ПУ должны представлять следующую информацию в части структуры и состава ТС ОРМ, состава и состояния интерфейса взаимодействия ТС ОРМ с ПУ:

1) перечень коммутационного и серверного оборудования, средств хранения данных с его идентификацией;

2) идентификацию интерфейсов подключения оборудования ТС ОРМ друг к другу;

3) параметры для серверного оборудования:

общий и занятый объем оперативной памяти;

количество сетевых интерфейсов с их идентификацией, нагрузку;

общее количество процессоров, загрузку;

общий объем дискового пространства, объем свободного пространства;

4) параметры технических средств хранения данных:

перечень модулей, составляющих средства хранения данных с их идентификацией;

для каждого входящего в состав средств хранения данных модуля: общий объем дискового пространства, объем свободного дискового пространства и состояние модуля (функционирует штатно, произошел сбой, модуль не функционирует), текстовую расшифровку сбоя.

3. ТС ОРМ по запросу ПУ должны представлять информацию в части точек подключения ТС ОРМ к ИС, интерфейсов ввода информации в ТС ОРМ, содержащую:

1) перечень точек подключения к ИС провайдера хостинга и точек ввода информации в ТС ОРМ с их идентификацией;

2) для каждой точки подключения предоставляет информацию о:

состоянии точки подключения (ввода информации) (функционирует штатно, произошел сбой, модуль не функционирует), текстовую расшифровку сбоя;

объеме информации, поступающей в секунду;

периоде времени, в течение которого на точку подключения и (или) ввода информации в ТС ОРМ не поступала информация.

4. ТС ОРМ по запросу ПУ должны представлять следующую информацию в части состава ПО ТС ОРМ и его состояния:

1) перечень установленного общесистемного ПО с его идентификацией;

2) информацию для общесистемного ПО:

идентификатор ТС ОРМ, на котором установлено ПО;

наименование ПО;

состояние ПО (функционирует штатно, произошел сбой, модуль не функционирует), текстовую расшифровку сбоя;

3) перечень установленного ПО ТС ОРМ с его идентификацией;

4) информацию для ПО ТС ОРМ:

идентификатор ТС ОРМ, на котором установлено ПО;

назначение (определяется разработчиком ТС ОРМ);

состояние (функционирует штатно, произошел сбой, модуль не функционирует), текстовую расшифровку сбоя;

список контролируемых параметров.

5. Информация о функционировании и состоянии ТС ОРМ, указанная в пунктах 1 - 4 настоящего приложения, должна быть представлена в виде временных рядов (далее - метрик).

6. Метрики должны иметь следующий обязательный набор меток (пара ключ-значение), в которых:

systemtype - относится ли метрика к оборудованию или ПО. Может принимать одно из значений "hardware" или "software";

moduleid - идентификатор модуля;

modulename - наименование модуля;

moduletype - тип модуля;

blocknumber - номер блока оборудования;

groupname - наименование группы метрик;

softwareparentmoduleid - идентификатор модуля ПО, в состав которого входит модуль с данной метрикой;

hardwareparentmoduleid - идентификатор модуля оборудования, в состав которого входит модуль с данной метрикой.

7. Для метрик также должны быть заданы единицы измерения и описания их назначения на русском языке.

8. Для получения значений метрик ПУ направляет ТС ОРМ запросы мониторинга на интерфейс "/metric".

9. Для кодирования содержимого запросов мониторинга и ответов ТС ОРМ должен применяться формат JSON.

10. ТС ОРМ при успешном выполнении запросов мониторинга должны возвращать HTTP код 2xx.

11. ТС ОРМ при возникновении ошибки во время выполнения запросов мониторинга должны в ответе возвращать поле "error" с информацией об ошибке и следующие HTTP коды:

400 Bad Request - в запросе отсутствуют или некорректно заданы параметры;

422 Unprocessable Entity - неправильный формат запроса на языке PromQL согласно пункту 13 настоящего приложения;

503 Service Unavailable - выполнение запроса прервано на стороне ТС ОРМ.

12. Ответы на запросы мониторинга должны иметь следующий формат:

    {
      "status": "success" | "error",
      "data": ,

      "errorType": "",
      "error": "",

      "warnings": (""]
    }

в котором:

1) поле "status" - статус выполнения запроса, может принимать одно из двух значений: "success" или "error";

2) поле "data" - результат выполнения запроса, структура поля зависит от интерфейса, на которую был отправлен запрос (согласно пункту 13 настоящего приложения);

3) поля "errorType" и "error" - соответственно тип и описание ошибки, возникшей при выполнении запроса. Данные поля должны быть задана только, если поле "status" имеет значение "error";

4) поле "warnings" - незначительные ошибки (предупреждения), возникшие во время выполнения запроса, но существенно не повлиявшие на его выполнение. При этом поле "data" может содержать частичные результаты выполнения запроса.

13. ТС ОРМ должны реализовывать внутри интерфейса "/metric" следующие дополнительные конечные точки:

1) "/api/vl/query" - предназначена для приема запросов мониторинга от ПУ в целях получения метрик для конкретного значения времени, а также передачи на ПУ результатов выполнения данных запросов. Данная интерфейс должна поддерживать HTTP методы GET и POST.

Принимаемые параметры:

"query" - запрос на языке PromQL;

"time" (опционально) - дата и время в формате согласно RFC3339 или Unix-время;

"duration" (опционально) - период времени в формате согласно Time Durations языка PromQL.

Поле "data" для ответа на запросы мониторинга для данной интерфейса должно иметь следующий вид:

    {
      "resultType": "matrix" | "vector" | "scalar" | "string",
      "result": 
    }

Формат поля "result" зависит от значения поля "resultType" согласно пункту 14 настоящего приложения;

2) "/api/vl/query_range" - предназначена для приема запросов мониторинга от ПУ в целях получения метрик для диапазона времени, а также передачи на ПУ результатов выполнения данных запросов. Данная интерфейс должна поддерживать HTTP методы GET и POST.

Принимаемые параметры:

"query" - запрос на языке PromQL;

"start" - дата и время начала диапазона в формате согласно RFC3339 или Unix-время;

"end" - дата и время конца диапазона в формате согласно RFC3339 или Unix-время;

"step" - временной шаг запроса в формате согласно Time Durations языка PromQL или число с плавающей точкой;

"duration" (опционально) - период времени в формате согласно Time Durations языка PromQL.

Поле "data" для ответа на запросы мониторинга для данной интерфейса должно иметь следующий вид:

    {
      "resultType": "matrix",
      "result": 
    }

Формат поля "result" представлен в подпункте 1 пункта 14 настоящего приложения;

3) "/api/vl/series" - предназначена для приема запросов мониторинга от ПУ в целях получения списка метрик, которые имеют заданный набор меток, а также передачи на ПУ результатов выполнения данных запросов. Данная интерфейс должна поддерживать HTTP методы GET и POST.

Принимаемые параметры:

"match[]" - перечень запрашиваемых меток в формате Time series Selectors языка PromQL;

"start" - дата и время начала диапазона в формате согласно RFC3339 или Unix-время;

"end" - дата и время конца диапазона в формате согласно RFC3339 или Unix-время.

Поле "data" для ответа на запросы мониторинга для данной интерфейса должно содержать перечень метрик (представляются перечнем их меток (пара ключ-значение)), удовлетворяющих критериям запроса;

4) "/api/vl/labels" - предназначена для приема запросов мониторинга от ПУ в целях получения списка меток, которые имеют заданный набор метрик, а также передачи на ПУ результатов выполнения данных запросов. Данная интерфейс должна поддерживать HTTP методы GET и POST.

Принимаемые параметры:

"match[]" (опционально) - перечень запрашиваемых метрик в формате Time series Selectors языка PromQL;

"start" (опционально) - дата и время начала диапазона в формате согласно RFC3339 или Unix-время;

"end" (опционально) - дата и время конца диапазона в формате согласно RFC3339 или Unix-время.

Поле "data" для ответа на запросы мониторинга для данной интерфейса должно содержать перечень названий меток, удовлетворяющих критериям запроса;

5) "/api/vl/label/<label_name>/values" - предназначена для приема запросов мониторинга от ПУ в целях получения значений заданных меток, а также передачи на ПУ результатов выполнения данных запросов. Данная интерфейс должна поддерживать HTTP метод GET.

Принимаемые параметры:

"match[]" (опционально) - перечень запрашиваемых метрик в формате Time series Selectors языка PromQL;

"start" (опционально) - дата и время начала диапазона в формате согласно RFC3339 или Unix-время;

"end" (опционально) - дата и время конца диапазона в формате согласно RFC3339 или Unix-время.

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

14. Поле "result" в ответах на запросы мониторинга может иметь один из следующих форматов:

1) если поле "resultType" имеет значение "matrix", то поле "result" должно иметь следующий формат:

    [
      {
        "metric": {"": "", ... },
        "values": [[, ""], ... ],
        "histograms": [[, ], ... ]
      },
      ...
    ]

2) если поле "resultType" имеет значение "vector", то поле "result" должно иметь следующий формат:

    [
      {
        "metric": {"": "", ... },
        "value": [, ""],
        "histogram": [, ],
      },
      ...
    ]

3) если поле "resultType" имеет значение "scalar", то поле "result" должно иметь следующий формат:

    [, ""]

;

4) если поле "resultType" имеет значение "string", то поле "result" должно иметь следующий формат:

    [, ""]

.