大家好今天想和大家聊一聊“可观测性”以及围绕它展开的 Monitor 监控体系。很多团队在做系统建设时都会遇到两个典型的困惑一是已经部署了监控系统但线上出故障时还是需要靠人工逐个 SSH 进服务器查看日志二是看到 Prometheus、Grafana、Alertmanager 这些组件时CPU 指标、内存指标、请求数指标都采集了告警也配了但告警内容却常常让值班同学一头雾水。这些问题的背后往往不是“监控不够多”而是“可观测性建设不够体系化”。本文将围绕可观测性与 Monitor 这个主题展开先梳理清楚概念边界再带大家用 Prometheus 全家桶从零搭建一套可以落地的最小监控告警系统。内容覆盖核心原理、配置文件、PromQL 查询、Grafana 可视化、Alertmanager 告警以及生产环境常见坑点和最佳实践。不管是刚开始接触监控的新手还是已经在项目里使用监控但未形成体系的后端、运维同学都可以在这篇文章里找到可以参考的内容。1. 可观测性与 Monitor 的概念边界1.1 什么是可观测性“可观测性”这个词最早来自控制理论指的是系统能够从外部输出信息推断出其内部状态的程度。放到互联网软件工程语境下可观测性就是一个系统运行得好不好、为什么不好我们能否通过它暴露出来的数据准确判断出来。想象一个非常朴素的场景服务突然变慢了用户开始投诉。如果团队只有“服务是活的”这个信息那么面对故障时基本无从下手。但如果此时我们有请求耗时曲线、错误率曲线、CPU 和内存用量、依赖中间件的延迟数据甚至每一次请求的完整调用链那么定位问题就会从容很多。这就引出了业界常说的可观测性三大支柱Three Pillars of ObservabilityMetrics指标以数值形式周期性采集的数据如 QPS、响应时间、错误数、CPU 使用率。它的特点是存储成本低、查询效率高适合衡量系统的整体健康状态和触发告警。Logging日志离散的、带时间戳的事件记录详细描述某个时间点发生了什么。它的信息最丰富但数据量通常最大适合事后分析和故障根因定位。Tracing链路追踪记录一次请求从入口到下游各个服务的完整调用路径和耗时。它用于回答“这个慢请求到底慢在哪个环节”。三大支柱之间不是替代关系而是互补关系。指标告诉你哪里出了问题日志告诉你具体报了什么错链路追踪告诉你是哪个下游调用导致的延迟。一个真正具备可观测性的系统需要把这三类数据协同起来。1.2 Monitor 在不同技术语境下的含义“Monitor”这个词在不同技术领域里指的东西差别很大这里做一个简单区分避免后面阅读时产生混淆。本文讨论的 Monitor是作为“监控体系”来理解的包括指标采集、数据存储、可视化、告警通知等一整套方案。这也是最常见、最通用的理解。在一些硬件或嵌入式场景中Monitor 也可能指显示设备上的“菜单叠加层”。例如 mstar晨星半导体的 monitor 方案中经常提到的 OSD 菜单制作就是在视频输出画面上叠加图形化菜单。这类方案主要面向电视、显示器、机顶盒类产品与互联网后端监控体系属于完全不同的技术栈。再比如 UE 插件里的 hardware monitor plugin它属于游戏引擎或图形应用侧的“硬件状态监控”工具用来采集 CPU、GPU、显存占用等信息帮助开发者做性能优化。这类工具通常是单机的、面向开发者自测的。所以如果你在搜索引擎里看到“Monitor”需要先判断它所在的语境是服务器监控、嵌入式显示还是游戏引擎开发。本文后续内容全部围绕互联网后端及基础设施的监控体系展开。1.3 监控与可观测性的区别很多人会把“监控”和“可观测性”划等号但实际上它们侧重点不同。监控Monitoring更偏向“已知问题的发现”。它关注的是我们提前定义好一批关键指标和阈值当指标超过阈值时发出告警。监控解决的是“系统是否还健康”的问题。它的前提是团队知道自己需要盯哪些数字。可观测性Observability更偏向“未知问题的探索”。它关注的是当系统出现一个没有预料到的故障时我们能否基于已有的数据快速推断出根因。可观测性解决的是“系统为什么变成这样”的问题。一个直观的例子监控能告诉你“CPU 使用率 95%触发告警”但可观测性会进一步帮你在 Trace 数据中看到 CPU 飙高是因为某个新上线的接口逻辑存在死循环。换句话说监控告诉你“有问题”可观测性帮你“定位问题”。两者是递进关系监控系统是构建可观测性的基础设施可观测性是监控系统建设的更高目标。2. 环境准备与组件说明在开始搭建之前先说明本文示例所用的实验环境。软件版本更新比较快具体小版本号请以官方发布为准。组件说明操作系统LinuxCentOS 7 或 Ubuntu 20.04 均可本文以 Ubuntu 20.04 为例Prometheus2.x 系列负责指标采集、存储和 PromQL 查询Node Exporter1.x 系列负责采集主机层的 CPU、内存、磁盘、网络等指标Grafana10.x 系列或更高负责指标可视化展示Alertmanager0.2x 系列负责接收 Prometheus 告警并做消息路由、去重和通知如果你的项目使用的是 Docker 环境也可以全部用容器部署便于隔离和快速重建。本文采用二进制方式部署目的是让读者更清楚地看到每个组件的数据流和配置文件理解原理之后再考虑容器化也会更轻松。建议操作系统最少为 2 核 CPU、2GB 内存磁盘预留 20GB。生产环境中磁盘容量需要根据指标数量和保留周期单独评估后面会在最佳实践部分详细说明。3. 核心原理拆解Prometheus 是怎么工作的3.1 Prometheus 的架构与数据模型Prometheus 是一款开源的服务监控系统和时序数据库。它的工作流程可以简化描述为Prometheus 通过 HTTP 接口周期性“拉取”Pull被监控目标的指标数据。被监控目标通过 Exporter 把内部状态转换成 Prometheus 能识别的指标格式并通过 HTTP 暴露出来。Prometheus 把拉取到的指标按时间序列方式存储到本地 TSDB。用户通过 PromQL 查询数据或通过 Grafana 可视化展示。用户预先定义告警规则Prometheus 定期计算规则当满足触发条件时把告警推给 Alertmanager。在 Prometheus 中一条时间序列由三个要素唯一确定指标名称例如node_cpu_seconds_total表示 CPU 累计使用秒数。标签一组 key-value 对用于区分同一指标的不同维度。例如cpu0、instance192.168.1.10:9100。样本值由时间戳和数值组成。用下面的示例来表示一条数据node_memory_MemAvailable_bytes{instance192.168.1.10:9100, jobnode-exporter} 8388608000其中node_memory_MemAvailable_bytes是指标名{instance..., job...}是标签集合8388608000是当前值采样时自动附带时间戳。标签非常重要因为 PromQL 的聚合、分组、过滤都依赖标签。设计标签时如果滥用高基数标签每个样本取值特别多的标签例如把用户 ID 作为标签会导致时序数据膨胀拖垮查询性能和存储空间。这一点在最佳实践章节会展开讲。3.2 Prometheus 的四种指标类型Prometheus 客户端库支持四种核心指标类型类型特点典型使用场景Counter只增不减的计数器重启后可清零请求总数、错误总数、CPU 累计时间Gauge可增可减的瞬时值当前 CPU 使用率、内存使用量、在线连接数Histogram观测值分布统计可计算分位数请求耗时分布、响应体大小Summary类似 Histogram但分位数由客户端计算请求耗时百分位、需要精确分位数时以 Counter 为例因为它是“只增不减”所以查询“每秒请求数”时不能直接看原始值而要使用 rate 函数计算变化速率rate(http_requests_total[5m])这条语句表示统计最近 5 分钟内请求数的每秒平均增量。这个思路在监控里面很常见如果没有理解 Counter 的语义很容易拿原始值去做判断导致结果偏差。3.3 Pull 模型与 Push 模型对比Prometheus 默认采用 Pull 模型也就是由 Prometheus 主动去目标地址抓取指标而不是由业务主动上报。这样做的好处是Prometheus 可以随时通过/targets页面看到哪些目标在线、哪些离线。采集目标不需要感知监控系统的存在解耦了业务与监控。更容易做采集质量控制和问题排查。与之对应的 Push 模型则适用于一次性任务、短生命周期任务、无法被轮询的网络环境。Prometheus 提供了 Pushgateway 在中间层接收此类指标但生产环境要谨慎使用因为它会增加指标管理复杂度且容易造成指标长期不更新但仍在展示的问题。本文的监控对象是主机Node Exporter 天然支持 Pull所以我们直接按照 Pull 模型搭建即可。3.4 PromQL 基础PromQL 是 Prometheus 的查询语言是后续写仪表盘和告警表达式的基础。这里只列出最常用的几个操作帮助读者先能读懂示例。选择指定指标node_memory_MemTotal_bytes通过标签过滤node_cpu_seconds_total{cpu0, modeidle}使用正则匹配node_disk_io_time_seconds_total{device~sd.*}计算速率rate(node_cpu_seconds_total{modeidle}[5m])聚合计算sum(rate(node_cpu_seconds_total{modeidle}[5m])) by (instance)聚合表达式在生产中非常常用尤其是 CPU 使用率指标通常会按照模式维度做分组聚合后再进行计算。具体表达式会在后面的实战演练中完整给出。4. 完整实战搭建一套可落地的监控告警系统下面进入本文的实战部分。我们将逐步搭建一套能够采集主机基础指标、展示 Grafana 仪表盘、并在服务异常时发送告警的完整系统。4.1 下载并启动 Node Exporter打开 Prometheus 官网 Downloads 页面找到 node_exporter 的下载链接复制 Linux amd64 版本的 tarball 地址。cd /opt/ wget https://github.com/prometheus/node_exporter/releases/download/v1.8.2/node_exporter-1.8.2.linux-amd64.tar.gz tar xvf node_exporter-1.8.2.linux-amd64.tar.gz cd node_exporter-1.8.2.linux-amd64版本号请以官网实际发布为准上述命令中的1.8.2仅是一个示例版本。解压后直接运行二进制文件./node_exporter --web.listen-address:9100启动成功后可以访问http://服务器IP:9100/metrics在浏览器中可以看到大量以node_开头的指标例如node_cpu_seconds_total{cpu0,modeidle} 1.234567e06 node_memory_MemTotal_bytes 8.44e09 node_filesystem_avail_bytes{device/dev/sda1,mountpoint/} 6.78e09这些指标已经是 Prometheus 标准格式不需要做任何转换Prometheus 可以直接抓取。实际生产环境中不建议直接在前台运行 node_exporter更推荐使用 systemd 或 supervisor 托管进程实现开机自启、崩溃自动拉起和日志管理。以 systemd 为例[Unit] DescriptionNode Exporter Afternetwork.target [Service] Userprometheus ExecStart/opt/node_exporter-1.8.2.linux-amd64/node_exporter --web.listen-address:9100 Restartalways RestartSec5 [Install] WantedBymulti-user.target将文件保存为/etc/systemd/system/node_exporter.service然后执行systemctl daemon-reload systemctl enable --now node_exporter这样即使机器重启Node Exporter 也会自动运行。4.2 安装并配置 Prometheus创建 Prometheus 数据目录和配置目录mkdir -p /opt/prometheus/data mkdir -p /etc/prometheus cd /opt/ wget https://github.com/prometheus/prometheus/releases/download/v2.53.0/prometheus-2.53.0.linux-amd64.tar.gz tar xvf prometheus-2.53.0.linux-amd64.tar.gz cd prometheus-2.53.0.linux-amd64同样地版本号请以官网为准。接下来编写核心配置文件/etc/prometheus/prometheus.ymlglobal: scrape_interval: 15s evaluation_interval: 15s scrape_configs: - job_name: node-exporter static_configs: - targets: [localhost:9100]配置说明scrape_intervalPrometheus 每隔多长时间抓取一次指标默认 15 秒。evaluation_intervalPrometheus 每隔多长时间计算一次告警规则。job_name一组采集任务的名称会作为标签job写入每条时序数据。targets需要被抓取的地址列表可以写多个。启动 Prometheus/opt/prometheus-2.53.0.linux-amd64/prometheus \ --config.file/etc/prometheus/prometheus.yml \ --storage.tsdb.path/opt/prometheus/data也可以添加--web.listen-address:9090指定监听端口。启动后访问http://服务器IP:9090能看到 Prometheus 自带的查询页面。点击顶部导航栏的 Status - Targets可以看到node-exporter任务处于 UP 状态这代表采集正常。4.3 通过 PromQL 查询主机核心指标在 Prometheus 查询页面输入以下表达式点击 Execute 查看结果。CPU 使用率100 - avg(rate(node_cpu_seconds_total{modeidle}[5m])) * 100这里的逻辑是先计算 5 分钟内 CPU 空闲时间的每秒变化率取平均值后得到空闲比例再用 100 减去它得到 CPU 使用率。内存使用率(1 - node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) * 100磁盘使用率(1 - node_filesystem_avail_bytes{mountpoint/} / node_filesystem_size_bytes{mountpoint/}) * 100节点在线状态upup是 Prometheus 自动生成的指标值为 1 时表示采集目标在线值为 0 时表示离线。这个指标非常适合用作主机存活告警。如果以上查询都能返回正常数值说明监控采集链路已经打通。4.4 安装 Grafana 并配置仪表盘Grafana 负责把 Prometheus 中的数据变成可视化图表。Ubuntu 下可以通过 apt 安装sudo apt-get install -y software-properties-common sudo add-apt-repository deb https://packages.grafana.com/oss/deb stable main wget -q -O - https://packages.grafana.com/gpg.key | sudo apt-key add - sudo apt-get update sudo apt-get install -y grafana安装完成后启动sudo systemctl enable --now grafana-server访问http://服务器IP:3000默认用户名和密码均为admin首次登录会要求修改密码。登录后按以下步骤配置数据源左侧菜单栏点击 Connections - Data sources。点击 Add data source选择 Prometheus。在 HTTP URL 一栏填写http://localhost:9090。点击底部的 Save test提示 Success 即表示连接成功。数据源配置完成后可以手动创建一个 Dashboard也可以导入官方现成的仪表盘模板。以 Node Exporter Full 模板为例在 Grafana 左侧 Dashboards 页面点击 Import输入模板 ID点击 Load然后选择刚才配置的 Prometheus 数据源并导入。导入完成后就能看到包含 CPU、内存、磁盘、网络等图表的完整主机监控面板。如果想自己手动创建一个面板在 Dashboard 中点击 Add - Visualization选择 Prometheus 数据源在查询框中输入上面的 PromQL 表达式例如 CPU 使用率表达式图表类型选择 Time series即可看到实时曲线。手动创建面板的好处是能更深入理解每个指标的计算逻辑。4.5 配置 Alertmanager 实现告警通知监控数据可视化只是第一步真正让监控产生价值的是告警通知。当指标异常时值班人员需要及时收到消息。Alertmanager 负责处理告警的接收、去重、分组和路由。下载并解压 Alertmanagercd /opt/ wget https://github.com/prometheus/alertmanager/releases/download/v0.27.0/alertmanager-0.27.0.linux-amd64.tar.gz tar xvf alertmanager-0.27.0.linux-amd64.tar.gz cd alertmanager-0.27.0.linux-amd64创建配置文件/etc/prometheus/alertmanager.yml下面是一个使用 Webhook 通知的简化示例route: group_by: [alertname, instance] group_wait: 30s group_interval: 5m repeat_interval: 4h receiver: webhook receivers: - name: webhook webhook_configs: - url: http://localhost:8080/alert配置说明group_by告警分组字段相同 instance 上的告警会合并成一条通知。group_wait组内第一条告警等待多久再发送用于缓冲短时间内的告警风暴。repeat_interval同一条告警重新通知的间隔避免不断骚扰。receivers定义告警被发送到哪个渠道Webhook、邮件、钉钉、企业微信等都可以。启动 Alertmanager/opt/alertmanager-0.27.0.linux-amd64/alertmanager \ --config.file/etc/prometheus/alertmanager.yml默认监听端口为9093。接下来在 Prometheus 中定义告警规则。创建目录并新建规则文件/etc/prometheus/rules/host.ymlgroups: - name: host-monitoring rules: - alert: HostDown expr: up 0 for: 1m labels: severity: critical annotations: summary: 主机 {{ $labels.instance }} 已离线 description: 主机 {{ $labels.instance }} 已经超过 1 分钟无法采集到指标。 - alert: HighCpuUsage expr: 100 - avg(rate(node_cpu_seconds_total{modeidle}[5m])) * 100 90 for: 5m labels: severity: warning annotations: summary: 主机 {{ $labels.instance }} CPU 使用率过高 description: CPU 使用率已持续超过 90%当前值为 {{ $value }}%。规则说明alert告警规则名称。expr触发条件表达式当计算结果大于阈值时进入 Pending 状态。for条件持续多长时间才触发告警用于过滤瞬时抖动。labels为告警附加标签。annotations告警通知里展示的摘要和详情内容。修改 Prometheus 配置文件在末尾加入 rules 路径rule_files: - /etc/prometheus/rules/*.yml重启 Prometheuspkill -f prometheus /opt/prometheus-2.53.0.linux-amd64/prometheus \ --config.file/etc/prometheus/prometheus.yml \ --storage.tsdb.path/opt/prometheus/data重启后访问 Prometheus 的 Alerts 页面可以看到刚才定义的两条规则已经加载。此时如果直接停掉 Node Exporter 或者使用压测工具拉高 CPU等待一段时间后就能看到告警状态从 Inactive 变为 Pending再变为 Firing并推送到 Alertmanager。Alertmanager 最终会按配置的 Webhook 地址发出 HTTP 请求。如果本地没有配置 Webhook 接收端可以使用邮件方式验证。在 Alertmanager 配置中增加一个 email 接收器即可但生产环境更推荐使用办公即时通讯工具的机器人 Webhook例如钉钉或企业微信自定义机器人这类方式配置简单、到达率高且不需要维护邮箱服务器。5. 常见问题与排查思路监控系统搭好后经常会遇到一些看起来不起眼但很影响使用体验的问题。下面把高频问题整理成表格再补充详细排查思路。问题现象常见原因解决思路Targets 页面显示 DOWNExporter 未启动端口不通防火墙拦截检查进程、端口、防火墙指标为空查询无数据Job 名或标签写错数据源选择错误检查 PromQL 标签过滤条件检查 Grafana 数据源告警一直不触发表达式写错for 持续时间未满足先在 Prometheus 查询页手动执行表达式告警风暴频繁阈值调整成固定值未结合业务周期使用动态阈值、增加 for 时长、按业务周期分组磁盘占用快速增长指标数量过多、保留周期过长调整 storage 保留时间减少高基数标签对历史数据做归档Grafana 数据显示时区不正确浏览器与时区设置不一致在 Grafana 默认设置中调整时区为 Asia/Shanghai5.1 Node Exporter 未启动导致 DOWN如果在 Prometheus Targets 页面看到目标状态是 DOWN第一步先在本机访问 Exporter 的 metrics 地址curl http://localhost:9100/metrics如果连接拒绝说明 Node Exporter 进程没有运行或端口配置不对。检查进程和监听端口ps -ef | grep node_exporter ss -lntp | grep 9100如果 curl 正常返回但 Prometheus 依然显示 DOWN需要检查 Prometheus 所在机器能否访问到该地址以及服务器防火墙是否放行了 9100 端口。5.2 查询结果为空PromQL 返回空数据时优先检查指标名称和标签是否匹配。例如写了node_memory_MemFree_bytes但当前 Exporter 指标名实际是node_memory_MemAvailable_bytes就会查不到数据。可以在 Prometheus 的查询页输入node_memory_MemTotal_bytes不带任何标签看是否有结果再逐步添加过滤条件。5.3 告警不触发告警表达式写完后先在 Prometheus 查询页手动执行一遍确认表达式结果能达到阈值。如果表达式本身输出为空那告警自然也不会触发。另外注意for字段只有当条件持续满足指定时间后告警才会从 Pending 转为 Firing刚开始测试时建议把 for 设短一些比如 10s确认整套链路通后再调整成生产值。5.4 告警重复通知告警重复通知通常由repeat_interval设置过短引起。生产环境建议设置为 4 小时以上避免一个故障持续期间值班人员收到大量重复消息。同时配合group_wait和group_interval做分组聚合把同一时间的相关告警合并成一条通知。6. 最佳实践与工程建议6.1 指标命名与标签设计指标命名最好遵循统一规范。Prometheus 社区的经验是使用“命名空间_子系统_单位_描述”的格式例如node_cpu_seconds_total、http_request_duration_seconds。如果公司内部有统一的指标规范优先遵守团队规范而不是自己另搞一套。标签设计要重点控制基数。不要把请求 ID、用户 ID、订单 ID 这类取值无限的字段放进标签里。高基数标签会显著增加时序数据量拖慢监控系统整体性能。如果需要按用户维度分析建议把这类数据放到日志系统里通过日志检索来定位而不是放进 Prometheus 指标中。6.2 告警设计要“可行动”告警不是越多越好也不是越灵敏越好。好的告警应该满足两个条件第一收到告警的人不需要再花大量时间排查才能判断问题严重性第二告警对应一个明确的响应动作。一条告警通知里至少要包含以下信息发生了什么问题指标名和当前值。影响范围哪台机器、哪个服务、哪个地域。已经持续多久。应该找谁来处理是否有可用的应急预案。很多团队把全部监控项都配上告警结果就是告警风暴让值班同学麻木最终真正重要的告警也被忽略。建议每一条告警规则都经过评审持续修不好的“狼来了”告警应该被优化或关闭。6.3 使用 Systemd 管理监控组件不要用nohup或者直接在 Shell 里后台运行监控组件推荐使用 systemd 全部托管。这样能保证进程崩溃后自动重启开机后自动拉起同时journalctl -u prometheus也能方便地查看日志。生产环境还要考虑监控组件自身的可用性有条件的话监控节点也应该做高可用避免监控系统单点。6.4 控制数据保留周期与磁盘容量Prometheus 默认将数据保存在本地磁盘默认保留 15 天。这个参数可以启动时用--storage.tsdb.retention.time修改。数据保留时间越长磁盘开销越大查询性能也会受到影响。本文演示环境指标量很小但生产环境如果管理几万台机器的指标需要认真做容量规划。一个简单的估算方式是每天新增指标数据量约等于采样指标总数乘以每个样本的平均大小再乘以每天采样次数。可以先运行一段时间观察磁盘增长速率再反推合适的保留周期和磁盘规格。6.5 安全边界Prometheus、Grafana、Alertmanager 都提供了 Web 管理页面默认没有鉴权时任何人都可以访问这是很大的安全隐患。至少应该做到将监控组件部署在内网或专有网络。对 Grafana 配置强口令并开启登录鉴权。通过反向代理或防火墙对 Prometheus 管理端口做访问控制。如果必须暴露到外网配置 HTTPS 和认证。对 Exporter 的访问地址做白名单限制避免被恶意采集或信息泄露。6.6 监控系统自身的测试监控系统上线后要定期做“故障演练”。例如主动停掉一个 Node Exporter确认告警能否在预期时间内到达主动拉高 CPU 使用率确认告警内容和阈值是否符合预期。很多团队在搭建监控时花了很多精力但从来没有真正验证过告警链路是否可用直到线上故障发生时才发现问题这种教训代价很高。7. 总结与下一步学习方向这篇文章从可观测性的基本概念讲起梳理了 Metrics、Logging、Tracing 三大支柱的定位也区分了“监控”和“可观测性”的差异然后通过完整的手把手实操搭建了一套基于 Prometheus Node Exporter Grafana Alertmanager 的主机监控告警系统。现在你应该已经掌握了Prometheus 的数据模型和四种指标类型。Pull 模型与 Push 模型的核心区别。通过 PromQL 查询 CPU、内存、磁盘等核心指标。编写 prometheus.yml 和告警规则。Alertmanager 的分组、路由和通知配置。监控系统开发过程中容易踩的常见坑。如果接下来想继续深入可以考虑以下几个方向一是把监控对象从主机扩展到应用层。可以接入 Spring Boot Actuator、Gin、Django 等框架的指标端点采集 JVM、线程池、HTTP 接口 QPS 和响应时间等业务指标。二是引入日志采集系统例如 Loki 或 ELK并尝试把日志、指标、告警联动起来形成完整的故障定位闭环。三是学习 Kubernetes 场景下的监控方案理解 kube-state-metrics、cAdvisor、Prometheus Operator 的工作原理。最后建议读者不要停留在“把监控搭起来”这个阶段而是持续打磨监控指标体系把每个告警都优化到“收到消息就能直接知道该干什么”的程度。看完文章后可以亲手做一遍实验尝试停掉进程、模拟高负载、修改告警阈值真正跑通整个故障发现与通知流程。这样在遇到线上问题时你才能从“看谁先发现”变成“系统第一时间告诉你发生了什么”。