第 5 章　动手之前

原书：Chapter 5. Before You Start（p.78–103） 翻译策略：技术直译 + 段落重排；专有项目名、协议名、API 名、CLI 命令、配置字段、证书/加密术语一律保留英文；首次出现的关键概念以"中文（English）"形式给出，后续沿用英文。术语对照见 TERMS.md。

章节导言

本章帮助你为 SPIFFE / SPIRE 的落地做各项决策做铺垫。

先搞定人

如果你已经读过前面几章，你一定迫不及待地想开始用 SPIRE——以那种"在多种系统和组织所有服务上都可以复用"的方式管理身份。但在动手之前，你需要意识到部署 SPIRE 是一次影响面很广的基础设施变更。本章讲的是如何规划一次 SPIRE 部署：如何争取支持、如何无中断地开启 SPIRE 支持，然后再用它来实施新的安全控制。

组建团队并识别其他利益相关方

要部署 SPIRE，你需要从安全、软件开发、DevOps 三个团队里识别利益相关方：

• 谁来维护 SPIRE Server 本身？
• 谁来部署 Agent？
• 谁来写注册条目？
• 谁来把 SPIFFE 能力集成进应用？
• 它会如何影响现有的 CI/CD 流水线？
• 出现服务中断时，谁来修？
• 性能需求和服务等级目标（Service Level Objective）是什么？

无论是本书、还是大量公开博客和会议演讲，都提供了组织成功部署 SPIRE 的案例——这些案例既可以作为你照搬的模式，也可以作为你向同事布道 SPIRE 的素材。

摆出你的理由并争取支持

SPIRE 横跨多个传统 IT 筒仓，所以可以预期你的 DevOps 团队、软件开发团队、安全团队之间会有更多跨组织协作。他们必须协同工作，才能保证部署顺利无缝。你需要理解每个团队的不同诉求和优先级——并相应地给出能让他们点头的理由。

在规划 SPIRE 部署时，你需要理解对业务而言最重要的产出是什么，并把这些作为项目驱动力以及你所交付方案的价值所在。每个团队都需要看到 SPIFFE 对他们自己、对整个业务的好处。第 2 章已经描述了 SPIRE 部署的诸多好处；本节会挑选几条最值得拿来当"卖点"的好处。

给安全团队的理由

减少安全团队的工作量是部署 SPIRE 最具说服力的理由之一：他们不必再去部署一堆"打补丁"式的安全方案，也不需要手动管理成百上千张证书——他们可以专注于设计合理的注册条目，保证每个服务拿到正确的身份。

一个更长远的收益是：SPIRE 能提升组织的整体安全姿态——SPIRE 不存在容易被偷或被滥用的凭证。与凭证盗用、滥用、敏感数据泄露相关的一大类攻击都可以被缓解。你甚至可以向外部审计员证明：正确的服务正在安全地相互通信。

给软件开发团队的理由

对应用开发团队来说，不再需要等工单或人工流程来签发证书是他们能跑得更快、也是最有说服力的理由。如果他们目前正在手工把秘密随代码一起部署，并且因此被安全团队反复"教育"——这种日子到头了。他们也无需在秘密存储里管理秘密了。

第二个好处是：软件组件可以以"以前无法安全做到"的方式直接通信。如果云服务因为"没有安全方式"而无法访问某个关键数据库或关键云服务，那就有可能用 SPIFFE 身份建立一条安全连接——为团队打开新的架构可能性。

给 DevOps 团队的理由

部署 SPIRE 最大的收益属于 DevOps 团队。如果每个服务都有自己的安全身份，那么服务就可以被部署到任何地方——任何本地数据中心、任何云厂商、同一云厂商的任何 region。这种新的灵活性让部署决策可以独立于安全要求做出来，从而降低成本、提升扩展性、改善可靠性。

对 DevOps 团队来说另一个关键收益是：每个服务的入站请求都带有一个 SPIFFE ID——可以被记录、计量、并上报到监控系统。这在拥有成百上千个服务的大型组织里对性能管理极其有用。

制定计划

规划 SPIRE 部署的首要目标是：确定"每个服务都需要 SPIFFE 化"，还是"非 SPIFFE 服务的孤岛"也能满足要求。把所有服务都迁到 SPIFFE 是最直接的方案，但在很大的组织里一口气推下去可能很困难。

孤岛与桥

有些环境很复杂——要么有多个组织交织，要么是遗留系统与新开发并存。在这种场景下，常常希望只把环境的一部分 SPIFFE 化。需要根据系统之间的集成度以及跨系统复杂度，从两个选项中选一个。我们把这两个架构叫做：Independent Islands（独立孤岛） 和 Bridged Islands（桥接孤岛）。

每个孤岛被视为一个 Trust Domain，岛上的工作负载或称"居民（resident）"。

独立孤岛

图 5.1　两个独立 SPIFFE 部署（独立孤岛）（见 assets/pages/page-082.png）。

独立孤岛模型让各个 Trust Domain 互相独立运行。这通常是最简单的选项——因为每个孤岛可以按对自己最合理的方式跑 SPIRE。

桥接孤岛

图 5.2　两个独立 SPIFFE 部署通过 Federation 桥接，让每个岛上的服务能够信任对方，进而通信。但 SPIFFE 岛和非 SPIFFE 岛之间仍然没有通信（见 assets/pages/page-083.png）。

图 5.3　在非 SPIFFE 岛上加 gateway，是桥接 SPIFFE 岛与非 SPIFFE 岛的一种方式（见 assets/pages/page-083.png）。

图 5.4　在这张图里有一个 SPIFFE 化的生态（"大陆"），而这个生态中有一片非 SPIFFE 服务的口袋（"湖心岛"）。大陆与岛上的服务要彼此通信，就必须有 gateway（见 assets/pages/page-084.png）。

图 5.5　桥接孤岛架构（见 assets/pages/page-085.png）。

桥接孤岛模型允许非 SPIFFE 岛上的非 SPIFFE 服务与一个 gateway 通信。gateway 再把请求转发到 SPIFFE 岛上的目标"居民"——我们叫它 Zero。从 Zero 的视角看，请求是 gateway 发出的。Zero 和 SPIFFE 岛上的"朋友"可以向 gateway 认证，进而把消息发给非 SPIFFE 岛上的服务。

在桥接孤岛架构下，gateway 会被创建在非 SPIFFE 岛上。非 SPIFFE 岛之所以没法轻易采用 SPIFFE 架构，原因可能有很多：可能存在无法轻易修改或更新的遗留软件；可能孤岛使用的是自己的身份体系（比如 Kerberos，或第 9 章中描述的其他方案之一）；也可能系统跑在现有 SPIFFE 方案（比如 SPIRE）所不太适配的技术上。

在这些情况下，用 gateway 服务把 SPIFFE 世界和非 SPIFFE 岛桥接起来是很有用的。当 SPIFFE 化的工作负载想与非 SPIFFE 岛上的工作负载通信时，它先与 gateway 建立一条已认证的连接，gateway 再与目标工作负载建立连接。这条到目标工作负载的连接可以是不带认证的，也可以使用该岛的非 SPIFFE 身份方案。反过来，当非 SPIFFE 岛上的工作负载想与 SPIFFE 化工作负载通信时，非 SPIFFE 工作负载先连上 gateway，gateway 再以 SPIFFE 认证的方式连到目标 SPIFFE 化工作负载。

在这种情况下，发生在 gateway 与 SPIFFE 化工作负载之间的认证在 gateway 处终止。这意味着：SPIFFE 化工作负载只能验证"自己在与一个合适的 gateway 对话"，但它无法验证"对话的另一端、gateway 背后那个具体的工作负载是否就是它要的那一个"。同样，目标工作负载只知道"gateway 服务给它发了个请求"，但丢失了原始 SPIFFE 化工作负载的认证上下文。

这个模型让那些复杂的组织可以开始采用 SPIFFE，而不必一次性完成所有转换。

在请求与工作流需要穿越非 SPIFFE 岛的场景下，用 JWT-SVID 跨请求传递身份是很有用的。更好的做法是：用 X509-SVID 签名文档（比如 HTTP Message Request Signing，即"HTTP 消息签名"，参考 tools.ietf.org/id/draft-cavage-http-signatures-...），而不仅仅依赖"服务到服务的互信 TLS"——这样 SPIFFE 化工作负载在另一端就能验证整条消息的真实性。这在那些已知"安全属性较弱"的孤岛里特别有用——它能让你对"经由中间生态转发的消息没有被篡改"有信心。

文档与可观测性

在准备上线时，为服务加上合适的埋点很重要——要能让指标和流量日志以这样的方式输出：

• 负责上线的人知道哪些服务已经 SPIFFE 化、哪些没有，各有多少。
• 客户端作者知道他们调用的服务里哪些是 SPIFFE 化的、哪些不是。
• 服务所有者知道哪些客户端在调用他的 SPIFFE 化端点、多少客户端还在调用遗留端点。

在上线之前，为客户端与服务端实现者准备参考文档很重要——这份文档应该预判你可能收到的支持请求类型。

创建一些工具来辅助常见调试和排错也很重要。回顾 SPIFFE 和 SPIRE 的好处，把 SPIFFE 引入你的组织应当赋能开发者、清除路障。如果让利益相关方觉得"你在增加工作量、带来摩擦"，最终会拖慢甚至阻断更广泛的采用。为了避免这一点、确保文档和工具覆盖到合适的话题，我们建议以下这些准备步骤：

表 5.1　上线前的准备清单（参考 assets/pages/page-088.png）

步骤	注释
决定 SPIFFE 身份需要支持哪些安全特性	例如用 SPIFFE 身份建立互信 TLS、用于授权、或其他功能，比如审计日志
确定 SVID 的格式以及使用目的	最常见的是用 X509-SVID 做互信 TLS，但确认是否适用以及是否还会用于其他应用
确定需要身份的工作负载数量	不是每个工作负载都需要身份，尤其是在早期
确定所需的独立 Trust Domain 数量	每个 Trust Domain 都需要自己的 SPIRE Server 部署。如何做这个决策详见下章
确定组织内需要与 SPIFFE 兼容的语言、框架、IPC 技术等	如果用 X509-SVID 做互信 TLS，需要确定组织内用了哪些 web server（Apache HTTPD、NGINX、Tomcat、Jetty 等）以及哪些客户端库。如果客户端库期望做 DNS hostname 校验，要保证你的 SPIFFE 部署兼容这种期望

理解性能影响

性能影响应当作为部署规划的一部分。

在准备上线时，应当对组织在产环境跑的各种工作负载做基准测试——以确保你至少意识到（并希望能处理）上线过程中可能出现的任何性能问题。

TLS 性能

在很多组织里，开发与运维团队抛出的第一个担忧是"服务间互信 TLS 太慢"。在现代硬件、配合现代 TLS 实现的情况下，TLS 的性能影响极小：

「在我们产环境的前端机器上，SSL/TLS 占用的 CPU 负载不到 1%、每个连接占用的内存不到 10KB、网络开销不到 2%。很多人认为 SSL/TLS 会吃很多 CPU，希望前面的数字能消除这种误解。」—— Adam Langley，Google，《Overclocking SSL》（参考 www.imperialviolet.org/2010/06/25/overclocking-...），2010 年

「我们已经用硬件和软件负载均衡器把 TLS 部署到了很大规模。我们发现，在商用 CPU 上跑的现代软件 TLS 实现足够快，完全能扛得住重型 HTTPS 流量，不必上专用加密硬件。」—— Doug Beaver，Facebook，HTTP/2 Expression of Interest（参考 lists.w3.org/Archives/Public/ietf-http-wg/2012J...），2012 年

关键洞察：通常，性能影响取决于多种因素——网络拓扑、API 网关、L4–L7 防火墙，等等。另外，你使用的协议及其实现、证书与密钥的尺寸也会影响性能——所以这是一个相当广泛的话题。

下表给出了两个阶段相对 TCP 的开销数据点，专门针对握手与数据传输阶段：

表 5.2　TLS 各阶段相对 TCP 的开销（参考 assets/pages/page-090.png）

TLS 阶段	协议开销	延迟	CPU	内存
握手	TLS 2 kB；mTLS 3 kB + 每多一张证书 +1 kB	12–17 ms	比 TCP 多约 0.5%	< 10 kB / 连接
数据传输	22 B / 包	< 3 µs	比 TCP 多不到 1%	< 10 kB / 连接

推动 SPIFFE / SPIRE 的落地

关于"组织如何应对、推动和处理变更"有大量研究历史。关于"新技术在公众中和组织中的接受与采用"也有很多有趣的研究。要把这些话题讲透超出了本书范围，但如果不提它们，就对不起"一次成功的 SPIFFE 上线"的相关性。

说服变革发生

有几种办法能说服他人变革在组织内必须发生。下面列出了你能用 SPIFFE / SPIRE 来推动变革的方式。

• 感知有用性（Perceived usefulness）——有人会认为 SPIFFE 在多大程度上能帮助他们提升工作绩效。展示可量化的成果有助于提升感知有用性。
• 感知易用性（Perceived ease-of-use）——有人会认为 SPIFFE 有多易用。对开发者和运维的用户体验保持专注至关重要。
• 同伴影响（Peer influence）——某人对"被自己尊敬的他人"如何看待 SPIFFE 采纳、以及他们是否已经采纳的感知。这是在组织里积攒的政治资本发挥作用的时候——通常说服对的人比试图说服所有人更关键。
• 形象（Image）——采纳 SPIFFE 在多大程度上能提升某人在组织里的地位。
• 自愿性（Voluntariness）——潜在采纳者把这次采纳视为自愿的还是强制的。效果如何取决于公司文化和个人性格。面对"被强制采纳者"和"顽固派"时（见本章稍后），要把这点记在心里。

图 5.6　技术采纳曲线（改编自 Roger 钟形曲线和 Gartner 炒作周期）。蓝色面积代表变更量与 SPIFFE 采纳者的数量（参考 en.wikipedia.org/wiki/Technology_adoption_life_...）。红线代表对 SPIFFE 采纳的热情与期望（见 assets/pages/page-091.png）。

采纳行为者

采纳行为者（adoption actors） 与技术曲线相对应，能帮你对"推动 SPIFFE / SPIRE 落地的过程会怎样发生"设定预期。下面列出了技术曲线中提到的采纳行为者，并加上了两个你很可能遇到的角色。

关于技术曲线中的采纳行为者，本书之外的资料里有更多信息。

• 创新者（Innovators）——就当你就是组织里的创新者——读了本书、读到了这里、决定往前推进。你本质上是在为"把 SPIFFE 和 SPIRE 加进架构"这件事打先锋——你需要帮助！建议提供"白手套"级别的支持与手把手辅导——一定要从"低垂果实"和"先行者"两类中（见下文）挑选你关系不错的志愿者。
• 早期采纳者（Early adopters）——重要的是把从"白手套 / 手把手"支持中得到的经验提炼成容易获取和理解的文档、好用的工具、可扩展的支持渠道。可能需要做不少工作来让"先决条件与推动者（precursors and enablers）" SPIFFE 化（本章稍后详述），让开发者不再被卡、进而能给自己的服务端和客户端 SPIFFE 化。
• 早期与晚期大多数（Early and late majority）——等你开始接入"早期大多数"的服务时，SPIFFE 化的过程应该已经是一台运转良好的机器。所有常用的推动者——CI/CD、工作流引擎、编排器、容器平台、服务网格——都应该已经 SPIFFE 化，这样应用开发者无论应用怎么部署、都能在应用全生命周期中得到支持。
• 落后者（Laggards）——你的组织里很可能有保守的落后者——原因可能是团队文化、个人性格、监管或合规要求。重要的是不要急着下结论——不要立即认定某个服务所有者就是这一类人——而是要调查根因并恰当地解决。
• "被迫"转化者（'Forced' converts）——一个 SPIFFE 化服务的最后一个采纳者，可能会觉得是被迫转化的。重要的是为这些"被迫转化者"做好准备，保证他们采纳 SPIFFE 的体验是正向的。
• 顽固派（Holdouts）——他们一定会出现。要让采纳过程简单、并且有激励。突出那些"已经在生产力高原上享受收益"的例子。你应该预期要为顽固派提供额外支持、并且手把手带着他们走完流程。

选择谁先上时的考量

在选择"谁先上"时，保持跨组织的最大兼容性是关键。服务应当保留它们现有的 API 接口和端口不变，把它们的 SPIFFE 化 API 放到新端口上。这能实现平滑切换，并方便在需要时回滚。客户端来自许多其他服务团队的服务，预计要维护和支持两个端点相当长一段时间（> 6 个月）。

一旦一个服务的所有客户端都 SPIFFE 化了、并且非 SPIFFE API 也不再被使用，就可以把非 SPIFFE API 关闭。

⚠️ 小心别过早关掉遗留端点。特别留意批处理任务、定时任务，以及其他不频繁、不规律的调用模式。你不希望成为那个"让季末或财年末对账任务跑挂"的家伙。

图 5.7　简化的微服务调用图（见 assets/pages/page-095.png）。

如果你的环境太大或太复杂，无法一蹴而就，在选择服务的 SPIFFE 化顺序时需要仔细思考。从"大石头、低垂果实、先决条件与推动者"这三个角度去思考，有助于加速采纳。

大石头（Big Rocks）

"大石头"是那些客户端最多、或与最多唯一服务相连的服务。尽早啃大石头看似诱人（可以加速采纳），但很可能会贪多嚼不烂、引发问题、把别人吓得不敢采纳。

关键洞察：看上方的调用图，大石头由"连接最多的"节点来识别。它们可能是被许多客户端调用的关键服务（比如 Service 0）；也可能是调用了许多服务的客户端（比如 Service 4）。大石头也可能包括既是客户端也是服务端的服务，比如 Service 7。迁移这类服务既带来收益也带来风险：

收益

• 吸引人的选择
• 潜在加速采纳
• 影响面广
• 激励其他人采纳

风险与挑战

• 在较长一段时间内维护两个端点（遗留 + SPIFFE 化）
• 在所有客户端都采纳 SPIFFE 之前不能关掉遗留端点
• 维护成本上升
• 复杂度上升
• 撑大组织容量
• 强制采纳
• 团队怨声载道
• 惊喜：角落里还有一只乌龟！

低垂果实（Low Hanging Fruit）

"低垂果实"是那些只有一两个客户端、或只连一两个服务的服务。这些通常最容易引导完成过渡，是理想的首批采纳者。

看回上面的同一张图，低垂果实是那些连接很少的节点。它们可能是某个只连另一个服务的客户端（比如 Service 2）；也可能是只有一个客户端的服务（比如 Service 8）。在选择"先迁哪些最少连接的服务"时，明智的做法是选那些"最容易维护双端点（遗留 + SPIFFE）"的，或者"必须维护双栈的时间最短"的。

收益

• 一旦出问题影响面小
• 更容易从遗留完整切到 SPIFFE，因为所需协调与规划更少
• 很好的实践与学习机会

风险与挑战

• 上线可能显得慢
• 可能不够醒目、不够有冲击力，难以激发关键服务所有者的采纳

加速采纳

在复杂、异构的环境下，有若干"先决条件与推动者"可以显著加速 SPIFFE 的采纳。它们各有不同的收益与挑战。上面的考量这里也适用——选那些影响面最广的系统，并且在没有 100% 确定所有非 SPIFFE 消费者都已转换前，不要关掉非 SPIFFE 功能。

先决条件包括能帮助别人采纳 SPIFFE 的工具与服务（比如 CI/CD 与工作流引擎）。开发与运维工具应该被提供给首批采纳者（创新者），并随着早期采纳者逐步接入而迭代改进。目标是当"早期大多数"加入时，赋能工具与服务已经达到成熟。如果对先决条件的投入不够，"晚期大多数"和落后者会很挣扎。

开发者工具

拥有能提升生产力的工具是 SPIFFE 成功上线的关键。整理出一份组织里现有工具的清单——覆盖应用全生命周期，从开发、运维、到下线——并考虑现有工具中哪些应当 SPIFFE 化、是否需要新建、购买或部署新工具。花在"创建、集成、改进工具"上的时间和精力往往有"力倍器"效应——能节省其他人的时间与精力，从而让过渡更顺畅。

关键洞察：工具不应该被孤立构建或购买，而应该与目标用户协商——最好以增量、迭代的方式。做到位需要时间。

"什么时候一个工具对首批和早期采纳者来说'够用'"是一个判断题。少数情况下，工具的第一版就够"早期与晚期大多数"用。

CI/CD 系统

在 CI/CD 工具里实现 SPIFFE 对组织里其他服务的 SPIFFE 采纳影响很大——因为大多数团队都会和 CI/CD 系统有规律性交互。但反过来说，这意味着让 CI/CD 系统的所有消费者都具备 SPIFFE 意识是一件大工程，可能需要很长时间才能关掉所有非 SPIFFE 集成。

容器编排器

如果你的组织已经在用容器编排器（比如 Kubernetes），那你已经成功一半了！ 编排器可以很方便地在你的工作负载前面挂上SPIFFE 感知的代理（SPIFFE-aware proxy），让开发者不必为 SPIFFE 操心。

服务网格

大型微服务架构里的服务网格（service mesh） 与 SPIFFE 部署的推动者特别相关——因为在服务网格里引入 SPIFFE 支持是把采纳面铺开的好办法，而不需要拉开发团队下场。

服务网格的相关性也伴随着一些风险与挑战。你可以想象，把服务网格搞坏可能在大范围产生影响，并可能以灾难性失败收尾。

规划 SPIRE 的运维

日常运行 SPIRE

建议负责管理与支持 SPIRE 基础设施的团队尽早介入。取决于你的组织结构，负责整个生命周期的很可能是你的安全团队或平台团队。

另一个需要思考的方面是：如何拆分"涉及系统安全、性能、可用性变更"的操作。任何与 PKI、HSM、密钥轮换以及相关运维沾边的事，都可能需要更严格的控制与门禁。你可能已经有一份变更管理流程——如果没有，现在就是开始落实它的好时机。

你的团队需要为各种故障场景编写 Runbook，并测试它们——知道该怎么处理、需要看哪些关键指标、配置监控和告警。你大概已经知道会用哪些监控告警系统，但理解 SPIRE Server 和 Agent 给出的遥测数据和指标、以及它们代表什么，能帮你的团队规避停机。

测试韧性

故障注入演练能帮助运维人员分析系统在不同故障条件下的表现。你可能对"系统在该架构下的反应"抱有某些假设；但 SPIRE 部署中确实存在多个潜在的故障点，值得专门去触发一下，以验证你的假设——这对你的运维团队也是好的实践，能保证他们把所有告警和 Runbook 都准备到位。

我们整理了一份清单，列出了一些你想纳入故障测试计划的场景。这不是一份完整指南，只是一份起点——用来为你的具体环境和部署模型构建检查表。理想情况下，你应该用两种不同的停机时长来跑所有这些测试：短于所配 TTL 的一半、长于所配 TTL。

1. 如果 SPIRE 部署使用单个数据库实例，把数据库干掉。
2. 如果 SPIRE 部署使用的是带一个写副本、多个读副本的数据库集群，把写实例干掉。
3. 模拟数据库丢失、测试数据恢复。如果你无法恢复数据、或者只能从一个月前的数据恢复，会怎么样？
4. 在 HA 部署中干掉几台 SPIRE Server。
5. 在 HA 部署中干掉负载均衡器。
6. 在 Agent 完成证明之后把 Agent 干掉，或者完全模拟 SPIRE Server 丢失。
7. 如果使用 upstream authority，模拟 upstream authority 失败。
8. 模拟根 CA 与中间 CA 被攻破、轮换与撤销。

为每个测试场景定义哪些指标最有用，记录它们预期健康与危险的区间，并随时间持续测量。

这些场景应当被良好地文档化、预期输出被清晰地定义，然后通过自动化测试自动、定期地执行。

日志

像所有系统一样，日志是 SPIRE 不可或缺的一部分。然而，SPIRE 产生的日志同时也充当审计与安全事件的证据。身份签发信息、可观察的证明细节，都可被用来证明某些工作负载与服务在某个时点的状态。由于这些日志可以作为证据，在搭建日志方案时你可能希望注意以下事项：

• 日志保留期应当与组织法律要求一致。
• 日志系统在接入和存储两端都应具备高可用。
• 日志应当是防篡改的，并且必须能够提供"防篡改"的证据。
• 日志系统应能提供完整的监管链（chain of custody）。

监控

除了通常对 SPIRE 组件健康度的监控以保证系统正常运行外，你还应当建立对 Server、Agent、Trust Bundle 配置的监控，以便发现未授权的变更——因为这些组件是系统安全的基础。此外，还可以对身份签发、Server 与 Agent 之间的通信做监控以发现异常。但鉴于系统里签发的身份数量可能很大，你也许需要重新考虑监控的广度。

SPIRE 通过 telemetry 提供灵活的指标上报支持（参考 en.wikipedia.org/wiki/Telemetry），允许用多种 collector 收集指标。目前支持的 metrics collector 有 Prometheus、StatsD、DogStatsD 和 M3。Server 和 Agent 都可以同时配置多个 collector。

SPIRE 上有大量可用指标，覆盖所有 API 和功能：

• Server：
  • Management API 操作
  • 每个 API 的 DB 操作
  • SVID 签发 API 操作
  • 轮换与密钥管理
• Agent：
  • 与 Server 的交互
  • SVID 轮换与缓存维护
  • Workload Attestation

---

下一章：第 6 章　设计一个 SPIRE 部署