1. Configure hooks Configure hooks in openclaw.json 1 2 3 4 5 6 7 "hooks": { "enabled": true, "token": "xxx", "path": "/openclaw/hooks", "allowRequestSessionKey": true, "allowedAgentIds": ["*"] }, See https://docs.openclaw.ai/automation/webhook The token here must not be the same as the gateway’s token. 2. Sending a message 1 2 3 4 5 6 7 8 9 10 11 12 curl --location 'https://xxx.

1. Handling Deterministic Faults For faults that have a specific handling procedure, just let the Agent handle them and send a notification to spread the word. For similar automated handling, we have exception load deletion at the application layer, disk cleanup at the node layer, masking an offline GPU card, masking a node, and so on.

https://github.com/shaowenchen/ops 1. Alerting on Kubernetes Cluster Events Monitor specified keywords 1 2 3 4 5 6 7 8 9 10 11 apiVersion: crd.chenshaowen.com/v1 kind: EventHooks metadata: name: kube-pod-falid namespace: ops-system spec: type: xiezuo url: https://xxx.com/api/v1/webhook/send?key=xxx subject: "ops.clusters.*.namespaces.*.pods.*.event" keywords: - failed A simple configuration like this yields a large number of related alerts.

1. An Operations Service System That Has Piled Up Beyond Repair Developing a corresponding operations service for a clear operations need, so that operations and business users can use it, is entirely reasonable. But if you are satisfied with only that, the following situation easily appears: Users constantly look for the entry point of each system, jumping back and forth between systems, busy hunting for buttons and copying parameters.

1. Preparing the Scheduled Script If it is a Bash script, the first line needs to specify the interpreter. 1 2 mkdir -p /root/scripts vim /root/scripts/quick-clear.sh 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 #!/bin/sh /usr/local/bin/kubectl --kubeconfig /root/.kube/config get pods --all-namespaces -o wide | grep Evicted | awk '{print $1,$2}' | xargs --no-run-if-empty -L1 /usr/local/bin/kubectl --kubeconfig /root/.