starRiverProperty/docs/testing/elevator-evidence-v1-v2-diff-20260430.md

# 电梯生产证据包差异分析（2026-04-30）

**证据根目录**（仓库内）：[`maven-cw-elevator-application/logs/evidence/`](../../maven-cw-elevator-application/logs/evidence/)

本文基于 `collect_elevator_runtime_evidence.sh` 现场采集产出的三份时间戳目录，对**制品真实版本**、**本地配置**、**Consul 健康实例**、**日志关键行**与 **jcmd** 作对比。与历史排查主线的关系见 [`elevator-service-instance-missing-investigation.md`](elevator-service-instance-missing-investigation.md)。

---

## 1. 三份目录与「版本指纹」

| 目录 | 采集时间（`collected-at.txt`） | `jar-path.txt` 展示名 | `jar.sha256.txt` | `jar-tf.txt` 内模块版本（lib） | 说明 |
|------|-------------------------------|------------------------|------------------|--------------------------------|------|
| `elevator-evidence-20260430-112820` | 2026-04-30T11:28:20+0800 | `.../cw-elevator-application-V1.0.0.20211103.jar` | `8da5978a7b34...90544908` | **无**（当次未成功生成 `jar-tf`） | 与 113912 **同一 JAR 字节**（见 sha256） |
| `elevator-evidence-20260430-113912` | 2026-04-30T11:39:12+0800 | 同上 | **同上** | 含 `cw-elevator-application-*-**2.0.7**.jar` | 可确认 fat-jar 内为 **Maven 2.0.7 发布结构** |
| `elevator-evidence-20260430-114350` | 2026-04-30T11:43:50+0800 | 同上 | `c087067de3f6...8942054`（**不同**） | 含 `cw-elevator-application-*-**1.0-SNAPSHOT**.jar` | **第三套制品**：与 113912 非同一文件；内嵌为 **SNAPSHOT 构件** |

**核心结论（勿仅看文件路径名）**：

- 三份 `jar-path.txt` 的**文件名**均为历史目录 `cw-elevator-application-V1.0.0.20211103.jar`，但 **112820/113912 与 114350 的 sha256 不同**，说明现场曾**替换过**该路径上的 JAR 或 114350 采自**另一时刻/已换包**。
- **112820 与 113912** 的 sha256 **一致**，不是「V1 代码 vs V2 代码」的两套包，而是**同一物理 JAR 的两次采集**；区别仅在于 113912 多出了 `jar-tf.txt` / `java-version.txt` 等，用于认定模块版本为 **2.0.7**。
- **114350** 代表另一制品：**内嵌 1.0-SNAPSHOT**，不得与「正式发布 2.0.7」混为一谈。

**JDK**：113912、114350 的 `java-version.txt` 均为 **OpenJDK 1.8.0_41**（路径脚本写死 `/data/cwos/java`）。

---

## 2. 主轴对比：112820 ↔ 113912（同一 JAR、两轮采集）

| 维度 | 112820 | 113912 | 结论 |
|------|--------|--------|------|
| 磁盘 `application.properties` | 内容一致 | 一致 | `diff` **无差异** |
| 磁盘 `bootstrap.properties` | 一致 | 一致 | **无差异** |
| `proc-cmdline.txt` | `java -jar ... cw-elevator-application-V1.0.0.20211103.jar`（含 JDWP） | **相同** | **无差异** |
| Consul `/v1/health/service/...?passing=true` | 各服务 **passing 数组长度均为 3** | **相同** | **无差异** |
| `elevator-app.log.keylines.txt` | 与 113912 同一时期的日志摘录 | 内容一致（同一日志切片） | **无实质环境差异** |

**小结**：此轴不宜表述为「V1 与 V2 运行态对比」，应表述为 **同一 2.0.7 制品（sha256 一致）在短时间内的两次证据归档**，第二次补充了 `jar tf` 与 JDK 版本文件。

---

## 3. 主轴对比：113912 ↔ 114350（两套不同 JAR）

| 维度 | 113912 | 114350 | 结论 |
|------|--------|--------|------|
| `jar.sha256.txt` | `8da5978a...` | `c087067d...` | **不同文件** |
| fat-jar 内 `lib/cw-elevator-application-*.jar` | `*-2.0.7.jar` | `*-1.0-SNAPSHOT.jar` | **版本线不同** |
| 解压 `jar-application.properties.txt`（BOOT-INF 内嵌默认） | `logging.level.*=debug`，`logging.path=/data/cwos/cw-elevator-application-V1.0.0.20211103/logs` | `logging.level.*=info`，`logging.path=logs` | **打包内嵌默认配置不同**（与磁盘目录 `application.properties` 可能再叠加覆盖） |
| 磁盘 `application.properties`（采集快照） | 需与 114350 目录单独比对 | | 以各目录下同名文件为准 |

**部署含义**：

- **114350** 更符合「本地 Maven reactor **SNAPSHOT** 打出 fat-jar」的内嵌特征（`1.0-SNAPSHOT` + 内嵌 properties 为相对 `logs`）。
- **113912** 更符合「**发布流程 2.0.7**」打入的内嵌与 lib 版本。

若现场长期沿用目录名 `cw-elevator-application-V1.0.0.20211103` 仅替换 JAR，会出现「路径像 V1、内容实为 2.0.7 或 SNAPSHOT」——**必须以 sha256 + `jar tf` 为准**。

---

## 4. jcmd

三份目录的 `jcmd-system-properties.txt` 均为 **Attach 失败**（`AttachNotSupportedException: Unable to open socket file`），无法对比进程内最终 system properties。后续现场需满足 JVM attach 条件后再采一次（或使用启动参数导出），否则 Ribbon/Feign 运行态只能依赖日志与磁盘配置。

---

## 5. 日志与 Ribbon 行为（三份 keylines 共性）

在 **112820 / 113912** 的 `elevator-app.log.keylines.txt` 中可见一致现象（与 [`elevator-service-instance-missing-investigation.md`](elevator-service-instance-missing-investigation.md) 一致）：

- **Consul 注册**：`elevator-app` 成功注册（带 HTTP health）。
- **配置探针**：磁盘 `./bootstrap.properties` 中 `spring.cloud.consul.discovery.enabled=true`，classpath 内嵌为 **false**（多源并存）。
- **`ninca-crk-std`**：`DynamicServerListLoadBalancer` 使用 **`ConfigurationBasedServerList`**，但 **current list of Servers=[]**，随后出现 **`Load balancer does not have available server for client: ninca-crk-std`**。
- **其他客户端**（如 `cwos-portal`、`ninca-common`）日志中可见 Consul 解析出的 **3 台**实例。

**差异排查方向**（非本次证据目录两两 diff，而是现象归因）：重点核对 **`ninca-crk-std` 的 Ribbon 静态列表 / `NincaCrkStdRibbonConfiguration` 生效路径**与 Consul 列表是否交替覆盖，详见上述 investigation 文档。

**114350** 的 `elevator-app.log.keylines.txt` 与 113912 **文件不完全相同**（`diff` 有差异），如需逐行对比可在本地对两份 keylines 执行 `diff -u`。

---

## 6. `logs/evidence/elevator-app.log` 全量日志专项排查

**逐项走查（客户端名 / 时序 / Consul vs ConfigurationBased / bootstrap）**：见 [`consul-ribbon-no-server-walkthrough.md`](consul-ribbon-no-server-walkthrough.md)。

针对 [`maven-cw-elevator-application/logs/evidence/elevator-app.log`](../../maven-cw-elevator-application/logs/evidence/elevator-app.log) 进行额外统计与时间线复盘：

### 6.1 关键信号统计

- `Load balancer does not have available server for client: ninca-crk-std`：**290** 次  
- `ConfigurationBasedServerList`：**1** 次  
- `ConsulServerList`：**7** 次  
- 探针启动信号（`CONFIG SOURCE PROBE START` / `RIBBON...PROBE` / `CONSUL...PROBE` / `ELEVATOR DIAGNOSTIC PROBES`）：仅 **2** 条（其中可见的为 `CONFIG SOURCE PROBE START`）

### 6.2 时间线（同一日志内存在两次启动）

1. **第一次启动窗口（11:16）**
   - `11:16:24` Tomcat 启动、Consul 注册；
   - `11:16:24` ConfigSourceProbeRunner 打印：`ninca-crk-std.ribbon.listOfServers value=null`，`ninca-crk-std.ip=10.0.22.102:16106`；
   - `11:16:34` `ninca-crk-std` 初始化为 `ConfigurationBasedServerList`，但 `current list of Servers=[]`；
   - 随后大量出现 `Load balancer does not have available server for client: ninca-crk-std`。

2. **第二次启动窗口（11:43）**
   - `11:43:24` 再次出现 Tomcat 启动与 Consul 注册（说明同一日志内发生过重启）；
   - `11:43:35` `ninca-crk-std` 初始化时已是 `current list of Servers=[...:16106 x3]`；
   - 第二次窗口未见与第一次同规模的“空列表 + 连续 no available server”模式。

### 6.3 结合证据包的解释

- `112820` / `113912` 与第一次窗口行为一致，暴露出 `ninca-crk-std` 在该时段未拿到可用服务列表；
- `114350` 对应另一制品（`1.0-SNAPSHOT`）后，日志中出现 `ninca-crk-std` 能初始化出 3 台服务的信号；
- 因三份 Consul 健康快照均显示 `ninca-crk-std` passing=3，可初步排除「Consul 没有实例」这一外因，更可能是客户端侧配置/初始化时序/构件差异导致。

---

## 7. Consul 健康快照

三份目录中下列服务的 **passing 实例数（JSON 数组长度）一致**：均为 **3**（`elevator-app`、`cwos-portal`、`ninca-common`、`ninca-common-component-organization`、`ninca-crk-std`、`cloudwalk-device-thirdparty`）。  
说明：**本次采集窗口内** Consul 侧上游实例数量**未**成为三份包之间的差异变量；与 JVM 内 Ribbon 列表为空等问题需从 **客户端配置与负载均衡初始化顺序** 侧继续查。

---

## 8. 建议的后续动作

1. **命名归档**：在证据目录或工单中显式标注 **JAR sha256** 与 **`jar tf` 中 `cw-elevator-application-*` 版本**，避免「V1 目录名」误导。
2. **修复 jcmd 采集**：解决 attach 权限 / JVM 参数后重采，补齐 **进程内** `ribbon.*` / `feign.*`。
3. **`ninca-crk-std`**：按 investigation 文档与 **下节第 1 条** 优先验证 `ribbon.listOfServers` 与 `ninca-crk-std.ip` 的关系。

---

## 9. 综合证据 + 日志 + 多进程后的「下一步方向」

### 9.1 已对齐的事实（减少走弯路）

| 来源 | 结论 |
|------|------|
| 三份 `consul-health-*.json` | 各上游（含 `ninca-crk-std`）**passing 均为 3** |
| `ps-ef.txt`（随证据采集） | 各业务为**独立 Java 进程**；`ninca-crk-std` 在目标环境以**单独进程**形式存在（与电梯进程不同） |
| `proc-cmdline.txt` | 电梯进程为 `java -jar`，工作目录下 **`cw-elevator-application-V1.0.0.20211103.jar`**（文件名可与真实字节不一致，须看 sha256） |
| `elevator-app.log` | **同一日志两次启动**：首次 **11:16** `ninca-crk-std` 负载均衡 **Servers=[]**；重启后 **11:43** 同客户端出现 **3 台 :16106**，说明问题偏 **客户端 Ribbon 配置/初始化时序**，而非「现场没有 `ninca-crk-std` 进程」 |

### 9.2 优先验证：Ribbon 静态列表键 ≠ 业务 `ninca-crk-std.ip`

证据包内 **`application.properties`**（及仓库 [`deploy/v2-maven/application.properties`](../../maven-cw-elevator-application/deploy/v2-maven/application.properties)）仅有：

- `ninca-crk-std.ip=10.0.22.102:16106`（供业务代码等使用）

而探针行显示：

- `ninca-crk-std.ribbon.listOfServers value=null`

电梯侧对 `ninca-crk-std` 使用 [`NincaCrkStdRibbonConfiguration`](../../maven-cw-elevator-application/cw-elevator-application-starter/src/main/java/cn/cloudwalk/ribbon/NincaCrkStdRibbonConfiguration.java)，其 `ConfigurationBasedServerList` **从 Ribbon 标准配置**（如 `ninca-crk-std.ribbon.listOfServers`）取服务器列表；**与 `ninca-crk-std.ip` 无自动绑定**（`ninca-crk-std.ip` 在业务类中如 `AcsElevatorRecordServiceImpl` 以 `@Value` 使用）。

对照 [`deploy/v1-legacy/application.properties`](../../maven-cw-elevator-application/deploy/v1-legacy/application.properties) 中显式：

- `ninca-crk-std.ribbon.NIWSServerListClassName=...`
- `ninca-crk-std.ribbon.listOfServers=...`

**建议下一步（配置侧，变更须评审与灰度）**：

1. 在**现场**与 **v2 部署模板**中显式增加与现场一致的 **`ninca-crk-std.ribbon.listOfServers`**（可填与日志中负载均衡最终一致的 **三台主机:16106**，或与 Consul 解析一致的主机名列表），使 **首次启动**即不为空；并与 `ninca-crk-std.ip` 的业务语义对齐（同一可达入口集合）。
2. 重启后对照日志：首次出现 `DynamicServerListLoadBalancer for client ninca-crk-std initialized` 时 **`current list of Servers`** 是否直接非空。

### 9.3 观测与采集强化（不改业务契约前提下）

1. **对照 Ribbon / Consul 探针**（当前代码库默认**始终**运行；延迟见 `ElevatorProbeConstants`）：在 `*-probe.log` 中查 **ribbonProbe instance**、**consulProbe instance** 行，与 JVM 及 Consul API 对照（见 [`scripts/collect_elevator_runtime_evidence.sh`](../../scripts/collect_elevator_runtime_evidence.sh)）。
2. **修复 jcmd Attach**：解决 `jcmd-system-properties.txt` 中的 `AttachNotSupportedException` 后重采，便于核对 **进程内最终** `ribbon.*` / `feign.*`（与磁盘 properties 是否一致）。

### 9.4 仍建议对照的仓库文档

- [`elevator-service-instance-missing-investigation.md`](elevator-service-instance-missing-investigation.md)：Ribbon 双路径（Consul vs ConfigurationBased）与现象描述。
- 若调整 `listOfServers`，需在变更说明中记录 **与对外 HTTP/Feign 契约不变**（仅内部路由与配置）。

---

## 10. `elevator-app-probe.log` 同步分析（仓库内样本）

**文件**：[`maven-cw-elevator-application/logs/evidence/elevator-app-probe.log`](../../maven-cw-elevator-application/logs/evidence/elevator-app-probe.log)（与主日志同一次启动窗口 **2026-04-30 11:16:24**，仅含 `cn.cloudwalk.elevator.debug` 包输出。）

### 10.1 探针开关（首行汇总）

本证据文件采自 **2026-04-30** 进程；当时摘要行仍描述 **config / ribbon / consul** 三开关。当前仓库实现为：**三类探针默认全开**，调度仅改源码 [`ElevatorProbeConstants`](../../maven-cw-elevator-application/cw-elevator-application-starter/src/main/java/cn/cloudwalk/elevator/debug/ElevatorProbeConstants.java)，**不再**使用 `elevator.*.probe.enabled`。

- **`configProbe=true`**：`ConfigSourceProbeRunner` 已执行（本文件主体）。
- **`ribbonProbe=false`**：当时未启用 Ribbon 探针属性，故本文件中**无** `ribbonProbe instance` 等行（非当前代码行为）。
- **`consulProbe=false`**：当时未启用 Consul HTTP 探针，故本文件中**无** `consulProbe instance` 等行（非当前代码行为）。

新版进程应在延迟（Consul 约 20s、Ribbon 约 22s）后于 `*-probe.log` 中出现 **consulProbe** / **ribbonProbe** 明细；与 `elevator-app.log` 中 Netflix Ribbon 行交叉验证时**无需**再开属性开关。

### 10.2 配置源冲突（与主日志 / keylines 一致）

| 键 | 合并后 `getProperty` | 并存来源 |
|----|----------------------|----------|
| `spring.cloud.consul.host` | `10.0.22.102` | 磁盘 `file:./bootstrap` 为 **IP**；`classpath:/bootstrap` 为 **主机名** |
| `spring.cloud.consul.discovery.enabled` | `true` | 磁盘为 **true**；classpath 为 **false**（最终以 Environment 合并结果为准，探针 `value=` 为 **true**） |

### 10.3 Ribbon 相关键在 Environment 中的显式值

- `*.ribbon.NIWSServerListClassName`：**均为 `null`**（探针未解析到属性文件中的覆盖字符串）。
- `*.ribbon.listOfServers`：**均为 `null`**。
- `ninca-crk-std.ip`：**`10.0.22.102:16106`**（`file:` 与 `classpath:` 一致）。

与 [`NincaCrkStdRibbonConfiguration`](../../maven-cw-elevator-application/cw-elevator-application-starter/src/main/java/cn/cloudwalk/ribbon/NincaCrkStdRibbonConfiguration.java) + 主日志中 **`ConfigurationBasedServerList` 且 Servers=[]** 的现象一并阅读：**Environment 层未出现 `ninca-crk-std.ribbon.listOfServers`**，与「仅靠业务键 `ninca-crk-std.ip`」并存。

### 10.4 小结

| 项目 | 结论 |
|------|------|
| 本文件作用 | 专用 **`elevator-app-probe.log`**，避免在主日志中筛选探针类 |
| 本次样本覆盖范围 | **仅 ConfigSource**（当时未开 Ribbon/Consul 探针）；新版本默认可见全量探针 |
| 与排查关系 | 历史样本解释「旧证据缺 Ribbon/Consul 行」；现行构建以 `ElevatorProbeConstants` 为准，深层 Ribbon 行为仍可对照 **`elevator-app.log`** 中 `DynamicServerListLoadBalancer` |

---

**延伸（不改现场属性文件的审核备忘）**：[`elevator-v1-v2-init-timing-config-audit.md`](elevator-v1-v2-init-timing-config-audit.md)（初始化时序、探针顺序、jcmd attach、V1/V2 模板对照）。

---

**文档生成说明**：基于仓库内已检入的 `logs/evidence` 快照文件；若现场重新采集，请更新本文件名中的日期或新增一篇并列保留历史结论。