OTCA 模拟考 A
哪种说法最准确地描述了监控和可观察性之间的关系?
- 监控在本地使用,可观察性在云中使用。
- 监控是指人们查看屏幕,而可观察性是指自动化查看屏幕。
- 监控监控预先确定的故障情况,可观察性是指通过数据追踪甚至意外故障的能力。
- 可观察性消除了对通知规则的需要,因此我们需要消除监控。
如果我将请求 ID 或用户 ID 等值添加到指标标签中会发生什么?
- 每个标签组合都会产生一个单独的时间序列,从而导致基数爆炸并将存储和查询一起崩溃。
- 聚合函数不起作用,因为度量值不是整数。
- OTLP不支持字符串标签,因此它们将在传输阶段被拒绝
- SDK将标签转换为哈希值,因此无法读回该值。
是什么让您能够在指标图表中找到具有大量延迟的部分,然后直接转到该部分的实际跟踪?
- 直方图桶边界
- 资源属性
- 行李物品
- 例子
RED方法和USE方法有什么区别?
- 不同之处在于 RED 查看日志,而 USE 查看指标。
- RED是处理请求的服务,而USE是资源视角,所以它们的目标不同。
- RED 旨在用于开发环境,USE 旨在用于操作环境。
- RED 是 CNCF 标准,USE 是已弃用的方法
使用结构化日志的最实际原因是什么?
- 由于字段具有名称和类型,因此您可以查询它们并将它们与其他信号关联起来,而无需使用正则表达式。
- 与纯文本日志相比,存储容量始终减少一半以下
- 即使没有日志收集器,后端也会自动收集日志。
- 仅结构化日志可以作为 OpenTelemetry 日志信号发送
SLO 和错误预算之间的正确关系是什么?
- 错误预算会结转到下个月,并且仅在实现 SLO 的月份进行累积。
- 如果错误预算仍然存在,您可以停止测量 SLI。
- 错误预算是SLO目标与100%之间的余量,其是否保持是调整部署速度的基础。
- 如果将 SLO 设置为 100%,错误预算将变为无穷大。
您需要知道特定请求在哪个服务上花费了时间。哪种信号最好,为什么?
- 这是一个指标。这是因为合计值是最准确的。
- 这是一个痕迹。这是因为一个请求以父子关系连接粗略的部分。
- 这是一个日志。因为所有的服务都已经留下了日志
- 这是一个个人资料。这是因为你可以看到函数单位时间。
OpenTelemetry 项目不提供什么?
- 用于创建遥测数据的 API 和 SDK
- OTLP,遥测传输协议
- 用于长期存储和查询遥测数据的存储库
- 收集和处理遥测数据的收集者
我们希望降低观测数据的成本。为了尽量减少信息丢失,首先应该解决什么问题?
- 将所有服务的日志级别提升为ERROR
- 完全停止收集痕迹,只留下指标
- 将保存期限缩短至1天
- 就像健康检查一样,它过滤掉无用的流量并将重复的事件转化为聚合。
为什么 OpenTelemetry 规范中为每个信号指定了单独的稳定性级别?
- 这是为了显示不同语言的 SDK 性能差异。
- 设计的固化点因每个信号而异,如果处于稳定水平,则承诺不会进行会破坏兼容性的更改。
- 这是为了区分付费支持的范围。
- 这是因为收集器无法处理低等级信号。
在故障调查期间,您需要知道“哪些代码正在使用CPU”。什么信号可以回答这个问题?
- 公制
- 日志
- 轮廓
- 痕迹
TracerProvider 的正确作用是什么?
- 它是一个HTTP客户端,直接将span传输到后端。
- 创建 Tracer 并保存 SDK 设置,例如采样器、跨度处理器和资源。
- 这是一个定义收集器中管道的配置块。
- 这是一个将跟踪上下文序列化为标头的组件。
接收和处理 HTTP 请求的服务器端条目 Span 应该附加什么 SpanKind?
- 内部的
- 客户
- 制片人
- 服务器
为什么在跨度中记录异常时需要包含状态代码?
- 这是因为记录异常会自动终止跨度。
- 异常日志记录仅添加一个事件,因此您必须单独将状态设置为 ERROR 以指示此部分失败。
- 这是因为如果您不设置状态,则跨度将被导出器丢弃
- 这是因为异常记录和状态设置是相同的操作,因此您只需要调用其中之一即可。
划分跨度属性和跨度事件的正确标准是什么?
- 属性是描述整个部分的键值,事件是在该部分内的特定时间发生的事情。
- 属性仅包含字符串,事件仅包含数字。
- 属性由 SDK 附加,事件由收集器附加。
- 属性是可搜索的,但事件则不可搜索。
为什么在一批处理 100 条消息的消费者 Span 中需要 Span Link?
- 这是因为链接继承了父跨度的采样决策。
- 这是因为如果没有链接,则不会创建跨度
- 这是因为批处理无法创建跟踪,因此改用链接。
- 你只能有一个父母,但有多个因果痕迹,所以你需要用链接指向其余的。
W3C 跟踪上下文的tracestate 标头包含什么?
-
这是每个供应商的附加状态信息,并且携带键值列表中无法用traceparent表达的值。
-
一位指示是否采样
-
这是请求正文的哈希值。
-
仅当对迹线进行采样时才会传播行李
-
Baggage 会自动提升为 span 属性,因此无需单独配置。
-
Baggage按原样携带在所有子调用的HTTP标头中,因此如果输入敏感信息,它将泄漏到外部服务,并且标头大小也会增加。
-
行李仅在流程内有效,不会传播到网络。
未单独指定 OTEL_PROPAGATORS 的 SDK 的默认传播器组合是什么?
- b3和耶格
- 没有注册发射器
- 跟踪上下文和行李
- X射线和OTTrace
旧服务仅发送 B3 标头,而新服务仅读取跟踪上下文。出现什么症状?
- 两个服务之间的调用在连接本身上失败
- 新服务启动新的跟踪,因为它找不到其父级,并且跟踪在边界处中断。
- 跟踪 ID 混合在一起,将不同的请求合并到一个跟踪中
- SDK 会自动在两种格式之间进行转换,因此您不会遇到任何问题。
当使用同步仪器记录不断增长的重复值(例如当前活动连接的数量)时,以下哪一项是合适的?
- 柜台
- 直方图
- 增减计数器
- 可观察计数器
为什么我们在记录请求延迟时使用直方图而不是计量表?
- 这是因为Histogram传输的数据总是小于Gauge。
- 这是因为 Gauge 只能包含整数。
- Gauge 在观察时只留下一个值,从而失去了分布和百分位数,但 Histogram 保留了桶的数量,可以产生 p95 等值。
- 这是因为仪表不是通过 OTLP 传输的。
为可观察(异步)工具编写回调时应遵循哪些规则?
- 每个收集周期都会调用回调,因此它们必须快速完成,并且不应包含阻塞操作或引发异常的代码。
- 您必须在回调中调用至少一种其他工具
- 回调必须由应用程序在任何时间点直接调用。
- 回调仅在进程启动时执行一次
指标的增量时间性和累积时间性之间有什么区别?
- delta 仅用于跟踪,cumulative 仅用于指标。
- delta 是自上次收集以来的变化,cumulative 是从开始的累积值。
- delta 只能包含整数,cumulative 只能包含实数。
- delta只能在SDK中创建,cumulative只能在collector中创建。
我们想要更改特定直方图的存储桶边界并删除一个不必要的属性。 SDK中使用什么?
- 采样器
- 资源检测器
- 传播者
- 看法
OpenTelemetry 日志信号的设计与跟踪或指标有何不同?
- 默认的引入路径是保持现有的日志框架不变,并通过桥(appender)将其连接起来。
- 日志无法通过OTLP传输,因此它们以文件形式保留,由收集器单独读取。
- 日志没有 API,仅由收集器生成。
- 日志没有资源属性
我需要什么才能从日志中获取trace_id并将其与跟踪连接起来?
- 当您打开收集器的批处理器时,它会自动附加。
- 需要仪器在记录时从活动上下文中读取跨度上下文并将其放入字段中。
- 后端将日志和跨度与接近的时间戳配对
- 如果将日志级别提升为DEBUG,SDK会自动添加。
当代码中创建的 Resource 和 OTEL_RESOURCE_ATTRIBUTES 环境变量具有相同的键时,正确的处理是什么?
- SDK检测到冲突并中止启动
- 两个值成为一个字符串,以逗号分隔。
- 环境变量值始终优先,代码设置被忽略。
- 资源被合并,显式创建的资源将覆盖环境变量中的默认资源。
在 Kubernetes 中,以下哪种方法不需要修改应用程序代码以包含 pod 名称和命名空间作为资源属性?
- 使用 Downward API 将值放入环境变量中并将其传递给 OTEL_RESOURCE_ATTRIBUTES,或将其附加到收集器的 k8sattributes 处理器。
- kubelet 拦截 OTLP 负载并自动插入 pod 名称和命名空间。
- SDK直接查询API服务器并填写。
- OTLP header 默认包含 Pod 信息
当 BatchSpanProcessor 的队列已满时会发生什么?
- 应用程序线程等待,直到队列中有可用空间
- 新传入的跨度将被悄悄丢弃,并且仅增加丢弃计数器。
- 处理器自动将队列大小加倍
- 导出器切换到同步模式
为什么SimpleSpanProcessor不在生产环境中使用?
- 这是因为它忽略了采样决策并导出所有跨度。
- 这是因为它不附加资源属性。
- 这是因为它在每个跨度的末尾立即导出,因此网络延迟被直接带入呼叫路径。
- 这是因为不支持 OTLP,并且只能进行控制台输出。
当遥测在短期批处理作业或无服务器功能中丢失时,您的代码应该做什么?
- 在终止进程之前,调用强制刷新和终止以刷新队列中的任何剩余数据。
- 通过设置更长的导出间隔来增大批量
- 通过将采样率降低到0来减少数据量
- 请务必将 SimpleSpanProcessor 替换为 BatchSpanProcessor
默认采样器parentbased_always_on的正确行为是什么?
- 遵循父级的采样决策(如果有),并且始终仅对没有父级的根跨度进行采样。
- 所有跨度都将单独重新评审,无论他们是否为父母。
- 即使父级没有被采样,子级也总是被采样
- 计算trace ID哈希值,只留下固定的百分比
头部采样决策如何传递给下游服务?
- 收集器查看服务列表并将其决定通知每个服务。
- 如果每个服务设置相同的采样率,判断结果会自动匹配。
- SDK 查询后端以查看跟踪是否已被采样。
- 它在traceparent标头的采样标志位中传播,子服务中的基于父级的采样器也会效仿。
零代码检测有哪些限制?
- 开启自动检测后,手动检测 API 不能一起使用。
- 自动检测仅创建指标而不创建跟踪
- 它设置了受支持的库的边界,但无法创建业务逻辑的有意义的部分和域属性。
- 自动测量仅适用于收集器
您可能只想暂时关闭某些 Pod 上的 SDK 以调查性能问题。如何在不更改代码的情况下使用它?
- 将 OTEL_SDK_DISABLED 设置为 true 以使 SDK 成为无操作。
- 将 OTEL_EXPORTER_OTLP_ENDPOINT 保留为空字符串
- 将 OTEL_LOG_LEVEL 保留为无
- 清除 OTEL_SERVICE_NAME 以释放资源
使用OTEL_EXPORTER_OTLP_TRACES_ENDPOINT时需要注意什么?
- 该变量仅在gRPC中有效
- 由于它是信号特定的变量,因此在 HTTP 中,SDK 不会添加路径,并且必须写入直到 /v1/traces 的整个值。
- 如果您使用此变量,指标和日志将一起发送到同一地址。
- 它的优先级比普通变量低,一起使用会被忽略。
遵循语义约定而不是任意命名跨度属性的最合适原因是什么?
- 这是因为随机属性不会传输到 OTLP。
- 这是因为 SDK 对属性数量的限制不适用于约定属性,因此您可以放置更多。
- 这是因为只有约定属性可以被索引和搜索。
- 这是因为后端、仪表板和收集器处理器在承诺密钥的前提下运行,因此如果名称不匹配,现有工具将无法识别数据。
我的代码创建了一个跨度,但省略了终止调用。结果如何?
- 进程结束后SDK自动关闭,正常传输。
- 相反,父跨度终止,因此其持续时间记录为 0。
- 创建下一个跨度时,上一个跨度会自动关闭
- 该跨度不会导出,只有其子跨度到达,从而使跟踪显示为空或不完整。
将收集器部署为代理和将其部署为网关有什么区别?
- 代理仅处理跟踪,网关仅处理指标
- 代理连接到节点或 sidecar 以收集本地数据,网关将它们作为单独的服务收集,并集中处理和路由它们。
- 代理只能使用Core发行版,网关只能使用Contrib发行版。
- 网关没有状态,代理有状态
我只在接收器和导出器中定义了该组件,但没有将其放入 service.pipelines 中。结果如何?
- 它只是定义了,并没有实际实例化,因此它不执行任何操作。
- 由于配置错误,收集器无法启动
- 它自动集成到基础管道中并运行。
- 留下警告日志后,收到第一个数据时会自动激活。
我打开了容器中的otlp接收器,但无法从外部连接。最可能的原因是什么?
- gRPC 不在容器内运行
- 接收方请求 TLS,但客户端正在发送纯文本。
- 收集器在没有处理器的情况下无法打开接收器
- 该端点绑定到本地主机,因此它不会接收来自容器外部的连接。
memory_limiter 处理器的正确行为是什么?
- 如果内存超出,收集器将重新启动以回收资源。
- 当内存使用达到临界点时,数据被拒绝,接收方向客户端返回错误,从而向前传递反压。
- 当内存使用达到临界点时,旧数据会被悄悄丢弃。
- 自动减少导出器队列大小
属性处理器和资源处理器有什么区别?
- 属性仅适用于跟踪,资源仅适用于指标
- 属性仅添加值,资源仅删除它们
- 属性处理每个范围或数据点的属性,资源处理描述创建数据的主体的资源属性。
- 属性只能在collector中使用,resource只能在SDK中使用
哪个收集器组件适合需要条件和转换的处理,例如仅屏蔽部分属性值?
- 使用 OTTL 语法的转换处理器
- 批处理器
- 内存限制器处理器
- 概率采样处理器
在收集器管道中同时使用 memory_limiter 和批处理时,建议的顺序是什么?为什么?
- 将批次放在第一位,以便内存限制器知道确切的大小
- 该顺序仅影响性能,对行为没有影响。
- 两个处理器不能共存
- 必须先设置 memory_limiter 来保护内存,在过载时先拒绝数据,然后再批量堆叠数据。
我们希望通过将一个管道的输出作为另一管道的输入传递来从跨度创建一个指标。你需要什么?
- 扩大
- 将两个接收器绑定到同一端口
- 连接器
- 出口商路由选项
使用尾部采样增加网关数量时,前端需要做什么?
- 根据跟踪 ID 进行分配的负载均衡导出器层
- 循环型通用L4负载均衡器
- 设置为每个网关提供相同的静态 IP
- 网关之间共享文件存储
导出器的sing_queue 和retry_on_failure 角色之间的正确区别是什么?
- send_queue 设置重试间隔,retry_on_failure 设置队列大小。
- send_queue缓冲等待发送的数据,retry_on_failure将失败的请求重新发送到backoff。
- 两者功能相同,只需开启其中一个即可。
- send_queue 将数据写入内存,retry_on_failure 将数据写入磁盘。
即使收集器重新启动,如何防止队列中剩余的数据丢失?
- 将single_queue的大小增加到最大值
- 将批处理器超时设置为 0
- 将内存限制器的阈值提高到100%
- 通过附加 file_storage 扩展名并指定导出器队列应使用该存储,将队列保留到磁盘。
哪个扩展检查收集器本身的状态以及用于此目的的正确配对是什么?
- health_check 通过 HTTP 公开收集器的启动状态并将其写入 Kubernetes 探针。
- zpages 将导出器队列存储在磁盘上
- pprof 验证管道配置
- health_check测量后端的响应时间
k8sattributes 处理器无法附加 Pod 信息。首先要检查什么?
- 将收集器更改为 DaemonSet 而不是 sidecar
- 向前移动批处理器
- 验证收集器 ServiceAccount 是否具有查找 Pod 和命名空间的 RBAC 权限
- 将OTLP传输方式改为gRPC
我应该使用什么组件来让收集器检索 Prometheus 格式指标?
- 普罗米修斯远程写入导出器
- 普罗米修斯接收器
- 普罗米修斯连接器
- 普罗米修斯扩展
我将文档中看到的组件添加到设置中,但收集器无法启动,说是未知类型。检查分布的命令是什么?
- 使用 otelcol validate --config 检查语法
- 只需使用 otelcol --version 检查版本
- 使用 kubectl describe 查看 pod 事件
- 检查此二进制文件中包含的组件列表及其与 otelcol 组件的稳定性评级
我想直观地检查数据是否真正进入收集器。对于最新的发行版,我应该使用哪个导出器?
- 伐木出口商
- 诺普出口商
- 调试导出器
- 文件导出器
otelcol_exporter_send_failed_spans 正在稳步增加。这个指标说明了什么?
- 应用程序 SDK 无法创建跨度
- 接收方正在接收格式错误的有效负载
- 处理器正在根据策略过滤掉跨度
- 从收集器到后端的部分出现故障,因此需要查看后端状态、身份验证和网络。
当数据未到达后端时,分段缩小管道范围最合理的顺序是什么?
- 首先查看接收器接收指示器,然后查看处理器丢弃指示器,然后查看导出器发送失败指示器。
- 首先查看后端仪表板,如果没有则重新启动收集器
- 先清除导出器设置,然后一一重新安装。
- 通过将所有服务的采样率提高到 100% 来重现
收藏家拥有自己的遥测技术最合适的理由是什么?
- 这是因为收集者自己的指标被排除在后端的收费目标之外,并且不花费任何费用。
- 这是因为观察管道本身可能是一个故障点,因此需要一个独立的信号来判断管道是否已死或被推回。
- 这是因为它会自动更正配置文件中的语法错误。
- 这是因为处理器仅在其自身的遥测打开时才被激活。
采集器升级新版本后,启动失败。您应该首先在发行说明中检查什么?
- 容器镜像压缩大小的变化
- 支持的 Kubernetes 版本列表
- 新添加的出口商类型
- 是否存在过时或重命名的组件和配置密钥?
后端的度量时间序列数量突然成倍增加。在收集器级别采取的最合适的操作是什么?
- 通过增加导出器队列大小来减少传输失败
- 增加批处理器的批处理大小以减少前往后端的请求数量
- 找到导致高基数的属性,并使用转换或属性处理器将其删除或捆绑该值。
- 停止指标管道并仅留下跟踪