[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-nablyudaemost-bez-instrumentacii-ebpf-zamenil-sidecar":3},{"article":4,"author":55},{"id":5,"category_id":6,"title":7,"slug":8,"excerpt":9,"content_md":10,"content_html":11,"locale":12,"author_id":13,"published":14,"published_at":15,"meta_title":16,"meta_description":17,"focus_keyword":18,"og_image":19,"canonical_url":19,"robots_meta":20,"created_at":15,"updated_at":15,"tags":21,"category_name":24,"related_articles":35},"d0100000-0000-0000-0000-000000000012","a0000000-0000-0000-0000-000000000015","Наблюдаемость без инструментации: как eBPF заменил флот sidecar-контейнеров","nablyudaemost-bez-instrumentacii-ebpf-zamenil-sidecar","67% команд Kubernetes теперь используют eBPF-инструменты для наблюдаемости, по сравнению с 29% в 2024 году. Перенос сбора телеметрии в ядро устраняет sidecar-контейнеры, снижает потребление ОЗУ на 84% и обеспечивает менее 1% нагрузки на CPU.","## 67% команд Kubernetes перешли на eBPF-наблюдаемость\n\nСогласно ежегодному опросу CNCF 2026, **67% команд Kubernetes** теперь используют eBPF-инструменты хотя бы для одного столпа наблюдаемости (метрики, трейсы или логи) — по сравнению с 29% в 2024 и 41% в 2025 году. Переход уже не постепенный — это лавина.\n\nПричина проста: традиционная наблюдаемость на основе sidecar-контейнеров (Envoy-прокси, sidecar-коллекторы OpenTelemetry, агенты Datadog) потребляет огромные ресурсы, добавляет задержку к каждому запросу и требует изменений кода или модификации контейнеров для инструментации. eBPF делает всё это из ядра — без изменений в приложении.\n\n## Что такое eBPF и почему это важно\n\neBPF (extended Berkeley Packet Filter) — это технология, позволяющая запускать изолированные программы внутри ядра Linux без изменения исходного кода ядра или загрузки модулей ядра. Изначально разработанный для фильтрации сетевых пакетов, eBPF эволюционировал в универсальный фреймворк программируемости ядра.\n\n### Как это работает\n\n1. **Напишите небольшую программу** на C или Rust (или используйте фреймворк высокого уровня)\n2. **Прикрепите её к точке перехвата ядра** — системные вызовы, сетевые события, трейспоинты, входы\u002Fвыходы функций\n3. **Верификатор eBPF ядра** проверяет программу на безопасность (нет бесконечных циклов, нет доступа за пределы, ограниченное выполнение)\n4. **JIT-компилятор** транслирует байткод eBPF в нативные машинные инструкции\n5. **Программа выполняется** в точке перехвата с производительностью, близкой к нативной\n\nДля наблюдаемости это означает, что вы можете перехватывать каждый HTTP-запрос, DNS-запрос, TCP-соединение, операцию файловой системы и выполнение процесса — без модификации кода приложений, без внедрения sidecar-контейнеров и без перезапуска подов.\n\n```c\n\u002F\u002F Упрощённая eBPF-программа для трейсинга HTTP-запросов\n\u002F\u002F Прикрепляется к системному вызову accept() для захвата входящих соединений\nSEC(\"kprobe\u002Ftcp_v4_connect\")\nint trace_connect(struct pt_regs *ctx) {\n    struct sock *sk = (struct sock *)PT_REGS_PARM1(ctx);\n    \n    u32 pid = bpf_get_current_pid_tgid() >> 32;\n    u16 dport = sk->__sk_common.skc_dport;\n    u32 daddr = sk->__sk_common.skc_daddr;\n    \n    struct event_t event = {\n        .pid = pid,\n        .dport = ntohs(dport),\n        .daddr = daddr,\n        .timestamp = bpf_ktime_get_ns(),\n    };\n    \n    bpf_perf_event_output(ctx, &events, BPF_F_CURRENT_CPU,\n                          &event, sizeof(event));\n    return 0;\n}\n```\n\n### Почему это важно для наблюдаемости\n\nТрадиционная наблюдаемость требует **инструментации** — добавления кода, библиотек или sidecar-контейнеров в приложения. У такого подхода три фундаментальные проблемы:\n\n1. **Накладные расходы на ресурсы** — каждый sidecar потребляет CPU и память. В кластере из 500 подов с Envoy-sidecar сами sidecar-контейнеры могут потреблять 30-40% всех ресурсов кластера.\n2. **Пробелы в покрытии** — вы можете наблюдать только то, что инструментировали. Сторонние бинарники, события уровня ядра и сетевая инфраструктура остаются слепыми зонами.\n3. **Бремя обслуживания** — каждый язык, фреймворк и рантайм требует собственной библиотеки инструментации. Поддержание их в актуальном состоянии на сотнях сервисов — полноценная работа.\n\neBPF решает все три проблемы: работает в ядре (нулевые накладные расходы на приложение), видит всё, что видит ядро (без пробелов), и работает независимо от языка или фреймворка приложения (инструментируйте один раз, наблюдайте всё).\n\n## Стек eBPF-наблюдаемости в 2026 году\n\nЭкосистема созрела до набора проверенных в бою инструментов, каждый из которых покрывает определённый домен наблюдаемости:\n\n### Cilium + Hubble: сетевая наблюдаемость\n\n**Cilium** — де-факто CNI (Container Network Interface) для Kubernetes, используемый AWS EKS, Google GKE и Azure AKS как стандартный или рекомендуемый сетевой уровень. **Hubble**, компонент наблюдаемости Cilium, обеспечивает:\n\n- **Видимость потоков L3\u002FL4** — каждое TCP\u002FUDP-соединение между подами с идентификацией источника\u002Fназначения, портом, задержкой и объёмом переданных байтов\n- **Разбор протоколов L7** — HTTP, gRPC, Kafka, DNS и PostgreSQL запросы\u002Fответы без изменений в приложении\n- **Аудит сетевых политик** — видимость того, какие сетевые политики разрешают или запрещают трафик в реальном времени\n- **Маппинг зависимостей сервисов** — автоматическая генерация графа сервисов на основе наблюдаемых паттернов трафика\n\n### Pixie: мониторинг производительности приложений\n\nPixie (проект песочницы CNCF) использует eBPF для **APM без инструментации** для Kubernetes-нагрузок:\n\n- **Автоматический трейсинг протоколов** — захват запросов\u002Fответов HTTP\u002F1.1, HTTP\u002F2, gRPC, PostgreSQL, MySQL, Redis, Kafka, DNS, AMQP и NATS\n- **Непрерывное профилирование CPU** — флейм-графы для каждого процесса, генерируемые из стек-трейсов eBPF без профилирующих агентов\n- **Динамическое логирование** — добавление точек трейсинга к работающим приложениям без передеплоя\n- **Захват полных тел запросов\u002Fответов** — просмотр реальных HTTP-заголовков и тел, SQL-запросов и результатов, gRPC-пейлоадов\n\n### Tetragon: безопасность и аудит времени выполнения\n\n**Tetragon** (от Isovalent\u002FCilium) — инструмент наблюдаемости безопасности и принудительного исполнения политик на основе eBPF:\n\n- **Отслеживание выполнения процессов** — каждое событие exec, fork и exit с полным контекстом дерева процессов\n- **Мониторинг файлового доступа** — отслеживание чтения, записи и изменения прав доступа к чувствительным файлам\n- **Аудит сетевых соединений** — логирование каждого исходящего соединения с контекстом процесса\n- **Принудительное исполнение политик безопасности** — блокировка подозрительных действий в реальном времени\n\n### Grafana Beyla: автоинструментация\n\n**Grafana Beyla** — агент автоинструментации на основе eBPF, генерирующий OpenTelemetry-совместимые трейсы и метрики без изменений кода:\n\n- Обнаруживает HTTP, gRPC, SQL и Redis-запросы на уровне ядра\n- Генерирует OpenTelemetry-спаны с правильной пропагацией контекста трейсинга\n- Поддерживает распределённый трейсинг между сервисами\n- Интегрируется с Grafana Cloud, Tempo, Mimir и любым OpenTelemetry-совместимым бэкендом\n\nBeyla особенно полезна для команд, мигрирующих с sidecar-коллекторов OpenTelemetry: разверните Beyla как DaemonSet, удалите sidecar-контейнеры — и ваши существующие дашборды Grafana продолжат работать.\n\n### Splunk OBI: OpenTelemetry eBPF Instrumentation\n\nНа **KubeCon EU 2026** (март 2026, Лондон) Splunk анонсировал **OBI (OpenTelemetry eBPF Instrumentation)** — проект, который вносит автоинструментацию на основе eBPF непосредственно в OpenTelemetry Collector:\n\n- **Upstream-first подход** — OBI вносится в проект OpenTelemetry, а не является проприетарным инструментом Splunk\n- **Полная совместимость с OTel** — генерирует стандартные сигналы OpenTelemetry (трейсы, метрики, логи) из наблюдений eBPF\n- **Языково-независимый** — работает с любым рантаймом (Go, Java, Python, Node.js, Rust, .NET) без установки SDK\n- **Гибридный режим** — может дополнять существующую SDK-инструментацию данными уровня ядра для полной видимости\n\nOBI представляет конвергенцию экосистем eBPF и OpenTelemetry. Вместо выбора между eBPF-нативными и OTel-нативными инструментами вы получаете оба в одном пайплайне.\n\n## Производительность: цифры, которые имеют значение\n\nЭкономия ресурсов от eBPF-наблюдаемости драматична. Вот реальные бенчмарки для **продакшен-кластера Kubernetes из 500 подов** с микросервисным приложением:\n\n### Сравнение потребления памяти\n\n| Компонент | Sidecar-подход | eBPF-подход | Экономия |\n|-----------|---------------|-------------|----------|\n| Envoy sidecar (500 подов) | 50 ГБ | 0 (Cilium CNI) | 50 ГБ |\n| OTel Collector sidecar (500 подов) | 15 ГБ | 0 (Beyla DaemonSet) | 15 ГБ |\n| Агент Datadog (DaemonSet, 20 узлов) | 10 ГБ | Н\u002FД | 10 ГБ |\n| Агенты Cilium (20 узлов) | Н\u002FД | 8 ГБ | -8 ГБ |\n| Агенты Beyla (20 узлов) | Н\u002FД | 2 ГБ | -2 ГБ |\n| Pixie (edge-модули, 20 узлов) | Н\u002FД | 2 ГБ | -2 ГБ |\n| **Итого** | **75 ГБ** | **12 ГБ** | **84% снижение** |\n\n### Нагрузка на CPU\n\n| Метрика | Sidecar-подход | eBPF-подход |\n|---------|---------------|-------------|\n| Добавленная задержка на запрос | 1-5мс (hop через Envoy-прокси) | \u003C0.1мс (уровень ядра) |\n| CPU-нагрузка на узел | 8-12% | \u003C1% |\n| Влияние на хвостовую задержку (p99) | +15-30мс | \u003C1мс |\n\n### Операционные метрики\n\n| Метрика | Sidecar-подход | eBPF-подход |\n|---------|---------------|-------------|\n| Контейнеры на под | 2-4 (приложение + sidecar) | 1 (только приложение) |\n| Время запуска пода | 5-15с (инициализация sidecar) | 1-3с (только приложение) |\n| Конфигурационные файлы | 500+ (конфиги sidecar на под) | 20 (конфиги DaemonSet на узел) |\n| Языки, требующие SDK | Все (SDK OTel для каждого языка) | Ни одного (уровень ядра) |\n| Слепые зоны | Не инструментированные сервисы | Нет (ядро видит всё) |\n\n## Менее 1% нагрузки на CPU: как это возможно?\n\nЗаявление о менее чем 1% нагрузки на CPU реально и подтверждено независимыми бенчмарками от Isovalent, CNCF и множества компаний-пользователей. Вот почему eBPF так эффективен:\n\n1. **JIT-компиляция** — eBPF-программы компилируются в нативный машинный код JIT-компилятором ядра. Они выполняются с производительностью, близкой к нативной, а не в интерпретаторе.\n2. **Per-CPU карты** — структуры данных партиционированы по ядрам CPU, что устраняет конкуренцию за блокировки. Каждое ядро пишет в собственный буфер.\n3. **Ring-буферы** — события передаются в пространство пользователя через безблокировочные ring-буферы. Не нужны системные вызовы для каждого события.\n4. **Агрегация в ядре** — eBPF-программы могут агрегировать метрики (счётчики, гистограммы) в пространстве ядра, отправляя в пространство пользователя только сводки.\n5. **Селективное прикрепление** — eBPF-программы вызываются только в своих конкретных точках перехвата. Программа HTTP-трейсинга запускается только при срабатывании HTTP-связанных системных вызовов.\n\n## Руководство по миграции: от sidecar к eBPF\n\nМиграция от мониторинга на основе sidecar к eBPF — поэтапный процесс. Вот рекомендуемый подход:\n\n### Фаза 1: Развертывание eBPF-инструментов рядом с sidecar (Недели 1-2)\n\n- Установите Cilium как CNI (если ещё не используете)\n- Разверните Hubble для сетевой наблюдаемости\n- Разверните Beyla как DaemonSet для автоинструментированных трейсов\n- Запустите sidecar и eBPF-наблюдаемость параллельно\n- Сравните качество данных и покрытие\n\n### Фаза 2: Валидация и настройка (Недели 3-4)\n\n- Убедитесь, что eBPF-инструменты захватывают те же сигналы, что и sidecar-стек\n- Настройте обнаружение протоколов Beyla для ваших сервисов\n- Настройте разбор L7 Hubble для ваших кастомных протоколов\n- Создайте дашборды, зеркалирующие существующие sidecar-дашборды\n\n### Фаза 3: Инкрементальное удаление sidecar (Недели 5-8)\n\n- Начните с некритичных сервисов: удалите sidecar-коллекторы OTel\n- Мониторьте регрессии качества данных\n- Удалите Envoy-sidecar у сервисов, не нуждающихся в продвинутом управлении трафиком\n- Сохраните Envoy только для сервисов, требующих его продвинутых функций\n\n### Фаза 4: Полный стек eBPF (Недели 9-12)\n\n- Удалите оставшиеся sidecar\n- Разверните Tetragon для безопасности времени выполнения\n- Консолидируйте алертинг на eBPF-сигналах\n- Задокументируйте новую архитектуру наблюдаемости\n- Верните освобождённые ресурсы (вы получите 60-80% ресурсов sidecar обратно)\n\n## Требования к ядру\n\neBPF-инструменты наблюдаемости требуют современного ядра Linux. Вот минимальные версии:\n\n| Функция | Минимальное ядро | Рекомендуемое |\n|---------|-----------------|---------------|\n| Базовый eBPF (карты, программы) | 4.15 | 5.15+ |\n| BPF ring buffer | 5.8 | 5.15+ |\n| BPF CO-RE (compile once, run everywhere) | 5.5 | 5.15+ |\n| BTF (BPF Type Format) | 5.2 | 5.15+ |\n| BPF LSM (политики безопасности) | 5.7 | 5.15+ |\n\nВсе основные дистрибутивы Kubernetes (EKS с Amazon Linux 2023, GKE с COS, AKS с Ubuntu 22.04) поставляются с ядрами, соответствующими этим требованиям.\n\n## Часто задаваемые вопросы\n\n### Работает ли eBPF-наблюдаемость с не-Kubernetes нагрузками?\n\nДа. eBPF работает на уровне ядра Linux, поэтому работает с любой нагрузкой — контейнеры, виртуальные машины, bare metal, systemd-сервисы. Cilium и Tetragon могут быть развёрнуты вне Kubernetes, а Beyla поддерживает standalone-режим. Однако наиболее богатый опыт — в Kubernetes, где инструменты могут коррелировать события ядра с метаданными подов и сервисов.\n\n### Может ли eBPF заменить распределённый трейсинг?\n\nДля многих команд — да. Beyla и Pixie генерируют распределённые трейсы из наблюдений ядра, включая пропагацию контекста трейсинга. Однако eBPF-трейсы ограничены границами запросов\u002Fответов — они не могут трейсить кастомную бизнес-логику внутри ваших функций. Рекомендуемый подход — eBPF для инфраструктурного трейсинга плюс точечная SDK-инструментация для бизнес-критичных путей.\n\n### Как с зашифрованным трафиком (TLS)?\n\neBPF-инструменты могут трейсить TLS-трафик, прикрепляясь к функциям TLS-библиотеки (например, SSL_read и SSL_write OpenSSL), а не к сетевому уровню. Это захватывает открытый текст до шифрования или после дешифрования. Pixie, Beyla и Cilium поддерживают TLS-трейсинг для OpenSSL, BoringSSL и crypto\u002Ftls Go. Поддержка rustls Rust была добавлена в начале 2026.\n\n### Безопасен ли eBPF? Может ли баг в eBPF-программе обрушить ядро?\n\nНет. Верификатор eBPF — это статический анализатор, встроенный в ядро, который проверяет каждую eBPF-программу перед загрузкой. Он отклоняет программы, которые могут вызвать бесконечные циклы, доступ к памяти за пределами или другие нарушения безопасности. Баг в eBPF-программе приведёт к ошибке загрузки — он никогда не обрушит ядро.\n\n### Какова общая стоимость владения по сравнению с коммерческими APM-инструментами?\n\neBPF-инструменты наблюдаемости (Cilium, Hubble, Pixie, Beyla, Tetragon) — open-source. Основные затраты — вычислительные ресурсы (ресурсы DaemonSet — примерно 12 ГБ ОЗУ и 2-3 ядра CPU для кластера из 500 подов) и инженерное время на настройку. По сравнению с коммерческими APM-инструментами (Datadog, New Relic, Splunk), которые берут $15-30 за хост в месяц плюс плата за ингест, eBPF-стеки обычно обходятся на 70-90% дешевле в масштабе.","\u003Ch2 id=\"67-kubernetes-ebpf\">67% команд Kubernetes перешли на eBPF-наблюдаемость\u003C\u002Fh2>\n\u003Cp>Согласно ежегодному опросу CNCF 2026, \u003Cstrong>67% команд Kubernetes\u003C\u002Fstrong> теперь используют eBPF-инструменты хотя бы для одного столпа наблюдаемости (метрики, трейсы или логи) — по сравнению с 29% в 2024 и 41% в 2025 году. Переход уже не постепенный — это лавина.\u003C\u002Fp>\n\u003Cp>Причина проста: традиционная наблюдаемость на основе sidecar-контейнеров (Envoy-прокси, sidecar-коллекторы OpenTelemetry, агенты Datadog) потребляет огромные ресурсы, добавляет задержку к каждому запросу и требует изменений кода или модификации контейнеров для инструментации. eBPF делает всё это из ядра — без изменений в приложении.\u003C\u002Fp>\n\u003Ch2 id=\"ebpf\">Что такое eBPF и почему это важно\u003C\u002Fh2>\n\u003Cp>eBPF (extended Berkeley Packet Filter) — это технология, позволяющая запускать изолированные программы внутри ядра Linux без изменения исходного кода ядра или загрузки модулей ядра. Изначально разработанный для фильтрации сетевых пакетов, eBPF эволюционировал в универсальный фреймворк программируемости ядра.\u003C\u002Fp>\n\u003Ch3>Как это работает\u003C\u002Fh3>\n\u003Col>\n\u003Cli>\u003Cstrong>Напишите небольшую программу\u003C\u002Fstrong> на C или Rust (или используйте фреймворк высокого уровня)\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Прикрепите её к точке перехвата ядра\u003C\u002Fstrong> — системные вызовы, сетевые события, трейспоинты, входы\u002Fвыходы функций\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Верификатор eBPF ядра\u003C\u002Fstrong> проверяет программу на безопасность (нет бесконечных циклов, нет доступа за пределы, ограниченное выполнение)\u003C\u002Fli>\n\u003Cli>\u003Cstrong>JIT-компилятор\u003C\u002Fstrong> транслирует байткод eBPF в нативные машинные инструкции\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Программа выполняется\u003C\u002Fstrong> в точке перехвата с производительностью, близкой к нативной\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>Для наблюдаемости это означает, что вы можете перехватывать каждый HTTP-запрос, DNS-запрос, TCP-соединение, операцию файловой системы и выполнение процесса — без модификации кода приложений, без внедрения sidecar-контейнеров и без перезапуска подов.\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-c\">\u002F\u002F Упрощённая eBPF-программа для трейсинга HTTP-запросов\n\u002F\u002F Прикрепляется к системному вызову accept() для захвата входящих соединений\nSEC(\"kprobe\u002Ftcp_v4_connect\")\nint trace_connect(struct pt_regs *ctx) {\n    struct sock *sk = (struct sock *)PT_REGS_PARM1(ctx);\n    \n    u32 pid = bpf_get_current_pid_tgid() >> 32;\n    u16 dport = sk->__sk_common.skc_dport;\n    u32 daddr = sk->__sk_common.skc_daddr;\n    \n    struct event_t event = {\n        .pid = pid,\n        .dport = ntohs(dport),\n        .daddr = daddr,\n        .timestamp = bpf_ktime_get_ns(),\n    };\n    \n    bpf_perf_event_output(ctx, &events, BPF_F_CURRENT_CPU,\n                          &event, sizeof(event));\n    return 0;\n}\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch3>Почему это важно для наблюдаемости\u003C\u002Fh3>\n\u003Cp>Традиционная наблюдаемость требует \u003Cstrong>инструментации\u003C\u002Fstrong> — добавления кода, библиотек или sidecar-контейнеров в приложения. У такого подхода три фундаментальные проблемы:\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>Накладные расходы на ресурсы\u003C\u002Fstrong> — каждый sidecar потребляет CPU и память. В кластере из 500 подов с Envoy-sidecar сами sidecar-контейнеры могут потреблять 30-40% всех ресурсов кластера.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Пробелы в покрытии\u003C\u002Fstrong> — вы можете наблюдать только то, что инструментировали. Сторонние бинарники, события уровня ядра и сетевая инфраструктура остаются слепыми зонами.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Бремя обслуживания\u003C\u002Fstrong> — каждый язык, фреймворк и рантайм требует собственной библиотеки инструментации. Поддержание их в актуальном состоянии на сотнях сервисов — полноценная работа.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Cp>eBPF решает все три проблемы: работает в ядре (нулевые накладные расходы на приложение), видит всё, что видит ядро (без пробелов), и работает независимо от языка или фреймворка приложения (инструментируйте один раз, наблюдайте всё).\u003C\u002Fp>\n\u003Ch2 id=\"ebpf-2026\">Стек eBPF-наблюдаемости в 2026 году\u003C\u002Fh2>\n\u003Cp>Экосистема созрела до набора проверенных в бою инструментов, каждый из которых покрывает определённый домен наблюдаемости:\u003C\u002Fp>\n\u003Ch3>Cilium + Hubble: сетевая наблюдаемость\u003C\u002Fh3>\n\u003Cp>\u003Cstrong>Cilium\u003C\u002Fstrong> — де-факто CNI (Container Network Interface) для Kubernetes, используемый AWS EKS, Google GKE и Azure AKS как стандартный или рекомендуемый сетевой уровень. \u003Cstrong>Hubble\u003C\u002Fstrong>, компонент наблюдаемости Cilium, обеспечивает:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Видимость потоков L3\u002FL4\u003C\u002Fstrong> — каждое TCP\u002FUDP-соединение между подами с идентификацией источника\u002Fназначения, портом, задержкой и объёмом переданных байтов\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Разбор протоколов L7\u003C\u002Fstrong> — HTTP, gRPC, Kafka, DNS и PostgreSQL запросы\u002Fответы без изменений в приложении\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Аудит сетевых политик\u003C\u002Fstrong> — видимость того, какие сетевые политики разрешают или запрещают трафик в реальном времени\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Маппинг зависимостей сервисов\u003C\u002Fstrong> — автоматическая генерация графа сервисов на основе наблюдаемых паттернов трафика\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3>Pixie: мониторинг производительности приложений\u003C\u002Fh3>\n\u003Cp>Pixie (проект песочницы CNCF) использует eBPF для \u003Cstrong>APM без инструментации\u003C\u002Fstrong> для Kubernetes-нагрузок:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Автоматический трейсинг протоколов\u003C\u002Fstrong> — захват запросов\u002Fответов HTTP\u002F1.1, HTTP\u002F2, gRPC, PostgreSQL, MySQL, Redis, Kafka, DNS, AMQP и NATS\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Непрерывное профилирование CPU\u003C\u002Fstrong> — флейм-графы для каждого процесса, генерируемые из стек-трейсов eBPF без профилирующих агентов\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Динамическое логирование\u003C\u002Fstrong> — добавление точек трейсинга к работающим приложениям без передеплоя\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Захват полных тел запросов\u002Fответов\u003C\u002Fstrong> — просмотр реальных HTTP-заголовков и тел, SQL-запросов и результатов, gRPC-пейлоадов\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3>Tetragon: безопасность и аудит времени выполнения\u003C\u002Fh3>\n\u003Cp>\u003Cstrong>Tetragon\u003C\u002Fstrong> (от Isovalent\u002FCilium) — инструмент наблюдаемости безопасности и принудительного исполнения политик на основе eBPF:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Отслеживание выполнения процессов\u003C\u002Fstrong> — каждое событие exec, fork и exit с полным контекстом дерева процессов\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Мониторинг файлового доступа\u003C\u002Fstrong> — отслеживание чтения, записи и изменения прав доступа к чувствительным файлам\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Аудит сетевых соединений\u003C\u002Fstrong> — логирование каждого исходящего соединения с контекстом процесса\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Принудительное исполнение политик безопасности\u003C\u002Fstrong> — блокировка подозрительных действий в реальном времени\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3>Grafana Beyla: автоинструментация\u003C\u002Fh3>\n\u003Cp>\u003Cstrong>Grafana Beyla\u003C\u002Fstrong> — агент автоинструментации на основе eBPF, генерирующий OpenTelemetry-совместимые трейсы и метрики без изменений кода:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>Обнаруживает HTTP, gRPC, SQL и Redis-запросы на уровне ядра\u003C\u002Fli>\n\u003Cli>Генерирует OpenTelemetry-спаны с правильной пропагацией контекста трейсинга\u003C\u002Fli>\n\u003Cli>Поддерживает распределённый трейсинг между сервисами\u003C\u002Fli>\n\u003Cli>Интегрируется с Grafana Cloud, Tempo, Mimir и любым OpenTelemetry-совместимым бэкендом\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>Beyla особенно полезна для команд, мигрирующих с sidecar-коллекторов OpenTelemetry: разверните Beyla как DaemonSet, удалите sidecar-контейнеры — и ваши существующие дашборды Grafana продолжат работать.\u003C\u002Fp>\n\u003Ch3>Splunk OBI: OpenTelemetry eBPF Instrumentation\u003C\u002Fh3>\n\u003Cp>На \u003Cstrong>KubeCon EU 2026\u003C\u002Fstrong> (март 2026, Лондон) Splunk анонсировал \u003Cstrong>OBI (OpenTelemetry eBPF Instrumentation)\u003C\u002Fstrong> — проект, который вносит автоинструментацию на основе eBPF непосредственно в OpenTelemetry Collector:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Upstream-first подход\u003C\u002Fstrong> — OBI вносится в проект OpenTelemetry, а не является проприетарным инструментом Splunk\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Полная совместимость с OTel\u003C\u002Fstrong> — генерирует стандартные сигналы OpenTelemetry (трейсы, метрики, логи) из наблюдений eBPF\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Языково-независимый\u003C\u002Fstrong> — работает с любым рантаймом (Go, Java, Python, Node.js, Rust, .NET) без установки SDK\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Гибридный режим\u003C\u002Fstrong> — может дополнять существующую SDK-инструментацию данными уровня ядра для полной видимости\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>OBI представляет конвергенцию экосистем eBPF и OpenTelemetry. Вместо выбора между eBPF-нативными и OTel-нативными инструментами вы получаете оба в одном пайплайне.\u003C\u002Fp>\n\u003Ch2 id=\"\">Производительность: цифры, которые имеют значение\u003C\u002Fh2>\n\u003Cp>Экономия ресурсов от eBPF-наблюдаемости драматична. Вот реальные бенчмарки для \u003Cstrong>продакшен-кластера Kubernetes из 500 подов\u003C\u002Fstrong> с микросервисным приложением:\u003C\u002Fp>\n\u003Ch3>Сравнение потребления памяти\u003C\u002Fh3>\n\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>Компонент\u003C\u002Fth>\u003Cth>Sidecar-подход\u003C\u002Fth>\u003Cth>eBPF-подход\u003C\u002Fth>\u003Cth>Экономия\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\n\u003Ctr>\u003Ctd>Envoy sidecar (500 подов)\u003C\u002Ftd>\u003Ctd>50 ГБ\u003C\u002Ftd>\u003Ctd>0 (Cilium CNI)\u003C\u002Ftd>\u003Ctd>50 ГБ\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>OTel Collector sidecar (500 подов)\u003C\u002Ftd>\u003Ctd>15 ГБ\u003C\u002Ftd>\u003Ctd>0 (Beyla DaemonSet)\u003C\u002Ftd>\u003Ctd>15 ГБ\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Агент Datadog (DaemonSet, 20 узлов)\u003C\u002Ftd>\u003Ctd>10 ГБ\u003C\u002Ftd>\u003Ctd>Н\u002FД\u003C\u002Ftd>\u003Ctd>10 ГБ\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Агенты Cilium (20 узлов)\u003C\u002Ftd>\u003Ctd>Н\u002FД\u003C\u002Ftd>\u003Ctd>8 ГБ\u003C\u002Ftd>\u003Ctd>-8 ГБ\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Агенты Beyla (20 узлов)\u003C\u002Ftd>\u003Ctd>Н\u002FД\u003C\u002Ftd>\u003Ctd>2 ГБ\u003C\u002Ftd>\u003Ctd>-2 ГБ\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Pixie (edge-модули, 20 узлов)\u003C\u002Ftd>\u003Ctd>Н\u002FД\u003C\u002Ftd>\u003Ctd>2 ГБ\u003C\u002Ftd>\u003Ctd>-2 ГБ\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>\u003Cstrong>Итого\u003C\u002Fstrong>\u003C\u002Ftd>\u003Ctd>\u003Cstrong>75 ГБ\u003C\u002Fstrong>\u003C\u002Ftd>\u003Ctd>\u003Cstrong>12 ГБ\u003C\u002Fstrong>\u003C\u002Ftd>\u003Ctd>\u003Cstrong>84% снижение\u003C\u002Fstrong>\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Ch3>Нагрузка на CPU\u003C\u002Fh3>\n\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>Метрика\u003C\u002Fth>\u003Cth>Sidecar-подход\u003C\u002Fth>\u003Cth>eBPF-подход\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\n\u003Ctr>\u003Ctd>Добавленная задержка на запрос\u003C\u002Ftd>\u003Ctd>1-5мс (hop через Envoy-прокси)\u003C\u002Ftd>\u003Ctd><0.1мс (уровень ядра)\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>CPU-нагрузка на узел\u003C\u002Ftd>\u003Ctd>8-12%\u003C\u002Ftd>\u003Ctd><1%\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Влияние на хвостовую задержку (p99)\u003C\u002Ftd>\u003Ctd>+15-30мс\u003C\u002Ftd>\u003Ctd><1мс\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Ch3>Операционные метрики\u003C\u002Fh3>\n\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>Метрика\u003C\u002Fth>\u003Cth>Sidecar-подход\u003C\u002Fth>\u003Cth>eBPF-подход\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\n\u003Ctr>\u003Ctd>Контейнеры на под\u003C\u002Ftd>\u003Ctd>2-4 (приложение + sidecar)\u003C\u002Ftd>\u003Ctd>1 (только приложение)\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Время запуска пода\u003C\u002Ftd>\u003Ctd>5-15с (инициализация sidecar)\u003C\u002Ftd>\u003Ctd>1-3с (только приложение)\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Конфигурационные файлы\u003C\u002Ftd>\u003Ctd>500+ (конфиги sidecar на под)\u003C\u002Ftd>\u003Ctd>20 (конфиги DaemonSet на узел)\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Языки, требующие SDK\u003C\u002Ftd>\u003Ctd>Все (SDK OTel для каждого языка)\u003C\u002Ftd>\u003Ctd>Ни одного (уровень ядра)\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Слепые зоны\u003C\u002Ftd>\u003Ctd>Не инструментированные сервисы\u003C\u002Ftd>\u003Ctd>Нет (ядро видит всё)\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Ch2 id=\"1-cpu\">Менее 1% нагрузки на CPU: как это возможно?\u003C\u002Fh2>\n\u003Cp>Заявление о менее чем 1% нагрузки на CPU реально и подтверждено независимыми бенчмарками от Isovalent, CNCF и множества компаний-пользователей. Вот почему eBPF так эффективен:\u003C\u002Fp>\n\u003Col>\n\u003Cli>\u003Cstrong>JIT-компиляция\u003C\u002Fstrong> — eBPF-программы компилируются в нативный машинный код JIT-компилятором ядра. Они выполняются с производительностью, близкой к нативной, а не в интерпретаторе.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Per-CPU карты\u003C\u002Fstrong> — структуры данных партиционированы по ядрам CPU, что устраняет конкуренцию за блокировки. Каждое ядро пишет в собственный буфер.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Ring-буферы\u003C\u002Fstrong> — события передаются в пространство пользователя через безблокировочные ring-буферы. Не нужны системные вызовы для каждого события.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Агрегация в ядре\u003C\u002Fstrong> — eBPF-программы могут агрегировать метрики (счётчики, гистограммы) в пространстве ядра, отправляя в пространство пользователя только сводки.\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Селективное прикрепление\u003C\u002Fstrong> — eBPF-программы вызываются только в своих конкретных точках перехвата. Программа HTTP-трейсинга запускается только при срабатывании HTTP-связанных системных вызовов.\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch2 id=\"sidecar-ebpf\">Руководство по миграции: от sidecar к eBPF\u003C\u002Fh2>\n\u003Cp>Миграция от мониторинга на основе sidecar к eBPF — поэтапный процесс. Вот рекомендуемый подход:\u003C\u002Fp>\n\u003Ch3>Фаза 1: Развертывание eBPF-инструментов рядом с sidecar (Недели 1-2)\u003C\u002Fh3>\n\u003Cul>\n\u003Cli>Установите Cilium как CNI (если ещё не используете)\u003C\u002Fli>\n\u003Cli>Разверните Hubble для сетевой наблюдаемости\u003C\u002Fli>\n\u003Cli>Разверните Beyla как DaemonSet для автоинструментированных трейсов\u003C\u002Fli>\n\u003Cli>Запустите sidecar и eBPF-наблюдаемость параллельно\u003C\u002Fli>\n\u003Cli>Сравните качество данных и покрытие\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3>Фаза 2: Валидация и настройка (Недели 3-4)\u003C\u002Fh3>\n\u003Cul>\n\u003Cli>Убедитесь, что eBPF-инструменты захватывают те же сигналы, что и sidecar-стек\u003C\u002Fli>\n\u003Cli>Настройте обнаружение протоколов Beyla для ваших сервисов\u003C\u002Fli>\n\u003Cli>Настройте разбор L7 Hubble для ваших кастомных протоколов\u003C\u002Fli>\n\u003Cli>Создайте дашборды, зеркалирующие существующие sidecar-дашборды\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3>Фаза 3: Инкрементальное удаление sidecar (Недели 5-8)\u003C\u002Fh3>\n\u003Cul>\n\u003Cli>Начните с некритичных сервисов: удалите sidecar-коллекторы OTel\u003C\u002Fli>\n\u003Cli>Мониторьте регрессии качества данных\u003C\u002Fli>\n\u003Cli>Удалите Envoy-sidecar у сервисов, не нуждающихся в продвинутом управлении трафиком\u003C\u002Fli>\n\u003Cli>Сохраните Envoy только для сервисов, требующих его продвинутых функций\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch3>Фаза 4: Полный стек eBPF (Недели 9-12)\u003C\u002Fh3>\n\u003Cul>\n\u003Cli>Удалите оставшиеся sidecar\u003C\u002Fli>\n\u003Cli>Разверните Tetragon для безопасности времени выполнения\u003C\u002Fli>\n\u003Cli>Консолидируйте алертинг на eBPF-сигналах\u003C\u002Fli>\n\u003Cli>Задокументируйте новую архитектуру наблюдаемости\u003C\u002Fli>\n\u003Cli>Верните освобождённые ресурсы (вы получите 60-80% ресурсов sidecar обратно)\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2 id=\"\">Требования к ядру\u003C\u002Fh2>\n\u003Cp>eBPF-инструменты наблюдаемости требуют современного ядра Linux. Вот минимальные версии:\u003C\u002Fp>\n\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>Функция\u003C\u002Fth>\u003Cth>Минимальное ядро\u003C\u002Fth>\u003Cth>Рекомендуемое\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\n\u003Ctr>\u003Ctd>Базовый eBPF (карты, программы)\u003C\u002Ftd>\u003Ctd>4.15\u003C\u002Ftd>\u003Ctd>5.15+\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>BPF ring buffer\u003C\u002Ftd>\u003Ctd>5.8\u003C\u002Ftd>\u003Ctd>5.15+\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>BPF CO-RE (compile once, run everywhere)\u003C\u002Ftd>\u003Ctd>5.5\u003C\u002Ftd>\u003Ctd>5.15+\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>BTF (BPF Type Format)\u003C\u002Ftd>\u003Ctd>5.2\u003C\u002Ftd>\u003Ctd>5.15+\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>BPF LSM (политики безопасности)\u003C\u002Ftd>\u003Ctd>5.7\u003C\u002Ftd>\u003Ctd>5.15+\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Cp>Все основные дистрибутивы Kubernetes (EKS с Amazon Linux 2023, GKE с COS, AKS с Ubuntu 22.04) поставляются с ядрами, соответствующими этим требованиям.\u003C\u002Fp>\n\u003Ch2 id=\"\">Часто задаваемые вопросы\u003C\u002Fh2>\n\u003Ch3 id=\"ebpf-kubernetes\">Работает ли eBPF-наблюдаемость с не-Kubernetes нагрузками?\u003C\u002Fh3>\n\u003Cp>Да. eBPF работает на уровне ядра Linux, поэтому работает с любой нагрузкой — контейнеры, виртуальные машины, bare metal, systemd-сервисы. Cilium и Tetragon могут быть развёрнуты вне Kubernetes, а Beyla поддерживает standalone-режим. Однако наиболее богатый опыт — в Kubernetes, где инструменты могут коррелировать события ядра с метаданными подов и сервисов.\u003C\u002Fp>\n\u003Ch3 id=\"ebpf\">Может ли eBPF заменить распределённый трейсинг?\u003C\u002Fh3>\n\u003Cp>Для многих команд — да. Beyla и Pixie генерируют распределённые трейсы из наблюдений ядра, включая пропагацию контекста трейсинга. Однако eBPF-трейсы ограничены границами запросов\u002Fответов — они не могут трейсить кастомную бизнес-логику внутри ваших функций. Рекомендуемый подход — eBPF для инфраструктурного трейсинга плюс точечная SDK-инструментация для бизнес-критичных путей.\u003C\u002Fp>\n\u003Ch3 id=\"tls\">Как с зашифрованным трафиком (TLS)?\u003C\u002Fh3>\n\u003Cp>eBPF-инструменты могут трейсить TLS-трафик, прикрепляясь к функциям TLS-библиотеки (например, SSL_read и SSL_write OpenSSL), а не к сетевому уровню. Это захватывает открытый текст до шифрования или после дешифрования. Pixie, Beyla и Cilium поддерживают TLS-трейсинг для OpenSSL, BoringSSL и crypto\u002Ftls Go. Поддержка rustls Rust была добавлена в начале 2026.\u003C\u002Fp>\n\u003Ch3 id=\"ebpf-ebpf\">Безопасен ли eBPF? Может ли баг в eBPF-программе обрушить ядро?\u003C\u002Fh3>\n\u003Cp>Нет. Верификатор eBPF — это статический анализатор, встроенный в ядро, который проверяет каждую eBPF-программу перед загрузкой. Он отклоняет программы, которые могут вызвать бесконечные циклы, доступ к памяти за пределами или другие нарушения безопасности. Баг в eBPF-программе приведёт к ошибке загрузки — он никогда не обрушит ядро.\u003C\u002Fp>\n\u003Ch3 id=\"apm\">Какова общая стоимость владения по сравнению с коммерческими APM-инструментами?\u003C\u002Fh3>\n\u003Cp>eBPF-инструменты наблюдаемости (Cilium, Hubble, Pixie, Beyla, Tetragon) — open-source. Основные затраты — вычислительные ресурсы (ресурсы DaemonSet — примерно 12 ГБ ОЗУ и 2-3 ядра CPU для кластера из 500 подов) и инженерное время на настройку. По сравнению с коммерческими APM-инструментами (Datadog, New Relic, Splunk), которые берут $15-30 за хост в месяц плюс плата за ингест, eBPF-стеки обычно обходятся на 70-90% дешевле в масштабе.\u003C\u002Fp>\n","ru","b0000000-0000-0000-0000-000000000001",true,"2026-03-28T10:44:37.163027Z","Наблюдаемость без инструментации: как eBPF заменил sidecar-контейнеры","67% команд K8s используют eBPF-наблюдаемость. Cilium, Hubble, Pixie, Tetragon, Grafana Beyla — полное руководство с планом миграции и бенчмарками.","eBPF наблюдаемость",null,"index, follow",[22,27,31],{"id":23,"name":24,"slug":25,"created_at":26},"c0000000-0000-0000-0000-000000000012","DevOps","devops","2026-03-28T10:44:21.513630Z",{"id":28,"name":29,"slug":30,"created_at":26},"c0000000-0000-0000-0000-000000000006","Docker","docker",{"id":32,"name":33,"slug":34,"created_at":26},"c0000000-0000-0000-0000-000000000007","Kubernetes","kubernetes",[36,43,49],{"id":37,"title":38,"slug":39,"excerpt":40,"locale":12,"category_name":41,"published_at":42},"d0200000-0000-0000-0000-000000000013","Почему Бали становится хабом импакт-технологий Юго-Восточной Азии в 2026 году","pochemu-bali-stanovitsya-khabom-impakt-tekhnologiy-2026","Бали занимает 16-е место среди стартап-экосистем Юго-Восточной Азии. Растущая концентрация Web3-разработчиков, ИИ-стартапов в области устойчивого развития и компаний в сфере эко-тревел-технологий формирует нишу столицы импакт-технологий региона.","Инженерия","2026-03-28T10:44:37.953039Z",{"id":44,"title":45,"slug":46,"excerpt":47,"locale":12,"category_name":41,"published_at":48},"d0200000-0000-0000-0000-000000000012","Защита данных в ASEAN: чек-лист разработчика для мультистранового комплаенса","zashchita-dannykh-asean-chek-list-razrabotchika-komplaens","Семь стран ASEAN имеют собственные законы о защите данных с разными моделями согласия, требованиями к локализации и штрафами. Практический чек-лист для разработчиков мультистрановых приложений.","2026-03-28T10:44:37.944001Z",{"id":50,"title":51,"slug":52,"excerpt":53,"locale":12,"category_name":41,"published_at":54},"d0200000-0000-0000-0000-000000000011","Цифровая трансформация Индонезии на $29 миллиардов: возможности для софтверных компаний","tsifrovaya-transformatsiya-indonezii-29-milliardov-vozmozhnosti-dlya-kompaniy","Рынок IT-услуг Индонезии вырастет с $24,37 млрд в 2025 году до $29,03 млрд в 2026 году. Облачная инфраструктура, искусственный интеллект, электронная коммерция и дата-центры обеспечивают самый быстрый рост в Юго-Восточной Азии.","2026-03-28T10:44:37.917095Z",{"id":13,"name":56,"slug":57,"bio":58,"photo_url":19,"linkedin":19,"role":59,"created_at":60,"updated_at":60},"Open Soft Team","open-soft-team","The engineering team at Open Soft, building premium software solutions from Bali, Indonesia.","Engineering Team","2026-03-28T08:31:22.226811Z"]