Открыть меню
Открыть персональное меню
Вы не представились системе
Your IP address will be publicly visible if you make any edits.

Запуск мониторинга Kubernetes/OpenShift: различия между версиями

Материал из Документация АппОптима
Нет описания правки
 
(не показано 5 промежуточных версий 2 участников)
Строка 1: Строка 1:
На этой странице описывается, как настроить мониторинг черезОператор Ключ-АСТРОМ версии 0.3.0+на Kubernetes (с <code>kubectl</code>) и OpenShift (с <code>oc</code>) с использованием следующих вариантов развертывания :
'''''[[Установка и настройка]] / [[Установка и настройка|АппОптима разворачивается на]] / [https://docs.expert-apm.ru/index.php/%D0%A3%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2%D0%BA%D0%B0_%D0%B8_%D0%BD%D0%B0%D1%81%D1%82%D1%80%D0%BE%D0%B9%D0%BA%D0%B0#:~:text=%D0%9A%D0%BE%D0%BD%D1%82%D0%B5%D0%B9%D0%BD%D0%B5%D1%80%D0%BD%D1%8B%D1%85%20%D0%BF%D0%BB%D0%B0%D1%82%D1%84%D0%BE%D1%80%D0%BC%D0%B0%D1%85 Контейнерных платформах] / [[Kubernetes/OpenShift]] / Запуск мониторинга Kubernetes/OpenShift'''''


* Классический полный стек
Есть разные способы активировать АппОптима в Kubernetes/Openshift/OKD. Каждый способ имеет свои преимущества. Мы рекомендуем эти стратегии развертывания с точки зрения полноты функций и отсутствия ограничений.
* Облачный полный стек
* Мониторинг хоста
* Автоматическое приложение только


Существующие пользователи
Вы можете перейти с устаревшего оператора ЕдиныйАгент на новый оператор АппОптима, который управляет жизненным циклом нескольких компонентов АппОптима, таких как ЕдиныйАгент, маршрутизация и монитор API Kubernetes. Инструкции по миграции см. в разделе Миграция с оператора ЕдиныйАгент на оператор АппОптима в Kubernetes/OpenShift/OKD с помощью kubectl/oc .


* Если вы уже настроили мониторинг с помощью более ранней версии Ключ-АСТРОМ Operator, мы рекомендуем вам обновиться до последней версии Ключ-АСТРОМ Operator .
== Классическое инжектирование полного стека (Classic full-stack) ==
* Если вы уже настроили мониторинг с помощью ЕдиныйАгент Operator, см. инструкции по переходу на Ключ-АСТРОМ Operator , поскольку процедура ЕдиныйАгент Operator устарела.
''Рекомендации'':
** Сведения об изменениях версии Ключ-АСТРОМ Operator см. в разделе Общие сведения и настройка пользовательского ресурса DynaKube .


Устаревшие страницы
Руководство по установке см. в разделе Настройка мониторинга Kubernetes .


Есть два способа настроить Ключ-АСТРОМ Operator для мониторинга вашего кластера Kubernetes:
'''Примечание.''' Если вы предпочитаете использовать Helm, см . раздел Настройка мониторинга Kubernetes/OpenShift/OKD с помощью Helm .


* Автоматический режим обеспечивает простую настройку базовой конфигурации с помощью веб-интерфейса Ключ-АСТРОМ.
=== Возможности и ограничения ===
* Ручной режим позволяет выполнять сложные настройки.
'''Возможности:'''


Инструкции см. ниже.
* Бесшовная интеграция с хостом (узлом Kubernetes). Инструментированные модули сохраняют свои таксономические отношения с хостами и метриками хостов. Агенты хоста дополняют модули кода обнаружением OOM, мониторингом дисков и хранилищ, мониторингом сети и т. д.
* Всесторонность. Этот комплексный подход включает в себя мониторинг кластера Kubernetes, распределенную трассировку, изоляцию домена сбоя и глубокое понимание на уровне кода с использованием единой конфигурации развертывания для ваших кластеров.


== Предпосылки ==
'''Ограничения:''' существует зависимость запуска между контейнером, в котором развернут ЕдиныйАгент, и контейнерами приложений, которые должны быть инструментированы (например, контейнерами, в которых включен глубокий мониторинг процессов). Контейнер ЕдиногоАгента должен быть запущен, а <code>oneagenthelper</code>процесс должен быть запущен до запуска контейнера приложения, чтобы приложение могло быть правильно инструментировано.


* См. Жизненный цикл поддержки для Kubernetes или Жизненный цикл поддержки для OpenShift для поддерживаемых версий и минимальных требований к версии.
=== Развернутые ресурсы ===
* Поды должны разрешать выход в вашу среду Ключ-АСТРОМ или в вашу среду АктивныйШлюз, чтобы метрическая маршрутизация работала правильно.
АппОптима Operator управляет классической инъекцией полного стека после развертывания следующих ресурсов.
* Для OpenShift ( <code>cloudNativeFullStack</code>и <code>applicationMonitoring</code>с развертыванием драйвера CSI) необходимо настроить ограничения контекста безопасности (OpenShift) .


Примечание. По умолчанию образы ЕдиныйАгент и АктивныйШлюз извлекаются из настроенной конечной точки кластера Ключ-АСТРОМ, если не указано иное. Подробнее см. в разделе Параметры .
* ЕдиныйАгент , развернутый как DaemonSet, собирает метрики хоста с узлов Kubernetes. Он также обнаруживает новые контейнеры и внедряет модули кода ЕдиныйАгент в модули приложений.
* АппОптима АктивныйШлюз используется для маршрутизации, а также для мониторинга объектов Kubernetes путем сбора данных (метрики, события, статус) из Kubernetes API.
* Сервер веб-перехватчиков АппОптима проверяет правильность определений Dynakube.
'''Примечание.''' Для классического внедрения полного стека требуется ''доступ'' на запись из модуля ЕдиныйАгент к файловой системе узла Kubernetes для обнаружения и внедрения во вновь развернутые контейнеры.


=== Требуются токены и разрешения ===
== Облачное внедрение полного стека (Cloud full-stack) ==
Руководство по установке см. в разделе Настройка мониторинга Kubernetes .


* Создайте токен API в своей среде Ключ-АСТРОМ и включите следующие разрешения:
'''Примечание.''' Если вы предпочитаете использовать Helm, см . раздел Настройка мониторинга Kubernetes/OpenShift с помощью Helm .
** Доступ к ленте проблем и событий, метрикам и топологии ( <code>DataExport</code>)
** Интеграция с PaaS — загрузка установщика ( <code>InstallerDownload</code>)
** Оператор Ключ-АСТРОМ версии 0.7.0+ Создать токены АктивныйШлюз ( <code>АктивныйШлюзTokenManagement.create</code>)  Примечание. Эта область создает токен аутентификации для вашего АктивныйШлюз для подключения к кластеру Ключ-АСТРОМ. Токен ротируется оператором Ключ-АСТРОМ каждые 30 дней. При смене токена аутентификации затронутый АктивныйШлюз автоматически удаляется и повторно развертывается.
** по желанию Оператор Ключ-АСТРОМ версии 0.4.0+Если вы хотите, чтобы Ключ-АСТРОМ Operator автоматически обрабатывал подключение к АктивныйШлюз через общедоступный API для мониторинга Kubernetes , не забудьте также включить следующие разрешения:
*** Чтение объектов ( <code>entities.read</code>)
*** Прочитать настройки ( <code>settings.read</code>)
*** Записать настройки ( <code>settings.write</code>)
* Оператор Ключ-АСТРОМ версии 0.4.0+Для развертываний <code>cloudNativeFullStack</code>и <code>applicationMonitoring</code>в дополнение к токену API также необходимо создать <code>dataIngestToken</code>токен для обогащения метрик метаданных и включить разрешение Ingest metrics (metrics.ingest) .
* Для OpenShift Dedicated вам потребуются права администратора кластера .


== Настроить мониторинг через Ключ-АСТРОМ Operator в автоматическом режиме ==
=== Возможности и ограничения ===
'''Возможности:'''


# В меню Ключ-АСТРОМ перейдите в Kubernetes .
* Предлагает аналогичную функциональность, как классическое внедрение полного стека (см. ограничения ниже).
# Выберите Подключаться автоматически через оператора Ключ-АСТРОМ .
* Использует изменяющиеся веб-перехватчики для внедрения модулей кода в модули приложений.
# Введите следующие данные.
#* Имя: определяет отображаемое имя вашего кластера Kubernetes. Кроме того, это имя будет использоваться в качестве префикса для именования ресурсов Ключ-АСТРОМ внутри кластера Kubernetes, таких как DynaKube (пользовательский ресурс), АктивныйШлюз (модуль), ЕдиныйАгентs (модуль), а также в качестве имени секрета, содержащего ваши токены.
#* по желанию Группа: определяет группу, которая будет использоваться различными настройками Ключ-АСТРОМ, включая сетевую зону, группу АктивныйШлюз и группу узлов. Если не установлено, используются значения по умолчанию или пустые значения.
#* Токен оператора Ключ-АСТРОМ: введите токен API , который вы создали в предварительных условиях , или выберите « Создать токен », чтобы он был создан автоматически.
#* по желанию Маркер приема данных. Для развертываний <code>cloudNativeFullStack</code>и <code>applicationMonitoring</code>введите маркер приема данных, созданный в разделе Предварительные условия , или выберите Создать маркер , чтобы он был создан автоматически.
# по желаниюВыберите, хотите ли вы, чтобы Ключ-АСТРОМ проверяла ваш SSL-сертификат.  Примечание. Сертификат SSL проверяется только для запросов Ключ-АСТРОМ Operator API.
# Для GKE, Anthos, CaaS, TGKI и IKS включите параметр Включить объемное хранилище (требуется только для <code>classicFullStack</code>развертываний).
# В разделе Kubernetes / OpenShift выберите «Загрузить dynakube.yaml» , затем скопируйте блок кода, созданный Ключ-АСТРОМ на основе ваших данных, полученных на предыдущих шагах, и запустите его в своем терминале. Обязательно выполняйте команды в том же каталоге, в который вы загрузили YAML, или адаптируйте команды для ссылки на расположение YAML.  Примечание . Загруженный файл YAML представляет собой базовую версию определения пользовательского ресурса DynaKube. Чтобы адаптировать значения к вашим конкретным потребностям, см. предварительно настроенные образцы пользовательских ресурсов DynaKube на GitHub . Дополнительные сведения о вариантах развертывания см. в разделе Варианты развертывания в Kubernetes/OpenShift .
# Чтобы увидеть статус развертывания, выберите Показать статус развертывания .


== Настройка мониторинга через Ключ-АСТРОМ Operator в ручном режиме. ==
'''Ограничения:'''
Создать <code>Ключ-АСТРОМ</code>пространство имен (Kubernetes)/Добавить <code>Ключ-АСТРОМ</code>проект (OpenShift)


Установите оператор Ключ-АСТРОМ.
* Файлы диагностики ("архивы поддержки") для модулей приложений пока не поддерживаются.
* Правила мониторинга контейнеров пока не поддерживаются (параметр селектора меток Dynakube предоставляет аналогичную функциональность).
* Сетевые зоны пока не поддерживаются.
* Трассировка дополнительных модулей Istio и входных шлюзов, а также любых других экземпляров прокси-сервера Envoy не поддерживается.


Дождитесь завершения инициализации компонентов оператора Ключ-АСТРОМ.
=== Развернутые ресурсы ===
АппОптима Operator управляет облачной инъекцией полного стека после развертывания следующих развернутых ресурсов.


Создайте секрет, содержащий ваши токены
* '''ЕдиныйАгент''' , развернутый как DaemonSet, собирает метрики хоста с узлов Kubernetes.
* '''Сервер веб-перехватчиков''' АппОптима изменяет определения модулей, чтобы включить модули кода АппОптима для наблюдения за приложениями.
* '''Драйвер АппОптима CSI''', развернутый как DaemonSet, предоставляет доступное для записи хранилище томов для ЕдиныйАгент и двоичных файлов ЕдиныйАгент для модулей.
* '''АппОптима АктивныйШлюз''' используется для маршрутизации, а также для мониторинга объектов Kubernetes путем сбора данных (метрики, события, статус) из Kubernetes API.
== Мониторинг хоста ==
Руководство по установке см. в разделе Настройка мониторинга Kubernetes .


Загрузите предварительно настроенный образец пользовательского ресурса DynaKube
'''Примечание'''. Если вы предпочитаете использовать Helm, см . раздел Настройка мониторинга Kubernetes/OpenShift с помощью Helm .


Просмотрите параметры
=== Возможности и ограничения ===
'''Возможности:''' собирает метрики узлов и обрабатывает данные.


Просмотрите доступные параметры конфигурации
'''Ограничения.''' Диагностические файлы («архивы поддержки») для модулей приложений еще не поддерживаются для файловых систем, доступных только для чтения.


Примените пользовательский ресурс DynaKube
=== Развернутые ресурсы ===
АппОптима Operator управляет мониторингом хоста после развертывания следующих развернутых ресурсов:


Проверьте подпись образа оператора Ключ-АСТРОМ.
* '''Сервер веб-перехватчиков АппОптима''' только проверяет DynaKube и проверяет его правильность, не изменяя определения модулей.
* '''Драйвер АппОптима CSI''' обеспечивает доступное для записи объемное хранилище для ЕдиныйАгент.
* '''АппОптима АктивныйШлюз''' используется для маршрутизации, а также для мониторинга объектов Kubernetes путем сбора данных (метрики, события, статус) из Kubernetes API.
== Мониторинг только приложений (Application only): автоматический ввод ==
Вы можете использовать стратегию внедрения только для приложений для модулей приложений. Вы не устанавливаете модули ЕдиныйАгент и не можете собирать метрики узлов с узлов Kubernetes. Вы можете собирать альтернативные метрики узлов из других источников, таких как Prometheus .
 
Руководство по установке см. в разделе Автоматическая инъекция только для приложений .
 
'''Примечание.''' Если вы предпочитаете использовать Helm, см . раздел Настройка мониторинга Kubernetes/OpenShift с помощью Helm .
 
=== Возможности и ограничения ===
'''Возможности:'''
 
* Он разработан для Kubernetes. АппОптима внедряет данные в модули с помощью контроллера допуска Kubernetes, который внедряет модуль кода АппОптима в контейнеры приложений.
* Гибкость. Вы получаете детальный контроль над инструментированными модулями с помощью пространств имен и аннотаций. Вы можете легко направлять метрики pod в разные среды АппОптима в одном кластере Kubernetes.
 
'''Ограничения.''' При развертывании в режиме только для приложений ЕдиныйАгент отслеживает память, диск, ЦП и сетевые процессы только внутри контейнера. Показатели хоста не отслеживаются. Топология ограничена модулями и контейнерами.
 
=== Развернутые ресурсы ===
АппОптима Operator управляет автоматическим инжектированием только для приложений после развертывания следующих ресурсов.
 
* '''Сервер веб-перехватчиков АппОптима''' изменяет определения модулей, чтобы включить модули кода АппОптима для наблюдения за приложениями.
* '''АппОптима АктивныйШлюз''' используется для маршрутизации, а также для мониторинга объектов Kubernetes путем сбора данных (метрики, события, статус) из Kubernetes API.
== Мониторинг только приложений (Application only): внедрение модуля во время выполнения ==
Вы можете использовать стратегию внедрения только для приложений для модулей приложений. Вы не устанавливаете модули ЕдиныйАгент и не можете собирать метрики узлов с узлов Kubernetes. Вы можете собирать альтернативные метрики узлов из других источников, таких как Prometheus .
 
Руководство по установке см . в разделе Внедрение пода во время выполнения .
 
=== Возможности ===
 
* Это родной Kubernetes. Модули кода АппОптима внедряются в модули с помощью контейнеров инициализации Kubernetes.
* Гибкость. Различные образы контейнеров могут содержать отдельные конфигурации для разных сред АппОптима.
== Мониторинг только приложений (Application only): внедрение контейнера во время сборки ==
Вы можете использовать стратегию внедрения только для приложений для модулей приложений. Вы не устанавливаете модули ЕдиныйАгент и не можете собирать метрики узлов с узлов Kubernetes. Вы можете собирать альтернативные метрики узлов из других источников, таких как Prometheus .
 
Руководство по установке см. в разделе Внедрение контейнера во время сборки .
 
=== Возможности ===
 
* Он имеет инъекцию статического контейнера. Модули кода АппОптима встраиваются в образы контейнеров по мере их создания.
* Он гибкий. Различные образы контейнеров могут содержать отдельные конфигурации для разных сред АппОптима. Вы можете использовать эти образы на любой контейнерной платформе или PaaS в дополнение к Kubernetes.
== Классическое ручное инжектирование полного стека ==
Вы можете использовать классическую стратегию ручного внедрения полного стека для ручного развертывания ЕдиныйАгент DaemonSet и Kubernetes API без оператора АппОптима.
 
== Требования к хранению ==
В следующей таблице показаны требования к хранилищу для типов развертывания АппОптима Operator.
{| class="wikitable"
!Тип развертывания
!Без драйвера CSI
!С драйвером CSI<sup>1</sup>
!С драйвером CSI и изображением кодовых модулей
|-
|<code>classicFullStack</code>
|~1,3 ГБ для конфигурации/бинарных файлов ЕдиногоАгента<sup>2</sup> (непосредственно на узле)
|неприменимо
|неприменимо
|-
|<code>hostMonitoring</code>
|~1,3 ГБ для конфигурации/бинарных файлов ЕдиныйАгент<sup>2</sup> (непосредственно на узле)
|~1,3 ГБ для конфигурации/бинарных файлов ЕдиныйАгент<sup>2</sup> (на узле, управляемом драйвером CSI)
|неприменимо
|-
|<code>applicationMonitoring</code>
|~650 МБ на отслеживаемый модуль<sup>3</sup> (во временном хранилище, непосредственно на модуле)
| - ~650 МБ на одного арендатора и работающей версии ЕдиногоАгента<sup>4</sup>
- ~0,2 МБ (и логи во время выполнения) на внедренный модуль
| - ~650 МБ на работающий версии ЕдиногоАгента<sup>4</sup>
- ~0,2 МБ (и журналы во время выполнения) на внедренный модуль
|-
|<code>cloudNativeFullStack</code>
|неприменимо (требуется драйвер CSI)
|Комбинация из следующего:
- <code>hostMonitoring</code>с драйвером CSI
- <code>applicationMonitoring</code>с драйвером CSI
|Комбинация из следующего:
- <code>hostMonitoring</code>с драйвером CSI
- <code>applicationMonitoring</code>с драйвером CSI и образом модулей кода
|}
<sup>1</sup> Используется для поддержки файловой системы только для чтения (по умолчанию для мониторинга узлов и облачных развертываний с полным стеком).
 
<sup>2</sup> Новые версии ЕдиногоАгента перезаписывают старые версии ЕдиногоАгента.
 
<sup>3</sup> Если модуль уничтожен, ЕдиныйАгент автоматически удаляется.
 
<sup>4</sup> Сборщик мусора удаляет старые версии ЕдиногоАгента, которые больше не используются, в течение 60 минут.
 
== OKD ==
Обратите внимания на особенности мониторинга OKD.
 
В связи с особенностями работы операционной системы на которой развернут OKD кластер, необходимо убедиться, что все необходимые пререквизиты выполнены:
 
1)   Убедитесь, что на нодах, на которых будет развернут оператор '''SELinux''' переведен в режим '''permissive'''.

Текущая версия от 08:57, 8 января 2025

Установка и настройка / АппОптима разворачивается на / Контейнерных платформах / Kubernetes/OpenShift / Запуск мониторинга Kubernetes/OpenShift

Есть разные способы активировать АппОптима в Kubernetes/Openshift/OKD. Каждый способ имеет свои преимущества. Мы рекомендуем эти стратегии развертывания с точки зрения полноты функций и отсутствия ограничений.

Вы можете перейти с устаревшего оператора ЕдиныйАгент на новый оператор АппОптима, который управляет жизненным циклом нескольких компонентов АппОптима, таких как ЕдиныйАгент, маршрутизация и монитор API Kubernetes. Инструкции по миграции см. в разделе Миграция с оператора ЕдиныйАгент на оператор АппОптима в Kubernetes/OpenShift/OKD с помощью kubectl/oc .

Классическое инжектирование полного стека (Classic full-stack)

Рекомендации:

Руководство по установке см. в разделе Настройка мониторинга Kubernetes .

Примечание. Если вы предпочитаете использовать Helm, см . раздел Настройка мониторинга Kubernetes/OpenShift/OKD с помощью Helm .

Возможности и ограничения

Возможности:

  • Бесшовная интеграция с хостом (узлом Kubernetes). Инструментированные модули сохраняют свои таксономические отношения с хостами и метриками хостов. Агенты хоста дополняют модули кода обнаружением OOM, мониторингом дисков и хранилищ, мониторингом сети и т. д.
  • Всесторонность. Этот комплексный подход включает в себя мониторинг кластера Kubernetes, распределенную трассировку, изоляцию домена сбоя и глубокое понимание на уровне кода с использованием единой конфигурации развертывания для ваших кластеров.

Ограничения: существует зависимость запуска между контейнером, в котором развернут ЕдиныйАгент, и контейнерами приложений, которые должны быть инструментированы (например, контейнерами, в которых включен глубокий мониторинг процессов). Контейнер ЕдиногоАгента должен быть запущен, а oneagenthelperпроцесс должен быть запущен до запуска контейнера приложения, чтобы приложение могло быть правильно инструментировано.

Развернутые ресурсы

АппОптима Operator управляет классической инъекцией полного стека после развертывания следующих ресурсов.

  • ЕдиныйАгент , развернутый как DaemonSet, собирает метрики хоста с узлов Kubernetes. Он также обнаруживает новые контейнеры и внедряет модули кода ЕдиныйАгент в модули приложений.
  • АппОптима АктивныйШлюз используется для маршрутизации, а также для мониторинга объектов Kubernetes путем сбора данных (метрики, события, статус) из Kubernetes API.
  • Сервер веб-перехватчиков АппОптима проверяет правильность определений Dynakube.

Примечание. Для классического внедрения полного стека требуется доступ на запись из модуля ЕдиныйАгент к файловой системе узла Kubernetes для обнаружения и внедрения во вновь развернутые контейнеры.

Облачное внедрение полного стека (Cloud full-stack)

Руководство по установке см. в разделе Настройка мониторинга Kubernetes .

Примечание. Если вы предпочитаете использовать Helm, см . раздел Настройка мониторинга Kubernetes/OpenShift с помощью Helm .

Возможности и ограничения

Возможности:

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

Ограничения:

  • Файлы диагностики ("архивы поддержки") для модулей приложений пока не поддерживаются.
  • Правила мониторинга контейнеров пока не поддерживаются (параметр селектора меток Dynakube предоставляет аналогичную функциональность).
  • Сетевые зоны пока не поддерживаются.
  • Трассировка дополнительных модулей Istio и входных шлюзов, а также любых других экземпляров прокси-сервера Envoy не поддерживается.

Развернутые ресурсы

АппОптима Operator управляет облачной инъекцией полного стека после развертывания следующих развернутых ресурсов.

  • ЕдиныйАгент , развернутый как DaemonSet, собирает метрики хоста с узлов Kubernetes.
  • Сервер веб-перехватчиков АппОптима изменяет определения модулей, чтобы включить модули кода АппОптима для наблюдения за приложениями.
  • Драйвер АппОптима CSI, развернутый как DaemonSet, предоставляет доступное для записи хранилище томов для ЕдиныйАгент и двоичных файлов ЕдиныйАгент для модулей.
  • АппОптима АктивныйШлюз используется для маршрутизации, а также для мониторинга объектов Kubernetes путем сбора данных (метрики, события, статус) из Kubernetes API.

Мониторинг хоста

Руководство по установке см. в разделе Настройка мониторинга Kubernetes .

Примечание. Если вы предпочитаете использовать Helm, см . раздел Настройка мониторинга Kubernetes/OpenShift с помощью Helm .

Возможности и ограничения

Возможности: собирает метрики узлов и обрабатывает данные.

Ограничения. Диагностические файлы («архивы поддержки») для модулей приложений еще не поддерживаются для файловых систем, доступных только для чтения.

Развернутые ресурсы

АппОптима Operator управляет мониторингом хоста после развертывания следующих развернутых ресурсов:

  • Сервер веб-перехватчиков АппОптима только проверяет DynaKube и проверяет его правильность, не изменяя определения модулей.
  • Драйвер АппОптима CSI обеспечивает доступное для записи объемное хранилище для ЕдиныйАгент.
  • АппОптима АктивныйШлюз используется для маршрутизации, а также для мониторинга объектов Kubernetes путем сбора данных (метрики, события, статус) из Kubernetes API.

Мониторинг только приложений (Application only): автоматический ввод

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

Руководство по установке см. в разделе Автоматическая инъекция только для приложений .

Примечание. Если вы предпочитаете использовать Helm, см . раздел Настройка мониторинга Kubernetes/OpenShift с помощью Helm .

Возможности и ограничения

Возможности:

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

Ограничения. При развертывании в режиме только для приложений ЕдиныйАгент отслеживает память, диск, ЦП и сетевые процессы только внутри контейнера. Показатели хоста не отслеживаются. Топология ограничена модулями и контейнерами.

Развернутые ресурсы

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

  • Сервер веб-перехватчиков АппОптима изменяет определения модулей, чтобы включить модули кода АппОптима для наблюдения за приложениями.
  • АппОптима АктивныйШлюз используется для маршрутизации, а также для мониторинга объектов Kubernetes путем сбора данных (метрики, события, статус) из Kubernetes API.

Мониторинг только приложений (Application only): внедрение модуля во время выполнения

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

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

Возможности

  • Это родной Kubernetes. Модули кода АппОптима внедряются в модули с помощью контейнеров инициализации Kubernetes.
  • Гибкость. Различные образы контейнеров могут содержать отдельные конфигурации для разных сред АппОптима.

Мониторинг только приложений (Application only): внедрение контейнера во время сборки

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

Руководство по установке см. в разделе Внедрение контейнера во время сборки .

Возможности

  • Он имеет инъекцию статического контейнера. Модули кода АппОптима встраиваются в образы контейнеров по мере их создания.
  • Он гибкий. Различные образы контейнеров могут содержать отдельные конфигурации для разных сред АппОптима. Вы можете использовать эти образы на любой контейнерной платформе или PaaS в дополнение к Kubernetes.

Классическое ручное инжектирование полного стека

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

Требования к хранению

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

Тип развертывания Без драйвера CSI С драйвером CSI1 С драйвером CSI и изображением кодовых модулей
classicFullStack ~1,3 ГБ для конфигурации/бинарных файлов ЕдиногоАгента2 (непосредственно на узле) неприменимо неприменимо
hostMonitoring ~1,3 ГБ для конфигурации/бинарных файлов ЕдиныйАгент2 (непосредственно на узле) ~1,3 ГБ для конфигурации/бинарных файлов ЕдиныйАгент2 (на узле, управляемом драйвером CSI) неприменимо
applicationMonitoring ~650 МБ на отслеживаемый модуль3 (во временном хранилище, непосредственно на модуле) - ~650 МБ на одного арендатора и работающей версии ЕдиногоАгента4

- ~0,2 МБ (и логи во время выполнения) на внедренный модуль

- ~650 МБ на работающий версии ЕдиногоАгента4

- ~0,2 МБ (и журналы во время выполнения) на внедренный модуль

cloudNativeFullStack неприменимо (требуется драйвер CSI) Комбинация из следующего:

- hostMonitoringс драйвером CSI - applicationMonitoringс драйвером CSI

Комбинация из следующего:

- hostMonitoringс драйвером CSI - applicationMonitoringс драйвером CSI и образом модулей кода

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

2 Новые версии ЕдиногоАгента перезаписывают старые версии ЕдиногоАгента.

3 Если модуль уничтожен, ЕдиныйАгент автоматически удаляется.

4 Сборщик мусора удаляет старые версии ЕдиногоАгента, которые больше не используются, в течение 60 минут.

OKD

Обратите внимания на особенности мониторинга OKD.

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

1)   Убедитесь, что на нодах, на которых будет развернут оператор SELinux переведен в режим permissive.