cx-dashboards

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Create Coralogix Dashboard

创建Coralogix仪表盘

Produces a Coralogix dashboard for a target service and deploys it via the

cx

CLI. Workflow: discover the service's telemetry, align on intent with the user, draft a plan, emit the JSON, live-verify every query through

cx

, then create the dashboard in a chosen folder.

Only use metric names, log fields, and span attributes you can cite from the service's code, README, configuration, or a live query that returned a result. Do not invent them.

为目标服务生成Coralogix仪表盘，并通过

cx

CLI进行部署。工作流程：发现服务的遥测数据，与用户确认需求意图，草拟计划，生成JSON文件，通过

cx

实时验证所有查询，然后在选定文件夹中创建仪表盘。

仅使用可从服务代码、README、配置文件或返回结果的实时查询中引用的指标名称、日志字段和追踪链路属性。不得自行编造。

Reference files

参考文件

Load these files for domain-specific guidance:

Task	Reference
DataPrime query syntax	`references/dataprime-reference.md`
PromQL query syntax, counters vs gauges, histograms	`references/promql-guidelines.md`
Log field discovery, query patterns, wildfind policy	`references/logs-querying.md`
Span field discovery, latency analysis, trace queries	`references/spans-querying.md`
Dashboard-specific query gotchas ( `${__range}` , `promqlQueryType` )	`references/query-syntax.md`
Widget JSON templates	`references/widget-templates.md`

For choosing the right signal (metrics / logs / traces), use

cx-telemetry-querying

加载以下文件获取特定领域的指导：

任务	参考文档
DataPrime查询语法	`references/dataprime-reference.md`
PromQL查询语法、计数器与计量器、直方图	`references/promql-guidelines.md`
日志字段发现、查询模式、wildfind策略	`references/logs-querying.md`
追踪链路字段发现、延迟分析、追踪查询	`references/spans-querying.md`
仪表盘特定查询注意事项（ `${__range}` 、 `promqlQueryType` ）	`references/query-syntax.md`
组件JSON模板	`references/widget-templates.md`

如需选择合适的信号类型（指标/日志/追踪），请使用

cx-telemetry-querying

工具。

Dashboard Management

仪表盘管理

Beyond creating dashboards, use these commands to manage existing ones:

Command	Purpose
`cx dashboards catalog -o json`	List all dashboards in the catalog
`cx dashboards get <id> -o json`	Get a dashboard definition (useful as a template)
`cx dashboards folders list -o json`	List dashboard folders
`cx dashboards folders create --name "Name"`	Create a dashboard folder
`cx dashboards folders create --name "Sub" --parent-id <id>`	Create a nested folder
`cx dashboards replace --from-file dashboard.json`	Replace an existing dashboard with updated JSON

To update an existing dashboard:

bash

cx dashboards get <dashboard-id> -o json > dashboard.json

除创建仪表盘外，可使用以下命令管理现有仪表盘：

命令	用途
`cx dashboards catalog -o json`	列出目录中的所有仪表盘
`cx dashboards get <id> -o json`	获取仪表盘定义（可用作模板）
`cx dashboards folders list -o json`	列出仪表盘文件夹
`cx dashboards folders create --name "Name"`	创建仪表盘文件夹
`cx dashboards folders create --name "Sub" --parent-id <id>`	创建嵌套文件夹
`cx dashboards replace --from-file dashboard.json`	用更新后的JSON替换现有仪表盘

更新现有仪表盘的步骤：

bash

cx dashboards get <dashboard-id> -o json > dashboard.json

Edit dashboard.json (change name, modify widgets, etc.)

编辑dashboard.json（修改名称、调整组件等）

cx dashboards replace --from-file dashboard.json


To duplicate a dashboard as a new copy:

```bash
cx dashboards get <dashboard-id> -o json > dashboard.json

cx dashboards replace --from-file dashboard.json


复制仪表盘生成新副本的步骤：

```bash
cx dashboards get <dashboard-id> -o json > dashboard.json

Remove the "id" field, then create as new:

删除"id"字段，然后创建新仪表盘：

cx dashboards create --from-file dashboard.json

---

cx dashboards create --from-file dashboard.json

---

Workflow

工作流程

Track progress through this checklist:

Dashboard Progress:
- [ ] Phase 1: Discover telemetry & business meaning
- [ ] Phase 2: Gather dashboard specifications from user
- [ ] Phase 3: Draft internal dashboard plan (sections/rows/widgets)
- [ ] Phase 4: Generate the Coralogix JSON
- [ ] Phase 5: Live-verify every query through the cx CLI
- [ ] Phase 6: Self-verify structure against the checklist
- [ ] Phase 7: Deploy via `cx dashboards create`
- [ ] Phase 8: Share the dashboard link with the user

Proceed in order. Don't jump to Phase 4 before the user approves the Phase 3 plan, and don't run Phase 7 before Phases 5 and 6 both pass. Phase 8 is mandatory — the workflow is not done until the user has a clickable link.

按照以下检查清单跟踪进度：

仪表盘进度：
- [ ] 阶段1：发现遥测数据及业务意义
- [ ] 阶段2：收集用户的仪表盘规格需求
- [ ] 阶段3：草拟内部仪表盘计划（板块/行/组件）
- [ ] 阶段4：生成Coralogix JSON文件
- [ ] 阶段5：通过cx CLI实时验证所有查询
- [ ] 阶段6：对照检查清单自行验证结构
- [ ] 阶段7：通过`cx dashboards create`部署
- [ ] 阶段8：与用户分享仪表盘链接

按顺序执行。在用户批准阶段3的计划前，不要进入阶段4；在阶段5和阶段6均通过前，不要执行阶段7。阶段8为必填项——只有当用户获得可点击的链接后，工作流程才算完成。

Phase 1: Discover telemetry & business meaning

阶段1：发现遥测数据及业务意义

For the target service, gather:

Business purpose - read
```
README.md
```
and the top-level entrypoint (
```
main.*
```
,
```
index.*
```
,
```
cmd/main.go
```
, etc.). Summarize in 2–3 sentences what it does, its key stages, and what can go wrong.
Metrics - for each candidate keyword (service name, subsystem, verbs like
```
request
```
,
```
error
```
,
```
latency
```
,
```
dlq
```
) run
```
cx metrics search --name '*<keyword>*'
```
. When a metric looks promising, list its labels with
```
cx metrics get-labels <metric>
```
. Only use names
```
cx metrics search
```
returns - this is what prevents invented metrics from reaching Phase 5. Cross-check the service's instrumentation (
```
prometheus_client
```
,
```
promauto.NewCounter/Histogram/Gauge
```
, OTel meters,
```
prom-client
```
, Micrometer,
```
metrics.py
```
) for semantics and histogram buckets (
```
_sum
```
,
```
_count
```
,
```
_bucket
```
).

Logs - discover custom

$d.*

fields with

cx search-fields "<description>" --dataset logs

before assuming a field exists. Sample message templates and severity with

cx logs "filter \$l.applicationname == '<app>'" --limit 5 -o json

. Standard fields (

$m.severity

$m.timestamp

$l.applicationname

$l.subsystemname

) don't need discovery.

Spans / traces - discover span attributes with

cx search-fields "<description>" --dataset spans

. Sample with

cx spans "filter \$l.serviceName == '<svc>'" --limit 5 -o json

. Error conventions vary (

$d.tags.error

$d.http.status_code

); check samples before filtering.

Message buses & DLQs - grep for Kafka, RabbitMQ, SQS, Pub/Sub clients and any
```
dlq
```
/
```
DLQ
```
references. Note topic/queue names for DLQ panels.
Service configuration - check
```
meta.yaml
```
, Helm
```
values.yaml
```
,
```
Deployment
```
,
```
Dockerfile
```
,
```
chart.yaml
```
. Extract:
- The
```
applicationname
```
  /
```
subsystemname
```
  label values as they appear in Coralogix.
- Tenant/account/team identifiers used as metric or log labels.
- Deployment environments (
```
prod
```
  ,
```
staging
```
  ,
```
dev
```
  , …).

If the signal for a question is ambiguous (e.g. "how much revenue last week"), delegate to

cx-telemetry-querying

first.

Produce a short internal summary before moving on. If critical telemetry is missing (e.g. no metrics), surface that to the user and ask whether they want a log-only or trace-only dashboard.

针对目标服务，收集以下信息：

业务用途 - 阅读
```
README.md
```
和顶层入口文件（
```
main.*
```
、
```
index.*
```
、
```
cmd/main.go
```
等）。用2-3句话总结其功能、关键阶段及可能出现的问题。
指标 - 针对每个候选关键词（服务名称、子系统、
```
request
```
、
```
error
```
、
```
latency
```
、
```
dlq
```
等动词/名词）运行
```
cx metrics search --name '*<keyword>*'
```
。当某个指标看起来有价值时，使用
```
cx metrics get-labels <metric>
```
列出其标签。仅使用
```
cx metrics search
```
返回的名称——这可防止自行编造的指标进入阶段5。交叉检查服务的埋点代码（
```
prometheus_client
```
、
```
promauto.NewCounter/Histogram/Gauge
```
、OTel meters、
```
prom-client
```
、Micrometer、
```
metrics.py
```
）以确认语义和直方图桶（
```
_sum
```
、
```
_count
```
、
```
_bucket
```
）。

日志 - 在假设字段存在前，使用

cx search-fields "<description>" --dataset logs

发现自定义

$d.*

字段。使用

cx logs "filter \$l.applicationname == '<app>'" --limit 5 -o json

获取消息模板示例和日志级别。标准字段（

$m.severity

、

$m.timestamp

、

$l.applicationname

、

$l.subsystemname

）无需发现。

追踪链路（spans/traces） - 使用
```
cx search-fields "<description>" --dataset spans
```
发现追踪链路属性。使用
```
cx spans "filter \$l.serviceName == '<svc>'" --limit 5 -o json
```
获取示例。错误约定各不相同（
```
$d.tags.error
```
、
```
$d.http.status_code
```
）；过滤前请先检查示例。
消息总线与死信队列（DLQs） - 搜索Kafka、RabbitMQ、SQS、Pub/Sub客户端及任何
```
dlq
```
/
```
DLQ
```
引用。记录死信队列面板所需的主题/队列名称。
服务配置 - 检查
```
meta.yaml
```
、Helm
```
values.yaml
```
、
```
Deployment
```
、
```
Dockerfile
```
、
```
chart.yaml
```
。提取：
- 在Coralogix中显示的
```
applicationname
```
  /
```
subsystemname
```
  标签值。
- 用作指标或日志标签的租户/账户/团队标识符。
- 部署环境（
```
prod
```
  、
```
staging
```
  、
```
dev
```
  等）。

如果某个问题的信号不明确（例如“上周收入多少”），请先委托

cx-telemetry-querying

工具处理。

进入下一阶段前，生成一份简短的内部总结。如果缺少关键遥测数据（例如无指标），请告知用户并询问是否需要仅基于日志或仅基于追踪的仪表盘。

Phase 2: Gather dashboard specifications

阶段2：收集仪表盘规格需求

Ask the user a focused set (≤6). Prefer

AskQuestion

Audience & use - on-call triage, product/business tracking, capacity planning, customer success?
Default time range - typical viewing window (e.g. 24h, 7d). Queries still use
```
${__range}
```
so users can zoom.
Slicing dimensions - top-level filters (
```
tenant_id
```
,
```
account_id
```
,
```
subsystem_name
```
,
```
region
```
,
```
env
```
, …).
Environment scope - which environments to include/exclude (common default: exclude
```
dev
```
,
```
staging
```
,
```
test
```
).
SLO-ish signals - success-rate, latency, or throughput targets to highlight?
Priorities - what to see first (drives row ordering and which section is
```
collapsed: true
```
).

Don't block on answers you can reasonably infer - state the inference and continue.

向用户提出一组聚焦的问题（≤6个）。优先使用

AskQuestion

：

受众与用途 - 值班故障排查、产品/业务跟踪、容量规划、客户成功？
默认时间范围 - 典型查看窗口（例如24h、7d）。查询仍会使用
```
${__range}
```
，以便用户可以缩放查看。
切片维度 - 顶层过滤器（
```
tenant_id
```
、
```
account_id
```
、
```
subsystem_name
```
、
```
region
```
、
```
env
```
等）。
环境范围 - 要包含/排除哪些环境（常见默认值：排除
```
dev
```
、
```
staging
```
、
```
test
```
）。
类SLO信号 - 是否需要突出显示成功率、延迟或吞吐量目标？
优先级 - 首先查看什么内容（决定行的顺序以及哪个板块设置为
```
collapsed: true
```
）。

对于可合理推断的答案，无需等待回复——说明推断结果并继续。

Phase 3: Draft the internal plan

阶段3：草拟内部计划

Write a markdown plan the user can approve before JSON generation:

undefined

编写一份Markdown计划，供用户在生成JSON前批准：

undefined

Dashboard: <Service> - <Purpose>

仪表盘：<服务名称> - <用途>

Section 1: <Overview> (collapsed: false)

板块1：<概览>（collapsed: false）

Row 1: [widget type] <title> - <what it shows> - source: metrics|logs|spans
Row 2: ...

行1：[组件类型] <标题> - <展示内容> - 数据源：metrics|logs|spans
行2：...

Section 2: <Deep dive> (collapsed: false)

板块2：<深入分析>（collapsed: false）

...

Section N: <Logs & errors> (collapsed: true)

板块N：<日志与错误>（collapsed: true）

...

Top-level filters

顶层过滤器

<label> (<source>)

<标签>（<数据源>）

Assumptions / gaps

假设/缺口


**Section design**:
- First section: at-a-glance health (gauges + key rates), always expanded.
- Pair related time-series in the same row (rate + latency).
- Final section (raw logs, rare breakdowns): `collapsed: true`.
- Aim for 3–5 sections, 6–20 widgets total.

**Widget-type selection**:

| Signal | Widget type |
|---|---|
| Single headline number (count, % success, totals) | `gauge` (Coralogix calls this "stat") |
| Breakdown across ≤8 categories | `pieChart` |
| Change over time (rate, latency, count per bucket) | `lineChart` |
| Top-N tables, last errors, per-entity listings | `dataTable` |

Don't use other widget types unless the user asks.

Wait for the user to approve or adjust the plan before emitting JSON.

---


**板块设计**：
- 第一个板块：一目了然的健康状态（计量器+关键比率），始终展开。
- 将相关时间序列放在同一行（比率+延迟）。
- 最后一个板块（原始日志、罕见细分）：设置为`collapsed: true`。
- 目标为3-5个板块，总计6-20个组件。

**组件类型选择**：

| 信号类型 | 组件类型 |
|---|---|
| 单个标题数字（计数、成功率百分比、总计） | `gauge`（Coralogix称之为“stat”） |
| 最多8个类别的细分 | `pieChart` |
| 随时间变化的趋势（比率、延迟、按桶计数） | `lineChart` |
| Top-N表格、最新错误、按实体列表 | `dataTable` |

除非用户要求，否则不要使用其他组件类型。

在生成JSON前，等待用户批准或调整计划。

---

Phase 4: Generate the Coralogix JSON

阶段4：生成Coralogix JSON文件

Produce a single JSON document following

references/widget-templates.md

. Key rules:

Top-level shape:

{
  "id": "<21-char-nanoid>",
  "name": "<Dashboard Name>",
  "layout": { "sections": [ ... ] },
  "variables": [],
  "variablesV2": [],
  "filters": [ ... ],
  "relativeTimeFrame": "<seconds>s",
  "annotations": [],
  "off": {},
  "actions": []
}

IDs - fresh UUIDs for every
```
section
```
,
```
row
```
,
```
widget
```
, and query
```
id
```
.
Row height -
```
"appearance": { "height": 19 }
```
unless there's a reason to change.

Section options - include

options.custom.name

collapsed

, and

color.predefined: "SECTION_PREDEFINED_COLOR_UNSPECIFIED"

Filters - one entry per slicing dimension from Phase 2. Default operator
```
equals
```
with empty
```
values
```
so users can fill in. Use
```
notEquals
```
for environment exclusions (see
```
references/widget-templates.md
```
).
relativeTimeFrame - default
```
"172800s"
```
(48h) unless the user specified otherwise.

For query syntax follow

references/query-syntax.md

; for the full query languages load

references/dataprime-reference.md

and

references/promql-guidelines.md

遵循

references/widget-templates.md

生成单个JSON文档。关键规则：

顶层结构：

{
  "id": "<21位nanoid>",
  "name": "<仪表盘名称>",
  "layout": { "sections": [ ... ] },
  "variables": [],
  "variablesV2": [],
  "filters": [ ... ],
  "relativeTimeFrame": "<秒数>s",
  "annotations": [],
  "off": {},
  "actions": []
}

ID - 为每个
```
section
```
、
```
row
```
、
```
widget
```
和查询
```
id
```
生成新的UUID。
行高 -
```
"appearance": { "height": 19 }
```
，除非有理由更改。

板块选项 - 包含

options.custom.name

、

collapsed

和

color.predefined: "SECTION_PREDEFINED_COLOR_UNSPECIFIED"

。

过滤器 - 对应阶段2中的每个切片维度，添加一个条目。默认操作符为
```
equals
```
，
```
values
```
为空，以便用户填写。对于环境排除，使用
```
notEquals
```
（参见
```
references/widget-templates.md
```
）。
relativeTimeFrame - 默认值为
```
"172800s"
```
（48小时），除非用户指定其他值。

查询语法遵循

references/query-syntax.md

；如需完整查询语言，请加载

references/dataprime-reference.md

和

references/promql-guidelines.md

。

Phase 5: Live-verify every query through the cx CLI

阶段5：通过cx CLI实时验证所有查询

Every PromQL and DataPrime query in the draft has to successfully run through

cx

before Phase 7. This catches invented metric names, typoed field paths, and malformed pipelines.

在进入阶段7前，草稿中的所有PromQL和DataPrime查询必须通过

cx

成功运行。这可捕获自行编造的指标名称、字段路径拼写错误和格式错误的流水线。

Frequent vs Archive (what / when / where in JSON)

频繁查询层与归档层（JSON中的内容/时机/位置）

What:

Frequent (
```
TIER_FREQUENT_SEARCH
```
): hot tier for fast search on recent logs/spans.
Archive (
```
TIER_ARCHIVE
```
): cold tier for older logs/spans (long-term).

When to choose:

Choose Frequent for on-call and recent investigations (hours/days).
Choose Archive for long lookbacks (weeks/months) or when the time range is beyond hot retention.

The two languages are verified against different windows:

PromQL: map
```
relativeTimeFrame
```
to a
```
$RANGE
```
token (e.g.
```
48h
```
for
```
172800s
```
), substitute
```
${__range}
```
with
```
[$RANGE]
```
for the CLI call, then restore
```
${__range}
```
in the JSON before Phase 6. Range vectors are window-sensitive, so the check has to match what the dashboard will evaluate.
DataPrime: verify against a fixed short window (
```
now-15m
```
→
```
now
```
,
```
--limit 1
```
). The goal is syntax / field / pipeline validation, not data-presence on the dashboard's window — a short window is faster and a cleaner fail signal.

Full procedure (CLI invocations,

$RANGE

mapping table, retry budget, failure modes):

references/verification.md

If a query can't be made to pass within the retry budget, surface it to the user with the CLI error verbatim - don't ship a broken widget.

内容：

频繁查询层（Frequent）（
```
TIER_FREQUENT_SEARCH
```
）：热层，用于快速搜索近期日志/追踪链路。
归档层（Archive）（
```
TIER_ARCHIVE
```
）：冷层，用于存储较旧的日志/追踪链路（长期保留）。

选择时机：

对于值班故障排查和近期调查（数小时/数天），选择频繁查询层。
对于长期回溯（数周/数月）或时间范围超出热层保留期的情况，选择归档层。

两种语言针对不同窗口进行验证：

PromQL：将
```
relativeTimeFrame
```
映射为
```
$RANGE
```
令牌（例如
```
172800s
```
对应
```
48h
```
），在CLI调用中将
```
${__range}
```
替换为
```
[$RANGE]
```
，然后在阶段6前将JSON中的
```
${__range}
```
恢复。范围向量对窗口敏感，因此检查必须与仪表盘将评估的内容匹配。
DataPrime：针对固定的短窗口（
```
now-15m
```
→
```
now
```
，
```
--limit 1
```
）进行验证。目标是验证语法/字段/流水线，而非检查仪表盘窗口上的数据存在性——短窗口速度更快，失败信号更清晰。

完整流程（CLI调用、

$RANGE

映射表、重试次数、失败模式）：

references/verification.md

。

如果查询在重试次数内无法通过，请将CLI错误原封不动地告知用户——不要部署有问题的组件。

Phase 6: Self-verify structure

阶段6：自行验证结构

Run this checklist against the final JSON. Fix and re-check if any item fails before Phase 7.

对照最终JSON运行以下检查清单。在进入阶段7前，修复所有未通过的项并重新检查。

Query syntax (dashboard-specific)

查询语法（仪表盘特定）

Every PromQL range vector in a metrics widget uses
```
[${__range}]
```
- never
```
[$__range]
```
, never
```
[5m]
```
(unless the panel is intentionally a sliding window).
```
promqlQueryType
```
is
```
PROM_QL_QUERY_TYPE_INSTANT
```
for single-value widgets (gauge, pieChart, dataTable). Omitted for
```
lineChart
```
.
DataPrime log queries use
```
$d.message
```
/
```
$l.applicationname
```
/ unquoted severity enums (full rules:
```
references/dataprime-reference.md
```
).
Every DataPrime widget query starts with
```
source logs
```
or
```
source spans
```
(dashboard widgets require the source prefix; Phase 5 verification strips it before handing the pipeline to
```
cx logs
```
/
```
cx spans
```
).
Success-rate denominators wrapped in
```
clamp_min(..., 1)
```
.
Histogram queries use the correct suffix (
```
_sum
```
,
```
_count
```
,
```
_bucket
```
).
Widget queries are valid without the dashboard-level
```
filters
```
- Coralogix injects them at render time.

指标组件中的每个PromQL范围向量都使用
```
[${__range}]
```
- 绝不要使用
```
[$__range]
```
或
```
[5m]
```
（除非面板特意设置为滑动窗口）。
单值组件（gauge、pieChart、dataTable）的
```
promqlQueryType
```
设置为
```
PROM_QL_QUERY_TYPE_INSTANT
```
。
```
lineChart
```
组件省略该字段。
DataPrime日志查询使用
```
$d.message
```
/
```
$l.applicationname
```
/未加引号的日志级别枚举（完整规则：
```
references/dataprime-reference.md
```
）。
每个DataPrime组件查询都以
```
source logs
```
或
```
source spans
```
开头（仪表盘组件需要源前缀；阶段5验证时会在将流水线交给
```
cx logs
```
/
```
cx spans
```
前移除该前缀）。
成功率分母包裹在
```
clamp_min(..., 1)
```
中。
直方图查询使用正确的后缀（
```
_sum
```
、
```
_count
```
、
```
_bucket
```
）。
组件查询在没有仪表盘级
```
filters
```
的情况下依然有效——Coralogix会在渲染时注入这些过滤器。

Structure

结构

Each section has
```
id.value
```
,
```
rows
```
, and
```
options.custom
```
.
Each row has
```
id.value
```
,
```
appearance.height
```
, and
```
widgets
```
.
Each widget has a unique
```
id.value
```
and a
```
definition
```
with exactly one of
```
gauge
```
/
```
pieChart
```
/
```
lineChart
```
/
```
dataTable
```
.
Success-rate gauges use
```
thresholdType: "THRESHOLD_TYPE_ABSOLUTE"
```
with green at high values; error/DLQ gauges use red at high values.
"Total" / "stat" widgets are encoded as
```
gauge
```
, not as a stat type.
Top-level
```
filters
```
includes each slicing dimension from Phase 2.
All IDs are freshly generated UUIDs, unique within the document.

每个板块都包含
```
id.value
```
、
```
rows
```
和
```
options.custom
```
。
每行都包含
```
id.value
```
、
```
appearance.height
```
和
```
widgets
```
。
每个组件都有唯一的
```
id.value
```
，且
```
definition
```
中恰好包含
```
gauge
```
/
```
pieChart
```
/
```
lineChart
```
/
```
dataTable
```
中的一种。
成功率计量器使用
```
thresholdType: "THRESHOLD_TYPE_ABSOLUTE"
```
，高值显示绿色；错误/死信队列计量器高值显示红色。
“总计”/“统计”组件编码为
```
gauge
```
，而非stat类型。
顶层
```
filters
```
包含阶段2中的每个切片维度。
所有ID都是新生成的UUID，在文档内唯一。

Content

内容

Dashboard name is descriptive (
```
"<Service> - <Purpose>"
```
).
Widget titles are short, human-readable, and match what the query computes.
The logs/errors section is
```
collapsed: true
```
unless the user said otherwise.

仪表盘名称具有描述性（
```
"<服务名称> - <用途>"
```
）。
组件标题简短、易于理解，与查询计算的内容匹配。
日志/错误板块设置为
```
collapsed: true
```
，除非用户另有说明。

Phase 7: Deploy via

cx dashboards create

阶段7：通过

cx dashboards create

部署

Don't tell the user to paste JSON into the Coralogix UI - deploy it directly.

List folders:
```
cx dashboards folders list -o json
```
.
Suggest the best folder match (team, product area, or a folder named after the service). Default to root (omit
```
--folder
```
) if nothing fits.
Write the verified JSON to a temp file and run
```
cx dashboards create --from-file /tmp/cx-dashboard-<slug>.json --folder <id>
```
. The CLI generates the
```
requestId
```
envelope and prints the created dashboard ID.

Full procedure (folder-picking UX, command templates, idempotency note):

references/deploy.md

On failure: show the CLI error verbatim and return to Phase 5. The most common cause is a query that parses locally but the live API rejects.

不要让用户将JSON粘贴到Coralogix UI中——直接部署。

列出文件夹：
```
cx dashboards folders list -o json
```
。
建议最合适的文件夹（团队、产品领域或以服务命名的文件夹）。如果没有合适的，默认使用根目录（省略
```
--folder
```
）。
将验证后的JSON写入临时文件，运行
```
cx dashboards create --from-file /tmp/cx-dashboard-<slug>.json --folder <id>
```
。CLI会生成
```
requestId
```
信封并打印创建的仪表盘ID。

完整流程（文件夹选择体验、命令模板、幂等性说明）：

references/deploy.md

。

部署失败时：显示CLI错误原文并返回阶段5。最常见的原因是本地解析通过但实时API拒绝的查询。

Phase 8: Share the dashboard link

阶段8：分享仪表盘链接

The workflow is not done until the user has a clickable link to the dashboard. Printing the ID alone forces the user to navigate the Coralogix UI by hand, which defeats the point of automating deployment.

After Phase 7 succeeds, capture the dashboard

id

returned by

cx dashboards create

, build the URL using the region → webapp host mapping in

references/deploy.md

§ "Share the link", and emit the output template below. Render the dashboard name as the link text — that's what the user clicks.

只有当用户获得可点击的仪表盘链接后，工作流程才算完成。仅打印ID会迫使用户手动导航Coralogix UI，这违背了自动化部署的初衷。

阶段7成功后，捕获

cx dashboards create

返回的仪表盘

id

，使用

references/deploy.md

中“分享链接”部分的区域→Web应用主机映射构建URL，并输出以下模板。将仪表盘名称渲染为链接文本——这是用户点击的内容。

Output format for the user

面向用户的输出格式

When the webapp host is resolvable (any built-in region, or a

Custom

endpoint that follows the

api.<host>

convention):

undefined

当Web应用主机可解析时（任何内置区域，或遵循

api.<host>

约定的

Custom

端点）：

undefined

Plan

计划

<已批准的阶段3计划>

Verification

验证结果

PromQL queries verified: <N>/<N>
DataPrime queries verified: <N>/<N>

PromQL查询验证通过：<已验证数>/<总数>
DataPrime查询验证通过：<已验证数>/<总数>

Deployed

已部署

Dashboard: <Name>
ID:
```
<id>
```
Folder:
```
<folder name or "root">
```
Profile:
```
<cx profile>
```

Open it: <Name>

Adjust filter values (e.g.

account_id

) after opening it.


When the webapp host **cannot** be derived (custom endpoint that doesn't match `api.<host>`), omit the link entirely — do not invent a URL. Use this template instead:

仪表盘：<名称>
ID：
```
<id>
```
文件夹：
```
<文件夹名称或"根目录">
```
配置文件：
```
<cx profile>
```

打开链接：<名称>

打开后可调整过滤器值（例如

account_id

）。


当Web应用主机**无法**推导时（不匹配`api.<host>`的自定义端点），完全省略链接——不要编造URL。改用以下模板：

Plan

计划

<已批准的阶段3计划>

Verification

验证结果

PromQL queries verified: <N>/<N>
DataPrime queries verified: <N>/<N>

PromQL查询验证通过：<已验证数>/<总数>
DataPrime查询验证通过：<已验证数>/<总数>

Deployed

已部署

Dashboard: <Name> (open via the Coralogix UI; ID
```
<id>
```
)
ID:
```
<id>
```
Folder:
```
<folder name or "root">
```
Profile:
```
<cx profile>
```

Adjust filter values (e.g.

account_id

) after opening it.

---

仪表盘：<名称>（通过Coralogix UI打开；ID
```
<id>
```
）
ID：
```
<id>
```
文件夹：
```
<文件夹名称或"根目录">
```
配置文件：
```
<cx profile>
```

打开后可调整过滤器值（例如

account_id

）。

---

References

参考资料

Dashboard query gotchas & cross-references:
```
references/query-syntax.md
```
Widget JSON templates:
```
references/widget-templates.md
```
Live-verification procedure:
```
references/verification.md
```
Deploy procedure:
```
references/deploy.md
```
DataPrime language reference:
```
references/dataprime-reference.md
```
PromQL reference:
```
references/promql-guidelines.md
```
Log querying patterns:
```
references/logs-querying.md
```
Span querying patterns:
```
references/spans-querying.md
```

Inline DataPrime help:

cx dataprime list

cx dataprime show <command>

Coralogix Custom Dashboards docs: https://www.coralogix.com/docs/user-guides/custom-dashboards/introduction/

仪表盘查询注意事项与交叉引用：
```
references/query-syntax.md
```
组件JSON模板：
```
references/widget-templates.md
```
实时验证流程：
```
references/verification.md
```
部署流程：
```
references/deploy.md
```
DataPrime语言参考：
```
references/dataprime-reference.md
```
PromQL参考：
```
references/promql-guidelines.md
```
日志查询模式：
```
references/logs-querying.md
```
追踪链路查询模式：
```
references/spans-querying.md
```

内嵌DataPrime帮助：

cx dataprime list

、

cx dataprime show <command>

Coralogix自定义仪表盘文档：https://www.coralogix.com/docs/user-guides/custom-dashboards/introduction/

cx-dashboards

Original

Translation

Create Coralogix Dashboard

创建Coralogix仪表盘

Reference files

参考文件

Dashboard Management

仪表盘管理

Edit dashboard.json (change name, modify widgets, etc.)

编辑dashboard.json（修改名称、调整组件等）

Remove the "id" field, then create as new:

删除"id"字段，然后创建新仪表盘：

Workflow

工作流程

Phase 1: Discover telemetry & business meaning

阶段1：发现遥测数据及业务意义

Phase 2: Gather dashboard specifications

阶段2：收集仪表盘规格需求

Phase 3: Draft the internal plan

阶段3：草拟内部计划

Dashboard: <Service> - <Purpose>

仪表盘：<服务名称> - <用途>

Section 1: <Overview> (collapsed: false)

板块1：<概览>（collapsed: false）

Section 2: <Deep dive> (collapsed: false)

板块2：<深入分析>（collapsed: false）

Section N: <Logs & errors> (collapsed: true)

板块N：<日志与错误>（collapsed: true）

Top-level filters

顶层过滤器

Assumptions / gaps

假设/缺口

Phase 4: Generate the Coralogix JSON

阶段4：生成Coralogix JSON文件

Phase 5: Live-verify every query through the cx CLI

阶段5：通过cx CLI实时验证所有查询

Frequent vs Archive (what / when / where in JSON)

频繁查询层与归档层（JSON中的内容/时机/位置）

Phase 6: Self-verify structure

阶段6：自行验证结构

Query syntax (dashboard-specific)

查询语法（仪表盘特定）

Structure

结构

Content

内容

Phase 7: Deploy via cx dashboards create

阶段7：通过cx dashboards create部署

Phase 8: Share the dashboard link

阶段8：分享仪表盘链接

Output format for the user

面向用户的输出格式

Plan

计划

Verification

验证结果

Deployed

已部署

Plan

计划

Verification

验证结果

Deployed

已部署

References

参考资料

Related Skills

相关技能

Phase 7: Deploy via
`cx dashboards create`

阶段7：通过
`cx dashboards create`
部署