给博客换了个主题：从 Hugo NexT 到自写的 Zhi/posts/aihelper/hugo-theme-zhi-intro/AI博客Hugo主题开发ZhiCSS前端<![CDATA[ 为什么换 这个博客之前用的 Hugo NexT，fork 了一份自己做修改。NexT 本身是个功能很全的主题，但在"自己改"这件事上，体验不太行。
问题集中在几件事上：
SCSS 套娃。101 个 SCSS 文件，三层目录嵌套。_common/components/post、_common/components/third-party、_common/outline/sidebar……改个样式得先搞清楚文件在哪、变量在哪定义、哪个 scheme 在 override。不是不能改，是改一次得翻半天。
四套布局方案。Gemini、Mist、Muse、Pisces，每套都是一套独立的 CSS。我只用 Gemini，但其他三套的代码还在那里，占了大量体积。
JS 耦合度高。9 个 JS 文件，next-boot.js 是总入口，pjax.js 做页面无刷新切换，config.js 读取主题配置。几个文件互相引用，想加个功能得理解整个启动流程。
改不动。主题是 fork 来的，上游更新了不敢合并——自己的改动散落在各个文件里，merge conflict 一堆。最后的结果就是 fork 彻底冻住，自己在一个固定版本上打补丁。
风格对不上。我有个工作室的官网，走的干净简约路线——大留白、无装饰、内容居中。NexT 是从 Hexo NexT 移植过来的，骨架里带着论坛/门户时代的审美：侧边栏信息密度高、配色选项多、组件叠加层次深。博客和工作室是同一个品牌，两个站放在一起看着像两个人做的，这事儿忍了很久。
总之，主题功能很多，但我只想改几个地方的时候，每次都要跟整个体系的复杂度搏斗。
换什么思路 想清楚了几个原则：
不要 SCSS。纯 CSS + CSS Variables 足够搞定主题系统，不用多一层预处理 不要构建工具。Hugo 自带 resources.Get → minify → fingerprint 管线，webpack 和 vite 都不需要 功能可开关。每个功能一个 feature flag，关了就不加载对应的 CSS 和 JS，不浪费字节 文件要少。能一个 CSS 文件解决的事不要拆成五个 然后就开工了。整个主题从零开始，结合 AI 写代码，前前后后花了大约两周。
Zhi 主题做了什么 主题叫 Zhi。名字取自我名字中间那个字，也有几层意思：紫 … ]]>智谱 Coding Plan × Oh My OpenCode：多模型编排配置实战/posts/aihelper/zhipuai-coding-plan-oh-my-opencode-setup/AI开发工具智谱AIGLM-5GLM-5.1Oh-My-OpenCodeOpenCode多模型编排AI编程<![CDATA[ 为什么折腾这个 用 AI 写代码这事儿，单模型和多人模型的差距越来越大。一个模型再强，也干不过一组各司其职的模型并行推进。
Oh My OpenCode（下文简称 OmO）是 OpenCode 生态里的多模型编排插件，11 个 Agent 各有分工，48 个 Hook 贯穿整个生命周期。智谱的 Coding Plan 则提供了 GLM 全系列的模型访问。两者搭配起来，就能按角色分配不同的模型——编码强的干编码，推理强的干推理，免费的干杂活。
这篇文章记录我的完整配置过程。
GLM 模型家族 智谱 Coding Plan 目前可用的编程相关模型：
模型 干什么用的 GLM-5 开源旗舰，744B MoE，200K 上下文，SWE-bench 77.8% GLM-5-turbo 闭源，在 GLM-5 基础上专门给 Agent 工作流做了优化，工具调用错误率从 2-6% 降到 0.67%，速度快了约 36% GLM-5.1 后训练优化的版本，编码得分从 35.4 涨到 45.3（+28%），相当于 Claude Opus 4.6 的 94.6% GLM-4.7 推理质量扎实，max 变体支持扩展思考 GLM-4.7-flash 速度优先的 4.7 变体 GLM-5v-turbo 多模态，能看图 这三个 “5 系” 容易搞混，关系是这样的：
1 2 3 GLM-5 ← 开源基座，啥都能干，但偶尔抽风 ├── 5-turbo ← 给 Agent 优化：快、稳、工具调用靠谱 └── 5.1 ← 给编码强化：代码质量涨了 28% 选型看需求就行：要编码选 5.1，要稳定跑 Agent 选 5-turbo，要推理选 4.7，要看图选 5v-turbo，要快选 4.7-flash。
OmO 的 Agent 体系 OmO 的思路很直接：每个 Agent 用自己的系统提示词、工具权限和模型。不是一刀切。
Agents Agent 干什么 需要什么样的模型 Sisyphus 主编排，任务分解和调度 最强编码 Prometheus 规划，需求澄清和计划制定 长链稳定，工具调用靠谱 Oracle 架构顾问，只读分析 深度推理 Librarian 文档和 API 检索 理解能力 Explore 代码库搜索 快 Metis 预规划咨询，找盲点 深度推理 Momus 计划评审 … ]]>Windows Defender 排除项批量清理指南/posts/windows/windows-defender-exclusion-cleanup/杂项WindowsPowerShellWindows Defender安全<![CDATA[ 当 Windows Defender 的排除项列表积累了大量无用条目时，可以通过 PowerShell 命令一键批量清理本文将详细介绍整个操作流程，包括备份、清理和验证三个步骤。
准备工作 修改 Defender 配置需要管理员权限，请按以下步骤打开具有足够权限的终端：
点击 Windows 开始菜单，搜索 PowerShell 在搜索结果中右键点击 Windows PowerShell，选择 以管理员身份运行 在弹出的用户账户控制（UAC）窗口中点击「是」确认授权 步骤一：备份现有排除项（强烈推荐） 在清理前，建议先备份当前的排除项列表，防止误删需要保留的配置。后续如需恢复，可从备份文件中找回。
在打开的管理员 PowerShell 窗口中，复制粘贴以下命令并回车执行：
powershell 1 2 3 # 将所有排除项备份到 C 盘根目录的备份文件中 Get-MpPreference | Select-Object ExclusionPath, ExclusionExtension, ExclusionProcess | Export-Csv -Path "C:\Defender_Exclusions_Backup.csv" -NoTypeInformation 执行完成后，您可以在 C:\ 盘根目录找到名为 Defender_Exclusions_Backup.csv 的备份文件，其中保存了当前所有的排除项配置。
步骤二：执行批量清理命令 备份完成后，执行以下命令即可一键清理所有类型的排除项（包括路径排除、文件扩展名排除、进程排除）：
powershell 1 2 3 4 5 6 7 # 批量清理所有 Defender 排除项 Get-MpPreference | Select-Object -Property ExclusionExtension | ForEach-Object { if ($_.ExclusionExtension -ne $null) { Remove-MpPreference -ExclusionExtension $_.ExclusionExtension } } Get-MpPreference | Select-Object -Property ExclusionPath | ForEach-Object { if ($_.ExclusionPath -ne $null) { Remove-MpPreference -ExclusionPath $_.ExclusionPath } } Get-MpPreference | Select-Object -Property ExclusionProcess | ForEach-Object { if ($_.ExclusionProcess -ne $null) { Remove-MpPreference -ExclusionProcess $_.ExclusionProcess } } 说明：该命令会自动判断不同类型的排除项是否存在，即使某一类排除项为空也不会报错，会自动跳过。
步骤三：验证清理结果 执行完清理命令后，可通过以下命令查看当前的排除项列表，确认是否已全部清空：
powershell 1 2 # 查看当前剩余的排除项 Get-MpPreference | Select-Object ExclusionPath, ExclusionExtension, ExclusionProcess 如果输出结果中三个属性都显示为空，说明清理已完成。
注意事项 不可逆操作 清理完成后，所有之前添加的排除项都会被移除，Windows Defender 会恢复对所有文件、进程的扫描。如有需要保留的排除项，清理后需重新添加。
权限问题 如果执行命令时提示「权限不足」，请确认已以管理员身份运行 PowerShell。普通用户权限无法修改 Defender 的系统配置。
系统兼容性 该方法适用于以下 Windows 版本：
Windows 10 Windows 11 Windows Server 2016 及以上版本 ]]>国产大模型资源与成本对比：GLM-5 / Kimi K2.5 / MiniMax M2.7/posts/aihelper/domestic-llm-cost-comparison/AI大模型GLM-5KimiMiniMax智谱AIGPU部署<![CDATA[ 概览 本文对比三款主流国产大模型的资源需求与使用成本，帮助开发者根据场景选择合适的方案。
模型 厂商 架构 最低可部署显存 API 是否可用 GLM-5 智谱AI Dense（多版本） 24GB（8B） ✅ Kimi K2.5 月之暗面 MoE（未公开） 24GB（轻量版） ✅ MiniMax M2.7 MiniMax MoE 2300亿 暂未开源 ✅ GLM-5（智谱AI） 版本与硬件需求 GLM-5 提供 4 个参数版本，是目前覆盖范围最广的国产大模型。
GLM-5-8B — 中小场景首选
最低配置：CPU 16核/32GB + RTX 3090（24GB）；推荐配置：CPU 32核/64GB + RTX 4090 或 A10（24GB）；量化运行：4-bit 量化后 16GB 显存即可；上下文 128K，纯文本。
GLM-5-40B — 企业级主力
最低配置：单张 A100（80GB）；推荐配置：H100（80GB）或 2×A100（80GB）；上下文 128K，支持文本/多模态。
GLM-5-120B — 大规模推理
最低/推荐：4×A100 或 4×H100（80GB×4）；上下文 256K，支持文本/多模态。
GLM-5-700B — 超大规模（仅大厂）
最低配置：8×H100（80GB）；推荐配置：16×H100（80GB）；上下文 512K+，支持文本/多模态。
软件环境：Linux（Ubuntu 20.04+ / CentOS 7+），依赖 CUDA 11.8+、Python 3.8+、PyTorch 2.0+。仅 8B 支持 Windows。
成本 模式 8B 40B 120B 700B 硬件采购 1-2 万 10-15 万 40-60 万 200-300 万 年运维 ~2000 元 1-2 万 5-8 万 30-50 万 云租赁 3-5 元/h 20-30 元/h 80-120 元/h 500-800 元/h API 输入 0.01-0.02 元/千Token 0.06-0.12 元/千Token 0.2-0.4 元/千Token 未公开 API 输出 0.03-0.06 元/千Token 0.18-0.36 元/千Token 0.6-1.2 元/千Token 未公开 Kimi K2.5（月之暗面） 版本与硬件需求 Kimi K2.5 采用 … ]]>基于 ESP01 主板的温湿度监控开发/posts/iot/esp-01-dht11/IOTIOTArduino<![CDATA[ 引言 在物联网应用中，温湿度监控是一个常见且重要的需求。ESP01 作为一款低成本、低功耗的 Wi-Fi 模块，为实现温湿度监控提供了一个便捷的解决方案。本文将详细介绍如何使用 ESP01 主板进行温湿度监控开发，包括硬件连接、代码实现和功能解析。
硬件准备 ESP01 主板：核心控制模块，负责数据采集和网络通信。 DHT 温湿度传感器：用于测量环境的温度和湿度。 杜邦线：用于连接 ESP01 和 DHT 传感器。 将 DHT 传感器的 VCC 引脚连接到 ESP01 的 3.3V 引脚，GND 引脚连接到 GND，数据引脚连接到 ESP01 的指定引脚（代码中为 DHTPIN）。
代码实现 引入必要的库 cpp 1 2 3 4 5 6 7 8 9 #include <ESP8266WiFi.h> #include <WiFiUdp.h> #include <NTPClient.h> #include <PubSubClient.h> #include <ESP8266WebServer.h> #include <ArduinoJson.h> #include <DHT.h> #include "app_config.h" #include "wifi_config.h" 这些库分别用于处理 Wi-Fi 连接、NTP 时间同步、MQTT 通信、Web 服务器、JSON 数据处理和 DHT 传感器读取。
初始化相关对象 cpp 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 // 创建一个UDP对象用于NTP客户端 WiFiUDP ntpUDP; NTPClient timeClient(ntpUDP, ntpserver, 8 * 3600, 60000); // 创建WiFi和MQTT客户端对象 WiFiClient espClient; PubSubClient client(espClient); uint32_t delayMS; unsigned long globalPreviousMillis = millis(); unsigned long globalCurrentMillis = millis(); … ]]>eBPF系列之：DeepFlow 扩展协议解析实践（MongoDB协议与Kafka协议）/posts/ebpf/deepflow-agent-proto-dev/eBPFTcpDeepFloweBPF<![CDATA[ 概述： 如何分析一个协议(MongoDB) 协议文档的分析思路 MongoDB协议操作码说明表 对最常见的操作码OP_MSG分析 在DeepFlow Agent扩展一个协议解析采集 DeepFlow Agent的开发文档概要 代码指引 定义一个协议，并用一个常量标识。 为新协议准备解析逻辑 定义结构体 实现 L7ProtocolParserInterface 利用Wasm插件扩展DeepFlow的协议采集 Kafka协议分析 Kafka的Header和Data概览 Kafka的Fetch API Kafka的Produce API Kafka协议DeepFlow Agent原生解码 DeepFlow Agent的 Wasm 插件 Wasm Go SDK 的框架 插件代码指引 结语 原生Rust扩展 Wasm插件扩展 附录 概述： MongoDB 目前使用广泛，但是缺乏有效的可观测能力。 DeepFlow 在可观测能力上是很优秀的解决方案，但是却缺少了对 MongoDB 协议的支持。 该文是为 DeepFlow 扩展了 MongoDB 协议解析，增强 MongoDB 生态的可观测能力，简要描述了从协议文档分析到在 DeepFlow 内实现代码解析的过程拆解。
如何分析一个协议(MongoDB) 协议文档的分析思路 首先要从官方网站找到协议解析的文档，在协议文档《mongodb-wire-protocol#standard-message-header》中，可以看到MongoDB的协议头结构体描述如下：
c 1 2 3 4 5 6 7 struct MsgHeader { int32 messageLength; // total message size, including this int32 requestID; // identifier for this message int32 responseTo; // requestID from the original request // (used in responses from the database) int32 opCode; // message type } 上述结构代码理解为下图所示：
注意，在协议文档《mongodb-wire-protocol》有一段说明，MongoDB协议是用了字节 … ]]>VictoriaMetrics的指标流聚合能力应用/posts/opentelemetry/stream-metrics-one/PrometheusVictoriaMetricsPrometheusVictoriaMetrics<![CDATA[ 社区VM对指标流聚合能力分析与问题 VictoriaMetrics开源项目的原生能力 VictoriaMetrics项目中的流聚合能力是从1.86版本开始整合到vmagent的，具体可参考： https://github.com/VictoriaMetrics/VictoriaMetrics/issues/3460 从源码分析来看，流集合能力如图：
核心计算的代码在pushSample函数中有描述：
go 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 func (as *totalAggrState) pushSample(inputKey, outputKey string, value float64) { currentTime := fasttime.UnixTimestamp() deleteDeadline := currentTime + as.intervalSecs + (as.intervalSecs >> 1) again: v, ok := as.m.Load(outputKey) if !ok { v = &totalStateValue{ lastValues: make(map[string]*lastValueState), } vNew, loaded := as.m.LoadOrStore(outputKey, v) if loaded { v = vNew } } sv := v.(*totalStateValue) sv.mu.Lock() deleted := sv.deleted if !deleted { lv, ok := sv.lastValues[inputKey] if !ok { lv = &lastValueState{} sv.lastValues[inputKey] = lv } d := value if ok && lv.value <= value { d = value - lv.value } if ok || currentTime > … ]]>eBPF系列之：Pixie浅剖析/posts/ebpf/pixie-try/eBPFeBPF<![CDATA[ 部署过程和指令参考：pixie install
Pixie平台主要由以下组件组成： Pixie Edge Module 边缘模块(PEM): Pixie’s agent, installed per node. PEMs use eBPF to collect data, which is stored locally on the node. Pixie的代理，安装在每个节点上。PEM使用eBPF收集数据，这些数据存储在节点本地。
Vizier: Pixie’s collector, installed per cluster. Responsible for query execution and managing PEMs. Pixie的收集器，安装在每个集群上。负责查询执行和管理PEM。
Pixie Cloud: Used for user management, authentication, and data proxying. Can be hosted or self-hosted. 用于用户管理、身份验证和数据代理。可以托管或自托管。
Pixie CLI: Used to deploy Pixie. Can also be used to run queries and manage resources like API keys. 用于部署Pixie。还可用于运行查询和管理API密钥等资源。
Pixie Client API: Used for programmatic access to Pixie (e.g. integrations, Slackbots, and custom user logic requiring Pixie data as an input) 用于对Pixie进行编程访问（例如，集成、Slackbots和需要Pixie数据作为输入的自定义用户逻辑）
本地部署涉及的组件和步骤： 初始化 日常运行时 Pixie自动收集以下数据：
Protocol traces: Full-body messages between the pods of your applications. Tracing currently supports the following list of protocols. For more information, see the Request Tracing, Service Performance, and Database Query Profiling tutorials.
Resource metrics 资源指标: CPU, memory and I/O metrics for your pods. For more information, see the Infra Health tutorial. 单元的CPU、内存和I/O指标。有关详细信息，请参见基础架构运行状况教程.
Network metrics 网络度量: Network-layer and connection-level RX/TX statistics. For more information, see the Network Monitoring tutorial. 网络层和连接级RX/TX统计信息。有关详细信息，请参阅网络监视教程。
JVM metrics: JVM memory management metrics for Java applications. Java应用程序的JVM内存管理度量。
Application CPU profiles: Sampled stack traces from your application. Pixie的连续性能分析器始终处于运行状态，以便在您需要时帮助识别应用程序的性能瓶颈。目前支持编译语言（Go、Rust、C/C ++）。有关详细信息，请参阅 Continuous Application Profiling 教程.
私有云端部署组件及架构： 涉及到的镜像： olm组件管理pixie 该组件部署要重制索引镜像指向国内仓库，并在国内仓库一一完成镜像指向配置。 elastic-operator 部署 elastic集群 nats集群组件 postgres gcr.io/pixie-oss/pixie-dev/cloud/api_server_image gcr.io/pixie-oss/pixie-dev/cloud/artifact_tracker_server_image gcr.io/pixie-oss/pixie-dev/cloud/auth_server_image gcr.io/pixie-oss/pixie-dev/cloud/config_manager_server_image gcr.io/pixie-oss/pixie-dev/cloud/proxy_server_image gcr.io/pixie-oss/pixie-dev/cloud/indexer_server_image gcr.io/pixie-oss/pixie-dev/cloud/metrics_server_image gcr.io/pixie-oss/pixie-dev/cloud/plugin_server_image gcr.io/pixie-oss/pixie-dev/cloud/profile_server_image gcr.io/pixie-oss/pixie-dev/cloud/project_manager_server_image gcr.io/pixie-oss/pixie-dev/cloud/scriptmgr_server_image gcr.io/pixie-oss/pixie-dev/cloud/cron_script_server_image gcr.io/pixie-oss/pixie-dev/cloud/vzconn_server_image gcr.io/pixie-oss/pixie-dev/cloud/vzmgr_server_image gcr.io/pixie-oss/pixie-dev/cloud/plugin/load_db 用户管理，脚本管理，任务执行管理记录在Postgres，Es用于缓存计算。 ]]>闲聊一下CPU时序和现代操作系统二三事/posts/opentelemetry/talk-about-cpu-timer/LinuxCPULinux<![CDATA[ 时分系统和Linux 首先我们补习一下时分系统，时分系统是一个非常重要的操作系统概念,它最大限度地提高了运算机的利用率,是实现多道程序并发执行的重要手段。 我们日常工作用到的Linux系统 内核也采用了时分系统的思想,主要体现在以下几个方面:
时间片: Linux 使用时间片机制对 CPU 进行时间分割,每个进程只能执行一个时间片的时间,然后交出 CPU 给其他进程运行。这实现了 CPU 时间的共享与公平分配。
上下文切换: 当时间片用完或进程主动放弃 CPU 时,会进行上下文切换,保存当前进程上下文并恢复下一个进程上下文。这使得 CPU 可以高效地在不同进程间切换。
进程调度: Linux 使用 CFS 调度器根据每个进程的时间片选择最适合运行的进程,这是时分系统思想的体现。不同的调度策略可以实现不同的时分效果。
中断机制: Linux 使用中断机制实现对时间的管理与调度。时钟中断可以在时间片用完时通知内核进行上下文切换与调度。这为时分系统提供了动力基础。
时钟事件: Linux 基于时分系统管理各种时间事件,如定时器、睡眠唤醒等。这需要内核根据时钟中断来进行管理与调度。
除此之外,时分系统的思想在 Linux 中还体现在:
多道程序设计 Linux 支持多道程序并发运行,这也依赖于时分系统实现的 CPU 时间共享机制。 实时性 通过设置实时调度策略和对中断处理的优化,Linux 可以提供较好的实时响应性能。这也需要时分系统的支持。 睡眠唤醒 进程可以主动睡眠释放 CPU,这需要时分系统在其唤醒后重新调度其 CPU 时间。 同步机制 Linux 提供多种同步机制,这都需要时分系统来实现进程之间的协调与调度。 时分系统是 Linux 实现多道程序、并发执行、实时响应、时间管理等功能的基础。它使 Linux 能够充分利用 CPU 资源,实现高效率与公平的调度。时分系统的思想贯穿 Linux 内核的方方面面,是理解 Linux 调度与实现并发执行的重要概念。
聊一下Linux的时序 接下来我们需要提前了解几个概念：
Some Words Jiffies 有更多兴趣的可以看看《内核时钟问题 》
jiffies是一个非常重要的Linux内核变量,它代表了自系统启动以来的时间戳,以时钟中断的个数来表示。它有以下特点:
jiffies以时钟中断的个数来衡量时间,所以它的精度由时 … ]]>监控系统企业架构演进史-拨测监控/posts/opentelemetry/prometheus-evolution-history-three/OpenTelemetryPrometheusPrometheus监控拨测架构<![CDATA[ 前情概述： 在《监控系统企业架构演进史-跨地域混合云》中，监控系统已经逐步成熟且企业化发展。 这一章节简单讲述一下期间的拨测能力搭建，以下是这套系统的发展史，在监控平台搭建的过程中，内部监控采集还不足以满足企业业务需求，在计划发展apm之前，异地拨测的黑匣子监控也纳入了该系统的一个子功能。
拨测监控架构的实现 系统搭建⾯临需解决的问题：
⻓期以来企业在公⽹监控，乃⾄⽤⼾侧最后⼀公⾥的监控都存在空洞，导致⽤⼾侧的业务故障问题 企业都没有及时发现，需要⽤⼾报障我们才后知后觉的排查问题。⿊匣⼦拨测监控系统项⽬的上线 就是解决了这⻓期以来的监控痛点。 ⿊盒监控 即以⽤⼾的⾝份测试服务的外部可⻅性，常⻅的 ⿊盒监控 包括 HTTP探针 、 TCP探针 等⽤于检测 站点或者服务的可访问性 ，以及 访问效率 等。⽽探针的设计需要⽀持对业务的交互 才能更有效的发现问题。所以在探针⼯具选型中选择了 Prometheus + blackbox_exporter 来实现需求。 拨测点需要在全国各地布点，在管理上难度较⼤，特别在兼顾拨测任务分发、拨测监控数据回收统 ⼀展⽰、告警聚合收敛的同时，还要考虑安全和应对审计等问题。架构的设计上需要严格控制 PULL和PUSH的数据流，还要和现有的采集监控系统独⽴出来。所以引⼊了Mosn做⽹格管理来降 低管理成本。 该系统的数据展⽰上默认只能⽤时序图和表格来展⽰现状，⼀个很直⽩的地域图更能说明问题。为 了做地域图的展⽰，还引进了 geohash + OpenStreetMap 来解决。 需求与功能 第一期的建设只是基本要求，但是需满足以下条件以达成业务基本需求：
⽀持对公司前端服务的证书链，DNS耗时，TLS耗时，⾸次建⽴建⽴耗时，加载完成耗时等监控 ⽀持ICMP拨测，可对⽣产业务系统的跨域内外⽹的⽹络质量监控，特别是跨域专线质量的监 控。 ⽀持DNS，TLS tcp，SMTP协议等交互监控。均⽀持在CDN服务场景，Proxy服务基础场景，邮 箱系统的使⽤场景。 同时，因为项目的0-1阶段基本都很难得到企业的深度投入，在第一期的建设也只能依赖开源项目搭建，后续逐步投入组件二开的研发资源以实现能力扩展。
架构简要 首先，定义每个拨测点为边缘孤岛，这里的边缘孤岛是因为它部署的地理位置远离企业系统的机房，分别在世界各地购买一些最便宜的虚拟机资源来部署服务， … ]]>监控系统企业架构演进史-跨地域混合云/posts/opentelemetry/prometheus-evolution-history-two/OpenTelemetryPrometheusPrometheusKubernetes监控架构<![CDATA[ 前情概述： 在《监控系统企业架构演进史-初入Prometheus》中，监控系统已经从单体架构升级到单IDC分布式架构了。 前一篇文章的内容是适用于虚拟机部署和容器部署的。Prometheus是云原生时代的产物，一般和Kubernetes配套使用，但是Prometheus本身也能在非Kubernetes取替传统监控如Zabbix使用的。 在该篇文章中，开始以Kubernetes的部署来升级整个监控系统架构，使之在跨地域混合云的业务场景中更具灵活性。
架构设计 跨地域的三层结构设计 设计三层区域结构，同时规范区域命名标签化来实现快速辨识服务的地域详细信息。 在第三层中的Cluster和VPC是同级，分别代表集群内或者某网段的隔离服务。
前端查询入口逻辑架构 用Thanos Query实现前期的层级架构 利用Thanos内的GRPC通讯协议和聚合查询能力来实现递级数据汇聚到最上层Thanos Query组件，再聚合计算时间线结果集前端展示。
引入Thanos Query Frontend完成统一前端查询入口 Thanos Query Frontend组件有以下配置能力优化查询，需根据实际情况调整：
时间线的纵向切割查询 比如查15天的数据，由于样本量的数据庞大，会在原始数据读取到内存时导致OOM问题。通过纵向切割比如把15天的聚合查询逻辑拆分成每6小时的聚合查询。 Thanos Query组件就会得到4 * 15个并发查询去完成样本查询并聚合成不同时间段的结果集再拼接展示，且每完成一个子查询聚合均及时释放内存高效优化了资源利用率。
查询结果集缓存 通过对查询语句和时间周期的HASH KEY缓存结果集到内存或者Redis以重复利用，减轻上游压力。
利用Kubernetes赋予更具弹性的冗余能力 自研架构组件 在基于原生开源项目的基础架构下，已基本实现对跨地域混合云的能力。但是要做到企业日常管理还远远不够，需要完善管理架构和前台能力才称得上企业服务。
基础设计逻辑 为了让整个架构具备灵活性和通用性，分别设计了几个组件：
Self-research service discovery 用于对接第三方系统，比如CMDB，CICD等收集业务系统和资产信息，并计算各个业务系统和基建关联关系，通过地域信息来调度资源信息同步给P-sidcar组件。 P-sidcar用于在边缘管理 … ]]>监控系统企业架构演进史-初入Prometheus/posts/opentelemetry/prometheus-evolution-history-one/OpenTelemetryPrometheusPrometheus监控架构<![CDATA[ Prometheus是一个开源的监控与时间序列数据库系统,在近年来得到了越来越广泛的应用。 官方的架构图如图所示： 本系列文章会以Prometheus的在一个企业里的部署架构演进过程中逐步理解和深入各种组件和概念。 先通过下图简单了解这个演进发展史 单节点架构 刚开始接触Prometheus监控体系，只需要在服务端部署Prometheus的二进制文件，用最基础的文件服务发现配置file_sd_config来实现对主机基础监控node_exporter进行拉取指标采集即可。 再通过Grafana的datasource配置Prometheus的url地址即可开始配置查看监控数据。
指标数据采集 Prometheus的数据模型主要由Metric、Label和 Sample组成。
Metric: 表示一个时序指标,对应于一个监控指标名称。如cpu_usage、free_memory等。 Metric仅包含时序数据名称,没有预定义的结构或类型。这使Prometheus具有很高的灵活性。 一个Prometheus实例可以包含任意数量的Metric。 Label: 用来描述和区分相同Metric的数据。类似于其他时序数据库的Tag。 Label通常表示数据的维度或属性,如instance、job、region等。 每个样本数据都必须包含相同的Label集。Label用于快速查询和聚合特定维度的数据。 Label的值可以是字符串、布尔值或整数。支持在Label上过滤和分组数据。 Sample: 表示一条时序数据,包含Timestamp、Value和Label集。 Timestamp表示时序数据的时间戳,精度为毫秒。它用于排序和查询给定时间范围的数据。 Value表示时序指标的值,可以是浮点数、整数或字符串。 Label集用于标识该Sample数据的属性与维度。相同Label的Sample表示同一指标的不同记录。 一个Prometheus Sample包含:
c 1 2 3 4 Metric - 时序指标名称 Timestamp - 时间戳,毫秒精度 Value - 指标数值 Label - 数据属性集 例如:
c 1 2 3 4 5 6 7 8 9 10 11 ################################################### Metric: … ]]>About me/about.html<![CDATA[ 个人简介 (Profile) I am a engineer with a rich work experience in IT field. I have extensive experience in operations, development and cloud native technologies. I have a passion for observable technologies and cloud native technologies. I have worked on shell scripts, VBA tools, Python, Lua, Golang, C and Rust. I also have experience in embedded development with Arduino and MicroPython.
我是一名经验丰富的IT技术工程师，拥有从运维到开发的丰富职业路径。我对可观测性技术充满热情，并对云原生技术有着深入的了解和实践经验。我的技术旅程始于Shell脚本，随后扩展到VBA工具开发，进而掌握了Python、Lua，并深入研究了Golang和Rust编程语言。此外，我还具备嵌入式开发的能力，包括Arduino和MicroPython等。
专业技能 (Skills) 编程语言 (Languages)： > I have extensive experience in shell scripts, VBA tools, Python, Lua, Golang, C and Rust. 精通 Shell、VBA、Python、Lua、Golang、C和Rust。
嵌入式开发 (Embedded Development)： > I have experience in embedded development with Arduino and MicroPython. 掌握简单的对`Esp32`、`STM32`和`RP2040`等`MCU`的`Arduino`和`MicroPython`开发，具备嵌入式系统的开发经验。 云原生技术 (Cloud Native Technologies)： > I have extensive experience in cloud native technologies such as Kubernetes and Docker. 具备国内外业务平台的运维和架构设计经验。
监控平台搭建 (Monitoring Platform)： > I have extensive experience in building monitoring platforms using Prometheus, Thanos and VictoriaMetrics. 利用Prometheus、Thanos、VictoriaMetrics以及自研架构组件，成功搭建了支持日千亿指标量的跨地域混合云监控平台，同时申请了四个专利。
项目经验 (Projects) Shell+Python： 我经常根据工作需要编写复杂的Shell和Python脚本。我的一个代表性项目是MLSBS，您可以通过MLSBS了解更多，或访问相关的GIT库。
Golang： 为Thanos社区和kube-state-metric项目贡献过代码。
eBPF/Rust： 在eBPF项目的代表之一DeepFlow社区的Agent项目中，我用Rust实现了MongoDB协议的解码逻辑，为项目做出了贡献。并受邀出席了现场分享。请点击链接
I am passionate about technology innovation and sharing my knowledge and experience. I hope to work with like-minded individuals to explore the future of technology together.
我致力于通过技术创新来解决复杂的技术挑战，并乐于分享我的知识和经验。期待与志同道合的伙伴们一起探索技术的未来。
]]>Linode的BBR简单测试/archives/linode-bbr-test/TcpTcp<![CDATA[ 概述: TCP BBR 解决两个问题：
在有一定丢包率的网络链路上充分利用带宽。适合高延迟、高带宽的网络链路。 降低网络链路上的 buffer 占用率，从而降低延迟。适合慢速接入网络的用户。 记得2017年BBR刚合入Linux 4.9内核时，Google提出的这个拥塞控制算法在技术圈特别火。当时我在Linode上做跨国文件传输，丢包几乎是家常便饭，就想亲自测试一下效果。
测试目的: 这次测试主要是针对丢包率。更有说服力的测试请参考Lawrence Brakmo的BBR Report。 BBR的另一面
测试准备： ADDR01：aaa.aaa.aaa.aaa shell 1 2 $ uname -r 4.8.6-x86_64-linode78 ADDR02：bbb.bbb.bbb.bbb shell 1 2 # uname -r 4.8.6-x86_64-linode78 这两台Linode机器分别在不同的数据中心，一台在美西，一台在欧洲，模拟的就是跨国网络环境。当时CentOS 7默认还是4.4内核，而BBR需要Linux 4.9+，所以必须先升级内核才能开启BBR。
测试方式： 模拟丢包1%-30%的场景，分别测试不同内核开启BBR先后的情况。 Linux的流量控制工具tc可以通过netem模拟各种网络状况，包括丢包、延迟、抖动等，这是做网络测试的标准工具。选rsync作为测试工具是因为平时真实使用场景就是跨服务器文件同步，最贴近实际。
用到的tc指令：
shell 1 2 3 4 5 6 7 8 # 清理tc规则： tc qdisc del root dev eth0 # 模拟1%丢包： tc qdisc add dev eth0 root netem loss 1% # 模拟10%丢包： tc qdisc add dev eth0 root netem loss 10% # 模拟30%丢包： tc qdisc add dev eth0 root netem loss 30% 测试从ADDR02传数据到ADDR01，ADDR01的内核不变，ADDR02在每次测试都会调整内核重启。 测试过程： 步骤略，test.gz约160MB，是平时用来备份代码的压缩包，过程大致如下： 没有启用BBR的情况，从ADDR02传数据到ADDR01：
shell 1 2 3 4 5 … ]]>树莓派 RaspberryPi docker集群/archives/rasp_pi_docker/DockerDockerArm<![CDATA[ 概述： 当时正在学习 Docker 集群管理，想找点低成本实验环境折腾，就想到用树莓派了。参考Hypriot的博客，我买了1块Rasp2代板和2块Rasp3代板。当初的考虑是2代便宜就做 master，3代性能好些做 node，组合起来刚好是个小集群。
其中2代默认安装了Hypriot的系统。3代板如果您有兴趣可以自己参考《Building a 64bit Docker OS for the Raspberry Pi 3》这篇文章编译一套64bit的系统。也可以直接下载作者的已编译好镜像地址中压缩包。
Hypriot 这系统当时还挺有意思，是专门为 ARM 设备定制的 Docker OS，内置了 docker-ce，省去了很多手动配置的麻烦。
网络的问题： 日常的升级或者包安装之类的情况，都会遇到墙的问题。避免经常为墙而烦恼的情况，有必要给控制网络出口的路由做些调整。参考《Shadowsocks + ChnRoute 实现 OpenWRT / LEDE 路由器自动翻墙》解决墙的烦恼，因为这个不是这篇文的重点，具体细节略。
当时在 ARM 板子上编译代理软件真的很痛苦，性能太差了。
给每个arm板子在路由上赋予一个静态IP地址。
系统： OS细节： 手动配3块板子真的很累，就找了个ansible-playbook来自动化部署。个人习惯调整一下环境，如zsh,vim等，可以考虑弄个ansible-playbook或者shell脚本来简化一下。
shell 1 2 3 4 5 6 7 # 调整默认文本工具为vim $ update-alternatives --config editor $ dpkg-reconfigure locales # 新建自己的账号并加入到docker组 $ usermod a -G docker xxx # 这步对集群很重要，修改设备的名字，否则后期加入集群会报错 $ sed -i "s/black-pearl/node01-pearl/" /boot/device-init.yaml /etc/hostname Hypriot 镜像是同一个，所以默认名字都叫 black-pearl，不改名字集群管理会很混乱。
Kubernetes(本来我想用这个来管理的，但是我的pi2的docker是最新ce版本，kubeadmin提示不支 … ]]>ARM的点点滴滴记录/archives/arm-board-note/ArmArmLinux<![CDATA[ Raspberry Pi 当初为了搭个docker集群环境折腾了树莓派，主要是看它价格便宜又省电。买了3个树莓派2代，大概花了600多块，当时ARM能跑Docker还是很新鲜的玩意。
我用树莓派搭建docker集群环境，参考Hypriot的博客
CubieBoard 在ARM上装Docker当时真是个大坑，官方支持很差，社区文档也少，全靠硬啃。
安装docker
选择Hypriot(截止到2017年3月版本是docker 1.11.1)，适合想要快速上手Docker ARM环境的用户，文档相对完整
shell 1 $ apt-get install -y apt-transport-https Add respository key shell 1 $ wget -q https://packagecloud.io/gpg.key -O - | sudo apt-key add - Add repository shell 1 2 $ echo 'deb https://packagecloud.io/Hypriot/Schatzkiste/debian/ jessie main' | sudo tee /etc/apt/sources.list.d/hypriot.list $ apt-get update Install Hypriot shell 1 2 $ apt-get install -y docker-hypriot $ systemctl enable docker 选择Dockerproject (随官方更新，截止2017年3月，版本17.03-ce)，适合需要最新Docker功能和长期维护的用户
shell 1 2 $ sudo apt-get update $ sudo apt-get install apt-transport-https ca-certificates Add repository shell 1 $ sudo apt-key adv --keyserver hkp://p80.pool.sks-keyservers.net:80 --recv-keys 58118E89F3A912897C070ADBF76221572C52609D 用下面的命令将 APT 源添加到 source.list（将其中的 替换为 … ]]>GitHub博客的搭建/archives/blog-mickeyzzc-github/GitHubGitHub<![CDATA[ 2023年的博客从hexo切换到hugo 主要是受够了hexo每次生成都要等半天，还有各种npm包的依赖管理问题，维护起来确实是个负担。而且hugo作为Go写的静态站点生成器，速度确实快多了。
工具选用了hugo 主题选择了Hugo.NexT CDN选择了CloudFlare 迁移过程中折腾了不少，主要是front matter格式要从YAML改成TOML，主题的各种配置差异也挺大的，不过最终还是折腾过来了。
迁移过程 搭建hugo新环境 shell 1 2 3 4 5 6 7 hugo new site mickeyzzcblog cd mickeyzzcblog git init git submodule add https://github.com/hugo-next/hugo-theme-next.git themes/hugo-theme-next cp themes/hugo-theme-next/exampleSite/config.yaml . vim config.yaml hugo server 这个CI workflow主要就是自动拉取代码、安装hugo、生成静态文件，然后自动推送到GitHub Pages上，算是彻底解放了手动部署的过程。
构建github ci的workflows mermaid flowchart LR A[push to main] --> B[Checkout + Submodules] B --> C[Setup Hugo] C --> D[hugo build] D --> E[Deploy to GitHub Pages] yaml 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 name: deploy on: push: workflow_dispatch: schedule: # Runs everyday at 8:00 AM - cron: "0 0 * * *" jobs: build: runs-on: ubuntu-latest steps: - name: Checkout uses: … ]]>监控采集点点记录/posts/opentelemetry/monitor-experience/MonitorMysqlTcpLinux<![CDATA[ MYSQL的监控 MySQL权限经验原则 权限控制主要是出于安全因素，因此需要遵循一下几个经验原则：
只授予能满足需要的最小权限，防止用户干坏事。比如用户只是需要查询，那就只给select权限就可以了，不要给用户赋予update、insert或者delete权限。 创建用户的时候限制用户的登录主机，一般是限制成指定IP或者内网IP段。 初始化数据库的时候删除没有密码的用户。安装完数据库的时候会自动创建一些用户，这些用户默认没有密码。 为每个用户设置满足密码复杂度的密码。 定期清理不需要的用户。回收权限或者删除用户。 eg:
针对MYSQL的监控需要开监控账号，针对本地监控和远程监控的分别授权；
sql 1 2 GRANT USAGE,PROCESS,REPLICATION CLIENT,REPLICATION SLAVE ON *.* TO 'monitor'@'10.12.%' IDENTIFIED BY 'xxx'; GRANT USAGE,SUPER,PROCESS,REPLICATION CLIENT,REPLICATION SLAVE ON *.* TO 'monitor'@'localhost' IDENTIFIED BY 'xxx'; 监控手段 show global status; 查看全局状态
show global variables; 查看全局变量设置
mysqladmin MySQL管理工具
show master status; 查看Master状态
show slave status; 查看Slave状态
show binary logs; 查看二进制日志文件
show engine innodb status\G 查看InnoDB存储引擎状态
show engine myisam status\G 查看MyISAM存储引擎状态
还有通过查看information_schema 这个数据库获取InnoDB存储引擎相关信息
权限表 权限 权限级别 权限说明 CREATE 数据库、表或索引 创建数据库、表或索引权限 DROP 数据库或表 删除数据库或表权限 GRANT OPTION 数据库、表或保存的程序 赋予权限选项 REFERENCES 数据库或表 ALTER 表 更改表，比如添加字段、索引等 DELETE 表 删除数据权限 INDEX 表 索引权限 INSERT 表 插入权限 SELECT 表 查询权限 UPDATE 表 更新权限 CREATE VIEW 视图 创建视图权限 SHOW VIEW 视图 查看视图权限 ALTER ROUTINE 存储过程 更改存储过程权限 CREATE ROUTINE 存储过程 创建存储过程权限 EXECUTE 存储过程 执行存储过程权限 FILE 服务器主机上的文件访问 文件访问权限 CREATE TEMPORARY TABLES 服务器管理 创建临时表权限 LOCK TABLES 服务器管理 锁表权限 CREATE USER 服务器管理 创建用户权限 PROCESS 服务器管理 查看进程权限 RELOAD 服务器管理 执行flush-hosts, flush-logs, flush-privileges, flush-status, flush-tables, flush-threads, refresh, reload等命令的权限 REPLICATION CLIENT 服务器管理 复制权限 REPLICATION SLAVE 服务器管理 复制权限 SHOW DATABASES 服务器管理 查看数据库权限 SHUTDOWN 服务器管理 关闭数据库权限 SUPER 服务器管理 执行kill线程权限 TCP 图：
该图详细介绍了 TCP/IP 协议族中的各个协议在 OSI 模型中的分布
]]>跨城区局域网的搭建（基于Docker）/archives/mi-docker-net/DockerDockerVPN<![CDATA[ 概述： 当时家里和公司都有服务器，想统一管理，但两边的内网是隔离的。传统的端口映射太麻烦，而且有些服务不想暴露在公网。试过一些方案，最后觉得用 Docker OpenVPN 最省事。
选择 Docker OpenVPN 而不是传统 VPN，主要是因为容器化部署特别方便，证书管理也简单得多。最后的效果很好，通过域名就能访问远程内网的各种服务，省去了很多配置麻烦。
网络拓扑： mermaid graph TD classDef gateway fill:#e67e22,stroke:#d35400,color:#fff,stroke-width:2px classDef lb fill:#2980b9,stroke:#2471a3,color:#fff,stroke-width:2px classDef proxy fill:#5dade2,stroke:#2e86c1,color:#fff classDef vpn fill:#5dade2,stroke:#2e86c1,color:#fff classDef arm fill:#85c1e9,stroke:#2e86c1,color:#333 classDef isp fill:#76d7c4,stroke:#1abc9c,color:#333 classDef user fill:#bdc3c7,stroke:#7f8c8d,color:#333 subgraph overseas["海外服务区域"] UserOut["外网用户"]:::user OS["海外服务"] CDN["CDN"] SS1["SS Server 1"]:::proxy SS2["SS Server 2"]:::proxy UserOut -->|用户访问| OS OS -->|用户访问| CDN CDN -->|用户访问| SS2 OS -->|Shadowsocks| SS1 OS -->|Shadowsocks| SS2 end GFW["GFW 防火墙"]:::gateway LB["负载均衡"]:::lb subgraph internal["内网核心区域"] … ]]>Tmux + Git + OhMyZsh + VIM/archives/zsh-tmux-vim-git/LinuxLinuxTmuxZshVIMGit<![CDATA[ 这是我的 Linux 开发环境配置记录，主要聚焦在四个基础工具的配置：tmux 终端复用、zsh 增强终端、vim 编辑器和 git 版本控制。这四个工具构成了 Linux 开发的基础配置，每个都有其明确的定位和协同配合。
Ubuntu下的环境： 要求： tmux >= 2.1 vim >= 7.3 zsh (oh-my-zsh) git 部署环境： TMUX(使用gpakosz的配置)： 我选择 gpakosz 的配置，因为它是开箱即用的，社区非常活跃，配置也相当完善。部署方式：
shell 1 2 3 4 5 $ cd ~ $ git clone https://github.com/gpakosz/.tmux.git $ ln -s -f .tmux/.tmux.conf $ cp .tmux/.tmux.conf.local . $ sudo apt-get install xclip ## Ubuntu下安装xclip来支持跨文件复制粘贴 我修改了 “.tmux.conf” 让 y 键可以直接复制到系统剪贴板：
shell 1 bind -t vi-copy y copy-selection 改为
shell 1 bind -t vi-copy y copy-pipe "xclip -sel clip -i" 这样在 tmux 的 copy 模式下，y 键可以直接复制到系统剪贴板，和其他终端保持一致。xclip 的作用就是让 tmux 原本不支持的应用间复制粘贴功能正常工作。
如果 tmux <1.8 请修改如下：
shell 1 2 3 # copy & paste between tmux and x clipboard bind C-p run-shell "tmux set-buffer \"$(xclip -o)\"; tmux paste-buffer" bind C-y run-shell "tmux show-buffer | xclip -sel clip -i" 修改 “.tmux.conf.local"把以下地方注释掉：
shell 1 2 # set -g status-keys vi # set -g mode-keys vi GIT： 日常工作中经常需要管理多个相关的 git 仓库，有同事的项目也有自己的项目。利用 git 子模块可以很好地实现统一管理，避免重复克隆和更新的麻烦。
shell 1 2 3 4 5 6 7 $ mkdir xxxx $ git init $ git remote add origin ssh://git@git.xxx.net/mickey/xxxx.git $ git submodule add ssh://git@git.xxx.net/mickey/tttt.git xxxx $ git add -A $ git commit -m "add submodule tttt" $ git push --set-upstream origin master 当需要批量更新所有子模块时：
shell 1 $ git submodule foreach git pull 这个命令很实用，特别是在需要同时更新多个依赖仓库的场景。
初始化新环境的流程：
shell 1 2 3 4 5 6 ➜ ~ git clone ssh://git@git.xxx.net/mickey/xxxx.git ➜ ~ cd xxxx ➜ xxxx git:(master) git submodule init ➜ xxxx git:(master) git submodule sync ➜ xxxx git:(master) git submodule update ➜ xxxx git:(master) git submodule foreach git pull origin master 这组命令是新环境首次克隆时的标准流程，确保所有子模块都能正确初始化和更新。
这四个工具配合起来使用非常高效：tmux 管理多个终端窗口和会话，zsh 提供强大的命令行功能和自动补全，vim 提供高效的文本编辑体验，git 管理版本控制和代码历史。它们共同构成了一个完整且高效的 Linux 开发环境。
]]>