Совместимость и ограничения

Что нужно агенту для работы и о чём его данные могут, а о чём не могут говорить.

Поддерживаемая платформа агента

Поддерживаемая база: Kubernetes 1.32 или новее, containerd 2.x через CRI, cgroup v2 в единой иерархии, Linux 6.1 LTS или новее с BTF и узлы x86_64. Владение нагрузкой должно идти по цепочке Pod → ReplicaSet → Deployment. То, что серверные образы собираются под ARM64, ничего не говорит об агенте: это отдельный вопрос, и ответ на него отрицательный.

Проверки ниже выполняются на предполагаемом узле Linux, но покрывают лишь часть условий: версии Kubernetes и runtime, права на подключение зондов и цепочку владения нагрузкой оператор проверяет отдельно. Другие runtime, cgroup v1, неподдерживаемые владельцы и ужесточённые конфигурации управляемых узлов как поддерживаемые не заявлены: они могут заработать, но обещаний тут нет.

test -e /sys/kernel/btf/vmlinux
test "$(stat -fc %T /sys/fs/cgroup)" = cgroup2fs
uname -m

Включение функций и ограничения ресурсов

Каждым профилем наблюдения управляет конфигурация. processExec задаётся явно; processExit при отсутствии равен false. В парсере сетевые connect, listen и accept, а также DNS по умолчанию отключены — но эталонное развёртывание включает несколько сетевых зондов, так что пример и значение по умолчанию — не одно и то же. Файловое наблюдение выключено и экспериментально. Если сомневаетесь, посмотрите тот ConfigMap, который работает у вас.

Сбор ограничен сразу с нескольких сторон: ёмкостью очереди, размером пакета, числом событий в секунду и количеством потоков приложений на одного агента. У DNS есть свои пределы на транзакции, сборку потоков и захваченные байты, а у входящего accept — отдельное ограничение скорости. Если обязательный зонд не удаётся подключить, агент честно остаётся неготовым. Следите за счётчиками потерь и заполнения и измеряйте собственную нагрузку: универсальной цифры накладных расходов нет, как нет и гарантии полноты.

Сбор жизненного цикла потоков ограничен ёмкостью состояния процессов и задач, корзин имён, размером снимка и числом возвращаемых окон. Имена сверх лимита процесса учитываются в строке Другие имена потоков и отражаются счётчиком переполнения. Поздно подключившийся наблюдатель может инициализировать активные потоки ограниченным снимком /proc, но такой снимок не восстанавливает более раннюю историю создания и переименований. Если снимок недоступен, столкнулся с гонкой или усечён, либо возникли потери ядра, декодирования, привязки, ёмкости или доставки, API помечает начальное состояние или окно неполным. Ограниченная сводка также может получить признак truncated; её значения являются нижними границами, а не нулями или точными итогами за весь срок жизни.

Активность потоков требует миграции базы данных сервера 32 и совместимого агента наблюдения, объявляющего task.lifecycle/v1. Установки с уже применённой миграцией 31 сохраняют записанные окна при обновлении до миграции 32. Более ранние агенты не восстанавливают историческую активность потоков. Для сбора создания, переименования и завершения задач включите observation.processExit; task.lifecycle/v1 объявляется только после успешной загрузки и подключения всех обязательных зондов ядра. processExec независимо управляет наблюдением выполнения программ. По умолчанию API выбирает последний час; явный период может охватывать не более 31 дня. Окна активности потоков подчиняются действующему сроку хранения сырых событий проекта. Истёкшие окна удаляются; отдельного исторического снимка для восстановления их счётчиков нет. Счётчики созданных и завершённых потоков охватывают выбранные окна, включая группировку по наблюдавшемуся имени. Число активных потоков по именам и наблюдавшийся пик доступны только для одного квалифицированного процесса и эпохи наблюдения; при нескольких процессах или эпохах сводка сообщает, что значения недоступны, вместо сложения несовместимых снимков. Разрывы наблюдения и усечение делают счётчики создания и завершения нижними границами; неполное начальное состояние также влияет на активное число и пик.

Границы выводов

Попытка connect не всегда заканчивается соединением. Совпадение с DNS — это подходящее по времени наблюдение, а не доказательство причины; зашифрованный, закэшированный или просто не совпавший DNS оставляет IP без имени. Файловые пути описывают аргументы поддерживаемых вызовов, а не каждое изменение в файловой системе. А один SIGKILL не доказывает, что процесс убили из-за памяти.

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

Читайте также

• Ресурсы приложения
• Okoscope Cloud — Быстрый старт
• Возможности
• Данные и безопасность