Alibaba SLS Error Log Volume Sentinel

An application logging to Alibaba Cloud Simple Log Service can start throwing errors in volume with nobody watching until a customer complains; SLS itself shows the logs if someone opens the console, it does not keep a schedule, compare the error count against a threshold you declare, or notify anyone. This blueprint reads the real matched count directly from SLS's own query engine, not a client-side guess.

This blueprint was created by Mohit Jeswani.

How it works

1. query_error_logs (io.kestra.plugin.alibaba.sls.Query) runs error_query against sls_logstore over the last lookback_minutes, with fetchType: NONE since this check only needs the matched count, not the log content itself. Read-only; nothing in SLS is changed. allowFailure: true covers an API or auth error without failing the flow outright.
2. evaluate (io.kestra.plugin.core.output.OutputValues) reads the matched count directly from the query response's own count field and compares it against max_error_count.
3. route (io.kestra.plugin.core.flow.If):
   • compliant: logs the count, below threshold.
   • alert: posts the count and query to Slack.
4. summary logs the count and severity, closing the governance cycle.
5. errors alerts Slack if the flow itself fails, for example an expired access key.

What you get

• A count that is SLS's own server-side query match, not a client-side guess computed after paging through log lines.
• A failed query and a genuine volume spike both surface, with distinct severities so you know which one happened without reading logs.
• A read-only check with zero risk of writing to or modifying the logstore.

Who it's for

• Platform and SRE teams running services that log to Alibaba Cloud SLS who want an error spike paged the moment it crosses a threshold, not discovered during an incident review.
• Teams evaluating the Alibaba Cloud plugin who want a worked example of sls.Query used as a standing log-volume compliance check, distinct from this repo's existing Alibaba blueprint, which audits OSS storage class cost rather than SLS log volume.

Why orchestrate this with Kestra

SLS answers one query at a time; it does not keep a schedule, compare the match count against a tolerance you declare, or notify a Slack channel when errors spike. Kestra keeps error_query, lookback_minutes, and max_error_count as flow inputs, turns the query into a Slack page naming the real count, and keeps a full execution history of every run.

Prerequisites

• An Alibaba Cloud account with an SLS project and logstore already receiving log data.
• An Alibaba Cloud access key with read permission on that project and logstore.
• A Slack incoming webhook URL.

This flow calls the Alibaba Cloud SLS API directly over HTTPS; there is no official local SLS emulator, so query_error_logs cannot be exercised against a local Docker container.

Secrets

• ALIBABA_ACCESS_KEY_ID / ALIBABA_ACCESS_KEY_SECRET: the Alibaba Cloud access key used by query_error_logs. In Kestra OSS, provide them as the base64-encoded environment variables SECRET_ALIBABA_ACCESS_KEY_ID and SECRET_ALIBABA_ACCESS_KEY_SECRET.
• SLACK_WEBHOOK_URL: used by alert and the errors block. In Kestra OSS, provide it as the base64-encoded environment variable SECRET_SLACK_WEBHOOK_URL.

Inputs

Input	Default	Purpose
error_query	level: ERROR	SLS query selecting the entries to count
lookback_minutes	15	How far back from now to search
max_error_count	10	Match count at or above which the alert fires

Outputs

• {{ outputs.query_error_logs.count }}: the real SLS-reported match count for error_query over the lookback window.
• {{ outputs.evaluate.values.error_count }} / .severity: the same count, and OK, ERROR_VOLUME_SPIKE, or CRITICAL.

Pitfalls

• error_query is the entire governance policy; a typo in the SLS query syntax makes SLS return an error surfaced via allowFailure, not a silently empty result.
• lines: 100 caps the detail SLS would otherwise return per call, but with fetchType: NONE this check never fetches log content, only the count, so the 100-line cap does not limit what gets counted.
• from/to are rendered here as epoch seconds computed from now(); SLS evaluates the range against its own server clock, so significant clock skew on either side can shift which log lines count as within the lookback window.

Quick start

1. Add the ALIBABA_ACCESS_KEY_ID, ALIBABA_ACCESS_KEY_SECRET, and SLACK_WEBHOOK_URL secrets.
2. Set sls_region, sls_project, and sls_logstore to a real logstore.
3. Run the flow manually and confirm summary logs a count.
4. Lower max_error_count below the real current count to confirm alert fires.
5. Enable the every_5_minutes trigger once the thresholds match your real alerting policy.

How to extend

• Loop over several sls_logstore values with io.kestra.plugin.core.flow.Loop to monitor more than one logstore's error volume in a single scheduled run.
• Switch fetchType to FETCH and chain an AI summarization task on the returned logs to include a sample of the actual error messages in the Slack alert.
• Add a second query_error_logs call with a WARN-level query to track both severities side by side in one run.

Links

• Alibaba Cloud plugin: https://kestra.io/plugins/plugin-alibaba
• Alibaba Cloud SLS query syntax reference: https://www.alibabacloud.com/help/en/sls/user-guide/search-syntax-and-usage
• Slack incoming webhooks: https://api.slack.com/messaging/webhooks