Akemi

纳甲六爻-十二地支的冲合、十二长生

2026-04-30T11:13:00.000Z

十二地支的冲合

需要记忆

相隔六位，互为对角，方向相反所以”冲”。

子午冲，丑未冲，寅申冲，卯酉冲，辰戌冲，巳亥冲
子丑合土，寅亥合木，卯戌合火，辰酉合金，巳申合水，午未合火。

冲：主散开、变动、分离、快、猛
合：主吸引，聚集、绊住、慢、柔、渐进

日月令的冲合

月冲/月破：没有能量，但如果是受日辰生扶，或其他爻生扶那就还有能量
月合：如果是旺相，就是合旺；如果休囚也没有用
日冲/冲起：
如果本身是旺相，就会引发暗动，即变成了动爻；
如果是旺相且旬空，就叫冲空填实；
如果休囚也没有用，有意向但能力不足；
日合：合绊/合旺

例子：

辰月丑日，看未土，得令并日辰生扶（旺相），同时丑未相冲，暗动
辰月丑日，看酉金，被日月相生（旺相），同时辰酉相合，合旺
寅月申日，看申金，月破但日辰生扶，说明这个月没能量了，但出了这个月还有用

旬空/空亡

空亡不主吉凶，仅取向用

表示空心、心里没底、不在、不自信
例
测朋友在不在家，兄弟空亡代表不在家
子孙空亡，说明没有想法

木空则朽，火空则发，土空则崩，金空则鸣，水空则流

旬空/空亡特殊情况-不空

“旺不为空，动不为空，空化空不为空，然则还是空”

“空而旺者，有名无实；空而动者，有始无终”

1.冲空填实
2.独动不空
3.休囚独动，短期不空，长期看还是空

取用神-用神两现（卦象里有两个用神）

1.动爻
2.空亡、月破之爻
3.逢冲、逢合、暗动之爻
4.居世爻、应爻
5.爻位/六神取像
6.兼看

十二长生

十二长生就是从出生到死亡的一整个过程

一般看长生(旺）、淋浴(桃花位）、帝旺(旺）、病(疾病)、死、墓(收/埋)、绝(3个休囚)

3个以上相同的六亲，认为是能量分散，需要入墓

例：
男测感情，妻财与应爻相合、沐浴，断女出轨
绝地，但有动爻生/日辰生扶，断绝处逢生
原神入墓，代表想法被埋了

纳甲六爻-从传统起卦到日月能量

2026-04-30T11:07:00.000Z

传统起卦的过程

六爻
六爻顾名思义一共有六根爻，每次获取爻都是从低到高一共六条
每一根爻都是阴或阳的不同形态：
— — 阴
—— 阳

使用3枚硬币或五铢钱摇卦，根据正反面来确定一根爻

遵循简为阳，繁为阴的原则
即光滑、无文字为阳面、有文字花纹为阴面
根据阴阳的数量来判断一根爻的类型

那么每次扔硬币都有4种状态：
2阴1阳 → ——少阳
2阳1阴 → — —少阴
3阳 → —— x老阳
3阴 → — — o老阴
其中老阴和老阳都是动爻，即发生变化的爻，老阴会变成少阳，老阳会变成少阴

后天八卦

需要记忆

那么一共扔了6次，就会出现上下两个卦，称为本卦
如果有动爻，或者日冲暗动，就会出现变卦
↑
这个过程在六爻排盘软件中可以自动进行，完成后就会给出一个像这样的卦象：

后天八卦的方位

一数坎来二数坤，三震四巽是中分，五数中宫六乾是，七兑八艮九离门。大概是下面这个方位

4 9 2
3 7
8 1 6

十二地支

需要记忆

寅卯辰巳午未申酉戌亥子丑

十二地支也有自己的属性，春季寅辰属木，夏季巳午属火，秋季申酉属金，冬季亥子属水

这里的季节是按照24节气来的：
立春到惊蛰之间 → 寅月（木）
惊蛰到清明之间 → 卯月（木）
清明到立夏之间 → 辰月（带木气的土）

五行生克

需要记忆
木火土金水（相生顺序）
木土水火金（相克顺序）

六亲生克

六亲与五行之间有着类似的生克关系：

父母生兄弟
兄弟生子孙
子孙生妻财
妻财生官鬼
官鬼生父母

六亲的象法
需要理解

父母：父母、长辈、老师、领导；文书、合同、证书、房屋、衣服、车船、信件；操心劳累、保护庇佑、学业文化

兄弟：兄弟姐妹、朋友、同学、同事、合伙人；竞争、争夺、破财损耗、口舌是非；义气帮助（与世爻同五行时）

子孙：子女、晚辈、学生、徒弟、下属；医药、快乐、娱乐、出行；福神解忧、克官鬼（不利求官求名、利于治病）

妻财：妻子、女友、情人、财务人员；钱财、工资、收入、资产、存款、食物、货物；财运进财、物质享受、克父母（不利文书学业）

官鬼：丈夫、官员、领导、上司、警察、法官、小人；官职、工作、官司、疾病、灾祸、压力、忧愁；约束管制、克兄弟（代表灾祸疾病）

旺相休囚死

需要记忆
旺相休囚死是从生克关系得来的一个关系，分为旺相、休囚、死三种状态，分别代表能量高、能量低但有气、没有能量三种能量状态

比如。火在巳午(火)月就是旺，在寅卯(木)月是相，在辰戌丑未(土)月是休，在申酉(金)月是囚，在亥子(水)月是死

月建与日建（月令/日令）能量

不同的日建和月建对不同的爻能量不一样

例：

午月午日，看午火，那就是临月建临日辰，属旺相
巳月寅日，看午火，那就是得月令扶助（得令），得日辰生扶（日辰生爻），属旺相
寅月申日，看子水，那就是被月建泄气（休），得日辰生扶，一得一生，平和状态

卦中的神
用神、原神、忌神、仇神、喜神
表示
我、生我、我生、克我、生克我的爻

一般只看前三个

VMware Workstation安装Openshift多节点

2026-04-17T02:06:00.000Z

宿主机配置要求至少16C64G
梯子要有流量，经过测试单master吃15G流量，3master吃50G

访问并登录https://console.redhat.com/openshift

获取镜像
1.进入界面
选择Resource-Assisted Installer辅助安装器
选择Create Cluster

2.填写基本信息
Cluster name 我写的是wangsheng
Base domain 我写的是ws.com
version选择4.21.9
Number of control plane nodes 选择3

3.直接到Host discovery，点击add hosts
镜像选择Full image
填入本机ssh公钥（作为openshift的ssh公钥
勾选使用代理，填入代理地址
完成后会给出iso下载地址

4.VMware workstation配置安装
创建5台虚拟机配置8C16G内存120G硬盘，网络使用NAT
使用下载下来的iso安装
在每台虚拟机的vmx中添加一行disk.EnableUUID = "TRUE"
开启5台虚拟机

5.继续网页安装
等5分钟，在网页Waiting for hosts中会出现这五台机器
下到第五步，填入两个与节点同网段的VIP
下到第七步，开始安装

6.访问管理面板
会提示要将解析添加到hosts文件中
192.168.8.200 api.wangsheng.ws.com
192.168.8.199 oauth-openshift.apps.wangsheng.ws.com
192.168.8.199 console-openshift-console.apps.wangsheng.ws.com
192.168.8.199 grafana-openshift-monitoring.apps.wangsheng.ws.com
192.168.8.199 thanos-querier-openshift-monitoring.apps.wangsheng.ws.com
192.168.8.199 prometheus-k8s-openshift-monitoring.apps.wangsheng.ws.com
192.168.8.199 alertmanager-main-openshift-monitoring.apps.wangsheng.ws.com

填入kubeadmin及其密码

使用OSS的Milvus-backup数据备份迁移

2026-04-15T10:40:00.000Z

参考文档：https://github.com/zilliztech/milvus-backup/releases

迁移原则：只能低到高，不能高到低；是一种全量备份的工具，需要暂停服务使用

如果需要热备、跨集群容灾或低停机时间迁移，可以结合Milvus CDC使用。参考文档：https://github.com/zilliztech/milvus-cdc

# 二进制安装
wget https://github.com/zilliztech/milvus-backup/releases/download/v0.5.12/milvus-backup_0.5.12_Linux_x86_64.tar.gz
tar -xf milvus-backup_0.5.12_Linux_x86_64.tar.gz
mv milvus-backup /usr/bin/

使用流程

创建backup.yaml，旧集群生成备份
物理数据搬迁，OSS文件从Old Bucket迁移到New Bucket
创建restore.yaml，指向新集群
在新集群执行恢复

环境说明

新milvus环境:
192.168.8.147:19530
oss-cn-beijing.aliyuncs.com
bucketName: "milvus-backup-test"

旧milvus环境:
192.168.10.100:19530
oss-cn-beijing.aliyuncs.com
bucketName: "milvus-wangsheng-test"

数据备份

具体backup.yaml字段格式可以查看https://github.com/zilliztech/milvus-backup?tab=readme-ov-file#backupyaml-configurations

# 创建backup.yaml
milvus:
 address: "192.168.10.100"
 port: 19530
minio:
 storageType: "minio"
 port: "443"
 address: "oss-cn-beijing.aliyuncs.com"
 bucketName: "milvus-wangsheng-test"
 rootPath: "test"
 accessKeyID: "xxxx"
 secretAccessKey: "xxxx"
 useSSL: true
 useIAM: false
 region: "cn-beijing"
backup:
 backuppath: "backup_folder"

# 检查是否可以连接
milvus-backup --config ./backup.yaml check

# 开始备份，会在oss创建名为backup_test_2026的文件夹
milvus-backup --config ./backup.yaml create -n backup_test_2026

...
[2026/04/15 14:08:38.106 +08:00] [INFO] [backup/task.go:261] ["backup successfully"] [task_id=5f2b4c61-c368-423a-aa20-ea442336a9e7]
duration:4.08 s

oss数据迁移-两种方法

这两种方法的最后，都是会在新对象存储的目录下，生成backup_test_2026的目录

1.方法1-使用ossutil搬运
ossutil cp -r oss://milvus-wangsheng-test/test/backup_test_2026 oss://milvus-backup-test/test/

2.方法2-直接在backup.yaml中定义目标s3的位置
milvus:
 address: "192.168.10.100"
 port: 19530
minio:
 # 源Bucket配置
 storageType: "minio"
 port: "443"
 address: "oss-cn-beijing.aliyuncs.com"
 bucketName: "milvus-wangsheng-test"
 rootPath: "test"
 accessKeyID: "xxxx"
 secretAccessKey: "xxxx"
 useSSL: true
 region: "cn-beijing"

 # 备份/目标Bucket配置
 backupAddress: "oss-cn-beijing.aliyuncs.com"
 backupPort: "443"
 backupBucketName: "milvus-backup-test"
 backupAccessKeyID: "xxxx"
 backupSecretAccessKey: "xxxx"
 backupRegion: "cn-beijing"
 backupRootPath: "test"
 backupUseSSL: true
backup:
 backuppath: "backup_folder"
 
milvus-backup create -n backup_2026_direct --config backup.yaml

恢复到新集群

# 创建restore.yaml
milvus:
 address: "192.168.8.147"
 port: 19530

minio:
 storageType: "minio"
 port: "443"
 address: "oss-cn-beijing.aliyuncs.com"
 bucketName: "milvus-backup-test"
 rootPath: "test"
 accessKeyID: "xxxx"
 secretAccessKey: "xxxx"
 useSSL: true
 region: "cn-beijing"

backup:
 backuppath: "backup_folder"
 

# 验证配置文件格式
milvus-backup list --config restore.yaml
>> Backups:
backup_2026_direct
backup_test_2026

↑说明有两个可还原的版本

# 选择恢复
milvus-backup restore -n backup_2026_direct --config restore.yaml
...
duration:42.30 s

测试访问

图形访问测试

docker run -d \
 --name attu \
 -p 8000:3000 \
 -e MILVUS_URL=192.168.8.147:19530 \
 zilliz/attu:latest

业务访问测试

修改代码访问的milvus端点，调用embedding后的向量

milvus_config = {
 "host": "192.168.8.147",
 "port": "19530"
}

VibeCoding改造博客使用Meilisearch搜索框—Openclaw创建多Agent迭代调试

2026-04-09T16:15:00.000Z

测试环境搭建与问题诊断

在上一篇文章中，我们完成了 MeiliSearch 的基础部署和索引创建，但搜索框的下拉显示功能存在问题。为了系统化地解决这个问题，我决定采用 OpenClaw 的三 Agent 协同工作流。

首先创建了测试环境：

目录：/blog-staging（与生产环境隔离）
容器：Docker 运行 nodejs 环境
端口：4000（可通过 localhost:4000 测试）
目标：所有修改先在测试环境验证，再合并到生产环境

OpenClaw 三 Agent 协同工作流设计

我创建了一个专门的 blog-feature-update skill，设计了三 Agent 协同工作流：

工作流架构

代码 Agent：负责修改代码和配置
部署 Agent：负责重新生成博客并重启服务
验证 Agent：负责自动化测试验证功能

每个 Agent 通过文件标志（.flag 文件）进行通信，形成完整的迭代开发循环：

1	用户需求 → 代码Agent → 部署Agent → 验证Agent → 结果反馈

验证 Agent 的自动化测试

为了确保每次修改都能可靠验证，我配置了验证 Agent 使用 Playwright 进行 UI 自动化测试：

中文字体问题：在容器环境中，Playwright 默认不包含中文字体，导致测试截图中的中文显示为方框。通过手动添加 simkai.ttf 字体文件解决：

六轮优化迭代过程

第一轮：修复下拉框显示

问题：API 请求成功（F12 可见），但下拉框不显示结果。

根本原因：JavaScript 数据处理逻辑 bug。searchMeilisearch 函数返回完整 API 响应，而 displayResults 函数期望处理后的数组。

代码 Agent 修复：

// 修复前：返回完整API响应
return data;

// 修复后：返回处理后的hits数组
return data.hits.map(hit => ({
    id: hit.id,
    title: hit.title || hit._formatted?.title || '',
    date: hit.date,
    tags: hit.tags || [],
    url: hit.url
}));

验证结果：✅ 下拉框正常显示搜索结果

第二轮：优化显示格式

用户反馈：下拉框显示格式有问题，包含重复标题行。

原始显示：

k8s证书延长有效期（标题，带超链接）
k8s证书延长有效期（标题） ← 重复行
http://192.168.10.100:4000/posts/K8s-crt/（链接）
2025-02-05 21:42:55（时间）

新需求：

最多显示5个待选项
删除第二行的重复标题
时间+相关性混合排序

代码 Agent 修改：

数量限制：limit: 10 → limit: 5
删除重复：移除 excerpt 相关代码
排序优化：添加 sort: ['date:desc']

技术问题：添加 sort: ['_score:desc', 'date:desc'] 导致 API 返回 0 个结果。

发现：MeiliSearch v0.24.0 不支持 _score:desc 排序参数。

解决方案：只使用 sort: ['date:desc']，依赖默认相关性排序。

优化后显示：

1
2
3

k8s剩余资源计算脚本（标题，带超链接）
http://192.168.10.100:4000/posts/K8s-resource/（链接）
2025-04-08 19:14:34（时间）

第三轮：添加标签显示

用户需求：删除 URL 行和时间行，添加其他字段。

选择：添加标签（tags）字段，因为：

信息价值高
API 已有该字段
格式简洁
用户友好

代码 Agent 修改：

删除 URL 显示代码
删除日期显示代码
添加标签显示逻辑：
- 最多显示3个标签
- 超过3个时显示”等X个标签”
- 无标签时显示”标签: 无”
- 添加 🏷️ 图标前缀

CSS Agent 添加样式：

.meilisearch-suggestion-tags {
    color: #666;
    font-size: 0.75rem;
    line-height: 1.4;
    margin-top: 4px;
}

.meilisearch-suggestion-tags::before {
    content: '🏷️ ';
    margin-right: 4px;
    opacity: 0.7;
}

优化后显示：

1 2	k8s剩余资源计算脚本（标题，带超链接）标签: k8s

第四轮：宽度调整

用户需求：将搜索框和下拉框长度扩展到1.5倍，保持居中。

初始状态：搜索框宽度 202px，容器最大宽度 500px。

第一轮扩展：

容器最大宽度：750px (500px × 1.5)
搜索框最小宽度：600px
结果：644px (3.2倍扩展，超出预期)

用户反馈：太宽了，缩减到400px。

最终调整：

容器最大宽度：400px
搜索框最小宽度：350px
结果：394px (接近400px目标)

第五轮：超链接修复

问题：下拉框中的文章链接点击跳转到无效链接。

根本原因：MeiliSearch 索引中的 URL 字段是旧格式 /posts/K8s-crt/，而实际 Hexo 生成的 URL 格式是 /年/月/日/文章文件名/。

解决方案：在 JavaScript 中动态生成正确的 URL。

代码 Agent 修复：

// 从原始URL提取slug（Hexo使用文件名作为slug）
if (result.url) {
    // 从 /posts/K8s-crt/ 提取 K8s-crt
    const match = result.url.match(/\/([^\/]+)\/?$/);
    if (match) {
        slug = match[1];
    }
}

// 构建Hexo格式URL
if (slug) {
    fullUrl = `/${year}/${month}/${day}/${slug}/`;
}

验证结果：✅ 链接可正常跳转到文章页面

第六轮：视觉标识（最终撤销）

用户需求：在搜索框最左边添加小的黑色放大镜图标。

发现：图标原本就存在，但被 CSS 隐藏：

/* style.css 中的隐藏规则 */
.meilisearch-icon {
    display: none !important;
}

解决方案：移除隐藏规则，设置黑色：

1
2
3

.meilisearch-icon {
    color: #000000;  /* 黑色放大镜 */
}

后续：用户觉得不需要，最终撤销此修改，恢复隐藏状态。

生产环境合并策略

所有功能在测试环境验证通过后，需要合并到生产环境，但要注意关键差异：

API 访问路径差异

测试环境：直接访问 http://114.55.64.10:7700
生产环境：使用 /search 代理路径

API 密钥处理差异

测试环境：前端传递 X-MEILI-API-KEY 头
生产环境：由 Nginx 反向代理自动添加，前端无需传递

合并实施

JavaScript 文件：应用所有功能优化，但保持生产环境的 API 调用方式
CSS 文件：直接复制所有样式优化
主题配置：保持 host: '/search' 设置
测试文章：仅合并《OpenClaw多Agent协同测试》一篇

技术总结与经验

MeiliSearch 版本兼容性教训

问题：v0.24.0 不支持 _score:desc 排序参数
现象：添加该参数导致 API 返回 0 个结果
解决：只使用 date:desc，依赖默认相关性排序
教训：使用开源工具时要关注版本特性差异

三 Agent 协同工作流优势

职责分离：代码、部署、验证各司其职
迭代可靠：验证失败可自动回退重试
通信简单：文件标志通信机制简单可靠
适合复杂任务：多步骤、需要验证的工作流

CSS 布局技巧

组合控制：max-width + min-width 实现弹性宽度
填充容器：width: 100% 确保填满父容器
下拉框同步：left: 0; right: 0; 实现与父容器同宽

Playwright UI 自动化测试价值

真实模拟：完全模拟用户操作流程
问题捕获：及时发现 JavaScript 错误和网络问题
可视化验证：截图提供直观的验证结果
回归测试：确保修改不会破坏现有功能

最终成果与反思

实现的功能

优雅显示：简洁的标题+标签，无冗余信息
智能排序：按相关性+时间混合排序
数量控制：最多显示5个最相关结果
正确链接：动态生成正确的 Hexo 文章 URL
适中宽度：400px 宽度，居中布局
安全访问：通过 Nginx 代理隐藏 API 密钥

vibe coding 工作模式反思

这次实践展示了 vibe coding（与 AI 协同编程）的有效工作模式：

人类角色：提供方向、决策、质量把控
AI 角色：执行具体任务、快速迭代、处理细节
协同关键：清晰的指令、及时的反馈、系统化的工作流

OpenClaw 多 Agent 架构的价值

通过创建 blog-feature-update skill 和三 Agent 工作流，我们实现了：

可复用的流程：类似任务可直接套用此模式
质量保证：自动化验证确保每次修改可靠
效率提升：并行处理代码、部署、验证步骤
文档完整：整个过程有完整记录可供复盘

部署与后续

所有修改已通过 ./hexo.sh 脚本部署到生产环境，包含：

两篇技术文章（本篇及前篇）
完全优化的搜索功能
测试文章验证

搜索功能现在提供优雅、高效的用户体验，同时后台通过系统化的 AI 协作流程保证质量和可靠性。

本文完整记录了 2026年4月9日使用 OpenClaw 三 Agent 协同工作流优化博客 MeiliSearch 搜索功能的详细过程。从工作流设计到六轮优化迭代，展示了如何通过系统化的 AI 协作解决复杂技术问题。

VibeCoding改造博客使用Meilisearch搜索框—iflow创建搜索框

2026-04-09T16:10:00.000Z

k8s部署meilisearch

给公司的公有云部署了一个，挺有意思的，我准备后续给我的博客也用上
官方文档：https://github.com/meilisearch/meilisearch-kubernetes
支持资源清单或helm部署

1	wget https://raw.githubusercontent.com/meilisearch/meilisearch-kubernetes/refs/heads/main/manifests/meilisearch.yaml

几个注意点：

建议加上环境变量 MEILI_MASTER_KEY
调整 NodeSelector、taint
默认使用 emptyDir 作为 tmp 和 data 卷，生产肯定需要改成 pvc

1	kubectl apply -f meilisearch.yaml

docker部署meilisearch

官方文档: https://www.meilisearch.com/docs/resources/self_hosting/getting_started/docker

mkdir /meili_data

docker run -itd --name meilisearch \
 -p 7700:7700 \
 -v /meili_data:/meili_data \
 -e MEILI_MASTER_KEY='MASTER_KEY'\
 getmeili/meilisearch:latest

token暴露问题

部署完成后，我要求 iflow：

在我的博客顶端中间增加一个颜色素、线条细的搜索框
搜索框与 Meilisearch 进行关联，并通过 hexo 主题的配置文件 _config.yaml 配置

但完成后发现一个新问题，就是这样我发起搜索的请求中，会直接带有 master key，这肯定不行

有两种方法可以解决：

使用 master key 向 meilisearch 重新申请一个只有读权限的 key，然后展示这个 key
在 nginx 后端添加新的路由，并且附带 token 转发到本机的 7700 端口

配置nginx

meilisearch 不使用 bearer auth，而是使用特殊请求头 X-MEILI-API-KEY（全大写）

# 添加nginx配置
location /search/ {
    # 将请求转发到本地 7700 端口
    proxy_pass http://127.0.0.1:7700/;

    # 在后端隐式添加 Meilisearch API Key
    proxy_set_header X-MEILI-API-KEY "xxxxxx";

    # 传递其他必要的头信息
    proxy_set_header Host $host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forwarded-Proto $scheme;

    # 限制客户端只能使用 POST 方法
    if ($request_method != POST) {
        return 405;
    }

    # 隐藏真实的后端响应头，防止信息泄露
    proxy_hide_header X-Meilisearch-Stats;
}

nginx -s reload

# 使用curl在云主机内部进行临时测试
curl -X POST 'http://127.0.0.1:7700/indexes/posts/search' \
    -H 'X-Meili-API-Key: xxxx' \
    -H 'Content-Type: application/json' \
    -d '{"q":"k8s","limit":5}'

# 看到已经可以正常访问meilisearch了，因为此时我还没有往里面传数据
{"message":"Index `posts` not found.","code":"index_not_found","type":"invalid_request","link":"https://docs.meilisearch.com/errors#index_not_found"}

创建索引与导入数据

这一步我让 openclaw 给我做了，主要内容如下：

中途我和它还对自动化、索引格式进行了讨论，所以说用 AI 还得懂技术才能用，不然他直接乱创建索引，查询效率就很低了

第一步：验证当前 Meilisearch 状态
# 1. 检查索引列表
curl -X GET 'http://114.55.64.10:7700/indexes' \
    -H 'X-MEILI-API-KEY: xxxxx'

# 2. 查看 posts 索引详情
curl -X GET 'http://114.55.64.10:7700/indexes/posts' \
    -H 'X-MEILI-API-KEY: xxxxx'

第二步：设计数据模型
基于 Hexo 文章结构：

{
    "id": "唯一标识（如文件名哈希）",
    "title": "文章标题",
    "content": "文章纯文本内容",
    "excerpt": "摘要",
    "date": "发布日期",
    "tags": ["标签数组"],
    "categories": ["分类数组"],
    "url": "文章URL"
}

第三步：创建/配置索引（如果需要）
# 如果 posts 索引不存在，创建它
curl -X POST 'http://114.55.64.10:7700/indexes' \
    -H 'X-MEILI-API-KEY: xxxxx' \
    -H 'Content-Type: application/json' \
    -d '{
        "uid": "posts",
        "primaryKey": "id"
    }'

第四步：提取 Hexo 博客文章
扫描 /blog/source/_posts/ 目录的所有 .md 文件
解析每篇文章：
- 提取 frontmatter（标题、日期、标签、分类）
- 提取内容并转换为纯文本
- 生成唯一ID

第五步：批量导入到 Meilisearch
# 分批导入文章数据
curl -X POST 'http://114.55.64.10:7700/indexes/posts/documents' \
    -H 'X-MEILI-API-KEY: xxxxx' \
    -H 'Content-Type: application/json' \
    -d '[{文章1数据}, {文章2数据}, ...]'

第七步：测试和验证
# 测试搜索功能
curl -X POST 'http://114.55.64.10:7700/indexes/posts/search' \
    -H 'X-MEILI-API-KEY: xxxxx' \
    -H 'Content-Type: application/json' \
    -d '{
        "q": "k8s",
        "limit": 5,
        "attributesToRetrieve": ["title", "date", "tags"],
        "attributesToHighlight": ["title"]
    }'

搜索框与下拉框问题

现在搜索框点了没反应，但在 F12 中可以看到接口已经返回了搜索到的文章。

这一步失败了很多次，所以重新创建了一个测试环境 /blog-staging，用 docker 运行 nodejs 环境，挂载我的 staging 环境，并暴露 4000 端口。让小龙虾直接改测试环境，我也可以通过 localhost:4000 做测试。

本文记录了使用 iflow 创建 MeiliSearch 搜索框的初步过程，包括部署、安全配置和索引创建。下一篇文章将详细介绍如何使用 OpenClaw 的三 Agent 协同工作流解决搜索功能的具体问题。

OpenClaw多Agent协同测试

2026-04-09T03:16:00.000Z

这是通过OpenClaw多Agent协同系统自动创建的一篇测试文章。

本文档用于验证多Agent协同工作流程，确保Hexo博客系统能够正确处理通过自动化工具创建的文章。

测试目的

验证OpenClaw多Agent协同系统的文章创建功能
测试Hexo博客系统的Front Matter格式兼容性
确保自动化流程不会破坏现有博客内容

技术细节

创建时间：2026年4月9日 11:16 GMT+8
创建方式：OpenClaw多Agent协同系统
文件位置：/blog-staging/source/_posts/openclaw-agent-test.md
验证方式：hexo clean && hexo g

注意事项

这仅是一篇测试文章，用于验证自动化流程。在实际部署前，请确保所有自动化工具都经过充分测试。

Prometheus使用process-exporter

2026-04-08T09:41:00.000Z

是一种工作在进程层面的exporter

比如k8s集群中，如果节点总是发生不明原因的OOM，在节点监控node-exporter的基础上，就很适合用这种exporter来进行针对性监控

二进制部署

因为我当前的k8s集群是kind，不太适用，如果在k8s内，就可以用daemonset

wget https://github.com/ncabatoff/process-exporter/releases/download/v0.8.1/process-exporter-0.8.1.linux-amd64.tar.gz

tar -xzf process-exporter-0.8.1.linux-amd64.tar.gz
cd process-exporter-0.8.1.linux-amd64/

# 创建配置文件
vim process-conf.yaml
process_names:
 # 监控所有进程
 - name: "{{.Comm}}"
 cmdline:
 - '.+'
 
# 直接运行测试
./process-exporter -config.path process-conf.yaml

# 
cp /root/process-exporter-0.8.1.linux-amd64/process-exporter /usr/local/bin/
cp /root/process-exporter-0.8.1.linux-amd64/process-conf.yaml /etc/process-exporter.yaml

# 没问题，写成systemd接管
cat > /etc/systemd/system/process-exporter.service <<EOF
[Unit]
Description=Process Exporter
After=network.target

[Service]
Type=simple
User=root
Group=root
WorkingDirectory=/root/process-exporter-0.8.1.linux-amd64
ExecStart=/usr/local/bin/process-exporter -config.path /etc/process-exporter.yaml
Restart=always
RestartSec=10
StandardOutput=journal
StandardError=journal

[Install]
WantedBy=multi-user.target
EOF
systemctl daemon-reload
systemctl enable process-exporter.service --now
systemctl is-active process-exporter.service
active

ss -tunlp | grep 9256
tcp LISTEN 0 4096 *:9256 *:* users:(("process-exporte",pid=2440161,fd=3))

添加Prometheus静态抓取配置

我使用的是helm部署的kube-prometheus-stack

# 修改values，添加静态配置
 additionalScrapeConfigs:
 - job_name: 'user-login-monitor'
 static_configs:
 - targets:
 - '192.168.10.100:9092'
 scrape_interval: 30s
 scrape_timeout: 10s
 metrics_path: /
 scheme: http
 - job_name: 'process-exporter'
 static_configs:
 - targets:
 - '192.168.10.100:9256'
# helm更新
helm upgrade --install prometheus ./ -f values.yaml -n prometheus

grafana展示

选择Import dashboard，导入13882

两周复习EFK第八天之Fluentd+Fluent Bit数据清洗

2026-04-03T08:46:00.000Z

Fluentd数据处理模型理论深入

tag与多级tag

tag是Fluentd和fluent bit都有的机制

K8s节点 → Fluent Bit → Fluentd → ES
 ↓ ↓ ↓
 生成Tag 基于Tag路由 基于内容存储
 ↓ ↓ ↓
 kube.** 匹配规则 索引选择
 
第一层：Fluent Bit的Tag路由
# Fluent Bit配置示例
[INPUT]
 Name tail
 Tag kube.nginx # 生成Tag

[OUTPUT]
 Name forward
 Match kube.nginx # 匹配Tag，发送到Fluentd

第二层：Fluentd的Tag路由
# Fluentd配置示例
<source>
 @type forward
 # 接收Fluent Bit发来的数据，保持Tag不变


 # 基于同样的Tag继续路由
 # 深度清洗、字段丰富


 # 更通用的匹配规则
 # 通用处理逻辑

tag分层

1.常见分层模式
kube.nginx.access # K8s中Nginx访问日志
kube.nginx.error # K8s中Nginx错误日志 
kube.system.kubelet # K8s系统组件日志
host.system.ssh # 主机SSH日志
app.payment.api # 应用支付接口日志

2.match匹配规则与方式
Fluentd按配置文件顺序匹配，第一个匹配的规则生效：
所以具体的规则在前，通用规则在后
 # 只匹配 "kube.nginx"
 # 只匹配 "kube.nginx.access"
 # 匹配所有以 kube. 开头的Tag
 # 匹配所有以 .error 结尾的Tag 
 # 匹配 app.xxx.api 模式
 # 匹配 kube.nginx 或 kube.apache
 # 匹配 app.api 或 web.api

3.分层的意义
(1)处理逻辑分离（给不同filter
kube.nginx.access → 解析访问日志，提取URL、状态码
kube.nginx.error → 解析错误日志，提取错误级别、堆栈
kube.system.kubelet → 解析系统日志，关注资源指标

(2)输出目标分流（给不同output
app.payment.** → 发送到高安全级别的ES集群
app.analytics.** → 发送到分析专用ES集群
** → 发送到通用ES集群（兜底）

(3)性能优化
kube.nginx.access（高频）→ 简单解析，快速转发
kube.system.kubelet（低频）→ 复杂解析，深度处理
**（其他）→ 基础处理，保证不丢数据

4.推荐的分层结构
第一级：环境标识 → {cluster}
第二级：命名空间 → {cluster}.{namespace}
第三级：工作负载 → {cluster}.{namespace}.{workload}
第四级：容器 → {cluster}.{namespace}.{workload}.{container}
第五级：日志类型 → {cluster}.{namespace}.{workload}.{container}.{log_type}

Fluentd插件链架构解析

Fluent Bit能做的：

多行日志合并
简单正则解析（如提取IP、时间戳）
K8s元数据自动添加
字段重命名/删除

Fluentd能做的：

复杂grok/regex解析
日期时间标准化
用户代理、地理位置等数据丰富
基于业务逻辑的字段计算和转换
多级插件链协同处理

输入插件 → Filter A → Filter B → Filter C → 输出插件
 ↓ ↓ ↓ ↓ ↓
 接收数据 → 清洗数据 → 增强数据 → 转换数据 → 发送数据

顺序性：插件按配置顺序依次执行
数据传递：每个插件接收上一步的输出作为输入
增量处理：数据在链中逐步丰富和转换
条件执行：某些插件可以基于数据内容决定是否执行

# 举例说明
原始日志
192.168.1.100 - - [02/Apr/2026:11:45:32 +0800] "GET /api/v1/users HTTP/1.1" 200 1234 "Mozilla/5.0" "http://example.com"

1.解析器parser
将文本日志拆解为结构化字段
client_ip: "192.168.1.100"
timestamp: "02/Apr/2026:11:45:32 +0800"
method: "GET"
url: "/api/v1/users"
status_code: "200"
response_size: "1234"
user_agent: "Mozilla/5.0"
referrer: "http://example.com"

2.日期处理插件Date
将文本时间戳转换为标准化时间格式
@timestamp: "2026-04-02T03:45:32.000Z"（UTC时间）
移除原始的timestamp字段

3.用户代理解析插件User Agent
解析User-Agent字符串，提取设备信息
browser: {name: "Chrome", version: "120.0.0.0"}
os: {name: "Windows", version: "10"}
device: {type: "desktop"}

4.字段增强插件Record Transformer
添加业务逻辑相关的派生字段
api_version: "v1" # 从URL提取
endpoint_category: "users" #从URL提取
is_success: true # 基于status_code>199且<300

5.地理位置插件（GeoIP）
geo: {country: "中国", city: "北京", coordinates: {lat: 39.9042, lon: 116.4074}}

# 其他高级特性
# 条件执行
插件链：解析器 → [条件]用户代理解析 → 地理位置 → 输出
条件逻辑：
- 如果`user_agent`字段存在 → 执行用户代理解析插件
- 如果`client_ip`是公网IP → 执行地理位置插件 
- 否则 → 跳过该插件

# 分支处理
状态码为5xx的错误日志 → 进入"错误处理链"（添加告警标记，发送到专门索引）
状态码为2xx的成功日志 → 进入"分析处理链"（添加业务标签，发送到分析索引）

# 并行处理
分支A：解析URL结构
分支B：分析User-Agent
分支C：验证请求合法性
聚合：合并所有结果

# 插件链设计原则
1. 失败率低的插件在前（避免后续插件白执行）
2. 计算量小的插件在前（快速过滤无效数据）
3. 必需的插件在前（确保基础字段存在）
4. 可选插件在后（基于已有字段决定是否执行）

与logstash架构的对比

Logstash：经典的“管道-过滤器”模型
Input → Filter → Output
核心思想：数据流过固定的三段式管道
类比：工厂流水线，每个工位完成特定任务
配置范式：集中式、声明式配置

Fluentd：基于“标签路由”的插件链模型
输入 → 路由决策 → 插件链A → 输出A
 → 插件链B → 输出B
 → 插件链C → 输出C
核心思想：数据根据标签被路由到不同的处理链
类比：快递分拣中心，按地址分发到不同处理线
配置范式：分布式、路由式配置

1.配置差异
Logstash：在代码中表达路由逻辑（if [type] == "nginx" { ... }）
Fluentd：在结构中表达路由逻辑（）

2.数据处理差异
隔离性：Fluentd不同链间完全隔离，Logstash共享同一处理上下文
并发性：Fluentd天然支持并行处理不同数据流
故障域：Fluentd链间故障隔离更好

3. 性能与资源特性
Logstash：单点处理能力强，适合集中式日志处理
Fluentd：资源效率高，适合云原生分布式环境

4.错误处理
Logstash：一个插件崩溃可能影响所有数据处理
Fluentd：一个链故障通常不影响其他链

5. 扩展与生态
两者都强：Elasticsearch输出、文件输入、正则解析
Logstash特强：复杂Grok模式、数据丰富化、协议解析
Fluentd特强：K8s集成、容器日志、指标收集

Fluentd数据清洗实践

当前我的k8s环境日志来源包括：
k8s组件日志
milvus 向量数据库组件日志
Prometheus及组件日志

fluent bit分流日志

识别特征：容器名包含kindnet

 filters: |
 [FILTER]
 Name kubernetes
 Match kube.var.log.containers.*
 Merge_Log On
 Keep_Log Off

 [FILTER]
 Name rewrite_tag
 Match kube.var.log.containers.*
 Rule $kubernetes['container_name'] ^(kindnet-cni)$ kube.net.kindnet false
 # container_name 匹配成功，则改标签为 kube.system.go.apiserver
 # false表示匹配到后，旧标签的数据就不再往下流了
 # 如果要区分Nginx
 # Rule $kubernetes['container_name'] ^.*nginx.*$ kube.app.nginx false 
 
 
helm upgrade --install fluent-bit . -f ./values.yaml -n fluent

fluentd清洗kindnet日志

# 添加fluentd配置，使其直接打印出kindnet的日志
 02_output.conf: |-
 
 @type stdout
 
...

helm upgrade --install fluentd . -f ./values.yaml -n fluent

可以看到日志的格式为：
I0402 08:41:30.590752 1 main.go:297] Handling node with IPs: map[172.19.0.3:{}]
↓
level: I
k8s_timestamp: 0402 08:41:30.590752
pid: 1
source_file: main.go
line: 297
message: Handling node with IPs: map[172.19.0.3:{}]

# 添加fluentd配置（Ruby DSL 语法）
01_filter.conf: |-
 # 数据清洗，expression使用正则将整句文本进行拆解，grok插件最终也会转化成正则
 
 @type parser
 key_name log # 指定要对哪个字段进行正则拆解
 reserve_data true # 保留原有的kubernetes元数据字段
 remove_key_name_field true # 解析成功后，删除原始的log字符串
 
 @type regexp
 expression /^(?[IWEF])(?<date>\d{4})\s+(?\d{2}:\d{2}:\d{2}\.\d{6})\s+(?\d+)\s+(?[^:]+):(?\d+)\]\s+(?.*)$/
 
 

 # 数据(写时)增强，将告警等级变具体
 
 @type record_transformer
 enable_ruby true
 
 level_name ${ {"I"=>"INFO", "W"=>"WARN", "E"=>"ERROR", "F"=>"FATAL"}[record["level"]] }
 clean_status "success" # 标记该记录已成功通过清洗逻辑
 processed_at ${Time.now.to_s} # 记录 Fluentd 正确处理这条日志的具体时间
 processed_by "fluentd-aio-cleaner" # 记录处理这条日志的具体组件名称
 
 
 
# 更新helm
helm upgrade --install fluentd . -f ./values.yaml -n fluent

# 重新查看fluentd输出的日志
2026-04-02 09:03:31.181201000 +0000 kube.net.kindnet: {"time":"2026-04-02T09:03:31.181227255Z","stream":"stderr","_p":"F","kubernetes":{"pod_name":"kindnet-dztmq","namespace_name":"kube-system","pod_id":"e3df4eab-ac3b-41eb-9c50-86269927556f","labels":{"app":"kindnet","controller-revision-hash":"5b49848c94","k8s-app":"kindnet","pod-template-generation":"1","tier":"node"},"host":"ws-k8s-worker2","pod_ip":"172.19.0.3","container_name":"kindnet-cni","docker_id":"914c97f17227aaf4940bb038b409c46fe5a58b6429d362ca7408b55687a34ca0","container_hash":"sha256:50415e5d05f05adbdfd902507532ebb86f924dc2e05511a3b47920156ee4236e","container_image":"docker.io/kindest/kindnetd:v20241108-5c6d2daf"},"level":"I","date":"0402","pid":"1","file":"main.go","line":"324","message":"Node ws-k8s-worker has CIDR [10.244.1.0/24] ","level_name":"INFO","clean_status":"success","processed_at":"2026-04-02 09:03:31 +0000","processed_by":"fluentd-aio-cleaner"}

正则片段	匹配内容	示例结果 (JSON Key: Value)
`^(?[IWEF])`	日志级别（首字母）	`"level": "I"`
`(?\d{4})`	4位数字日期 (MMDD)	`"date": "0402"`
`\s+(?...)`	空格 + 详细时间戳	`"time": "08:41:30.590752"`
`\s+(?\d+)`	空格 + 进程 ID	`"pid": "1"`
`\s+(?[^:]+)`	空格 + 文件名（直到冒号）	`"file": "main.go"`
`:(?\d+)\]`	冒号 + 行号 + 右中括号	`"line": "297"`
`\s+(?.*)$`	空格 + 剩下的所有消息内容	`"message": "Handling node..."`

fluent bit多行日志合并（未完成）

如果 kindnet 抛出一个 Go 的多行报错，现在的正则会失效（只能匹配到第一行）。

多行日志合并的重点是定义"开始行"
开始行 (start_state)：匹配到这个模式，说明这是一个新的日志块
后续行 (cont)：如果不匹配"开始行"，就一直把内容追加到上一条日志里

I0402 08:41:30.590752 1 main.go:297] Handling node with IPs: map[172.19.0.3:{}]

# 在 custom_parsers.conf 中定义解析器，让input中应用它
custom_parsers.conf: |
 [MULTILINE_PARSER]
 name klog-multiline
 type regex
 flush_timeout 1000
 rule "start_state" "/^([IWEF])\d{4}/" "cont"
 rule "cont" "/^(?![IWEF]\d{4})/" "cont"
# 规则：匹配 I/W/E/F + 4位数字（如 I0402）。只要符合这个，就是新的一行
# 规则：如果不符合上面的开头，就属于持续行，继续合并

# input使用新解析器
 inputs: |
 [INPUT]
 Name tail
 Path /var/log/containers/*.log
 # Kind 环境建议加上 DB 记录读取位点
 DB /fluent-bit/tail_db.db
 multiline.parser klog-multiline
 Tag kube.*
 Mem_Buf_Limit 50MB
 Skip_Long_Lines On

# 验证
kubectl exec -it -n kube-system kindnet-dztmq -- sh
# 先写一行标准的开头（符合 start_state）
echo "I0403 09:40:00.123456 1 main.go:100] Standard log line"

# 紧接着写几行不符合开头的（应该被合并进上一行）
echo " This is a fake stacktrace line 1"
echo " This is a fake stacktrace line 2"

# 再写一行标准开头（触发上一条合并结束，开启新的一条）
echo "I0403 09:40:05.654321 1 main.go:101] New standard line"

但是没反应。。而且会导致fluentd解析错误，算了，这个需求再说吧

分析与清洗milvus数据库日志

配置fluent bit重定向tag，筛选出milvus相关的日志
配置fluentd将日志输出在控制台来调试，并查看日志格式
配置fluentd里针对该tag的日志格式，进行数据清洗和增强
根据清洗完成后的数据，定义es索引模板
如果milvus的多个服务日志格式不同，需要fluentd中进行路由处理

分析日志格式

milvus组件我开启了下面这些，并观察日志格式
milvus-datanode
milvus-etcd
milvus-mixcoord
milvus-proxy
milvus-querynode

A类(etcd)：
标准的JSON结构，包含 level, ts, caller, msg
{"level":"warn","ts":"2026-04-03T06:13:12.304285Z","caller":"v3rpc/interceptor.go:197","msg":"request stats","start time":"2026-04-03T06:13:11.902903Z","time spent":"401.376037ms","remote":"10.244.1.5:57238","response type":"/etcdserverpb.Lease/LeaseRevoke","request count":-1,"request size":-1,"response count":-1,"response size":-1,"request content":""}

B类：
[时间戳] [级别] [文件名:行号] ["消息内容"] [Key=Value 键值对]
[2026/04/03 06:21:16.762 +00:00] [WARN] [balancer/balancer_impl.go:542] ["fail to assign channel"] [module=streamingcoord] [component=balancer] [policy=vchannelFair] [assignment=by-dev-rootcoord-dml_5:rw@6445>16@10.244.1.5:22222] [error="/milvus.proto.streaming.StreamingNodeManagerService/Assign; rpc error: code = DeadlineExceeded, desc = context deadline exceeded"]

[2026/04/03 06:20:09.199 +00:00] [INFO] [resolver/resolver_with_discoverer.go:199] ["update resolver done"] [component=grpc-resolver] [scheme=channel-assignment]

添加fluent bit tag分流

 filters: |
 [FILTER]
 Name kubernetes
 Match kube.var.log.containers.*
 Merge_Log On
 Keep_Log Off

 [FILTER]
 Name rewrite_tag
 Match kube.var.log.containers.*
 Rule $kubernetes['container_name'] ^(kindnet-cni)$ kube.net.kindnet false
 Rule $kubernetes['container_name'] ^(milvus-.*)$ milvus.$1 false
 
# 添加fluent-bit调试
 [OUTPUT]
 Name stdout
 Match *
 Format json_lines

# 可以观察到Mlivus的日志格式与kindnet不一样
{"date":1775530768.779644,"time":"2026-04-07T02:59:28.779643812Z","stream":"stderr","_p":"F","log":"I0407 02:59:28.779423 1 main.go:301] handling current node","kubernetes":{"pod_name":"kindnet-nncxf","namespace_name":"kube-system","pod_id":"c725a431-7ed2-446d-b658-117b2db76821","labels":{"app":"kindnet","controller-revision-hash":"5b49848c94","k8s-app":"kindnet","pod-template-generation":"1","tier":"node"},"host":"ws-k8s-worker","pod_ip":"172.19.0.2","container_name":"kindnet-cni","docker_id":"21c44bc97879fdb3a7dfc68b081bbb502a5a38ac8dcc3d26dc719cd12fae144b","container_hash":"sha256:50415e5d05f05adbdfd902507532ebb86f924dc2e05511a3b47920156ee4236e","container_image":"docker.io/kindest/kindnetd:v20241108-5c6d2daf"}}
↑这是kindnet的，"container_name":"kindnet-cni"
↓这是Mlivus的，"container_name":"mixcoord"
{"date":1775530214.9856,"time":"2026-04-07T02:50:14.985599656Z","stream":"stdout","_p":"F","log":"[2026/04/07 02:50:14.784 +00:00] [INFO] [observers/collection_observer.go:319] [\"observe all collections done\"] [num=3] [dur=124.242\\u00b5s]","kubernetes":{"pod_name":"milvus-mixcoord-644ff7f6c-jjnxm","namespace_name":"milvus","pod_id":"e3216590-342e-497c-8e16-d3e54790f13c","labels":{"app.kubernetes.io/instance":"milvus","app.kubernetes.io/name":"milvus","component":"mixcoord","pod-template-hash":"644ff7f6c"},"annotations":{"checksum/config":"3da19a518253dd9df639b082fc3b2c43da4e4c5bbf7c99ef3c8a7c60ecd35a39"},"host":"ws-k8s-worker","pod_ip":"10.244.1.9","container_name":"mixcoord","docker_id":"b85f3c15ca148ab5dcfa56b923349b9ce1d8a1909edf9899572d548d84e06e82","container_hash":"docker.io/milvusdb/milvus@sha256:1db6370509d9eb8de6d5d0dfe3c1555810b422301a0830c7fe352a595fa377ed","container_image":"docker.io/milvusdb/milvus:v2.6.11"}}

# 所以B类的rule应该写成这样
Rule $kubernetes['container_name'] ^(mixcoord|datanode|etcd|proxy|querynode|streamingnode|indexnode)$ milvus.$1 false

fluentd分流日志与数据清洗

# 将tag的日志显示在fluentd日志中
02_output.conf: |-
 
 @type stdout
 

# 可以看到已经tag标记出来了
2026-04-07 03:10:51.585214297 +0000 milvus.mixcoord: {"time":"2026-04-07T03:10:51.585214297Z","stream":"stdout","_p":"F","log":"[2026/04/07 03:10:51.184 +00:00] [INFO] [observers/collection_observer.go:314] [\"observe collection done\"] [collectionID=465149880322646675] [dur=4.385µs]","kubernetes":{"pod_name":"milvus-mixcoord-644ff7f6c-jjnxm","namespace_name":"milvus","pod_id":"e3216590-342e-497c-8e16-d3e54790f13c","labels":{"app.kubernetes.io/instance":"milvus","app.kubernetes.io/name":"milvus","component":"mixcoord","pod-template-hash":"644ff7f6c"},"annotations":{"checksum/config":"3da19a518253dd9df639b082fc3b2c43da4e4c5bbf7c99ef3c8a7c60ecd35a39"},"host":"ws-k8s-worker","pod_ip":"10.244.1.9","container_name":"mixcoord","docker_id":"b85f3c15ca148ab5dcfa56b923349b9ce1d8a1909edf9899572d548d84e06e82","container_hash":"docker.io/milvusdb/milvus@sha256:1db6370509d9eb8de6d5d0dfe3c1555810b422301a0830c7fe352a595fa377ed","container_image":"docker.io/milvusdb/milvus:v2.6.11"}}

# 清洗这些日志
{streamingnode,mixcoord,datanode,querynode,indexnode,proxy,rootcoord}>
 @type parser
 key_name log
 reserve_data true
 remove_key_name_field true
 
 @type regexp
 expression /^\[(?\d{4}\/\d{2}\/\d{2} \d{2}:\d{2}:\d{2}\.\d{3} \+\d{2}:\d{2})\] \[(?[A-Z]+)\] \[(?[^\]]+)\] \[(?"[^"]*")\](?(?: \[[^\]]+\])*)$/
 


# 查看日志
2026-04-07 04:07:21.048175513 +0000 milvus.mixcoord: {"time":"2026-04-07T04:07:20.387864605Z","stream":"stdout","_p":"F","kubernetes":{"pod_name":"milvus-mixcoord-644ff7f6c-jjnxm","namespace_name":"milvus","pod_id":"e3216590-342e-497c-8e16-d3e54790f13c","labels":{"app.kubernetes.io/instance":"milvus","app.kubernetes.io/name":"milvus","component":"mixcoord","pod-template-hash":"644ff7f6c"},"annotations":{"checksum/config":"3da19a518253dd9df639b082fc3b2c43da4e4c5bbf7c99ef3c8a7c60ecd35a39"},"host":"ws-k8s-worker","pod_ip":"10.244.1.9","container_name":"mixcoord","docker_id":"b85f3c15ca148ab5dcfa56b923349b9ce1d8a1909edf9899572d548d84e06e82","container_hash":"docker.io/milvusdb/milvus@sha256:1db6370509d9eb8de6d5d0dfe3c1555810b422301a0830c7fe352a595fa377ed","container_image":"docker.io/milvusdb/milvus:v2.6.11"},"timestamp":"2026/04/07 04:07:19.985 +00:00","level":"INFO","file":"observers/collection_observer.go:314","message":"\"observe collection done\"","kv_block":" [collectionID=465149880321444020] [dur=9.228µs]"}

本来还想做数据强转和数据增强的，算了有点搞不明白ruby

转发es与创建索引

 
 @type elasticsearch
 host "192.168.10.100"
 port 9200
 scheme https
 ssl_verify false
 user elastic
 password "123456"
 logstash_format true
 logstash_prefix "milvus"
 

PUT _index_template/milvus_logs_template
{
 "index_patterns": ["milvus-*"],
 "priority": 100,
 "template": {
 "settings": {
 "index.number_of_shards": 1,
 "index.number_of_replicas": 0,
 "index.refresh_interval": "10s"
 },
 "mappings": {
 "properties": {
 "@timestamp": { "type": "date" },
 "timestamp": { "type": "keyword" },
 "log_level": { "type": "keyword" },
 "message": { "type": "text", "analyzer": "standard" },
 "file": { "type": "keyword" },
 "kv_block": { "type": "text" },
 "processed": { "type": "keyword" },
 "kubernetes": {
 "properties": {
 "pod_name": { "type": "keyword" },
 "namespace_name": { "type": "keyword" },
 "container_name": { "type": "keyword" },
 "host": { "type": "keyword" }
 }
 }
 }
 }
 }
}

查看索引是否已经正确写入
GET _cat/indices/milvus-*
green open milvus-2026.04.07 TadupvsOTjWBdaU5cLg2oQ 1 0 20256 0 4.6mb 4.6mb 4.6mb

两周复习EFK-第七天之Helm部署Fluentd+Fluent Bit

2026-04-01T10:42:00.000Z

特性	Logstash (ELK)	Fluent Bit (EFK)
开发语言	JRuby (依赖 JVM，内存大户)	C (极度轻量，几 MB 内存)
配置风格	三段式 (Input/Filter/Output)	插件化配置，更模块化
生态地位	传统的企业级日志中心	云原生、K8s、嵌入式设备的首选
处理能力	插件极其丰富，处理逻辑极强	偏重转发，逻辑相对简单

Fluent Bit + Fluentd的配合

1.Fluent Bit
在 K8s 每一个节点（Node）上以 DaemonSet 方式运行
把容器产生的各种标准输出、系统日志快速抓取出来
不进行复杂的清洗，直接把原始数据转发出去

2.Fluentd
作为集群中独立的Deployment运行
接收来自几十个节点上 Fluent Bit 发来的数据。在这里进行深度加工：利用丰富的插件进行 Grok 解析、字段重命名、甚至去调个外部 API 补全信息。处理完后，再写入 Elasticsearch。

Fluentd/Fluent Bit 最大的特色是 **Tag（标签）路由**。
- 给 SSH 日志打上 `auth.ssh` 标签。
- 给 Nginx 日志打上 `web.nginx` 标签。
- 在 `[OUTPUT]` 块中通过 `Match auth.*` 或是 `Match web.*` 实现精准转发。这比 Logstash 的 `if [type] == "xxx"` 逻辑更高效

Helm部署Fluentd

参考文档：https://artifacthub.io/packages/helm/fluent/fluentd

https://github.com/fluent/helm-charts

因为我们是helm糕手，所以不直接部署，我们直接拉下来看values变量文件

# 添加仓库
helm repo add fluent https://fluent.github.io/helm-charts/
unset http_proxy
unset https_proxy
helm repo update

# 看下用哪个版本
helm search repo fluent/fluentd --versions
NAME CHART VERSION APP VERSION DESCRIPTION
fluent/fluentd 0.5.3 v1.17.1 A Helm chart for Kubernetes
fluent/fluentd 0.5.2 v1.16.2 A Helm chart for Kubernetes
fluent/fluentd 0.5.1 v1.16.2 A Helm chart for Kubernetes
fluent/fluentd 0.5.0 v1.16.2 A Helm chart for Kubernetes

# 最新的0.5.3版本已经是2025年出的了，所以用这个
helm pull fluent/fluentd --version 0.5.3 --untar
cd fluentd/

变量文件参数说明

# 变化
variant: elasticsearch8
# 默认DaemonSet 模式，可选聚合模式（Deployment/StatefulSet），接收Fluent Bit的日志
kind: "DaemonSet"

metrics: # prometheus的相关配置，默认关闭
 serviceMonitor:...
 prometheusRule:...

# fluent引入外置插件的字段
plugins: []
# - fluent-plugin-out-http

# 引用集群中已经存在的、非Helm维护的ConfigMap
configMapConfigs: []
# - fluentd-prometheus-conf
# - fluentd-systemd-conf

# Fluentd配置文件内部定义
fileConfigs:
 01_sources.conf: |-
 ## logs from podman
 <source>
 @type tail
 ...

调整配置与部署Fluentd

修改
variant: elasticsearch8
kind: "Deployment"
...
# 新增转发的service，默认只有一个metrics的
service:
 enabled: true
 type: "ClusterIP"
 annotations: {}
 ports:
 - name: "forwarder"
 protocol: TCP
 containerPort: 24224

fileConfigs:
 00_monitoring.conf: |-
 # 监控插件的主入口
 
 @type prometheus
 bind 0.0.0.0
 port 24231
 metrics_path /metrics
 
 
 # 监控 Fluentd 自身的 input/output 指标
 
 @type prometheus_monitor
 interval 10s
 
 
 # 监控输出端（ES）的写入情况
 
 @type prometheus_output_monitor
 interval 10s
 
 01_input.conf: |-
 
 @type forward
 port 24224
 bind 0.0.0.0
 

 02_output.conf: |-
 
 @type elasticsearch
 host "192.168.10.100"
 port 9200
 scheme https
 ssl_verify false
 user elastic
 password "123456"
 logstash_format true
 logstash_prefix "kind-logs"
 

# 部署helm
kubectl create ns fluent
helm upgrade --install fluentd . -f ./values.yaml -n fluent

Helm部署Fluent Bit

helm search repo fluent/fluent-bit --versions
NAME CHART VERSION APP VERSION DESCRIPTION 
fluent/fluent-bit 0.57.0 5.0.0 Fast and lightweight log processor and forwarde...
fluent/fluent-bit 0.56.0 4.2.3 Fast and lightweight log processor and forwarde...
fluent/fluent-bit 0.55.1 4.2.3 Fast and lightweight log processor and forwarde...
fluent/fluent-bit 0.55.0 4.2.2 Fast and lightweight log processor and forwarde...

helm pull fluent/fluent-bit --version 0.57.0 --untar
cd fluent-bit/

变量文件参数说明

# 核心配置
config:
 service:
 inputs:
 filters:
 outputs:
 customParsers:
 
[SERVICE]：全局配置
Flush 数据冲刷周期，1秒
Parsers_File 子配置文件位置
HTTP_Server/Health_Check：开启监控

[INPUT]：数据源
Name 插件名称（tail插件、systemd插件）
Path 数据源位置
Tag 给数据打tag
multiline.parser docker, cri 用解析器剥离容器运行时的JSON封装
Systemd_Filter 过滤某个systemd-service

[FILTER]：过滤器
Name kubernetes 启用Kubernetes元数据过滤器
Match kube.* 仅作用于tag以 kube. 开头的日志记录
Merge_Log On 解析为JSON
Keep_Log Off 删除原log
K8S-Logging.Parser On 启用基于Pod注解的解析
K8S-Logging.Exclude On 注解fluentbit.io/exclude: "true" 则该 Pod 的所有日志都会被丢弃

[OUTPUT]:
Name es：使用 Elasticsearch 输出插件。
Match kube.*：仅处理标签以 kube. 开头的日志
Host elasticsearch-master：Elasticsearch 服务的地址
Logstash_Format On：启用 Logstash 风格的索引命名例如 logstash-2026.03.31）
Retry_Limit False：重试次数不设限

Match host.*：处理标签以 host.开头的日志，即systemd的主机日志
Logstash_Prefix node 自定义索引前缀，例如 node-2026.03.31

[PARSER]: 格式转换器
Name docker_no_time 解析器的名称，供其他配置
Format json
Time_Keep Off 关闭日志自带的时间戳
Time_Format %Y-%m-%dT%H:%M:%S.%L 定义时间戳的解析格式

调整配置与部署Fluent bit

正常fluent bit会从容器日志和systemd两种方式获取日志（默认配置）

但我这里是kind部署的k8s，所以只要用tail插件

extraVolumes:
 - name: varlog
 hostPath:
 path: /var/log
extraVolumeMounts:
 - name: varlog
 mountPath: /var/log
 readOnly: true

# ↑这部分不需要，fluent-bit官方已经加好了

#
config:
 service: |
 [SERVICE]
 Daemon Off
 Flush {{ .Values.flush }}
 Log_Level {{ .Values.logLevel }}
 Parsers_File /fluent-bit/etc/parsers.conf
 Parsers_File /fluent-bit/etc/conf/custom_parsers.conf
 HTTP_Server On
 HTTP_Listen 0.0.0.0
 HTTP_Port {{ .Values.metricsPort }}
 Health_Check On
 
 
 inputs: |
 [INPUT]
 Name tail
 Path /var/log/containers/*.log
 # Kind 环境建议加上 DB 记录读取位点
 DB /fluent-bit/tail_db.db
 multiline.parser docker, cri
 Tag kube.*
 # 日志缓冲区，因为积压的日志有点多
 Mem_Buf_Limit 50MB
 Skip_Long_Lines On

 filters: |
 [FILTER]
 Name kubernetes
 Match kube.*
 Merge_Log On
 Keep_Log Off
 K8S-Logging.Parser On
 K8S-Logging.Exclude On

# 修改 outputs：由直连 ES 改为转发 Fluentd
 outputs: |
 [OUTPUT]
 Name forward
 Match *
 Host fluentd.fluent.svc.cluster.local
 Port 24224
 # 开启连接重试
 Retry_Limit False
 # 开启网络保持
 net.keepalive On

 
# helm部署
helm upgrade --install fluent-bit . -f ./values.yaml -n fluent

定义索引模板

现在数据已经发给es了，但是在这个搭建的流程中，没有通过grok来提取字段，在es中也没有专门为这条fluent bit+fluentd的路径定义索引模板

先搞个索引模板，让ES中可以看到它，等后面处理完数据，可以再进行完善

fluent bit+fluentd的数据处理后面再说吧，今天太忙了，好累。

# 用curl一眼数据结构，可以看到里面非常乱
curl -u elastic:123456 -k -X GET "https://192.168.10.100:9200/kind-logs-*/_search?pretty" -H 'Content-Type: application/json' -d'
{
 "size": 1,
 "sort": [{ "@timestamp": "desc" }]
}
'
{
 "took" : 16,
 "timed_out" : false,
 "_shards" : {
 "total" : 1,
 "successful" : 1,
 "skipped" : 0,
 "failed" : 0
 },
 "hits" : {
 "total" : {
 "value" : 1560,
 "relation" : "eq"
 },
 "max_score" : null,
 "hits" : [
 {
 "_index" : "kind-logs-2026.04.01",
 "_id" : "k3B3SJ0BhqMFurw_h4yK",
 "_score" : null,
 "_source" : {
 "time" : "2026-04-01T09:54:40.590735118Z",
 "stream" : "stderr",
 "_p" : "F",
 "log" : "I0401 09:54:40.590512 1 main.go:297] Handling node with IPs: map[172.19.0.2:{}]",
 "kubernetes" : {
 "pod_name" : "kindnet-nncxf",
 "namespace_name" : "kube-system",
 "pod_id" : "c725a431-7ed2-446d-b658-117b2db76821",
 "labels" : {
 "app" : "kindnet",
 "controller-revision-hash" : "5b49848c94",
 "k8s-app" : "kindnet",
 "pod-template-generation" : "1",
 "tier" : "node"
 },
 "host" : "ws-k8s-worker",
 "pod_ip" : "172.19.0.4",
 "container_name" : "kindnet-cni",
 "docker_id" : "ad3a9ffe8101377b135ea0113d6612fd9d251ce2eb089cab587b484db0afbb25",
 "container_hash" : "sha256:50415e5d05f05adbdfd902507532ebb86f924dc2e05511a3b47920156ee4236e",
 "container_image" : "docker.io/kindest/kindnetd:v20241108-5c6d2daf"
 },
 "@timestamp" : "2026-04-01T09:54:40.590735118+00:00"
 },
 "sort" : [
 1775037280590
 ]
 }
 ]
 }
}

# 定义索引模板
PUT _index_template/kind_logs_template
{
 "index_patterns": ["kind-logs-*"],
 "priority": 200,
 "template": {
 "settings": {
 "index.number_of_shards": 1,
 "index.number_of_replicas": 0,
 "index.refresh_interval": "10s"
 },
 "mappings": {
 "properties": {
 "@timestamp": { "type": "date" },
 "log": { "type": "text", "analyzer": "standard" },
 "stream": { "type": "keyword" },
 "time": { "type": "date" },
 "kubernetes": {
 "properties": {
 "pod_name": { "type": "keyword" },
 "namespace_name": { "type": "keyword" },
 "host": { "type": "keyword" },
 "container_name": { "type": "keyword" },
 "docker_id": { "type": "keyword" },
 "labels": { "type": "object", "enabled": true }
 }
 }
 }
 }
 }
}

查看今天获取的日志

stack-management → data views
创建

打开discovery

纳甲六爻-AI算卦方法与缺点

2026-03-31T08:56:00.000Z

写在前面：AI算卦的局限性

视角问题：卦象是以求卦人当前的处境，所揭示的未来信息。如果起卦人本身没有”陷于之中”，那卦象也不会准确
AI的局限：卦象的信息是非常丰富的，实操中的解卦需要结合求卦人的具体状态进行综合分析来获取信息，而AI解卦只能解出其中通用的部分

~~王盛从开始AI算卦炒股，到现在已经亏了1w了~~

六爻算卦基础

六爻是一种基于易经的算卦方法，讲究一个天人感应越信越准，用起来分”起卦”和”解卦”两个阶段。

起卦：动念头扔硬币6次，扔出6根爻，排盘后会得出一个卦象
解卦：解读卦象中的信息

传统六爻解卦上手门槛极高并且吃经验，初学者往往需要花巨时间精力学习基础知识与实战案例。

不如直接选用一个聪明的AI，将卦象的内容以图片（或将六爻以文字方式）发给AI，让AI进行解读。

具体操作方式

起卦方法

传统起卦方式是扔六次3枚硬币，需要一定的基础知识。

现在有网页上起卦的方法：~~用这个网站https://cm.k366.com/pp/liuyao.asp~~，用这个网站https://pp.6yao666.com/pp/p6y.php

解卦方法

解卦很吃AI的水平，我推荐用谷歌的AI gemini：

网页版：https://gemini.google.com/app
注意：这个网页需要使用梯子（部分地区如香港也不行）
我一般用新加坡的节点就可以正常用

纳甲六爻-基础知识笔记

2026-03-31T08:12:00.000Z

六爻京房纳甲，又称“纳甲筮法”，是汉代易学家京房（公元前77年—前37年）在《周易》基础上创立的占卜体系。其核心在于将十天干、十二地支纳入八卦六爻之中，形成一套精密的时间与空间模型。京房以“纳甲”之名，实则是将干支、五行、六亲等元素与卦爻结合，使得抽象的卦象能够对应具体的人事、物象与时间流转，从而进行吉凶推断。此法后世流传广泛，成为六爻占卜的主流方法之一。

本文仅记录基础知识，后续应该会更新更多完善的基础知识与实战案例

阴阳与八卦

阴阳

阳爻：——
阴爻：— —
老阳→少阴，老阴→少阳

后天八卦

六爻只看后天八卦，离为首

天干地支

天干地支基础

天干：甲、乙、丙、丁、戊、己、庚、辛、壬、癸
地支：子、丑、寅、卯、辰、巳、午、未、申、酉、戌、亥

地支、时间、五行的关系

寅卯主木：寅木、卯木
巳午主火：巳火、午火
申酉主金：申金、酉金
亥子主水：亥水、子水
辰未戌丑主土：辰土、未土、戌土、丑土

五行生克与六亲

五行生克

相生：火生土、土生金、金生水、水生木、木生火
相克：火克金、金克木、木克土、土克水、水克火

六亲生克关系

相生：父母生兄弟、兄弟生子孙、子孙生妻财、妻财生官鬼，官鬼生父母
相克：父母克子孙、子孙克官鬼、官鬼克兄弟、兄弟克妻财、妻财克父母

旺相休囚死

春天：木旺、火相、水休、金囚、土死
夏天：火旺、土相、木休、水囚、金死
秋天：金旺、水相、土休、火囚、木死
冬天：水旺、木相、金休、土囚、火死
四季（每季最后一个月）：土旺、金相、火休、木囚、水死

起卦方法

正为阴，背为阳
以少为贵

例如一个硬币，1是正面，花是反面：

1xx为阴
11x为阳
111为阴，但老阴变为阳，这条爻为动爻，变出来的就叫变爻

连续投6次，得到六条爻

六亲与用神

用神系统

用神：所问之事、所问之人的核心爻
原神：生用神的爻
忌神：克用神的爻
仇神：生忌神的爻（不常用）
喜神：克忌神的爻（不常用）

六冲六合

地支相冲

子午冲、丑未冲、寅申冲、卯酉冲、辰戌冲、巳亥冲

地支相合

子丑合、寅亥合、卯戌合、辰酉合、巳申合、午未合

特性

冲：不久、冲散、不安、分散、争斗
合：长久、合住、合作、纠缠、和好

下图实线为相冲，虚线为相合；不代表吉凶

日月的影响

日月可以作用于卦中的爻，卦中爻不能影响日月

月令影响

月令：衡量各爻的”季节性强弱”（旺相休囚死）
月破：在寅月（正月），卦中如果有一个申爻，那么这个申爻就是”月破”
月合（合旺）：在子月（十一月），卦中如果有一个丑爻，那么这个丑爻就是”月合”

日辰影响

日辰：衡量各爻的”日常状态”（生旺墓绝）
日冲：暗动/日破，如果是旺相，收日冲为暗动；如果是休囚收日冲为日破（冲空填实）
日合：（待补充）

象法

六亲类象

父母：长辈、支持的东西（交通工具、椅子、结婚证、技术）
官鬼：男朋友、0的1、小偷、工作、钱、心中之鬼
兄弟：同龄人、合作伙伴
子孙：生的东西、创意类的产物、警察、宠物
妻财：女朋友、1的0、钱财、为你所用的（食物、电脑）

五行性情

木主仁：根据旺相休囚死来判断
火主礼：外向/性子直
土主信：憨厚/顽固
金主义：义气/残暴
水主智：聪明/阴暗

十二长生

伏藏

“伏藏”指的是 “伏神” 与 “飞神” 的关系：

伏神：隐藏在卦中的爻，代表问卦所寻找的、缺失的、或尚未显现的人、事、物。
飞神：覆盖在伏神之上的爻，是卦中原本就存在的爻，它压住了伏神，是伏神藏身之所。

六神

六神指青龙、朱雀、勾陈、腾蛇、白虎、玄武（不主吉凶）

青龙

主仁义、善良、忠义、正义。属木

朱雀

主说话、诉讼。属火

兄弟：必定代表口舌争端
子孙：代表唱K酒吧、鹦鹉
妻财：生代表会撒娇、会说话；克代表嘴毒辣

勾陈

主肿胀、懒惰、田地、传统。属土

父母：（交通工具）很慢
兄弟：老朋友、熟人
子孙：打游戏、孩子生慢性病
妻财：土地，房产
官鬼：（男）出轨

腾蛇

没有特定方位

可以代表狡诈、狭小、神秘

白虎

主坚强、牢狱、血光、沉稳。属金

玄武

主肮脏、偷摸、迷糊。属水

父母：假的合同、文书
兄弟：赌博输钱
子孙：不正当的寻欢作乐
妻财：见不得光的财、出轨
官鬼：有小偷、是小偷

三合

有很多人参与（集中力量）

三合局

寅午戌（火）
巳酉丑（金）
申子辰（水）
亥卯未（木）

条件

需要至少两根爻在卦中发动，且必须有一根是子午卯酉
如果两根都是动的，最后一根可以在变爻里找
有一根没动，就是虚一待用（静候天机）
如果有破（月破、日破），或空亡，就需要出空、解破之后才行

三刑

受刑、指责、刁难、拖累、添乱、痛苦、憎恨、斗争、嫉妒（心理活动）

三刑类型

子卯相刑：无礼之刑（帮你又背刺）
寅巳申三刑：持势之刑（用权力欺压）
丑未戌三刑：无恩之刑（没感情）
辰酉午亥自刑：内耗，自己折磨自己
只有两种也可以算刑，但没有三刑严重

进神与退神

动爻→变爻时，如果属性相同，如果向前进就是进神，往后退就是退神（能量比日月、生合、冲克大）

定义

如动爻为寅木，变爻为卯木，就是进神

特性

进神：成长、发展、上进、采取行动、主动、变大、不断的
退神：退缩、淘汰、后悔、倒退、衰弱

特殊情况

合而不退（冲的时候退）
旺而不退（休囚的时候退）
短期不退，但长期来看这几种都是退的

两周复习EFK第六天之深化数据清洗-GeoIP、运行时字段与TSVB图表

2026-03-30T11:20:00.000Z

GeoIP（实时全球威胁地图）

GeoIP 是一种将 IP 地址 映射到 地理位置（经纬度、国家、城市、邮政编码）的技术。Logstash 默认内置了 geoip 插件

添加filiter字段

# 只有当 src_ip 字段存在时，才执行地理位置查询
if [src_ip] {
 geoip {
 source => "src_ip" # 数据源字段
 target => "geo" # 放入新字段
 fields => ["city_name", "country_name", "location", "region_name", "country_code2"] # 只保留国家、城市、经纬度和代码
 }
 }

filter {
 grok {
 match => { "message" => "%{SYSLOGTIMESTAMP:timestamp} %{HOSTNAME:hostname} sshd\[\d+\]: %{WORD:auth_result} password for %{USER:username} from %{IP:src_ip} port %{NUMBER:port}" }
 }

 date {
 match => [ "timestamp", "MMM d HH:mm:ss", "MMM dd HH:mm:ss" ]
 timezone => "Asia/Shanghai"
 }
 mutate {
 convert => {
 "port" => "integer"
 "severity" => "integer"
 }
 }

 if [auth_result] == "Failed" {
 mutate {
 add_field => { "event_type" => "ssh_brute_force" }
 replace => { "severity" => 3 }
 }
 }
if [src_ip] {
 geoip {
 source => "src_ip"
 target => "geo"
 fields => ["city_name", "country_name", "location", "region_name", "country_code2"]
 }
 }
if [geo][geo] {
 mutate {
 rename => { "[geo][geo][location]" => "[geo][location]" }
 rename => { "[geo][geo][city_name]" => "[geo][city_name]" }
 rename => { "[geo][geo][country_name]" => "[geo][country_name]" }
 remove_field => [ "[geo][geo]" ]
}
}
}
systemctl restart logstash.service

但是当前的es其实并不识别这几个新加入进去的字段，所以需要重新定义索引模板

这里使用kibana dev tools了，用postman太麻烦了
PUT _index_template/syslog_template
{
 "index_patterns": [
 "syslog-security-*"
 ],
 "priority": 200, 
 "template": {
 "settings": {
 "index": {
 "number_of_shards": 3,
 "number_of_replicas": 1,
 "lifecycle": {
 "name": "my_syslog_policy",
 "rollover_alias": "syslog-security"
 }
 }
 },
 "mappings": {
 "properties": {
 "@timestamp": { "type": "date" },
 "hostname": { "type": "keyword" },
 "event_type": { "type": "keyword" },
 "auth_result": { "type": "keyword" },
 "message": { "type": "text" },
 "src_ip": { "type": "ip" },
 "severity": { "type": "integer" },
 "port": { "type": "integer" },
 "geo": {
 "properties": {
 "location": { "type": "geo_point" },
 "city_name": { "type": "keyword" },
 "country_name": { "type": "keyword" },
 "region_name": { "type": "keyword" }
 }
 }
 }
 }
 }
}

清除今日索引
DELETE syslog-security-2026.03.30

模拟真实IP攻击

echo "$(date "+%b %d %H:%M:%S") 1panel sshd[1234]: Failed password for root from 8.8.8.8 port 5678 ssh2" >> /var/log/secure

echo "$(date "+%b %d %H:%M:%S") 1panel sshd[5678]: Failed password for admin from 114.55.64.10 port 9999 ssh2" >> /var/log/secure

echo "$(date "+%b %d %H:%M:%S") 1panel sshd[9999]: Failed password for user1 from 123.123.123.123 port 4433 ssh2" >> /var/log/secure

Runtime Fields（运行时字段）

在传统的 ELK 流程里，数据是”一锤子买卖”：

采集（Logstash）：你写好 Grok，把日志切开。
存储（Elasticsearch）：数据按照 Mapping 存入磁盘。一旦存进去，字段类型和内容就固定了。
展示（Kibana）：你只能查磁盘里已有的东西。

如果你今天下午开会，老板突然说：”那个 severity: 3 太冷冰冰了，我要在报表里直接看到’严重威胁‘四个字，而且还要能根据这个文字做饼图统计。”

传统做法：你得改 Logstash 脚本 -> 重启服务 -> 把过去几天的索引全删了重新跑（Reindex）。这对生产环境来说简直是噩耗。
Runtime Fields（运行时字段）：它给了你一颗”后悔药”。它允许你在查询阶段，临时通过一段代码，把磁盘里的 3 变成内存里的 严重威胁。

核心原理

1. Schema on Write (写入时定义 - 传统方式)
当你把数据存入索引时，Mapping 决定了数据长什么样。

- **优点**：查询极快（因为数据是预处理好的）。
- **缺点**：死板。想改字段逻辑？重写数据吧。

2. Schema on Read (读取时定义 - Runtime Fields)
磁盘里存的还是原始数据，但在你点击"查询"的那一秒，ES 会启动一个轻量级的脚本引擎（Painless），现场计算出结果。

- **优点**：极其灵活！不需要改旧数据，不需要重启 Logstash，随时加字段，随时改逻辑。
- **缺点**：消耗 CPU。如果数据量是亿级的，现场计算会比查预存字段慢一点。

修改索引模板的运行时字段

Painless语言特点
1.语法类似 Java：变量声明、控制流（if/else、for、while）、方法调用等都与 Java 几乎一致。
2.专为 Elasticsearch 优化：可以直接访问文档字段（如 `doc['field'].value`）、支持聚合脚本、运行时字段等。
3.安全性高：默认禁用系统调用、文件访问等危险操作，避免恶意脚本攻击。
4.性能优异：Painless 会被编译为字节码，执行效率接近原生 Java。

PUT _index_template/syslog_security_template
{
 "index_patterns": ["syslog-security-*"],
 "template": {
 "mappings": {
 "runtime": {
 "port_type": {
 "type": "keyword",
 "script": {
 "lang": "painless",
 "source": """
 // 1. 获取原始数据
 def p = params._source['port'];
 if (p != null) {
 try {
 // 2. 转换为长整型进行比对
 long portVal = Long.parseLong(p.toString());
 
 // 3. 使用 params 中定义的参数
 if (portVal < params.threshold) {
 emit(params.label_low);
 } else {
 emit(params.label_high);
 }
 } catch (Exception e) {
 emit('格式错误');
 }
 } else {
 emit('未知端口');
 }
 """,
 "params": {
 "threshold": 1024,
 "label_low": "系统特权端口",
 "label_high": "用户随机端口"
 }
 }
 }
 }
 }
}
runtime.port_type 自定义的名称
runtime.type 类型:keyword(常用)、long、double
runtime.script 代码段
runtime.script.lang 选择语言，默认painless，可选expression
runtime.script.params 外部参数
runtime.script.source 表达式正文

# 清理环境，因为我之前有几天port是没有转换成数字的，无法对比
PUT _cluster/settings
{
 "persistent": {
 "action.destructive_requires_name": false
 }
}
DELETE syslog-security-2026.03.*

造数据

# 模拟 1: 真实的上海阿里云 IP，尝试访问 SSH (特权端口)
echo "$(date "+%b %d %H:%M:%S") 1panel sshd[1001]: Failed password for root from 106.11.248.175 port 22 ssh2" >> /var/log/secure

# 模拟 2: 真实的北京腾讯云 IP，访问 Web 服务 (特权端口)
echo "$(date "+%b %d %H:%M:%S") 1panel sshd[1002]: Failed password for admin from 115.159.152.210 port 443 ssh2" >> /var/log/secure

# 模拟 3: 真实的 Google 公共 DNS IP，模拟非标准高位端口 (随机端口)
echo "$(date "+%b %d %H:%M:%S") 1panel sshd[1003]: Failed password for testuser from 8.8.8.8 port 54321 ssh2" >> /var/log/secure

# 模拟 4: 真实的 Cloudflare IP，模拟另一个高位端口 (随机端口)
echo "$(date "+%b %d %H:%M:%S") 1panel sshd[1004]: Failed password for guest from 1.1.1.1 port 33890 ssh2" >> /var/log/secure

TSVB 趋势预测与去噪

从”快照”进化到”趋势”

在安全运维中，原始数据是”骗人”的。
• 去噪（De-noising）：识别”手抖”与”爆破”
◦ 现象：如果你看原始 Count，某个整点突然多了 5 个 Failed，那是用户忘密码了，还是机器在试探？
◦ TSVB 解决：通过 Moving Average（移动平均），这种瞬时的毛刺会被平滑掉。如果平滑线（Trend Line）持续走高，说明攻击者不是在”路过”，而是在”驻留”尝试。
• 指标关联（Metric Math）：看”质”不看”量”
◦ 现象：今天有 10,000 次登录失败，听起来很恐怖？但如果今天总访问量是 100 万次，那失败率其实很低。
◦ TSVB 解决：利用 Filter Ratio，直接计算 $\frac{Failed}{Total}$ 的百分比。比看绝对数量更能反映系统真实的受攻击程度。

创建TSVB

1.创建visualization（上一次使用是创建整个数据看板）
Create visualization-Legacy-TSVB

****2.创建基础的count图表,填入panel options和data的信息

3.在count图表基础上，再创建平滑趋势趋势线

4.视觉分离

5.模拟攻击，我用的openclaw写入文件直接模拟攻击

平滑趋势趋势线

换色与两个图表的叠加

两周复习EFK第五天之使用Lens图表

2026-03-30T11:15:00.000Z

创建一个lens图表

X 轴（时间）：依赖 date 插件的纠偏，否则历史数据会全部堆积在”现在”
指标（数值）：依赖 mutate 的强转，否则无法进行平均值、最大值或范围聚合。
维度（拆分）：依赖 grok 的精准切分（如 auth_result）。

两周复习EFK第四天之数据深加工-时间轴纠偏与Mutate字段强转

2026-03-25T10:53:35.000Z

data插件-时间轴纠偏的意义

1.断点续传
默认情况下，ES使用写入时间作为@timestamp，也就是Kibana 的右侧时间筛选器里，默认绑定的是 @timestamp
因为现有的Filebeat 和 Logstash 性能很好，日志产生后 0.1 秒就传到了 ES。所以"发生时间"和"写入时间"几乎重合，在 Kibana 上感觉不出差别，但如果你的 Logstash 停机维护了 2 小时。重启后，Filebeat 会把积压的 2 小时日志瞬间发过来
这 2 小时的陈旧日志，在 Kibana 看来全都是"刚刚产生的"

2.补录历史数据
如果要把去年的备份日志导入 ES 做审计，没有 date 插件，这些日志全都会显示为"今天"。

3.时区问题
Elasticsearch 内部强制使用 UTC（0时区） 存储时间

Mutate插件-字段强转的意义

1. 从"展示"到"计算"
Grok 插件默认抓取的所有内容都是 String
如果你不强转，"port": "8888" 和 "severity": "3" 在 ES 看来和 "root" 这个用户名没有区别
也就无法在Kibana里对它们做任何数学运算：不能算平均值、不能算总和、不能做范围过滤

2.节省存储与查询性能
在底层的 Lucene 引擎中，存储一个整数比存储一个等值的字符串要高效得多

3.防止"制图失败"
当你尝试在 Kibana 里画一个折线图来展示"每分钟平均严重程度"时，如果你没做强转，Kibana 会直接报错，或者在选择指标（Metrics）时，下拉菜单里根本找不到 severity 这个字段。

Grok 只是把字符串"切"出来，而 Mutate 的 convert 才是给这些碎片赋予"灵魂"（数据类型）

logstash配置修改

/etc/logstash/conf.d/ssh_filter.conf

（真实操作时，json不支持注释）

# 原配置
filter {
 grok {
 match => { "message" => "%{SYSLOGTIMESTAMP:timestamp} %{HOSTNAME:hostname} sshd\[\d+\]: %{WORD:auth_result} password for %{USER:username} from %{IP:src_ip} port %{NUMBER:port}" }
 }
 if [auth_result] == "Failed" {
 mutate {
 add_field => { "event_type" => "ssh_brute_force" }
 replace => { "severity" => 3 }
 }
 }
}

# 修改配置
filter {
 # 1. 基础拆分（保持你原有的逻辑，但注意字段名我们统称为 timestamp）
 grok {
 match => { "message" => "%{SYSLOGTIMESTAMP:timestamp} %{HOSTNAME:hostname} sshd\[\d+\]: %{WORD:auth_result} password for %{USER:username} from %{IP:src_ip} port %{NUMBER:port}" }
 }

 # 2. 使用data插件，让kibana中的时间轴以日志里的时间为准
 date {
 # 匹配 timestamp 字段中的内容，尽可能匹配多种格式
 match => [ "timestamp", "MMM d HH:mm:ss", "MMM dd HH:mm:ss" ]
 # 显式指定时区
 timezone => "Asia/Shanghai"
 }
 # 3.把字符串变成数字
 mutate {
 convert => {
 "port" => "integer" # 强转端口为整数，方便以后搜 port > 1024
 "severity" => "integer" # 强转严重性为整数，方便以后算平均值
 }
 }

 if [auth_result] == "Failed" {
 mutate {
 add_field => { "event_type" => "ssh_brute_force" }
 replace => { "severity" => 3 }
 }
 }
}

测试过去的日志

echo "Mar 22 14:30:05 1panel sshd[12345]: Failed password for root from 192.168.10.200 port 2222 ssh2" >> /var/log/secure

api请求es，查询这条日志
# 搜索23号端口号大于2000的所有安全日志
GET /syslog-security-2026.03.22/_search
{
 "query": {
 "range": {
 "port": {
 "gt": 2000
 }
 }
 }
}
返回
...
"@version": "1",
"message": "Mar 22 14:30:05 1panel sshd[12345]: Failed password for root from 192.168.10.200 port 2222 ssh2",
"src_ip": "192.168.10.200",
"port": 2222

如果能搜到这条日志，就说明这条历史日志已经被正确存放到了当天3.22的索引中了
同时也可以看到这条日志的port已经不是""字符串了，而是整型

两周复习EFK第三天之索引CRUD与生命周期管理

2026-03-24T15:26:00.000Z

有没有发现今天的内容甚至有些倒退，是的，是因为gemini忘了一开始指定的计划了，我让它回想起来之后，它觉得我学的太快了，所以重新学一些基础的东西

查看集群状态_cluster/health

number_of_nodes：集群中在线的总节点数。
number_of_data_nodes：专门负责存储数据的节点数。
active_primary_shards：集群中所有索引处于激活状态的主分片总数。
active_shards：所有激活的分片总数（主分片 + 副本分片）。
relocating_shards：正在从一个节点移动到另一个节点的分片数（通常发生在扩容或缩容时）。
initializing_shards：正在初始化的分片数（刚创建索引或节点重启时）。
unassigned_shards：重点关注。未分配的分片数。如果非 0，集群状态通常会变黄或变红。

{
 "cluster_name": "es-cluster",
 "status": "green", 
 "timed_out": false,
 "number_of_nodes": 3,
 "number_of_data_nodes": 3,
 "active_primary_shards": 49,
 "active_shards": 98,
 "relocating_shards": 0,
 "initializing_shards": 0,
 "unassigned_shards": 0,
 "unassigned_primary_shards": 0,
 "delayed_unassigned_shards": 0,
 "number_of_pending_tasks": 0,
 "number_of_in_flight_fetch": 0,
 "task_max_waiting_in_queue_millis": 0,
 "active_shards_percent_as_number": 100.0
}

查看索引清单_cat/indices

health：这个索引自己的健康度。
status：通常是 open。
index：索引的名字（比如 syslog-security-xxx）。
docs.count：这里面现在存了多少条日志？
pri (Primary)：主分片数量。
rep (Replica)：副本分片数量。

可以看出的内容

.internal 开头的：这些是系统的”内账”，记录的是 Kibana 的配置、告警规则等
syslog-security 索引，pri 是 3，rep 是 1。数据被切成了 3 块（分片）存储，且每一块都有 1 个备份

ES的CRUD

1.创建一条假日志
PUT /test-index/_doc/1
{
 "user": "admin",
 "action": "login",
 "status": "success",
 "timestamp": "2026-03-24T10:00:00Z"
}
返回
{
 "_index": "test-index",
 "_id": "1",
 "_version": 1,
 "result": "created",
 "_shards": {
 "total": 2,
 "successful": 2,
 "failed": 0
 },
 "_seq_no": 0,
 "_primary_term": 1
}

2.查询假日志
GET /test-index/_doc/1
返回
{
 "_index": "test-index",
 "_id": "1",
 "_version": 1,
 "_seq_no": 0,
 "_primary_term": 1,
 "found": true,
 "_source": {
 "user": "admin",
 "action": "login",
 "status": "success",
 "timestamp": "2026-03-24T10:00:00Z"
 }
}

3.更新日志
POST /test-index/_update/1
返回
{
 "_index": "test-index",
 "_id": "1",
 "_version": 2,
 "result": "updated",
 "_shards": {
 "total": 2,
 "successful": 2,
 "failed": 0
 },
 "_seq_no": 1,
 "_primary_term": 1
}

4.删除索引
DELETE /test-index

第二天创建了一个索引，syslog-security-*，索引默认会永久保存
现在要让他在7天后自动删除以节省空间

这个在kibana的面板上点点点也可以设置，但是我们这里用api，这俩是同步的

创建生命周期策略

PUT _ilm/policy/my_syslog_policy
min_age: 7d 满7天执行删除
rollover: 如果索引满1天或者满 50GB，就自动切分出一个新索引

{
 "policy": {
 "phases": {
 "hot": { 
 "actions": {
 "rollover": { 
 "max_age": "1d",
 "max_size": "50gb"
 }
 }
 },
 "delete": {
 "min_age": "7d", 
 "actions": {
 "delete": {} 
 }
 }
 }
 }
}

绑定生命周期策略到现有索引模板

PUT _index_template/syslog_template
{
 "index_patterns": ["syslog-security-*"],
 "template": {
 "settings": {
 "index.lifecycle.name": "my_syslog_policy", 
 "index.lifecycle.rollover_alias": "syslog-security"
 }
 }
}
syslog_template 匹配的索引模板
index_patterns 索引模板的匹配规则
index.lifecycle.name 绑定刚才创建的策略
index.lifecycle.rollover_alias 用于自动滚动的别名

# 存量索引
# 给 23 号和 24 号的索引手动开启生命周期管理
PUT /syslog-security-2026.03.2*/_settings
{
 "index.lifecycle.name": "my_syslog_policy"
}

匹配范围：当一个新索引（如 syslog-security-2026.03.24）创建时，ES 会扫描所有模板。
冲突检查：如果有多个模板的 index_patterns 都匹配这个名字，ES 会检查 priority。
报错触发：如果优先级相同，ES 为了防止配置混乱（比如模板 A 说要 3 个分片，模板 B 说要 1 个分片），就会抛出你看到的这个 illegal_argument_exception。

Helm部署Milvus与langchain集成

2026-03-24T09:55:00.000Z

本文默认读者是一个helm糕手，会略过一些基础的概念，仅对关键部分做解释

Milvus是一个向量数据库，但是和之前用过的Chorma和FAISS相比，更加倾向于是一个功能完整的分布式数据库

维度	FAISS	Chroma	Milvus
定位	高性能向量搜索库	轻量级向量数据库	云原生分布式向量数据库
核心特点	极致检索速度、支持GPU加速	极简API、与LangChain等AI框架无缝集成	完整的数据管理能力、支持分布式、混合检索
架构/部署	本地嵌入式库，无服务端	本地或Docker部署，嵌入式优先	分布式、云原生，可部署在K8s上或使用云服务
数据规模	十亿级（通过GPU/多卡）	百万级	百亿/千亿级
索引与功能	提供多种索引算法(IVF, HNSW, PQ)，但无数据持久化、无CRUD，只是搜索库	基础索引，支持元数据过滤，但不支持复杂混合检索	支持向量与标量字段的混合检索、数据分区、多副本、高可用等完整数据库特性
性能指标	极致快（毫秒级，尤其在GPU上），纯算法层优化	较快，但在大规模数据和高并发场景下性能衰减明显	快（毫秒级，<50ms），且在亿级数据下性能表现稳定，高QPS
易用性	较高，需自行集成和管理索引文件	极高，几行Python代码即可运行	中等，功能丰富，但需要一定的运维知识（尤其是自建）
典型场景	学术研究、对性能有极致要求的特定场景、作为其它数据库的核心引擎	快速原型验证、个人项目、Jupyter Notebook中的AI实验	企业级生产环境、大规模RAG应用、推荐系统、多模态搜索

Milvus现在也支持单机部署或使用Lite轻量版直接用pip安装，不过我这里肯定是用更高级的方法部署，也就是Helm部署

参考文档：https://milvus.io/docs/zh/overview.md
官网推荐使用Operator或者Helm部署

Helm部署

# mlivus需要一个provisioner，必须搞一个
kubectl apply -f https://raw.githubusercontent.com/rancher/local-path-provisioner/master/deploy/local-path-storage.yaml
# 我使用的是kind部署的测试集群，所以默认就有
kubectl get sc
NAME PROVISIONER RECLAIMPOLICY VOLUMEBINDINGMODE ALLOWVOLUMEEXPANSION AGE
standard (default) rancher.io/local-path Delete WaitForFirstConsumer false 5d5h

# 我使用的helm版本为v4.0.4
helm repo add zilliztech https://zilliztech.github.io/milvus-helm/
helm repo update

# 直接部署的方式，但我没采用这种方式，因为后面肯定主要追求helm集成到我们自己的工程文件中
helm install my-release zilliztech/milvus \
 --set image.all.tag=v2.6.11 \
 --set pulsarv3.enabled=false \
 --set woodpecker.enabled=true \
 --set streaming.enabled=true \
 --set indexNode.enabled=false

# 搜索与拉取helm chart
helm search repo zilliztech/milvus --versions
NAME CHART VERSION APP VERSION DESCRIPTION 
zilliztech/milvus 5.0.16 2.6.13 Milvus is an open-source vector database built ...
zilliztech/milvus 5.0.15 2.6.12 Milvus is an open-source vector database built ...
zilliztech/milvus 5.0.14 2.6.11 Milvus is an open-source vector database built ...
...

helm pull zilliztech/milvus --version 5.0.14 --untar
cd milvus/

# 查看values.yaml文件，参数说明
上面他关闭和开启的几个模块：
pulsarv3 Pulsar (消息队列)因为启用了woodpecker，所以不需要了
woodpecker 啄木鸟 云原生预写日志（WAL）系统，作用是替代外部的消息队列
streaming 流服务 提供流数据的接入、管理和订阅功能，默认使用minio，也可以用公有云服务
indexNode 索引节点，用以加速向量检索，但消耗资源

# 调整参数（注意需要指定存储类）
pulsarv3.enabled=false
woodpecker.enabled=true
streaming.enabled=true
indexNode.enabled=false
etcd.persistence.storageClass=standard
minio.persistence.storageClass=standard
# 使用本地文件--首次部署
helm upgrade --install milvus . -f ./values.yaml -n milvus --create-namespace

配置Milvus使用OSS

# 在开始之前可以先用mc确认一下aksk以及endpoint是否正确
mc ls mlivus/milvus-wangsheng-test/
[2026-03-23 22:18:01 CST] 0B test/

# 关闭原本有的minio
minio:
 enabled: false
...

# 配置外部S3
# 他妈的这个b参数我真的试了几个小时，才试出来
externalS3:
 enabled: true
 host: "oss-cn-beijing.aliyuncs.com"
 port: "443"
 accessKey: "LTAIxxxx"
 secretKey: "qbfxxxxx"
 useSSL: true
 bucketName: "milvus-wangsheng-test"
 rootPath: "test"
 useIAM: false
 cloudProvider: "aliyun"
 iamEndpoint: ""
 region: "cn-beijing"
 useVirtualHost: true

# 清理方法
helm delete milvus -n milvus
kubectl delete pvc --all -n milvus

# helm更新
helm upgrade --install milvus . -f ./values.yaml -n milvus

部署Attu可视化看板

Attu 是 Milvus 官方推出的开源图形化管理工具

# 打一个端口转发，使外部可以访问到milvus本地
kubectl -n milvus port-forward --address 0.0.0.0 service/milvus 27017:19530 & 
kubectl -n milvus port-forward --address 0.0.0.0 svc/milvus 9091:9091 &

# 现在访问端点是 192.168.10.100:27017

# 部署attu
docker run -d \
 --name attu \
 -p 8000:3000 \
 -e MILVUS_URL=192.168.10.100:27017 \
 zilliz/attu:latest
 
# 访问端口8000就可以看到，直接点访问就可以点进去了

理解Milvus

要使用milvus首先要理解milvus的基本理论知识
Milvus 采用的是存储与计算分离的架构，它把整个系统拆成了四个层级：

**接入层 (Access Layer/Proxy)**：
就像酒店的前台。它不存数据，只负责校验你的请求、限流，并将请求转发给内部组件。
**协调器 (Coordinators)**：
系统的”大脑”。负责分配任务（比如告诉某个 Worker 该去处理哪个数据段）、管理元数据（存放在 Etcd）以及给数据分配唯一的 ID（TSO）。
执行节点 (Worker Nodes)：
系统的”苦力”。分为 QueryNode（负责搜）、DataNode（负责写）和 IndexNode（负责建立索引）。
**存储层 (Storage)**：

**对象存储 (OSS/MinIO)**：存放真正的向量数据和索引文件（你刚才折腾最久的地方）。
**元数据存储 (Etcd)**：存 Collection 结构、Pod 状态等。
消息队列 (Pulsar/Kafka)：这是 Milvus 的血液。所有的写入操作都会先变成一条消息进入队列。

实际上的使用流程

定义 Schema：选好维度和距离算法。
创建 Collection：定好 shards_num（影响写入吞吐）。
插入数据：批量插入（Batch Insert）效率远高于单条。
建立索引：选好 index_type（影响查询延迟）。
Load：设置 replica_number（影响查询并发）。
Search：开始你的向量检索。

使用Milvus

~~在理解流程的基础上，我准备使用我之前用langchain写的一个streamlit的项目，小改一手让他用milvus~~

~~是我高估自己了，我是个菜逼，整了半天硬是跑不通，算了跑个简单的得了~~

哈哈，成啦，我简直是个天才

之前失败是因为调整了oss参数，却没有清空etcd数据，数据不同步
导致proxy向mixcoord发起创建collection的请求失败
所以连接是通的，但发起collection的请求一直死锁

测试milvus连接

# 现在访问端点是 192.168.10.100:27017
cd langchain_project_PDF/
conda activate langchain
pip install -U pymilvus

cat > test_milvus.py <<EOF
from pymilvus import connections, utility

def test_connection():
 print("正在尝试连接 Milvus...")
 try:
 # 设置一个短的 timeout，防止无限等待
 connections.connect(
 alias="default", 
 host="192.168.10.100", 
 port="27017", 
 timeout=5
 )
 
 # 获取服务器版本，这是最轻量的请求
 version = utility.get_server_version()
 print(f"✅ 连接成功！Milvus 版本: {version}")
 
 # 列出所有集合名
 collections = utility.list_collections()
 print(f"当前数据库中的集合: {collections}")
 
 except Exception as e:
 print(f"❌ 连接失败: {e}")
 finally:
 connections.disconnect("default")

if __name__ == "__main__":
 test_connection()

EOF
python test_milvus.py

正在尝试连接 Milvus...
✅ 连接成功！Milvus 版本: 2.6.11
当前数据库中的集合: []

集成到langchain代码

import streamlit as st
from streamlit_extras.add_vertical_space import add_vertical_space
from PyPDF2 import PdfReader
from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain_huggingface import HuggingFaceEmbeddings
from langchain.vectorstores import FAISS
# from langchain_community.vectorstores import Milvus
from langchain_deepseek import ChatDeepSeek
from langchain.chains.question_answering import load_qa_chain
from langchain.callbacks.streamlit import StreamlitCallbackHandler
from langchain.callbacks import get_openai_callback
import pickle
import os
from dotenv import load_dotenv
import hashlib

# Milvus 相关导入
from pymilvus import connections, utility
from langchain_community.vectorstores import Milvus

load_dotenv()

# 1.创建UI
with st.sidebar:
 st.title("Ask for PDF")
 st.markdown("该项目提供PDF文件上传的功能，用户可以输入问题，在PDF文件中进行搜索")
 add_vertical_space(10) # 空五行
 st.write("测试项目")

# 写一个main作为程序入口
def main():
 st.header("Ask for PDF")
 
 # 文件上传器
 pdf = st.file_uploader("上传PDF", type="pdf")
 if pdf is not None:
 st.write(f">{pdf.name}上传完成")

 # ==================== MD5 哈希处理文件名 ====================
 # 解决中文名报错，并实现文件去重
 file_bytes = pdf.read()
 file_hash = hashlib.md5(file_bytes).hexdigest()
 collection_name = f"pdf_{file_hash}" 
 pdf.seek(0) # 重要：复位指针，确保下文 PdfReader 能读取内容
 # =============================================================

 # 2.读取pdf
 pdf_reader = PdfReader(pdf)
 text = ""
 for page in pdf_reader.pages:
 text += page.extract_text()
 
 # 3.文本切割
 text_splitter = RecursiveCharacterTextSplitter(chunk_size=1000, chunk_overlap=20, length_function=len)
 texts = text_splitter.split_text(text)
 st.write(texts)
 
 # 4.向量初始化
 embeddings = HuggingFaceEmbeddings(
 model_name="sentence-transformers/all-mpnet-base-v2",
 model_kwargs={'device': 'cpu'}
 )
 st.write(">嵌入式模型初始化完成")
 
 # 保留原有的 store_name 变量，兼容你之前的注释代码
 store_name = pdf.name[:-4]
 
 # ==================== FAISS 原代码（保留注释）====================
 # 如果数据库文件已存在，直接使用
 # if os.path.exists(f"{store_name}.pkl"):
 # with open(f"{store_name}.pkl", "rb") as f:
 # vectorstore = pickle.load(f)
 # st.write(">数据库已从磁盘加载")
 # else:
 # vectorstore = FAISS.from_texts(texts, embeddings)
 # # 数据库保存
 # with open(f"{store_name}.pkl","wb") as f:
 # pickle.dump(vectorstore, f)
 # st.write(f">数据库已保存为 {store_name}.pkl")
 # ================================================================
 
 # ==================== Milvus 新代码 (修正版) ====================
 # 定义统一的连接参数，避免使用 url 导致格式错误
 milvus_config = {
 "host": "192.168.10.100",
 "port": "19530"
 }

 # 连接到 Milvus
 connections.connect(
 alias="default",
 **milvus_config
 )
 st.write(f">已连接到 Milvus 服务器，映射集合名: {collection_name}")
 
 # 检查集合是否已存在
 if utility.has_collection(collection_name):
 # 从已有集合加载向量存储
 vectorstore = Milvus(
 embedding_function=embeddings,
 connection_args=milvus_config,
 collection_name=collection_name
 )
 st.write(f">Milvus 集合 '{collection_name}' 已从服务器加载")
 else:
 # 创建新的 Milvus 集合并插入向量
 vectorstore = Milvus.from_texts(
 texts=texts,
 embedding=embeddings,
 connection_args=milvus_config,
 collection_name=collection_name,
 drop_old=False
 )
 st.write(f">Milvus 集合 '{collection_name}' 已创建并保存")
 # ================================================================
 
 # 5.用户输入问题，检索数据库
 query = st.text_input("输入问题:")
 if query:
 docs = vectorstore.similarity_search(query, k=30)
 
 # web流式输出
 response_container = st.empty()
 st_callback = StreamlitCallbackHandler(parent_container=response_container)

 llm = ChatDeepSeek(
 model="deepseek-chat", 
 temperature=0.7,
 streaming=True,
 callbacks=[st_callback]
 )
 chain = load_qa_chain(llm, chain_type="stuff")
 
 # 回调统计token
 with get_openai_callback() as cb:
 reponse = chain.invoke({"question": query, "input_documents": docs})
 st.write(f">检索结果: {reponse['output_text']}")
 st.success(f"> 总Token数: {cb.total_tokens}")

if __name__ == '__main__':
 main()

两周复习EFK第二天之部署与使用logstash+filebeat+es

2026-03-23T08:17:43.000Z

创建一个索引模板

昨天手动put了syslog-security-2026.03.19的索引格式，但一条一条添加肯定不行

以后任何以 syslog-security- 开头的索引，都会自动变成 3 分片、1 副本，并且 src_ip 永远是 ip 类型。

部署与使用Logstash

支持input→filter→ouput的工作流，特别是filter功能可以识别IP、时间格式对数据进行拆分，输出规整的精美json

参考文档：
二进制部署：https://www.elastic.co/docs/reference/logstash/installing-logstash

目前我们是初学者，就先用二进制部署，用helm部署的k8s版本就再说吧

# ubuntu版本
wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo gpg --dearmor -o /usr/share/keyrings/elastic-keyring.gpg
sudo apt-get install apt-transport-https
echo "deb [signed-by=/usr/share/keyrings/elastic-keyring.gpg] https://artifacts.elastic.co/packages/9.x/apt stable main" | sudo tee -a /etc/apt/sources.list.d/elastic-9.x.list
sudo apt-get update && sudo apt-get install logstash

systemctl enable logstash.service --now
systemctl is-active logstash.service
active

# 红帽系
rpm --import https://artifacts.elastic.co/GPG-KEY-elasticsearch
cat > /etc/yum.repos.d/logstash.repo <<EOF
[logstash-9.x]
name=Elastic repository for 9.x packages
baseurl=https://artifacts.elastic.co/packages/9.x/yum
gpgcheck=1
gpgkey=https://artifacts.elastic.co/GPG-KEY-elasticsearch
enabled=1
autorefresh=1
type=rpm-md
EOF
yum -y install logstash

# 新建配置文件
cat > /etc/logstash/conf.d/ssh_filter.conf <<'EOF'
input {
 beats {
 port => 5044
 }
}
filter {
 grok {
 match => { "message" => "%{SYSLOGTIMESTAMP:timestamp} %{HOSTNAME:hostname} sshd\[\d+\]: %{WORD:auth_result} password for %{USER:username} from %{IP:src_ip} port %{NUMBER:port}" }
 }
 if [auth_result] == "Failed" {
 mutate {
 add_field => { "event_type" => "ssh_brute_force" }
 replace => { "severity" => 3 }
 }
 }
}
output {
 stdout { codec => rubydebug }
 elasticsearch {
 hosts => ["https://192.168.10.100:9200"]
 index => "syslog-security-%{+YYYY.MM.dd}"
 api_key => "MnQxUUJaMEIzMlk0TE9TWnFaeEQ6UjAyLVloeUFNRGw4Rl85d25BeEM3dw=="
 ssl_verification_mode => "none"
 }
}
EOF

这里的工作流解释：
1.接收beats插件给5044端口的数据，beats字段指插件
2.通过filiter使用grok插件规定格式进行正则筛选
3.对数据进行清洗，如果是Failed就标记严重性为3
4.将输出发送给控制台(debug)，同时发送给es集群

systemctl restart logstash.service
# 查看日志是否报错
tail -f /var/log/logstash/logstash-plain.log

# 验证5044端口是否监听
ss -tunlp | grep 5044
tcp LISTEN 0 4096 *:5044 *:* users:(("java",pid=62517,fd=154))

部署与使用filebeat

极轻量的日志收集器，只搬运不加工，支持断点续传（offset偏移量）

适用二进制部署和k8s集群部署，我这k8s集群有点问题，暂时先用二进制部署

参考文档：https://www.elastic.co/docs/reference/beats/filebeat

curl -L -O https://artifacts.elastic.co/downloads/beats/filebeat/filebeat-9.3.2-x86_64.rpm
rpm -vi filebeat-9.3.2-x86_64.rpm

# 修改配置文件/etc/filebeat/filebeat.yml，这配置文件挺好认的，一段一段的
filebeat.inputs:
# 添加输入块，type决定了使用什么引擎去处理，比如filestream/log文本读取、syslog网络监听、container容器json
filebeat.inputs:
- type: filestream
 id: ssh-security-logs
 enabled: true
 paths:
 - /var/log/secure

 
# 添加输出块，默认有一段es的配置项，需要删除，因为我们现在用Logstash做聚合了
output.logstash:
 hosts: ["192.168.10.100:5044"] 

systemctl restart filebeat.service

测试链路

# 制造假数据
logger "Mar 21 22:00:01 prod-web-01 sshd[123]: Failed password for root from 192.168.10.105 port 5566 ssh2"

# 在logstash中已经可以看到相关日志了
journalctl -u logstash -f
Mar 23 15:30:42 1panel logstash[128105]: "@version" => "1",
Mar 23 15:30:42 1panel logstash[128105]: "timestamp" => "Mar 23 15:30:00",
Mar 23 15:30:42 1panel logstash[128105]: "auth_result" => "Failed",
Mar 23 15:30:42 1panel logstash[128105]: "port" => "5566",
Mar 23 15:30:42 1panel logstash[128105]: "ecs" => {
Mar 23 15:30:42 1panel logstash[128105]: "version" => "8.0.0"
Mar 23 15:30:42 1panel logstash[128105]: },
Mar 23 15:30:42 1panel logstash[128105]: "log" => {
Mar 23 15:30:42 1panel logstash[128105]: "file" => {
Mar 23 15:30:42 1panel logstash[128105]: "inode" => "67682980",
Mar 23 15:30:42 1panel logstash[128105]: "fingerprint" => "98136ef7ebcc4f2aaf3c2f6ec8556cf7cb6674e1d26ad145fd40c8f4b98bad95",
Mar 23 15:30:42 1panel logstash[128105]: "path" => "/var/log/secure",
Mar 23 15:30:42 1panel logstash[128105]: "device_id" => "64768"
Mar 23 15:30:42 1panel logstash[128105]: },
Mar 23 15:30:42 1panel logstash[128105]: "offset" => 14796257
Mar 23 15:30:42 1panel logstash[128105]: },
Mar 23 15:30:42 1panel logstash[128105]: "tags" => [
Mar 23 15:30:42 1panel logstash[128105]: [0] "beats_input_codec_plain_applied"
Mar 23 15:30:42 1panel logstash[128105]: ],
Mar 23 15:30:42 1panel logstash[128105]: "input" => {
Mar 23 15:30:42 1panel logstash[128105]: "type" => "filestream"
Mar 23 15:30:42 1panel logstash[128105]: },
Mar 23 15:30:42 1panel logstash[128105]: "severity" => "3",
Mar 23 15:30:42 1panel logstash[128105]: "src_ip" => "10.2.3.6",
Mar 23 15:30:42 1panel logstash[128105]: "event_type" => "ssh_brute_force",
Mar 23 15:30:42 1panel logstash[128105]: "username" => "root",
Mar 23 15:30:42 1panel logstash[128105]: "@timestamp" => 2026-03-23T07:30:40.640Z,
Mar 23 15:30:42 1panel logstash[128105]: "message" => "Mar 23 15:30:38 1panel root[344379]: Mar 23 15:30:00 1panel sshd[12345]: Failed password for root from 10.2.3.6 port 5566 ssh2"

初步使用kibana

KQL还可以支持一些高级语法，比如
排除法： NOT src_ip : "192.168.10.1" # 排除内网IP
多重条件： event_type : "ssh_brute_force" AND username : "root"
范围查找： port > 1024

AIGC工具MoneyPrinter部署与使用

2026-03-20T07:56:00.000Z

环境准备

# 切换WSL1到2（如果原本使用的是WSL1
dism.exe /online /enable-feature /featurename:VirtualMachinePlatform /all /norestart
wsl --set-version Ubuntu-22.04 2
wsl --set-default-version 2

# 升级wsl
wsl --update
# 使用systemd
echo -e "[boot]\nsystemd=true" | sudo tee -a /etc/wsl.conf
wsl --shutdown

# 验证systemd，如果输出为'systemd'就正常
ps -p 1 -o comm=

# 安装依赖
sudo apt update
sudo apt install -y git python3-pip python3-venv ffmpeg imagemagick
sudo apt install -y libjpeg-dev zlib1g-dev libpng-dev libfreetype6-dev
sudo apt install -y build-essential python3-dev

安装本地大模型ollama

# 本地部署
sudo apt-get install zstd
curl -fsSL https://ollama.com/install.sh | sh
# 验证
sudo systemctl is-active ollama
ss -tunlp | grep 11434
tcp LISTEN 0 4096 127.0.0.1:11434 0.0.0.0:* 

# 验证NVIDIA驱动，windows上安装驱动即可
nvidia-smi

# 拉取模型，你想用啥用啥
ollama pull llama3.1:8b

安装与配置MoneyPrinter

# 克隆git与同步环境
git clone https://github.com/FujiwaraChoki/MoneyPrinter.git
cd MoneyPrinter

# 安装uv
curl -LsSf https://astral.sh/uv/install.sh | sh
source $HOME/.local/bin/env
uv --version
# uv 0.10.12 (x86_64-unknown-linux-gnu)

uv python install 3.12
uv sync --python 3.12

# 配置
cp .env.example .env

# 填入PEXELS_API_KEY（素材库
# 官网https://www.pexels.com/api/

# 填入AssemblyAI的api-key（字幕
# 官网www.assemblyai.com

# 这俩都是免费的

启动与管理MoneyPrinter

# 启动后端
cd Backend/
export no_proxy="localhost,127.0.0.1"
python main.py

 * Serving Flask app 'main'
 * Debug mode: on
INFO:werkzeug:WARNING: This is a development server. Do not use it in a production deployment. Use a production WSGI server instead.
 * Running on all addresses (0.0.0.0)
 * Running on http://127.0.0.1:8080
 * Running on http://172.21.207.11:8080
INFO:werkzeug:Press CTRL+C to quit
INFO:werkzeug: * Restarting with stat
WARNING:werkzeug: * Debugger is active!
INFO:werkzeug: * Debugger PIN: 434-739-362

# 启动前端
cd ~/MoneyPrinter/Frontend/
python3 -m http.server 3000
Serving HTTP on 0.0.0.0 port 3000 (http://0.0.0.0:3000/) ...

# 启动消费者进程
cd ~/MoneyPrinter/Backend
python worker.py

# 访问前端页面http://localhost:3000/
就可以看到了

总的流程是这样：
1.前端请求
2.后端将任务写入SQLite（moneyprinter.db）
3.worker.py扫描数据库，发现有queue任务则将其改为processing
4.worker.py调用本地模型llama3.1:8b

使用tmux开多窗口管理

测试生成视频

在网页端进行网页生成测试，提示词就简单写就行，执行后可以看到有GPU内存已经被占用了5G了

不过我这里失败了，估计跟网络环境有点关系，这个生成视频的过程中，会去访问另外那些提供音频的网站，等回家再试试

两周复习EFK-第一天之部署与访问ES集群

2026-03-19T10:34:00.000Z

我准备使用两周时间重新学习和理解EFK/ELK体系，之前我也学习过，但是因为没有实际可操作的项目，所以很快就忘记了，以下是AI（gemini）给我提供的学习方案

学习方案

第一阶段：核心基石与可视化（第 1 - 3 天）

目标：搞定存储端 Elasticsearch 和展示端 Kibana，理解数据的”家”是怎么建的。

第 1 天：Elasticsearch 架构与索引原理
复习倒排索引（Inverted Index）和分片（Shards/Replicas）的概念。
实战： 使用 Docker 部署一个三节点的 ES 集群。手动通过 curl 或 Kibana Dev Tools 执行 CRUD。
重点： 理解 Index Template 和 ILM（索引生命周期管理），这是生产环境下防止磁盘爆满的关键。
第 2 天：Kibana 数据可视化
实战： 导入官方示例数据集（Sample Data）。
练习创建 Index Pattern，制作 Discover 视图，搭建一个简单的 Dashboard（柱状图、饼图）。
第 3 天：ES 性能调优与健康检查
学习常用的集群健康检查 API (_cat/indices, _cluster/health)。
思考： 当集群状态变为 Yellow 或 Red 时，你该如何排查？

第二阶段：采集端之争 ELK vs. EFK（第 4 - 8 天）

目标：理解 Logstash 与 Fluentd/Fluent Bit 的区别，掌握数据清洗（Grok/Filter）。

第 4 - 5 天：Logstash（ELK 的”L”）
学习 Logstash 的三段式配置：Input, Filter, Output。
实战： 模拟收集 Nginx 日志。使用 Grok 插件将非结构化日志解析成 JSON。
难点： 调试 Grok 表达式（推荐使用 Kibana 内置的 Grok Debugger）。
第 6 - 7 天：Fluentd & Fluent Bit（EFK 的”F”）
了解为什么云原生环境（K8s）更偏爱 Fluentd。
实战： 部署 Fluent Bit 收集系统日志（Journald），并转发给 ES。
对比： 感受 Fluentd 的”轻量化”配置与 Logstash 的区别。
第 8 天：Beats 系列（运维利器）
快速上手 Filebeat 和 Metricbeat。
实战： 使用 Filebeat 直接对接 ES（绕过 Logstash），体验 Ingest Pipeline 在 ES 端做简单处理。

第三阶段：安全、监控与实战场景（第 9 - 12 天）

目标：结合你的安全背景，把系统”锁死”并投入实战。

第 9 天：安全加固（RBAC & TLS）
实战： 开启 ES 的内置安全功能。配置用户权限（Role-based Access Control），设置 Kibana 登录认证。
生成证书并开启节点间的加密传输（TLS）。
第 10 天：监控与告警
学习使用 Watcher 或 Kibana Alerting。
场景： 设置一个告警，当 5 分钟内 Nginx 出现超过 10 次 500 错误时，触发通知。
第 11 - 12 天：日志收集的”最后公里”
实战： 结合 rsyslog。很多旧系统只支持 syslog，练习如何用 Logstash 或 Fluentd 接收 syslog 数据流。
架构思考： 引入消息队列（如 Redis 或 Kafka）作为缓冲，防止日志峰值冲垮 ES。

第四阶段：总演练与大作业（第 13 - 14 天）

目标：从零搭建一套完整的生产级架构。

任务：搭建一个”全栈日志审计系统”

环境： 在你的 WSL2 或服务器上，用容器起一套完整环境。
采集： Filebeat 收集 /var/log/auth.log（安全审计）和 Nginx 日志。
清洗： 经过 Logstash 过滤，提取出：访问 IP、地理位置（GeoIP 插件）、状态码。
存储： 存入 ES，并配置 7 天自动删除旧索引。
展示： 在 Kibana 做一个”安全监控大屏”，显示异常登录尝试和流量趋势。

第一天

搭建一个es集群

二进制安装

# 二进制安装系统支持情况
https://www.elastic.co/support/matrix

# 我使用的是eve-ng部署的3节点almalinux9.6
# 二进制安装
wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-9.3.1-linux-x86_64.tar.gz
wget https://artifacts.elastic.co/downloads/elasticsearch/elasticsearch-9.3.1-linux-x86_64.tar.gz.sha512
shasum -a 512 -c elasticsearch-9.3.1-linux-x86_64.tar.gz.sha512
tar -xzf elasticsearch-9.3.1-linux-x86_64.tar.gz
cd elasticsearch-9.3.1/

docker-compose安装

# 直接略过单机安装，直接用docker-compose装集群了
mkdir elasticsearch-docker-compose
cd elasticsearch-docker-compose/

wget https://raw.githubusercontent.com/elastic/elasticsearch/refs/heads/main/docs/reference/setup/install/docker/.env
wget https://raw.githubusercontent.com/elastic/elasticsearch/refs/heads/main/docs/reference/setup/install/docker/docker-compose.yml

# 在.env中配置es和kibana的密码
ELASTIC_PASSWORD=123456
KIBANA_PASSWORD=123456
STACK_VERSION=9.3.1

# 内核参数调整
echo "vm.max_map_count=262144" >> /etc/sysctl.d/99-sysctl.conf
sysctl -p

# 启动docker-compose
docker-compose up -d

# 默认用户名为elastic
# 登录https://192.168.10.100:9200之后会返回这个，说明es已经正常运行了
{
 "name" : "es01",
 "cluster_name" : "es-cluster",
 "cluster_uuid" : "uJYHX3NHS2qYSZUsk2KK6w",
 "version" : {
 "number" : "9.3.1",
 "build_flavor" : "default",
 "build_type" : "docker",
 "build_hash" : "0dd66e52ba3aa076cf498264e46339dbb71f0269",
 "build_date" : "2026-02-23T23:37:38.684779921Z",
 "build_snapshot" : false,
 "lucene_version" : "10.3.2",
 "minimum_wire_compatibility_version" : "8.19.0",
 "minimum_index_compatibility_version" : "8.0.0"
 },
 "tagline" : "You Know, for Search"
}

获取es集群的api key

我这里下载了postman

使用最简单的basic auth（账密）

获取id和api-key

记录id与encoded的值，encoded是id 和 api_key组合后经过 Base64 编码的结果

2t1QBZ0B32Y4LOSZqZxD
MnQxUUJaMEIzMlk0TE9TWnFaeEQ6UjAyLVloeUFNRGw4Rl85d25BeEM3dw==

使用api key进行连接es集群测试

向es集群中传入数据

创建索引并定义 Mapping（手动创建

这个行为类似于建立数据库中的一个表，一行数据有很多键，每个键都有对应的字段行为，比如自增、字符串格式、时间格式等

将索引PUT进去，这个syslog表就手动创建了一个索引，用来对syslog日志中的字段进行分类

{
 "settings": {
 "number_of_shards": 3, //分片数
 "number_of_replicas": 1 //副本数
 },
 "mappings": {
 "properties": {
 "@timestamp": { "type": "date" }, //作为时间格式存储
 "hostname": { "type": "keyword" }, //精确匹配，不分词
 "event_type": { "type": "keyword" }, 
 "message": { "type": "text" }, //全文索引，分词
 "src_ip": { "type": "ip" }, //作为ip类型存储
 "severity": { "type": "integer" }//作为数字类型存储
 }
 }
}

手动传入数据

查找数据

在kibana中查看数据

在kibana-stack management中创建一手图表