Auto-sync: 2026-04-27 00:02
This commit is contained in:
54
wiki/concepts/AlertManagement.md
Normal file
54
wiki/concepts/AlertManagement.md
Normal file
@@ -0,0 +1,54 @@
|
||||
---
|
||||
title: "Alert Management"
|
||||
type: concept
|
||||
tags: [monitoring, alerting, devops, sre]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Alert Management（告警管理）
|
||||
|
||||
**中文名称：** 告警管理
|
||||
|
||||
**类型：** 运维流程与方法论
|
||||
|
||||
**别名：**
|
||||
- 告警管理
|
||||
- 告警分发
|
||||
- Alert Routing
|
||||
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
告警管理（Alert Management）是指从告警**生成 → 接收 → 分类 → 分发 → 响应 → 关闭**的全生命周期管理流程，目的是在关键系统异常时及时通知相关人员，同时避免告警风暴和告警疲劳。
|
||||
|
||||
**告警生命周期：**
|
||||
1. **生成（Generate）：** 监控系统（Prometheus）基于规则判断是否触发告警
|
||||
2. **转发（Forward）：** Prometheus 通过 Alertmanager API 发送告警
|
||||
3. **分发表单（Dismiss）：** Alertmanager 执行抑制、分组、静默
|
||||
4. **路由（Route）：** 按标签/严重级别路由到对应通知渠道
|
||||
5. **响应（Respond）：** 值班人员收到通知并处理
|
||||
6. **关闭（Resolve）：** 问题解决后告警自动消失
|
||||
|
||||
**告警治理最佳实践：**
|
||||
- **SLO/SLA 驱动：** 告警应与业务关键指标绑定，而非基础设施细节
|
||||
- **分级告警：** Critical / Warning / Info 三级，避免所有告警同等紧急
|
||||
- **抑制规则：** 根因告警触发时自动抑制派生告警
|
||||
- **静默期：** 维护窗口内临时屏蔽告警
|
||||
- **On-call Rotation：** 值班轮换确保 24/7 有人响应
|
||||
|
||||
**告警评估黄金法则：** 每条告警必须有明确处理步骤；无法立即采取行动的告警应该被抑制或降低级别
|
||||
|
||||
---
|
||||
|
||||
## Prometheus 告警管理架构
|
||||
|
||||
```
|
||||
Prometheus (规则判断) → Alertmanager (抑制/分组/路由) → 通知渠道 (邮件/Slack/PagerDuty/电话)
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## Related Sources
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]]
|
||||
- [[ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-brid]]
|
||||
69
wiki/concepts/Docker-Daemon-Proxy.md
Normal file
69
wiki/concepts/Docker-Daemon-Proxy.md
Normal file
@@ -0,0 +1,69 @@
|
||||
---
|
||||
title: "Docker Daemon Proxy"
|
||||
type: concept
|
||||
tags: [docker, proxy, systemd, container]
|
||||
date: 2026-05-14
|
||||
---
|
||||
|
||||
# Docker Daemon Proxy
|
||||
|
||||
## Aliases
|
||||
- Docker Daemon Proxy
|
||||
- Docker 守护进程代理
|
||||
- Dockerd Proxy
|
||||
- HTTP_PROXY for Docker Daemon
|
||||
- Docker Daemon HTTP 代理
|
||||
|
||||
## Definition
|
||||
Docker Daemon Proxy 是指通过 systemd 环境变量（`HTTP_PROXY`/`HTTPS_PROXY`）为 Docker 守护进程（`dockerd`）配置显式代理，使所有 `docker pull`、`docker build` 和容器出站流量走指定代理服务器。这是透明代理失效时（尤其在群晖 DSM/Ubuntu Server 环境中）的推荐替代方案。
|
||||
|
||||
## When to Use
|
||||
- 透明代理（V2RayA/Clash）对 Docker Daemon 网络栈无效
|
||||
- 需要可靠、可预测的 `docker pull` 代理行为
|
||||
- 生产环境/多容器部署中需要与系统路由表解耦
|
||||
- 群晖 DSM 7.x（服务名 `pkg-ContainerManager-dockerd`）
|
||||
|
||||
## Implementation Pattern
|
||||
|
||||
### Step 1: Create systemd override directory
|
||||
```bash
|
||||
sudo mkdir -p /etc/systemd/system/pkg-ContainerManager-dockerd.service.d/
|
||||
```
|
||||
|
||||
### Step 2: Create proxy config file
|
||||
```bash
|
||||
sudo vi /etc/systemd/system/pkg-ContainerManager-dockerd.service.d/http-proxy.conf
|
||||
```
|
||||
|
||||
### Step 3: Write environment variables
|
||||
```ini
|
||||
[Service]
|
||||
Environment="HTTP_PROXY=http://127.0.0.1:20171"
|
||||
Environment="HTTPS_PROXY=http://127.0.0.1:20171"
|
||||
Environment="NO_PROXY=localhost,127.0.0.1,192.168.*,*.synology.me"
|
||||
```
|
||||
|
||||
### Step 4: Reload and restart
|
||||
```bash
|
||||
sudo systemctl daemon-reload
|
||||
sudo systemctl restart pkg-ContainerManager-dockerd
|
||||
```
|
||||
|
||||
## Key Distinction from Transparent Proxy
|
||||
| 维度 | 透明代理（Transparent Proxy） | Docker Daemon Proxy |
|
||||
|------|------------------------------|-------------------|
|
||||
| 作用层级 | iptables（内核网络层） | systemd 环境变量 |
|
||||
| 生效范围 | 所有出站流量（NAS 本机） | 仅 Docker Daemon 进程 |
|
||||
| DSM 兼容性 | 可能失效（网络栈差异） | 稳定可靠 |
|
||||
| 对其他服务的影响 | 可能影响 NAS 其他网络服务 | 仅影响 Docker |
|
||||
| 维护难度 | 高（修改系统路由表） | 低（配置分离） |
|
||||
|
||||
## Related Sources
|
||||
- [[群晖NAS科学上网方法]] — DSM 7.x 环境下的 Docker Daemon Proxy 完整配置
|
||||
- [[Ubuntu-Server科学上网]] — Ubuntu Server 环境下的 Docker Daemon Proxy 配置
|
||||
|
||||
## Related Concepts
|
||||
- [[透明代理]] — V2RayA 的默认透明代理机制（在 DSM 中对 Docker Daemon 失效）
|
||||
- [[V2RayA]] — Docker Daemon Proxy 的上游代理服务提供者
|
||||
- [[分流模式]] — V2RayA 的流量路由策略
|
||||
- [[iptables]] — 透明代理依赖的内核规则
|
||||
47
wiki/concepts/Observability.md
Normal file
47
wiki/concepts/Observability.md
Normal file
@@ -0,0 +1,47 @@
|
||||
---
|
||||
title: "Observability"
|
||||
type: concept
|
||||
tags: [devops, monitoring, sre, infrastructure]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Observability（可观测性）
|
||||
|
||||
**中文名称：** 可观测性
|
||||
|
||||
**类型：** 技术方法论 / SRE 核心支柱
|
||||
|
||||
**别名：**
|
||||
- 可观测性
|
||||
- 云原生可观测性
|
||||
- Observability Stack
|
||||
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
可观测性（Observability）是指通过系统外部输出来推断其内部状态的能力。在 IT 运维领域，通常由三大支柱构成：
|
||||
|
||||
1. **指标（Metrics）：** 系统运行时数值数据的时序聚合——如 CPU 使用率、内存占用、请求 QPS。代表工具：Prometheus、InfluxDB、VictoriaMetrics。
|
||||
2. **日志（Logs）：** 系统运行事件的离散记录——如错误日志、访问日志、业务事件。代表工具：ELK（Elasticsearch + Logstash + Kibana）、Loki、Graylog。
|
||||
3. **链路（Traces）：** 分布式请求在多个服务间的调用路径追踪——如 HTTP 请求从 API → DB → Cache 的完整耗时。代表工具：Jaeger、Zipkin、OpenTelemetry。
|
||||
|
||||
**第三支柱趋势：** OpenTelemetry（OTel）作为 CNCF 项目，正在成为可观测数据的统一采集标准，将 Traces、Metrics、Logs 三者以统一规范融合。
|
||||
|
||||
---
|
||||
|
||||
## 家庭监控场景下的应用
|
||||
|
||||
在家庭服务器/NAS 监控中，可观测性通过以下组件实现：
|
||||
- **指标：** Prometheus + node_exporter + cAdvisor + blackbox_exporter
|
||||
- **可视化：** Grafana 仪表盘
|
||||
- **告警：** Alertmanager + 邮件/Slack 通知
|
||||
- **日志（可选）：** Loki + Promtail
|
||||
|
||||
---
|
||||
|
||||
## Related Sources
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]]
|
||||
- [[public-cloud-learning-sessions-observability-with-opentelemetry]]
|
||||
- [[ctp-topic-67-cloud-native-observability-using-opentelemetry]]
|
||||
- [[ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-brid]]
|
||||
@@ -1,74 +1,74 @@
|
||||
# SOCKS5代理
|
||||
|
||||
> SOCKS5，本地科学上网代理协议，监听 127.0.0.1:10808，在 Mac Mini、Ubuntu1、Ubuntu2 上正常运行，NAS 上仅本机监听。
|
||||
|
||||
## Overview
|
||||
SOCKS5 代理是一种网络协议，通过 SOCKS 代理服务器转发客户端的网络请求，支持 TCP 和 UDP。本方案中各节点通过 v2rayA 或类似代理客户端在本地启动 SOCKS5 代理服务，供本机应用走科学上网通道。
|
||||
|
||||
## Node Status
|
||||
|
||||
|| 节点 | IP | 端口 | 状态 | FRP 暴露 |
|
||||
|------|-----|-----|------|----------|
|
||||
| Mac Mini M4 | 127.0.0.1 | 10808 | ✅ 正常 | — |
|
||||
| Ubuntu Server 1 | 127.0.0.1 | 10808 | ✅ 正常 | — |
|
||||
| Ubuntu Server 2 | 127.0.0.1 | 10808 | ✅ 正常 | — |
|
||||
| Synology NAS | 127.0.0.1 | 20170 | ❌ 仅本机监听 | 否 |
|
||||
|
||||
## Usage Patterns
|
||||
|
||||
### 终端命令级（ProxyChains）
|
||||
ProxyChains 通过 LD_PRELOAD 劫持 socket 调用，强制任意终端命令走 SOCKS5 代理：
|
||||
```bash
|
||||
# /etc/proxychains4.conf
|
||||
socks5 127.0.0.1 10808
|
||||
|
||||
# 使用
|
||||
proxychains4 curl https://google.com
|
||||
```
|
||||
|
||||
### Git 全局代理
|
||||
Git 不读取系统环境变量，必须显式配置：
|
||||
```bash
|
||||
git config --global http.proxy socks5://127.0.0.1:10808
|
||||
git config --global https.proxy socks5://127.0.0.1:10808
|
||||
```
|
||||
|
||||
### Docker Daemon 代理
|
||||
通过 systemd drop-in 文件注入环境变量：
|
||||
```bash
|
||||
# /etc/systemd/system/docker.service.d/http-proxy.conf
|
||||
[Service]
|
||||
Environment="HTTP_PROXY=socks5://127.0.0.1:10808"
|
||||
Environment="HTTPS_PROXY=socks5://127.0.0.1:10808"
|
||||
```
|
||||
|
||||
### Docker 容器环境变量
|
||||
```bash
|
||||
# 容器内使用 ALL_PROXY 环境变量
|
||||
docker run -e ALL_PROXY=socks5://172.24.0.1:10808 ...
|
||||
```
|
||||
|
||||
## Key Distinction: socks5 vs socks5h
|
||||
- **socks5**：DNS 解析在本地完成，可能 DNS 污染
|
||||
- **socks5h**：DNS 解析由代理服务器完成，防止本地 DNS 污染
|
||||
```bash
|
||||
curl -x socks5h://127.0.0.1:10808 https://google.com
|
||||
```
|
||||
|
||||
## Docker 网络网关 IP
|
||||
Docker 容器内访问宿主机的 IP 不是 127.0.0.1（那是容器自身），而是 Docker 网络网关 IP：
|
||||
- bridge 网络默认：`172.17.0.1`
|
||||
- 自定义网络（如 compose 项目）：`172.24.0.1`
|
||||
|
||||
## Related Concepts
|
||||
- [[透明代理]] — V2RayA 通过 iptables 劫持系统出站流量
|
||||
- [[环境变量代理]] — HTTP_PROXY/HTTPS_PROXY/ALL_PROXY 环境变量
|
||||
- [[Docker Daemon 代理]] — systemd drop-in 方式为 docker pull 配置代理
|
||||
- [[ProxyChains]] — 终端命令级流量劫持工具
|
||||
- [[Git 全局代理]] — Git 专用代理配置
|
||||
|
||||
## Related Entities
|
||||
- [[v2rayA]] — NAS 上的 SOCKS5 代理来源（端口20170）
|
||||
- [[Mac Mini M4]] — SOCKS5 代理节点之一
|
||||
- [[Ubuntu Server]] — SOCKS5 代理节点
|
||||
- [[Synology NAS DS718]] — v2rayA 部署位置（仅本机监听）
|
||||
# SOCKS5代理
|
||||
|
||||
> SOCKS5，本地科学上网代理协议，监听 127.0.0.1:10808，在 Mac Mini、Ubuntu1、Ubuntu2 上正常运行，NAS 上仅本机监听。
|
||||
|
||||
## Overview
|
||||
SOCKS5 代理是一种网络协议，通过 SOCKS 代理服务器转发客户端的网络请求，支持 TCP 和 UDP。本方案中各节点通过 v2rayA 或类似代理客户端在本地启动 SOCKS5 代理服务，供本机应用走科学上网通道。
|
||||
|
||||
## Node Status
|
||||
|
||||
|| 节点 | IP | 端口 | 状态 | FRP 暴露 |
|
||||
|------|-----|-----|------|----------|
|
||||
| Mac Mini M4 | 127.0.0.1 | 10808 | ✅ 正常 | — |
|
||||
| Ubuntu Server 1 | 127.0.0.1 | 10808 | ✅ 正常 | — |
|
||||
| Ubuntu Server 2 | 127.0.0.1 | 10808 | ✅ 正常 | — |
|
||||
| Synology NAS | 127.0.0.1 | 20170 | ❌ 仅本机监听 | 否 |
|
||||
|
||||
## Usage Patterns
|
||||
|
||||
### 终端命令级（ProxyChains）
|
||||
ProxyChains 通过 LD_PRELOAD 劫持 socket 调用，强制任意终端命令走 SOCKS5 代理：
|
||||
```bash
|
||||
# /etc/proxychains4.conf
|
||||
socks5 127.0.0.1 10808
|
||||
|
||||
# 使用
|
||||
proxychains4 curl https://google.com
|
||||
```
|
||||
|
||||
### Git 全局代理
|
||||
Git 不读取系统环境变量，必须显式配置：
|
||||
```bash
|
||||
git config --global http.proxy socks5://127.0.0.1:10808
|
||||
git config --global https.proxy socks5://127.0.0.1:10808
|
||||
```
|
||||
|
||||
### Docker Daemon 代理
|
||||
通过 systemd drop-in 文件注入环境变量：
|
||||
```bash
|
||||
# /etc/systemd/system/docker.service.d/http-proxy.conf
|
||||
[Service]
|
||||
Environment="HTTP_PROXY=socks5://127.0.0.1:10808"
|
||||
Environment="HTTPS_PROXY=socks5://127.0.0.1:10808"
|
||||
```
|
||||
|
||||
### Docker 容器环境变量
|
||||
```bash
|
||||
# 容器内使用 ALL_PROXY 环境变量
|
||||
docker run -e ALL_PROXY=socks5://172.24.0.1:10808 ...
|
||||
```
|
||||
|
||||
## Key Distinction: socks5 vs socks5h
|
||||
- **socks5**：DNS 解析在本地完成，可能 DNS 污染
|
||||
- **socks5h**：DNS 解析由代理服务器完成，防止本地 DNS 污染
|
||||
```bash
|
||||
curl -x socks5h://127.0.0.1:10808 https://google.com
|
||||
```
|
||||
|
||||
## Docker 网络网关 IP
|
||||
Docker 容器内访问宿主机的 IP 不是 127.0.0.1（那是容器自身），而是 Docker 网络网关 IP：
|
||||
- bridge 网络默认：`172.17.0.1`
|
||||
- 自定义网络（如 compose 项目）：`172.24.0.1`
|
||||
|
||||
## Related Concepts
|
||||
- [[透明代理]] — V2RayA 通过 iptables 劫持系统出站流量
|
||||
- [[环境变量代理]] — HTTP_PROXY/HTTPS_PROXY/ALL_PROXY 环境变量
|
||||
- [[Docker-Daemon-Proxy]] — systemd drop-in 方式为 docker pull 配置代理
|
||||
- [[ProxyChains]] — 终端命令级流量劫持工具
|
||||
- [[Git 全局代理]] — Git 专用代理配置
|
||||
|
||||
## Related Entities
|
||||
- [[v2rayA]] — NAS 上的 SOCKS5 代理来源（端口20170）
|
||||
- [[Mac Mini M4]] — SOCKS5 代理节点之一
|
||||
- [[Ubuntu Server]] — SOCKS5 代理节点
|
||||
- [[Synology NAS DS718]] — v2rayA 部署位置（仅本机监听）
|
||||
|
||||
45
wiki/concepts/SymbolicLink.md
Normal file
45
wiki/concepts/SymbolicLink.md
Normal file
@@ -0,0 +1,45 @@
|
||||
---
|
||||
title: "SymbolicLink"
|
||||
type: concept
|
||||
tags: [filesystem, macos, linux, unix]
|
||||
sources: [macos-创建与解除-symbolic-link-openclaw-目录映射]
|
||||
last_updated:
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
Symbolic Link（符号链接，简称 Symlink）是 Unix/Linux/macOS 文件系统中的一种特殊类型文件，它指向另一个文件或目录的路径。访问符号链接时，系统会自动重定向到目标路径。
|
||||
|
||||
## Core Mechanism
|
||||
|
||||
```
|
||||
~/openclaw -> ~/.openclaw
|
||||
```
|
||||
|
||||
符号链接本身只存储目标路径字符串（轻量），不存储实际文件内容。删除符号链接不会影响目标文件/目录。
|
||||
|
||||
## Common Use Cases
|
||||
|
||||
| 场景 | 命令 |
|
||||
|------|------|
|
||||
| 创建目录符号链接 | `ln -s /path/to/target /path/to/link` |
|
||||
| 删除符号链接 | `rm /path/to/link` |
|
||||
| 验证链接存在 | `ls -l ~ \| grep linkname` |
|
||||
| 查看链接目标 | `readlink /path/to/link` |
|
||||
|
||||
## Key Properties
|
||||
|
||||
- **非复制**：符号链接不复制数据，只存储路径引用
|
||||
- **可跨文件系统**：可以指向任意位置的文件或目录
|
||||
- **可链接目录**：目录也可以创建符号链接
|
||||
- **透明访问**：应用程序访问符号链接时无感知重定向
|
||||
- **危险操作**：`rm -rf` 指向目录的符号链接会删除目标数据（注意区分）
|
||||
|
||||
## Relationship to Related Concepts
|
||||
|
||||
- [[目录映射]]：符号链接是实现目录映射的常用手段
|
||||
- [[软链接策略]]：（如存在）符号链接的应用策略层
|
||||
- [[ObsidianVault]]：Obsidian 可通过符号链接访问非标准位置的笔记目录
|
||||
|
||||
## Related Entities
|
||||
- [[OpenClaw]]：通过符号链接将隐藏目录 `~/.openclaw` 映射为可见目录 `~/openclaw`
|
||||
52
wiki/concepts/SyntheticMonitoring.md
Normal file
52
wiki/concepts/SyntheticMonitoring.md
Normal file
@@ -0,0 +1,52 @@
|
||||
---
|
||||
title: "Synthetic Monitoring"
|
||||
type: concept
|
||||
tags: [monitoring, devops, uptime, availability]
|
||||
last_updated: 2026-04-26
|
||||
---
|
||||
|
||||
## Synthetic Monitoring（合成监控）
|
||||
|
||||
**中文名称：** 合成监控 / 主动式可用性监控
|
||||
|
||||
**类型：** 监控方法论
|
||||
|
||||
**别名：**
|
||||
- 合成监控
|
||||
- 主动监控
|
||||
- Blackbox Monitoring
|
||||
- Uptime Monitoring
|
||||
- Ping Monitoring
|
||||
|
||||
---
|
||||
|
||||
## Definition
|
||||
|
||||
合成监控（Synthetic Monitoring）是通过**主动发起模拟请求**（HTTP/DNS/TCP/ICMP）来探测服务端点可用性、响应时间和功能正确性的监控方式，与之对应的是基于真实用户流量的 RUM（Real User Monitoring）。
|
||||
|
||||
**核心特点：**
|
||||
- 不依赖真实用户流量，可在服务上线前发现问题
|
||||
- 覆盖内网/外网所有端点
|
||||
- 支持 TLS 证书到期监控
|
||||
- DNS 解析可用性验证
|
||||
- 细粒度延迟和状态码追踪
|
||||
|
||||
**代表工具：**
|
||||
- **Blackbox Exporter（Prometheus 生态）：** 探测指标暴露到 Prometheus，支持 PromQL 告警规则集成
|
||||
- **Uptime Kuma：** 开源自托管 uptime monitoring，支持 HTTP/TCP/DNS/TLS，历史记录 + 告警通知
|
||||
|
||||
---
|
||||
|
||||
## 与 Real User Monitoring 的区别
|
||||
|
||||
| 维度 | 合成监控 | 真实用户监控 (RUM) |
|
||||
|------|---------|-----------------|
|
||||
| 数据来源 | 模拟探针主动探测 | 真实用户请求 |
|
||||
| 覆盖范围 | 全部端点（含无流量路径） | 仅被访问的路径 |
|
||||
| 时机 | 可在部署前发现问题 | 依赖真实流量触发 |
|
||||
| 适用场景 | 可用性 SLA 保障 | 真实用户体验感知 |
|
||||
|
||||
---
|
||||
|
||||
## Related Sources
|
||||
- [[家庭监控方案-prometheus-grafana-node-exporter-cadvisor-blackbox]]
|
||||
Reference in New Issue
Block a user