基于Opentelemetry标准化的产品应用
基于Opentelemetry标准化的产品应用
otel项目作为旨在解决可观测数据采集的最终标准化解决方案，数据的字段定义约定也是其落地的目标，这关系到后端观测系统的产品能力的衍生和发展。也是未来规范在不同的场景有着一致性的约束，对比与数据协议本身也是有着非常重要的作用。
otel语义标准化的字段定义
上述三个链接是目前otel协议已经落地的相关标准化字段和标准化定义的相关规范，也就是说所有的otel相关的落地使用我们都应该遵守这个规范。这些标准化的字段规范有哪些内容。
- 定义了不同场景下的该怎么命名字段。
- 定义了不同场景下我们应该怎么去设置我们的span或者metric的内容。
我们从三个场景的例子来看看这些定义都有什么
Resource
Resouce在otel里面是一个全局的通用标签，也就是说，这个内容一般对于一个服务来说都是一致的。生意在Resource里面我们一般定义了以下的标准化字段
- 服务的字段定义
这个定义就可以帮助我们的后段系统通过一下的字段，知道服务有哪些，以及服务的租户、实例和版本等。
| Attribute | Type | Description | Examples | Requirement Level |
|---|---|---|---|---|
service.name |
string | Logical name of the service. [1] | shoppingcart |
Required |
service.namespace |
string | A namespace for service.name. [2] |
Shop |
Recommended |
service.instance.id |
string | The string ID of the service instance. [3] | 627cc493-f310-47de-96bd-71410b7dec09 |
Recommended |
service.version |
string | The version string of the service API or implementation. | 2.0.0 |
Recommended |
- SDK的字段定义
- 例如
telemetry.sdk.name就可以表示访问所使用的sdk的名字，因为我们服务所使用的sdk不一定的otel官方的sdk也可以是用户自研或者jager等开源sdk，这样我们就可以较好的了解sdk的使用情况。
- 例如
- 环境的字段定义
- 操作系统
- 社保
- 云厂商
- 部署方式
- 浏览器
Trace
trace的规范一般是在使用traceSDK的使用需要记录一些我们相关埋点的一些信息。
比如我们要记录ip的时候要怎么命名呢？是ip,inner_ip,ipv4,ipv6呢？
如果是发生调用的时候怎么区别是本机的ip还是对端的ip呢。
这个规范定义就帮我们做到了这些。
Trace的标准规范就建议我们网络相关的使用net.*.name的命名方式，并且已经将常用的定义以及规范了下来。
比如ip的定义就是net.host.ipORnet.peer.ip分别表示本机的ip和对端的ip，我们也看到了我们使用net.host.*来表示本机的网络信息定义，net.peer.*来表示对方的网络信息定义，这样也就方便我们在数据分析的时候做到相关的关联分析。
| Attribute | Type | Description | Examples | Requirement Level |
|---|---|---|---|---|
net.transport |
string | Transport protocol used. See note below. | ip_tcp |
Recommended |
net.app.protocol.name |
string | Application layer protocol used. The value SHOULD be normalized to lowercase. | amqp; http; mqtt |
Recommended |
net.app.protocol.version |
string | Version of the application layer protocol used. See note below. [1] | 3.1.1 |
Recommended |
net.peer.ip |
string | Remote address of the peer (dotted decimal for IPv4 or RFC5952 for IPv6) | 127.0.0.1 |
Recommended |
net.peer.port |
int | Remote port number. | 80; 8080; 443 |
Recommended |
net.peer.name |
string | Remote hostname or similar, see note below. [2] | example.com |
Recommended |
net.host.ip |
string | Like net.peer.ip but for the host IP. Useful in case of a multi-IP host. |
192.168.0.1 |
Recommended |
net.host.port |
int | Like net.peer.port but for the host port. |
35555 |
Recommended |
net.host.name |
string | Local hostname or similar, see note below. | localhost |
Recommended |
我们以网络相关的规范字段定义来了解了Trace相关的定义其他的可以自行前往对应的文档地址查看。
Metric
Metric
Metric跟前两者不同的是，这里不仅有字段规范的定义，也有着指标名称的命名以及单位的规范建议。
命名规范
- limit 上限/总量
用来表示恒定，已知的指标对象应该叫做entity.limit, 例如system.memory.limit表示系统的内存总量 - usage 使用量
用来表示恒定的目标对象的使用量的指标对象应该叫做entity.usage, 例如system.memory.usage表示系统内存使用量 - utilization 利用率
个测量超出其限制的使用量的指标对象应该被叫做entity.utilization,例如system.memory.utilisation表示正在使用的内存部分.utilization应该在[0, 1] - time
用来表示时间流逝的指标对象应该叫做entity.timem, 例如system.cpu.time表示cpu的占用时间 - io
测量双向流动的指标对象应该叫做enitry.io, 例如system.network.io - other
如果不符合上述描述的目标，可以比较自由的命名例如network.packets
产品形态应用
我们如何在相关的观测产品上利用这些标准化的约定呢。众所周知，我们有了标准的数据，就可以尽可能的互相关联，减少我们在解决问题的时候排查时间，甚至在建设监控大盘的时候，可以比较容易的通告标准化的定义，快速建设相关仪表。
主机实例的产品关联
前置条件：主机性能数据 CMDB基础架构数据 网络性能数据
我们已知在数据中含有相关的ip字段内容，我们即可以通过ip与主机性能数据进行关联。如果CMDB系统比较强大的话。我们甚至可以直接展示主机到目标机器的直接的网络拓扑情况，能很快的排查底层的网络状态。
- 快速查看目标主机性能和调用方主机性能
- 查看主机之间的网络联通状态
容器实例级别的
前置条件：容器监控数据 容器基础数据
我们可以知道标准字段已经存在了容器习惯的字段，但是需要我们的SDK去在应用部署到docker或者k8s上面的时候去获取到容器基础数据。这样我们就能在仪表中快速关联到相关容器性能
- 快速查看相关联容器性能，k8s集群状态
DB级别
标准字段的DB字段，可以让我们识别出对应的数据库实例，这样可以直接查看数据库性能数据，而且可以进行sql的深度分析，来进行我们更加业务程度的性能分析。
- 数据库性能数据查看
sql分析
指标标准
我们可以标准的指标命名做什么，一旦指标在某个场景固定下来了指标的命名方式，我们即可以认为这个数据的已经固定了下来，我们可以正对一类的指标limit去固定相关的仪表使用方式，告警策略，更固定的命名可以直接固定仪表以及告警策略，对于用户来说，减少了使用成本，开箱即用。不用理解特定场景的下的指标命名。
- 固定仪表盘
- 固定告警策略
以上我们介绍了基于otel标准化的一些产品上的应用，otel不仅在做协议标准，SDK, collector,还有这些数据标准化也是相当重要的落地，只要这些标准化了，我们才能在产品上有更多的想象空间，不然就会在落地的实现上造成更多的割裂。希望otel的标准化落地越来越好，也希望在SDK有更多的标准化使用，以及落地实践。我们该怎样基于标准化去使用SDK,也希望更多的观测产品的设计者和开发者深度了解标准才能更好的设计出更好使用的可观测统一的产品。