4. 标签设计原则：基数控制、命名规范、避免动态标签

在 Loki 中，标签（Label）是日志数据的索引键值对。标签设计的好坏直接决定了查询性能、存储效率以及告警规则的可靠性。对于弹性伸缩健康检查场景，错误的标签设计会导致基数爆炸、查询超时、告警延迟甚至系统不可用。本节从三个核心原则出发，给出可落地的标签设计指南。

4.1 基数控制：高基数是告警系统的第一杀手

基数（Cardinality） 指一个标签值可能出现的不同取值的数量。Loki 的倒排索引会将每个标签键值对作为索引项，高基数标签会生成海量索引条目，导致内存膨胀、写入变慢、查询扫描范围剧增。

4.2 命名规范：可读性与可发现性

统一的标签命名规范能降低团队协作成本，避免因命名歧义导致的告警规则误匹配。推荐采用以下规范：

• 使用小写字母 + 下划线：例如 health_status、scaling_group，避免使用驼峰或大写。
• 前缀命名空间：使用 app_、env_、check_ 等前缀区分标签用途。例如 app_name、env_stage、check_type。
• 避免缩写歧义：svc 不如 service 清晰，hcheck 不如 health_check 直观。
• 保留标准标签：Loki 保留标签如 job、instance、__name__ 等，不要覆盖或滥用。

4.3 避免动态标签：将变量放入日志行

动态标签 指标签值随每次日志事件变化，例如 request_id、user_id、session_id、timestamp 等。这些标签会直接导致基数爆炸，必须严格禁止。

正确的做法是：

1. 将动态值放入日志行内容，通过 logfmt 或 json 格式结构化输出。
2. 使用 Loki 的 | pattern 或 | json 解析器 在查询时提取，而非在采集时建立索引。
3. 固定标签只保留用于过滤和聚合的维度，例如服务名、环境、健康检查类型、状态码。

# ❌ 错误：将动态值作为标签
{app="web", request_id="abc-123-def"}  # 高基数！

# ✅ 正确：动态值放在日志行内
{app="web", env="prod"} | json | request_id == "abc-123-def"

4.4 标签设计决策流程

下图展示了在弹性伸缩健康检查场景中，如何判断一个字段是否应该作为 Loki 标签：

4.5 弹性伸缩场景标签设计清单

针对弹性伸缩健康检查，推荐使用以下固定标签集：