Нет описания правки |
|||
(не показано 6 промежуточных версий 2 участников) | |||
Строка 1: | Строка 1: | ||
'''''[[Применение АппОптима]] / Владение / Назначение владельцев объектов''''' | |||
Владение можно применить с помощью нескольких методов, таких как метки и аннотации Kubernetes, метаданные хоста, переменные среды и теги (в том числе через API пользовательских тегов | Вы можете назначить '''Команды владения''' для любого контролируемого объекта в АппОптима, используя основной идентификатор команды или дополнительные идентификаторы (определяемые при настройке команды). Это упрощает мгновенный поиск ответственной команды и связь с ней в случае возникновения какой-либо проблемы с объектом, например, если объект затронут уязвимостью. | ||
Владение можно применить с помощью нескольких методов, таких как метки и аннотации Kubernetes, метаданные хоста, переменные среды и теги (в том числе через API пользовательских тегов АппОптима). | |||
== Поддерживаемые методы применения владения == | == Поддерживаемые методы применения владения == | ||
Строка 39: | Строка 41: | ||
# Сохраните изменения. | # Сохраните изменения. | ||
[[Файл:229.png|граница]] | [[Файл:229.png|граница|1100x1100пкс]] | ||
При отключении или удалении ключа объекта, назначенные командам через такие ключи, больше не будут отображать или хранить метаданные о владении. Однако такие ключи будут отображаться как обычные теги, применяемые к объектам. | При отключении или удалении ключа объекта, назначенные командам через такие ключи, больше не будут отображать или хранить метаданные о владении. Однако такие ключи будут отображаться как обычные теги, применяемые к объектам. | ||
Строка 53: | Строка 55: | ||
Мы рекомендуем определить владельца для Deployment и всех других объектов, для которых вы хотите охват владения. См. также '''''[[Лучшие команды для владения]]'''''. | Мы рекомендуем определить владельца для Deployment и всех других объектов, для которых вы хотите охват владения. См. также '''''[[Лучшие команды для владения]]'''''. | ||
* Установка идентификатора команды в качестве метки или аннотации для Deployment, CronJob, Job, DaemonSet или StatefulSet предоставляет информацию о владении командой для соответствующих объектов <code>CLOUD_APPLICATION</code>. Обратите внимание, что это владение не распространяется на <code>CLOUD_APPLICATION_INSTANCE</code>. В этом примере двойное владение устанавливается через две метки для Deployment. Каждая метка имеет уникальный ключ. Уникальные ключи являются обязательным требованием в метках и аннотациях Kubernetes. | * Установка идентификатора команды в качестве метки или аннотации для Deployment, CronJob, Job, DaemonSet или StatefulSet предоставляет информацию о владении командой для соответствующих объектов <code>CLOUD_APPLICATION</code>. Обратите внимание, что это владение не распространяется на <code>CLOUD_APPLICATION_INSTANCE</code>. В этом примере двойное владение устанавливается через две метки для Deployment. Каждая метка имеет уникальный ключ. Уникальные ключи являются обязательным требованием в метках и аннотациях Kubernetes. <br /><br /><code>apiVersion: apps/v1</code> <br /><code>kind: Deployment</code> <br /><code>metadata:</code> <br /><code> name: demo</code> <br /><code> labels:</code> <br /><code> dt.owner-1: my-team-1 # Dual team ownership defined for the Deployment</code> <br /><code> dt.owner-2: my-team-2</code> <br /><code>spec:</code> <br /><br />В примере кода ниже показана аннотация для владения на уровне развертывания. <br /><br /> <code>apiVersion: apps/v1</code> <br /><code>kind: Deployment</code> <br /><code>metadata:</code> <br /><code> name: demo</code> <br /><code> annotations:</code> <br /><code> dt.owner: my-team # Ownership defined for the Deployment</code> <br /> | ||
* Установите метки для Pod, чтобы указать владельца для соответствующего объекта <code>CLOUD_APPLICATION_INSTANCE</code>. Укажите владельца для каждого Pod. | * Установите метки для Pod, чтобы указать владельца для соответствующего объекта <code>CLOUD_APPLICATION_INSTANCE</code>. Укажите владельца для каждого Pod. <br /><br /><code>apiVersion: apps/v1</code> <br /><code>kind: Deployment</code> <br /><code>metadata:</code> <br /><code> name: demo</code> <br /><code>spec:</code> <br /><code> replicas: 3</code> <br /><code> selector:</code> <br /><code> matchLabels:</code> <br /><code> app: demo</code> <br /><code> template:</code> <br /><code> metadata:</code> <br /><code> labels:</code> <br /><code> app: demo</code> <br /><code> dt.owner: my-team # Ownership defined for the Pod</code> <br /><code> spec:</code> <br /><br />В примере кода ниже показан манифест для Pod, имеющего аннотацию <code>dt.owner: myTeam</code>. <br /><br /><code>apiVersion: v1</code> <br /><code>kind: Pod</code> <br /><code>metadata:</code> <br /><code> name: annotations-demo</code> <br /><code> annotations:</code> <br /><code> imageregistry: "<nowiki>https://hub.docker.com/</nowiki>"</code> <br /><code> dt.owner: my-team</code> <br /><code>spec:</code> <br /><code> containers:</code> <br /><code> - name: nginx</code> <br /><code> image: nginx:1.14.2</code> <br /><code> ports:</code> <br /><code> - containerPort: 80</code> <br /> | ||
* Для процесса укажите владельца, используя пары ключ-значение с переменной среды <code>DT_CUSTOM_PROP</code> , которая определена для контейнера. В переменных окружения можно указать несколько значений для одного и того же ключа. В этом примере двойное владение определяется с помощью ключа <code>owner</code>. | * Для процесса укажите владельца, используя пары ключ-значение с переменной среды <code>DT_CUSTOM_PROP</code> , которая определена для контейнера. В переменных окружения можно указать несколько значений для одного и того же ключа. В этом примере двойное владение определяется с помощью ключа <code>owner</code>. <br /><br /><code>apiVersion: apps/v1</code> <br /><code>kind: Deployment</code> <br /><code>metadata:</code> <br /><code> name: demo</code> <br /><code>spec:</code> <br /><code> replicas: 3</code> <br /><code> selector:</code> <br /><code> matchLabels:</code> <br /><code> app: demo</code> <br /><code> template:</code> <br /><code> spec:</code> <br /><code> containers:</code> <br /><code> - name: demo</code> <br /><code> image: demo:1.0.0</code> <br /><code> env:</code> <br /><code> - name: DT_CUSTOM_PROP ## Environment variable</code> <br /><code> value: "owner=team-automation owner=team-dev" # Dual ownership for the process; team IDs are team-automation and team-dev.</code> <br /> | ||
* Метки Kubernetes для сервиса | * Метки Kubernetes для сервиса <br /><br /><code>apiVersion: v1</code> <br /><code>kind: Service</code> <br /><code>metadata:</code> <br /><code> name: my-service</code> <br /><code> labels:</code> <br /><code> dt.owner: team-a # Ownership defined for the Service</code> <br /><code>spec:</code> <br /><code> selector:</code> <br /><code> app.kubernetes.io/name: MyApp</code> <br /><code>ports:</code> <br /><code> - protocol: TCP</code> <br /><code> port: 80</code> <br /><code> targetPort: 9376</code><br /> | ||
* Метки Kubernetes для namespace | * Метки Kubernetes для namespace <br /><br /><code>apiVersion: v1</code> <br /><code>kind: Namespace</code> <br /><code>metadata:</code> <br /><code> name: my-namespace</code> <br /><code> labels:</code> <br /><code> dt.owner: team-a # Ownership defined for the namespace</code> | ||
== Метаданные хоста == | == Метаданные хоста == | ||
Строка 91: | Строка 93: | ||
Мы '''не рекомендуем''' использовать теги для назначения владения процессам или группам процессов. | Мы '''не рекомендуем''' использовать теги для назначения владения процессам или группам процессов. | ||
Узнайте больше об определении метаданных | Узнайте больше об [[Теги и метаданные хоста|'''''определении тегов и метаданных для хостов''''']], например, о настройке переменной среды <code>DT_CUSTOM_PROP</code> для IIS и Windows . | ||
<code>export DT_CUSTOM_PROP dt.owner=DemoTeam</code> | |||
См. '''Формат заполнения информации о владении (выше)''' ко всем существующим параметрам «ключ-значение» или для создания собственного. | |||
== Теги == | |||
Используйте теги для применения владения только для объектов, которые не охватываются описанными выше методами. Обычно это объекты, такие как фронтенд-приложения, которые стабильны и малочисленны. | |||
=== Методы тегов === | |||
Вы можете использовать теги для применения владения в парах '''«ключ-значение» (раздел выше)''' к любому отслеживаемому объекту — '''''[[Теги и метаданные|подробнее о тегах]]'''''. | |||
[[Файл:230.png|граница]] | |||
* Ручные теги, использующие определенные ключи или префиксы ключей (например, <code>owner</code>и <code>dt.owner</code>), легко применяются через веб-интерфейс. | |||
* Вы также можете настроить правила автоматических тегов через веб-интерфейс. | |||
* Мы рекомендуем использовать API пользовательских тегов вместо правил автоматических тегов для применения владения к объектам. API пользовательских тегов позволяет вам удобно применять теги к большой группе объектов в рамках одного вызова API, выполняемого немедленно. | |||
Обратите внимание, что вручную примененные теги можно удалить вручную. Автоматически примененные теги нельзя удалить вручную из отдельных служб, групп процессов, экземпляров групп процессов, приложений или хостов. | |||
См. раздел '''''[[Лучшие команды для владения]]''''' для получения дополнительной информации о преимуществах и ограничениях тегов для назначения владельцев объектов. | |||
=== Разрешения === | |||
Для добавления, изменения или удаления владения через API пользовательских тегов вам потребуются все следующие разрешения. | |||
* Разрешение токена <code>entities.write</code> | |||
* Разрешение токена <code>settings.read</code> или политика IAM <code>ALLOW settings:objects:read WHERE settings:schemaId = "builtin:ownership.teams";</code> | |||
Для добавления, изменения или удаления тегов через веб-интерфейс вам необходимо разрешение '''Управление параметрами мониторинга''' на уровне среды или зоны управления. | |||
== Просмотр информации о владельце в веб-интерфейсе == | |||
Для хостов и всех сущностей '''Kubernetes''' выберите '''Владельцы''' на странице сведений о объекте, чтобы просмотреть информацию о владельце. | |||
В этом примере показано сопоставление рабочей нагрузки Kubernetes с объектом <code>CLOUD_APPLICATION</code>. Разверните имя команды, чтобы просмотреть ее данные. Выберите на странице '''Владельцы''', чтобы изменить данные команды в '''Настройках'''. | |||
[[Файл:231.png|граница|1101x1101пкс]] | |||
В этом примере показана информация о владельце модуля Kubernetes. | |||
[[Файл:232.png|граница|1096x1096пкс]] | |||
На странице '''Хосты''' можно искать хосты с владением — фильтровать по '''Тегам''' с ключевыми префиксами, которые вы определили, например, <code>owner</code>и <code>dt-owner</code>. Обратите внимание, что пары ключ-значение владение должны быть применены как минимум к одному хосту, чтобы ключ был доступен в фильтре '''Теги''' . Этот метод поиска владения доступен на всех страницах групп объектов, которые можно фильтровать по тегам. | |||
[[Файл:233.png|граница|1099x1099пкс]] | |||
На странице сведений о хосте, в примере ниже, у хоста есть три владельца команды. Один из владельцев отмечен как '''Неизвестный идентификатор команды''' . Это связано с тем, что даже если идентификатор команды был применен к хосту (например, через oneagentctl или ручной тег) в паре ключ-значение, команда не существует. Недействительный идентификатор команды означает, что команда или дополнительный идентификатор были применены к хосту в неправильном формате . | |||
Выберите '''Свойства и теги''' , чтобы просмотреть все теги, примененные к хосту. | |||
[[Файл:234.png|граница|1094x1094пкс]] | |||
Выберите [[Файл:235.png|граница|23x23пкс]] рядом с неизвестной командой, а затем выберите '''Добавить команду''' , чтобы определить информацию о команде в '''Настройках''' . Затем сущность автоматически обновляется с определением команды. | |||
[[Файл:236.png|граница]] |
Текущая версия от 15:14, 26 декабря 2024
Применение АппОптима / Владение / Назначение владельцев объектов
Вы можете назначить Команды владения для любого контролируемого объекта в АппОптима, используя основной идентификатор команды или дополнительные идентификаторы (определяемые при настройке команды). Это упрощает мгновенный поиск ответственной команды и связь с ней в случае возникновения какой-либо проблемы с объектом, например, если объект затронут уязвимостью.
Владение можно применить с помощью нескольких методов, таких как метки и аннотации Kubernetes, метаданные хоста, переменные среды и теги (в том числе через API пользовательских тегов АппОптима).
Поддерживаемые методы применения владения
Поддерживаются следующие методы применения типов собственности и объектов.
- Метаданные развертывания или конфигурации рекомендуется
Метод | Типы сущностей |
---|---|
Метки и аннотации Kubernetes | Все объекты Kubernetes |
Хост метаданных через oneagentctl илиhostcustomproperties.conf
|
Хосты |
Переменные среды | Процессы |
- Теги (ручные, автоматические и через API) — все отслеживаемые объекты
Формат заполнения информации о владении
Независимо от используемого метода информация о владении применяется к объектам в парах ключ-значение . Ключи по умолчанию owner
и dt.owner
доступны в каждой среде мониторинга — см. Настройки > Владение > Настройка. Однако вы можете изменить или удалить ключи по умолчанию и определить свои собственные .
Значение всегда является уникальным идентификатором команды, указанным при создании команды. Вы также можете использовать дополнительные идентификаторы.
У сущности может быть более одной команды владения. Вы можете добиться этого, применяя несколько пар ключ-значение, как показано в следующих разделах.
Пользовательские ключи для информации владения
Вы можете определить максимум пять ключей для применения информации владения.
- Перейдите в Настройки > Владение > Настроить.
- Нажмите на кнопку Добавить ключ.
- Введите ключ (Включено по умолчанию).
- Сохраните изменения.
При отключении или удалении ключа объекта, назначенные командам через такие ключи, больше не будут отображать или хранить метаданные о владении. Однако такие ключи будут отображаться как обычные теги, применяемые к объектам.
Дополнительные требования к ключам владения
- Вы можете определить максимум пять и минимум один ключ.
- Вы можете использовать любой из определенных вами ключей в качестве префикса в парах ключ-значение. Например, для ключей
owner
иdt.owner
вы можете использоватьowner-1
иdt.owner-test
.
Метки и аннотации Kubernetes
Вы можете указать команды владения для различных объектов Kubernetes, таких как Deployments, Pods, Services или namespaces. Чтобы гарантировать, что объекты Kubernetes имеют адекватное покрытие владения, что особенно важно для недолговечных сущностей, таких как Pods, предоставьте информацию о владельце в виде меток или аннотаций Kubernetes с парами ключ-значение в файле спецификации развертывания, например, deployment.yaml
.
Мы рекомендуем определить владельца для Deployment и всех других объектов, для которых вы хотите охват владения. См. также Лучшие команды для владения.
- Установка идентификатора команды в качестве метки или аннотации для Deployment, CronJob, Job, DaemonSet или StatefulSet предоставляет информацию о владении командой для соответствующих объектов
CLOUD_APPLICATION
. Обратите внимание, что это владение не распространяется наCLOUD_APPLICATION_INSTANCE
. В этом примере двойное владение устанавливается через две метки для Deployment. Каждая метка имеет уникальный ключ. Уникальные ключи являются обязательным требованием в метках и аннотациях Kubernetes.apiVersion: apps/v1
kind: Deployment
metadata:
name: demo
labels:
dt.owner-1: my-team-1 # Dual team ownership defined for the Deployment
dt.owner-2: my-team-2
spec:
В примере кода ниже показана аннотация для владения на уровне развертывания.
apiVersion: apps/v1
kind: Deployment
metadata:
name: demo
annotations:
dt.owner: my-team # Ownership defined for the Deployment
- Установите метки для Pod, чтобы указать владельца для соответствующего объекта
CLOUD_APPLICATION_INSTANCE
. Укажите владельца для каждого Pod.apiVersion: apps/v1
kind: Deployment
metadata:
name: demo
spec:
replicas: 3
selector:
matchLabels:
app: demo
template:
metadata:
labels:
app: demo
dt.owner: my-team # Ownership defined for the Pod
spec:
В примере кода ниже показан манифест для Pod, имеющего аннотациюdt.owner: myTeam
.apiVersion: v1
kind: Pod
metadata:
name: annotations-demo
annotations:
imageregistry: "https://hub.docker.com/"
dt.owner: my-team
spec:
containers:
- name: nginx
image: nginx:1.14.2
ports:
- containerPort: 80
- Для процесса укажите владельца, используя пары ключ-значение с переменной среды
DT_CUSTOM_PROP
, которая определена для контейнера. В переменных окружения можно указать несколько значений для одного и того же ключа. В этом примере двойное владение определяется с помощью ключаowner
.apiVersion: apps/v1
kind: Deployment
metadata:
name: demo
spec:
replicas: 3
selector:
matchLabels:
app: demo
template:
spec:
containers:
- name: demo
image: demo:1.0.0
env:
- name: DT_CUSTOM_PROP ## Environment variable
value: "owner=team-automation owner=team-dev" # Dual ownership for the process; team IDs are team-automation and team-dev.
- Метки Kubernetes для сервиса
apiVersion: v1
kind: Service
metadata:
name: my-service
labels:
dt.owner: team-a # Ownership defined for the Service
spec:
selector:
app.kubernetes.io/name: MyApp
ports:
- protocol: TCP
port: 80
targetPort: 9376
- Метки Kubernetes для namespace
apiVersion: v1
kind: Namespace
metadata:
name: my-namespace
labels:
dt.owner: team-a # Ownership defined for the namespace
Метаданные хоста
Для хостов мы рекомендуем использовать метаданные хоста в качестве основного метода применения права собственности.
Узнайте больше об определении тегов и метаданных для хостов и интерфейсе командной строки ЕдиногоАгента oneagentctl
.
Вы также можете назначать владение хостам с помощью тегов .
С помощью oneagentctl
ЕдиныйАгент версии 1.189+ Для хостов с ЕдинымАгентом версии 1.189+ используйте oneagenctl
интерфейс командной строки после установки, чтобы задать свойство метаданных для отдельного хоста. Запустите oneagentctl
с правами администратора или root из этих расположений по умолчанию.
- Windows:
%PROGRAMFILES%\astromkey\oneagent\agent\tools
- Все Unix-подобные системы:
/opt/astromkey/oneagent/agent/tools
В этом примере для Unix-подобных систем используется --set-host-property
установка владения с помощью пары ключ-значение owner-1=team-automation
, где team-automation
— основной идентификатор команды или дополнительный идентификатор.
./oneagentctl --set-host-property owner-1=team-automation
С помощью hostcustomproperties.conf
ЕдиныйАгент версии 1.187 и более ранних Для хостов на ЕдиномАгенте 1.187 и более ранних версиях создайте или отредактируйте файл hostcustomproperties.conf
конфигурации ЕдиногоАгента в следующих местах.
- Windows:
%PROGRAMDATA%\astromkey\oneagent\agent\config
- се Unix-подобные системы:
/var/lib/astromkey/oneagent/agent/config
В этом примере для Unix-подобных систем устанавливается влияние на хост с помощью пары ключ-значение dt.owner-1=team-automation
, где team-automation
— основной идентификатор команды или дополнительный идентификатор.
cat hostcustomproperties.conf dt.owner-1=team-automation
Переменные среды процесса
Для процессов мы рекомендуем указывать владение в парах ключ-значение через переменную среды DT_CUSTOM_PROP
.
Мы не рекомендуем использовать теги для назначения владения процессам или группам процессов.
Узнайте больше об определении тегов и метаданных для хостов, например, о настройке переменной среды DT_CUSTOM_PROP
для IIS и Windows .
export DT_CUSTOM_PROP dt.owner=DemoTeam
См. Формат заполнения информации о владении (выше) ко всем существующим параметрам «ключ-значение» или для создания собственного.
Теги
Используйте теги для применения владения только для объектов, которые не охватываются описанными выше методами. Обычно это объекты, такие как фронтенд-приложения, которые стабильны и малочисленны.
Методы тегов
Вы можете использовать теги для применения владения в парах «ключ-значение» (раздел выше) к любому отслеживаемому объекту — подробнее о тегах.
- Ручные теги, использующие определенные ключи или префиксы ключей (например,
owner
иdt.owner
), легко применяются через веб-интерфейс. - Вы также можете настроить правила автоматических тегов через веб-интерфейс.
- Мы рекомендуем использовать API пользовательских тегов вместо правил автоматических тегов для применения владения к объектам. API пользовательских тегов позволяет вам удобно применять теги к большой группе объектов в рамках одного вызова API, выполняемого немедленно.
Обратите внимание, что вручную примененные теги можно удалить вручную. Автоматически примененные теги нельзя удалить вручную из отдельных служб, групп процессов, экземпляров групп процессов, приложений или хостов.
См. раздел Лучшие команды для владения для получения дополнительной информации о преимуществах и ограничениях тегов для назначения владельцев объектов.
Разрешения
Для добавления, изменения или удаления владения через API пользовательских тегов вам потребуются все следующие разрешения.
- Разрешение токена
entities.write
- Разрешение токена
settings.read
или политика IAMALLOW settings:objects:read WHERE settings:schemaId = "builtin:ownership.teams";
Для добавления, изменения или удаления тегов через веб-интерфейс вам необходимо разрешение Управление параметрами мониторинга на уровне среды или зоны управления.
Просмотр информации о владельце в веб-интерфейсе
Для хостов и всех сущностей Kubernetes выберите Владельцы на странице сведений о объекте, чтобы просмотреть информацию о владельце.
В этом примере показано сопоставление рабочей нагрузки Kubernetes с объектом CLOUD_APPLICATION
. Разверните имя команды, чтобы просмотреть ее данные. Выберите на странице Владельцы, чтобы изменить данные команды в Настройках.
В этом примере показана информация о владельце модуля Kubernetes.
На странице Хосты можно искать хосты с владением — фильтровать по Тегам с ключевыми префиксами, которые вы определили, например, owner
и dt-owner
. Обратите внимание, что пары ключ-значение владение должны быть применены как минимум к одному хосту, чтобы ключ был доступен в фильтре Теги . Этот метод поиска владения доступен на всех страницах групп объектов, которые можно фильтровать по тегам.
На странице сведений о хосте, в примере ниже, у хоста есть три владельца команды. Один из владельцев отмечен как Неизвестный идентификатор команды . Это связано с тем, что даже если идентификатор команды был применен к хосту (например, через oneagentctl или ручной тег) в паре ключ-значение, команда не существует. Недействительный идентификатор команды означает, что команда или дополнительный идентификатор были применены к хосту в неправильном формате .
Выберите Свойства и теги , чтобы просмотреть все теги, примененные к хосту.
Выберите рядом с неизвестной командой, а затем выберите Добавить команду , чтобы определить информацию о команде в Настройках . Затем сущность автоматически обновляется с определением команды.