Мониторинг компонентов системы¶

Средства мониторинга (monitoring) и обнаружения компонентов (discovery) позволяют администратору системы решить две основные задачи:

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

Компоненты системы¶

Основные компоненты сервера приложений, для которых выполняется мониторинг и диагностика: web, jinni, monitor, chronos, webbi. Более подробная информация с описанием находится в разделе Компоненты системы.

Note

Для работы веб-сервисов web, chronos, jinni необходим файл лицензии.

Каждое конкретное внедрение может добавлять свои компоненты к системе. Однако, чтобы ими можно было управлять, все компоненты должны следовать определённым правилам и предоставлять о себе требуемую информацию, указанную далее (ниже описаны поля JSON объекта, а для работы в C# можно использовать класс DiscoveryComponentInfo).

Имя	Тип	Описание
`Cid`	строковой	Уникальный идентификатор компонента
`ServerCode`	строковый	Код (символьное имя) сервера TESSA, к которому относится компонент
`MachineName`	строковый	Имя (сетевое) компьютера, на котором запущен компонент
`ComponentType`	строковый	Имя типа компонента. Базовые компоненты были рассмотрены выше
`State`	строковый	Состояние компонента. Допустимо одно из трёх: - `OK` - компонент работает штатно; - `ERROR` - компонент не работает или работает не штатно; - `WARNING` - компонент работает штатно, но с некоторыми отклонениями
`StateDescription`	строковый	Описание состояния компонента. Особенно важно указывать здесь причины сбоев или нештатной работы
`Info`	JSON объект	Содержит дополнительную информацию о компоненте. Необязательное поле

Описание известных полей JSON объекта Info с дополнительной информацией о компоненте.

Имя	Тип	Описание
`PID`	целочисленный	Идентификатор процесса ОС данного компонента
`ProcessCPUUsage`	строковый	Строковое представление вещественного числа для процентного соотношения использования ресурсов процессора компонентом
`ProcessMemoryUsage`	целочисленный	Процентное соотношение использования оперативной памяти компонентом
`TotalCPUUsage`	строковый	Строковое представление вещественного числа для процентного соотношения общего использования ресурсов процессора системы
`TotalMemoryUsage`	целочисленный	Процентное соотношение общего использования оперативной памяти системы
`DiskQueueLength`	строковый	Строковое представление вещественного числа средней длины очереди запросов к диску
`Plugins`	список JSON объектов	Информация о запущенных плагинах `chronos`

Note

Каждый компонент публикует только ту информацию, которую может (обладает). Так, информацию о запущенных плагинах публикует только chronos. Статистику об использовании системных ресурсов публикуют те компоненты, которые её собирают. На данный момент её собирает только web.

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

Описание полей JSON объекта информации о запущенном плагине chronos (для работы в C# можно использовать класс DiscoveryPlugin).

Имя	Тип	Описание
`PID`	целочисленный	Идентификатор процесса ОС плагина
`Name`	строковый	Имя типа плагина
`LastRun`	строковый	Строковое представление даты и времени последнего запуска плагина в формате `ISO 8061`
`Duration`	строковый	Строковое представление продолжительности работы плагина в формате `[d'.']hh':'mm':'ss['.'fffffff]`
`CidName`	строковый	Уникальный идентификатор плагина как компонента
`State`	строковый	Состояние последнего запуска плагина после того, как он отработал. Допустимо одно из трёх: - `OK` - компонент работает штатно; - `ERROR` - компонент не работает или работает не штатно; - `WARNING` - компонент работает штатно, но с некоторыми отклонениями
`StateDescription`	строковый	Описание состояния последнего запуска плагина после того, как он отработал

Данная информация хранится в виде JSON объекта в Redis по ключу discovery:components.

Note

Каждый компонент должен выполнять публикацию своего состояния в Redis раз в 30 секунд.

Рассмотрим примеры информации о компонентах:

web - основной web-сервис TESSA:

{
"Info": {
    "PID": 22464,
    "ProcessCPUUsage": "0.00",
    "ProcessMemoryUsage": 2,
    "TotalCPUUsage": "9.14",
    "TotalMemoryUsage": 62,
    "DiskQueueLength": "0.01"
},
"Cid": "super-baker-dRflIq",
"ServerCode": "tessa",
"MachineName": "DESKTOP-1ACJ3LQ",
"ComponentType": "web",
"State": "OK",
"StateDescription": "Everything is fine"
}

chronos - сервис помощник запуска задач по расписанию:

{
"Info": {
    "PID": 17712,
    "Plugins": [
    {
        "PID": 31076,
        "Name": "Tessa.Chronos.Workflow.WorkflowEngineAsyncPlugin",
        "LastRun": "2023-09-28T12:27:20.0579619Z",
        "Duration": null,
        "CidName": "broad-addition-oQeFxb-yvK",
        "State": "OK",
        "StateDescription": "Everything is fine"
    },
    {
        "PID": 18780,
        "Name": "Tessa.Chronos.Roles.RoleSchedulerPlugin",
        "LastRun": "2023-09-28T12:27:20.0620845Z",
        "Duration": null,
        "CidName": "broad-addition-oQeFxb-vcB",
        "State": "OK",
        "StateDescription": "Everything is fine"
    },
    {
        "PID": 21104,
        "Name": "Tessa.Chronos.Acl.AclGenerationPlugin",
        "LastRun": "2023-09-28T12:27:20.1016597Z",
        "Duration": "00:00:02.7657303",
        "CidName": "broad-addition-oQeFxb-CUN",
        "State": "OK",
        "StateDescription": "Everything is fine"
    }
    ]
},
"Cid": "broad-addition-oQeFxb",
"ServerCode": "tessa",
"MachineName": "DESKTOP-1ACJ3LQ",
"ComponentType": "chronos",
"State": "OK",
"StateDescription": "Everything is fine"
}

Помимо представленной информации, каждый плагин chronos также может обновлять информацию о своей работе непосредственно в процессе её выполнения. Состояние работы плагина chronos описывается следующим JSON объектом (для работы в C# можно использовать класс PluginState).

Имя	Тип	Описание
`Cid`	строковый	Уникальный идентификатор плагина как компонента
`State`	строковый	Текущее состояние плагина. Допустимо одно из трёх: - `OK` - компонент работает штатно; - `ERROR` - компонент не работает или работает не штатно; - `WARNING` - компонент работает штатно, но с некоторыми отклонениями
`StateDescription`	строковый	Описание состояния плагина

Данная информация хранится в виде JSON объекта в Redis по ключу discovery:chronos.

Приведём пример информации о работе плагина конвертации документов.

{
  "State": "OK",
  "StateDescription": "Performing \"test.docx\" with CardID={D2F5287A-28BC-4224-8028-A94347A28CF9} and FileID={52BB24F9-9BF5-405F-99EC-A7772C6CE2C4}"
}

Правила генерации уникальных идентификаторов компонентов¶

Уникальный идентификатор компонента имеет вид <adjective>-<noun>-<randomWord>, где <adjective> - случайное английское прилагательное, <noun> - случайное английское существительное, <randomWord> - случайное слово (случайно сгенерированная последовательность из букв верхнего и нижнего регистра английского алфавита, длиной 6 символов).

Note

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

Note

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

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

Рассмотрим логику работы компонента с уникальным идентификатором:

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

Important

Рекомендуется создавать файл .cid вручную в нужной директории и задавать путь к нему при запуске компонента. Для файла нужно указывать соответствующие разрешения на чтение и запись.

Note

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

Для разрешения коллизий, после обнаружения таковой, компонент должен обновить свой уникальный идентификатор следующим образом <oldCID>_<randomWord>, где <oldCID> - текущий уникальный идентификатор компонента, <randomWord> - случайно сгенерированное слово из букв английского алфавита длиной не менее 3-х символов. Этот уникальный идентификатор хранится только в памяти компонента и не сохраняется на диск.

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

Note

При генерации уникального идентификатора для каждого запуска плагина chronos используется следующая схема <parentCID>-<randomWord>, где <parentCID> - уникальный идентификатор родительского процесса chronos для плагина, <randomWord> - случайно сгенерированное слово из букв английского алфавита длиной не менее 3-х символов. Этот уникальный идентификатор хранится только в памяти компонента и не сохраняется на диск.

За работу с описанными правилами генерации уникальных идентификаторов компонентов в C# отвечает интерфейс ICidProvider.

Контуры¶

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

доверенный - его содержимое считается безопасным и содержит критически важную инфраструктуру. Отметим, что СУБД Redis является в нём обязательным ресурсом;
внешний - его содержимое считается не безопасным.

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

Все из вышеперечисленных компонентов работают в доверенном контуре. Помимо них, в доверенный контур также входят СУБД Microsoft SQL Server или PostgreSQL, Redis (является обязательным ресурсом), разделяемые сетевые файловые директории и соответствующий reverse proxy, в роли которого может выступать IIS или nginx.

К внешнему контуру относятся различные приложения, которые работают с компонентами доверенного контура, отправляя запросы через reverse proxy. Таким образом, reverse proxy является соединительным шлюзом для доверенного и внешнего контура.

Important

За работу с командами, поступающими из внешнего контура, отвечает специальный маршрут webbi, настраиваемый в секции Settings->Management соответствующего файла app.json и отключенный по умолчанию.
Таким образом, для работы компонентов с командами из внешнего контура, в файле app.json webbi нужно включить использование маршрута Settings->Management->Enable и настроить его имя в соответствии с имеющимися требованиями Settings->Management->Endpoint, по умолчанию используется имя management.
Важно помнить, что webbi примет только те команды из внешнего контура, которые подписаны известными ему ключами.
Также важно помнить, что webbi работает по протоколу http, а команды должны приниматься по протоколу https. За подобную маршрутизацию, а также за работу с соответствующими сертификатами безопасности и отвечает reverse proxy, который перенаправляет запросы от клиентов в webbi и ответы от webbi клиентам. Таким образом, прямой доступ к webbi должен осуществляться только внутри доверенного контура. Доступ к webbi из внешнего контура должен осуществляться только через reverse proxy.

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

Компонент	Связанные компоненты и ресурсы
`jinni`	`web` Redis
`monitor`	Redis
`chronos`	Redis Microsoft SQL Server или PostgreSQL Сетевые файловые директории
`web`	Redis Microsoft SQL Server или PostgreSQL Сетевые файловые директории
`webbi`	Redis

Механизмы управления компонентами¶

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

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

Рассмотрим каждый из названных механизмов.

Система прав выполнения операций/действий¶

Набор прав на выполнение определённых операций будем называть Scope.

Important

Важно помнить, что наборы прав не пересекаются.

Перечислим наборы прав, поддерживаемые в существующих командах.

Код набора прав	Описание
`PublishTrustedKeys`	Главный набор правил. Позволяет выписывать и публиковать новые ключи. Под публикацией понимается процесс оповещения заинтересованных компонентов о существовании данного ключа. Буквально добавление ключа в коллекцию ключей каждого из компонентов, которым он предназначается, и которые должны работать с этим ключом. Подробнее ниже
`manage-keys`	Позволяет выполнять все операции с ключами, кроме выписывания новых ключей
`maintenance`	Позволяет переводить систему в режим технического обслуживания и выводить из этого режима
`tracing`	Позволяет управлять трассировкой запросов системы
`manage-locks`	Позволяет управлять блокировками в Redis, получать и удалять их
`discovery-info`	Позволяет получать информацию о компонентах

Note

Новые команды могут вводить дополнительные наборы прав.

Note

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

Ассиметричные ключи для подтверждения наличия прав¶

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

Important

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

Important

Чтобы компоненты могли работать с командами, подписанными данными ключами, компонентам требуются публичные ключи.

Рассмотрим структуру приватного ключа, хранящегося на стороне клиента, которым в дальнейшем будут подписываться команды (ниже описаны поля JSON объекта, а для работы в C# можно использовать класс DiscoveryKey).

Имя	Тип	Описание
`KeyID`	строка	Уникальный идентификатор ключа
`Subject`	строка	Описание назначения данного ключа. Содержит основание, по которому был выдан ключ
`IssuerKeyID`	строка	Уникальный идентификатор родительского ключа, на основании которого был выписан данный ключ. У самоподписанного мастер ключа равен `KeyID`
`Issuer`	строка	Назначение родительского ключа, на основании которого был выдан данный ключ. У самоподписанного мастер ключа равен `Subject`
`PublicKey`	строка	Публичный ключ в формате `X509`
`PrivateKey`	строка	Приватный ключ в формате `PKCS#8`
`Algorithm`	строка	Наименование алгоритма шифрования
`Scopes`	массив строк	Перечень прав на выполнение операций для данного ключа
`IssuedAt`	строка	Дата и время создания данного ключа в формате `ISO 8601`
`ExpiredAt`	строка	Дата и время окончания действия данного ключа в формате `ISO 8601`

Note

Приватный ключ хранится в файловой системе в виде защищённого файла JWE.

Рассмотрим структуру публичного ключа, хранящегося в Redis, а также на стороне компонентов, используемого ими для проверки подлинности команд (ниже описаны поля JSON объекта, а для работы в C# можно использовать класс DiscoveryPublishedKey).

Имя	Тип	Описание
`KeyID`	строка	Уникальный идентификатор ключа
`Subject`	строка	Описание назначения данного ключа. Содержит основание, по которому был выдан ключ
`IssuerKeyID`	строка	Уникальный идентификатор родительского ключа, на основании которого был выписан данный ключ
`Issuer`	строка	Назначение родительского ключа, на основании которого был выдан данный ключ
`PublicKey`	строка	Публичный ключ в формате `X509`
`Algorithm`	строка	Наименование алгоритма шифрования
`Scopes`	массив строк	Перечень прав на выполнение операций для данного ключа
`IssuedAt`	строка	Дата и время создания данного ключа в формате `ISO 8601`
`ExpiredAt`	строка	Дата и время окончания действия данного ключа в формате `ISO 8601`

Как можно заметить, публичный ключ отличается от приватного лишь отсутствием поля PrivateKey.

Note

Публичный ключ хранится в файловой системе и Redis в ключе keys в виде JWT, содержащего данные для проверки подлинности.

Команды управления компонентами¶

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

Рассмотрим структуру команды (ниже описаны поля JSON объекта, а для работы в C# можно использовать класс DiscoveryCommandRequest).

Имя	Тип	Описание
`ID`	строка	Уникальный идентификатор команды
`Created`	строка	Дата и время создания команды в формате `UTC` согласно `ISO 8601`
`ExpireAt`	строка	Дата и время истечения срока действия команды в формате `UTC` согласно `ISO 8601`
`Type`	строка	Код типа команды
`Arguments`	JSON объект	Аргументы команды. Зависят от типа команды и им же регламентируются
`Targets`	массив строк	Перечень компонентов адресатов команды
`Scopes`	массив строк	Перечень прав выполнения для данной команды

Important

В качестве адресата может выступать:

конкретный компонент, в этом случае указывается его уникальный идентификатор;
все компоненты указанного типа, в этом случае указывается тип компонента (поле ComponentType);
все компоненты системы, в этом случае указывается строка all.

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

Important

Каждая команда отправляется в формате JWT и подписывается приватным ключом. Поэтому важно помнить что права выполнения, указанные у команды, не должны превышать права выполнения используемого для её подписи ключа.

Note

Все отправленные команды хранятся в Redis по ключу commands.

Рассмотрим поддерживаемые типы команд.

Тип команды	Обязательные права выполнения	Описание
`PublishKey`	`PublishTrustedKeys`	Добавить ключ в коллекцию ключей компонента, т.е. опубликовать
`CheckKey`	`manage-keys`	Проверить наличие ключа у компонента
`DeleteKey`	`manage-keys`	Удалить ключ из коллекции ключей компонента
`Maintenance`	`maintenance`	Включить/выключить режим технического обслуживания системы
`EnableTracing`	`tracing`	Включить трассировку
`DisableTracing`	`tracing`	Выключить трассировку

При необходимости можно добавить поддержку любых дополнительных типов команд.

Note

Далее под командой подразумевается описанный выше JSON объект с конкретным значением поля Type.

Note

Команды tadmin SendCommand и SendCommandClient уже поддерживают возможность отправки произвольных команд компонентам и помещения всех аргументов командной строки, передаваемых в аргументах -pp:, в поле Arguments команды.

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

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

Рассмотрим подробнее аргументы (структуру JSON объектов поля Arguments команд) для поддерживаемых типов команд:

PublishKey:

Имя Тип Описание

Key строка Публичный ключ в виде JWT
CheckKey и DeleteKey:

Имя Тип Описание

KeyID строка Уникальный идентификатор ключа

Maintenance:

Имя	Тип	Описание
`maintenance`	строка	Флаг перевода системы в режим технического обслуживания. `on` - включить режим технического обслуживания; `off` - выключить режим технического обслуживания
`messages`	JSON объект	Набор сообщений, выводимых пользователю с поддержкой строк локализации. Ключом является имя сообщения. Значением - строка сообщения с поддержкой строк локализации. Подробнее можно прочитать здесь
`localization`	JSON объект	Набор строк локализации, используемых в сообщениях или независимо от них, для отображения пользователю. Ключом является имя строки локализации с опциональным префиксом кода языка согласно `ISO 639`. Значением - сама строка на указанном языке. Подробнее можно прочитать здесь

EnableTracing:

Имя Тип Описание

Settings JSON объект Объект с настройками параметров трассировки

DisableTracing:

Имя	Тип	Описание
`Source`	строка	Имя источника сбора данных для выключения трассировки

Рассмотрим структуру JSON объекта для настроек параметров трассировки (в C# можно использовать класс TracingSettings).

Имя	Тип	Описание
`SourceName`	строка	Имя источника сбора данных для трассировки (см. таблицу ниже)
`EndDate`	строка	Дата и время окончания данного вида трассировки в формате `UTC` согласно `ISO 8601`. Информация о запросах, произошедших по окончании данного времени, не собирается
`MinimalDuration`	строка	Минимальный порог длительности запроса, включаемого в данные трассировки в формате `[d'.']hh':'mm':'ss['.'fffffff]`. Если не указан, данные собираются для всех запросов
`CardID`	строка	Уникальный идентификатор карточки, для запросов которой включается трассировка, если есть
`UserID`	строка	Уникальный идентификатор пользователя, для запросов от которого включается трассировка, если есть
`CardTypeID`	строка	Уникальный идентификатор типа карточки, для запросов от которого включается трассировка, если есть
`Settings`	JSON объект	Объект с дополнительными настройками для трассировки в зависимости от `SourceName`. Предназначено для передачи параметров собственным источникам данных трассировки

Список имён доступных источников трассировок можно найти в документации по сервису monitor.

Каждый компонент периодически получает перечень имеющихся в Redis команд и в случае, если команда верифицирована, адресована данному компоненту и поддерживается им, выполняет её обработку и возвращает ответ следующей структуры (ниже описаны поля JSON объекта, а для работы в C# можно использовать класс DiscoveryCommandResponse).

Имя	Тип	Описание
`Cid`	строка	Уникальный идентификатор компонента
`Result`	строка	Результат обработки команды. Допустим один из трёх: - `OK` - команда выполнена успешно; - `ERROR` - во время выполнения произошла ошибка; - `WARNING` - команда выполнена, но нештатно, т.к. были обнаружены и скорректированы отклонения во входных данных или работе команды
`Text`	строка	Поясняющий результат работы команды текст
`Time`	строка	Дата и время завершения выполнения команды в формате `UTC` согласно `ISO 8601`

Note

Результаты обработки команд компонентами хранятся в ключе commands:{commandID}.

Important

Компонент при помещении ответа на команду в ключ commands:{commandID} должен установить для него предельное время жизни, равное времени жизни команды (поле ExpireAt команды) плюс одна минута.

Режимы безопасности при работе с ключами¶

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

Important

Все ключи компонента содержатся в директории authorized_keys, находящейся рядом с исполняемым файлом компонента.

Рекомендуется создавать эту директорию вручную и устанавливать ей соответствующие настройки доступа для чтения и записи компонентом.

При работе компонентов с ключами реализованы две политики безопасности, отличающиеся лишь тем, как происходит начальная инициализация компонента:

нормальная - при запуске компонент проверяет наличие ключей в директории authorized_keys:
- если файлы с ключами есть, они загружаются с соответствующей валидацией;
- если файлов с ключами нет, производится загрузка ключей из Redis с их валидацией. Ключи прошедшие проверку сохраняются в директории authorized_keys;
строгая - загружаются только ключи, содержащиеся в директории authorized_keys.

Important

Если среди загруженных компонентом ключей нет ни одного с правами PublishTrustedKeys (он же мастер ключ), то добавление новых ключей возможно только их ручным копированием в директорию authorized_keys.

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

Note

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

Note

Управление режимом безопасности работы с ключами производится при помощи задания соответствующего значения полю Settings -> Discovery.KeysStrictSecurity в файле app.json каждого компонента:

false или отсутствие данного поля означает использование нормальной политики безопасности;
true - использование строгой политики безопасности.

Команды `tadmin`¶

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

Команда просмотра состояния компонентов¶

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

Синтаксис команды и описание её параметров указаны в соответствующем разделе документации tadmin.

Important

Для выполнения команды PrintDiscoveryInfoClient необходимо, чтобы в webbi был включен приём внешних команд, а ключ имел набор прав, содержащий discovery-info.

Пример работы команды для доверенного контура:

tadmin PrintDiscoveryInfo -q

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

OK webbi (wet-island-DjxdNv) last seen <30sec
OK web (1 procs):
    OK clean-football-srTBUK 34496 last seen <30sec

Пример работы команды для внешнего контура:

tadmin PrintDiscoveryInfoClient -k:discoveryInfo.key -kp:password -wa:https://localhost/tessa/webbi -wm:management -q

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

OK webbi (wet-island-DjxdNv) last seen <30sec
OK web (1 procs):
    OK clean-football-srTBUK 34496 last seen <30sec

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

Important

Каждый компонент публикует информацию о своей работе раз в 30 секунд.

Important

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

Info

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

В экспортном формате будет выведена следующая информация:

tadmin PrintDiscoveryInfo -e -q

[
  {
    "CID": "wet-island-DjxdNv",
    "ComponentType": "webbi",
    "Info": {
      "PID": 33516
    },
    "MachineName": "DESKTOP-0047",
    "ServerCode": "tessa",
    "State": "OK",
    "StateDescription": "Good"
  },
  {
    "CID": "clean-football-srTBUK",
    "ComponentType": "web-server",
    "Info": {
      "DiskQueueLength": "0.02",
      "PID": 34496,
      "ProcessCPUUsage": "0.00",
      "ProcessMemoryUsage": 1,
      "TotalCPUUsage": "10.95",
      "TotalMemoryUsage": 88
    },
    "MachineName": "DESKTOP-0047",
    "ServerCode": "tessa",
    "State": "OK",
    "StateDescription": "Everything is fine"
  }
]

Команда генерации ключей¶

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

Note

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

Important

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

Синтаксис команды и описание её параметров указаны в соответствующем разделе документации tadmin.

Important

Мастер ключ системы (первый, он же главный ключ системы, на основании которого выписываются все остальные ключи, подробнее смотри ниже) должен быть самоподписанным и иметь права выполнения PublishTrustedKeys.

Рекомендуется также указывать для этого ключа права выполнения manage-keys.

Note

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

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

Пример работы команды:

tadmin GenerateDiscoveryKey "PublishTrustedKeys" "manage-keys" "-s:Root system key" "-p:admin" -em:12 -self -o:System.key -nologo

После выполнения команды в файловой системе появятся два файла System.key и System_public.key.

Команда просмотра ключа¶

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

Синтаксис команды и описание её параметров указаны в соответствующем разделе документации tadmin.

Пример работы команды:

tadmin ViewDiscoveryKey "System.key" "-p:admin" -nologo

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

{"KeyID":"CPeu45FlewsyNHAqhAj8PFXGhFEY64lyIN7r6lqo3Yne2S9johOoPLnKBJnLZO6SWsvbba63xBv2zi+WeME01A==","IssuerKeyID":"CPeu45FlewsyNHAqhAj8PFXGhFEY64lyIN7r6lqo3Yne2S9johOoPLnKBJnLZO6SWsvbb
a63xBv2zi+WeME01A==","Scopes":["PublishTrustedKeys","manage-keys"],"Subject":"Root system key","Issuer":"Root system key","PublicKey":"MIGbMBAGByqGSM49AgEGBSuBBAAjA4GGAAQAyPRccg8Ho6rV3oQdPbSB1VaFBBJn
+KqvGhUQ3pP6HFcwfmUOmWb4X91P2aMHq7z50yeF4sEaLeome5kRlgL9bwsBLxCPZ6kvNww7asyKsa6GxYIbfTapUVkvz+R9JHC+LsvRmc/fWalVML1zvT9OMEGkEr7TMFq/iiPi0m23VftJVw0=","Algorithm":"ecdsa","IssuedAt":"20
23-10-03T09:54:29.9271438Z","ExpiredAt":"2024-10-03T09:54:29.9271438Z","PrivateKey":"MIHuAgEAMBAGByqGSM49AgEGBSuBBAAjBIHWMIHTAgEBBEIBJHrkueY7rXCNgsvBjEkPqJEL4/xa4r5dofQ5eLD940DR/hWW+vF
uSBnqC4mwB6WTVAb1OU9jYGKbk5mFt6kirdahgYkDgYYABADI9FxyDwejqtXehB09tIHVVoUEEmf4qq8aFRDek/ocVzB+ZQ6ZZvhf3U/ZowervPnTJ4XiwRot6iZ7mRGWAv1vCwEvEI9nqS83DDtqzIqxrobFght9NqlRWS/P5H0kcL4uy9GZz99
ZqVUwvXO9P04wQaQSvtMwWr+KI+LSbbdV+0lXDQ=="}

Команда отправки универсальных команд компонентам¶

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

Синтаксис команды и описание её параметров указаны в соответствующем разделе документации tadmin.

Important

Для отправки команд из внешнего контура нужно активировать возможность их приёма в webbi и настроить reverse proxy (IIS или nginx) для маршрутизации сообщений на нужный маршрут.

Также важно помнить, что reverse proxy должен быть настроен таким образом, чтобы принимать команды только по HTTPS.

Пример работы серверной команды:

tadmin SendCommand CheckKey -k:System.key -kp:admin -s:manage-keys -t:all -timeout:3 "-pp:k=System.key" "-pp:kp=admin" -nologo

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

wet-island-DjxdNv OK: Key found
clean-football-srTBUK OK: Key found

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

Пример работы клиентской команды:

tadmin SendCommandClient CheckKey -k:System.key -kp:admin -s:manage-keys -t:all -timeout:3 -wa:https://localhost/tessa/webbi -wm:management "-pp:k=System.key" "-pp:kp=admin" -nologo

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

wet-island-DjxdNv OK: Key found
clean-football-srTBUK OK: Key found

Работа администраторов с ключами¶

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

Important

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

Генерация мастер ключа при установке системы¶

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

Important

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

При использовании нормального режима безопасности работы компонентов с ключами для генерации мастер ключа удобнее всего использовать команду:

tadmin GenerateDiscoveryKey "PublishTrustedKeys" "manage-keys" "-s:Root system key" -mode:Register "-p:admin" -self -o:root.key -nologo

В результате работы команды в файловой системе будет создан файл приватного ключа root.key и файл публичного ключа root_public.key. При этом публичный ключ сразу же будет помещён в Redis.

Important

В этом случае ключ будет создан сроком на 3 месяца, для генерации ключа с большим периодом действия необходимо использовать аргумент -em.

При использовании строгого режима безопасности работы компонентов с ключами для генерации мастер ключа нужно использовать команду:

tadmin GenerateDiscoveryKey "PublishTrustedKeys" "manage-keys" "-s:Root system key" "-p:admin" -self -o:root.key -nologo

В результате работы команды в файловой системе будет создан файл приватного ключа root.key и файл публичного ключа root_public.key.

Important

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

Important

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

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

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

tadmin PrintDiscoveryInfo -q

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

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

tadmin SendCommand CheckKey -k:root.key -kp:admin -s:manage-keys -t:all -timeout:3 "-pp:k=root.key" "-pp:kp=admin" -nologo

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

Генерация ключа перевода системы в режим технического обслуживания¶

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

Important

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

При использовании нормального режима безопасности работы компонентов с ключами для генерации мастер ключа удобнее всего использовать команду:

tadmin GenerateDiscoveryKey "maintenance" "-s:Key for system maintenance" -mode:Publish "-p:admin" "-k:root.key" "-kp:admin" -o:maintenance.key -nologo

В результате работы команды в файловой системе будет создан файл приватного ключа maintenance.key и файл публичного ключа maintenance_public.key. При этом публичный ключ сразу же будет помещён в Redis и отправлена команда публикации ключа.

Important

В этом случае ключ будет создан сроком на 3 месяца, для генерации ключа с большим периодом действия необходимо использовать аргумент -em.

При использовании строгого режима безопасности работы компонентов с ключами для генерации мастер ключа нужно использовать команду:

tadmin GenerateDiscoveryKey "maintenance" "-s:Key for system maintenance" "-p:admin" "-k:root.key" "-kp:admin" -o:maintenance.key -nologo

В результате работы команды в файловой системе будет создан файл приватного ключа maintenance.key и файл публичного ключа maintenance_public.key.

Important

Для того, чтобы webbi мог работать со сгенерированным ключом, необходимо скопировать файл maintenance_public.key в директорию authorized_keys каждого из компонентов webbi.

tadmin SendCommand CheckKey -k:root.key -kp:admin -s:manage-keys -t:webbi -timeout:3 "-pp:k=maintenance.key" "-pp:kp=admin" -nologo

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

Генерация ключа для включения трассировки запросов¶

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

Important

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

При использовании нормального режима безопасности работы компонентов с ключами для генерации мастер ключа удобнее всего использовать команду:

tadmin GenerateDiscoveryKey "tracing" "-s:Key for tracing system requests" -mode:Publish "-p:admin" "-k:root.key" "-kp:admin" -o:tracing.key -nologo

В результате работы команды в файловой системе будет создан файл приватного ключа tracing.key и файл публичного ключа tracing_public.key. При этом публичный ключ сразу же будет помещён в Redis и отправлена команда публикации ключа.

Important

В этом случае ключ будет создан сроком на 3 месяца, для генерации ключа с большим периодом действия необходимо использовать аргумент -em.

При использовании строгого режима безопасности работы компонентов с ключами для генерации мастер ключа нужно использовать команду:

tadmin GenerateDiscoveryKey "tracing" "-s:Key tracing system requests" "-p:admin" "-k:root.key" "-kp:admin" -o:tracing.key -nologo

В результате работы команды в файловой системе будет создан файл приватного ключа tracing.key и файл публичного ключа tracing_public.key.

Important

Для того, чтобы основной веб-сервис TESSA web мог работать со сгенерированным ключом, необходимо скопировать файл tracing_public.key в директорию authorized_keys каждого из компонентов web.

tadmin SendCommand CheckKey -k:root.key -kp:admin -s:manage-keys -t:web -timeout:3 "-pp:k=tracing.key" "-pp:kp=admin" -nologo

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

Мониторинг компонентов системы¶

Компоненты системы¶

Правила генерации уникальных идентификаторов компонентов¶

Контуры¶

Механизмы управления компонентами¶

Система прав выполнения операций/действий¶

Ассиметричные ключи для подтверждения наличия прав¶

Команды управления компонентами¶

Режимы безопасности при работе с ключами¶

Команды tadmin¶

Команда просмотра состояния компонентов¶

Команда генерации ключей¶

Команда просмотра ключа¶

Команда отправки универсальных команд компонентам¶

Работа администраторов с ключами¶

Генерация мастер ключа при установке системы¶

Генерация ключа перевода системы в режим технического обслуживания¶

Генерация ключа для включения трассировки запросов¶

Команды `tadmin`¶