![\"\"](\"https:\/\/gavrilov.info\/pictures\/2026-11-02-v-23.31.41.png\")
\n<\/div>\n![\"\"](\"https:\/\/gavrilov.info\/pictures\/image-247.png\")
\n🌐 Где применим кейс с Webhook?<\/h4>\n
Webhook-источник в `faucet` — это универсальный «швейцарский нож». Вам не нужно писать код для интеграции с десятками сервисов, если они умеют отправлять HTTP-запросы:<\/p>\n
- \n
- Jira \/ GitLab \/ GitHub:<\/b> Ловить события создания, изменения или закрытия задач (issues) и пулл-реквестов для построения аналитики по продуктивности команд.<\/li>\n
- Stripe \/ ЮKassa:<\/b> Принимать уведомления об успешных платежах или подписках в реальном времени.<\/li>\n
- CRM-системы (HubSpot, amoCRM):<\/b> Ловить изменения статусов сделок.<\/li>\n
- IoT-устройства:<\/b> Отправлять телеметрию при наступлении определенных событий (например, срабатывании датчика).<\/li>\n<\/ul>\n
Вы просто настраиваете в Jira Webhook на URL вашего `faucet`, и все изменения задач автоматически превращаются в строки в вашей Iceberg-таблице без единой строчки кода на Python или Java.<\/p>\n
⚠️ Ограничения Webhook-подхода<\/h4>\n
Несмотря на удобство, важно понимать природу Webhooks:<\/p>\n
- \n
- Доставка «At-most-once» (в лучшем случае):<\/b> Отправитель (например, Jira) отправляет запрос и ждет ответа `200 OK`. Если ваш сервер временно недоступен (упал, перезагружается), событие будет потеряно навсегда<\/b>. Webhooks не гарантируют доставку.<\/li>\n
- Отсутствие идемпотентности:<\/b> Отправитель может отправить одно и то же событие дважды (сетевые сбои). `faucet` запишет оба события (append-only), поэтому вам нужно самостоятельно чистить дубликаты на этапе аналитики.<\/li>\n
- Зависимость от отправителя:<\/b> Если Jira не имеет встроенного механизма повторных попыток (retry) при ошибках, вам придется самостоятельно обеспечивать высокую доступность эндпоинта `faucet`.<\/li>\n<\/ol>\n
Для критически важных данных лучше использовать очереди (Kafka) или CDC (Debezium), но для аналитики, логов и некритичных бизнес-событий Webhook + `faucet` — это самое быстрое и дешевое решение.<\/p>\n
\n🛠️ Пошаговая инструкция: Webhook → Iceberg → Trino<\/h3>\n
В этой инструкции мы развернем современный Lakehouse-стек:<\/p>\n
- \n
- Silo<\/b> (S3-совместимое хранилище с поддержкой STS).<\/li>\n
- Lakekeeper<\/b> (REST-каталог Iceberg).<\/li>\n
- Trino<\/b> (движок запросов).<\/li>\n
- faucet-stream<\/b> (приемщик вебхуков).
\n*(Стек запускается через Podman на macOS).*<\/li>\n<\/ul>\n📂 Шаг 1: Подготовка файлов<\/h4>\n
Создайте рабочую директорию и положите в нее три файла.<\/p>\n
1. `docker-compose.yaml`<\/b> (Только инфраструктура):<\/p>\n
services:\n silo:\n image: pgsty\/silo:RELEASE.2026-09-03T13-18-01Z\n command: server \/data --console-address ":9001"\n environment:\n MINIO_ROOT_USER: silo-root-user\n MINIO_ROOT_PASSWORD: silo-root-password\n healthcheck:\n test: ["CMD", "mc", "ready", "local"]\n interval: 2s\n timeout: 10s\n retries: 2\n start_period: 15s\n ports:\n - "9000:9000"\n - "9001:9001"\n networks:\n - iceberg_net\n\n create-bucket:\n image: pgsty\/silo:RELEASE.2026-09-03T13-18-01Z\n depends_on:\n silo:\n condition: service_healthy\n entrypoint: \/bin\/sh\n command:\n - -c\n - |\n mc alias set local http:\/\/silo:9000 silo-root-user silo-root-password &&\n mc mb --ignore-existing local\/examples\n networks:\n - iceberg_net\n\n db:\n image: postgres:17\n environment:\n - POSTGRES_PASSWORD=postgres\n healthcheck:\n test: ["CMD-SHELL", "pg_isready -U postgres -p 5432 -d postgres"]\n interval: 2s\n timeout: 10s\n retries: 2\n start_period: 10s\n networks:\n - iceberg_net\n\n migrate:\n image: quay.io\/lakekeeper\/catalog:latest-main\n pull_policy: always\n environment:\n - LAKEKEEPER__PG_ENCRYPTION_KEY=This-is-NOT-Secure!\n - LAKEKEEPER__PG_DATABASE_URL_READ=postgresql:\/\/postgres:postgres@db:5432\/postgres\n - LAKEKEEPER__PG_DATABASE_URL_WRITE=postgresql:\/\/postgres:postgres@db:5432\/postgres\n - RUST_LOG=info\n restart: "no"\n command: ["migrate"]\n depends_on:\n db:\n condition: service_healthy\n networks:\n - iceberg_net\n\n lakekeeper:\n image: quay.io\/lakekeeper\/catalog:latest-main\n pull_policy: always\n environment:\n - LAKEKEEPER__PG_ENCRYPTION_KEY=This-is-NOT-Secure!\n - LAKEKEEPER__PG_DATABASE_URL_READ=postgresql:\/\/postgres:postgres@db:5432\/postgres\n - LAKEKEEPER__PG_DATABASE_URL_WRITE=postgresql:\/\/postgres:postgres@db:5432\/postgres\n - RUST_LOG=info\n command: ["serve"]\n healthcheck:\n test: ["CMD", "\/home\/nonroot\/lakekeeper", "healthcheck"]\n interval: 1s\n timeout: 10s\n retries: 3\n start_period: 3s\n depends_on:\n migrate:\n condition: service_completed_successfully\n db:\n condition: service_healthy\n silo:\n condition: service_healthy\n create-bucket:\n condition: service_completed_successfully\n ports:\n - "8181:8181"\n networks:\n - iceberg_net\n\nnetworks:\n iceberg_net:\n driver: bridge<\/code><\/pre>2. `create-default-warehouse.json`<\/b> (Настройка каталога):<\/p>\n
{\n "warehouse-name": "demo",\n "project-id": "00000000-0000-0000-0000-000000000000",\n "storage-profile": {\n "type": "s3",\n "bucket": "examples",\n "endpoint": "http:\/\/silo:9000",\n "region": "us-east-1",\n "path-style-access": true,\n "flavor": "s3-compat",\n "sts-enabled": true\n },\n "storage-credential": {\n "type": "s3",\n "credential-type": "access-key",\n "aws-access-key-id": "silo-root-user",\n "aws-secret-access-key": "silo-root-password"\n }\n}<\/code><\/pre>3. `pipeline.yaml`<\/b> (Конфигурация `faucet` с Webhook):<\/p>\n
version: 1\npipeline:\n source:\n type: webhook\n config:\n listen_addr: "0.0.0.0:8080"\n path: "\/v1\/events"\n auth_token: "123"\n max_payloads: 10\n timeout_secs: 3600\n\n sink:\n type: iceberg\n config:\n catalog:\n type: rest\n uri: "http:\/\/lakekeeper:8181\/catalog"\n warehouse: "demo"\n properties:\n # Включаем использование временных ключей от Lakekeeper\n rest.vended-credentials-enabled: "true"\n io-impl: "org.apache.iceberg.aws.s3.S3FileIO"\n s3.endpoint: "http:\/\/silo:9000"\n s3.path-style-access: "true"\n s3.region: "us-east-1"\n namespace: ["demo"]\n table: "events"\n create_table: true\n write_mode: append<\/code><\/pre>
\n🚀 Шаг 2: Запуск и инициализация<\/h4>\n
Выполняйте команды строго по одной в терминале.<\/p>\n
1. Поднимаем инфраструктуру:<\/b><\/p>\n
podman-compose down -v\npodman-compose up -d\nsleep 10<\/code><\/pre>*Убедитесь, что контейнер `faucet-stream_lakekeeper_1` имеет статус `healthy` (`podman ps`).*<\/p>\n
2. Инициализируем Lakekeeper (Bootstrap и создание Warehouse):<\/b><\/p>\n
# Bootstrap\npodman run --rm --network faucet-stream_iceberg_net curlimages\/curl \\\n -X POST http:\/\/lakekeeper:8181\/management\/v1\/bootstrap \\\n -H "Content-Type: application\/json" \\\n --data '{"accept-terms-of-use": true}'\n\n# Создание Warehouse\npodman run --rm --network faucet-stream_iceberg_net \\\n -v "$(pwd)\/create-default-warehouse.json:\/tmp\/wh.json" \\\n curlimages\/curl \\\n -X POST http:\/\/lakekeeper:8181\/management\/v1\/warehouse \\\n -H "Content-Type: application\/json" --data @\/tmp\/wh.json<\/code><\/pre>3. Запускаем Trino и настраиваем каталог:<\/b><\/p>\n
# Запуск Trino\npodman run -d --name trino --network faucet-stream_iceberg_net \\\n -p 9999:8080 -e CATALOG_MANAGEMENT=dynamic trinodb\/trino:476\n\n# Ждем инициализации Trino (20 секунд)\necho "Waiting for Trino to start..."\nsleep 20\n\n# Создаем каталог lakekeeper в Trino\npodman exec trino trino --execute "\nCREATE CATALOG lakekeeper USING iceberg\nWITH (\n \\"iceberg.catalog.type\\" = 'rest',\n \\"iceberg.rest-catalog.uri\\" = 'http:\/\/lakekeeper:8181\/catalog',\n \\"iceberg.rest-catalog.warehouse\\" = 'demo',\n \\"iceberg.rest-catalog.nested-namespace-enabled\\" = 'true',\n \\"iceberg.rest-catalog.vended-credentials-enabled\\" = 'true',\n \\"iceberg.unique-table-location\\" = 'true',\n \\"s3.region\\" = 'us-east-1',\n \\"fs.native-s3.enabled\\" = 'true',\n \\"s3.path-style-access\\" = 'true',\n \\"s3.endpoint\\" = 'http:\/\/silo:9000'\n);"<\/code><\/pre>
\n🎯 Шаг 3: Запуск faucet и отправка вебхука<\/h4>\n
1. В новом окне терминала запускаем `faucet`:<\/b><\/p>\n
podman run --rm -it --network faucet-stream_iceberg_net \\\n -p 8081:8080 -v "$(pwd)\/pipeline.yaml:\/app\/pipeline.yaml" \\\n ghcr.io\/faucet-hq\/faucet-stream:full run \/app\/pipeline.yaml<\/code><\/pre>2. В третьем окне отправляем тестовый вебхук<\/b> (имитируем событие из Jira):<\/p>\n
curl -X POST http:\/\/127.0.0.1:8081\/v1\/events \\\n -H "Authorization: Bearer 123" \\\n -H "Content-Type: application\/json" \\\n -d '{"event_id": "evt-001", "user": "alice", "action": "login"}'<\/code><\/pre>*(В логах `faucet` вы увидите `records_written=10` и `succeeded=1`).*<\/p>\n
3. Проверяем результат в Trino:<\/b><\/p>\n
podman exec trino trino --execute "SELECT * FROM lakekeeper.demo.events;"<\/code><\/pre>Вывод:<\/b><\/p>\n
"evt-001","alice","login"\n"evt-002","alice","login"\n...<\/code><\/pre>Готово! Вы только что превратили HTTP-события в структурированную Iceberg-таблицу. 🎉<\/p>\n
\n💡 Дополнение 1: За пределами Webhook: faucet как ETL-платформа<\/h4>\n
Хотя в этой инструкции мы сфокусировались на кейсе с Webhook, важно понимать, что `faucet-stream` — это не просто приемщик HTTP-запросов, а полноценная ETL-платформа<\/b>.<\/p>\n
Помимо Webhook, он поддерживает десятки других паттернов интеграции: от классического чтения REST API (с пагинацией и инкрементальной загрузкой) и баз данных (включая CDC из PostgreSQL и MySQL) до потоковой передачи из Kafka и чтения файлов из S3. Webhook — это лишь один из самых простых и быстрых способов начать, который идеально ложится на интеграцию с Jira, Stripe, GitHub и другими SaaS-сервисами.<\/p>\n
🐛 О решенном баге и версиях<\/h5>\n
В ходе настройки мы столкнулись с ошибкой `StorageFactory must be provided for RestCatalog`. На момент выхода версии `v1.15.1` коннектор Iceberg в `faucet` не умел передавать фабрику хранилища для REST-каталогов. Команда проекта оперативно отреагировала на баг-репорт<\/a>, и исправление уже вошло в последующие релизы (в частности, в рамках PR #966).<\/p>\n
Теперь интеграция с Lakekeeper и Silo работает из коробки. Актуальный и стабильный образ всегда можно найти в официальном реестре: ghcr.io\/faucet-hq\/faucet-stream<\/a><\/b>.<\/p>\n
🍏 Почему мы запускали Trino и Faucet вручную на macOS?<\/h5>\n
Если вы обратили внимание, в инструкции мы запускали инфраструктуру (Silo, Lakekeeper) через `podman-compose`, а `Trino` и `faucet` — отдельными командами `podman run`.<\/p>\n
Это не архитектурное требование, а вынужденный обход специфичного бага `podman-compose` на macOS<\/b>. На Mac этот инструмент часто пытается объединить все контейнеры в один «Pod» и некорректно обрабатывает сложные цепочки зависимостей (`depends_on: condition: service_healthy`). В результате вы получаете общую ошибку `starting some containers: internal libpod error`, за которой невозможно разглядеть реальные логи контейнера.<\/p>\n
Ручной запуск через `podman run` с явным указанием сети (`--network faucet-stream_iceberg_net`) гарантирует, что контейнеры стартуют в правильном порядке, а вы всегда видите их реальные логи. На Linux-серверах или в Docker Desktop для Mac этот шаг можно смело делать через стандартный `docker-compose up -d`.<\/p>\n
В итоге, объединив мощь `faucet-stream`, современный REST-каталог Lakekeeper и движок Trino, вы получили гибкий и масштабируемый Lakehouse. Теперь любые события из внешних систем могут напрямую попадать в вашу аналитику без единой строчки кода! 🚀 Но не все так просто и радужно, как может показаться 🌈🦄 ...<\/p>\n
\n💡 Дополнение 2: Архитектура faucet-stream, Push vs Pull и будущее потоковой обработки<\/h4>\n
В завершение статьи важно заглянуть «под капот» `faucet-stream` и обсудить два фундаментальных подхода к интеграции данных: Push (Webhook)<\/b> и Pull (REST API)<\/b>. Понимание этой разницы критически важно, так как от нее зависит надежность вашего будущего Lakehouse.<\/p>\n
📤 Push-модель (Webhook) и её ограничения в faucet<\/h5>\n
В этой инструкции мы использовали `webhook` — это классическая Push-модель<\/b>. Отправитель (например, Jira или Stripe) сам «толкает» событие на ваш сервер.<\/p>\n
- \n
- Плюсы:<\/b> Мгновенная реакция на событие, минимальная задержка, не нужно писать код для опроса.<\/li>\n
- Ограничения `faucet-stream`:<\/b> Важно понимать, что источник `webhook` в `faucet` — это временный буфер<\/b>, а не долгоживущий сервер. Сервер запускается, собирает POST-запросы в память (в течение `timeout_secs` или до `max_payloads`), а затем завершается, сбрасывая данные в Iceberg.<\/li>\n
- Режим `serve`:<\/b> Даже при запуске `faucet serve --triggers` триггер выступает лишь оркестратором<\/b>. Он запускает пайплайн по событию, но само тело вебхука (`${trigger.body}`) не передается в пайплайн как готовый поток записей — его можно использовать только для параметризации источников внутри пайплайна.<\/li>\n
- Риск потери:<\/b> Если сервис перезагрузится или окно приема истечет в момент отправки, событие будет потеряно (доставка *at-most-once*). Установка огромного `timeout_secs` не решает проблему, а лишь откладывает ее, создавая риск переполнения памяти (OOM).<\/li>\n<\/ul>\n
📥 Pull-модель (REST API): Надежность для Production<\/h5>\n
Альтернатива — Pull-модель<\/b>. Вместо того чтобы ждать вебхук, `faucet` сам регулярно опрашивает API внешней системы (например, Jira) с помощью источника `rest`.<\/p>\n
- \n
- Плюсы:<\/b> Абсолютная надежность. Если `faucet` упал или был перезапущен, при следующем запуске он просто продолжит чтение с того места, где остановился (благодаря параметру `replication_method: Incremental`). Вы не потеряете ни одного события.<\/li>\n
- Где использовать:<\/b> Для критически важных бизнес-данных, аналитики и построения Lakehouse лучше выбирать именно Pull-модель, запуская пайплайн по расписанию (например, через `cron` или `faucet schedule` каждые 5-15 минут).<\/li>\n<\/ul>\n
🌊 Сравнение с RisingWave: Batch\/ETL против True Streaming<\/h5>\n
Учитывая слово `stream` в названии, многие ожидают от `faucet` поведения полноценной потоковой платформы, например, RisingWave<\/b>.<\/p>\n
- \n
- RisingWave<\/b> — это потоковая база данных (True Streaming)<\/b>. Она выступает в роли постоянного получателя. Вы создаете таблицу с коннектором `webhook`, и все входящие HTTP-запросы немедленно попадают в нее и обрабатываются с низкой задержкой. Она держит состояние постоянно.<\/li>\n
- faucet-stream<\/b> — это, прежде всего, декларативный ETL-инструмент (Batch\/ELT)<\/b>. Его парадигма — выполнение задачи (run) от начала до конца. Несмотря на название, на данный момент `faucet` не является долгоживущим стриминговым движком в том же смысле, что RisingWave или Kafka Streams. Его сила — в огромном количестве коннекторов, эффективной пакетной обработке и простоте YAML-конфигурации.<\/li>\n<\/ul>\n
Взгляд в будущее:<\/b> Слово «stream» в названии оставляет надежду, что в будущих версиях `faucet` может обзавестись более нативными примитивами для непрерывной потоковой обработки. Но на сегодняшний день, если вам нужен постоянный, вечно живой приемник вебхуков с гарантией сохранности каждого байта<\/b> (что нетривиально при текущем состоянии документации 😁), — это задача для потоковых баз данных (RisingWave) или связки «сервис-приемник + очередь (Kafka\/Redis)». Если же вам нужен мощный и гибкий инструмент для периодического перемещения данных (ETL)<\/b> по расписанию или событию, `faucet-stream` с Pull-моделью — идеальный выбор.<\/p>\n
\n![\"\"](\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2026-11-01-v-12.58.16.png\")
\n<\/div>\n",
"date_published": "2026-10-31T01:37:44+03:00",
"date_modified": "2026-11-02T23:32:52+03:00",
"tags": [
"big data",
"Data",
"Data Engineer",
"DevOps"
],
"image": "https:\/\/gavrilov.info\/pictures\/2026-11-02-v-23.31.41.png",
"_date_published_rfc2822": "Sat, 31 Oct 2026 01:37:44 +0300",
"_rss_guid_is_permalink": "false",
"_rss_guid": "365",
"_rss_enclosures": [],
"_e2_data": {
"is_favourite": false,
"links_required": [
"highlight\/highlight.js",
"highlight\/highlight.css"
],
"og_images": [
"https:\/\/gavrilov.info\/pictures\/2026-11-02-v-23.31.41.png",
"https:\/\/gavrilov.info\/pictures\/image-247.png",
"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2026-11-01-v-12.58.16.png"
]
}
},
{
"id": "361",
"url": "https:\/\/gavrilov.info\/all\/kagent-kubernetes-nativny-rantaym-dlya-ai-agentov-arhitektura-pr\/",
"title": "kagent: Kubernetes-нативный рантайм для AI-агентов — архитектура, практика и альтернативы",
"content_html": "kagent<\/b> — это open-source платформа с открытым исходным кодом, которая привносит «агентный» искусственный интеллект в облачные и Kubernetes-среды. Если говорить проще, она позволяет создавать интеллектуальных агентов, которые понимают запросы на естественном языке и автономно выполняют сложные операции по управлению инфраструктурой: диагностируют проблемы с сетью, анализируют логи, управляют развертываниями. https:\/\/kagent.dev<\/a><\/p>\n
\n![\"\"](\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2026-10-23-v-02.24.05.png\")
\n<\/div>\nkagent был создан компанией Solo.io в 2025 году и является sandbox-проектом CNCF (Cloud Native Computing Foundation). Его главная идея — превратить AI-агента из простого чат-бота в полноценного участника DevOps- и платформенных процессов, управляемого теми же инструментами, что и остальные рабочие нагрузки в кластере.<\/p>\n
🎯 Что дает kagent и как он работает<\/h3>\n
Ключевые возможности<\/h4>\n
- \n
- Управление как кодом (GitOps)<\/b>: Агенты определяются как обычные Kubernetes-ресурсы (Custom Resources). Вы можете версионировать их, применять через `kubectl` и управлять ими так же, как и любыми другими компонентами инфраструктуры.<\/li>\n
- Автоматизация рутины<\/b>: Агенты самостоятельно выполняют многошаговые задачи по устранению неполадок и мониторингу, снижая нагрузку на специалистов.<\/li>\n
- Гибкость и отсутствие привязки<\/b>: kagent поддерживает множество LLM-провайдеров (OpenAI, Anthropic, Gemini и другие), а также любые OpenAI-совместимые эндпоинты<\/b>, что позволяет использовать практически любую модель, включая вашу собственную.<\/li>\n
- Интеграция с инструментами<\/b>: Агенты могут использовать широкий набор инструментов (Tools) через Model Context Protocol (MCP) для взаимодействия с системами: просмотр логов подов, запросы к Prometheus, управление ресурсами Kubernetes и многое другое.<\/li>\n
- Human-in-the-loop<\/b>: Встроенные механизмы подтверждения действий, когда агент предлагает изменить ресурс, но ждет одобрения человека, а также поддержка инициативных вопросов от агента.<\/li>\n
- Долговременная память<\/b>: Векторная память, позволяющая агентам помнить контекст между сессиями, а не только в рамках последнего запроса.<\/li>\n
- Agent-to-Agent (A2A)<\/b>: Агенты могут обнаруживать друг друга и вызывать, что позволяет строить многоагентные рабочие процессы с делегированием задач.<\/li>\n<\/ul>\n
Архитектура<\/h4>\n
Архитектура kagent состоит из трех основных компонентов:<\/p>\n
- \n
- Tools (Инструменты)<\/b>: Это «руки» агента — набор функций, которые агент может вызывать для выполнения реальных действий в инфраструктуре. kagent поставляется с предустановленными инструментами для отображения логов подов, запросов к Prometheus, генерации ресурсов и многого другого.<\/li>\n
- Agents (Агенты)<\/b>: Это «мозг» системы — автономные системы, которые планируют, выполняют и анализируют задачи, используя доступные инструменты. Вы описываете агента в YAML-файле, указывая его системный промпт (роль), модель LLM и список инструментов, к которым у него есть доступ. Агенты могут объединяться в команды, где планирующий агент распределяет задачи между исполнителями.<\/li>\n
- Framework (Фреймворк)<\/b>: Гибкий интерфейс, позволяющий запускать агентов как через UI, так и декларативно. Он построен на фреймворке Google ADK, но также поддерживает LangGraph, CrewAI и собственные фреймворки.<\/li>\n<\/ol>\n
🐳 Практический пример: запуск kagent в Podman на macOS<\/h3>\n
Перейдем от теории к практике. Наш тестовый агент `myagent` был успешно запущен локально на MacBook (Intel) с использованием Podman. Он продемонстрировал возможность вызова инструментов (Tool Calling) и ведения диалога на русском языке.<\/p>\n
Ключевые шаги развертывания<\/h4>\n
- \n
- Подготовка окружения<\/b>: Установка Podman и `podman-compose`, а также создание скрипта-обертки `docker-compose`, который перенаправляет вызовы в `podman-compose`, поскольку kagent ожидает наличия именно этой утилиты.<\/li>\n
- Создание проекта агента<\/b>: Генерация структуры проекта командой `kagent init adk python myagent`.<\/li>\n
- Настройка базового образа<\/b>: В `Dockerfile` базовый образ был заменен на `kagent-adk:0.10.4-full`, так как distroless-вариант не содержит оболочки `\/bin\/sh`, необходимой для выполнения команд установки зависимостей. Также был добавлен шаг `RUN uv pip install “google-adk[extensions]”` для поддержки LiteLLM и указана переменная `ENV PYTHONPATH=\/app`.<\/li>\n
- Конфигурация подключения к LLM<\/b>: В файле `agent.py` (и\/или `docker-compose.yaml`) были явно указаны параметры для подключения к вашему эндпоинту ProxyAPI:\n
- \n
- Модель: `openai\/z-ai\/glm-5.3-flash` (обязательный префикс `openai\/` для LiteLLM).<\/li>\n
- Базовый URL: `https:\/\/api.proxyapi.ru\/v1<\/a>`.<\/li>\n
- API-ключ: ваш токен от ProxyAPI.<\/li>\n<\/ul>\n<\/li>\n
- Запуск<\/b>: Сборка образа и запуск контейнера через `podman-compose up`.<\/li>\n<\/ol>\n
Результат: работающий агент с Tool Calling<\/h4>\n
На скриншоте видно, как агент `myagent` в интерактивном режиме `kagent run` отвечает на приветствие, а затем по запросу «давай кинем» выполняет вызов инструмента:<\/p>\n
- \n
- Tool Call<\/b>: `roll_die` с параметром `{“sides”: 6}`.<\/li>\n
- Tool Result<\/b>: `{“result”: 1}`.<\/li>\n
- Ответ агента<\/b>: «Выпала 1<\/b> 🎲. На кубике с 6 гранями это минимальный результат — не повезло, но такое бывает! Хочешь бросить ещё раз или проверить число на простоту?»<\/li>\n<\/ul>\n
Этот пример наглядно демонстрирует полный цикл работы агента: понимание запроса, выбор и вызов нужного инструмента, обработка результата и формирование естественно-языкового ответа.<\/p>\n
\n![\"\"](\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2026-10-23-v-02.18.20.png\")
\n<\/div>\n⚖️ Сравнение с альтернативами<\/h3>\n
kagent — не единственный инструмент в этой нише. Чтобы понять его место, полезно сравнить его с другими решениями, которые решают смежные, но зачастую разные задачи. Подробные обзоры на Asya и Agent Autoscale появятся в отдельных статьях, а здесь мы приведем краткое сравнение.<\/p>\n
- Tool Result<\/b>: `{“result”: 1}`.<\/li>\n
- Создание проекта агента<\/b>: Генерация структуры проекта командой `kagent init adk python myagent`.<\/li>\n
- Agents (Агенты)<\/b>: Это «мозг» системы — автономные системы, которые планируют, выполняют и анализируют задачи, используя доступные инструменты. Вы описываете агента в YAML-файле, указывая его системный промпт (роль), модель LLM и список инструментов, к которым у него есть доступ. Агенты могут объединяться в команды, где планирующий агент распределяет задачи между исполнителями.<\/li>\n
- Автоматизация рутины<\/b>: Агенты самостоятельно выполняют многошаговые задачи по устранению неполадок и мониторингу, снижая нагрузку на специалистов.<\/li>\n
- faucet-stream<\/b> — это, прежде всего, декларативный ETL-инструмент (Batch\/ELT)<\/b>. Его парадигма — выполнение задачи (run) от начала до конца. Несмотря на название, на данный момент `faucet` не является долгоживущим стриминговым движком в том же смысле, что RisingWave или Kafka Streams. Его сила — в огромном количестве коннекторов, эффективной пакетной обработке и простоте YAML-конфигурации.<\/li>\n<\/ul>\n
- Где использовать:<\/b> Для критически важных бизнес-данных, аналитики и построения Lakehouse лучше выбирать именно Pull-модель, запуская пайплайн по расписанию (например, через `cron` или `faucet schedule` каждые 5-15 минут).<\/li>\n<\/ul>\n
- Ограничения `faucet-stream`:<\/b> Важно понимать, что источник `webhook` в `faucet` — это временный буфер<\/b>, а не долгоживущий сервер. Сервер запускается, собирает POST-запросы в память (в течение `timeout_secs` или до `max_payloads`), а затем завершается, сбрасывая данные в Iceberg.<\/li>\n
- Lakekeeper<\/b> (REST-каталог Iceberg).<\/li>\n
- Отсутствие идемпотентности:<\/b> Отправитель может отправить одно и то же событие дважды (сетевые сбои). `faucet` запишет оба события (append-only), поэтому вам нужно самостоятельно чистить дубликаты на этапе аналитики.<\/li>\n
- Stripe \/ ЮKassa:<\/b> Принимать уведомления об успешных платежах или подписках в реальном времени.<\/li>\n
![\"\"](\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2026-09-28-v-23.38.21.png\")
\n<\/div>\n![\"\"](\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2026-09-28-v-23.49.01.png\")
\n<\/div>\n![\"\"](\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2026-10-01-v-21.07.56.png\")
\n<\/div>\n![\"\"](\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2026-10-01-v-21.10.22.png\")
\n<\/div>\n![\"\"](\"https:\/\/gavrilov.info\/pictures\/Snimok-ekrana-2026-09-28-v-22.55.24.png\")
\n<\/div>\n