PCA 模拟考 A

指标相对于日志最准确的优势是什么？

• 通过保留个人请求的完整背景，可以轻松进行后续调查。
• 由于这些数字是随着时间的推移而汇总的，因此存储成本较低，并且适合长期趋势和通知。
• 原样显示服务之间的调用关系
• 单独保存每个事件而不采样

我们应该如何定义 SLI 来捕获由于延迟而不是可用性而导致用户体验较差的情况？

• 仅查看成功回复的百分比
• 查看设定标准时间内成功请求的百分比
• 查看请求总数
• 查看响应时间的算术平均值

白盒监控和黑盒监控有什么区别？

• 白盒着眼于系统内部暴露的指标，黑盒着眼于可以从外部观察到的症状。
• 白盒用外部探头检查，黑盒用代码测量检查。
• 白盒仅使用日志，黑盒仅使用指标。
• 白盒只能在运行环境中使用，黑盒只能在开发环境中使用。

可观察性和监控之间最合适的关系是什么？

• 监控是回答预定问题的能力，可观察性是回答意外问题的能力。
• 可观察性是监视的旧名称，因此它们是同一件事。
• 监控仅处理指标，可观察性仅处理跟踪
• 可观察性是工具的名称，监控是过程的名称。

以下哪项不是四个黄金信号之一？

• 延迟
• 交通
• 部署频率
• 饱和

为什么高基数标签会出现问题？

• 这是因为为每个标签值组合创建一个单独的时间序列，从而显着增加内存和存储空间。
• 这是因为如果标签值很长，抓取请求将会失败。
• 如果标签过多，会出现 PromQL 语法错误。
• 这是因为如果标签值较多，则无法创建通知规则。

设置 SLO 时，不以 100% 为目标的最合适理由是什么？

• 因为 100% 测量本身是不可能的。
• 因为最后几位数的成本增长很快，你无力做出改变。
• 因为客户的要求并不是100%
• 因为普罗米修斯无法100%表达

当错误预算耗尽时，最合适的行动是什么？

• 通过降低 SLO 目标重新确保预算
• 放慢新功能部署，将重点转向提高稳定性
• 提高通知阈值以接收更少的通知
• 增加测量窗口以减少违规行为

哪个示例最适合作为分布式跟踪如何回答难以用指标回答的问题的示例？

• 过去 30 天内错误率有何变化？
• 这个缓慢的请求花费了时间在哪个服务部分？
• 集群当前的总请求吞吐量是多少？
• 节点内存利用率是否超过阈值？

USE 方法论中正确的三件事是什么？

• 利用率、饱和度、错误
• 请求率、错误、持续时间
• 利用率、速度、范围
• 正常运行时间、服务、体验

创建仪表板时最常见的错误是什么？

• 只放置几个关键指标，而不将面板分成小块
• 将所有可能的指标放在一个屏幕上，这样您就不知道该看哪里。
• 指定每个面板的单位
• 将用户角度的指标放在顶部

Prometheus 数据模型中时间序列的唯一标识是什么？

• 指标名称和标签名称/值集的组合
• 一个指标名称
• 抓取目标的IP地址
• 样本时间戳

以下哪一项不是 Prometheus 中的四种度量类型之一？

• 柜台
• 测量
• 计时器
• 直方图

关于计数器类型，以下哪项是正确的？

• 它可以上升和下降，因此适合当前的温度或队列长度。
• 它单调增加，并在进程重新启动时返回到 0。
• 值以每秒的速率自动转换和存储。
• 仅存储最近的值，并丢弃过去的值。

Prometheus 选择 pull 方法作为默认的最合适的原因是什么？

• 这是因为服务器知道目标列表，因此Scrape本身可以确定目标是否还活着。
• 这是因为它总是比推送方法使用更少的网络带宽。
• 这是因为目标不需要存储自己的指标。
• 因为根本不需要设置防火墙。

目标的up指标为 0 的最准确含义是什么？

• 目标的应用程序返回错误响应。
• 上一次抓取失败
• 目标从服务发现中消失
• 所有目标指标值为0。

仅使用 static_configs 管理目标而不使用服务发现时会出现什么问题？

• 每次目标增加或减少时，都必须修改设置并重新读取。
• 无法标记它们，因此无法在查询中区分它们
• 无法指定刮擦间距
• 您无法使用 TLS 进行抓取

如果scrape_interval持有时间过短，最合适的补偿是多少？

• 随着样本数量的增加，存储容量和查询成本都会增加。
• 标签基数自动增加
• 目标拒绝抓取
• 不评估通知规则

Prometheus TSDB 中头块的作用是什么？

• 压缩最旧的数据并将其移动到对象存储以进行长期存储。
• 最近的样本存储在内存中，写入 WAL，并定期传输到磁盘块。
• 缓存查询结果，重复相同请求时快速响应
• 保存通知规则的状态，以便它们在重新启动后保持不变

添加长期存储而不是增加 Prometheus 的数据保留期限最合适的理由是什么？

• 这是因为单实例的磁盘和内存很难处理，而且不冗余。
• 因为 Prometheus 不支持保留超过 30 天。
• 因为长期存储使得 PromQL 运行得更快
• 这是因为当附加长期存储时，基数限制就会消失。

如果设置honor_labels: true会发生什么？

• 来自抓取数据的标签优先于来自 Prometheus 的标签。
• 所有标签都转换为小写
• 目标标签将被忽略，仅保留作业标签。
• 标签值的长度限制被取消

如何正确使用Prometheus federation？

• 通过将所有时间序列从较低的服务器复制到较高的服务器来创建单个存储库。
• 通过仅将少量已聚合的时间序列从较低级别的服务器导入到较高级别来创建全局视角。
• 让父服务器直接抓取目标，而不是子服务器
• 来自下层服务器的通知规则被移至上层服务器并集中评估。

Prometheus实现高可用的一般方法有哪些？

• 多个实例选出一位领导者并只刮取一个
• 相同配置的两个实例独立地抓取相同的目标。
• 数据在实例之间实时复制以维护相同的块。
• 一个实例读取另一个实例的 WAL 作为共享卷

PromQL 中http_requests_total[5m]的结果类型是什么？

• 即时向量
• 区间向量
• 标量
• 细绳

在 Counter 中使用rate()时，是否被告知将段长度设置为至少几倍的抓取间隔？

• 1x
• 2次
• 4次
• 10次

rate()和irate()之间的正确区别是什么？

• rate 是整个区间的平均增长率，irate 是仅查看最后两个样本时的增长率。
• Rate 写在 Gauge 中，irate 写在 Counter 中。
• 速率不补偿重置，仅补偿
• irate 着眼于整个区间，rate 只着眼于最后一个样本。

什么最准确地描述了increase(http_requests_total[1h])？

• 它是过去一小时内观察到的最后一个值减去第一个值的整数差。
• 由于比率乘以间隔长度，因此可能会因外推而出现小数。
• 这是最后一小时的平均值
• 这是最近一小时内的最高值

当试图查看仪表的变化趋势时，应该使用哪个函数来代替rate()？

• 三角洲（）
• 增加（）
• 重置（）
• idelta() 和rate() 的组合

sum(rate(http_requests_total[5m])) by (job)和sum(rate(...)) without (instance)之间的正确区别是什么？

• by 仅保留列出的标签，而 without 仅丢弃列出的标签并保留其余标签。
• by 计算总和，不计算平均值
• by 返回立即向量，without 返回区间向量。
• 两种表达式完全相同，因此无论使用哪一种，结果都是相同的。

sum(rate(http_request_duration_seconds_sum[5m])) / sum(rate(http_request_duration_seconds_count[5m]))计算出什么值？

• 间隔内的平均响应时间
• 间隔的第 95 个百分位响应时间
• 间隔期间的最大响应时间
• 时间间隔内每秒的请求数

如果histogram_quantile(0.95, sum(rate(x_bucket[5m])) by (le))中省略了by (le)会怎样？

• 桶边界信息缺失，因此无法计算分位数，结果为空或不正确。
• 结果始终为0
• 所有分位数都具有相同的值。
• 查询运行正常，但性能缓慢。

直方图分位数值可能与实际不同的根本原因是什么？

• 因为普罗米修斯随机丢弃样本。
• 这是因为分位数计算会累积浮点误差。
• 这是因为桶是独占存储的，而不是累积存储的。
• 这是因为插值是在假设值均匀分布在桶内的情况下执行的。

为什么我无法使用 Summary 获取整个服务的分位数？

• 因为Summary不支持标签
• 这是因为 Summary 的值存储为字符串。
• 总结因为Prometheus无法抓取
• 这是因为 Summary 公开了实例内已计算的分位数值，因此无法跨实例对它们进行相加或求平均值。

在矢量匹配中，on(job)和ignoring(instance)之间的正确关系是什么？

• on 仅适用于左向量，ignoring 仅适用于右向量。
• on只能用于一对一匹配，ignoring只能用于多对一匹配。
• 两者的结果总是相同的，这是一个品味问题
• on 仅与列出的标签匹配，并忽略与除列出的标签之外的其余部分的匹配。

什么情况下最适合使用group_left？

• 我想根据右向量的顺序对左向量的时间序列进行排序。
• 从计算结果中删除左向量的所有标签
• 当左侧多个时间序列对应右侧一个时间序列时，拖动右侧标签，
• 我想用右向量的值替换左向量的值。

absent(up{job="payments"})什么时候有用？

• 当你想在时间序列的值为0时显示通知
• 如果你想求时间序列的增长率
• 当你想求多个时间序列的平均值时
• 当您想在时间序列根本不存在时显示通知

使用offset 1h最合适的目的是什么？

• 将查询执行推迟一小时
• 将片段长度增加到一小时
• 我试图获取一小时前的值并将其与现在进行比较。
• 将通知评估周期更改为一小时

topk(5, sum(rate(errors_total[5m])) by (service))的正确结果是什么？

• 前五个错误率的一个标量和
• 随机选择五个服务
• 错误率最低的五种服务
• 错误率最高的五个时间序列服务

avg_over_time(node_memory_usage_bytes[1h])和avg(node_memory_usage_bytes)有什么区别？

• 前面只能在Gauge中使用，后面只能在Counter中使用。
• 前面返回立即向量，后面返回区间向量。
• 前面是每个时间序列在时间轴上的平均，后面是时间序列之间某个时间点的平均。
• 两个表达式始终返回相同的值

当 PromQL 查询速度慢时，首先要检查什么？

• 普罗米修斯日志级别设置
• 通知规则中的值
• 警报管理器组设置
• 选择的时间序列数量和查询间隔长度

哪个指标名称符合 Prometheus 命名规范？

• httpRequestsTotal
• http_requests_total
• http.requests.count
• HTTP-Requests

使用出口商的最准确原因是什么？

• 尝试保存 Prometheus 无法保存的数据
• 尝试在多个 Prometheus 实例之间同步数据
• 试图通过将其转换为 Prometheus 格式来公开无法直接测量的第三方系统的状态。
• 向收件人发送通知

node_exporter提供的最合适的指标是什么？

• Kubernetes 对象的状态
• 应用程序中的 HTTP 请求延迟
• 容器的资源使用情况
• 主机CPU、内存、磁盘、网络等操作系统级别指标

blackbox_exporter的正确操作方法是什么？

• 安装在目标系统内部并直接读取内部状态
• 通知被评估并发送到 Alertmanager，而不是 Prometheus。
• 当 Prometheus 通过将目标地址作为参数传递来请求探测时，结果将作为指示器返回。
• 从多个导出器收集指标并将其缓存在一个位置

为什么 Pushgateway 不应该用于连续工作负载？

• 这是因为 Pushgateway 不支持 Counter 类型。
• 因为Pushgateway不支持标签
• 这是因为使用 Pushgateway 时无法指定抓取间隔。
• 因为该值持续保留，所以即使实例死亡，指标也看起来还活着，并且无法通过 up 来确定存活情况。

kube-state-metrics 和metrics-server 之间的正确区别是什么？

• kube-state-metrics 处理资源使用情况，metrics-server 处理对象状态。

编写记录规则的主要目的是什么？

• 监控标签值的数量并自动降低基数
• 提前计算常用的重表达式并将其保存为新的时间序列。

记录规则名称的推荐约定是什么？

• 使用与原始指标相同的名称，但仅标签不同。
• 使用规则文件名作为指标名称。
• 该名称包含level:metric:operations形式的聚合级别和操作。
• 使用不带前缀的随机短名称

在检测应用程序时用作标签值最危险的是什么？

• HTTP 状态码
• 请求路径的路由模板
• 用户标识符因请求而异
• 服务名称

通知规则中的for子句有什么作用？

• 防止在通知发生后的时间内重新发送。
• 该时间段过后，通知将自动关闭。
• 规则每个周期评估一次。
• 要发生触发，条件必须在整个期间保持正确。

通知规则中标签和注释的作用有什么区别？

• 标签包含人类可读的描述，注释包含路由信息。
• 两者都用于路由，唯一的区别是名称。
• 标签用于识别和路由通知，注释包含人类可读的描述。
• 标签由Alertmanager创建，注释由Prometheus创建。

Alertmanager的分组解决了什么问题？

• 自动确定通知的严重性
• 通过消除重复的收件人来降低成本
• 重新评估通知条件以过滤掉误报
• 通过将因同一原因同时爆炸的通知捆绑并发送到一个通知中来防止溢出。

什么情况下最适合使用Alertmanager抑制规则？

• 当重复出现相同的通知时，从第二次开始忽略它。
• 停止在夜间发送所有通知
• 当有整个集群挂掉的通知时，不要从子服务发送通知。
• 按严重性对通知进行排序

沉默和抑制之间的正确区别是什么？

• 沉默只能通过配置文件创建，抑制只能通过UI创建。
• 静默会阻止通知本身被评估，而抑制只会阻止发送通知。
• 两者的功能相同，只是名称不同。
• 沉默是一个人在设定的时间段内采取的临时操作，而抑制是由设置定义的通知之间的关系。

减少警觉疲劳的最合适方法是什么？

• 通过增加所有阈值来减少通知数量
• 通过增加通知收件人的数量来分担负担
• 仅发送需要人们立即采取行动的呼叫，并将其余呼叫路由至工单或仪表板。
• 一次性大幅提升通知规则的for值

推荐基于症状的警报的最合适理由是什么？

• 因为它们总是比基于原因的通知发生得更快。
• 由于可以使用的通知规则较少，因此设置较短。
• 这是因为症状指标的基数低于原因指标。
• 由于它直接检测用户遇到的问题，因此可以捕获由于意外原因而发生的故障。

为什么我们在基于消耗率的通知中同时使用长窗口和短窗口？

• 为了通过平均两个窗口来提高准确性，
• 长窗用于白天，短窗用于夜间。
• 长窗口可以减少误报，短窗口可以防止通知在已经发生恢复的情况下继续进行。
• 因为这是一个后备条件，以防短窗口失败。

Alertmanager中的group_wait是做什么的？

• 当新通知添加到已发送的组中时，等待下一次发送
• 等待再次发送相同内容的通知
• 如果收件人没有响应，请等待继续处理下一个收件人。
• 稍等片刻，查看是否有来自同一组的更多通知，然后再发送新组的第一个通知。

当通知路由树中的子路由未指定与其父路由不同的值时，会发生什么情况？

• 恢复默认
• 验证设置时发生错误。
• 继承父路由的设置
• 该路线被忽略

为什么在仪表板上一起绘制通知阈值很有帮助？

• 这是因为当您绘制阈值线时，通知会发生得更快。
• 这是因为仅当存在阈值线时 PromQL 才会返回准确的值。
• 这是因为绘制临界线会减少时间序列的存储容量。
• 因为您可以一目了然地看到当前值距离通知标准有多远，因此可以判断您的响应裕度。