Prometheus 支持通过 HTTP 摄取 OTLP（即“OpenTelemetry 协议”）数据。
默认情况下，OTLP 接收器与远程写入接收器一样被禁用。这是因为 Prometheus 可以在没有任何身份验证的情况下工作，因此除非明确配置，否则接受传入流量是不安全的。
要启用接收器，您需要打开 CLI 标志 --web.enable-otlp-receiver。这将使 Prometheus 在 HTTP 路径 /api/v1/otlp/v1/metrics 上提供 OTLP 指标接收功能。
$ prometheus --web.enable-otlp-receiver
通常，您需要告知 OTLP 指标流量的源头 Prometheus 的端点以及应该使用 OTLP 的 HTTP 模式（gRPC 通常是默认值）。
OpenTelemetry SDK 和插桩库通常可以通过标准环境变量进行配置。以下是将 OpenTelemetry 指标发送到本地主机上的 Prometheus 服务器所需的 OpenTelemetry 变量
export OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
export OTEL_EXPORTER_OTLP_METRICS_ENDPOINT=http://localhost:9090/api/v1/otlp/v1/metrics
关闭跟踪和日志
export OTEL_TRACES_EXPORTER=none
export OTEL_LOGS_EXPORTER=none
OpenTelemetry 指标的默认推送间隔是 60 秒。以下将设置 15 秒的推送间隔
export OTEL_METRIC_EXPORT_INTERVAL=15000
如果您的插桩库未开箱即用地提供 service.name 和 service.instance.id，强烈建议您设置它们。
export OTEL_SERVICE_NAME="my-example-service"
export OTEL_RESOURCE_ATTRIBUTES="service.instance.id=$(uuidgen)"
以上假设您的系统上可用 uuidgen 命令。请确保 service.instance.id 对于每个实例都是唯一的，并且每当资源属性发生变化时都会生成新的 service.instance.id。推荐的方法是在实例每次启动时生成一个新的 UUID。
本节解释了 Prometheus 服务器的各种推荐配置方面，以启用和调优您的 OpenTelemetry 数据流。
请参阅我们将在以下部分使用的示例 Prometheus 配置文件：文件。
您可能希望启用乱序数据摄取的原因有很多。
例如，OpenTelemetry Collector 鼓励批量处理，并且您可能有多个 Collector 副本来向 Prometheus 发送数据。由于没有机制对这些样本进行排序，它们可能会出现乱序。
要启用乱序数据摄取，您需要在 Prometheus 配置文件中添加以下内容
storage:
tsdb:
out_of_order_time_window: 30m
在大多数情况下，30 分钟的乱序数据已经足够，但请根据您的需求随意调整此值。
根据经验和与社区的交流，我们发现，在所有常见的资源属性中，有些属性值得附加到所有 OTLP 指标上。
默认情况下，Prometheus 不会提升任何属性。如果您想提升其中的任何属性，可以在 Prometheus 配置文件的此部分进行。以下代码段分享了最佳实践的属性集，供您提升
otlp:
# Recommended attributes to be promoted to labels.
promote_resource_attributes:
- service.instance.id
- service.name
- service.namespace
- service.version
- cloud.availability_zone
- cloud.region
- container.name
- deployment.environment
- deployment.environment.name
- k8s.cluster.name
- k8s.container.name
- k8s.cronjob.name
- k8s.daemonset.name
- k8s.deployment.name
- k8s.job.name
- k8s.namespace.name
- k8s.pod.name
- k8s.replicaset.name
- k8s.statefulset.name
所有未被提升的、更详细或唯一的标签都附加到一个特殊的 target_info。
您可以使用此指标在查询时连接一些标签。
一个此类查询的示例如下所示
rate(http_server_request_duration_seconds_count[2m])
* on (job, instance) group_left (k8s_cluster_name)
target_info
此查询的作用是，rate(http_server_request_duration_seconds_count[2m]) 生成的时间序列会附加来自 target_info 系列的 k8s_cluster_name 标签，这些系列共享相同的 job 和 instance 标签。换句话说，job 和 instance 标签在 http_server_request_duration_seconds_count 和 target_info 之间共享，类似于 SQL 外键。另一方面，k8s_cluster_name 标签对应于 OTel 资源属性 k8s.cluster.name（Prometheus 会将点转换为下划线）。
那么，target_info 指标与 OTel 资源属性之间有什么关系？当 Prometheus 处理 OTLP 写入请求时，如果包含的资源包含属性 service.instance.id 和/或 service.name，Prometheus 会为每个 (OTel) 资源生成信息指标 target_info。它会为每个此类 target_info 系列添加标签 instance，其值为 service.instance.id 资源属性的值；以及标签 job，其值为 service.name 资源属性的值。如果存在资源属性 service.namespace，则将其前置到 job 标签值（即 <service.namespace>/<service.name>）。
默认情况下，service.name、service.namespace 和 service.instance.id 本身不会添加到 target_info 中，因为它们被转换为了 job 和 instance。但是，可以启用以下配置参数，将它们直接添加到 target_info 中（如果 otlp.translation_strategy 是 UnderscoreEscapingWithSuffixes，则会经过标准化处理，将点替换为下划线），这是在转换为 job 和 instance 的基础上进行的。
otlp:
keep_identifying_resource_attributes: true
其余的资源属性也会作为标签添加到 target_info 系列中，如果 otlp.translation_strategy 是 UnderscoreEscapingWithSuffixes，则名称会转换为 Prometheus 格式（例如，点转换为下划线）。如果资源同时缺少 service.instance.id 和 service.name 属性，则不会生成相应的 target_info 系列。
对于资源的每个 OTel 指标，Prometheus 会将其转换为相应的 Prometheus 时间序列，并且（如果生成了 target_info）添加正确的 instance 和 job 标签。
从 3.x 版本开始，Prometheus 支持指标名称和标签使用 UTF-8，因此可以省略 OpenTelemetry 的 Prometheus 标准化转换器包。
UTF-8 在 Prometheus 存储和 UI 中默认启用，但您需要为 OTLP 指标接收器配置 translation_strategy，其默认设置为旧的标准化方式 UnderscoreEscapingWithSuffixes。
我们建议将其设置为 NoUTF8EscapingWithSuffixes，这将禁用将特殊字符更改为 _，从而允许原生使用 OpenTelemetry 指标格式，特别是配合语义约定使用时。请注意，单位和计数器使用的 _total 等特殊后缀仍会附加。目前正在进行取消后缀生成的工作，敬请关注。
otlp:
# Ingest OTLP data keeping UTF-8 characters in metric/label names.
translation_strategy: NoUTF8EscapingWithSuffixes
OpenTelemetry 规范规定，Delta Temporality 和 Cumulative Temporality 都受支持。虽然 Delta Temporality 在 statsd 和 graphite 等系统中很常见，但 Cumulative Temporality 是 Prometheus 中的默认设置。
如今，Prometheus 内嵌了来自 OpenTelemetry-Collector-contrib 的 delta 转 cumulative 处理器，该处理器能够摄取 delta 数据并将其转换为等效的 cumulative 表示形式，然后存储在 Prometheus 的 TSDB 中。
此功能是实验性的，因此启动 Prometheus 时需要启用功能标志 otlp-deltatocumulative 才能使用它。
团队仍在研究更高效地处理 OTLP delta 数据的方法。
本文档是开源的。请通过提交问题或拉取请求来帮助改进它。