测验：基数爆炸

当标签为method(5)×status(8)×endpoint(40)时，时间序列的数量是多少？

• 添加了 53 个标签值类型
• 所有标签值的 1,600 种组合
• 320次只是方法和状态
• 3个标签名称数以万计

以下哪项作为公制标签最危险？

• 每个请求的trace_id都会改变
• 具有有限值类型的 HTTP 方法
• 具有有限值类型的 status_code
• 表示部署环境的环境

如果我创建endpoint="/api/orders/8f3a91"形式的标签会怎样？

• 查询更准确
• 时间序列随着订单数量的增加而扩展并爆炸。
• 节省存储空间
• 通知变得更加准确

我们需要知道“为什么这个用户的请求很慢”。我应该使用什么信号？

• 将 user_id 标签添加到指标
• 延长指标保留期
• 日志和跟踪 - 高基数正是您所需要的
• 添加仪表板

当基数爆炸已经发生时，可以立即采取哪些操作而不部署应用程序？

• 延长时间序列的保留期限
• 清晰厚重的仪表板
• 关闭响铃通知规则
• 在收集阶段将问题标签或指标作为重新标签删除。

标记错误的正确格式是什么？

• 排序值如error="db_timeout"
• error="connection to 10.0.3.17:5432 timed out"
• error=的堆栈跟踪
• error=包含时间戳