Sentry 开发者贡献指南 - SDK 开发(性能监控)

本文涉及的产品
函数计算FC,每月15万CU 3个月
简介: Sentry 开发者贡献指南 - SDK 开发(性能监控)

性能监控指南



本文档介绍了 SDK 应如何通过分布式跟踪添加对性能监控的支持。

这应该提供 SDK 需要实现的 API 的概述,而不强制要求内部实现细节。

参考实现:

  • @sentry/tracing (JavaScript)
  • Python SDK


SDK 配置



通过设置两个新的 SDK 配置选项之一来启用跟踪,tracesSampleRatetracesSampler。如果未设置,则两者都默认为 undefined,从而选择如何加入跟踪。


tracesSampleRate

这应该是介于 0.01.0(含)之间的 float/double,表示任何给定 transaction 将被发送到 Sentry 的百分比机会。因此,0.00% 的机会(不会发送),而 1.0100% 的机会(都将发送)。此 rate 同样适用于所有 transaction;换句话说,每个 transaction 都应该有相同的随机机会以 sampled = true 结束,等于 tracesSampleRate


tracesSampler

这应该是一个 callback,在 transaction 开始时调用,它将被赋予一个 samplingContext 对象,并且应该返回一个介于 0.01.0 之间的采样率_对于所讨论的 transaction_。此采样率的行为方式应与上面的 tracesSampleRate 相同,不同之处在于它仅适用于新创建的 transaction,因此可以以不同的 rate 对不同的 transaction 进行采样。返回 0.0 应该强制删除 transaction(设置为 sampled = false),返回 1.0 应该强制发送 transaction(设置 sampled = true)。

可选地,tracesSamplercallback 也可以返回一个布尔值来强制进行采样决策(false 等同于 0.0true 等同于 1.0)。如果返回两种不同的数据类型在实现语言中不是一个选项,则可以安全地省略这种可能性。


maxSpans

由于 transactionpayload 在摄取端强制执行最大大小,因此 SDK 应限制附加到事务的 span 数。这类似于如何限制面包屑和其他任意大小的列表以防止意外误用。如果在达到最大值后添加新的 spanSDK 应删除 span 并理想地使用内部日志记录来帮助调试。

maxSpans 应该作为一个内部的、不可配置的、默认为 1000 的常量来实现。如果在给定的平台中有理由,它可能会变得可配置。

maxSpans 限制还可以帮助避免永远不会完成的 transaction(在 span 打开时保持 transaction 打开的平台中),防止 OOM 错误,并通常避免降低应用程序性能。


Event 变更


在撰写本文时,transaction 是作为 Event 模型的扩展实现的。

Transaction 的显着特征是 type: "transaction"

除此之外,Event 获得了新的字段:spanscontexts.TraceContext


新的 SpanTransaction


在内存中,span 构建了一个定时操作的概念树(conceptual tree)。我们称整个 span treetransaction。有时我们使用术语 "transaction" 来指代作为整棵树的 span tree,有时特指树的 root span

通过网络,transaction 被序列化为 JSON 作为增强的 Event,并作为 envelope 发送。不同的 envelope 类型用于优化摄取(因此我们可以以不同于其他事件的方式路由 “transaction events”,主要是 “error events”)。


Sentry UI 中,您可以使用 Discover 查看所有类型的事件,并使用 IssuesPerformance 部分分别深入研究 errorstransactions。 面向用户的跟踪文档解释了更多产品级别的概念。


Span 类将每个单独的 span 存储在 trace 中。

Transaction 类就像一个 span,有几个主要区别:

  • Transactionnamespan 没有。
  • span 上调用 finish 方法会记录 span 的结束时间戳。对于 transactionfinish 方法另外向 Sentry 发送一个事件。

Transaction 类可能继承自 Span,但这是一个实现细节。从语义上讲,transaction 既表示 span treetop-level span,也表示向 Sentry 报告的单位。

  • Span 接口
  • 创建 Span 时,将 startTimestamp 设置为当前时间
  • SpanContextSpan 的属性集合(可以是一个实现细节)。如果可能,SpanContext 应该是不可变的。
  • Span 应该有一个方法 startChild,它使用当前 spanid 作为新 spanparentSpanId 创建一个新的 span,并将当前 spansampled 值复制到新 spansampled 属性
  • startChild 方法应遵守 maxSpans 限制,一旦达到限制,SDK 不应为给定的 transaction 创建新的子 span
  • Span 应该有一个名为 toSentryTrace 的方法,它返回一个字符串,该字符串可以作为名为 sentry-traceheader 发送。
  • Span 应该有一个名为 iterHeaders(适应平台的命名约定)的方法,它返回一个可迭代的或 header 名称和值的映射。这是一个包含 return {"sentry-trace": toSentryTrace()} 的薄 wrapper。请参阅 continueFromHeaders 以了解为什么存在这种情况,并且在编写集成(integration)时应该首选。
  • Transaction 接口
  • 一个 Transaction 内部包含一个子 Span 的平面列表(不是树结构)
  • Transaction 还有一个 setName 方法来设置 transaction 的名称
  • Transaction 在创建时收到一个 TransactionContext(新属性与 SpanContextname
  • 由于 Transaction 继承了 Span,因此它具有所有 Span 可用的函数并且可以像 Span 一样进行交互
  • 一个 transaction 要么被采样(sampled = true),要么被取消采样(sampled = false),一个在 transaction 的生命周期中被继承或设置一次的决定,并且在任何一种情况下都会传播给所有的 children。不应将未抽样的 transaction 发送给 Sentry
  • TransactionContext 应该有一个叫做 fromSentryTracestatic/ctor 方法,它用从 sentry-traceheader值接收的数据预填充一个 TransactionContext
  • TransactionContext 应该有一个名为 continueFromHeaders(headerMap)static/ctor 方法,它现在实际上只是一个围绕 fromSentryTrace(headerMap.get("sentry-trace")) 的薄 wrapperintegration/framework-sdk 的作者应该更喜欢 fromSentryTrace,因为它隐藏了核心 sdk 中更深层次使用的确切 header 名称,并为将来使用其他 header(来自 W3C)留下了机会,而无需更改所有集成。
  • Span.finish()
  • 只需将 endTimestamp 设置为当前时间(在 payloadtimestamp 中)
  • Transaction.finish()
  • super.finish() (在 Span 上调用 finish)
  • 仅当 sampled == true 时才将其发送给 Sentry
  • 一个 Transaction 需要被包裹在一个 Envelope 中并发送到 Envelope Endpoint
  • Transport 应该为 Transactions/Events 使用相同的内部队列
  • Transport 应该实现基于类别的速率限制 →
  • Transport 应该处理在内部将 Transaction 包装在 Envelope


采样


每个 transaction 都有一个 “抽样决策”,即一个布尔值,指示是否应该将其发送给 Sentry。这应该在 transaction 的生命周期内只设置一次,并且应该存储在内部的 sampled 布尔值中。


transaction 可以通过多种方式结束抽样决策(sampling decision)

  • 根据 tracesSampleRate 中设置的静态采样率随机采样
  • 根据 tracesSampler 返回的动态采样率进行随机采样
  • tracesSampler 返回的绝对决策(100% 概率或 0% 概率)
  • 如果 transaction 有父级,继承其父级的抽样决策
  • 传递给 startTransaction 的绝对决策

当其中一个以上发挥作用的可能性时,应适用以下优先规则:


  1. 如果将抽样决策传递给 startTransaction (startTransaction({name: "my transaction", sampled: true})),则将使用该决策,而不管其他任何事情。
  2. 如果定义了 tracesSampler,则将使用其决策。它可以选择保留或忽略任何父采样决策,或使用采样上下文数据做出自己的决策或为 transaction 选择采样率
  3. 如果未定义 tracesSampler,但存在父采样决策,则将使用父采样决策。
  4. 如果没有定义 tracesSampler 并且没有父采样决策,则将使用 tracesSampleRate


Transaction 应仅通过 tracesSampleRatetracesSampler 进行采样。sampleRate 配置用于 error 事件,不应应用于 transaction

采样上下文


如果定义,tracesSampler 回调应该传递一个 samplingContext 对象,该对象至少应该包括:

  • 创建 transactiontransactionContext
  • 一个布尔值 parentSampled,包含从父级传递过来的采样决策,如果有的话
  • 来自可选的 customSamplingContext 对象的数据在手动调用时传递给 startTransaction

根据平台,可能包含其他默认数据。(例如,对于服务器框架,包含与 transaction 正在测量的请求相对应的 request 对象是有意义的。)


传播


transaction抽样决策应传递给其所有子项,包括跨服务边界。这可以在相同服务子项的 startChild 方法中完成,并为不同服务中的子项使用 senry-traceheader


Header sentry-trace


Header 用于跟踪传播。SDK 使用 header 继续跟踪来自上游服务(传入 HTTP 请求),并将跟踪信息传播到下游服务(传出 HTTP 请求)。

sentry-trace = traceid-spanid-sampled

sampled 是可选的。所以至少,它是预期的:

sentry-trace = traceid-spanid

为了与 W3C traceparent header(没有版本前缀) 和 Zipkin's b3 headers(考虑 64 位和 128 位的 traceId 有效)提供最小的兼容性, sentry-trace header 应具有以 32 个十六进制字符编码的 128 位的 traceId 以及以 16 个十六进制字符编码的 64spanId。为了避免与 W3C traceparent header(我们的 header 相似但不相同)混淆, 我们将其简称为 sentry-traceheader 中没有定义版本。


sampled


为简化处理,该值由单个(可选)字符组成。可能的值为:


- No value means defer
0 - Don't sample
1 - Sampled


b3header 不同,sentry-traceheader 不应该只包含一个采样决策,没有 traceidspanid 值。有很好的理由 无论采样决策如何,始终包含 traceidspanid,这样做也简化了实现。


除了在 Sentry 的情况下使用 *defer 的通常原因外, 还有一个原因是下游系统使用 Sentry 捕获 error 事件。可以在那时做出决定,对跟踪进行采样,以便为报告的崩溃提供跟踪数据。


sentry-trace = sampled


这实际上对于代理将其设置为 0 并选择退出跟踪很有用。


Static API 变更


Sentry.startTransaction 函数应该接受两个参数 - 传递给 Transaction 构造函数的 transactionContext 和一个包含要传递给 tracesSampler(如果已定义)的数据的可选的 customSamplingContext 对象。


它创建一个绑定到当前 hubTransaction 并返回实例。用户与实例交互以创建子 span,因此,必须自己跟踪它。


Hub 变更


  • 引入一个名为 traceHeaders 的方法
  • 此函数返回 header(string)sentry-trace
  • 该值应该是当前在 Scope 上的 Spantrace header 字符串
  • 引入一个名为 startTransaction 的方法
  • 采用与 Sentry.startTransaction 相同的两个参数
  • 创建一个新的 Transaction 实例
  • 应按照本文档 'Sampling' 部分中更详细的描述实施抽样
  • 修改名为 captureEventcaptureTransaction 的方法
  • 不要为 transaction 设置 lastEventId


Scope 变更


Scope 持有对当前 SpanTransaction 的引用。

  • Scope 引入 setSpan
  • 这可以在内部使用,来传递 Span / Transaction,以便集成可以将子项附加到它
  • Scope(旧版)上设置 transaction 属性应该覆盖存储在 Scope 中的 Transaction 的名称,如果有的话。这样,即使用户无法直接访问 Transaction 的实例,我们也可以让用户选择更改 transaction 名称。


beforeSend 和事件处理器的交互


beforeSend 回调是我们认为最重要的特殊 Event Processor。适当的事件处理器通常被认为是内部的。


Transaction 应该通过 beforeSend。但是,它们仍然由事件处理器处理。这是在将 transaction 作为 event 的当前实现处理的一些灵活性与为 transactionspan 的不同生命周期 hook 留出空间之间的折衷。

动机:


  1. 面向未来:如果用户依赖 beforeSend 进行 transaction, 这将使最终在不破坏用户代码的情况下实现单个 span 摄取变得复杂。在撰写本文时,transaction 作为 event 发送,但这被视为实现细节。
  2. API 兼容性:用户拥有他们现有的 beforeSend 实现,只需要处理错误事件。我们将 transaction 作为一种新型 event 引入。当用户升级到新的 SDK 版本并开始使用跟踪时,他们的 beforeSend 将开始看到他们的代码不打算处理的新类型。在 transaction 之前,他们根本不必关心不同的事件类型。有几种可能的后果:破坏用户应用程序;默默地和无意地放弃 transactiontransaction 事件以令人惊讶的方式修改。
  3. 就可用性而言,beforeSend 不适合删除 transaction,就像删除 error 一样。 Error 是一个时间点事件。当 error 发生时,用户在 beforeSend 中有完整的上下文, 并且可以在它进入 Sentry 之前修改/丢弃事件。对于交易,transaction 是不同的。创建 transaction,然后将它们打开一段时间,同时创建 child span 并将其附加到它。同时传出的 HTTP 请求包括当前 transaction 与其他服务的采样决策。在 spantransaction 完成后,将 transaction 放入类似 beforeSend 的钩子中会在跟踪中留下来自其他服务的孤立 transaction。同样,在此后期将采样决策修改为 "yes" 也会产生不一致的痕迹。


跟踪上下文(实验性)



为了对跟踪进行采样,我们需要沿着调用链传递 trace id 以及做出采样决策所需的信息,即所谓的 跟踪上下文(trace context)


协议


Trace 信息作为编码的 tracestateheaderSDK 之间传递,SDK 预计会拦截和传播这些 header

对于向 sentry 提交的事件,trace context 作为嵌入在 Envelope header 中的 JSON 对象发送,keytrace


跟踪上下文


无论采用何种传输机制,trace context 都是具有以下字段的 JSON 对象:

  • trace_id (string, required) - UUID V4 编码为不带破折号的十六进制序列(例如771a43a4192642f0b136d5159a501700),它是一个由 32 个十六进制数字组成的序列。这必须与提交的 transaction itemtrace id 匹配。
  • public_key (string, required) - 来自 SDK 使用的 DSNPublic key。它允许 Sentry 通过基于起始项目解析相同的规则集来对跨多个项目的跟踪进行采样。
  • release (string, optional) - 客户端选项中指定的版本名称,通常是:package@x.y.z+build这应该与 transaction event payloadrelease 属性匹配*
  • environment - 客户端选项中指定的 environment 名称,例如 staging这应该与 transaction event payloadenvironment 属性匹配*
  • user (object, optional) - 包含以下字段的 scopeuser context 的子集:
  • id (string, optional) - 用户上下文的 id 属性。
  • segment (string, optional) - 用户数据包中的 segment 属性值(如果存在)。将来,该字段可能会被提升为用户上下文的适当属性。
  • transaction (string, optional) - 在 scope 上设置的 transaction 名称。这应该与 transaction event payloadtransaction 属性匹配*

例子:


{
  "trace_id": "771a43a4192642f0b136d5159a501700",
  "public_key": "49d0f7386ad645858ae85020e393bef3",
  "release": "myapp@1.1.2",
  "environment": "production",
  "user": {
    "id": "7efa4978da177713df088f846f8c484d",
    "segment": "vip"
  },
  "transaction": "/api/0/project_details"
}


Envelope Headers(信封头)


当通过 EnvelopeSentry 发送 transaction 事件时,必须在 trace 字段下的 envelope header 中设置 trace 信息。


这是一个包含 trace context 的最小 envelope header 的示例(尽管 header 不包含换行符,但在下面的示例中添加了换行符以提高可读性):


{
  "event_id": "12c2d058d58442709aa2eca08bf20986",
  "trace": {
    "trace_id": "771a43a4192642f0b136d5159a501700",
    "public_key": "49d0f7386ad645858ae85020e393bef3"
    // other trace attributes
  }
}


Tracestate Headers(跟踪状态头)


跟踪上下文传播到其他 SDK 时,Sentry 使用 W3C tracestate header。有关如何将这些 header 传播到其他 SDK 的更多信息,请参阅 "Trace Propagation"


Tracestateheader 包含几个特定于供应商的不透明数据。根据 HTTP 规范,这些多个 header 值可以通过两种方式给出,通常由 HTTP 库和开箱即用的框架支持:


  • 用逗号连接:


tracestate: sentry=<data>,other=<data>


  • 重复:


tracestate: sentry=<data>
tracestate: other=<data>


要创建 tracestate header 的内容:


  1. 将完整的 trace context 序列化为 JSON,包括 trace_id
  2. 如果字符串在平台上的表示方式不同,则将生成的 JSON 字符串编码为 UTF-8
  3. 使用 base64UTF-8 字符串进行编码。
  4. 去除尾随填充字符 (=),因为这是一个保留字符。
  5. 在前面加上 "sentry=",导致 "sentry=<base64>"
  6. 如上所述加入 header

通过去除尾随填充,默认的 base64 解析器可能会检测到不完整的 payload。选择允许丢失 = 或允许截断 payload 的解析模式。


例如:


{
  "trace_id": "771a43a4192642f0b136d5159a501700",
  "public_key": "49d0f7386ad645858ae85020e393bef3",
  "release": "1.1.22",
  "environment": "dev",
  "user": {
    "segment": "vip",
    "id": "7efa4978da177713df088f846f8c484d"
  }
}


将编码为


ewogICJ0cmFjZV9pZCI6ICI3NzFhNDNhNDE5MjY0MmYwYjEzNmQ1MTU5YTUwMTcwMCIsCiAgInB1YmxpY19rZXkiOiAiNDlkMGY3Mzg2YWQ2NDU4NThhZTg1MDIwZTM5M2JlZjMiLAogICJyZWxlYXNlIjogIjEuMS4yMiIsCiAgImVudmlyb25tZW50IjogImRldiIsCiAgInVzZXIiOiB7CiAgICAic2VnbWVudCI6ICJ2aXAiLAogICAgImlkIjogIjdlZmE0OTc4ZGExNzc3MTNkZjA4OGY4NDZmOGM0ODRkIgogIH0KfQ


并导致 header


tracestate: sentry=ewogIC...IH0KfQ,other=[omitted]


(注意 header 末尾的第三方条目;新的或修改的条目总是添加到左侧,因此我们将 sentry= 值放在那里。另请注意,尽管此处为了清晰起见省略了编码值, 在真正的 header 中,将使用完整的值。)


实施指南


支持此 headerSDK 必须:

  • 创建新的 trace context 时使用 scope 信息
  • 为包含 transactionenvelope 添加带有 trace contextenvelope header
  • tracestateHTTP header 添加到传出的 HTTP 请求以进行传播
  • 在适用的情况下拦截对 tracestateHTTP header 的传入 HTTP 请求,并将它们应用到 local trace context


背景


这是性能指南涵盖的 trace ID 传播的扩展。根据统一 API 跟踪规范Sentry SDK 通过集成向传出请求添加 HTTP headersentry-trace。最重要的是,此 header 包含 trace ID,它必须与 transaction eventtrace id 以及下面的 trace contexttrace id 匹配。


trace context 应在 W3C traceparent header 中定义的附加 tracestateheader 中传播。请注意,我们必须保持与 W3C 规范的兼容性,而不是专有的 sentry-traceheader。除了 Sentry SDK 放置的内容之外,tracestateheader 还包含供应商特定的不透明数据。



Client 选项


虽然 trace context 正在开发中,但它们应该在内部 trace_sampling 布尔值 client 选项后面进行门控。该选项默认为 false,不应在 Sentry 文档中记录。


根据平台命名指南,该选项应该适当地区分大小写:


  • trace_sampling (snake case)
  • traceSampling (camel case)
  • TraceSampling (pascal case)
  • setTraceSampling (Java-style setters)


添加 Envelope Header


在以下任何一种情况下,SDK 应将 envelope header 添加到传出 envelope 中:


  1. envelope 包含 transaction event
  2. scope 有一个 transaction 绑定。

具体来说,这意味着即使没有 transactionenvelope 也可以包含 traceenvelope header, 从而允许 Sentry 最终对属于 transactionattachment 进行采样。当 envelope 包含 transactionscope 有绑定 transaction 时, SDK 应使用 envelopetransaction 来创建 traceenvelope header


冻结上下文


为了确保 trace 中所有 transactiontrace context 完全一致,一旦通过网络发送 trace context,就不能更改 trace context,即使 scopeoptions 之后发生更改。也就是说,一旦计算出 trace context 就不再更新。即使应用程序调用 setRelease,旧版本仍保留在 context 中。


为了弥补对 setTransactionsetUser 等函数的延迟调用, 可以认为 trace context 处于两种状态:NEWSENT。最初,context 处于 NEW 状态并且可以修改。第一次发送后,它将变为 SENT 并且不能再更改。

我们建议 trace context 应该在第一次需要时即时计算:


  • 创建 Envelope
  • 传播到传出的 HTTP 请求

Trace context 必须保留,直到用户开始新的 trace,此时 SDK 必须计算新的 trace context


建议 SDK 记录在 trace context 冻结时会导致 trace context 更改的属性修改,例如 user.id,以简化常见动态采样陷阱的调试。


传入上下文


与拦截来自入站 HTTP 请求的 trace ID 相同,SDK 应读取 tracestateheader 并假设 Sentry 跟踪上下文(如果指定)。这样的上下文立即冻结在 SENT 状态,不应再允许修改。


平台细节



在 JavaScript 中编码


如前所述,我们需要使用 UTF-8 字符串对 JSON trace context 进行编码。JavaScript 内部使用 UTF16,因此我们需要做一些工作来进行转换。

Base64 encoding and decoding in JavaScript(以及 Using Javascript's atob to decode base64 doesn't properly decode utf-8 strings)介绍了基本思想。



简而言之,这是将 context 转换为可以保存在 tracestate 中的 base64 字符串的函数。最后我们采用了一个更简单的实现,但想法是一样的:


// Compact form
function objToB64(obj) {
  const utf16Json = JSON.stringify(obj);
  const b64 = btoa(
    encodeURIComponent(utf16Json).replace(
      /%([0-9A-F]{2})/g,
      function toSolidBytes(match, p1) {
        return String.fromCharCode("0x" + p1);
      }
    )
  );
  const len = b64.length;
  if (b64[len - 2] === "=") {
    return b64.substr(0, len - 2);
  } else if (b64[len - 1] === "=") {
    return b64.substr(0, len - 1);
  }
  return b64;
}
// Commented
function objToB64(obj) {
  // object to JSON string
  const utf16Json = JSON.stringify(obj);
  // still utf16 string but with non ASCI escaped as UTF-8 numbers)
  const encodedUtf8 = encodeURIComponent(utf16Json);
  // replace the escaped code points with utf16
  // in the first 256 code points (the most wierd part)
  const b64 = btoa(
    endcodedUtf8.replace(/%([0-9A-F]{2})/g, function toSolidBytes(match, p1) {
      return String.fromCharCode("0x" + p1);
    })
  );
  // drop the '=' or '==' padding from base64
  const len = b64.length;
  if (b64[len - 2] === "=") {
    return b64.substr(0, len - 2);
  } else if (b64[len - 1] === "=") {
    return b64.substr(0, len - 1);
  }
  return b64;
}
// const test = {"x":"a-🙂-读写汉字 - 学中文"}
// objToB64(test)
// "eyJ4IjoiYS3wn5mCLeivu+WGmeaxieWtlyAtIOWtpuS4reaWhyJ9"


这是接受 base64 字符串(带或不带 '=' 填充)并返回一个对象的函数


function b64ToObj(b64) {
  utf16 = decodeURIComponent(
    atob(b64)
      .split("")
      .map(function(c) {
        return "%" + ("00" + c.charCodeAt(0).toString(16)).slice(-2);
      })
      .join("")
  );
  return JSON.parse(utf16);
}
// b64ToObj("eyJ4IjoiYS3wn5mCLeivu+WGmeaxieWtlyAtIOWtpuS4reaWhyJ9")
// {"x":"a-🙂-读写汉字 - 学中文"}


带有命令行实用程序的 Base64


GNUbase64 命令行实用程序带有一个开关来包装编码的字符串。这与 tracestateheader 不兼容,应该避免。如果 base64 实现创建多行,则必须将它们连接在一起。


Span Operations(跨度操作)



Span 操作是识别 span 正在测量的操作类型的短代码。 Span 操作是低基数属性 - 它们应该尽可能通用,同时仍然是人类可读和有用的。他们应该避免包含高基数数据,如 IDURL


操作应尽可能遵循 OpenTelemetry 的语义约定。


保持 SDKintegration 之间的类别一致很重要,因为 Sentry 在操作细分功能中使用它们。例如,db.initdb.query 都将被归类为数据库操作(db)。可以在projectoptions/defaults.py 查看默认操作细分配置。



操作列表


下表包含 SDKSentry 产品使用的操作示例。表中的 Usage 列包含使用该操作类别的示例,但不是操作用法硬性建议。只要类别保持一致,SDK 开发人员就可以自由选择最适合他们正在检测的用例的操作标识符

如果未提供 span 操作,则使用 default 的值。


Browser


Category Usage Description
pageload
Web 应用程序的完整页面加载
navigation
Web 应用程序中的客户端浏览器 history 更改
resource
资源,根据性能资源计时

resource.script

resource.link

resource.css

resource.img
browser
浏览器 API 或功能的使用

browser.paint
mark
performance.mark() API 的使用
measure
performance.measure() API 的使用
ui


ui.animation 一个 animation

ui.render 渲染 UI 元素所需的时间

ui.update 更新 UI 元素所需的时间



JS Frameworks


JS 框架应该在 UI 组件相关的操作前加上 ui 类别。


Category Usage Description
ui.react
与 React 组件相关的 Span

ui.react.mount

ui.react.render
ui.vue
与 Vue.js 组件相关的 Span

ui.vue.mount

ui.vue.update
ui.angular
与 Angular 组件相关的 Span
ui.ember
与 EmberJS 组件相关的 Span


Web Server


Web server 相关的 span 应该尽可能遵循 OpenTelemetry 的 HTTP 和 RPC 语义约定。


Category Usage Description
http
与 http 操作相关的 Span

http.client

http.server
rpc
与远程过程调用 (RPC) 相关的 Span
grpc
gRPC 框架的使用
template


template.init

template.parse

template.render
render
渲染视图
serialize
数据序列化
console
通过命令行访问 Web 服务器(例如 Rails 控制台)



Web Frameworks


Category Usage Description
django


django.middleware

django.view
express

rails

rack


Database


在可能的情况下,与数据库相关的 span 应遵循 OpenTelemetry 的 Database 语义约定。



Category Usage Description
db
对数据库的操作

db.connection

db.transaction

db.sql.query

db.query

db.query.compile


Serverless (FAAS)


Serverless 相关的 span 应尽可能遵循 OpenTelemetry 的 FaaS 语义约定。

Category Usage Description
faas
serverless function 的调用

faas.aws

faas.aws.lambda

faas.aws.request

faas.gcp


Mobile


Category Usage Description
app
关于 mobile app 的数据

app.start

app.start.warm

app.start.cold
ui
移动/桌面 UI 上的操作

ui.load

ui.action
navigation
导航到另一个屏幕
file
对文件系统的操作

file.read

file.write


Messages/Queues

Messages/Queues 跨度应尽可能遵循 OpenTelemetry 的 Messaging 语义约定。


Category Usage Description
topic


topic.send

topic.recieve

topic.process
queue


queue.process
job


job.exec
celery


相关实践学习
【文生图】一键部署Stable Diffusion基于函数计算
本实验教你如何在函数计算FC上从零开始部署Stable Diffusion来进行AI绘画创作,开启AIGC盲盒。函数计算提供一定的免费额度供用户使用。本实验答疑钉钉群:29290019867
建立 Serverless 思维
本课程包括: Serverless 应用引擎的概念, 为开发者带来的实际价值, 以及让您了解常见的 Serverless 架构模式
相关文章
|
4月前
|
数据采集 开发工具 Python
海康威视工业相机SDK+Python+PyQt开发数据采集系统(支持软件触发、编码器触发)
该系统基于海康威视工业相机SDK,使用Python与PyQt开发,支持Gige与USB相机设备的搜索及双相机同时显示。系统提供软件触发与编码器触发模式,并可在数据采集过程中实时保存图像。此外,用户可以调节曝光时间和增益,并进行信息输入,这些信息将被保存至配置文件以便下次自动加载。参数调节与实时预览等功能进一步增强了系统的实用性。
224 1
|
4月前
|
存储 监控 开发工具
Django 后端架构开发:手机与邮箱验证码接入、腾讯云短信SDK和网易邮箱
Django 后端架构开发:手机与邮箱验证码接入、腾讯云短信SDK和网易邮箱
68 0
|
5月前
|
NoSQL 开发工具 数据库
开发与运维测试问题之应用启动报 Can not load this fake sdk class 的异常如何解决
开发与运维测试问题之应用启动报 Can not load this fake sdk class 的异常如何解决
|
7月前
|
开发工具 CDN 容器
基于Html+腾讯云播SDK开发的m3u8播放器
周末业余时间在家无事,学习了一下腾讯的云播放sdk,并制作了一个小demo(m3u8播放器),该在线工具是基于腾讯的云播sdk开发的,云播sdk非常牛,可以支持多种播放格式。
237 1
|
6月前
|
API 开发工具
抖音sdk,抖音开发api接口
抖音sdk,抖音开发api接口
|
7月前
|
Java 开发工具 Maven
Android SDK开发的那些事(1),已整理成文档
Android SDK开发的那些事(1),已整理成文档
|
7月前
|
缓存 监控 小程序
微信小程序全栈开发中的性能监控与调优
【4月更文挑战第12天】本文探讨了微信小程序全栈开发中的性能监控与调优。页面加载速度、响应速度、内存占用和电量消耗是关键性能问题。开发者可利用微信小程序开发者工具进行性能监控,分析指标并优化代码、数据缓存、资源管理。通过综合性能调优,提升小程序性能和用户体验,降低用户流失。开发者需持续关注和学习新性能优化技术。
217 2
|
7月前
|
API 开发工具 C#
[相机开发] VC++联合相机SDK开发
[相机开发] VC++联合相机SDK开发
80 0
|
7月前
|
人工智能 缓存 前端开发
下一代 AI 开发工具Vercel AI SDK 快速入门
下一代 AI 开发工具Vercel AI SDK 快速入门
351 0
|
7月前
|
JSON JavaScript 前端开发
全面的.NET微信网页开发之JS-SDK使用步骤、配置信息和接口请求签名生成详解
全面的.NET微信网页开发之JS-SDK使用步骤、配置信息和接口请求签名生成详解

热门文章

最新文章