Setup
On first use, explain planned local storage in ~/beszel/ and ask for confirmation before creating or updating files.
When to Use
User needs help planning, deploying, or maintaining Beszel for infrastructure monitoring.
Agent handles topology choices, secure agent onboarding, alert calibration, and upgrade-safe operations.
Architecture
Memory lives in ~/beszel/. See memory-template.md for setup.
CODEBLOCK0
Quick Reference
| Topic | File |
|---|
| Setup behavior | INLINECODE3 |
| Memory structure |
memory-template.md |
| Deployment topologies |
deployment-patterns.md |
| Alert calibration workflow |
alert-tuning.md |
| Diagnostics and recovery |
diagnostics-playbook.md |
Data Storage
All skill files are stored in ~/beszel/.
Before writing new files, summarize the planned changes and get user confirmation.
Core Rules
1. Define Monitoring Scope Before Installation
- - Confirm which hosts, services, and failure modes matter most before recommending a layout.
- Prioritize high-impact systems first so coverage is meaningful from day one.
2. Keep Agent Access Minimal
- - Use least privilege for monitored hosts and avoid broad root-level automation by default.
- Treat onboarding credentials as sensitive and avoid copying secrets into workspace notes.
3. Baseline First, Then Tune Alerts
- - Collect a short baseline period before applying strict thresholds.
- Tune alert levels with operating context such as business hours, maintenance windows, and expected burst patterns.
4. Troubleshoot with a Fixed Sequence
- - Validate service status, agent connectivity, clock sync, and resource pressure in a consistent order.
- Isolate one variable at a time to avoid changing many factors during an active incident.
5. Make Upgrades Reversible
- - Require backup and rollback steps before version changes.
- Upgrade one environment at a time and confirm health before broader rollout.
6. Keep Operations Memory Current
- - Record node ownership, alert intent, and previous incidents after meaningful changes.
- Convert repeated incidents into prevention rules and adjust thresholds accordingly.
Common Traps
- - Enrolling many agents before defining alert ownership -> noisy incidents with unclear responders.
- Copying thresholds from another environment -> chronic false positives or missed real failures.
- Upgrading hub and agents simultaneously -> hard-to-debug version mismatch issues.
- Ignoring host clock drift -> misleading timelines and confusing incident analysis.
- Logging sensitive credentials in notes -> unnecessary security exposure.
Security & Privacy
Data that may leave your machine (only when user configures external integrations):
- - Monitoring notifications sent to selected channels or alerting tools.
- Metadata required by external notification endpoints chosen by the user.
Data that stays local by default:
- - Monitoring topology, node notes, threshold history, and incident logs in
~/beszel/.
This skill does NOT:
- - Enable external alert destinations automatically.
- Create new credentials without explicit user approval.
- Send undeclared network requests.
Related Skills
Install with
clawhub install <slug> if user confirms:
- -
monitoring — monitoring architecture and operational standards - INLINECODE12 — server diagnostics and maintenance workflows
- INLINECODE13 — self-hosted deployment and hardening practices
- INLINECODE14 — container runtime and image management discipline
- INLINECODE15 — multi-service orchestration patterns
Feedback
- - If useful: INLINECODE16
- Stay updated: INLINECODE17
设置
首次使用时,说明计划存储在 ~/beszel/ 中的本地存储,并在创建或更新文件前请求确认。
使用时机
用户需要帮助规划、部署或维护用于基础设施监控的 Beszel。
代理处理拓扑选择、安全代理接入、告警校准以及升级安全操作。
架构
数据存储在 ~/beszel/ 中。参见 memory-template.md 了解设置方法。
text
~/beszel/
├── memory.md # 当前环境、目标和优先级
├── nodes.md # 代理清单和所有权
├── alerts.md # 告警阈值和升级目标
└── incidents.md # 事件时间线和恢复记录
快速参考
memory-template.md |
| 部署拓扑 | deployment-patterns.md |
| 告警校准工作流 | alert-tuning.md |
| 诊断与恢复 | diagnostics-playbook.md |
数据存储
所有技能文件存储在 ~/beszel/ 中。
在写入新文件前,总结计划变更并获取用户确认。
核心规则
1. 安装前定义监控范围
- - 在推荐布局前,确认哪些主机、服务和故障模式最为重要。
- 优先覆盖高影响系统,确保从第一天起监控就有意义。
2. 保持代理访问权限最小化
- - 对受监控主机使用最小权限,默认避免广泛的 root 级自动化。
- 将接入凭证视为敏感信息,避免将密钥复制到工作区笔记中。
3. 先建立基线,再调整告警
- - 在应用严格阈值前,先收集一段短期的基线数据。
- 结合运行环境(如工作时间、维护窗口和预期突发模式)调整告警级别。
4. 按固定顺序进行故障排除
- - 按一致顺序验证服务状态、代理连接、时钟同步和资源压力。
- 每次只隔离一个变量,避免在事件处理中同时改变多个因素。
5. 确保升级可回滚
- - 在版本变更前要求备份和回滚步骤。
- 一次只升级一个环境,确认健康后再进行更广泛的部署。
6. 保持运维记录最新
- - 在有意义的变更后,记录节点所有权、告警意图和之前的事件。
- 将重复事件转化为预防规则,并相应调整阈值。
常见陷阱
- - 在定义告警所有权前接入大量代理 → 产生噪音事件且响应者不明确。
- 从其他环境复制阈值 → 长期误报或遗漏真实故障。
- 同时升级中心和代理 → 难以调试的版本不匹配问题。
- 忽略主机时钟漂移 → 误导性时间线和混乱的事件分析。
- 在笔记中记录敏感凭证 → 不必要的安全暴露。
安全与隐私
可能离开您机器的数据(仅在用户配置外部集成时):
- - 发送到选定渠道或告警工具的监控通知。
- 用户选择的外部通知端点所需的元数据。
默认保留在本地的数据:
- - ~/beszel/ 中的监控拓扑、节点笔记、阈值历史和事件日志。
此技能不会:
- - 自动启用外部告警目标。
- 未经用户明确批准创建新凭证。
- 发送未声明的网络请求。
相关技能
如果用户确认,使用 clawhub install 安装:
- - monitoring — 监控架构和运维标准
- server — 服务器诊断和维护工作流
- self-host — 自托管部署和安全加固实践
- docker — 容器运行时和镜像管理规范
- docker-compose — 多服务编排模式
反馈
- - 如果觉得有用:clawhub star beszel
- 保持更新:clawhub sync