Use Dify with CLS Logs for Natural-Language Querying and Alert Analysis
Configure the Tencent Cloud Log Service plugin, query logs from a Dify app, and call a Dify workflow from CLS alerts

LLM operations tools become more useful when they can inspect real operational data. The Tencent Cloud Log Service plugin for Dify gives a Dify application direct access to CLS logs after Tencent Cloud CAM-based authorization. From there, a Dify app can answer simple natural-language log questions, and a Dify workflow can run automatically when a CLS alert fires.
What the plugin adds
| Capability | Operational value |
|---|---|
| CAM-based authorization | Dify accesses CLS through Tencent Cloud credentials configured in the plugin. |
| Log search and analysis | The app can query a specified log topic and pass results into LLM reasoning. |
| Natural-language query path | Users can ask basic log questions in a Dify app. |
| Alert workflow path | A CLS alert can call a Dify workflow API for automatic cause analysis. |
Install the CLS plugin in Dify
- Install the Tencent Cloud Log Service plugin from the Dify marketplace, or search for
CLSin the Dify marketplace. - Open the plugin and choose the authorization entry.
- Enter the Tencent Cloud
SecretIdandSecretKey. - For safer operations, use a separate user with the read-only CLS policy
QcloudCLSReadOnlyAccess. - Set the default log topic for queries.
- Save the configuration.
The plugin setup has two parts: the marketplace installation makes the CLS tool available in Dify, and the authorization step binds that tool to a Tencent Cloud account. Keep the credential scope narrow when possible; a read-only user with QcloudCLSReadOnlyAccess is enough for query and analysis workflows.
Case 1: query logs from a Dify app
The simplest path is to create a Dify application, add the Tencent Cloud log query tool, select the LLM model, and ask log questions in the conversation box.
This path is useful for demonstration and simple lookup. For complex log-query requirements, the recommended path is to use the AI intelligent query-writing capability in the Tencent Cloud Log Service console, because general-purpose models may need precise prompt instructions to produce the right log query syntax.
Case 2: analyze alert causes automatically
A stronger use case is alert triage. When CLS triggers an alert, a custom callback can invoke a Dify workflow API. The workflow queries related raw logs and uses the model to produce an initial cause analysis, then sends both the original alert and the analysis to the operations channel.
The alert-analysis flow has four moving parts:
| Component | Role |
|---|---|
| CLS alert policy | Detects the log condition and triggers the notification path. |
| Custom callback | Calls the Dify workflow API when the alert fires. |
| Dify workflow | Uses the alert payload to query related logs and generate an initial cause analysis. |
| Team notification channel | Delivers the original alert together with the generated analysis for operator review. |
The resulting message contains two parts: the original CLS alert content and a clearer LLM-generated alert-cause analysis.
Build the alert-analysis workflow
This workflow uses an imported Dify workflow configuration named CLS alert intelligent warning analysis.yml, then publishes the workflow and connects it to CLS alerting.
- Create a Dify workflow and import the workflow configuration.
- Update the Enterprise WeCom node webhook key.
- Publish the workflow.
- Copy the Dify workflow API key.
- In the CLS console, create a notification content template that calls the Dify API endpoint.
- Put the Dify API key in the request header.
- Create a CLS integration configuration and point it to the Dify API.
- Create a notification channel group that uses the new template and integration configuration.
- Attach the notification channel group to the CLS alert policy.
The CLS side of the integration should be configured in this order:
| CLS configuration object | Required information |
|---|---|
| Notification content template | The Dify workflow API endpoint, request method, request headers, and alert payload body. |
| Request header | The Dify workflow API key, kept out of the message body. |
| Integration configuration | The target Dify API connection used by CLS alert delivery. |
| Notification channel group | The content template and integration configuration that should be used by the alert policy. |
| Alert policy | The rule that attaches the notification channel group to the actual log alert. |
Implementation notes
- Keep the Dify API key in the CLS request header rather than embedding it in message text.
- Use a read-only CLS policy for the plugin account when the workflow only needs analysis.
- Treat natural-language log querying as a convenience layer; keep complex query generation explicit and verifiable.
- Include the raw alert payload in the workflow context so the model can connect symptoms to recent logs.
- Send both the raw alert and the generated analysis so operators can audit the model output.
FAQ
Can Dify query CLS logs directly?
Yes. After the Tencent Cloud Log Service plugin is installed and authorized, a Dify app can query the configured CLS log topic.
Should production alert triage rely only on a model answer?
No. The model-generated cause analysis should be delivered with the original CLS alert and related log context so operators can verify it.






