signoz-creating-dashboards

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Dashboard Create

创建仪表盘

Prerequisites

前置条件

This skill calls SigNoz MCP server tools (

signoz:signoz_create_dashboard

signoz:signoz_list_dashboards

signoz:signoz_list_dashboard_templates

signoz:signoz_import_dashboard

signoz:signoz_list_metrics

signoz:signoz_get_field_values

signoz:signoz_aggregate_logs

signoz:signoz_aggregate_traces

, etc.). Before running the workflow, confirm the

signoz:signoz_*

tools are available. If they are not, the SigNoz MCP server is not installed or configured — stop and direct the user to set it up: https://signoz.io/docs/ai/signoz-mcp-server/. Do not fall back to raw HTTP calls or fabricate dashboard JSON without the MCP tools.

本技能会调用SigNoz MCP服务器工具（

signoz:signoz_create_dashboard

、

signoz:signoz_list_dashboards

、

signoz:signoz_list_dashboard_templates

、

signoz:signoz_import_dashboard

、

signoz:signoz_list_metrics

、

signoz:signoz_get_field_values

、

signoz:signoz_aggregate_logs

、

signoz:signoz_aggregate_traces

等）。在运行工作流之前，请确认

signoz:signoz_*

工具可用。如果不可用，说明SigNoz MCP服务器未安装或配置——请停止操作并引导用户按照以下链接进行设置：https://signoz.io/docs/ai/signoz-mcp-server/。不要退回到原始HTTP调用，也不要在没有MCP工具的情况下编造仪表盘JSON。

When to use

使用场景

Use this skill when the user asks to:

Create, set up, or build a new dashboard
Monitor a specific technology (database, service, infrastructure, AI/LLM platform)
"Set up observability" for a service or component
Import a dashboard template

Do NOT use when:

User wants to modify an existing dashboard →
```
signoz-modifying-dashboards
```
User wants to understand what a dashboard shows →
```
signoz-explaining-dashboards
```
User wants to query data without creating a dashboard →
```
signoz-generating-queries
```

当用户提出以下需求时使用本技能：

创建、设置或构建新仪表盘
监控特定技术（数据库、服务、基础设施、AI/LLM平台）
为服务或组件“设置可观测性”
导入仪表盘模板

请勿在以下场景使用：

用户想要修改现有仪表盘 → 使用
```
signoz-modifying-dashboards
```
用户想要了解仪表盘展示内容 → 使用
```
signoz-explaining-dashboards
```
用户想要查询数据但不创建仪表盘 → 使用
```
signoz-generating-queries
```

Instructions

操作流程

The flow runs in order: duplicate check → user picks modify-or-create → on create, template lookup decides template-import vs custom-build. Duplicate check comes first so we never silently create a second copy of something that already exists. Once the user has chosen to create a new dashboard, the template lookup is an internal implementation detail — if a curated template exists we use it, otherwise we build from scratch. The user is offered exactly two choices: modify an existing dashboard, or create a new one.

流程按以下顺序执行：重复项检查 → 用户选择修改或创建 → 创建时，模板查找决定是导入模板还是自定义构建。重复项检查优先进行，避免静默创建已有内容的副本。一旦用户选择创建新仪表盘，模板查找是内部实现细节——如果存在经过筛选的模板则使用该模板，否则从头构建。用户仅有两个选择：修改现有仪表盘，或创建新仪表盘。

Step 1: Check for duplicates

步骤1：检查重复项

Call

signoz:signoz_list_dashboards

to see what dashboards already exist. Paginate through all pages — check

pagination.hasMore

in the response. If

hasMore

is true, call again with

offset

set to

pagination.nextOffset

and repeat until all pages are exhausted. Only after checking every page can you conclude no similar dashboard exists.

Match aggressively. For each existing dashboard, compare its lowercased

name

and

tags

against the user's request. A match is any of:

lowercased name contains the technology/domain keyword (e.g. "redis", "postgres", "k8s"/"kubernetes", "docker"/"container", "host");
any tag matches the keyword;
existing name and the user's request share the root token (e.g. "Redis - Overview" vs a request for a Redis dashboard).

调用

signoz:signoz_list_dashboards

查看已存在的仪表盘。遍历所有分页——检查响应中的

pagination.hasMore

。如果

hasMore

为true，则再次调用该工具并将

offset

设置为

pagination.nextOffset

，重复此操作直到所有分页都检查完毕。只有检查完所有分页后，才能确定不存在类似的仪表盘。

严格匹配。对于每个现有仪表盘，将其小写的

name

和

tags

与用户请求进行比对。满足以下任一条件即视为匹配：

小写名称包含技术/领域关键词（例如“redis”、“postgres”、“k8s”/“kubernetes”、“docker”/“container”、“host”）；
任一标签与关键词匹配；
现有名称与用户请求共享根词（例如“Redis - Overview”与用户请求的Redis仪表盘）。

Step 2: Ask the user — modify or create

步骤2：询问用户——修改还是创建

Present exactly two options:

Duplicates found: "There are already these similar dashboards: [list with name, UUID, created-at]. Want me to (a) modify one of these, (b) create a new dashboard anyway, or (c) stop?"
No duplicates: "I'll create a new dashboard for this. Proceed?" (No "modify" option when there's nothing to modify.)

Wait for the user's choice. If they pick "modify", go to Step 3a. If they pick "create new" (or confirm creation), go to Step 3b. If they pick "stop", stop.

仅提供以下两个选项：

找到重复项：“已存在以下类似仪表盘：[列出名称、UUID、创建时间]。请问您想要(a)修改其中一个，(b)仍创建新仪表盘，还是(c)停止操作？”
无重复项：“我将为您创建一个新仪表盘。是否继续？”（无重复项时不提供“修改”选项）

等待用户选择。如果用户选择“修改”，进入步骤3a；如果选择“创建新仪表盘”（或确认创建），进入步骤3b；如果选择“停止”，则终止操作。

Step 3: Create or modify

步骤3：创建或修改

Step 3a: Modify an existing dashboard

步骤3a：修改现有仪表盘

Call

signoz:signoz_get_dashboard

with the chosen UUID to fetch the full configuration, plan the requested changes, then call

signoz:signoz_update_dashboard

with the complete updated JSON. Stop here.

调用

signoz:signoz_get_dashboard

并传入所选UUID以获取完整配置，规划所需修改，然后调用

signoz:signoz_update_dashboard

并传入完整的更新后JSON。操作到此结束。

Step 3b: Create a new dashboard

步骤3b：创建新仪表盘

Run the template lookup first. The user has already agreed to create a new dashboard — the lookup just decides how we build it, no extra confirmation prompt.

Call

signoz:signoz_list_dashboard_templates

with

searchContext

set to the user's raw request. The tool returns the full catalog as a JSON array of

{id, title, path, description, category, keywords}

entries. Read the list and pick the entry whose

title

description

keywords

category

best matches the user's intent — this is a model judgment, not a keyword score.

Narrowing by category (optional). When the user's request is broad (e.g. "give me an APM dashboard", "something for Kubernetes"), pass

category

to restrict the catalog (case-insensitive), e.g.

category="Apm"

category="K8S Infra Metrics"

. Present the narrowed list to the user and ask them to pick before importing.

Branch on the result:

Template found (a catalog entry is clearly relevant) — proceed to Step 3b-i (template import). Briefly tell the user "I found a pre-built [title] template and will use it" so they know what's being created; do not block on a yes/no.
No template (nothing in the catalog matches) — proceed to Step 3b-ii (custom build).

首先执行模板查找。用户已同意创建新仪表盘——查找仅决定构建方式，无需额外确认提示。

调用

signoz:signoz_list_dashboard_templates

并将

searchContext

设置为用户的原始请求。该工具会返回完整的模板目录，格式为

{id, title, path, description, category, keywords}

的JSON数组。读取列表并选择

title

description

keywords

category

最符合用户意图的条目——这是模型判断，而非关键词评分。

按类别筛选（可选）。当用户请求较为宽泛时（例如“给我一个APM仪表盘”、“适用于Kubernetes的仪表盘”），传入

category

以限制目录范围（不区分大小写），例如

category="Apm"

或

category="K8S Infra Metrics"

。将筛选后的列表展示给用户，让用户选择后再导入。

根据结果分支处理：

找到匹配模板（目录中存在明显相关的条目）——进入步骤3b-i（导入模板）。简要告知用户“我找到了一个预构建的[title]模板，将使用该模板创建仪表盘”，无需等待用户确认；
无匹配模板（目录中没有匹配项）——进入步骤3b-ii（自定义构建）。

Step 3b-i: Import the template

步骤3b-i：导入模板

Tool guardrail. The only template tools are
signoz:signoz_list_dashboard_templates
and
signoz:signoz_import_dashboard
. Do not shell out, fetch raw GitHub URLs, or invent other tool names.
signoz:signoz_import_dashboard
takes the template
path
from the catalog entry and creates the dashboard in one call — you do not need to fetch the JSON yourself or call
signoz:signoz_create_dashboard
afterwards.

Pre-flight no-data check. Before calling
```
signoz:signoz_import_dashboard
```
, probe whether the template's signals are actually being ingested. Since we don't fetch the template body up front, base the probe on the catalog entry's
```
category
```
,
```
title
```
, and
```
keywords
```
plus the user's stated technology. Pick up to ~5 representative signals and check them — keep the total small:
- Metric-based templates (most infra/runtime templates — e.g. PostgreSQL, Redis, JVM, hostmetrics, k8s): call
```
signoz:signoz_list_metrics
```
  with
```
searchText=<technology prefix>
```
  (e.g.
```
postgresql
```
  ,
```
redis
```
  ,
```
jvm
```
  ,
```
system.
```
  ,
```
k8s.
```
  ) and
```
timeRange=1h
```
  . Empty result → metric family is not being ingested.
- Trace-based templates (APM-style): call
```
signoz:signoz_aggregate_traces
```
  with
```
aggregation=count
```
  , an appropriate filter (e.g.
```
service.name EXISTS
```
  ),
```
timeRange=1h
```
  . A zero count → no traces.
- Log-based templates: call
```
signoz:signoz_aggregate_logs
```
  with
```
aggregation=count
```
  , a relevant filter,
```
timeRange=1h
```
  . A zero count → no logs.
- Variable values (when the template clearly relies on a resource attribute, e.g.
```
service.name
```
  ,
```
k8s.cluster.name
```
  ): call
```
signoz:signoz_get_field_values
```
  to confirm there are values to pick from.
- If none of the probed signals return data, warn the user verbatim: "I couldn't find data for [list] in the last hour — this template is for [technology] and it doesn't look like that data is being ingested yet. I can still create the dashboard (it will just show 'No data' until you ingest), or I can stop here. Which would you like?" Wait for the user's choice.
- If some signals are present and others aren't, list which are missing and proceed only on confirmation.
- If everything is present, proceed silently.
Create the dashboard. Call
```
signoz:signoz_import_dashboard
```
with the
```
path
```
from the chosen catalog entry (e.g.
```
postgresql/postgresql.json
```
). The server fetches the JSON, validates it, and creates the dashboard in one call.
Report and offer customization. Tell the user what was created (title, panel count, sections — read these from the response). If the user requests changes, call
```
signoz:signoz_get_dashboard
```
to fetch the current state, then
```
signoz:signoz_update_dashboard
```
with the modified full JSON.

工具约束。唯一可用的模板工具是
signoz:signoz_list_dashboard_templates
和
signoz:signoz_import_dashboard
。不要使用shell命令、获取原始GitHub URL或使用其他工具名称。
signoz:signoz_import_dashboard
接收目录条目中的
path
参数，一次调用即可创建仪表盘——无需自行获取JSON或在之后调用
signoz:signoz_create_dashboard
。

预检查数据是否存在。在调用
```
signoz:signoz_import_dashboard
```
之前，探测模板所需的信号是否已被采集。由于我们不会预先获取模板内容，需基于目录条目的
```
category
```
、
```
title
```
、
```
keywords
```
以及用户指定的技术进行探测。选择最多约5个代表性信号进行检查——数量不宜过多：
- 基于指标的模板（大多数基础设施/运行时模板——例如PostgreSQL、Redis、JVM、hostmetrics、k8s）：调用
```
signoz:signoz_list_metrics
```
  并设置
```
searchText=<技术前缀>
```
  （例如
```
postgresql
```
  、
```
redis
```
  、
```
jvm
```
  、
```
system.
```
  、
```
k8s.
```
  ）和
```
timeRange=1h
```
  。结果为空→该指标系列未被采集。
- 基于追踪的模板（APM风格）：调用
```
signoz:signoz_aggregate_traces
```
  并设置
```
aggregation=count
```
  、合适的过滤器（例如
```
service.name EXISTS
```
  ）、
```
timeRange=1h
```
  。计数为0→无追踪数据。
- 基于日志的模板：调用
```
signoz:signoz_aggregate_logs
```
  并设置
```
aggregation=count
```
  、相关过滤器、
```
timeRange=1h
```
  。计数为0→无日志数据。
- 变量值（当模板明显依赖资源属性时，例如
```
service.name
```
  、
```
k8s.cluster.name
```
  ）：调用
```
signoz:signoz_get_field_values
```
  确认存在可选值。
- 如果所有探测的信号都未返回数据，直接警告用户：“我在过去一小时内未找到[列出信号]的数据——此模板适用于[技术]，但看起来相关数据尚未被采集。我仍可以创建仪表盘（在您开始采集数据前，仪表盘将显示‘无数据’），也可以在此停止操作。您希望如何处理？”等待用户选择。
- 如果部分信号存在而其他信号缺失，列出缺失的信号并仅在用户确认后继续操作。
- 如果所有信号都存在，则静默继续操作。
创建仪表盘。调用
```
signoz:signoz_import_dashboard
```
并传入所选目录条目的
```
path
```
（例如
```
postgresql/postgresql.json
```
）。服务器会获取JSON、验证并一次性创建仪表盘。
反馈结果并提供自定义选项。告知用户已创建的内容（标题、面板数量、分区——从响应中读取这些信息）。如果用户请求修改，调用
```
signoz:signoz_get_dashboard
```
获取当前状态，然后调用
```
signoz:signoz_update_dashboard
```
并传入修改后的完整JSON。

Step 3b-ii: Custom build (no template, or import failed)

步骤3b-ii：自定义构建（无匹配模板或导入失败）

Run this path when the Step 3b template lookup found no match, or when

signoz:signoz_import_dashboard

failed. Build a dashboard from scratch.

Gather requirements — ask the user:
- What signals to monitor (metrics, traces, logs, or a combination)
- What specific metrics or data points matter most
- Which services or components to include
- What filters/variables they need (environment, service name, instance)
Read the dashboard MCP resources for JSON structure, panel types, query builder format, and layout rules:
- ```
signoz://dashboard/instructions
```
  — title, tags, description, variables.
- ```
signoz://dashboard/widgets-instructions
```
  — 7 panel types and layout rules.
- ```
signoz://dashboard/widgets-examples
```
  — complete widget configurations.
- ```
signoz://dashboard/query-builder-example
```
  — query builder reference. Add metric/trace/log-specific resources (
```
signoz://dashboard/clickhouse-*
```
  ,
```
signoz://dashboard/promql-example
```
  ,
```
signoz://traces/query-builder-guide
```
  ) as needed for the signal types involved.
Build the dashboard JSON following the v5 schema as documented in the MCP resources loaded in the previous step. Use OTel semantic attribute names (not shorthand) in filters, groupBy, and variables.
Pre-flight no-data check. Before calling
```
signoz:signoz_create_dashboard
```
, probe a representative subset of the metrics / attributes you used, using the same MCP tools listed in Step 3b-i.1 (
```
signoz:signoz_list_metrics
```
for metrics,
```
signoz:signoz_aggregate_traces
```
/
```
signoz:signoz_aggregate_logs
```
for trace/log presence,
```
signoz:signoz_get_field_values
```
for variable values). If none return data in the last hour, warn the user (same wording as Step 3b-i.1) and wait for confirmation before creating.
Shape check before create. The
```
signoz:signoz_create_dashboard
```
tool rejects stringified JSON for array/object fields with errors like
```
cannot unmarshal string into ... layout of type []LayoutItem
```
/
```
... tags of type []string
```
. Verify the values you are about to pass match the input schema's types — do not wrap them in
```
JSON.stringify
```
/
```
json.dumps
```
:
- ```
tags
```
  → array of strings.
- ```
layout
```
  → array of
```
{i, x, y, w, h}
```
  objects.
- ```
widgets
```
  → array of widget objects.
- ```
variables
```
  → object/map keyed by variable name.
- ```
title
```
  ,
```
description
```
  → plain strings.
Call
```
signoz:signoz_create_dashboard
```
with the built JSON.
Report what was created and offer to adjust anything. If the user requests changes, call
```
signoz:signoz_get_dashboard
```
to fetch the current state, then use
```
signoz:signoz_update_dashboard
```
with the modified full dashboard JSON.

当步骤3b的模板查找未找到匹配项，或

signoz:signoz_import_dashboard

调用失败时，执行此流程。从头构建仪表盘。

收集需求——询问用户：
- 需要监控哪些信号（指标、追踪、日志或组合）
- 哪些特定指标或数据点最为重要
- 需要包含哪些服务或组件
- 需要哪些过滤器/变量（环境、服务名称、实例）
读取仪表盘MCP资源以了解JSON结构、面板类型、查询构建器格式和布局规则：
- ```
signoz://dashboard/instructions
```
  ——标题、标签、描述、变量。
- ```
signoz://dashboard/widgets-instructions
```
  ——7种面板类型和布局规则。
- ```
signoz://dashboard/widgets-examples
```
  ——完整的组件配置示例。
- ```
signoz://dashboard/query-builder-example
```
  ——查询构建器参考。根据涉及的信号类型，添加特定于指标/追踪/日志的资源（
```
signoz://dashboard/clickhouse-*
```
  、
```
signoz://dashboard/promql-example
```
  、
```
signoz://traces/query-builder-guide
```
  ）。
构建仪表盘JSON，遵循MCP资源中记录的v5 schema。在过滤器、groupBy和变量中使用OTel语义属性名称（而非简写）。
预检查数据是否存在。在调用
```
signoz:signoz_create_dashboard
```
之前，使用步骤3b-i.1中列出的MCP工具探测所使用的指标/属性的代表性子集（指标使用
```
signoz:signoz_list_metrics
```
，追踪/日志存在性使用
```
signoz:signoz_aggregate_traces
```
/
```
signoz:signoz_aggregate_logs
```
，变量值使用
```
signoz:signoz_get_field_values
```
）。如果过去一小时内没有数据返回，警告用户（使用与步骤3b-i.1相同的措辞）并等待用户确认后再创建。
创建前的格式检查。
```
signoz:signoz_create_dashboard
```
工具会拒绝数组/对象字段的字符串化JSON，错误信息类似
```
cannot unmarshal string into ... layout of type []LayoutItem
```
/
```
... tags of type []string
```
。验证即将传入的值是否符合输入schema的类型——不要使用
```
JSON.stringify
```
/
```
json.dumps
```
进行包装：
- ```
tags
```
  → 字符串数组。
- ```
layout
```
  →
```
{i, x, y, w, h}
```
  对象数组。
- ```
widgets
```
  → 组件对象数组。
- ```
variables
```
  → 以变量名为键的对象/映射。
- ```
title
```
  ,
```
description
```
  → 纯字符串。
调用
```
signoz:signoz_create_dashboard
```
并传入构建好的JSON。
反馈已创建的内容并提供调整选项。如果用户请求修改，调用
```
signoz:signoz_get_dashboard
```
获取当前状态，然后使用
```
signoz:signoz_update_dashboard
```
并传入修改后的完整仪表盘JSON。

Guardrails

约束规则

Duplicate check first: Always call
```
signoz:signoz_list_dashboards
```
(paginated) before anything else. The user's only two upfront options are "modify an existing one" or "create a new one" — never offer template-import as a separate top-level choice.
Template-first on the create path: Once the user has chosen to create a new dashboard, always run
```
signoz:signoz_list_dashboard_templates
```
before any
```
signoz:signoz_create_dashboard
```
call. If a matching template exists, import it via
```
signoz:signoz_import_dashboard
```
(just inform the user); only build from scratch when no template matches.
No blind creation: For custom builds, confirm the plan with the user after gathering requirements before calling
```
signoz:signoz_create_dashboard
```
.
Valid JSON only: When building custom dashboards, follow the v5 schema as documented in the
```
signoz://dashboard/*
```
MCP resources. Required widget and
```
queryData
```
fields are listed in
```
signoz://dashboard/widgets-instructions
```
and
```
signoz://dashboard/widgets-examples
```
— include all of them. Never generate malformed queries or layouts.
OTel attribute names: Always use OpenTelemetry semantic conventions for attribute names in filters, groupBy, and variables. Use
```
service.name
```
not
```
service
```
,
```
host.name
```
not
```
host
```
,
```
deployment.environment.name
```
not
```
env
```
.
No metric guessing: For custom builds, if you are not sure what metrics are available, ask the user. Wrong metric names produce empty panels.
No-data warning before create: Always run the pre-flight probe (Step 3b-i.1 / Step 3b-ii.4) before
```
signoz:signoz_import_dashboard
```
/
```
signoz:signoz_create_dashboard
```
. A "No data" dashboard is a worse user outcome than one extra confirmation prompt. Skip the probe only if the user has explicitly opted out for this request.
Full state on update:
```
signoz:signoz_update_dashboard
```
requires the complete dashboard JSON (not a partial patch). Always call
```
signoz:signoz_get_dashboard
```
first to get the current state, merge your changes into that full object, and pass the result to
```
signoz:signoz_update_dashboard
```
.
Scope boundary: This skill creates dashboards. Post-creation modifications beyond the initial customization offer belong to
```
signoz-modifying-dashboards
```
.

优先检查重复项：在执行任何操作之前，始终调用
```
signoz:signoz_list_dashboards
```
（分页遍历）。用户仅有的两个初始选项是“修改现有仪表盘”或“创建新仪表盘”——切勿将导入模板作为单独的顶级选项提供。
创建流程优先使用模板：一旦用户选择创建新仪表盘，在调用
```
signoz:signoz_create_dashboard
```
之前始终先运行
```
signoz:signoz_list_dashboard_templates
```
。如果存在匹配模板，通过
```
signoz:signoz_import_dashboard
```
导入（仅告知用户）；仅当无匹配模板时才从头构建。
不盲目创建：对于自定义构建，收集需求后需与用户确认方案，再调用
```
signoz:signoz_create_dashboard
```
。
仅使用有效JSON：构建自定义仪表盘时，遵循
```
signoz://dashboard/*
```
MCP资源中记录的v5 schema。
```
signoz://dashboard/widgets-instructions
```
和
```
signoz://dashboard/widgets-examples
```
中列出了组件和
```
queryData
```
的必填字段——必须包含所有必填字段。切勿生成格式错误的查询或布局。
使用OTel属性名称：在过滤器、groupBy和变量中始终使用OpenTelemetry语义规范的属性名称。使用
```
service.name
```
而非
```
service
```
，
```
host.name
```
而非
```
host
```
，
```
deployment.environment.name
```
而非
```
env
```
。
不猜测指标：对于自定义构建，如果不确定可用的指标有哪些，请询问用户。错误的指标名称会导致面板为空。
创建前的无数据警告：在调用
```
signoz:signoz_import_dashboard
```
/
```
signoz:signoz_create_dashboard
```
之前，始终执行预检查探测（步骤3b-i.1 / 步骤3b-ii.4）。显示“无数据”的仪表盘比多一次确认提示的用户体验更差。仅当用户明确选择跳过此探测时才可以省略。
更新时传入完整状态：
```
signoz:signoz_update_dashboard
```
需要完整的仪表盘JSON（而非部分补丁）。始终先调用
```
signoz:signoz_get_dashboard
```
获取当前状态，将修改合并到完整对象中，再将结果传入
```
signoz:signoz_update_dashboard
```
。
范围边界：本技能负责创建仪表盘。创建后的修改超出初始自定义范围的，属于
```
signoz-modifying-dashboards
```
的范畴。

Examples

示例

User: "Create a dashboard for my PostgreSQL database"

Agent:

Calls
```
signoz:signoz_list_dashboards
```
(paginated) — no existing PostgreSQL dashboard.
Says: "I'll create a new dashboard for PostgreSQL. Proceed?"
User confirms.
Calls
```
signoz:signoz_list_dashboard_templates
```
with the user's request as
```
searchContext
```
— picks the
```
postgresql/postgresql.json
```
entry. Tells the user: "I found a pre-built PostgreSQL template and will use it."

Runs the no-data probe (

signoz:signoz_list_metrics searchText=postgresql

), then calls

signoz:signoz_import_dashboard

with

path=postgresql/postgresql.json

Reports: "Created 'Postgres overview' dashboard with N panels across M sections. Want me to adjust any panels, add variables, or change the layout?"

User: "Create a dashboard to track our payment processing pipeline"

Agent:

Calls
```
signoz:signoz_list_dashboards
```
(paginated) — no existing payment dashboard.
Says: "I'll create a new dashboard for the payment processing pipeline. Proceed?"
User confirms.
Calls
```
signoz:signoz_list_dashboard_templates
```
— nothing in the catalog matches "payment processing". Falls through to custom build.
Gathers requirements: transaction count, latency, error rate, services involved, filter needs.

Reads

signoz://dashboard/instructions

widgets-instructions

, and

widgets-examples

for JSON structure.

Builds dashboard with sections: Overview, Latency, Errors, Infrastructure. Runs the no-data probe.
Calls
```
signoz:signoz_create_dashboard
```
.
Reports what was created, offers customization.

User: "Set up monitoring for Redis"

Agent:

Calls
```
signoz:signoz_list_dashboards
```
(paginated) — finds existing "Redis Overview" dashboard.
Says: "There's already a 'Redis Overview' dashboard. Want me to (a) modify it, (b) create a new dashboard anyway, or (c) stop?"
If user picks (a) — Step 3a: calls
```
signoz:signoz_get_dashboard
```
, plans changes, calls
```
signoz:signoz_update_dashboard
```
with the full updated JSON.

If user picks (b) — Step 3b: calls

signoz:signoz_list_dashboard_templates

, picks

redis/redis.json

, imports it via

signoz:signoz_import_dashboard

(Step 3b-i).

用户：“为我的PostgreSQL数据库创建仪表盘”

Agent：

调用
```
signoz:signoz_list_dashboards
```
（分页遍历）——未找到现有的PostgreSQL仪表盘。
回复：“我将为您创建一个新的PostgreSQL仪表盘。是否继续？”
用户确认。
调用
```
signoz:signoz_list_dashboard_templates
```
并将用户请求作为
```
searchContext
```
——选择
```
postgresql/postgresql.json
```
条目。告知用户：“我找到了一个预构建的PostgreSQL模板，将使用该模板创建仪表盘。”

执行无数据探测（

signoz:signoz_list_metrics searchText=postgresql

），然后调用

signoz:signoz_import_dashboard

并传入

path=postgresql/postgresql.json

。

反馈：“已创建‘Postgres overview’仪表盘，包含N个面板，分为M个分区。是否需要调整面板、添加变量或修改布局？”

用户：“创建一个仪表盘来追踪我们的支付处理流程”

Agent：

调用
```
signoz:signoz_list_dashboards
```
（分页遍历）——未找到现有的支付相关仪表盘。
回复：“我将为您创建一个支付处理流程的新仪表盘。是否继续？”
用户确认。
调用
```
signoz:signoz_list_dashboard_templates
```
——目录中没有匹配“支付处理”的模板。进入自定义构建流程。
收集需求：交易数量、延迟、错误率、涉及的服务、过滤需求。

读取

signoz://dashboard/instructions

、

widgets-instructions

和

widgets-examples

以了解JSON结构。

构建包含以下分区的仪表盘：概览、延迟、错误、基础设施。执行无数据探测。
调用
```
signoz:signoz_create_dashboard
```
。
反馈已创建的内容，提供自定义选项。

用户：“为Redis设置监控”

Agent：

调用
```
signoz:signoz_list_dashboards
```
（分页遍历）——找到现有的“Redis Overview”仪表盘。
回复：“已存在一个‘Redis Overview’仪表盘。请问您想要(a)修改它，(b)仍创建新仪表盘，还是(c)停止操作？”
如果用户选择(a)——步骤3a：调用
```
signoz:signoz_get_dashboard
```
，规划修改，调用
```
signoz:signoz_update_dashboard
```
并传入完整的更新后JSON。
如果用户选择(b)——步骤3b：调用
```
signoz:signoz_list_dashboard_templates
```
，选择
```
redis/redis.json
```
，通过
```
signoz:signoz_import_dashboard
```
导入（步骤3b-i）。",