@thinkingai/ae-cli 1.0.28 → 6.0.16

package/wiki/te-docs/raw//345/256/242/346/210/267/347/253/257-sdk//346/270/270/346/210/217/345/274/225/346/223/216/layaair.md

@@ -0,0 +1,179 @@
+---
+code: laya_sdk_installation
+name: "LayaAir"
+wikiToken: DwgQwnSQpibhLEkcrR8cQbaHnKg
+parentWikiToken: G5xvwevvSi8u93kR0RwcN52MnFc
+updateTime: 1780571688000
+sourceUrl: https://docs-v2.thinkingdata.cn/?version=v6.0&lan=zh-CN&code=laya_sdk_installation
+---
+
+::: tip 提示
+ 在接入前, 请先阅读[<text color="purple" underline="true">接入前准备</text>](https://thinkingdata.feishu.cn/wiki/OvpawZlw1idmxzkwiJWcxlfNnNc)。
+LayaAir SDK 支持平台：iOS、Android、Web、微信小游戏、华为快游戏、字节跳动小游戏、bilibili小游戏、vivo小游戏、OPPO小游戏、小米快游戏、百度小游戏、QQ小游戏、淘宝创意互动小程序、支付宝小游戏、WKWebView。
+ :::
+**最新版本: **v3.6.1
+**更新时间: **2026-06-04
+**资源下载**: [源码](https://github.com/ThinkingDataAnalytics/mp-sdk/tags)、[SDK下载](https://download.thinkingdata.cn/client/MPMG/ta_laya_sdk_v3.6.1.zip)
+::: warning 注意
+当前文档适用于 v3.0.0 及以后的版本，历史版本请参考 [LayaAir 接入指南（V2）](https://docs.thinkingdata.cn/ta-manual/v4.1/installation/installation_menu/client_sdk/game_engine_sdk_installation/laya_sdk_installation/laya_sdk_installation.html)，[SDK下载（v2.2.4）](https://download.thinkingdata.cn/client/MPMG/ta_laya_sdk_v3.0.0-beta.1.zip)
+::: 
+## 一、集成SDK
+下载并解压 [LayaAir SDK](https://download.thinkingdata.cn/client/MPMG/ta_laya_sdk_v3.6.1.zip)
+:::: el-tabs
+::: el-tab-pane label=TypeScript 集成
+如果您的项目是 TypeScript 工程，接入步骤如下：
+1. 将声明文件 tdanalytics.laya.d.ts 放入 libs 目录
+2. 将 SDK 文件（tdanalytics.mg.layats.min.js）放入 bin/js 目录中
+3. 修改 bin/index.js 文件，加载 AE SDK：
+```javascript
+// 在加载 bundle.js 之前加载 AE SDK
+loadLib("js/tdanalytics.mg.layats.min.js");
+loadLib("js/bundle.js");
+```
+
+:::
+::: el-tab-pane label=JavaScript 集成
+ 如果您的项目是 JavaScript 工程，您可以直接将 `tdanalytics.mg.laya.min.js` 放入您的工程中，在源码中引用:
+```javascript
+import TDAnalytics from "./tdanalytics.mg.laya.min";
+```
+
+:::
+::::
+## 二、初始化
+引入 AE SDK 后，您可以在代码中使用 TDAnalytics:
+```javascript
+// TE SDK 配置对象
+var config = {
+  appId: "YOUR_APPID", // 项目 APP ID
+  serverUrl: "YOUR_SERVER_URL", // 上报地址
+  autoTrack: {
+    appLaunch: true, // 自动采集 ta_mg_launch
+    appShow: true, // 自动采集 ta_mg_show
+    appHide: true // 自动采集 ta_mg_hide
+  }
+};
+// 初始化
+TDAnalytics.init(config);
+```
+
+AE 配置对象参数说明如下：
+- `appId`: 您项目的 APP ID，必需, 可以在 AE 后台项目管理页查看
+- `serverUrl`: 数据上报 URL，必需 
+  - 如果您使用的是云服务，填入: https://global-receiver-ta.thinkingdata.cn
+  - 如果您使用的是私有化部署的版本，请与运维同学确认上报地址
+- `autoTrack`：可选, 表示是否开启自动采集功能，每一个元素分别代表如下的自动采集事件，默认全部关闭： 
+  - `appLaunch`：自动采集小程序初始化
+  - `appShow`：自动采集小游戏启动，或从后台进入前台
+  - `appHide`：自动采集小游戏从前台进入后台，并记录本次访问（启动至调入后台）的时间
+::: warning 注意
+ 在上报数据之前，请先在微信公众平台或其他平台的开发设置中，将数据传输 URL 加入到服务器域名的 request 列表中.
+ :::
+## 三、常用功能 
+在使用常用功能之前，建议你先了解[用户识别规则](https://thinkingdata.feishu.cn/wiki/AUyiw6XZsiF9EMk2fBScKjzunjd)；SDK默认会生成随机数作为访客ID，并持久化存储访客ID在本地；用户未登录之前，会以访客ID作为身份识别ID。注意:访客 ID 在用户清理缓存 以及更换设备时将会变更。
+### 3.1 设置账号ID
+在用户进行登录时，可调用 `login` 来设置用户的账号 ID， AE 平台将会以账号 ID 作为身份识别 ID，并且设置的账号 ID 将会在调用 `logout` 之前一直保留。多次调用 `login` 将覆盖先前的账号 ID 。
+```javascript
+// 用户的登录唯一标识，此数据对应上报数据里的#account_id，此时#account_id的值为TA
+TDAnalytics.login("TA");
+```
+
+<quote-container>
+**该方法不会上传登录事件**
+</quote-container>
+
+### 3.2 设置公共事件属性
+公共事件属性指的就是每个事件都会带有的属性，您可以调用 `setSuperProperties` 来设置公共事件属性，我们推荐您在发送事件前，先设置公共事件属性。对于一些重要的属性，譬如用户的会员等级、来源渠道等，这些属性需要设置在每个事件中，此时您可以将这些属性设置为公共事件属性。
+```javascript
+var superProperties = {
+    channel : "ta", //字符串
+    age : 1,//数字
+    isSuccess : true,//布尔
+    birthday :  new Date(),//对象
+    object : { key : "value" },//对象
+    object_arr : [ { key : "value" } ],//对象组
+    arr : [ "value" ]//数组
+};
+TDAnalytics.setSuperProperties(superProperties);//设置公共事件属性
+```
+
+公共事件属性将会被保存到缓存中，无需每次启动时调用。如果调用 `setSuperProperties` 上传了先前已设置过的公共事件属性，则会覆盖之前的属性。
+- Key 为该属性的名称，为字符串类型，规定只能以字母开头，包含数字，字母和下划线 "_"，长度最大为 50 个字符，对字母大小写不敏感，AE 会统一转化为小写字母
+- Value 为该属性的值，支持字符串、数字、布尔、时间、对象、对象组、数组
+<quote-container>
+**事件属性、用户属性的要求与公共事件属性保持一致**
+</quote-container>
+
+### 3.3 发送事件
+您可以调用 `track` 来上传事件，建议您根据先前梳理的埋点文档来设置事件的属性以及发送信息的条件，此处以用户购买某商品作为范例：
+```javascript
+TDAnalytics.track({
+    eventName: "product_buy", // 事件名称
+    properties: {
+        product_name: "商品名"
+    } //事件属性
+});
+```
+
+事件的名称是字符串类型，只能以字母开头，可包含数字，字母和下划线 "_"，长度最大为 50 个字符。
+### 3.4 设置用户属性
+对于一般的用户属性，您可以调用 `userSet` 来进行设置，使用该接口上传的属性将会覆盖原有的属性值，如果之前不存在该用户属性，则会新建该用户属性，类型与传入属性的类型一致，此处以设置用户名为例：
+```javascript
+//此时username为TA
+TDAnalytics.userSet({
+    properties: {
+        username: "TA"
+    }
+});
+//此时userName为AE
+TDAnalytics.userSet({
+    properties: {
+        username: "TE"
+    }
+});
+```
+
+## 四、最佳实践
+以下示例代码包含以上所有操作，我们推荐按照如下步骤使用:
+```javascript
+var TDAnalytics = require("./tdanalytics.wx.min.js");
+var config = {
+  appId: "YOU-APP-ID", // 项目的 APP ID
+  serverUrl: "https://youserverurl.com", // 数据上报地址
+  autoTrack: {
+    appLaunch: true, // 自动采集 ta_mp_launch
+    appShow: true, // 自动采集 ta_mp_show
+    appHide: true, // 自动采集 ta_mp_hide
+    pageShow: true, // 自动采集 ta_mp_view
+    pageShare: true // 自动采集 ta_mp_share
+  }
+};
+// 初始化
+TDAnalytics.init(config);
+// 用户的登录唯一标识，此数据对应上报数据里的#account_id，此时#account_id的值为TA
+TDAnalytics.login("TA");
+//设置公共事件属性
+var superProperties = {
+    channel : "ta", //字符串
+    age : 1,//数字
+    isSuccess : true,//布尔
+    birthday :  new Date(),//对象
+    object : { key : "value" },//对象
+    object_arr : [ { key : "value" } ],//对象组
+    arr : [ "value" ]//数组
+};
+TDAnalytics.setSuperProperties(superProperties);
+//发送事件
+TDAnalytics.track({
+    eventName: "product_buy", // 事件名称
+    properties: {
+        product_name: "商品名"
+    } //事件属性
+});
+//设置用户属性
+TDAnalytics.userSet({
+    properties: { 
+        username: "TE" 
+    }
+});
+```

package/wiki/te-docs/schema.md

@@ -0,0 +1,16 @@
+# AE docs Wiki Schema
+
+## Layout
+- `index.md` — catalog of pages with raw paths and source URLs
+- `raw/` — Feishu docx → markdown mirror (read-only, crawler-owned)
+- `synthesis/` — topic pages authored by synthesizer agents
+
+## Query flow for consuming skills
+1. Read `index.md` first.
+2. For topic overviews, prefer `synthesis/`.
+3. For exact API / config lookup, read `raw/`.
+4. Cite `sourceUrl` from page frontmatter when quoting.
+
+## Rules
+- Do not edit `raw/` — it is regenerated by the crawler.
+- Hand-authored or LLM-synthesized notes go in `synthesis/`.

package/wiki/te-docs/synthesis/batch-ingest-comparison.md

@@ -0,0 +1,324 @@
+---
+topic: Batch Ingestion Comparison
+sources:
+  - raw/data-ingestion-guide/data-import-tools.md
+  - raw/data-ingestion-guide/data-import-tools/logbus2-user-guide.md
+  - raw/data-ingestion-guide/data-import-tools/logbus-user-guide.md
+  - raw/data-ingestion-guide/data-import-tools/ta-datax-writer-plugin-user-guide.md
+  - raw/data-ingestion-guide/data-import-tools/filebeat-logstash-user-guide.md
+  - raw/data-ingestion-guide/data-import-tools/logbus-windows-user-guide.md
+generated: 2026-06-16
+---
+
+## Overview
+
+ThinkingData provides four primary tools for batch data ingestion into the TA platform:
+**LogBus2**, **LogBus (v1)**, **DataX Writer**, and **Filebeat + Logstash**.
+Each tool serves distinct use cases, from real-time log tailing to one-off historical data
+migration. This document compares their architectures, performance characteristics,
+deployment complexity, and recommended use cases to help you select the right tool.
+
+---
+
+## Quick-Reference Comparison Table
+
+| Dimension | LogBus2 | LogBus (v1) | DataX Writer | Filebeat + Logstash |
+|---|---|---|---|---|
+| **Current version** | 2.1.1.6 (Dec 2024) | 1.5.15.7 (Dec 2021) | DataX plugin | Logstash plugin v1.0.0 (Jun 2020) |
+| **Language / Runtime** | Go (native binary) | Java (JDK 8+) | Java (DataX framework) | Java (Logstash) + Go (Filebeat) |
+| **Memory footprint** | ~1/5 of LogBus v1 | Higher (JVM, ~2GB default max) | Depends on DataX job config | Filebeat ~10MB; Logstash JVM heavy |
+| **Throughput** | 5x faster than LogBus v1 | Moderate | High (parallel channels + threads) | **Low** (explicitly noted; not for bulk) |
+| **Data sources** | File (Glob), Kafka, SLS (Aliyun) | File (regex/Glob), Kafka | Any DataX reader (MySQL, HDFS, Hive, etc.) | File (via Filebeat) |
+| **Primary use case** | Real-time + bulk; server SDK logs, Kafka pipelines | Real-time + bulk; legacy deployments | Batch historical data migration from databases/data warehouses | Lightweight real-time log tailing; existing ELK shops |
+| **Deployment platforms** | Linux, macOS, Windows, Docker, K8s (Helm) | Linux, Windows (separate build), Docker | Anywhere DataX runs (Linux/macOS) | Anywhere ELK stack runs |
+| **Compression** | gzip, none (HTTP layer) | gzip, lzo, lz4, snappy, none | gzip, lzo, lz4, snappy (DataX level) | gzip, none (Logstash output plugin) |
+| **Multi-tenancy** | Multi APP_ID per instance, multi-pipeline | Multi APP_ID per instance | One APP_ID per job config | One APP_ID per Logstash output |
+| **Monitoring** | Prometheus + Grafana dashboards, progress command | status, progress, doctor commands | DataX built-in job metrics | ELK-native monitoring (Elastic) |
+| **Custom parsing** | gRPC plugin system | Java CustomInterceptor | DataX reader/writer column mapping | Ruby filter scripts |
+| **Windows support** | Yes (native, v2.1.1.6) | Yes (v1.3.0, file source only) | No (DataX only) | Yes (Filebeat + Logstash) |
+
+---
+
+## Tool-by-Tool Analysis
+
+### LogBus2
+
+LogBus2 is the **recommended real-time ingestion tool** and the direct successor to the
+original LogBus. It was rewritten in Go for dramatically lower resource consumption and
+higher throughput.
+
+**Architecture**: A single Go binary (`logbus`) that monitors data sources and pushes
+data to the TA receiver over HTTP. It maintains a runtime directory with consumption
+offset snapshots, enabling crash recovery without data loss (provided files are not
+deleted before consumption completes).
+
+**Data Sources**:
+- **File**: Glob pattern matching against local log directories. Supports auto-deletion
+  policies (`unit_remove` + `offset_remove`) and directory cleanup.
+- **Kafka**: Full consumer group support with SASL authentication (PLAIN, SCRAM-SHA-256,
+  SCRAM-SHA-512), cloud provider presets (Aliyun, Tencent, Huawei), and transactional
+  read support (`read_committed`).
+- **SLS (Aliyun Log Service)**: Via Kafka protocol bridge (requires Aliyun-side
+  enablement).
+
+**Performance Features**:
+- CPU limit via `cpu_limit` config (default: unlimited)
+- IOPS throttling (`limit` + `iops` config)
+- HTTP compression (gzip) for bandwidth savings
+- SIMD-accelerated JSON processing (since 2.1.1.4)
+- Configurable `http_timeout` (200ms–600s, default 600s)
+
+**Operational Commands**:
+```shell
+./logbus start                 # Start ingestion
+./logbus stop                  # Graceful stop (no data loss)
+./logbus restart               # Restart to pick up config changes
+./logbus env                   # Verify config + TA connectivity
+./logbus progress              # View per-file transmission progress
+./logbus dev                   # Validate file format locally
+./logbus reset                 # Clear all read offsets (use with caution)
+./logbus update                # Self-update to latest version
+```
+
+**Deployment Options**:
+- **Bare metal**: Download tarball, edit `conf/daemon.json`, run `./logbus start`
+- **Docker**: Prebuilt image `thinkingdata/ta-logbus-v2:latest`; mount data, conf, log,
+  and runtime directories as volumes
+- **Kubernetes**: Helm chart with StatefulSet; PVC-backed for persistence; each pod
+  handles its own file patterns via `container:` prefix in `values.yaml`
+
+**Limitations**:
+- Kafka source does not support the `progress`, `reset`, or `dev` commands as of v2.1.1.6
+- Kafka consumption is load-balance mode; number of LogBus2 instances must not exceed
+  partition count
+- File patterns do not support regular expressions (Glob only)
+
+**When to choose LogBus2**:
+- You need the highest throughput with the lowest resource footprint
+- You are starting a new deployment (greenfield)
+- You need K8s-native deployment
+- You require Prometheus/Grafana monitoring integration
+- You are consuming from Kafka or SLS
+
+---
+
+### LogBus (v1)
+
+The original LogBus, built on Apache Flume (Java). It is **mature and stable** but no
+longer receives major feature updates. The last release (1.5.15.7) was a security patch
+for the log4j vulnerability in December 2021.
+
+**Architecture**: Java process embedding Flume components (Source -> Channel -> Sink).
+Uses file-based or memory-based channels for buffering. Each APP_ID deployment requires
+at least 10GB of disk space for channel buffers.
+
+**Data Sources**:
+- **File**: Java-standard regex or Glob matching (configurable via `TAIL_MATCHER`).
+  Supports `DATE{YYYYMMDD}` templates for date-based directory structures (regex mode
+  only).
+- **Kafka**: Consumer group based, supports SASL authentication (since 1.5.15.5).
+  Requires Kafka broker version 0.10.1.0+.
+
+**Notable Features**:
+- File format debugging via `data_debug` command (validates data format against TA spec)
+- `doctor` command for automated troubleshooting
+- `status` command for real-time speed, memory, and CPU monitoring
+- Custom parser via Java `CustomInterceptor` interface (Maven/Gradle dependency)
+- Multi-threaded transmission with configurable `NUMTHREAD`
+
+**Limitations**:
+- Higher memory footprint due to JVM overhead
+- No native macOS support
+- No K8s/Helm deployment option
+- No multi-platform binary (separate Windows build at v1.3.0 with reduced features)
+- End of active feature development
+
+**When to choose LogBus v1**:
+- You have an existing LogBus v1 deployment to maintain
+- Your environment has special JDK constraints that make Go binaries impractical
+- You need regex-based file matching (not available in LogBus2 Glob patterns)
+- You need the `data_debug` bulk format validation command
+
+---
+
+### DataX Writer (ta-datax-writer)
+
+The DataX Writer plugin is designed exclusively for **one-off bulk historical data
+migration** from relational databases, data warehouses, HDFS, or other structured
+sources into TA.
+
+**Architecture**: A writer plugin for Alibaba's DataX framework. DataX manages the
+reader (source) and writer (TA) in a job with configurable channel parallelism. Each
+channel independently reads from the source and writes to TA via HTTP (receiver
+endpoint).
+
+**Column Mapping**: The writer maps source columns to TA data model fields via a
+`column` array:
+```json
+{
+  "index": "0",
+  "colTargetName": "#distinct_id",
+  "type": "string"
+}
+```
+
+Each column specification requires at least one of `index` (source column ordinal) or
+`value` (constant). Type conversion follows this mapping:
+
+| DataX Internal Type | TA Data Type |
+|---|---|
+| Int | Number |
+| Long | Number |
+| Double | Number |
+| String | String |
+| Boolean | Boolean |
+| Date | Date (with configurable `dateFormat`) |
+
+**Supported Data Types**: `track` (event data) and `user_set` (user property data).
+
+**Performance**: Throughput is determined by DataX's channel count (`speed.channel`) and
+the writer's thread count (`thread`, default 3). These operate independently -- multiple
+writer threads within each channel.
+
+**Compression**: Supports gzip, lzo, lz4, snappy at the sink level.
+
+**Limitations**:
+- Only supports writing to TA clusters (single-purpose writer)
+- Requires separate DataX installation and configuration
+- No real-time/streaming capability -- batch job only
+- One APP_ID per job JSON configuration
+- No built-in offset tracking, retry, or crash recovery beyond DataX's job-level
+  semantics
+
+**When to choose DataX Writer**:
+- You are migrating historical data from a database or data warehouse into TA
+- The source is one of DataX's many supported readers (MySQL, Oracle, HDFS, Hive, ODPS,
+  MongoDB, etc.)
+- You need column-level type mapping and transformation
+- The job is one-off or scheduled batch, not real-time streaming
+
+---
+
+### Filebeat + Logstash
+
+This combination uses open-source ELK stack components for real-time log tailing. It is
+best suited for teams **already operating an ELK stack** who want to add TA as an
+additional output destination.
+
+**Architecture**:
+```
+Log files -> Filebeat (tail) -> Logstash (filter/transform) -> TA Receiver
+```
+
+- **Filebeat**: Lightweight Go agent (~10MB memory) installed on each log-producing
+  server. Monitors files via Glob patterns and ships lines to Logstash. Supports
+  multiple input configurations with tag-based routing.
+- **Logstash**: Java-based data processing pipeline. Receives events from Filebeat via
+  the Beats input plugin on port 5044. Transforms data using Ruby filter scripts.
+  Outputs to TA via the `logstash-output-thinkingdata` plugin.
+
+**Key Configuration Points**:
+- `queue.type: persisted` is strongly recommended to prevent data loss on unexpected
+  shutdown (persistent queues on disk)
+- `queue.drain: true` ensures all buffered data is flushed before graceful shutdown
+- `pipeline.workers: 1` is required for `user_set` data to preserve event ordering;
+  `track` events can use multiple workers
+- `loadbalance: true` in Filebeat is only safe for `track` events; must be `false` for
+  `user_set`
+
+**Custom Parsing (Ruby Filters)**:
+Logstash requires Ruby scripts to transform arbitrary log formats into TA data format.
+Example for a structured log:
+```ruby
+def filter(event)
+  _message = event.get('message')
+  time, account_id, ip, event_name, msg, intdata = _message.split(/,/)
+  properties = { 'msg' => msg, 'int_data' => intdata.to_i }
+  data = {
+    '#time' => time,
+    '#account_id' => account_id,
+    '#event_name' => event_name,
+    '#ip' => ip,
+    '#type' => 'track',
+    'properties' => properties
+  }
+  event.set('message', data.to_json)
+  return [event]
+rescue
+  return []  # drop bad records
+end
+```
+
+**Limitations**:
+- **Low throughput**: The official documentation explicitly warns that Logstash has low
+  throughput and recommends DataX or LogBus for bulk historical data
+- Requires JDK environment on Logstash nodes
+- Two daemons to maintain (Filebeat + Logstash)
+- No built-in TA-specific monitoring or debug commands
+- No multi APP_ID support per Logstash pipeline (one output plugin instance = one APP_ID)
+
+**When to choose Filebeat + Logstash**:
+- Your organization already runs and maintains an ELK stack
+- You want to reuse existing Filebeat agents already deployed on your servers
+- Your throughput requirements are modest
+- You need flexible, script-based log transformation (Ruby) for non-standard formats
+- You want to avoid deploying a separate ingestion tool
+
+---
+
+## Selection Decision Matrix
+
+| Requirement | Recommended Tool |
+|---|---|
+| Real-time server log tailing (new deployment) | **LogBus2** |
+| Real-time server log tailing (existing LogBus v1) | **LogBus2** (migrate) or maintain **LogBus v1** |
+| Bulk historical data from database/warehouse | **DataX Writer** |
+| Kafka-based streaming pipeline | **LogBus2** |
+| K8s-native deployment | **LogBus2** (Helm) |
+| Existing ELK stack, add TA as output | **Filebeat + Logstash** |
+| Windows server environment | **LogBus2** (preferred) or **LogBus Windows** (legacy) |
+| Prometheus/Grafana monitoring required | **LogBus2** |
+| Low memory budget | **LogBus2** (Go binary, ~1/5 of LogBus v1) |
+| Regex-based file matching needed | **LogBus v1** |
+| Aliyun SLS as data source | **LogBus2** |
+
+---
+
+## Performance Hierarchy (high to low throughput)
+
+1. **LogBus2** -- 5x faster than LogBus v1; Go runtime with SIMD acceleration
+2. **DataX Writer** -- High throughput via parallel channels; tunable
+3. **LogBus v1** -- Moderate; JVM-bound; tunable thread count
+4. **Filebeat + Logstash** -- Low throughput; explicitly noted as unsuitable for bulk
+
+---
+
+## Deployment Complexity (simplest to most complex)
+
+1. **LogBus2** -- Single binary; one JSON config file; Docker/K8s/Helm available
+2. **LogBus v1** -- Java runtime required; properties-file config; Docker available
+3. **DataX Writer** -- Requires DataX framework installation + plugin deployment + job
+   JSON authoring
+4. **Filebeat + Logstash** -- Two daemons; Java + Go runtimes; Logstash plugin
+   installation; Ruby filter scripting
+
+---
+
+## Migration Path: LogBus v1 to LogBus2
+
+For teams currently on LogBus v1, a migration to LogBus2 is recommended given that v1
+receives only security patches and LogBus2 delivers a 5x throughput improvement at 1/5
+the memory cost. Key migration considerations:
+
+- **Config format changes**: LogBus v1 uses Java-style `.conf` properties files; LogBus2
+  uses JSON (`daemon.json`). Use the `configConvert` tool shipped in the LogBus2
+  `tools/` directory to assist.
+- **File matching**: LogBus v1 supports both regex and Glob; LogBus2 supports Glob only.
+  Review `TAIL_FILE` patterns for regex constructs that need rewriting.
+- **Custom parsers**: LogBus v1 uses Java `CustomInterceptor` (JAR-based); LogBus2 uses
+  gRPC-based plugins. Parser logic must be reimplemented.
+- **Monitoring**: LogBus v1 uses the `status` and `doctor` commands; LogBus2 uses
+  Prometheus metrics and Grafana dashboards.
+- **Kafka offset**: Both consume from `earliest` by default and support
+  `auto.offset.reset`. Coordinate consumer group names to avoid re-consuming existing
+  data.