macOS Xinference 安装记录

Xorbits inference 是一个强大且通用的分布式推理框架,可用于大语言模型(LLM),语音识别模型,多模态模型等各种模型的推理。可以轻松地一键部署自己的模型或内置的前沿开源模型。我主要是为了在 dify 上使用 Rerank,然后运行的Xinference。

一、安装

官方手册:https://inference.readthedocs.io/zh-cn/latest/getting_started/installation.html

conda create -n xinference python=3.11
conda activate xinference
pip install "xinference[all]"
CMAKE_ARGS="-DLLAMA_METAL=on" pip install llama-cpp-python

image-20250313午後32636314

遇到了一些错误,也觉得正常:

/private/var/folders/sl/j0g8fv0d5h97tc_xxsy3fkyr0000gn/T/pip-install-6lcea4jt/llama-cpp-python_47e4373c3e314d09bee185d9fcb17bda/vendor/llama.cpp/ggml/src/ggml-quants.c
ninja: build stopped: subcommand failed.

*** CMake build failed
[end of output]

note: This error originates from a subprocess, and is likely not a problem with pip.
ERROR: Failed building wheel for llama-cpp-python
Failed to build llama-cpp-python
ERROR: Failed to build installable wheels for some pyproject.toml based projects (llama-cpp-python)

image-20250313午後32211672

安装 ninja即可:

brew install ninja

之后运行:

xinference-local # 本地
xinference-local -H 0.0.0.0 # 建议用这个,因为要和dify配合

image-20250313午後33149271

image-20250313午後34651133

image-20250313午後33234731

可以改语言成中文,顺眼一点:

image-20250313午後40911619

二、加载模型

查看内置模型:https://inference.readthedocs.io/zh-cn/latest/models/builtin/index.html

xinference launch --model-name bge-reranker-large --model-type rerank # 加载模型

也可以ui界面操作:

image-20250313午後40457075

xinference 默认的是从 huggingface 下载大模型,网络原因根本下载不下来,需要更换为国内的源,重新启动:

XINFERENCE_MODEL_SRC=modelscope xinference-local --host 0.0.0.0

看日志终于开始下载了:

image-20250313午後41453455

下载完成:

image-20250313午後45657070

三、dify接入

添加供应商:

image-20250313午後45918906

image-20250313午後45958268

修改知识库检索设置:

image-20250313午後50127250

接入成功🏅

四、其他

xinference terminate --model-uid ${model_uid}   # 结束模型

Dify 知识库相关备忘

上一篇文章讲了 Dify 如何安装和简单运行,这一篇接着往下记录,主要是知识库相关的只言片语,参考了官方手册和论坛上的一些讨论。因为现在刚开始接触,可能不够准确,以后会增量更新。

背景

Dify 是一个 LLMOps 服务, 涵盖了大语言模型(如GPT系列)开发、部署、维护和优化的一整套实践和流程。可以大幅简化大模型应用的开发,涉及到模型训练、部署、监控、更新、安全性和合规性等方面。

基于 Dify 可以在不需要太多开发的情况下,快速搭建一个大模型应用。应用中可以调用 Dify 中内置的大量基础能力,比如知识库检索 RAG,大模型调用。通过可插拔式的组合构建大模型应用。

使用 LLMOps 平台前的开发过程:

  1. 数据准备:手动收集和预处理数据,可能涉及到复杂的数据清洗和标注工作,需要编写较多代码。
  2. Prompt Engineering:开发者只能通过调用 API 或 Playground 进行 Prompt 编写和调试,缺乏实时反馈和可视化调试。
  3. 嵌入和上下文管理:手动处理长上下文的嵌入和存储,难以优化和扩展,需要不少编程工作,熟悉模型嵌入和向量数据库等技术。
  4. 应用监控与维护:手动收集和分析性能数据,可能无法实时发现和处理问题,甚至可能没有日志记录。
  5. 模型微调:自行处理微调数据准备和训练过程,可能导致效率低下,需要编写更多代码。
  6. 系统和运营:需要技术人员参与或花费成本开发管理后台,增加开发和维护成本,缺乏多人协同和对非技术人员的友好支持。

一个典型的应用如下所示: 请添加图片描述

简单的 Dify RAG 模块化结构如下所示:

img

一、分段和清洗

在 RAG 的生产级应用中,为了获得更好的数据召回效果,需要对多源数据进行预处理和清洗,即 ETL (extract, transform, load)。为了增强非结构化/半结构化数据的预处理能力,Dify 支持了可选的 ETL 方案:Dify ETL 和 Unstructured ETL 。Unstructured 能够高效地提取并转换你的数据为干净的数据用于后续的步骤。Dify 各版本的 ETL 方案选择:

SaaS 版不可选,默认使用 Unstructured ETL;

社区版可选,默认使用 Dify ETL ,可通过环境变量开启 Unstructured ETL;

文件解析支持格式的差异:

Dify ETL Unstructured ETL txt、markdown、md、pdf、html、htm、xlsx、xls、docx、csv

txt、markdown、md、pdf、html、htm、xlsx、xls、docx、csv、eml、msg、pptx、ppt、xml、epub

不同的 ETL 方案在文件提取效果的方面也会存在差异,想了解更多关于 Unstructured ETL 的数据处理方式,请参考官方文档。 https://docs.unstructured.io/open-source/core-functionality/partitioning

1.1 分段

由于大语言模型的上下文窗口有限,无法一次性处理和传输整个知识库的内容,因此需要对文档中的长文本分段为内容块。

LLM 能否精准地回答出知识库中的内容,关键在于知识库对内容块的检索与召回效果。类似于在手册中查找关键章节即可快速得到答案,而无需逐字逐句分析整个文档。经过分段后,知识库能够基于用户问题,采用分段 TopK 召回模式,召回与问题高度相关的内容块,补全关键信息从而提高回答的精准性。

在进行问题与内容块的语义匹配时,合理的分段大小非常关键,它能够帮助模型准确地找到与问题最相关的内容,减少噪音信息。过大或过小的分段都可能影响召回的效果。

针对 1.0.0 版本的 Dify,一开始创建知识库时候可以选择通用和父子分段两种模式。

通用模式相比,父子模式采用双层分段结构来平衡检索的精确度和上下文信息,让精准匹配与全面的上下文信息二者兼得。

image-20250313午前104925308

这两种模式选定后,后期管理知识库时不可以再修改,单个文档可以针对某个模式下的细节调整(但不可以由父子分段改为通用分段或反过来调整):

image-20250313午前105131714

1.2清洗

为了保证文本召回的效果,通常需要在将数据录入知识库之前便对其进行清理。例如,文本内容中存在无意义的字符或者空行可能会影响问题回复的质量,需要对其清洗。Dify 已内置的自动清洗策略,详细说明请参考 ETL

image-20250312午後52532604

二、索引

2.1 Embedding 模型

Embedding 嵌入是一种将离散型变量(如单词、句子或者整个文档)转化为连续的向量表示的技术。它可以将高维数据(如单词、短语或图像)映射到低维空间,提供一种紧凑且有效的表示方式。这种表示不仅减少了数据的维度,还保留了重要的语义信息,使得后续的内容检索更加高效。

Embedding 模型是一种专门用于将文本向量化的大语言模型,它擅长将文本转换为密集的数值向量,有效捕捉语义信息。

如需了解更多,请参考:《Dify:Embedding 技术与 Dify 知识库设计/规划》。https://mp.weixin.qq.com/s/vmY_CUmETo2IpEBf1nEGLQ

不知道为什么shaw/dmeta-embedding-zh添加不进来,nomic-embed-text是可以的。先不管他了。

image-20250312午後62432648

image-20250312午後62707242

image-20250312午後62807747

2.2 检索设置

知识库在接收到用户查询问题后,按照预设的检索方式在已有的文档内查找相关内容,提取出高度相关的信息片段供语言模型生成高质量答案。

  1. 向量检索

    image-20250313午後55301707

    • TopK 筛选:挑选出与用户查询最相关的文本段落。系统会根据所选模型的上下文窗口大小自动调整选取的段落数量。
    • Score 阈值设置:确定文本段落筛选的相似度门槛,即仅召回分数超过设定值的文本段落。
    • Rerank 重排序模型:将使用第三方 Rerank 模型再一次重排序由向量检索召回的内容分段,提升输出的质量。启用重排序模型后,TopK 和 Score 阈值的设置仅适用于重排序阶段
  2. 全文检索

    索引文档中的所有词汇,从而允许用户查询任意词汇,并返回包含这些词汇的文本片段。

    image-20250313午後61933073

  3. 混合检索

    image-20250313午後62058192

向量检索和全文检索在召回测试中有着不同的表现:

  • 向量检索基于语义理解,能够找到与查询语义相近的文本,即使查询词与文档中的词汇不完全匹配,也可能得到相关的结果;
  • 全文检索主要依赖于关键字的匹配,适用于简短字符的匹配,并倾向于匹配低频词汇。

通过结合多个检索系统,混合检索策略实现了不同检索技术之间的相互补充。

2.3 Rerank

Rerank 重排序模型通过计算候选文档集合与用户查询的语义契合度,进而对这些文档进行基于语义的重新排序,以此提升排序的准确性。该过程涉及对用户查询与每份候选文档之间的相关性分数进行计算,并按照相关性分数从高到低对文档列表进行排序。常见的重排序模型包括:Cohere rerank、bge-reranker 等。重排序通常被置于搜索流程的最终阶段,它特别适用于整合并优化来自不同检索系统的搜索结果。

三、召回测试与优化

完成文档的上传和索引后,我们需要对知识库进行召回测试,以确保能够准确地从知识库中检索出与查询相关的信息。

召回测试可以在App中测试,也可以在知识库中测试。在APP中可以加入多个知识库进行测试。

image-20250313午後63657604

四、其他

知识库请求频率限制

知识库请求频率限制,指一个工作区在知识库中每分钟可执行的最大操作数。这些操作包括数据集创建、文档管理,以及在应用或工作流中的知识库查询。

工具

工具可以扩展 LLM 的能力,比如联网搜索、科学计算或绘制图片,赋予并增强了 LLM 连接外部世界的能力。Dify 提供了两种工具类型:第一方工具自定义工具

参考资料


macOS 使用 cherry studio 备忘

Cherry Studio,很好用的一个大模型的本地客户端。安装的没有什么特别需要提的,这里就记录平时使用的一些点,文章也会持续更新。有啥新的好玩的就补一下到这里。

一、添加模型

点击管理按钮,选择嵌入模型,可以把这几个都添加进去。

image-20250311午後42228468

确认后可以看到我们之前添加嵌入式模型了。

image-20250311午後42329824

二、添加知识库

image-20250311午後42355946

三、编辑助手

image-20250311午後43553787

image-20250311午後43607951

四、助手

image-20250312午前104314545

五、火山引擎/token焦虑

https://www.volcengine.com/

模型广场: https://console.volcengine.com/ark/region:ark+cn-beijing/model?vendor=Bytedance&view=LIST_VIEW

image-20250311午後54727765

image-20250311午後61530066

拷贝拿到model id:

image-20250311午後64056258 连接测试:

image-20250311午後64027542


macOS 私有化部署 deepseek qwq open-webui anythingllm dify 备忘

这篇文章记录我在 macOS 下使用 Ollama 安装 通义千问 QwQ-32B 推理模型/ DeepSeekR1-llama-70b 和下游三个软件 Open-webui/AnythingLLM/Dify 的过程,以备后续查阅。

我的 Mac studio 是 96G 的 M2 Max,macOS 15.2。日常使用我感觉 QwQ已经很不错了。

先给这篇文章的几个工具做简单的介绍:

  • ollama,一个简单易用的大语言模型的部署工具。

    同类还有vLLM,吞吐量和扩展性更好,但生态较弱,部署相对复杂。

  • open-webui,一个web前端工具,用于对接ollama启动的大语言模型。

    同类的还有 chatbox等客户端。

专业术语:

  • RAG

    检索增强生成(RAG)是一种将外部知识检索与大语言模型(LLM)相结合的技术。传统的大语言模型虽然拥有丰富的知识,但知识更新可能不及时,或者在特定领域的知识储备不足。RAG 通过在生成回答之前,先从外部知识源(如文档数据库、网页等)中检索相关信息,然后将这些信息与用户的问题一起输入到大语言模型中,从而生成更准确、更具时效性的回答。

接下来是本地知识库搭建开源方案:

  1. AnythingLLM:开源企业级文档聊天机器人,支持本地部署和多用户权限管理,通过工作区隔离文档,确保数据隐私。适合注重隐私与定制化的企业级RAG应用。
  2. Dify:开源LLM应用开发平台,集成数百种模型,支持可视化工作流编排和高质量RAG引擎,覆盖对话与自动化场景。开发者友好,适合构建多样化AI应用。
  3. RAGFlow:端到端RAG引擎,以深度文档解析见长,支持表格、图片等复杂格式处理,提供可追溯的答案引用以降低幻觉。文档处理能力突出,适合高精度知识检索场景。

核心差异点:

维度 AnythingLLM Dify RAGFlow
数据隐私 完全本地化,无数据外传 支持本地部署,但依赖部分云服务 本地部署为主,强调数据控制
开发门槛 低(开箱即用) 中(需配置工作流与模型) 高(需调整文档解析参数)
文档处理能力 基础格式(PDF/TXT/DOCX) 常规格式(PDF/PPT) 复杂格式(影印件、表格、音频)
定制化能力 有限(依赖预置模板) 高(支持自定义工具与流程) 中(需调整检索策略与切片规则)
适用规模 中小型知识库 中大型企业应用 企业级复杂文档处理

也问了deepseek他们的区别,这是回答:

image-20250311午後14441412

ollama

Ollama 是简单易用的LLM部署工具。正常安装即可:

image-20250311午前114150140

ollama run deepseek-r1:70b
ollama run qwq

image-20250310午後42838013

可以直接运行然后对话:

image-20250310午後50543561

单请求qwq下占用显存大概20G,功率100W(平时待机8W)。

image-20250310午後50629872

image-20250310午後50729543

如果使用其他的UI客户端,则不需要run,只要把 ollama 应用打开就好了。

ollama可以简化我们使用大模型的安装问题。当然既然简化了,就说明它在生产环境上使用不如其他的工具强大。以下是一些其他替代工具,我有空也会研究下:

  • LMDeploy,能够针对内存管理、并发处理和负载均衡等多个方面进行细致的优化。
  • vLLM,vLLM通过 PagedAttention 高效地管理attention中缓存的张量,实现了比HuggingFace Transformers高14-24倍的吞吐量。

open-webui

可以使用 open-webui 进行简单的问答。

参考官方文档运行pip安装的open-webui。由于我用miniconda管理python环境,所以需要先激活环境。如果你没有使用,则不需要关注第一行:

conda active pandas
open-webui serve

image-20250310午後44425976

输入账号密码登录即可。左上角可以选择本机上的模型。

image-20250310午後44746788

同类的我还使用 chatbox 和 浏览器的插件Page Assist

  • Page Assist

    利用本地运行的AI模型,在浏览网页时进行交互.

    image-20250311午前101852651

  • chatbox

    Chatbox AI 是一款 AI 客户端应用和智能助手,支持众多先进的 AI 模型和 API,可在 Windows、MacOS、Android、iOS、Linux 和网页版上使用。

    image-20250311午後120144840

    image-20250311午前102318334

  • Cherry Studio

    轻量级的桌面端工具,集成多种开源模型,支持离线问答,适合个人用户快速验证创意。

    image-20250311午前115944068

    image-20250311午後120212295

anythingllm

开源企业级文档聊天机器人,支持本地部署和多用户权限管理,通过工作区隔离文档,确保数据隐私。适合注重隐私与定制化的企业级RAG应用。

只是粗浅使用,我感觉效果不好,可能还要调整配置吧。先浅尝则止,到此为止了。官方文档

image-20250310午後50214159

image-20250310午後50921579

image-20250310午後51548611

上传文档:

image-20250310午後52141565

几乎把我gpu和内存吃满了:

IMG_3326

工作区中共享文档:

image-20250310午後52733477

image-20250310午後52841116

seve后pin一下:

image-20250310午後53332606

就可以在当前工作区共享文档的内容了。

Dify

Dify 是一个开源的大语言模型(LLM)应用开发平台,融合了后端即服务(Backend as Service, BaaS)和 LLMOps 理念,旨在简化和加速生成式AI应用的创建和部署。它支持多种大型语言模型(如OpenAI的GPT系列、Claude3等),并提供强大的数据集管理功能、可视化的 Prompt 编排以及应用运营工具。

安装包括原生安装和容器安装两种方式。推荐使用容器安装,因为原生的组件太多辣:

  • 数据库:PostgreSQL 或 MySQL。
  • 缓存:Redis。
  • 向量数据库:Weaviate。
  • 代理服务:Nginx 或 Squid。
  • Dify 源码运行:需配置 Python 环境、依赖库及前后端构建。

1. 安装

wget https://github.com/langgenius/dify/archive/refs/tags/1.0.0.zip
unzip 1.0.0.zip
cd dify-1.0.0/docker
cp .env.example .env  # 修改端口等参数(可选)

如果需要修改nginx映射的端口,则修改 .env 文件,例如我的:

image-20250313午後55426540

国内拉不到docker.io,需要修改容器源的地址,拷贝内容到下图位置,重启docker:

"registry-mirrors":[
    "https://9cpn8tt6.mirror.aliyuncs.com",
    "https://registry.docker-cn.com",
    "https://mirror.ccs.tencentyun.com",
    "https://docker.1panel.live",
    "https://2a6bf1988cb6428c877f723ec7530dbc.mirror.swr.myhuaweicloud.com",
    "https://docker.m.daocloud.io",
    "https://hub-mirror.c.163.com",
    "https://mirror.baidubce.com",
    "https://your_preferred_mirror",
    "https://dockerhub.icu",
    "https://docker.registry.cyou",
    "https://docker-cf.registry.cyou",
    "https://dockercf.jsdelivr.fyi",
    "https://docker.jsdelivr.fyi",
    "https://dockertest.jsdelivr.fyi",
    "https://mirror.aliyuncs.com",
    "https://dockerproxy.com",
    "https://mirror.baidubce.com",
    "https://docker.m.daocloud.io",
    "https://docker.nju.edu.cn",
    "https://docker.mirrors.sjtug.sjtu.edu.cn",
    "https://docker.mirrors.ustc.edu.cn",
    "https://mirror.iscas.ac.cn",
    "https://docker.rainbond.cc"
    ]

image-20250311午前112210435

执行启动命令:

docker-compose up -d

image-20250311午前112038916

最终结果:

image-20250311午前112418148

image-20250311午後44629642

有一个比较奇怪的地方,我本机已经跑了nginx了。

brew services start nginx

也占用的80端口和443端口。但是挺奇怪,它和Dify的80/443竟然不冲突?!发现原来是因为docker监听的是ipv6地址,而我默认的nginx监听的是ipv4的地址:

lsof -i :80 -n -P

image-20250311午前113457011

需要修改nginx映射端口的话,修改 .env 文件里EXPOSE_NGINX_PORTEXPOSE_NGINX_SSL_PORT配置即可。

后来我改成了12080端口:

image-20250317午前103310118

访问:http://localhost

image-20250311午前112559670

设置完成后就进入Dify了,右上角设置ollama内容:

image-20250311午前114930583

image-20250311午前114946244

配置Ollama信息:

image-20250311午前115302700

2. 增加一个nomic-embed-text模型

nomic-embed-text,这是一个文本向量化的模型,做向量化检索时使用。

ollama pull nomic-embed-text

image-20250311午前115605895

image-20250311午後120400580

此时有两个模型了:

image-20250311午後120504830

3. 创建知识库

  1. 选择数据源:

    image-20250311午後120722362

  2. 数据分段与清洗

    image-20250311午後120814202

  3. 处理

    等待完成即可。

    image-20250311午後120839573

    处理的时候占用的CPU/GPU/内存大概如下:

    image-20250311午後121139696

    image-20250311午後121124422

    image-20250311午後121040049

  4. 完成

    image-20250311午後121245488

4. 创建聊天助手

image-20250311午前113054583

选择知识库,开始提问。明显感觉比anythingLLM靠谱。

image-20250311午後121812581

5. 工作流

image-20250311午後121940119

GitHub上有一些有趣的工作流,可以看看:Awesome-Dify-Workflow

image-20250311午後125954225

比如:《完蛋!我被LLM包围了!》

Xnip2025-01-21_09-39-18.jpg

RagFLow

1. 安装

git clone https://github.com/infiniflow/ragflow.git
cd ragflow/docker
cp docker-compose-macos.yml docker-compose.yml

改一下docker-compose.yml 的 80和443端口,然后修改.env,将macOS的注释去了。

vi .env

image-20250311午後12426566

增加一个环境变量:

 export HF_ENDPOINT=https://hf-mirror.com

运行:

docker-compose up -d

参考文章:https://zhuanlan.zhihu.com/p/701768574

2. 修bug

看这个提示,似乎是不支持macOS?

image-20250311午後52957874

没道理,我看这个bug他们已经修复了:https://github.com/infiniflow/ragflow/issues/5171

换了最新的版本v0.17.1,还有问题。又翻了下:有大佬给解决办法了,直接本地build这个基础镜像:

git clone https://github.com/infiniflow/ragflow.git
cd ragflow/
pip3 install huggingface_hub nltk
python3 download_deps.py
docker build -f Dockerfile.deps -t infiniflow/ragflow_deps .
docker build -f Dockerfile -t infiniflow/ragflow:nightly .
docker build --build-arg LIGHTEN=1 -f Dockerfile -t infiniflow/ragflow:nightly-slim .

ps:注意要git下载啊! nightly 的镜像还要拷贝 .git 目录,我服了。

image-20250311午後62901992

下载有点狠,不知道要占用多少空间,本不富裕的Mac硬盘又要雪上加霜:

image-20250311午後54104539

下载完了,开始build:

image-20250311午後61913446

build好花时间啊。

image-20250311午後65614233

3. 运行

image-20250311午後71141139

4. 添加点文件

image-20250311午後72107295

5. 添加模型

image-20250311午後72257003

image-20250311午後72516431

image-20250311午後72640838

6. 待续

image-20250311午後72742368

7. 待续

参考资料


在 macOS 上切换到 Homebrew 版的 Docker Compose

在折腾 Docker ,发现 docker-compose 默认是 Docker Desktop 自带的版本,路径是:

/usr/local/bin/docker-compose -> /Applications/Docker.app/Contents/Resources/bin/docker-compose

但我更希望使用 Homebrew 安装的最新的版本,比如:

/opt/homebrew/Cellar/docker-compose/2.33.1/bin/docker-compose

为了让 docker-compose 指向 Homebrew 版本:

1. 移除 Docker Desktop 自带的 docker-compose

sudo rm /usr/local/bin/docker-compose

2. 软链接到 Homebrew 版本

sudo ln -s /opt/homebrew/bin/docker-compose /usr/local/bin/docker-compose

3. 验证

which docker-compose

输出:

/usr/local/bin/docker-compose

再确认版本号:

docker-compose version

使用 prometheus 优化 WireGuard 监控与可视化

最近心血来潮把wireguard的监控搬到 prometheus 上来,在 Grafana 中动态展示 WireGuard 网络的健康状态,如果某条断联了,由prometheus进行告警,于是便有了这篇文章。

1. WireGuard Exporter 安装

参考:MindFlavor/prometheus_wireguard_exporter,为每一个节点安装exporter:

version: '2.4'

services:
  wgexporter:
    image: mindflavor/prometheus-wireguard-exporter
    network_mode: host
    container_name: wg-exporter
    cap_add:
      - NET_ADMIN
    privileged: true
    command: ["--prepend_sudo", "true"]
    environment:
      - PROMETHEUS_WIREGUARD_EXPORTER_VERBOSE_ENABLED=true
      - PROMETHEUS_WIREGUARD_EXPORTER_PORT=12386
    restart: always

相关的配置参考github即可。我是用了两个配置:

  • PROMETHEUS_WIREGUARD_EXPORTER_VERBOSE_ENABLED,详细模式
  • PROMETHEUS_WIREGUARD_EXPORTER_PORT,自定义端口

2. Prometheus 采集 WireGuard 状态

在 Prometheus 的配置文件 prometheus.yml 中添加 scrape_configs 来收集 WireGuard 的指标:

scrape_configs:
  - job_name: 'wireguard_exporter'
    static_configs:
      - targets:
          - 'wg-exporter.nanjing1.local:12386'
          - 'wg-exporter.chengdu2.local:12386'
    relabel_configs:
      - source_labels: [__address__]
        regex: 'wg-exporter\.([^.]+)\..*'
        target_label: src_peer
    metric_relabel_configs:
       - source_labels: [allowed_ips]
         regex: .*100\.100\.100\.100/32.*
         action: replace
         target_label: target_peer
         replacement: OnePlus

此配置帮助我从每个节点的 instance 中提取出 nanjing1 或 chengdu2 作为新的 src_peer 标签,从结果中将 100.100.100.100 的节点标记为OnePlus节点,增加可读性。

这里涉及到了 relabel_configsmetric_relabel_configs 两个配置项,能够帮助我们灵活地重命名、修改、删除或过滤标签以及指标。常用于数据抓取(scrape_configs)和指标数据的处理(metric_relabel_configs)

  • relabel_configs:当我们要修改或过滤抓取目标时使用。例如,改变目标实例的名称,或选择性地抓取某些目标。
    • source_labels:一个标签列表,Prometheus 会从这些标签中提取信息进行后续处理。它的内容可以是任何来自目标的标签。
    • target_label:表示你希望修改或创建的目标标签的名称。如果你想修改现有的标签值,指定该标签的名称即可。如果你想添加新的标签,则可以指定新的标签名称。
    • regex:一个正则表达式,用来匹配标签的值。如果正则表达式匹配成功,就可以根据 replacement 替换值或执行其他操作。
    • replacement:如果 regex 匹配成功,可以用 replacement 字符串替换标签值。如果 replacement 为一个空字符串,则会删除匹配的标签
  • metric_relabel_configs:已经抓取了指标数据,但想对这些数据进行修改或过滤时使用。例如,修改指标标签的值,重命名指标,或删除一些不需要的指标。
    • source_labels:一个标签列表,类似于 relabel_configs,它指定要修改的标签。
    • target_label:希望修改或添加的指标标签的名称。
    • regex:用于匹配标签值的正则表达式。
    • replacement:当 regex 匹配成功时,用来替换标签值或创建新的标签。
    • action:定义如何处理匹配的指标,可以是:
      • replace:替换标签值。
      • keep:保留该指标数据。
      • drop:丢弃该指标数据。

3. Grafana 可视化

  1. 可视化握手时间

    (time() - wireguard_latest_handshake_seconds{src_peer!="",target_peer!=""})
    
  2. 可视化连接速率

    irate(wireguard_sent_bytes_total{node=~"a1|b1",target_peer=~"a2|b2"}[$interval])