Prometnehs 告警规则如下：
- alert: HostTCPRetransmitsHigh |
Prometheus 监控数据显示： retrans=21736/5m
检查系统上的 网络内核协议栈状态 ，使用工具 nstat ，它能显示网络栈的统计信息，还能通过差值计数快速定位当前发生的异常。默认显示自系统启动以来的所有统计项。
nstat |
使用 bpftrace 跟踪重传发生的端口统计数据
bpftrace -e ' |
使用 bpftrace 实时跟踪指定端口的重传数据
bpftrace -e ' |
BPF(Berkeley Packet Filter) 是由 Berkeley 学院于 1992 年开发的一款，主要用于提高抓包工具的性能。并于 2014 年被重写进 Linux 内核中，可以用于 内核观测、网络诊断、性能观测、安全、Kubernetes 网络治理等方面 。 [1]
BPF 是一种灵活且高效的技术实现，主要由 指令集（Instruction Set） 、 存储对象（Storage Objects maps） 和 帮助函数（Helper Functions） 构成。因为其 虚拟指令集规范（Virtual Instruction Set Specification） ，可以认为 BPF 是一个虚拟机，BPF 运行于 内核模式（Kernel Mode） 。BPF 基于事件（Events）运行： Socket Events 、 Tracepoints 、 USDT Probes、kprobes、uprobes、perf_events.
eBPF 允许 ：
在运行中的内核里插入自己的逻辑
比如：
而且：
无需修改内核源码，只在内核事件点插入逻辑，无需重启系统，是 Linux 内核的动态扩展机制
这是 eBPF 最核心的价值。
eBPF 本质 运行在 Linux 内核中的事件驱动程序 。关键点：
eBPF = Hook + Event + Action
eBPF 的执行流程分六步
编写 eBPF 程序 。例如 把程序挂到 tcp_connect 函数上
SEC("kprobe/tcp_connect") |
编译为 BPF Bytecode(eBPF 虚拟机字节码) 。eBPF 运行的不是机器码，而是 BPF 字节码
clang -> BPF bytecode |
加载到内核 。用户态程序通过 bpf() 系统调用，把字节码加载进内核。
Verifier 验证程序安全 ，这是 eBPF 最重要的机制，用户把程序加载到内核，是极其危险的，它会检查
Attach：把程序挂到事件点 。程序通过 verifier 后，要挂到某个 Hook 点 (Event)，比如
kprobe:tcp_connect ，每次调用 tcp_connect ，就执行 eBPF 程序tracepoint:sys_enter_execve，每次进程执行时触发XDP ，挂到网卡驱动层本质是： Attach = 指定“什么时候执行 eBPF” 。这是 eBPF 的事件驱动核心。
事件发生时，程序运行
Map 是内核（Kernel）与用户态（User Space）之间的通信机制 。eBPF 程序运行在内核，但它不能直接：
所以必须通过 BPF Map 与用户态交换数据。其本质是内核中的 Key-Value 存储。eBPF 程序更新 Map，用户态读取 Map。 Map 是用户态和内核态共享数据桥梁
Hook 点是在内核执行路径中插入的一个触发点或者说在内核某个位置插入 eBPF 程序 。正常内核流程：
事件发生 -> 内核函数执行 |
加上 eBPF 后:
事件发生 -> Hook 点 -> eBPF 程序执行 -> 原逻辑继续 |
不同 Hook 点，看到的数据不同，性能不同，用途不同
open() 、 execve() 等函数，适合 进程行为观测所以： Hook 点 = eBPF 能看到什么、能做什么
tcp_connect 。因为挂在函数入口，所以常用于：tcp_connect(sock, addr) 拿到: socket 信息、目标地址kprobe 用于跟踪内核函数行为 。优点是非常灵活，能挂任意内核函数；缺点是依赖内核函数名，不稳定（不同内核版本可能变），内核升级可能导致 kprobe 失效
bpftrace 是一个基于 BPF 的追踪工具（Trace Tools），提供了高级别的编程能力，同时包含了命令行和脚本使用方式
bpftrace 命令详细帮助文档请查看 man bpftrace，下表列出常用选项和参数
| 选项 | 说明 | 示例 |
|---|---|---|
-l [SEARCH] |
列出匹配的事件（Event/Probe），没有 SEARCH 表达式则列出所有的 Event。SEARCH 支持通配符 |
|
-e 'program' |
跟踪脚本 |
筛选指定的事件
bpftrace -l "tracepoint:*exec*" |
执行以下命令，可以追踪系统中新启动的进程及其参数
bpftrace -e 'tracepoint:syscalls:sys_enter_execve { join(args->argv); }' |
Systems Performance: Enterprise and the Cloud v2
服务器配置如下（32CPU 32G RAM, 无 GPU）：
lscpu | grep NUMA |
模型推荐清单 (纯 CPU 环境)
| 模型名称 | 推荐版本 | 理由 | 内存占用 | 速度预期 |
|---|---|---|---|---|
| DeepSeek-V3 / R1 (Distill) | deepseek-r1:7b 或 14b | 目前最强的推理模型，逻辑能力极佳。 | ~5GB / 9GB, | 极快 / 流畅 |
| Llama 3.1 | llama3.1:8b | 综合素质平衡，适合通用的英文/开发任务。 | ~5.5GB | 极快 |
| Qwen 2.5 (通义千问) | qwen2.5:7b 或 14b | 中文语境支持最好，适合文档处理、后端开发辅助。 | ~5GB / 9GB | 极快 / 流畅 |
| Command R | command-r:35b | 内存极限挑战。适合需要长上下文（RAG）的任务。 | ~20GB | 较慢 |
安装 Ollama
curl -fsSL https://ollama.com/install.sh | sh |
查看 Ollama Service 状态
systemctl status ollama --no-pager |
运行推荐模型 (以 DeepSeek R1 7B 为例)
ollama run deepseek-r1:7b |
(Optional)部署 Open WebUI（原 Ollama WebUI） ，它支持 Docker 部署
services: |
rules |
ansible-core 版本及 Python 版本支持对应关系
| ansible-core Version | Control Node Python | Target Python / PowerShell |
|---|---|---|
| 2.16 | Python 3.10 - 3.12 | Python 2.7 Python 3.6 - 3.12 Powershell 3 - 5.1 |
为了环境部署方便灵活，可以选择使用 python:3.12.3 的 Docker 镜像，以其为基础环境安装 ansible-core 2.16 或者直接使用 ansible 镜像启动。
docker run --rm -it python:3.12.3 bash |
在服务器本地环境部署，如果想要灵活管理配置，也可以使用 pip3 命令安装 ansible
pip3 install ansible |
如此安装的 ansible 默认不加载任何配置文件，此时只需在 ~/.ansible/ 下手动创建 ansible.cfg 即可
[defaults] |
切换到 ~/.ansible/ 目录，再次查看 Ansible 加载的配置，其已经加载了 ~/.ansible/ansible.cfg
ansible --version |
Ansible 主配置文件为 /etc/ansible/ansible.cfg，其中的配置都可以被 ansible-playbook 或者命令行参数覆盖。
ansible 默认会读取环境变量
ANSIBLE_CONFIG指定的配置文件，当前路径下的ansible.cfg，以及用户家目录下的.ansible.cfg，以及/etc/ansible/ansible.cfg作为配置文件，已第一个找到的为准
常用配置说明
| 配置项 | 说明 | 示例 |
|---|---|---|
inventory |
指定 inventory （主机列表）文件的路径，默认为 /etc/ansible/hosts |
|
remote_user |
（未指定用户时）连接远程主机时使用的用户 | |
remote_port |
连接远程主机时使用的(默认)端口 | |
host_key_checking |
默认启用。检查主机密钥可以防止服务器欺骗和中间人攻击。 如果主机重新安装并且在 know_hosts 中拥有不同的密钥，ansible 会提示确认密钥。如果要禁用此行为，可以配置为 False |
|
ask_pass |
默认为 False。当设置为 True 时，ansible 要求输入远端服务器的密码，即使配置了免密登录 | |
log_path |
日志文件，默认 /var/log/ansible.log |
|
pattern |
当没有给出 pattern 时的默认 pattern，默认值是 * 即所有主机 |
配置示例
[defaults] |
默认的 inventory 配置文件路径为 /etc/ansible/hosts，主要用来配置 Managed Hosts 列表 [3]
在命令行中，可以使用选项 -i <path> 指定不同的 inventory 或者可以在 ansible 配置文件 ansible.cfg 中使用指令 inventory 指定 inventory 文件位置。
命令行中可以使用
-i <path1> -i <path2> ...指定多个inventory
inventory 文件支持多种格式，最常见的是 INI 和 YAML 格式。
all : 包含所有主机ungrouped : 包含所有不在其他组（all 除外）中的所有主机。任何一个主机都会至少在 2 个组中，要么 在
all和某个组中，要么 在all和ungrouped组。
parent/child 组，child 组被包含在 parent 组中。:children 后缀配置 parentchildren: 配置 parent
- 任何在
child组中的主机自动成为parent组中的一员- 一个组可以包括多个
parent和child组，但是不能形成循环关系- 一个主机可以在多个组中，但是在运行时，只能有一个实例存在，Ansible 会自动将属于多个组的主机合并。
[webservers] |
... |
范围格式 的第一项和最后一项也包括在内。即匹配
www01和www50
在主机数量较多，或者组织结构较复杂的情况下，使用单个 Inventory 配置文件会导致主机管理较为复杂。将单个 Inventory 配置文件按照项目或者组织或其他规则进行分割会显著降低维护复杂度。
Inventory 多配置文件支持，可以使用以下方法之一
-i <path1> -i <path2> ... 指定多个 inventory/etc/ansible/inventory/），在命令行中使用选项 -i /etc/ansible/inventory/ 或者在 Ansible 配置文件(ansible.cfg)中使用指令 inventory 配置目录。注意事项： Ansible 使用字典顺序加载配置文件，如果在不同的配置文件中配置了
parent groups和child groups，那么定义child groups的配置要先用定义parent groups的文件加载，否则 Ansible 加载配置会报错：Unable to parse /path/to/source_of_parent_groups as an inventory source[4]
group_vars 和 host_vars 目录分别存储组变量和主机变量 [7]注意事项： 组变量和主机变量必须使用 YAML 格式，合法的文件扩展名包括：
.yaml、yml、.json或者无文件扩展名
主机列表中的主机可以单独出现，也可以位于某个或者多个 组([] 开头的行)中
ansible-demo1.local |
连接主机使用的常用配置说明 [6]
| 配置项 | 说明 | 示例 |
|---|---|---|
ansible_host |
远程主机地址 | |
ansible_port |
远程主机端口 | |
ansible_user |
连接远程主机的 ssh 用户 Ansible 默认使用 control node 上执行 ansible 的用户名来连接远程主机 [9] |
|
ansible_password |
连接远程主机的 ssh 用户密码，建议使用 key 连接 | |
ansible_ssh_private_key_file |
连接远程主机的 ssh 私钥文件路径 | |
ansible_become ansible_sudo ansible_su |
用户权限提升 | |
ansible_become_method |
用户权限提升(escalation)的方式 | |
ansible_become_user ansible_sudo_user ansible_su_user |
用户权限提升(escalation)后的用户 | |
ansible_become_password ansible_sudo_password ansible_su_password |
sudo 密码(这种方式并不安全,强烈建议使用 --ask-sudo-pass) |
|
ansible_become_exeansible_sudo_exe ansible_su_exe |
设置用户权限提升(escalation)后的可执行文件 | |
ansible_connection |
与主机的连接类型.比如:local, ssh 或者 paramikoAnsible 1.2 以前默认使用 paramiko。1.2 以后默认使用 smart,smart 方式会根据是否支持 ControlPersist, 来判断 ssh 方式是否可行. |
|
ansible_shell_type |
目标系统的 shell 类型.默认情况下,命令的执行使用 sh 语法,可设置为 csh 或 fish. |
|
ansible_python_interpreter |
目标主机的 python 路径 系统中有多个 Python, 或者命令路径不是 /usr/bin/python |
Loki 是 Grafana 体系里的日志聚合系统，设计思路和 Prometheus 很像，但处理对象是日志。它和传统全文检索型日志系统的最大区别是： 默认只索引标签（labels），不索引整条日志正文 ，所以存储成本通常更低，扩展性也更好，特别适合 Kubernetes、Docker、主机系统日志、应用日志统一汇聚场景。
截至 2026-04-16，Promtail 已经 EOL，新的采集端优先建议使用 Grafana Alloy ；另外，Loki 本身不内置认证层，生产环境应放在 Nginx 等反向代理或网关之后。
它的典型链路是：
日志源 → 采集器（Alloy）→ Loki → Grafana 查询与展示
其中：
Loki 核心架构逻辑上常见有这些组件：
标签设计建议
Loki 的性能很大程度取决于标签设计，因此标签设计非常关键。
建议保留低基数标签 ：
不要把高基数内容做成标签 ：
官方文档强调 labels 是 Loki 的核心组织方式，但标签过多、基数过高会带来性能和成本问题。
services: |
主配置文件 /etc/loki/config.yaml 内容参考：
auth_enabled: false |
Alloy 配置文件参考：
logging { |
启动成功后，在 Grafana 中添加新的 Data Source。即可在 Grafana 中查看到日志。
以下配置适用于单机、单副本、本地文件系统、保留 7 天数据的 Liki
auth_enabled: false |
Alloy 配置文件本质上是在描述一条 数据流水线
Alloy 的配置语法由两类基础元素组成：attributes（属性） 和 blocks（块） 。属性用 key = value 赋值，块用来定义组件实例和嵌套配置。
Alloy 官方把一些顶层块称为 configuration blocks ，它们用于配置 Alloy 进程本身，不是在采集业务日志或者输出日志。比如：
loggingtracinghttplivedebuggingimport.*Linux 下 Alloy 默认配置文件路径是 /etc/alloy/config.alloy
logging { # 配置 Alloy 自己的日志 |
可以把 Alloy 理解成 组件图 。比如上面的配置链路：
discovery.docker (用于 Docker 目标发现)去发现 Docker 容器loki.source.docker 读取这些容器的日志，并转发给其他 loki.* 组件loki.write 把日志发给 Loki，用于接收日志并通过 Loki logproto 发往远端 Loki如果不是采集 Docker，而是采集文件日志，这时通常会用：
loki.source.filelocal.file_matchloki.source.file "files" { |
Grafana 是一款用 GO 语言开发的开源数据可视化工具，可以做数据监控和数据统计，带有告警功能。
Organization 相当于一个 Namespace，一个 Organization 完全独立于另一个 Organization，包括 datasource、dashboard 等，创建一个 Organization 就相当于打开了一个全新的视图，所有的 datasource、dashboard 等都需要重新创建。一个用户(User) 可以属于多个 Organization。
User 是 Grafana 里面的用户，用户可以有以下 角色
admin - 管理员权限，可以执行任何操作。editor - p不可以创建用户、不可以新增 Datasource、可以创建 Dashboard**viewer - 仅可以查看 Dashboardread only editor - 允许用户修改 Dashboard，但是 不允许保存Grafana 中操作的数据集、可视化数据的来源
在 Dashboard 页面中，可以组织可视化数据图表。
Panel - 在一个 Dashboard 中，Panel 是最基本的可视化单元。通过 Panel 的 Query Editor 可以为每一个 Panel 添加查询的数据源以及数据查询方式。每一个 Panel 都是独立的，可以选择一种或者多种数据源进行查询。一个 Panel 中可以有多个 Query Editor 来汇聚多个可视化数据集Row - 在 Dashboard 中，可以定义一个 Row，来组织和管理一组相关的 Panel在 Dashboard 的设置页面中，有 Variables 页面，在其中可以为 Dashboard 配置变量，之后可以在 Panel 的 Query Editor 中使用这些预定义的变量。变量的值也可以是通过表达式获取的值。也可以在 Panel 的标题中使用变量
例如以下 Variables 配置
Node label_values(kubernetes_io_hostname) |
在 Dashboard 中定义了这些变量后，可以在 Panel 的 Query Editor 中使用，在 Query Editor 中使用了 Variables 中定义的变量后，在 Dashboard 的顶部下拉菜单中可以选择预定义的变量的值（需要在定义 Variables 时配置 Show on dashboard 为 Label and Value 以使在 Dashboard 顶部显示下拉菜单），Panel 中的 Query 表达式就会使用这些变量的值进行计算以及显示图表。
在 Docker 以及 Docker Compose 容器化场景下，监控不能只看容器活着没，而要覆盖以下 5 个层面：
stdout/stderr 、应用日志、错误日志、访问日志核心原则：
基础监控栈
日志栈
应用 Exporter（按需加）
promtail 和 fluentbit , filebeat 比较
| 工具 | 核心定位 | 特点 |
|---|---|---|
| Promtail | Loki 专用日志采集器（强绑定 Grafana 生态） | 只服务 Loki 配置简单 强依赖 label（标签体系） 与 Grafana 联动极好 基本不通用 |
| Fluent Bit | 轻量级、高性能日志采集/转发器（云原生首选） | 云原生事实标准、CNCF 项目（和 Kubernetes 生态融合好） 插件体系强、最通用、最灵活 支持输出到： - Loki - Elasitcsearch - Kafaka - S3 - Opensearch - ClickHouse - HTTP |
| Filebeat | ELK 生态日志采集器（Elastic 官方） | 深度集成 Elasticsearch + Logstash + Kibana 内置大量 module（nginx、mysql、system 等） 优势：开箱即用、解析能力强 劣势：资源占用较高、生态绑定严重 |
promtail 和 fluentbit , filebeat 性能比较
| 项目 | Promtail | Fluent Bit | Filebeat |
|---|---|---|---|
| 内存占用 | ⭐⭐ | ⭐⭐⭐⭐（最低） | ⭐ |
| CPU 占用 | ⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐ |
| 吞吐能力 | 中等 | ⭐⭐⭐⭐（非常高） | 较高 |
| 启动速度 | 快 | ⭐⭐⭐⭐ | 较慢 |
| 高并发日志 | 一般 | ⭐⭐⭐⭐ | 较好 |
promtail 和 fluentbit , filebeat 日志处理能力（解析/清洗）
| 能力 | Promtail | Fluent Bit | Filebeat |
|---|---|---|---|
| 正则解析 | ✔️ | ✔️ | ✔️ |
| JSON解析 | ✔️ | ✔️ | ✔️ |
| Pipeline处理 | ⭐⭐ | ⭐⭐⭐⭐ | ⭐⭐⭐⭐ |
| Lua/扩展脚本 | ❌ | ✔️ | ✔️（processor） |
| 复杂ETL能力 | 弱 | 强 | 很强 |
Grafana 集成的 Alertmanager 还是 Prometheus 集成的 Alertmanager ？
👉 优先选择：Prometheus 原生 Alertmanager（强烈推荐）
👉 Grafana Alerting 适合作为补充，而不是主告警系统
两种架构对比
| 维度 | Prometheus + Alertmanager | Grafana Alerting |
|---|---|---|
| 架构职责 | 清晰（采集 / 存储 / 告警分离） | 混合（Grafana 做太多） |
| 解耦程度 | ⭐⭐⭐⭐ | ⭐⭐ |
| 稳定性 | ⭐⭐⭐⭐（生产级） | ⭐⭐⭐ |
| 可控性 | ⭐⭐⭐⭐ | ⭐⭐⭐ |
| 学习成本 | ⭐⭐⭐ | ⭐⭐ |
| 多数据源支持 | ❌（只 Prometheus） | ⭐⭐⭐⭐ |
| UI 操作 | ❌（写 YAML） | ⭐⭐⭐⭐ |
| 运维规范性 | ⭐⭐⭐⭐ | ⭐⭐ |
Prometheus Alertmanager 的优势（重点）
✅ 1）真正的 运维级告警系统
👉 职责清晰、可控性强
✅ 2）强大的告警路由能力
Alertmanager 支持：
👉 Grafana 很难做到同级别复杂度
✅ 3）抗压能力强（生产关键）
Prometheus + Alertmanager：
👉 不会因为 Grafana 挂掉导致告警失效
✅ 4）支持大规模告警治理
例如：
👉 Prometheus 体系更成熟
✅ 5）行业标准
几乎所有生产环境：
👉 都是 Prometheus + Alertmanager
✅ 5）版本/状态管理
Grafana Alerting 的优势
✅ 1）支持多数据源告警（最大优势）
Grafana 可以对：
统一做告警
👉 Prometheus 做不到
✅ 2）UI 配置（非常友好）
✅ 3）适合日志告警
比如：
👉 Prometheus 不擅长日志
✅ 4）适合小团队
监控 Docker Engine，可以开启 Docker daemon metrics
{ |
重启 Docker
systemctl restart docker |
Prometheus 增加抓取 Docker Daemon Metrics：
- job_name: docker-daemon |
这样能看到：
cAdvisor（Container Advisor）主要负责：
👉 不负责：
cAdvisor 推荐作为一个独立的监控容器运行，最小可用 docker-compose.yml 参考
|
/var/lib/docker 用来读取容器元数据（必须）/sys ,/proc 获取 cgroup 和资源统计/var/run 读取 Docker socket 信息privileged: true 解决权限问题（生产建议保留）/dev/kmsg 采集 kernel 相关指标（可选但推荐）启动 cAdvisor 并通过 http://<host-ip>:8080 或 http://<host-ip>:8080/metrics 验证是否能看到:
在 Prometheus 中使用以下配置接入：
scrape_configs: |
user nginx nginx; |
Kasm Workspaces 是在浏览器里运行完整应用/桌面/浏览器的 云工作空间平台
你会看到：
Kasm 的核心能力
services: |
启动后，首先使用 https://<IP>:3000 进行初始化，初始化时需要设置管理员账号密码信息。初始化成功后，通过 https://<IP>:443 连接 Workspaces。
默认大多数的 Workspace 容器启动时都是没有中文输入的。如果要提供中文输入，可以使用系统提供的 IME Input Mode 。它可以将本地电脑的输入映射到 Kasm Workspaces 中。只需在对应的 Workspace 中开启 IME 配置即可。
使用管理员登录 Kasm。定位到 Workspaces ，编辑对应的 Workspace（如 Kali Linux），找到 Docker Run Configuration Override (JSON)
填入以下内容(如果有其他内容，插入以下内容)，开启 IME
{ |
销毁之前的 Workspace Session，运行新的 Workspace Session，打开左侧的配置菜单，找到 Advanced Settings ，将 IME Input Mode 配置为 On
即可在 Workspace 中使用中文
在 Kasm 中，实现 Workspace 用户数据（如 Chrome 书签、桌面配置、文档等）持久化的标准方案是使用 Persistent Profiles（持久化配置层） 。
核心原理
Kasm 会将容器内的用户目录（通常是 /home/kasm ）映射到宿主机的特定路径（即 docker-compose.yaml 中定义的 /profiles 目录）。当用户结束会话时，Kasm 会将该目录打包；下次启动时，再自动解压回容器。
开启 Persistent Profiles
docker-compose.yaml 中，已经配置了持久化卷 /opt/kasm-workspaces/profiles:/profiles ，这表示所有持久化数据将保存在宿主机的 /opt/kasm-workspaces/profiles 目录下。[email protected] （管理员账户）登录。local-storageCustom 。/profiles{ |
local-storage 并添加
/profiles/{user_id} ，启用 Enforce Workspace Persistent Profile
Kasm 会自动将
{user_id}替换为登录用户的 ID（例如 admin ）。这样即便有多个用户，他们的数据也会分开放，互不干扰。
/opt/kasm-workspaces/profiles/ 中是否有文件存在。配置了 Persistent Profile 后，在 Kasm Workspaces 中启动 Session 也会显示已经启用了 Persistent Profile
在每台节点机器上使用本文档的目录结构，通过 Docker Compose 以 Host Network 模式部署 OpenSearch 3 节点集群，并启用 OpenSearch Security + TLS（HTTP 与 Transport 双层 TLS）。
规划如下信息如下：
opensearch-1：172.16.10.72 ,配置 32 vCPU， 32G RAM
opensearch-2: 172.16.10.70
opensearch-3: 172.16.10.71
集群名：opensearch-prod
角色 ：3 台节点都同时作为
这样 3 节点具备仲裁能力，任意挂 1 台仍可工作。
Docker Host Network 模式会直接占用宿主机端口：
92009300生产建议（需要你在系统层面自行设置）：
echo "vm.max_map_count=262144" | sudo tee -a /etc/sysctl.conf ，执行命令 sudo sysctl -p 生效nofile >= 65536bootstrap.memory_lock: true，确保 memlock 相关限制满足sudo swapoff -a创建持久化数据目录：
mkdir -p /opt/opensearch-cluster |
整体目录结构如下：
. |
通用的 Docker Compose 配置
services: |
Zabbix 支持 TimescaleDB 作为 PostgreSQL 扩展，用于大规模时间序列数据。
TimescaleDB 不支持给 Zabbix Proxy 当数据库 ，只能给中心 zabbix-server 的 PostgreSQL 后端使用。
Zabbix 7.0.6 开始把 TimescaleDB 最大支持版本提升到 2.17.x，7.0.13 提升到 2.19.x。
目录结构示例：
. |
.env 内容参考
TZ=Asia/Shanghai |
initdb 中的初始化 SQL
DO |
CREATE EXTENSION IF NOT EXISTS timescaledb CASCADE; |
GRANT ALL PRIVILEGES ON DATABASE zabbix TO zabbix; |
Postgresql 主配置 config/postgresql.conf
listen_addresses = '*' |
config/pg_hba.conf 配置示例
# TYPE DATABASE USER ADDRESS METHOD |
docker-compose.yaml 配置示例
services: |
以下命令可以用于在 Zabbix Server 检查到 Zabbix Agent 的连通性，连接 Agent 正常会返回 1
docker compose exec -T zabbix-server zabbix_get -s 172.247.1.1 -p 10050 -k agent.ping |
如果防火墙已经放通，却依然无法连接，很可能是 zabbix-agent2 配置中的 Server= 配置的 IP 不是 Zabbix Server 实际使用的 IP。此时可以通过 tcpdump 抓包确定请求 Zabbix Agent 的 Zabbix Server IP
tcpdump -n dst port 10050 |
也可查看 zabbix-agent2 日志：
tail -f /var/log/zabbix/zabbix_agent2.log |
为了将不同的告警发送给不同的用户，首先需要为每个用户添加 Media，以 Admin 用户为例，为其添加 Media。定位到 Users -> Users: Admin -> Media -> Add ，以添加 Telegram 为例，在 Send to 中填入 群组 ID
配置 Medias 。定位到 Alerts -> Media types 。Zabbix Server 已经配置了非常多可用的告警 Medias，选择 Telegram，将 api_token 修改为你自己的 Telegram Bot API Token，确保配置中的 api_chat_id 的值为 {ALERT.SENDTO}
不要在这里硬编码
api_chat_id，否则使用 Telegram 这个渠道只能将所有的消息发送到同一个群组，无法达到告警分流的作用，正确做法是将其配置为{ALERT.SENDTO}，当用户 Media 被调用时，会自动使用用户 Media 变量Send to的值达到告警分流到不通用户的 Media
创建 Actions 触发发送告警 。告警 Medias 配置好后，需要创建一个 Action（或修改默认的），以决定什么时候触发告警
定位到 Alerts -> Actions -> Trigger actions 。配置 Action
配置 Operations 发送消息。在 Alerts -> Actions -> Trigger actions -> Action: Operations 中配置
确定 Actions Trigger ，在 Monitoring -> Problems 中观察具体告警中的 Actions，看是否有关联，如果 Actions 为空，说明Action 根本没有被触发 ，检查 Action 配置
如果 Problems 中的事件是在创建 Action 之前产生，那么它不会自动关联到新建的 Actions。此时可以 Update problems，将其关闭（Close），使其重新产生， Action 配置正常的话，会自动关联到 Action。
Zabbix 告警默认只会发送一次，（未恢复）不会持续发送。要配置未恢复的问题间隔几分钟后再次发送。可以参考以下配置：
Default operation step duration = 5m |
在 Zabbix Server 测试主机连通性返回 1 ，说明 网络 + agent 都是 OK 的
root@zabbix:/opt/zabbix# docker compose exec -T zabbix-server zabbix_get -s 172.17.0.1 -p 10050 -k agent.ping |
但是 Zabbix Web 中主机状态显示 Unknow 。这种情况大概率是 Host 配置问题，重点检查：
Playbooks 使用 YAML 语法定义（描述）。一个 playbook 由一个或多个 play 依序组成。每个 play 运行一个或多个 task，每个 task 也称为一个 module
每一个 play 中包含了一个 tasks 列表，tasks 列表中的每个 task 在其对应的 hosts 上 依次执行。即一个 task 执行完毕，下一个 task 才会执行。
在运行 playbook 的过程中，如果一个 host 执行 task 失败，这个 host 将从整个 playbook 中移除。如果发生执行失败的情况，需要修正 playbook 中的错误，重新执行。
Ansible playbook 示例：
--- |
一个 Ansible playbook 由一个或多个 plays 组成，每个 play 包含以下部分：
name : 描述性的名称hosts : 指定目标主机， 必须字段become : 提升权限（默认是使用 sudo 提升到 root 用户）remote_user : 用于连接到远程主机的账户。(如果 Inventory 中定义了远程连接的用户，会覆盖此处的配置)tasks : 要执行的一系列任务列表vars : 用于定义变量，便于管理和重用gather_facts : 收集 Facts， 默认值为 yestasks 是一个任务列表，每个任务执行特定的操作。任务包含以下元素：
name : 描述任务的目的。module_name : Ansible 模块名称，如 apt、service 等。module_options : 模块的参数，以键值对的形式提供。when : 条件语句，控制任务是否执行。loop : 循环执行任务执行以下命令运行 playbook.yml
ansible-playbook playbook.yml -f 10 |
常用选项说明
| 选项 | 说明 | 示例 |
|---|---|---|
-f--forks |
指定并发执行的数量，默认为 5 | |
-v--verbose -vvvvvv |
打印 debug 信息，详细程度从 -v 到 -vvvvvv |
|
-C--check |
Check mode，不执行任何实际操作，而是对要执行的操作进行验证 |
|
-D--diff |
- 只使用 --diff 会执行 play 定义的实际操作，并对所有受影响的文件或者模板显示其变更前后的具体差异- 和 --check 一起使用，不会执行 play 定义的实际操作，只显示变更前后的差异，可以在实际执行前，调试/预览将要进行的变更，防止意外配置变更或文件修改主要用于文件或者模板的变更，对于其他类型的任务（如包安装、服务管理、修改主机名等），不会显示具体的差异（ 配合 --check 使用时，结果会显示为 skipping，实际执行时结果为 changed ）。 |
|
--list-hosts |
不执行任何实际操作，只列出符合 pattern 的目标主机 |
|
--list-tasks |
不执行任何实际操作，只列出将要执行的 task |
|
--syntax-check |
不执行任何实际操作，只检查 playbook 文件是否有语法错误 | |
-i INVENTORY, --inventory INVENTORY, --inventory-file INVENTORY |
在 ansible-playbook 命令行中指定使用那个 Inventory 文件 |
|
-l SUBSET, --limit SUBSET |
只能在 playbook 已经选定的 hosts 范围内做进一步过滤 |
nftables 是一个 netfilter 项目，旨在替换现有的 {ip,ip6,arp,eb}tables 框架，为 {ip,ip6}tables 提供一个新的包过滤框架、一个新的用户空间实用程序（nft）和一个兼容层(iptables-nft)。它使用现有的钩子、链接跟踪系统、用户空间排队组件和 netfilter 日志子系统。
在 Linux 内核版本高于 3.13 时可用
它由三个主要组件组成：
netlink 配置接口以及运行时规则集评估libnl netlink : libnl 包含了与内核通信的基本函数nftables : 用户空间前端。nftables 的用户空间实用程序 nft 评估大多数规则集并传递到内核。规则存储在链中，链存储在表中。与 iptables 不同点
nftables 在用户空间中运行，iptables 中的每个模块都运行在内核（空间）中nftables 中，表是没有特定语义的链的容器。iptables 附带了具有预定义数量的基链的表，即使您只需要其中之一，所有链都已注册，未使用的基础链也会损害性能。iptables 中，您只能指定一个目标。这是一个长期存在的局限性，用户可以通过跳到自定义链来解决，但代价是使规则集结构稍微复杂一些。nftables 中，这些是可选的，因此您可以按需启用计数器。由于 iptables 内置了一个数据包计数器，所以即使这些内置的链是空的，也会带来性能损耗nftables 中，如果添加新规则，则剩余的现有规则将保持不变，因为规则集以链表形式表示，这与整体式 blob 表示相反，后者在执行规则集更新时内部状态信息的维护很复杂。inet 系列，可让您注册同时查看 IPv4 和 IPv6 流量的基链。 因此，您不再需要依赖脚本来复制规则集。服务名称默认为 nftables，默认配置文件为 /etc/nftables.conf ，其中已经包含一个名为 inet filter 的简单 ipv4/ipv6 防火墙列表。
!/usr/sbin/nft -f |
nftables 服务的 systemd 配置文件如下：
[Unit] |
nftables 使用的内核模块如下，加载这些模块，服务才能正常运行
lsmod | grep nf |
nftables 在启动时（执行
nft -f /etc/nftables.conf）是顺序解析的。在使用了include动态加载set(集合)的场景中， 如果它解析主配置文件没问题，但是子配置（include文件）有语法错误，可能会出现主配置加载成功并已经应用，但是子配置未加载导致规则不全 ，因此建议修改nftables服务的启动流程，启动之前首先检查所有的配置文件（nft -c -f /etc/nftables.conf），如果配置检查不通过，则不启动。使用
systemctl edit创建一个drop-in覆盖文件，而不是直接修改/lib/systemd/system/nftables.service（这样可以防止系统更新时被覆盖）。
在其中写入以下内容
在执行真正的启动 (ExecStart) 或重载 (ExecReload) 之前，先运行语法检查
注意：这里假设你的主配置文件是 /etc/nftables.conf，如果不是，请替换为实际路径
ExecStartPre=/usr/sbin/nft -c -f /etc/nftables.conf
K3S 是 Kubernetes（K8S）的简化部署版本，日常使用几乎一模一样，差别主要在 安装、资源占用、默认组件 。适合
安装部署非常简单
curl -sfL https://get.k3s.io | sh -s |
安装之后会启动 k3s (systemd service) ，查看服务状态
systemctl status k3s |
K3s 自带的
kubeconfig一般在export KUBECONFIG=/etc/kubernetes/admin.conf，要注意此变量值，否则kubectl可能连接到错误的集群或无法连接
E0325 15:37:50.808781 3442105 memcache.go:265] "Unhandled Error" err="couldn't get current server API group list: the server could not find the requested resource"
E0325 15:37:50.814831 3442105 memcache.go:265] "Unhandled Error" err="couldn't get current server API group list: the server could not find the requested resource"
K3S 依赖宿主机的 /etc/resolv.conf ，如果其中配置了 nameserver 127.0.0.53 会导致容器无法解析外部域名而不可用，需要修改为容器可以访问的 DNS 地址，如 8.8.8.8
nftables 防火墙示例规则参考：
table inet filter { |
dnf install -y https://www.rpmfind.net/linux/centos-stream/9-stream/BaseOS/x86_64/os/Packages/lrzsz-0.12.20-55.el9.x86_64.rpm |
sudo dnf install -y cronie |
dnf install -y docker |
OpenClaw ，包括 OpenCode 等都是是开源社区针对官方 Claude Code 打造的全能型、无限制开源替代方案。
OpenClaw 的运行由三个核心部分驱动：
OpenClaw 依赖 Node.js 22 或更高版本。可以参考以下命令安装 Node.js
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.39.7/install.sh | bash |
安装 OpenClaw，以下两种方式任选其一即可，也可用于升级。
curl -fsSL https://openclaw.ai/install.sh | bash |
初始化与配置 ，安装完成后，你需要运行 onboard 向导来配置 API Key（如 Anthropic, OpenAI 或本地的 Ollama）以及通信渠道。
openclaw onboard --install-daemon |
配置渠道（以 Telegram 为例）
openclaw channels login telegram |
查看 OpenClaw 安装的 Skills
openclaw skills list |
安装完成后，其配置和常用文件位于 ~/.openclaw/
tree .openclaw/ |
AWS OpenSearch 是一个完全开源的搜索和分析引擎，用于日志分析、实时应用程序监控和点击流分析等用例。
AWS OpenSearch（AOS） 和 Elasticsearch 对比
| OpenSearch | Elasticsearch | |
|---|---|---|
| 背景 | AWS 主导的开源分支 | Elastic 公司主导 |
| 授权 | Apache 2.0 | SSPL + Elastic License |
| 商业控制 | 社区驱动 | 公司控制 |
| K8s 生态 | 非常友好 | 也支持 |
| 云原生趋势 | 越来越主流 | 商业版更强 |
| 日志检索 | 很强 | 很强 |
| 向量搜索 | 有 | 更成熟 |
| ML 功能 | 有 | 更强 |
| APM | 基础 | 商业版更强 |
| 插件生态 | 少一些 | 更丰富 |
原本是同一个项目
2021 年因授权问题分叉
👉 7.10 是最后一个纯开源 Elasticsearch 版本
之后 AWS fork 出：
🔹 OpenSearch
而原厂继续发展：
🔹 Elasticsearch
在 AWS 上，Amazon 托管服务默认是 OpenSearch。
OpenSearch 服务域是 OpenSearch 集群的同义词.域是包含您指定的设置、实例类型、实例计数和存储资源的集群。
登录控制台：前往 Amazon OpenSearch Service。 Domains -> Create domain 。
使用 公开访问权限 部署的 AOS，可以直接使用 OpenSearch 控制面板 URL 在互联网访问。如果要控制访问，可以使用以下方法：
修改 集群访问策略 (Access Policy)
IpAddress 的 Condition 。 { |
Node.js 是一个 基于 Chrome V8 引擎的 JavaScript 运行环境，可以让 JavaScript 在服务器端运行 。
Node.js 的核心特点：
npm 是世界最大的包管理平台。wget https://nodejs.org/dist/latest/node-v15.12.0-linux-x64.tar.gz |
安装pm2
npm install pm2 -g |
npm install pm2 |
安装指定版本的包
npm install -g [email protected] |
以 hexo 安装包为例，以下命令查看 hexo 安装包有哪些可选版本
npm show hexo versions |
以下命令可显示安装的包及它们的版本
npm ls |
如果要查看全局类型的包，使用 -g 选项
npm ls -g |
npm uninstall package_name |
卸载全局安装的包
npm uninstall package_name -g |
WARN EACCES user “root” does not have permission to access the dev dir “/root/.node-gyp/11.15.0”
ERR! stack Error: EACCES: permission denied, mkdir ‘node_modules/sqlite3/.node-gyp’
[解决方法]：
npm install --unsafe-perm |
一个 Node 项目通常是：
project |
在 Node.js 生态中，通常有两个 核心基础配置文件
dotenv 库使用。{ |
name & version : 项目名称和版本。发布 npm 包时这是必填的唯一标识。main : 程序主入口，Node 默认的执行文件。scripts : 这是整个配置中最重要的部分。它定义了 快捷命令（命令脚本） ："start": "node app.js" -> 执行 npm start 命令，实际会运行 node app.js 启动程序。"dev": "vue-cli-service serve" -> 执行 npm run dev 命令，会使用 vue-cli-service serve 启动服务dependencies : 行环境必需的包（如 express, mongoose 等）。安装命令：npm install <pkg> 。devDependencies : 仅开发环境需要的包（如 eslint, jest, nodemon ）。安装命令：npm i <pkg> -D 。engines : 指定 Node.js 或 npm 的版本范围，防止因环境版本不同导致代码崩溃。初始化项目 ，会生成 package.json
npm init |
安装依赖
npm install |
启动
node app.js |
如果直接使用 node app.js 这种方式启动，会存在以下问题：
PM2 就是为解决这些问题而生，它是 Node.js 最流行的进程管理工具 。主要负责以下功能：
| 功能 | 说明 |
|---|---|
| 进程守护 | 程序崩溃自动重启 |
| 负载均衡 | Node.js 是单线程的，pm2 可以让其充分利用多核 CPU 实现多进程 |
| 日志管理 | 自动手机程序日志 |
| 开机自启 | 服务器启动自动运行 |
| 性能监控 | CPU/内存 |
| 后台运行 | 让程序以守护进程（Daemon）方式在后台运行 |
PM2 启动程序，假设程序是 app.js
pm2 start app.js --name "app-name" |
查看进程状态
pm2 list |
程序生命周期管理
pm2 start app.js |
查看进程
pm2 list |
日志管理
pm2 logs # 默认日志位置 ~/.pm2/logs |
监控程序，查看 CPU/Memory 实时监控界面
pm2 monit |
配置 pm2 开机自启动
pm2 save # 保存当前进程列表 |
Node.js 是单线程 。PM2 可以启动 多进程利用多核 CPU 。
✔ 提高性能
✔ 提高并发
✔ 程序挂掉自动拉起
集群模式启动命令
pm2 start app.js -i max |
-i max ： 根据 CPU 核心数启动，如 4 vCPU 则启动 4 个 node 进程。生产环境一般使用 ecosystem.config.js 作为 pm2 管理配置文件来管理所有的项目，让你的部署过程 版本化、自动化、可复用 。
module.exports = { |
pm2 start ecosystem.config.js |
使用 PM2 配置文件时，需要注意以下事项：
集群模式（Cluster）与单实例（Fork）
如果你的应用是单机版的，没做多进程适配（例如：在内存里存 Session、使用本地变量计数），开启 instances: max 会导致数据不一致。
生产环境尽量使用 cluster 模式以压榨多核性能，但确保你的应用是 无状态（Stateless） 的。
内存溢出防御
max_memory_restart 。比如你的服务器有 2G 内存，给每个实例设个 800M 左右的阈值，能有效防止全机卡死。避免 无限重启循环
min_uptime （程序运行多久才算启动成功）和 max_restarts （最大重试次数），避免刷爆 CPU 和日志文件。Watch 模式的风险
watch: truewatch 仅建议在开发或测试环境使用。环境变量的优先级
env 变量，直接 pm2 restart 有时是不生效的。pm2 reload <name> --update-env 或直接 pm2 delete 后再重新 start 。环境信息 ：
三台 Rocky9 Linux 服务器, 配置为 4CPU 16G RAM , 内网地址和主机名分别为:
172.31.29.164 vp-elk-1172.31.24.61 vp-elk-2172.31.25.106 vp-elk-3修改系统参数 /etc/sysctl.conf ，Elasticsearch 必须配置：
vm.max_map_count = 262144 |
执行命令 sysctl -p 生效，使用命令 sysctl vm.max_map_count 验证
创建 ELK 目录
mkdir -p /data/elk |
目录结构如下：
/data/elk |
因为要开启集群安全认证（X-Pack Security） xpack.security.enabled: true ，就必须为节点之间的通信配置 Transport 层 TLS 加密 ，否则 ES 会拒绝在生产模式下启动。
证书可以选用以下两种方式之一
生成集群证书（仅在一个节点上操作即可） 。利用 ES 自带的工具生成 CA 和节点证书，每个节点有自己的证书。
cd /data/elk |
创建 实例配置文件，比如 config/certs/instances.yml 用来为节点生成证书
instances: |
使用实例配置文件，比如 config/certs/instances.yml 生成节点证书
docker run --rm \ |
解压证书文件，获得节点证书，文件结构如下：
tree |
生成 p12 类型的节点证书
生成 config/instances.yml
instances: |
生成 CA
cd /data/elk |
会生成无密码的 config/certs/elastic-ca.p12 CA 证书文件，接着使用 CA 根证书生成节点证书，使用 config/instances.yml 配置证书中包含的 SAN
docker run --rm -v ./config/certs:/certs docker.elastic.co/elasticsearch/elasticsearch:8.12.2 \ |
会生成 ./config/certs/elastic-certificates.p12 ，这实际上是个 zip 压缩文件，要解压后获得各个节点的证书
可以通过以下方式检查证书中的 SAN 信息
# cd config/certs/ |
生成证书后，将证书文件分发到其他两个节点上。
Elasticsearch 集群配置文件 ./config/elasticsearch.yml ， 每个节点都要配置 ，修改 node.name 为对应的节点名称； 修改证书路径为对应节点的证书
cluster.name: vp-elk-cluster |
Kibana 配置文件 config/kibana.yml ，只需要在一个节点上配置即可。
server.name: kibana |
Docker Compose 配置文件 docker-compose.yml ，3 台 ES 节点使用同样的配置即可， ES 配置在配置文件在每个节点的 config/elasticsearch.yml 中 。Kibana 只需要在一台服务器部署即可。
services: |
启动
docker compose up -d |
为 elastic 等用户重置密码
docker compose exec -it elasticsearch bin/elasticsearch-setup-passwords interactive |
重置 elastic 用户密码
docker compose exec elasticsearch bin/elasticsearch-reset-password -u elastic |
首先确认节点是否全部加入集群。
GET / |
检查集群健康状态
GET /_cluster/health?pretty |
检查节点状态
GET /_cat/nodes?v |
检查节点角色
GET /_cat/nodes?v&h=name,ip,node.role,master |
m masterd datai **ingest检查分片分布
GET /_cat/shards?v |
检查索引状态
GET /_cat/indices?v |
检查 Master 选举
GET /_cat/master?v |
只有一个 Master 就正常
检查 JVM Heap
GET /_cat/nodes?v&h=name,heap.percent |
检查磁盘使用情况
GET /_cat/allocation?v |
检查线程池情况
GET /_cat/thread_pool?v |
关注 queue、rejected > 0 ，说明集群过载
检查 Pending Tasks
GET /_cluster/pending_tasks?pretty |
检查证书
GET /_ssl/certificates |
查看集群的全局配置
GET /_cluster/settings?include_defaults |
这会输出 Elasticsearch 集群的所有配置，包括默认配置。
查看模版配置
GET /_index_template?pretty |
其中可以查看 number_of_shards ， number_of_replicas ，默认值都是 1
在 Docker 中 几乎 90% 是被系统 OOM Killer 杀掉（内存不够）。重点检查 mem_limit: 8g ， 和 ES_JAVA_OPTS=-Xms8g -Xmx8g
适用版本信息说明
- filebeat 7
- elasticsearch 7
filebeat 7.5.2 上传数据到 Elasticsearch 报错：
journalctl -f -u filebeat |
此错误原因是由于 Elasticsearch 的集群中打开的分片数量超过了集群的最大分片限制。在 Elasticsearch 中，每个索引由多个分片组成，而集群有一个设置的最大分片数限制。这个限制是为了防止分片数过多导致性能问题。
错误消息 {"type":"illegal_argument_exception","reason":"Validation Failed: 1: this action would add [2] total shards, but this cluster currently has [6924]/[3000] maximum shards open;"} 显示当前集群已有 6924 个分片，超过了 3000 个的限制。
要解决这个问题，可以考虑以下几个选项：
调整 Elasticsearch 集群设置，增加最大分片数限制
可以通过更改 Elasticsearch 配置来增加最大分片数的限制。但请注意，这可能会导致性能问题，尤其是如果硬件资源有限的话。
这可以通过修改 cluster.max_shards_per_node 设置来实现
PUT /_cluster/settings |
获取 Elasticsearch 集群的最大分片数限制
curl -X GET "http://[your_elasticsearch_host]:9200/_cluster/settings?include_defaults=true&pretty" |
删除一些不必要的索引 :如果有些索引不再需要，可以删除它们来减少分片数。
curl -X DELETE "localhost:9200/my_index" |
合并一些小索引：如果有很多小的索引，可以考虑将它们合并为更大的索引，以减少总分片数。
优化现有索引的分片策略：可以优化索引的分片数量，例如，通过减少每个索引的主分片数量。
适用版本信息说明
- filebeat 7
- elasticsearch 7
使用以下 filebeat 配置文件
filebeat.inputs: |
filebeat 启动后报错，elasticsearch 上未创建相应的索引，关键错误信息 Failed to connect to backoff(elasticsearch(http://1.57.115.214:9200)): Connection marked as failed because the onConnect callback failed: resource 'filebeat-7.5.2' exists, but it is not an alias
journalctl -f -u filebeat |
这表明 Filebeat 无法正常连接到 Elasticsearch 集群。出现这个问题的主要原因可能为：
索引/别名冲突: Filebeat 试图创建或使用一个名为 filebeat-7.5.2 的索引或别名，但这个资源在 Elasticsearch 中已存在且不是一个别名。解决方法为 删除或重命名冲突索引
ILM 配置问题
使用此配置文件，解决 索引/别名冲突 问题后，filebeat 运行正常，但是 Elasticsearch 上未创建配置中的索引 logstash-admin-*，而是将数据上传到了索引 filebeat-7.5.2-*。这个问题是由 ILM 导致，可以禁用 ILM。参考以下配置，禁用 ILM (setup.ilm.enabled: false)
filebeat.inputs: |