使用 Citrix ADM 对 Citrix Cloud 本机网络连接进行故障排除

概述

在本文档中，我们将回顾如何使用 Citrix ADM 交付和监控 Kubernetes 微服务应用程序。我们还将深入探讨如何使用 CLI、服务图和跟踪，以便平台和 SRE 团队进行故障排除。

应用程序性能和延迟概述

TLS 加密

TLS 是一种加密协议，旨在保护Internet通信。TLS 握手是启动使用 TLS 加密的通信会话的过程。在 TLS 握手期间，通信双方交换消息以互相确认、互相验证、建立他们使用的加密算法，并就会话密钥达成一致。TLS 握手是 HTTPS 工作原理的基础部分。

TLS vs. SSL 握手

SSL，或安全套接字层，是最初为 HTTP 开发的加密协议。不久前，传输层安全性 TLS 取代了 SSL。SSL 握手现在被称为 TLS 握手，尽管“SSL”名称仍在广泛使用。

TLS 握手何时发生？

每当用户通过 HTTPS 导航到网站并且浏览器首先开始查询该网站的源服务器时，就会发生 TLS 握手。每当任何其他通信使用 HTTPS（包括 API 调用和通过 HTTPS 的 DNS 查询）时，也会发生 TLS 握手。

TLS 握手发生在通过 TCP 握手打开 TCP 连接之后。

TLS 握手期间会发生什么？

• 在 TLS 握手期间，客户端和服务器一起执行以下操作：
  • 指定他们使用的 TLS 版本（TLS 1.0、1.2、1.3 等）。
  • 确定它们使用的密码套件（请参阅以下部分）。
  • 通过服务器的公钥和 SSL 证书颁发机构的数字签名验证服务器的身份。
  • 握手完成后生成会话密钥以使用对称加密。

TLS 握手的步骤是什么？

• TLS 握手是由客户端和服务器交换的一系列数据报或消息。TLS 握手涉及多个步骤，因为客户端和服务器交换完成握手所需的信息并使进一步的对话成为可能。

TLS 握手中的确切步骤因所使用的密钥交换算法类型和双方支持的密码套件而异。最常使用 RSA 密钥交换算法。它如下所示：

1. “客户端 hello”消息：客户端通过向服务器发送“hello”消息来启动握手。该消息包括客户端支持的TLS版本, 支持的密码套件, 以及一串随机字节，称为“客户端随机”.“
2. “服务器你好”消息：在回复客户端 hello 消息时，服务器发送一条消息，其中包含服务器的 SSL 证书、服务器选择的密码套件和“服务器随机”（由服务器生成的另一个随机字节字符串）。
3. 身份验证：客户端使用颁发该证书的证书颁发机构验证服务器的 SSL 证书。这确认了服务器是它所说的那样，并且客户端正在与域的实际所有者进行交互。
4. premaster secret：客户端再发送一个随机的字节字符串，即“premaster secret”。“ premaster secret使用公钥加密，并且只能由服务器使用私钥解密。（客户端从服务器的 SSL 证书中获取公钥。）
5. 使用的私钥：服务器解密预主密钥。
6. 创建的会话密钥：客户端和服务器都会从客户端随机生成会话密钥、服务器随机密钥和预主密钥生成会话密钥。他们应该得出相同的结果。
7. 客户端已准备就绪：客户端发送使用会话密钥加密的“已完成”消息。
8. 服务器已就绪：服务器发送使用会话密钥加密的“已完成”消息。
9. 已实现安全对称加密：握手已完成，并继续使用会话密钥进行通信。

所有 TLS 握手都使用非对称加密（公钥和私钥），但并非所有握手都在生成会话密钥的过程中使用私钥。例如，短暂的 Diffie-Hellman 握手按如下方式进行：

1. 客户端 hello：客户端发送客户端 hello 消息，其中包含协议版本、客户端随机数和密码套件列表。
2. 服务器 hello：服务器使用其 SSL 证书、选定的密码套件和服务器随机进行回复。与上一节中介绍的 RSA 握手不同，在本消息中，服务器还包括以下内容（步骤 3）。
3. 服务器的数字签名：服务器使用其私钥对客户端随机加密、服务器随机加密以及其 DH 参数*。此加密数据充当服务器的数字签名，从而确定服务器具有与 SSL 证书中的公钥相匹配的私钥。
4. 数字签名已确认：客户端使用公钥解密服务器的数字签名，验证服务器是否控制私钥以及它所说的是谁。客户端 DH 参数：客户端将其 DH 参数发送到服务器。
5. 客户端和服务器计算预主密钥：客户端和服务器不像在 RSA 握手中那样生成预主密钥并将其发送到服务器，而是使用交换的 DH 参数分别计算匹配的预主密钥。
6. 创建的会话密钥：现在，客户端和服务器将根据预主密钥、客户端随机和服务器随机计算会话密钥，就像在 RSA 握手中一样。
   • 客户端已准备就绪： 与 RSA 握手相同
   • 服务器已准备就绪
   • 实现了安全的对称加密

   *DH 参数：DH 代表 Diffie-Hellman。Diffie-Hellman 算法使用指数计算得出相同的预制密钥。服务器和客户端各自为计算提供一个参数，当它们组合在一起时，两端的计算结果不同，结果相等。

要详细了解短暂的 Diffie-Hellman 握手与其他类型的握手之间的对比，以及它们如何实现向前保密，请参阅此 TLS 协议文档。

什么是密码套件？

• 密码套件是一组用于建立安全通信连接的加密算法。（加密算法是对数据执行的一组数学运算，用于使数据看起来是随机的。）有各种各样的密码套件在广泛使用，TLS 握手的一个重要部分是就该握手使用哪个密码套件达成一致。

要开始使用，请参阅参考： TLS 协议文档。

Citrix Application Delivery Management SSL 控制面板

Citrix Application Delivery Management (ADM) 现在可以为您简化证书管理的各个方面。通过一个控制台可以建立自动化策略以确保合适的颁发者、密钥强度和正确的算法，同时密切跟踪未使用或即将过期的证书。要开始使用 Citrix ADM 的 SSL 仪表板及其功能，您必须了解什么是 SSL 证书以及如何使用 Citrix ADM 跟踪您的 SSL 证书。

安全套接字层 (SSL) 证书是任何 SSL 交易的一部分，是标识公司（域）或个人的数字数据表单 (X509)。证书具有公钥组成部分，想要启动与服务器的安全事务的任何客户端都可以看见该组成部分。相应的私钥安全地驻留在 Citrix 应用程序 Delivery Controller (ADC) 设备上，用于完成非对称密钥（或公钥）加密和解密。

您可以通过以下任何一种方式获取 SSL 证书和密钥：

• 来自授权证书颁发机构 (CA)
• 通过在 Citrix ADC 设备上生成新的 SSL 证书和密钥

Citrix ADM 提供了在所有托管 Citrix ADC 实例上安装的 SSL 证书的集中视图。在 SSL 控制面板上，您可以查看有助于跟踪证书颁发者、密钥强度、签名算法、过期或未使用的证书等的图表。您还可以查看您的虚拟服务器上运行的 SSL 协议的分布情况以及这些服务器上启用的密钥。

您还可以设置通知，以便在证书即将过期时通知您，并包括有关哪些 Citrix ADC 实例使用这些证书的信息。

您可以将 Citrix ADC 实例的证书链接到 CA 证书。但是，请确保链接到同一 CA 证书的证书具有相同的来源和相同的颁发者。将证书链接到 CA 证书后，可以取消它们的链接。

要开始使用，请参阅以下 S SL 控制面板文档。

第三方集成

应用程序延迟以毫秒为单位，它可以指示两种情况之一，具体取决于所使用的指标。衡量延迟的更常见方法称为“往返时间”（或 RTT）。RTT 计算数据包在网络上从一个点传输到另一个点以及将响应发送回源所花费的时间。另一种测量方法称为“到达第一个字节的时间”（或TTFB），它记录从数据包离开网络上的某一点到到达目的地所花费的时间。RTT 更常用于测量延迟，因为它可以从网络上的单个点运行，并且不需要在目的点上安装数据收集软件（就像 TTFB 那样）。

通过实时监控应用程序带宽使用情况和性能，ADM 服务可以轻松识别问题，并在潜在问题显现并影响网络用户之前先发制人地解决这些问题。此基于流程的解决方案可按界面、应用程序和对话跟踪使用情况，从而为您提供有关整个网络活动的详细信息。

使用 Splunk 工具

基础架构和应用程序性能是相互依存的。为了全面了解情况，SignalFX提供了云基础架构与在其上运行的微服务之间的无缝关联。如果您的应用程序由于内存泄漏、噪音邻居容器或任何其他与基础架构相关的问题而运行，SignalFX 会通知您。为了更全面地了解情况，对Splunk日志和事件的上下文访问可以进行更深入的故障排除和根本原因分析。

有关 SignalFX 微服务 APM 和使用 Splunk 进行故障排除的更多信息，请查看 Splunk for DevOps 信息。

MongoDB 支持

MongoDB 将数据存储在灵活的类似 JSON 的文档中。含义字段可能因文档而异，并且数据结构可能会随着时间的推移而改变。

文档模型映射到应用程序代码中的对象，使数据易于使用。

按需查询、索引和实时聚合提供了访问和分析数据的强大方法。

MongoDB 是其核心的分布式数据库，因此内置了高可用性、横向扩展和地理分布且易于使用。

MongoDB 旨在满足现代应用程序的需求，其技术基础使您能够：

• 文档数据模型 — 向您展示处理数据的最佳方式。
• 分布式系统设计 — 允许您智能地将数据放到您想要的位置。
• 一种统一的体验，使您可以在任何地方自由运行，使您的工作经得起未来考验，消除供应商的束缚。

借助这些功能，您可以构建一个以 MongoDB 为基础的智能运营数据平台。有关更多信息，请参阅 MongoDB 文档。

如何对基于 TCP 或 UDP 的应用程序的入口流量进行负载平衡

在 Kubernetes 环境中，入口是允许从 Kubernetes 集群外部访问 Kubernetes 服务的对象。标准 Kubernetes Ingress 资源假定所有流量都是基于 HTTP 的，不能满足非基于 HTTP 的协议，例如 TCP、TCP-SSL 和 UDP。因此，基于 L7 协议的关键应用程序，例如 DNS、FTP、LDAP，无法使用标准 Kubernetes Ingress 进行公开。

Kubernetes 的标准解决方案是创建一个负载均衡器类型的服务。有关详细信息，请参阅 Citrix ADC 中的服务类型负载均衡器 。

第二种选择是对入口对象进行注释。Citrix ingress controller 使您能够对基于 TCP 或 UDP 的入口流量进行负载平衡。它提供了以下 注释 ，您可以在 Kubernetes Ingress 资源定义中使用这些注解来对基于 TCP 或 UDP 的入口流量进行负载平衡：

• ingress.citrix.com/insecure-service-type：该注释启用了使用 TCP、UDP 或 ANY 作为 Citrix ADC 协议的 L4 负载平衡。
• ingress.citrix.com/insecure-port：该注释配置了 TCP 端口。当需要在非标准端口上访问微服务时，该注释很有用。默认情况下，配置端口 80。

有关更多信息，请参阅 如何对基于 TCP 或 UDP 的应用程序的入口流量进行负载平衡

监控和提高基于 TCP 或 UDP 的应用程序的性能

应用程序开发人员可以通过 Citrix ADC 中的丰富监视器（例如 TCP-ECV、UDP-ECV）密切监视基于 TCP 或 UDP 的应用程序的运行状况。ECV（扩展内容验证）监视器有助于检查应用程序是否返回预期内容。

此外，通过使用源IP 等持久性方法，可以提高应用程序的性能。您可以通过 Kubernetes 中的 智能注释 使用这些 Citrix ADC 功能。下面就是一个这样的例子：

apiVersion: extensions/v1beta1
kind: Ingress
metadata:
    name: mongodb
    annotations:
        ingress.citrix.com/insecure-port: “80”
        ingress.citrix.com/frontend-ip: “192.168.1.1”
        ingress.citrix.com/csvserver: ‘{“l2conn”:”on”}’
        ingress.citrix.com/lbvserver: ‘{“mongodb-svc”:{“lbmethod”:”SRCIPDESTIPHASH”}}’
        ingress.citrix.com/monitor: ‘{“mongodbsvc”:{“type”:”tcp-ecv”}}’
Spec:
    rules:
    - host: mongodb.beverages.com
      http:
        paths:
        - path: /
          backend:
            serviceName: mongodb-svc
            servicePort: 80
<!--NeedCopy-->

Citrix Application Delivery Management (ADM) 服务

Citrix ADM 服务具有以下优势：

• 敏捷 — 易于操作、更新和使用。Citrix ADM Service 的服务模型可通过云获得，因此易于操作、更新和使用所提供的功能。更新频率与自动更新功能相结合，可快速增强 Citrix ADC 部署。
• 更快实现价值 — 更快地实现业务目标。与传统的本地部署不同，您只需单击几下即可使用 Citrix ADM 服务。您不仅可以节省安装和配置时间，还可以避免在潜在错误上浪费时间和资源。
• 多站点管理 — 跨多站点数据中心实例的单一玻璃窗格。借助 Citrix ADM 服务，您可以管理和监视处于各种部署类型中的 Citrix ADC。您可以为本地和云中部署的 Citrix ADC 提供一站式管理。
• 运营效率 — 优化和自动化的方式，以实现更高的运营效率。借助 Citrix ADM 服务，您可以节省维护和升级传统硬件部署的时间、资金和资源，从而降低运营成本。

Kubernetes 应用程序的服务图

使用 Citrix ADM 中云原生应用程序功能的服务图，您可以：

• 确保端到端应用程序的整体性能
• 识别由应用程序的不同组件的相互依赖性所造成的瓶颈
• 收集对应用程序不同组件依赖关系的见解
• 监控 Kubernetes 集群中的服务
• 监视哪个服务有问题
• 检查导致性能问题的因素
• 查看服务 HTTP 事务的详细可见性
• 分析 HTTP、TCP 和 SSL 指标

通过在 Citrix ADM 中可视化这些指标，您可以分析问题的根本原因并更快地采取必要的故障排除操作。服务图显示各种组件服务中的应用程序。在 Kubernetes 群集内运行的这些服务可以与应用程序内外的各种组件进行通信。

要开始使用，请参阅 设置服务图。

3 层 Web 应用程序的服务图

使用应用程序仪表板中的服务图功能，您可以查看：

• 有关如何配置应用程序的详细信息（使用内容交换虚拟服务器和负载平衡虚拟服务器）
  • 对于 GSLB 应用程序，您可以查看数据中心、ADC 实例、CS 和 LB 虚拟服务器
• 从客户端到服务的端到端交易
• 客户端访问应用程序的位置
• 处理客户端请求的数据中心名称以及关联的数据中心 Citrix ADC 衡量指标（仅适用于 GSLB 应用程序）
• 客户端、服务和虚拟服务器的度量详细信息
• 如果错误来自客户端或服务
• 服务状态，例如“严重”、“审核”和“良好”。Citrix ADM 根据服务响应时间和错误计数显示服务状态。
  • 严重（红色） -表示平均服务响应时间大于 200 毫秒且错误计数 > 0
  • 查看（橙色） -表示平均服务响应时间大于 200 毫秒或错误计数 > 0
  • 良好（绿色） -表示没有错误，平均服务响应时间小于200毫秒
• 客户端状态，例如“严重”、“审阅”和“良好”。Citrix ADM 根据客户端网络延迟和错误计数显示客户端状态。
  • 严重（红色）-指示客户端网络平均延迟大于 200 毫秒且错误计数 > 0
  • 查看（橙色） -指示客户端网络平均延迟 > 200 毫秒或错误计数 > 0
  • 良好（绿色） -表示无错误且客户端网络平均延迟小于 200 毫秒
• 虚拟服务器的状态，例如“严重”、“审核”和“良好”。Citrix ADM 根据应用程序分数显示虚拟服务器状态。
  • 严重（红色） -表示应用分数小于40时
  • 评价（橙色） -表示应用分数介于 40 和 75 之间的情况
  • 良好（绿色） -指示应用程序分数大于 75

注意事项：

• 服务图中仅显示负载平衡、内容交换和 GSLB 虚拟服务器。
• 如果没有虚拟服务器绑定到自定义应用程序，则详细信息在应用程序的服务图中不可见。
• 只有在虚拟服务器和 Web 应用程序之间发生活动事务时，才能在服务图中查看客户端和服务的衡量指标。
• 如果虚拟服务器和 Web 应用程序之间没有可用的活动事务，则只能根据配置数据（如负载平衡、内容切换、GSLB 虚拟服务器和服务）在服务图中查看详细信息。
• 应用程序配置中的更新可能需要 10 分钟才能反映在服务图中。

有关详细信息，请参阅 应用程序的服务图。

要开始使用，请参阅 服务图文档。

Citrix ADC 团队的故障排除

让我们讨论一些用于对 Citrix ADC 平台进行故障排除的最常见属性，以及这些故障排除技术如何应用于微服务拓扑的 Tier-1 部署。

Citrix ADC 具有实时显示命令的命令行界面 (CLI)，可用于确定运行时配置、静态和策略配置。这可以通过“SHOW”命令来实现。

显示-执行 ADC CLI 操作：

>Show running config (-summary -fullValues)

 Ability to search (grep command)
>“sh running config | -i grep vserver”

Check the version.
>Show license
  “sh license"
<!--NeedCopy-->

显示 SSL 统计信息

>Sh ssl
        System
        Frontend
        Backend
        Encryption
<!--NeedCopy-->

Citrix ADC 有一个命令，用于根据七 (7) 秒计数器间隔枚举所有对象的统计信息。这是通过“STAT”命令来实现的。

Citrix ADC 的高精度 L3-L7 遥测

• 系统级别：ADC 的 CPU 和内存利用率。
• HTTP 协议：#Requests /Responses、GET/POST 拆分、N-S 和 E-W 的 HTTP 错误（仅适用于服务网格精简版，sidecar 即将推出）。
• SSL：#Sessions 和 #Handshakes 仅适用于服务网格精简版的 N-S 和 E-W 流量。
• IP 协议：#Packets 已接收/发送、#Bytes 已接收/发送、#Truncated 数据包和 #IP 地址查找。
• Citrix ADC AAA：#Active 会话
• 接口：#Total 组播数据包、#Total 已传输字节和接收/发送的 #Jumbo 数据包。
• 负载平衡虚拟服务器和内容交换虚拟服务器：#Packets、#Hits 和 #Bytes 已接收/发送。

STAT-执行 ADC CLI 操作：

>Statistics
“stat ssl”
<!--NeedCopy-->

Citrix ADC 具有日志存档结构，允许在通过“NSCONMSG”命令对特定错误进行故障排除时搜索统计信息和计数器。

NSCONMSG -主日志文件（ns 数据格式）

    Cd/var/nslog

    “Mac Moves”
    nsconmsg -d current -g nic_err
<!--NeedCopy-->

Nstcpdump

您可以使用 nstcpdump 进行低级故障排除。 nstcpdump 收集的信息与 nstrace 相比不太详细。打开 ADC CLI 并键入 shell。您可以将过滤器与 nstcpdump 结合使用， 但不能使用特定于 ADC 资源的过滤器。转储输出可以直接在 CLI 屏幕中查看。

CTRL + C — 同时按下这些键可停止 nstcpdump。

nstcpdump.sh dst host x.x.x.x — 显示发送到目标主机的流量。

nstcpdump.sh -n src host x.x.x.x — 显示来自指定主机的流量，但不将 IP 地址转换为名称 (-n)。

nstcpdump.sh host x.x.x.x — 显示进出指定主机 IP 的流量。

![示例 nstcpdump] (/en-us/advanced-concepts/media/nstcpdump.png)

NSTRACE -数据包跟踪文件

NSTRACE 是用于排除网络故障的低级数据包调试工具。它允许您存储捕获文件，您可以使用分析器工具进一步分析这些文件。两种常见的工具是网络分析器和Wireshark。

![ nstrace 输出] (/en-us/advanced-concepts/media/nstrace.png)

在 ADC 的 /var/nstrace 中创建 NSTRACE 捕获文件后，您可以将捕获文件导入 Wireshark 以进行数据包捕获和网络分析。

SYSCTL-详细的 ADC 信息：描述、型号、平台、CPU 等

    sysctl -a grep hw.physmem

    hw.physmem: 862306304
    netscaler.hw_physmem_mb: 822
<!--NeedCopy-->

aaad.debug-开放管道获取身份验证调试信息

有关如何使用 aaad.debug 模块通过 ADC 或 ADC 网关对身份验证问题进行故障排除的更多信息，请参阅此 aaad.debug 支持文章。

还可以直接获取 ADC 的性能统计数据和事件日志。有关此内容的更多信息，请参阅此 ADC 支持文档。

SRE 和平台团队的故障排除

Kubernetes 流量

北/南：

• 南北流量是通过入口从用户流入集群的流量。

东/西：

• 东西向流量是围绕 Kubernetes 集群流动的流量：服务到服务或服务到数据存储。

Citrix ADC CPX 如何在 Kubernetes 环境中对东西向流量进行负载平衡

部署 Kubernetes 集群后，您必须通过在 ADM 中提供 Kubernetes 环境的详细信息，将集群与 ADM 集成。ADM 会监控 Kubernetes 资源的变化，例如服务、终端节点和入口规则。

当你在 Kubernetes 集群中部署 ADC CPX 实例时，它会自动向 ADM 注册。在注册过程中，ADM 会获悉 CPX 实例 IP 地址以及它可以访问实例的端口，以便使用 NITRO REST API 对其进行配置。

下图显示了 ADC CPX 如何在 Kubernetes 集群中对东西向流量进行负载均衡。

在此示例中，

Kubernetes 集群的节点 1 和节点 2 包含前端服务和后端服务的实例。在节点 1 和节点 2 中部署 ADC CPX 实例时，ADC CPX 实例会自动向 ADM 注册。您必须通过在 ADM 中配置 Kubernetes 集群详细信息来手动将 Kubernetes 集群与 ADM 集成。

客户端请求前端服务时，Ingress 资源将对两个节点上的前端服务的实例之间的请求进行负载平衡。当前端服务的实例需要来自集群中后端服务的信息时，它会将请求定向到其节点中的 ADC CPX 实例。该 ADC CPX 实例在集群中的后端服务之间对请求进行负载平衡，从而提供东西向流量。

应用程序的 ADM 服务图

Citrix ADM 中的服务图功能使您能够以图形表示形式监视所有服务。此功能还提供了详细的分析和有用的指标。您可以查看以下各项的服务图表：

• 跨所有 Citrix ADC 实例配置的应用程序
• 库贝内特斯应用程序
• 3 层 Web 应用程序

要开始使用，请参阅 服务图中的详细信息。

查看微服务应用程序计数器

服务图还显示属于 Kubernetes 集群的所有微服务应用程序。将鼠标指针悬停在服务上以查看指标详细信息。

您可以查看：

• 服务名称
• 服务使用的协议，如 SSL，HTTP，TCP，SSL 通过 HTTP 使用的协议
• 点击 数 — 服务接收的点击总数
• 服务响应时间 — 服务所需的平均响应时间。 （响应时间 = 客户端 RTT + 请求最后一个字节-请求第一个字节）
• 错误 — 总错误，如 4xx、5xx 等
• 数据量 — 服务处理的数据总量
• 命名空间 — 服务的命名空间
• 集群名称 — 托管服务的集群名称
• SSL 服务器错误 — 来自该服务的 SSL 错误总数

这些特定的计数器和事务日志可以使用一系列受支持的端点通过 Citrix 可观察性导出器 (COE) 提取。有关 COE 的更多信息，请参阅以下章节。

Citrix ADC 统计信息的导出器

这是一个简单的服务器，可以抓取 Citrix ADC 统计信息并通过 HTTP 将其导出到普罗米修斯。然后可以将普罗米修斯作为数据源添加到 Grafana 中，以图形方式查看 Citrix ADC 统计信息。

要监视 Citrix ADC 实例的统计信息和计数器， citrix-adc-metric-exporter 可以作为容器或脚本运行。导出器会从 Citrix ADC 实例中收集 Citrix ADC 统计信息，例如虚拟服务器的总点击数、HTTP 请求速率、SSL 加密解密率等，并保留这些统计信息，直到 Prometheus 服务器提取统计信息并使用时间戳存储它们为止。然后，可以将 Grafana 指向 Prometheus 服务器以获取统计数据、绘制统计数据、设置警报、创建热点图、生成表等，以分析 Citrix ADC 统计信息。

以下各节提供了有关将导出器设置为在环境中工作的详细信息（如图所示）。还解释了导出器默认抓取哪些 Citrix ADC 实体/指标以及如何对其进行修改的注释。

有关适用于 Citrix ADC 的导出器的更多信息，请参阅 指标导出器 GitHub。

ADM 服务分布式跟踪

在服务图中，您可以使用分布式跟踪视图执行以下操作：

• 分析整体服务性能。
• 可视化选定服务与其相互依赖服务之间的通信流。
• 确定哪些服务指示错误并排除错误服务的故障
• 查看所选服务与每个相互依赖的服务之间的交易详细信息。

ADM 分布式跟踪必备条件

要查看服务的跟踪信息，您必须：

• 确保应用程序在发送任何东西向流量时维护以下跟踪标头：

• 使用 NS_DISTRIBUTED_TRACING 更新 CPX YAML 文件，并将值设置为“是”。 要开始使用，请参阅 分布式跟踪。

Citrix Observability Exporter (COE) 解析

Citrix 可观察性导出器是一个容器，用于从 Citrix ADC 收集指标和事务，并将其转换为支持的终端节点的合适格式（例如 JSON、AVRO）。您可以将 Citrix 可观察性导出器收集的数据导出到所需的终端节点。通过分析导出到端点的数据，您可以在微服务级别获得由 Citrix ADC 代理的应用程序的宝贵见解。

有关 COE 的更多信息，请参阅 COE GitHub。

使用 Elasticsearch 作为交易终端节点的 COE

当将 Elasticsearch 指定为事务终端节点时，Citrix 可观察性导出器会将数据转换为 JSON 格式。在 Elasticsearch 服务器上，Citrix 可观察性导出器每小时为每个 ADC 创建 Elasticsearch 索引。这些索引基于数据、小时、ADC 的 UUID 和 HTTP 数据的类型（http_event 或 http_error）。然后，Citrix 可观察性导出器会在每个 ADC 的弹性搜索索引下以 JSON 格式上载数据。所有常规事务都被放置到 http_event 索引中，任何异常都会放入 http_error 索引中。

Zipkin 支持分布式跟踪

在微服务架构中，单个最终用户请求可能跨越多个微服务，这使得跟踪事务和修复错误源具有挑战性。在这种情况下，传统的性能监视方法无法准确地查明故障发生的位置以及性能不佳的原因是什么。您需要一种方法来捕获处理请求的每个微服务的特定数据点，并对其进行分析以获得有意义的见解。

分布式跟踪通过提供一种端到端跟踪事务并了解如何在多个微服务中处理事务的方式来解决这一难题。

OpenT race 是一套规范和标准 API 集，用于设计和实施分布式跟踪。分布式跟踪器允许您显示微服务之间的数据流，并帮助识别微服务架构中的瓶颈。

Citrix Observability Exporter 器为 Citrix ADC 实施分布式跟踪，目前支持 Zipkin 作为分布式跟踪器。

目前，您可以使用 Citrix ADC 在应用程序级别监视性能。使用 Citrix Observability Exporter 和 Citrix ADC，您可以获取由 Citrix ADC CPX、MPX 或 VPX 代理的每个应用程序的微服务的跟踪数据。

要开始使用，请参阅 GitHub 可观察性导出器。

用于应用程序调试的 Zipkin

Zipkin 是一个 开源 的分布式跟踪系统，基于 Google 的 Dapper 的论文。Dapper 是 Google 的系统，用于在生产环境中进行系统分布式跟踪。Google 在他们的论文中解释了这一点：“我们构建Dapper是为了向Google的开发人员提供有关复杂分布式系统行为的更多信息”。在进行故障排除时，从不同角度观察系统至关重要，尤其是在系统复杂且分散的情况下。

以下 Zipkin 跟踪数据总共标识了与 Watch 示例应用程序相关的 5 个跨度和 5 个服务。跟踪数据显示了跨越5个微服务的特定跨度数据。

要开始使用，请参阅以下 Zipkin。

显示初始页面加载请求的应用程序延迟的 Zipkin span 示例：

用于查看数据的 Kibana

Kibana 是一个开放的用户界面，可让您可视化您的 Elasticsearch 数据并浏览弹性堆栈。从跟踪查询负载到了解请求流经应用的方式，执行任何操作。

无论您是分析师还是管理员，Kibana都可以通过提供以下三个关键功能来使您的数据具有可操作性：

• 开源分析和可视化平台。使用 Kibana 来探索你的 Elasticsearch 数据，然后构建漂亮的可视化和仪表板。
• 用于管理弹性堆栈的 UI。管理您的安全设置、分配用户角色、拍摄快照、汇总数据等等，所有这些都可通过 Kibana UI 轻松实现。
• Elastic 解决方案的集中中心。从日志分析到文档发现再到 SIEM，Kibana 是访问这些和其他功能的门户。

Kibana 旨在使用 Elasticsearch 作为数据源。可以将 Elasticsearch 想象成存储和处理数据的引擎，Kibana 处于领先地位。

在主页上，Kibana 提供了以下添加数据的选项：

• 使用 文件数据可视化工具导入数据。
• 使用我们的内置教程设置数据流向 Elasticsearch。如果您的数据没有教程，请前往 Beats 概述 了解 Beats 系列中的其他数据发送者。
• 添加样本数据集 ，然后使用 Kibana 进行试用，无需自己加载数据。
• 使用 R EST API 或 客户端库将您的数据索引到 Elasticsearch 中。

Kibana 使用 指数模式 来告诉它要探索哪些 Elasticsearch 指数。如果您上载文件、运行内置教程或添加示例数据，则可以免费获得索引模式，并且可以开始探索。如果您加载自己的数据，则可以在 堆栈管理中创建索引模式。

步骤 1：为 Logstash 配置索引模式

步骤 2：选择索引并生成要填充的流量。

第 3 步：从日志源的非结构化数据中生成应用程序。

第 4 步：Kibana 将 Logstash 输入的格式设置为创建报表和仪表板。

• 时间范围
• 表格视图
• 命中次数根据应用程序而定。
  • 时间 IP、代理、Machine.OS、响应代码 (200)、URL
  • 筛选值

步骤 5：在聚合报告中可视化数据。

• 图表报表中的结果聚合（饼图、图表等）