Instana 日志记录的最佳实践 OpenTelemetry 日志记录
要为 OpenTelemetry （OTEL）收集器应用通用日志采集，请根据已知功能和限制遵循以下最佳实践：
应用程序日志
任何日志监控和分析平台的价值都取决于其采集日志的质量。 因此，日志的结构会极大影响日志消息在诊断问题时的有效性。
使用定义明确的日志语义，为时间戳、日志级别、错误代码和上下文信息提供统一的格式。 这种方法有助于深入理解应用程序行为，并支持根本原因分析。
标准日志记录功能可提供结构化日志记录。 例如，各种 Java 日志框架都使用了 Simple Logging Facade（用于 Java （ SLF4J ）） API ，以及 Golang 中的 slog 包，该包支持键值结构化日志记录。
仅记录必要信息，避免生成对应用程序毫无价值的冗余日志。 日志过多可能导致性能下降，增加内存和网络压力，并使 Instana 对日志数据进行不必要的保留和分析。
OpenTelemetry 收集器日志收集
属性提取
日志消息关联
Instana 利用充足的上下文资源和日志记录属性 ，将日志消息与其生成实体关联起来，从而在二者之间建立联系。 Instana 采用尽力而为策略，利用有效负载中提供的属性建立关联。 最直接的关联使用进程标识符（PID），而最间接的关联则使用主机机器。
配置OTEL收集器，使其将日志数据直接发送到与OTEL收集器运行在同一主机上的 Instana 代理。 此配置会自动将 Instana 代理的主机设置为被监控应用程序所在的主机，从而为日志提供最少的直接关联。
请勿将来自多个主机的OTEL收集器配置为将日志发送到同一个 Instana 代理。 这样做可能会导致日志的主机归属错误。 因此， Instana 无法如预期般关联日志消息。
容器与集群相关性
容器化应用场景直接支持实体关联，适用于由 K8sattributes 处理器捕获的 Kubernetes 属性，例如 container.id。 该 container.id 属性用于将日志与容器实体进行匹配，这些实体由 Instana 的原生[ DockerLog 和 ContainerD 传感器进行监控。 同样地，` Kubernetes ` k8s.pod.uid 属性用于将日志关联至其对应的 `` Pod 实体，这些实体由 ` Kubernetes ` 传感器注册。 在容器化应用中捕获进程标识符（PID）没有用处。 每个容器都拥有独立的进程ID命名空间，在该命名空间内，进程的进程ID从1开始分配。 因此， container.id 它为容器化应用程序提供了最直接的连接。
有关集群环境的更多信息，请参阅集群监控文档。
Instana 支持以下容器或集群相关字段，这些字段可作为属性进行捕获：
container.idk8s.pod.uidk8s.job.uidk8s.cronjob.uidk8s.node.uidservice.instance.id
对于 AWS 的部署，可捕获以下属性：
aws.ecs.container.arnfaas.id
导出日志数据
过滤日志有效负载
由于应用程序日志生成的特性，应用程序可能通过日志意外泄露敏感的个人身份信息（PII）数据，例如信用卡号和凭证信息。 为避免将敏感信息包含在发送到 Instana 的日志负载中，请使用过滤处理器。 将此处理器置于OTEL日志管道配置的前端，可防止其他管道处理器对被丢弃且永远无法到达 Instana 的日志消息进行不必要的处理。
日志消息批处理
批处理程序将日志消息放入队列，并批量发送至 Instana。 使用批处理器通过减少传输数据所需的出站连接数量来降低网络负载，并支持对出站数据进行更高效的压缩。 将此处理器放置在日志处理器管道的末端。 此种放置方式有助于确保处理日志记录内容、过滤或采样操作的处理器在批处理有效负载构建之前运行。
批处理程序的性能取决于配置的批处理大小。 如果批处理大小过低，会增加外发请求的数量，从而增加网络流量。 另一方面，如果批处理大小过高，则会增加内存压力，并可能导致内存不足（OOM）错误。
选择两个足够远的数值（ send_batch_size 例如5000 send_batch_max_size 和10000）。 这增加了以下可能性：如果日志文件中添加了对应的异常堆栈跟踪行，所有这些行都将在发送前被添加到同一个批次中。 如果异常堆栈跟踪中的日志行被添加到不同的批次（或甚至单独发送，未进行任何批处理），它们在Unbounded分析中可能不会按原始顺序显示。
为批处理选择一个 timeout 值，使其在正常条件下能够扩展 send_batch_size 至指定规模，同时确保日志消息在您的使用场景所需的时间范围内完成分发——即使数据流入量低于常规水平时亦能实现。
有关 batch 处理器配置的更多信息，请参阅 OpenTelemetry collector。
默认的批处理器配置适用于许多客户端场景。 然而，建议熟悉配置选项，以评估特定场景下的内存和网络使用影响，尤其是在高吞吐量场景中。 您还可以使用 exporterhelper 插件来优化导出器的性能。
减少不必要的日志捕获
如果您的应用程序生成冗余或低价值日志并将其发送到 Instana ，请使用过滤器处理器在日志到达 Instana 之前将其移除。 您可以完全移除整个日志类别，或使用probabilisticsampler 处理器对生成的日志进行抽样捕获。 此操作可减轻网络负载，通过减少噪声来提升摄入日志的质量，并节省处理和存储成本。
数据压缩
根据日志收集场景考虑采用有效负载压缩。 并非所有日志收集场景都能从压缩率和压缩比中获得显著效益。
如果您的OTEL收集器处于CPU瓶颈状态（即CPU成为性能限制因素，而磁盘、内存和网络资源均属可变因素），且运行在高速网络环境中，请禁用数据压缩功能以提升性能。 在这种情况下，压缩带来的效益有限。 对于较慢的网络，请启用压缩功能以减少需要传输的数据量。 较小的日志批次大小会降低压缩算法识别模式的可能性。 因此，相对于较大的批量负载，压缩率会下降，同时CPU使用率会上升——这是因为压缩算法需要更努力地工作，却发现可压缩结构更少。
压缩率取决于日志数据的熵值，该值衡量数据中包含的信息量或随机性程度。 因此，熵值较低的日志包含更多重复内容，从而实现更优的压缩效果。 熵值较高的日志模式较少，因此压缩效果较差。
有关压缩选项的更多信息，请参阅 HTTP 有效负载压缩和 gRPC 有效负载压缩 ，具体取决于首选的数据传输方式。
gzip 压缩算法将OTEL有效负载发送至 Instana。数据加密
在生产环境中始终启用加密功能。 如果OTEL收集器向本地 Instana 代理发送数据，请按照以下步骤启用 Instana 代理与后端之间的 TLS 加密通信。