OpenTelemetry属性命名的五个最佳实践( 二 ) _OpenTelemetry

为避免与其他项目、供应商或公司发生冲突，明智的做法是考虑使用基于公司域名的前缀，以相反的顺序，例如io.chronosphere.myapp 。
即使您确定该名称绝对不会在您的应用程序之外使用，仅在公司内部使用，前缀仍然是防止冲突的重要手段。考虑使用与您的应用程序或项目相关联的前缀名称，例如bluebook.widget_count 。
你可能会想要利用属于 OpenTelemetry 或其他项目或供应商的现有前缀。共享前缀可能导致后续发生名称冲突，使您和同事在事故期间努力找到将他人的数据与您的数据分开的方法。
4. 注重服务水平在决定要应用于您的跟踪的属性时，请记住您的应用程序的重点是为客户提供高质量的软件体验。这一使命被编码在您服务/应用程序的服务水平目标（SLOs）中，可能以 99.999% 的正常运行时间期望的形式存在。从 SLO 中，您可以缩小到哪些服务水平指标（SLIs）最好支持或最有可能威胁实现 SLOs 。您的属性应支持您的服务水平。
例如，如果您在流量的不同部分之间有延迟 SLO，使用提供段维度的属性，如 ProductID、FeatureID 或 RegionID，可以帮助您相应地组织警报。
5. 思考新的用例将属性视为分布式系统中模式匹配的根源。如果您想要调查跨类别和类别之间的关系，属性是排序和比较的工具。
逐步尝试不同的属性，看看会有什么变化。让我们考虑一个例子。
你的高级客户是否因发票错误而联系支持？难道订单服务不是几分钟前部署了新版本吗？对比属性，例如service.version和membership.level，对服务名称为 order 的错误指标进行关联，可以帮助确定高级会员的升高错误率是否与订单服务的新版本高度相关。
有用的属性类型在制定 OpenTelemetry 的标准属性时进行了大量慎重考虑，而这个列表一直在不断发展。尽管这里无法提及所有类别，但在制定内部命名标准时探索现有内容并强调在调查回归时对团队有用的内容可能会很有帮助。以下是注册表中的一些示例：

常规属性：常规属性提供有关整体环境和网络的广泛背景信息。

server.address：服务器的地址。
destination.address：目标的地址。
code.filepath：代码的文件路径。

消息系统：与消息系统相关的属性，有助于跟踪和诊断消息处理中的问题。
messaging.destination：
描述消息发布到的逻辑实体。
messaging.kafka.consumer.group：
处理消息的 Kafka 消费者组。
messaging.message.body.size：
消息主体的大?。ㄗ纸冢?。
HTTP：对于跟踪 HTTP 请求和响应至关重要，提供有关 Web 事务的见解。
http.url：
完整的 HTTP 请求 URL 。
http.status_code：
HTTP 响应状态码。
user_agent.original：
客户端的 HTTP User-Agent 头的值。
资源属性：这些属性提供有关服务、基础设施和操作环境的详细背景信息。
service.version：
服务的版本。
k8s.cluster.name：
Kubernetes 集群的名称。
gcp.gce.instance.name：
google Compute Engine 实例的名称。
aws.ecs.container.arn：
ECS 容器的 Amazon 资源名称（ARN）。

那事件呢？有一种特殊类型的跨度属性称为跨度事件日志经常被忽视。跨度事件与日志非常相似，但它们是放置上下文信息的好地方，这些信息在故障排除事务问题时可能非常有用。
在考虑要放入跨度事件日志的内容时，应清理任何私人用户数据的有效负载/添加跨度内发生的任何事件，包括所发生事件的简要摘要、任何异常或完整的错误消息，以及额外的上下文信息。
避免的属性实践我们一直在关注属性的“做法”，但这里更仔细地看一下一些要避免的属性陷阱。