在 Coralogix 中配置日志解析、富化、E2M…

当需要通过 cx CLI 配置 Coralogix 的解析规则、富化表、Events2Metrics 或 Prometheus 录制规则时，按模板化流程创建并验证。

适用场景

解决思路

1. 所有 create/update 操作统一使用 `--from-file <path>`（或 `-` 从 stdin 读取），所有命令支持 `-o json` 输出和 `-p <profile>` 选择配置。
2. `cx parsing-rules update` 和 `cx recording-rules update` 必须同时提供 `--from-file` 和规则组 ID。
3. `cx enrichments custom search` 需要 `--id <table-id>` 和 `--query <text>`；`cx parsing-rules bulk-delete` 需要 `--ids <id1> <id2> ...`。
4. 创建/更新前先用 `cx <command> get <id> -o json > template.json` 从已有资源导出模板，修改字段（create 时删除 ID），再执行 create/update，以避免 JSON 格式错误。
5. 解析规则流程：用 `cx parsing-rules list -o json` 列出规则（可配合 jq 提取 id/name/enabled/rule_count），用 `cx parsing-rules get <id> -o json` 导出模板，编辑后 `cx parsing-rules create --from-file`，再用 `cx logs 'source logs | filter $d.subsystem == "my-service" | limit 10' -o json` 验证字段提取，最后用 `cx parsing-rules usage-limits -o json` 检查用量上限。
6. 富化流程：用 `cx enrichments list -o json`、`cx enrichments settings -o json`、`cx enrichments limit -o json` 查看现状；如需自定义表，用 `cx enrichments custom list -o json` 和 `cx enrichments custom create --from-file table-definition.json` 创建。
7. 自定义富化表定义必须使用 v5 JSON 结构（内联文件内容，而非 multipart `file=@...`），包含 name、description 和 file 对象（textual、extension、name、size）；更新时需额外包含数字类型的 `customEnrichmentId`。
8. 添加富化规则时使用 `cx enrichments add --from-file enrichment-rules.json`，payload 必须使用 `requestEnrichments`（而非 list 输出中的 `enrichments`），且每个 `enrichmentType` 是对象而非字符串，例如 `{"fieldName": "sourceIPs", "enrichmentType": {"geoIp": {"withAsn": true}}}`；其他类型包括 `{"aws": {"resourceType": "ec2"}}`、`{"suspiciousIp": {}}`、`{"customEnrichment": {"id": 1}}`。
9. 用 `cx enrichments custom search --id <table-id> --query "search term"` 搜索自定义表数据。
10. 验证富化字段时查询热存储（FrequentSearch 层）日志，避免查询归档层导致因摄入延迟而误判，例如 `cx logs 'source logs | filter $d.enriched_field != null | limit 5' -o json`。
11. E2M 设计：选择 `logs2metrics` 或 `spans2metrics`、源字段与聚合方式、标签（注意基数）；如需限定到某个 dataset，设置可选字段 `dataSource` 为 `"<dataspace>/<dataset>"`，这需要账户特性 `e2m_dataset_source_enabled`，否则 API 会以 "dataSource is not enabled for this company" 拒绝；标准日志/span 流则省略该字段。
12. E2M 容量评估：用 `cx e2m limits -o json` 查看账户 E2M 数量上限与已用量，用 `cx e2m labels-cardinality -o json` 查看基数预测；注意该端点目前不接受参数，会返回空列表（CLI 缺口），需改用 UI 预测或手动估算排列数（各标签不同值之积）并设置 `permutationsLimit`；切勿使用高基数字段（ID、原始 URL、IP）作为标签；预测仅覆盖 Frequent-Search（High 层）数据。
13. E2M 模板化：只有 `cx e2m get` 返回完整 payload（`{"e2m": {...}}`），`list` 只打印摘要；用 `cx e2m get <id> -o json | jq '.e2m | del(.id, .permutations, .createTime, .updateTime, .metricName)' > e2m.json` 提取并删除只读字段，再 `cx e2m create --from-file e2m.json`。
14. E2M 验证：用 `cx metrics search --name "<targetBaseMetricName>"` 和 `cx metrics query "<target_metric_name>" --time now` 确认指标序列已产生。
15. E2M 无指标序列排查：先检查源数据的 TCO 层，若被路由到 Low/compliance 或被阻断则 E2M 无法运行，应通过 TCO 变更（`cx tco list` / `cx-cost-optimization`）修复而非改 E2M；再验证查询能匹配流式数据，将 E2M 的 `lucene` 过滤条件作为实时 `cx logs`/`cx spans` 查询运行确认有近期结果（注意 `cx logs` 默认查 Frequent-Search/High 层，Medium 层归档源需加 `--tier archive`）；最后记住 E2M 是仅向前生效，创建前摄入的数据不会产生序列。
16. 成本优化：当客户最关心聚合/指标视图时，先将 High 层日志转为指标，再把原始日志从 High 降为 Medium（Medium 仍支持 E2M/告警/看板且成本更低）；步骤为：用 `cx usage summary` / `cx tco list` 找出高流量 High 层源，确认驱动看板/告警的字段，先构建并验证 E2M，再修改 TCO 策略将原始日志 High→Medium；若仍需指标或告警，不要降到 Low/compliance。
17. 录制规则流程：用 `cx recording-rules list -o json` 列出（可配合 jq 提取 id/name/rules[].record），用 `cx recording-rules get <id> -o json > recording-rule-template.json` 导出模板，`cx recording-rules create --from-file recording-rule-group.json` 创建，最后用 `cx metrics query "new_precomputed_metric" --time now` 验证预计算指标可用。
18. 通用原则：始终从已有资源模板化；创建后查询日志/指标验证管道变更生效；所有 payload 检查与创建使用 `-o json`；创建前先检查上限（`cx parsing-rules usage-limits`、`cx e2m limits`）；清理时用 `cx parsing-rules bulk-delete --ids` 批量删除而非逐个删除。

适用边界 · 注意事项

• 未安装并配置 Coralogix `cx` CLI 及有效 profile 时无法使用。
• E2M 仅向前生效，无法为创建前已摄入的数据回填指标序列。
• E2M 无法作用于被路由到 Low/compliance 层或被阻断的数据，需先调整 TCO 策略。