FME：Shutdown Script 收尾动作：成功或失败后复制结果、发邮件、调外部脚本

1. 引言：被忽视的"最后一公里"

在数据集成项目中，工程师往往将90%的精力投入到转换器链的设计、性能调优与数据质量校验上，而Workspace执行完毕后的收尾动作——结果归档、状态通知、下游触发——却常常以"手动处理"或"下次再说"草草收场。这种"重转换、轻收尾"的惯性，在单次调试时无伤大雅，一旦进入生产环境的高频调度，就会迅速演变为运维黑洞：失败任务无人知晓、中间结果覆盖丢失、下游系统空等上游信号。

FME提供的Shutdown Script（收尾脚本）正是填补这一空白的官方机制。它允许在Workspace执行结束（无论成功或失败）后自动运行一段脚本，完成清理、通知、复制、调用等动作。然而，官方文档对这一机制的描述相对克制，社区讨论也多为零散片段，缺乏系统性的工程方法论。本文评述认为，Shutdown Script的价值远不止"清理临时文件"，它是FME任务从"一次性执行"走向"可运维服务"的关键枢纽。

本文的核心创新在于提出"状态感知型收尾流水线"（State-Aware Shutdown Pipeline, SASP）这一分析框架。SASP将收尾动作抽象为四个阶段：状态捕获（Sense）→ 决策路由（Decide）→ 动作执行（Act）→ 结果反馈（Feedback）。所有具体实现——复制结果、发邮件、调外部脚本——都是这一框架下的动作实例。这一抽象使得收尾逻辑可设计、可测试、可复用，而非每次从零编写。

本文评述：将Shutdown Script视为"流水线的最后一道工序"是一种局限视角。更准确的理解是：它是任务生命周期的"状态出口"，承担着将执行结果向外部世界广播的职责。没有这个出口，FME任务就是信息孤岛。

2. Shutdown Script 机制全景解析

2.1 在Workbench中的位置与配置

在FME Workbench中，Shutdown Script的配置入口位于导航器（Navigator）面板的Workspace Settings → Scripting → Shutdown Script。用户可以选择脚本语言（Python、Tcl、JavaScript等，取决于FME版本与安装组件），并指定脚本文件路径或直接内联编写。

需要特别注意的是，Shutdown Script与Startup Script（启动脚本）成对出现，但二者的执行语义截然不同。Startup Script在Workspace开始读取数据前运行，适合做环境准备；Shutdown Script在Workspace所有转换完成后运行，适合做收尾。二者共享同一个脚本解释器上下文（在单次执行中），这意味着Startup Script中设置的变量可以在Shutdown Script中读取——这是实现"会话级状态传递"的关键技巧。

2.2 执行时机与生命周期

阶段	触发条件	典型用途	可否访问转换结果
Startup Script	Workspace启动时	环境变量设置、临时目录创建	否
转换执行	数据读取与处理	核心业务逻辑	—
Shutdown Script	转换成功或失败后	复制、通知、调用外部脚本	是（通过FME_Status等）
进程退出	脚本执行完毕	释放资源	—

从上表可以清晰看出，Shutdown Script是唯一能够同时感知"执行结果"与"执行上下文"的节点。这一独特位置决定了它在SASP框架中的核心地位。笔者认为，理解这一点是掌握收尾脚本设计的前提——它不是可有可无的装饰，而是任务状态的唯一权威出口。

2.3 可用脚本语言与运行环境

FME支持多种脚本语言用于Shutdown Script，选择取决于版本与部署环境。根据Safe Software官方文档（2024），主流选择如下：

• Python：推荐首选。FME内置Python解释器（通常为3.x），支持标准库与部分第三方库。适合复杂逻辑、HTTP请求、文件操作。
• Tcl：FME的传统脚本语言，轻量、启动快。适合简单文件操作与条件判断。
• JavaScript：部分版本支持，但生态与文档相对薄弱。

需要强调的是，FME内置的Python环境是受限环境——它不包含完整的pip生态，第三方库（如requests、pandas）未必可用。这是许多工程师踩坑的地方。解决方案有两种：一是使用标准库（urllib、smtplib、shutil）替代；二是通过subprocess调用系统Python。本文后续代码示例将优先使用标准库，确保可移植性。

3. 状态捕获：成功与失败的精确认知

3.1 FME_Status 与相关变量

在Shutdown Script中，FME通过预定义变量向脚本传递执行状态。最核心的是FME_Status，其值通常为0（成功）或非0（失败）。不同FME版本中变量名可能略有差异，建议在脚本开头打印所有FME_*变量以确认。

# Python Shutdown Script - 状态探测
import os

# 打印所有FME相关环境变量，便于调试
for key, value in sorted(os.environ.items()):
    if key.startswith('FME_'):
        print(f"{key} = {value}")

# 获取状态（不同版本可能为 FME_Status 或 FME_STATUS）
status = os.environ.get('FME_Status', os.environ.get('FME_STATUS', '0'))
print(f"Workspace status code: {status}")

上述代码是每个收尾脚本的"第一步"——先探测，再决策。本文评述认为，许多收尾脚本失效的根源在于盲目假设变量名与值，而不同FME版本、不同操作系统（Windows/Linux）下这些细节确实存在差异。打印环境变量是最廉价、最可靠的兼容性保障手段。

3.2 状态码语义与边界情况

状态码	含义	典型场景	收尾建议
0	成功	所有要素处理完毕	复制结果、发送成功通知
1	一般错误	转换器报错、数据格式异常	保留现场、发送失败告警
2	警告终止	达到错误阈值后中止	区分告警级别、部分结果归档
其他	版本相关	自定义终止、外部中断	记录原始码、人工介入

需要指出的是，FME的状态码语义并非在所有版本中完全一致。根据Safe Software社区论坛（2023-2024）的多条讨论，部分用户在FME 2022+版本中观察到状态码行为的变化。因此，生产环境的收尾脚本应避免对具体非零值做硬编码判断，而应采用"0为成功、非0为失败"的二分逻辑，将详细错误信息通过日志文件传递。

3.3 超越状态码：日志与统计信息捕获

仅凭状态码，收尾脚本只能知道"成功或失败"，却无法回答"处理了多少要素""耗时多久""哪个转换器最慢"。要实现真正的可观测性，需要从FME日志中提取统计信息。FME在运行时会将日志写入指定文件（可通过Workspace Settings配置），收尾脚本可以读取该文件并解析关键指标。

# 从FME日志中提取要素统计（简化示例）
import os
import re

log_path = os.environ.get('FME_LOG_FILE', '')
stats = {'features_read': 0, 'features_written': 0, 'elapsed': ''}

if log_path and os.path.exists(log_path):
    with open(log_path, 'r', encoding='utf-8', errors='ignore') as f:
        content = f.read()
    # 匹配典型日志行，实际正则需根据日志格式调整
    m = re.search(r'Total Features Read[:\s]+(\d+)', content)
    if m:
        stats['features_read'] = int(m.group(1))
    m = re.search(r'Total Features Written[:\s]+(\d+)', content)
    if m:
        stats['features_written'] = int(m.group(1))
    m = re.search(r'Total Time[:\s]+([\d.]+)', content)
    if m:
        stats['elapsed'] = m.group(1) + 's'

print(f"Stats: {stats}")

上述正则表达式为示意性质，实际日志格式因FME版本而异。笔者认为，更稳健的做法是使用FME的Logger转换器在Workspace内部主动输出结构化日志（如JSON行），收尾脚本只需解析这些自定义行即可，避免依赖官方日志格式的稳定性。

4. 结果复制：从临时目录到归档体系

4.1 为什么需要收尾复制

在FME的典型工作流中，输出数据往往先写入临时目录或工作目录，再由下游系统消费。这种模式存在三个风险：一是临时目录可能被系统清理；二是并发执行时文件名冲突；三是失败任务可能留下不完整的输出文件，污染下游。收尾脚本的复制动作，本质上是将"临时产物"转化为"正式交付物"的原子操作。

本文评述认为，复制策略的设计应遵循"成功才归档、失败留现场"原则。成功时，将结果复制到带时间戳的归档目录，并可选地更新"latest"软链接；失败时，保留临时文件供排查，同时记录失败标记。

4.2 复制策略设计矩阵

策略	适用场景	优点	缺点
时间戳归档	需要历史追溯	版本清晰、可回滚	磁盘占用增长快
覆盖式更新	结果只关心最新	节省空间	无法回溯
latest软链接	下游固定路径消费	兼顾归档与稳定路径	Windows需管理员权限
增量同步	大数据量、变化少	传输高效	实现复杂

4.3 Python实现：健壮的归档复制

# Python Shutdown Script - 结果归档复制
import os
import shutil
import datetime
import glob

STATUS = os.environ.get('FME_Status', '0')
SOURCE_DIR = os.environ.get('FME_MacroValues_OUTPUT_DIR', r'C:\fme\temp\output')
ARCHIVE_ROOT = r'D:\data_archive\project_x'
PATTERN = '*.csv'  # 按需调整

def archive_results():
    if STATUS != '0':
        print("[SKIP] Workspace failed, keep temp files for debugging.")
        return None
    ts = datetime.datetime.now().strftime('%Y%m%d_%H%M%S')
    target = os.path.join(ARCHIVE_ROOT, ts)
    os.makedirs(target, exist_ok=True)
    files = glob.glob(os.path.join(SOURCE_DIR, PATTERN))
    if not files:
        print("[WARN] No files matched for archiving.")
        return target
    for fp in files:
        shutil.copy2(fp, target)
        print(f"[OK] Copied {os.path.basename(fp)}")
    # 更新 latest 指针（Linux/macOS）
    latest = os.path.join(ARCHIVE_ROOT, 'latest')
    try:
        if os.path.islink(latest) or os.path.exists(latest):
            os.remove(latest)
        os.symlink(target, latest)
    except OSError as e:
        print(f"[INFO] Symlink skipped: {e}")
    return target

archive_results()

这段代码体现了SASP框架的"决策路由"思想：先判断状态，成功才归档；失败则保留现场。同时，通过try-except处理了软链接在Windows上的兼容性问题，避免因权限问题导致整个收尾脚本崩溃。笔者认为，收尾脚本自身的健壮性比功能丰富性更重要——一个抛异常的收尾脚本可能掩盖主任务的真实状态。

4.4 Tcl实现：轻量替代方案

# Tcl Shutdown Script - 结果复制
set status $env(FME_Status)
set src "C:/fme/temp/output"
set dst "D:/data_archive/project_x"

if {$status != 0} {
    puts "Workspace failed, skip archiving."
    exit 0
}

set ts [clock format [clock seconds] -format "%Y%m%d_%H%M%S"]
set target "$dst/$ts"
file mkdir $target

foreach f [glob -nocomplain -directory $src *.csv] {
    file copy -force $f $target
    puts "Copied: [file tail $f]"
}

Tcl版本更简洁，适合逻辑简单的场景。但其错误处理能力弱于Python，且glob在大量文件时性能较差。本文评述认为，选择语言的依据应是"逻辑复杂度"而非"个人偏好"：简单的文件复制用Tcl，涉及HTTP、JSON解析、复杂条件判断则用Python。

5. 邮件通知：多通道告警体系构建

5.1 SMTP基础实现

邮件通知是收尾脚本最经典的应用。Python的smtplib与email标准库足以完成这一任务，无需第三方依赖。以下是一个可直接使用的模板：

# Python Shutdown Script - 邮件通知
import os
import smtplib
from email.mime.text import MIMEText
from email.header import Header
from email.utils import formataddr
import datetime

STATUS = os.environ.get('FME_Status', '0')
WORKSPACE = os.environ.get('FME_WorkspaceName', 'Unknown')

SMTP_HOST = 'smtp.example.com'
SMTP_PORT = 587
SMTP_USER = 'fme-bot@example.com'
SMTP_PASS = os.environ.get('FME_SMTP_PASS', '')  # 从环境变量读取，勿硬编码
MAIL_TO = ['dataops@example.com', 'oncall@example.com']

def build_body():
    ts = datetime.datetime.now().strftime('%Y-%m-%d %H:%M:%S')
    if STATUS == '0':
        subject = f"[FME OK] {WORKSPACE} 执行成功"
        body = f"Workspace: {WORKSPACE}\n时间: {ts}\n状态: 成功\n"
    else:
        subject = f"[FME FAIL] {WORKSPACE} 执行失败 (code={STATUS})"
        body = f"Workspace: {WORKSPACE}\n时间: {ts}\n状态: 失败\n错误码: {STATUS}\n请及时排查。\n"
    return subject, body

def send_mail():
    subject, body = build_body()
    msg = MIMEText(body, 'plain', 'utf-8')
    msg['From'] = formataddr((str(Header('FME Robot', 'utf-8')), SMTP_USER))
    msg['To'] = ', '.join(MAIL_TO)
    msg['Subject'] = Header(subject, 'utf-8')
    try:
        with smtplib.SMTP(SMTP_HOST, SMTP_PORT, timeout=15) as server:
            server.starttls()
            server.login(SMTP_USER, SMTP_PASS)
            server.sendmail(SMTP_USER, MAIL_TO, msg.as_string())
        print("[OK] Mail sent.")
    except Exception as e:
        print(f"[ERROR] Mail failed: {e}")

send_mail()

安全提示：切勿在脚本中硬编码SMTP密码。推荐做法是将密码存入FME的环境变量、Windows凭据管理器或外部配置文件，脚本运行时读取。这是本文反复强调的安全底线。

5.2 Webhook与即时通讯集成

邮件之外，企业微信、钉钉、Slack、Microsoft Teams等平台均提供Webhook接口，可实现秒级告警。以企业微信群机器人为例：

# Python - 企业微信Webhook通知（使用标准库urllib）
import os
import json
import urllib.request

WEBHOOK = os.environ.get('FME_WECOM_WEBHOOK', '')
STATUS = os.environ.get('FME_Status', '0')
WORKSPACE = os.environ.get('FME_WorkspaceName', 'Unknown')

def notify():
    if not WEBHOOK:
        print("[SKIP] No webhook configured.")
        return
    color = "info" if STATUS == '0' else "warning"
    text = f"FME任务 {WORKSPACE} 状态: {'成功' if STATUS=='0' else '失败('+STATUS+')'}"
    payload = {
        "msgtype": "markdown",
        "markdown": {"content": f"{text}"}
    }
    data = json.dumps(payload).encode('utf-8')
    req = urllib.request.Request(WEBHOOK, data=data,
                                 headers={'Content-Type': 'application/json'})
    try:
        with urllib.request.urlopen(req, timeout=10) as resp:
            print(f"[OK] Webhook status: {resp.status}")
    except Exception as e:
        print(f"[ERROR] Webhook failed: {e}")

notify()

本文评述认为，告警通道的选择应遵循"分级路由"原则：成功通知走低打扰通道（如邮件日报），失败告警走高时效通道（如IM群@值班人）。将所有状态都推到同一个通道，会导致"告警疲劳"，最终无人关注。

5.3 告警分级与抑制策略

级别	触发条件	通道	抑制策略
INFO	成功完成	邮件汇总	每日合并一封
WARN	成功但有警告	邮件+IM	1小时内去重
ERROR	执行失败	IM@值班+电话	连续失败升级
CRITICAL	核心任务失败	全通道+工单	立即升级

6. 外部脚本调用：安全边界与工程模式

6.1 为什么需要调用外部脚本

FME内置Python环境的局限（无第三方库、版本固定）使得复杂任务需要借助外部脚本。典型场景包括：调用数据库客户端执行存储过程、触发Airflow DAG、运行R/Python数据科学管道、调用云API等。收尾脚本在此扮演"编排器"角色。

6.2 subprocess调用模式与安全边界

# Python - 安全调用外部脚本
import os
import subprocess
import shlex

STATUS = os.environ.get('FME_Status', '0')

def run_external(cmd_list, timeout=300):
    """cmd_list 必须是列表，避免shell注入"""
    try:
        result = subprocess.run(
            cmd_list,
            capture_output=True,
            text=True,
            timeout=timeout,
            check=False
        )
        print(f"[CMD] {' '.join(cmd_list)}")
        print(f"[STDOUT] {result.stdout[:500]}")
        if result.returncode != 0:
            print(f"[STDERR] {result.stderr[:500]}")
        return result.returncode
    except subprocess.TimeoutExpired:
        print("[ERROR] External script timeout.")
        return -1
    except Exception as e:
        print(f"[ERROR] {e}")
        return -2

if STATUS == '0':
    # 成功后才触发下游
    rc = run_external(['python', r'D:\scripts\trigger_airflow.py', '--dag', 'daily_etl'])
    print(f"Downstream trigger return code: {rc}")

安全红线：永远不要使用 shell=True 拼接用户可控的字符串。参数注入是收尾脚本最常见的安全漏洞。使用列表形式传参，让操作系统直接exec，杜绝shell解析。

本文评述认为，外部脚本调用应遵循"三不原则"：不阻塞（设置超时）、不静默（捕获输出）、不信任（校验返回码）。收尾脚本是主任务的"最后一环"，它的失败不应导致主任务被误判为失败，但也不能被完全忽略——正确的做法是记录到独立的收尾日志，并触发收尾级别的告警。

6.3 幂等性设计

外部脚本可能因网络抖动、服务重启等原因被重复调用。收尾脚本应通过"幂等令牌"机制避免重复副作用。例如，在调用前检查一个标记文件或数据库记录：

import os
import hashlib

def idempotent_run(task_id, func):
    token = hashlib.md5(task_id.encode()).hexdigest()
    flag = os.path.join(r'D:\fme\flags', token + '.done')
    if os.path.exists(flag):
        print(f"[SKIP] Task {task_id} already executed.")
        return
    func()
    with open(flag, 'w') as f:
        f.write('done')

这一模式在FME Server的失败重试场景中尤为重要。根据Safe Software官方文档，FME Server的Job重试机制可能导致Shutdown Script多次执行，幂等设计是避免下游重复消费的关键保障。

7. FME Server / Cloud 环境适配

7.1 FME Server中的脚本执行差异

在FME Server环境中，Workspace运行在Engine进程中，Shutdown Script的执行上下文与桌面版存在显著差异。主要区别包括：

• 工作目录：Server环境的工作目录由Engine动态分配，不能假设固定路径。
• 环境变量：Server注入的FME_*变量集合与桌面版不同，需重新探测。
• 权限：Engine服务账户的权限决定了脚本能访问哪些资源。
• 并发：多个Job可能同时执行，收尾脚本必须考虑并发安全。

本文评述认为，从桌面迁移到Server时，收尾脚本必须重新测试，不能想当然地复用。尤其是文件路径，应通过FME_MacroValues或FME共享资源路径来动态获取。

7.2 使用FME Server REST API实现通知

FME Server本身提供了通知服务（Notification Service），支持邮件、Webhook、Amazon SNS等。相比在Shutdown Script中手写SMTP，使用Server通知服务更规范、更易管理。收尾脚本只需调用REST API触发通知：

# 触发FME Server通知服务
import os, json, urllib.request, base64

FME_SERVER = 'https://fme-server.example.com'
TOKEN = os.environ.get('FME_SERVER_TOKEN', '')
TOPIC = 'job-status'

def publish_notification(message):
    url = f"{FME_SERVER}/fmerest/v3/notifications/topics/{TOPIC}/message"
    payload = json.dumps({"message": message}).encode('utf-8')
    req = urllib.request.Request(url, data=payload, method='POST')
    req.add_header('Authorization', f'fmetoken token={TOKEN}')
    req.add_header('Content-Type', 'application/json')
    try:
        with urllib.request.urlopen(req, timeout=10) as r:
            print(f"[OK] Notification published: {r.status}")
    except Exception as e:
        print(f"[ERROR] {e}")

publish_notification(f"Workspace done, status={os.environ.get('FME_Status')}")

7.3 FME Cloud与容器化部署

FME Cloud基于AWS基础设施，Engine运行在容器中。收尾脚本在此环境下面临"无状态"挑战：容器可能随时被回收，本地文件不持久。因此，收尾脚本的复制动作应指向S3、Azure Blob等对象存储，而非本地磁盘。

根据AWS官方文档与FME Cloud用户指南（2024），推荐模式是：收尾脚本调用AWS CLI或boto3将结果上传至S3，再通过SNS触发下游。这一模式与云原生的"事件驱动"架构天然契合。笔者认为，云环境下的收尾脚本本质上是"事件发布器"，其职责从"文件搬运"转向"信号广播"。

8. 工程实践：五个典型场景的完整实现

场景一：每日ETL任务的归档+通知

这是最常见的场景。Workspace每日凌晨执行，输出CSV到临时目录，收尾脚本负责归档到日期目录并发送成功/失败邮件。实现要点：使用日期戳避免覆盖、失败时保留临时文件、邮件正文包含要素统计。

场景二：数据库同步后的下游触发

Workspace将数据写入PostGIS后，收尾脚本调用外部Python脚本刷新物化视图，并触发BI工具的缓存刷新API。要点：幂等令牌防止重复刷新、超时控制避免阻塞、返回码校验。

场景三：批量任务的汇总报告

多个Workspace由FME Server的Job Orchestrator串联执行。每个Workspace的收尾脚本将状态写入共享的Redis或数据库，最后一个Workspace的收尾脚本汇总所有状态并发送综合报告。

场景四：失败自动重试

收尾脚本检测到失败后，通过FME Server REST API重新提交Job，并记录重试次数。超过阈值后升级告警。要点：重试计数需持久化、避免无限重试、区分可重试错误与致命错误。

场景五：数据质量报告的自动分发

Workspace执行数据质量检查，输出HTML报告。收尾脚本将报告上传至内部Wiki或对象存储，并将链接通过IM发送给数据负责人。要点：报告文件命名规范、链接有效期管理、权限控制。

9. 前沿趋势与学术预判

9.1 从脚本到声明式配置

当前收尾逻辑以命令式脚本为主，可维护性依赖工程师的编码素养。业界正在向声明式配置演进——通过YAML/JSON描述"何时、何种状态、执行何种动作"，由平台统一解释执行。这一趋势与Kubernetes的Operator模式、Airflow的on_success_callback/on_failure_callback高度一致。本文评述认为，FME收尾逻辑的声明式封装是值得关注的工程方向，可显著降低运维门槛。

9.2 可观测性三支柱的融合

Logs（日志）、Metrics（指标）、Traces（链路）是可观测性的三大支柱。当前FME收尾脚本主要贡献Logs，对Metrics与Traces的支持薄弱。未来方向是：收尾脚本将执行时长、要素数量、错误率等指标推送到Prometheus，将任务链路信息推送到OpenTelemetry。这将使FME任务融入企业统一的可观测性平台。

9.3 AI辅助的异常诊断

随着大语言模型在运维领域的应用，收尾脚本可以承担"异常摘要生成"职责：将FME日志中的错误信息输入LLM，生成人类可读的故障分析报告，并附带修复建议。根据2024年多项运维AI研究（如Microsoft的AIOps相关论文），这一模式在日志聚类与根因分析上已展现潜力。笔者认为，收尾脚本是AI运维能力接入FME的天然入口，因为它掌握着任务的全量上下文。

9.4 边缘计算与轻量化收尾

在边缘计算场景中，FME Engine可能运行在资源受限的设备上，无法承载完整的Python环境。此时收尾脚本需要极致轻量化——仅使用Tcl或最小Python，通过MQTT等轻量协议上报状态。这与物联网领域的边缘-云协同架构一致。

10. 总结与最佳实践清单

回顾全文，SASP框架将FME收尾动作统一为"感知-决策-执行-反馈"四阶段。围绕这一主线，本文给出了状态捕获、结果复制、邮件通知、外部调用的完整实现路径。以下是可直接落地的实践清单：

1. 先探测，后决策：脚本开头打印所有FME_*环境变量，确认状态码与路径变量。
2. 成功才归档，失败留现场：避免不完整结果污染下游。
3. 告警分级路由：成功走低打扰通道，失败走高时效通道。
4. 永不硬编码凭据：密码、Token从环境变量或凭据管理器读取。
5. 外部调用三不原则：不阻塞、不静默、不信任。
6. 幂等设计：用令牌机制防止重复副作用。
7. 收尾脚本自身健壮：用try-except包裹，避免掩盖主任务状态。
8. Server环境重新测试：路径、权限、并发均与桌面版不同。
9. 云环境面向对象存储：本地文件不持久，结果上传S3/Blob。
10. 记录收尾日志：收尾动作的执行结果独立记录，便于审计。

本文评述认为，收尾脚本的成熟度是FME工程化水平的"试金石"。一个只有转换逻辑、没有收尾设计的Workspace，在单次调试中或许够用，但在生产环境中必然成为运维负担。将收尾动作纳入SASP框架系统设计，是每个FME工程师值得投入的"最后一公里"。

拓展学习资源

• Safe Software官方文档 - Shutdown Script: docs.safe.com
• FME Community - Scripting 板块: community.safe.com
• FME Server REST API 文档: docs.safe.com/fme
• Python subprocess 官方文档: docs.python.org
• OpenTelemetry 官网: opentelemetry.io