Возможности

Что даёт каждый вид наблюдений и когда его стоит включать.

Сначала проверьте состояние наблюдения

Страница приложения показывает, получает ли Okoscope runtime-события, сколько узлов сообщает состояние, а также время первого и последнего принятого события. Если данных нет, она различает аутентификацию, совпадение нагрузки, разрешения Kubernetes, поддержку ядра, ожидание трафика, устаревшие отчёты и отозванный credential и предлагает следующую проверку для каждого состояния.

Недавний сигнал агента означает только, что сервер слышал этот узел в пределах опубликованного окна свежести. Это не гарантирует, что stream подключён прямо сейчас, а capability или heartbeat не доказывает, что соответствующее событие наблюдалось. Если состояние не удаётся обновить, страница сохраняет timestamps, но помечает свежесть неизвестной вместо догадки.

Карточки агентов хранят ограниченную историю heartbeat за 1, 6 или 24 часа. Диаграмма различает полученные сигналы, пропуски внутри известного покрытия и историю, недоступную до начала сбора или за пределами хранения; пробелы не интерполируются. Полный поддерживаемый набор capability всегда показан одной строкой иконок: заявленные возможности выделены, неактивные показаны серым, а локализованное название каждой иконки доступно при наведении или фокусе с клавиатуры. Эти состояния описывают только то, что заявил агент. Принятые события приложения показаны отдельно, поэтому сообщающий данные агент без событий остаётся видимым и ссылается на объяснение readiness.

Диагностика приложения показывает положительные изменения за выбранный период, а не значения за всё время. В неё входят только потери и результаты доставки, отнесённые к аутентифицированному потоку выбранной нагрузки: например, заполнение очереди маршрута, ограничение частоты или повтор доставки. Сбросы отмечаются отдельно для маршрута этого приложения. Ошибки до атрибуции нагрузки и другая диагностика всего узла остаются в логах агента и внутренней телеметрии оператора и никогда не проецируются на приложение. Каждый принятый heartbeat обязан содержать снимок диагностики приложения; несовместимые агенты отклоняются и не создают неоднозначное состояние совместимости в интерфейсе. История здоровья хранится не менее 25 часов, а ответ ограничен 20 агентами и не более чем 96 интервалами на агента.

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

Процессы, системные вызовы и завершения

В «Активности приложения» три факта о процессе показаны отдельно: процесс создан означает, что ядро наблюдало создание нового процесса; программа выполнена — что существующий процесс загрузил исполняемый образ; процесс завершён — что завершившаяся задача была классифицирована как лидер процесса. Поэтому exec не называется созданием процесса. Исторические завершения, записанные до появления классификации задач, остаются видимыми как задача завершена (устаревшая классификация) и не утверждают, что завершился лидер процесса.

Наблюдение выполнения программ показывает, какие исполняемые файлы работали внутри выбранных нагрузок. Если нужны и завершения, включите processExit, а системные вызовы перечислите явно — например, ptrace и setns. Это профиль, который вы настраиваете сами, а не запись всех системных вызовов подряд.

Выберите отдельную категорию Потоки в «Активности приложения», чтобы изучить изменения потоков без сохранения каждого потока как отдельной идентичности инвентаря. Это представление относится ко всему приложению и отделено от видов инвентаря, поэтому состояние политики инвентаря, поиск по идентичности и фильтры поведения к нему не применяются. Для выбранного периода панель сообщает, сколько потоков создано и завершено, сколько активно в конце и каков был пик, а счётчики создания и завершения группирует по наблюдавшемуся имени Linux-потока. Ограниченная строка Другие имена потоков и уведомление о переполнении не дают числу имён расти без границ. Панель также сообщает, получено ли начальное число активных потоков из наблюдаемого создания процесса, снимка /proc или оно недоступно. Гонки снимка, пробелы сбора или доставки, неполное начальное состояние и усечённый ограниченный результат превращают затронутые значения в нижние границы; интерфейс явно пишет Не менее, а не выдаёт их за точные.

Веб-клиент читает эти ограниченные некэшируемые представления из GET /api/v1/projects/{project_id}/applications/{application_id}/thread-activity и GET /api/v1/projects/{project_id}/applications/{application_id}/thread-activity/summary. Оба маршрута принимают явный период from/to, а маршрут окон использует пагинацию с непрозрачным cursor. Имена и счётчики потоков не становятся группами событий, политиками, подавлениями, уведомлениями или идентичностями исполняемых файлов в инвентаре.

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

Инвентаризация приложения объединяет одинаковый системный вызов от разных Linux-потоков. Команду исходного процесса можно увидеть в каждом сохранённом сыром наблюдении. Группы событий остаются привязанными к процессу; создание процесса, выполнение программы и классифицированное завершение процесса остаются разными фактами жизненного цикла.

Представления завершений и перезапусков показывают рядом данные ядра и Kubernetes: процесс, контейнер, к которому он относился, код выхода или сигнал, указанную причину и связанные наблюдения. Смотрите на них вместе. Сам по себе SIGKILL не означает, что процесс убили из-за памяти: для такого вывода нужны прямые подтверждения. И перезапуск контейнера — это не то же самое, что завершение дочернего процесса.

Исходящая сеть, входящая сеть и DNS

Исходящие наблюдения connect дают адрес и порт назначения, семейство адресов и результат системного вызова. О транспорте они ничего не говорят, поэтому не вычитывайте из них TCP или UDP, а сама попытка ещё не означает установленного соединения. Наблюдения listen и accept включаются отдельно и описывают другое направление: слушающие точки TCP и принятую входящую активность. Прежде чем сравнивать наблюдения между собой, посмотрите, какое направление описывает каждое.

DNS по умолчанию выключен. Если включить, вы получите ограниченные наблюдения открытого трафика UDP и TCP на порту 53: имена, адреса A и AAAA, связи CNAME, код ответа и TTL. Недавний совпавший ответ может подписать соединение именем — это удобно, но за одним общим IP может стоять несколько имён, а совпадение по времени не доказывает причинной связи. Зашифрованный DNS остаётся зашифрованным, а имя по обратному запросу Okoscope не подставляет.

В инвентаризации приложения одна исходящая точка назначения или точная DNS-идентичность показывается один раз, даже если её наблюдали от нескольких Linux-потоков. Для DNS в основном списке видны записанное имя запроса и тип A или AAAA; у каждой идентичности остаются собственная история наблюдений, состояние политики, фильтры и пагинация. Только верхний некликабельный обзор объединяет связанные запросы резолвера в логические назначения, чтобы варианты поискового расширения Kubernetes не вытесняли другие часто наблюдаемые назначения. Группы в обзоре не меняют поиск или фильтр идентичности списка, а точные запросы ниже остаются отдельными записанными идентичностями.

Экспериментальная файловая активность

Наблюдение файлов включается отдельно, и настроить его придётся самостоятельно: выбрать операции и задать хотя бы один нормализованный абсолютный префикс включения. Исключения всегда важнее включений. Профиль syscall-path сообщает об успешных поддерживаемых операциях, опираясь на пути, которые передал сам процесс, и на сохранённые соответствия дескрипторов. Содержимое файлов он не читает и каноническую идентичность inode не определяет.

Относительные пути, псевдонимы символических ссылок и записи через mmap этот профиль полнотой не покрывает. Изменения объединяются в фиксированном окне в пять секунд, поэтому частые записи схлопываются в одно наблюдение. Успешный open с O_CREAT ещё не доказывает, что файл создан: доказывает только сочетание O_CREAT и O_EXCL. Начните с одного узкого пути, где нет чувствительных данных.

Одинаковые файловые операции над одним переданным путём объединяются в инвентаризации приложения между потоками процесса. Команда-источник сохраняется в подробностях наблюдения.

observation:
  files:
    enabled: true
    operations: [create, modify, delete, rename]
    includePaths: [/app/data]
    excludePaths: [/app/data/private]

Инвентаризация, релизы, политики и уведомления

Инвентаризация — это место, где можно просмотреть увиденное: исполняемые файлы, сетевые объекты, пути — вместе с сохранившимися подтверждениями. Сравнение релизов ставит базовую версию рядом с целевой и показывает, чем отличается их поведение; там, где история истекла, ответом будет «неизвестно», а не «не было». Поэтому сначала смотрите на покрытие и только потом решайте, что означает отсутствующее поведение.

Любому поведению из инвентаря можно задать название в контексте приложения — будь то процесс, соединение, домен, системный вызов, файловая операция или событие жизненного цикла. Например, наблюдаемое направление можно назвать Подключение к базе, а процесс — Фоновый обработчик заявок. Название является пользовательской интерпретацией: Okoscope всегда показывает под ним каноническую техническую идентичность, а именование не меняет данные агента, группировку, счётчики и вычисление политик. Названия относятся к одному приложению, могут повторяться, участвуют в поиске по инвентарю и сохраняются после истечения старых исходных данных. Изменившаяся техническая идентичность или новая версия identity не наследует название автоматически.

Откройте карточку инвентаря или её историю наблюдений и нажмите Добавить название. Создавать, изменять и удалять названия может любой вошедший пользователь с доступом к проекту. Название должно содержать от 1 до 120 символов без управляющих символов. Параллельные изменения обнаруживаются; при конфликте проверьте загруженное актуальное значение перед повторной попыткой.

Политики фиксируют, как вы решили относиться к поведению при разборе. Это инструмент анализа: они не ставят межсетевой экран в ядре и не блокируют системные вызовы. Уведомления проекта пересылают поддерживаемые находки настроенным получателям. Доставка учитывается отдельно от самой находки, поэтому смотрите запись доставки и её попытки: событие в интерфейсе ещё не значит, что webhook дошёл.

«Активность приложения»: наблюдаемое поведение по видам и наиболее часто наблюдаемые DNS-запросы примерного приложения.

Инвентарь просматривают в «Активности приложения». Доли описывают записанные наблюдения, а не объём трафика или риск.