Alerting¶

AI Studio workspace alerting consists of alert rules, notification recipients, and alert records. Rules observe ingestion and processing metrics, recipients determine message delivery, and records preserve trigger events. The SDK can help an application investigate related tasks, but it does not currently manage these alerting objects.

Current SDK boundary¶

The official Python SDK and Go SDK currently provide no public methods or types to:

list, create, update, enable, disable, or delete alert rules;
manage email, SMS, phone, or WeCom notification recipients;
query alert records, change read state, or acknowledge an alert.

Perform those operations on the AI Studio Alerts page. Do not use RawClient request helpers to call internal console paths. Undocumented paths, fields, and enumerations can change between service versions.

The SDK is useful in the investigation that follows an alert:

Obtain the trigger time, rule ID, expression, and related task information from the notification or alert record.
Query an ingestion task by task ID, or query a workflow job by workflow ID and source file ID.
Correlate the returned state with job logs, SQL history, and compute-resource state.
After remediation, review the alert in the console and adjust its threshold, notification interval, or recipients if needed.

An alert record marked read means that someone viewed it; it does not mean the underlying condition has recovered.

Query an ingestion task¶

get_task / GetTask retrieves an ingestion task. It is not a general alert-details API. The task ID usually comes from an ingestion or upload response. Whether a notification includes that ID depends on the current rule and message format.

Python¶

import os

from moi import RawClient

client = RawClient(
    base_url=os.environ["MOI_BASE_URL"],
    api_key=os.environ["MOI_API_KEY"],
)

task = client.get_task({"task_id": 123456})
print("status:", task.get("status"))

for result in task.get("load_results", []):
    if result.get("reason"):
        print("failure:", result["reason"])

The Python SDK returns response data as a dictionary. Check for optional fields instead of assuming every deployment returns an identical shape.

Go¶

package main

import (
	"context"
	"fmt"
	"log"
	"os"

	sdk "github.com/matrixorigin/moi-go-sdk"
)

func main() {
	client, err := sdk.NewRawClient(
		os.Getenv("MOI_BASE_URL"),
		os.Getenv("MOI_API_KEY"),
	)
	if err != nil {
		log.Fatal(err)
	}

	task, err := client.GetTask(context.Background(), &sdk.TaskInfoRequest{
		TaskID: sdk.TaskID(123456),
	})
	if err != nil {
		log.Fatal(err)
	}

	fmt.Printf("task=%s status=%s\n", task.ID, task.Status)
	for _, result := range task.LoadResults {
		if result != nil && result.Reason != "" {
			fmt.Printf("failure=%s\n", result.Reason)
		}
	}
}

TaskInfoResponse can also contain start, end, and update times, source files, and load results. Follow the actual response, and do not treat the client request completion time as the server-side event time associated with the alert.

Query a workflow job¶

When an alert identifies both a workflow and a source file, use the high-level client to find that job.

from moi import SDKClient

sdk = SDKClient(client)
job = sdk.get_workflow_job(
    workflow_id="workflow-123",
    source_file_id="file-456",
)
print(job.get("job_id"), job.get("status"))

If the job may not have appeared in the list yet, the Python SDK also provides wait_for_workflow_job(). The Go SDK provides GetWorkflowJob() and WaitForWorkflowJob(). Put an overall deadline around polling and stop after a terminal failure state. Use the SDK’s public types and the actual service response as the source of truth for status codes and fields.

Design actionable alerts¶

Before creating a rule in the console, connect each alert setting to the information needed for diagnosis:

Setting	Guidance
Rule	Choose templates and thresholds separately for ingestion and processing risks
Notification recipient	Model recipients around on-call responsibility instead of repeating individual addresses across rules
Severity	Use severity to communicate response priority, not as a substitute for a well-chosen threshold
Notification interval	Account for both condition duration and the notification volume recipients can handle
Diagnostic identifiers	Ensure operators can locate the rule, time, workflow, file, or task from the message or console

Create recipients first, then rules, and finally use alert records to verify triggering and delivery. Before disabling or deleting a recipient, check whether any rules still reference it.

Identify the alerting domain¶

This page covers ingestion and processing alerts inside an AI Studio workspace. The following systems are independent and do not share rules, recipients, or records:

Alert source	Documentation
AI Studio workspace	AI Studio · Alerts
MatrixOne database instance	MatrixOne · Alerts
Balance and spending	Account settings

When a message arrives, first identify its platform, workspace, and time range, then select the matching logs and SDK identifiers. Do not query workspace tasks for an instance alert or use a workspace API key to manage an alert from another platform.