Data Storage
CODEBLOCK0
Create on first use: INLINECODE0
Scope
This skill:
- - ✅ Stores monitor definitions in ~/monitor/
- ✅ Runs checks at specified intervals
- ✅ Alerts user on status changes
Execution model:
- - User explicitly defines WHAT to monitor
- User grants any permissions/tools needed
- Skill only handles WHEN and ALERTING
This skill does NOT:
- - ❌ Assume access to any service or endpoint
- ❌ Run checks without user-defined instructions
- ❌ Store credentials (user provides via environment or other skills)
Requirements
Required:
Optional (for alerts):
- -
PUSHOVER_TOKEN / PUSHOVER_USER — for push notifications - Webhook URL — user provides their own endpoint
Used if available:
- -
openssl — for SSL certificate checks - INLINECODE5 — for process checks
- INLINECODE6 — for disk space checks
- INLINECODE7 — for port checks
Quick Reference
| Topic | File |
|---|
| Monitor type examples | INLINECODE8 |
| Alert configuration |
alerts.md |
| Analysis patterns |
insights.md |
Core Rules
1. User Defines Everything
When user requests a monitor:
- 1. WHAT: User specifies what to check
- HOW: User provides method or grants tool access
- WHEN: This skill handles interval
- ALERT: This skill handles notifications
Example flow:
CODEBLOCK1
2. Monitor Definition
In ~/monitor/monitors.json:
CODEBLOCK2
3. Common Check Types
User can request any of these (or others):
| Type | What it checks | Tool used |
|---|
| http | URL status + latency | curl |
| ssl |
Certificate expiry | openssl |
| process | Process running | pgrep |
| disk | Free space | df |
| port | Port open | nc |
| custom | User-defined command | user specifies |
4. Confirmation Format
CODEBLOCK3
5. Alert on Change
- - Alert when status changes (ok→fail, fail→ok)
- Include failure count
- Recovery message when back to OK
- Never spam repeated same-status
6. Permissions
The
requires field lists what user granted:
- - Empty = basic checks only (curl, df, pgrep)
- INLINECODE12 = user granted SSH access
- INLINECODE13 = user granted Docker access
Agent asks before assuming any access.
数据存储
~/monitor/
├── monitors.json # 监控定义
├── config.json # 告警偏好
└── logs/ # 检查结果
└── {name}/YYYY-MM.jsonl
首次使用时创建:mkdir -p ~/monitor/logs
适用范围
本技能:
- - ✅ 将监控定义存储在 ~/monitor/ 目录下
- ✅ 按指定间隔执行检查
- ✅ 在状态变化时向用户发送告警
执行模式:
- - 用户明确指定要监控的内容
- 用户授予所需的任何权限/工具
- 本技能仅处理时间安排和告警触发
本技能不会:
- - ❌ 假定对任何服务或端点的访问权限
- ❌ 在无用户定义指令的情况下执行检查
- ❌ 存储凭据(用户通过环境变量或其他技能提供)
依赖要求
必需:
可选(用于告警):
- - PUSHOVERTOKEN / PUSHOVERUSER — 用于推送通知
- Webhook URL — 用户提供自己的端点
可用时使用:
- - openssl — 用于 SSL 证书检查
- pgrep — 用于进程检查
- df — 用于磁盘空间检查
- nc — 用于端口检查
快速参考
| 主题 | 文件 |
|---|
| 监控类型示例 | templates.md |
| 告警配置 |
alerts.md |
| 分析模式 | insights.md |
核心规则
1. 用户定义所有内容
当用户请求监控时:
- 1. 监控内容:用户指定要检查的内容
- 检查方式:用户提供方法或授予工具访问权限
- 检查频率:本技能处理时间间隔
- 告警方式:本技能处理通知
示例流程:
用户:每5分钟监控我的API api.example.com
助手:我将检查HTTP状态。状态变化时告警?
用户:是的,同时检查SSL证书
→ 使用用户定义的检查项存储监控配置
2. 监控定义
在 ~/monitor/monitors.json 中:
json
{
api_prod: {
description: 用户的API健康状态,
checks: [
{type: http, target: https://api.example.com/health},
{type: ssl, target: api.example.com}
],
interval: 5m,
alert_on: change,
requires: [],
created: 2024-03-15
}
}
3. 常见检查类型
用户可以请求以下任何类型(或其他类型):
| 类型 | 检查内容 | 使用工具 |
|---|
| http | URL状态 + 延迟 | curl |
| ssl |
证书过期时间 | openssl |
| process | 进程运行状态 | pgrep |
| disk | 磁盘剩余空间 | df |
| port | 端口开放状态 | nc |
| custom | 用户自定义命令 | 用户指定 |
4. 确认格式
✅ 监控:[描述]
🔍 检查:[将检查的内容]
⏱️ 间隔:[检查频率]
🔔 告警:[通知条件]
🔧 依赖:[所需工具/权限]
5. 状态变化告警
- - 状态变化时告警(正常→故障,故障→正常)
- 包含故障次数
- 恢复时发送恢复消息
- 绝不重复发送相同状态的告警
6. 权限管理
requires 字段列出用户已授予的权限:
- - 空值 = 仅基础检查(curl, df, pgrep)
- [ssh:server1] = 用户已授予SSH访问权限
- [docker] = 用户已授予Docker访问权限
助手在假定任何访问权限前会先询问用户。