Batch ingest: Multi-Agent Team / DevOps Maturity / 一语点醒梦中人 / NodeWarden
Sources: - Agent-usecases-multi-Agent-Team.md - DevOps-Maturity-Model-From-Traditional-IT-to-Advanced-DevOps.md - AI-一语点醒梦中人.md - Home-Office-NodeWarden-把-Bitwarden-搬上-Cloudflare-Workers彻底告别服务器.md Entities: Trebuh, Cloudflare Concepts: DevOps成熟度模型, 共享内存模式, 空性智慧, 绝处逢生
This commit is contained in:
61
wiki/sources/AI-一语点醒梦中人.md
Normal file
61
wiki/sources/AI-一语点醒梦中人.md
Normal file
@@ -0,0 +1,61 @@
|
||||
---
|
||||
title: "一语点醒梦中人——东方人生智慧"
|
||||
type: source
|
||||
tags: [chinese-wisdom, daoism, confucianism, buddhism, life-philosophy]
|
||||
date: 2026-04-15
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/AI/一语点醒梦中人.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：中国古典哲学与人生修养箴言，涵盖道家/儒家/佛教/禅宗智慧
|
||||
- 问题域：现代人在困境、焦虑、执着中寻找内心平静与处事之道
|
||||
- 方法/机制：以经典引述+释义+背景延伸的结构，解析名言背后的哲学思想
|
||||
- 结论/价值：东方智慧提供"绝处逢生"、"放下执着"、"守拙内敛"的实践路径
|
||||
|
||||
## Key Claims
|
||||
- 王维"行到水穷处，坐看云起时"：人生困境（"水穷处"）与超然觉醒（"云起时"）的辩证关系，仕途挫折促使其转向佛学形成空寂淡泊心境
|
||||
- 曾国藩"唯忘机可以消众机，唯懵懂可以祓不吉祥"：以无争、大智若愚姿态化解官场算计与人生风险
|
||||
- "知其不可奈何而安之若命"（庄子）：区分"可奈何"与"不可奈何"，对无法改变之事安然接受，而非继续内耗
|
||||
- "一切有为法，如梦幻泡影，如露亦如电，应作如是观"（金刚经）：世间一切因缘和合之物皆虚幻短暂，以"空性"智慧观照而不执着
|
||||
- "执一守中，有劳而作，言行意合，自然而行"：融合儒家"执两用中"与道家"守中"，在劳作中体悟，在言行中修心
|
||||
|
||||
## Key Quotes
|
||||
> "知其不可奈何而安之若命，德之至也" — 庄子·内篇·人间世
|
||||
> "大智若愚，大巧若拙" — 老子·第四十五章
|
||||
> "和其光，同其尘" — 老子·第五十六章
|
||||
> "一切有为法，如梦幻泡影，如露亦如电，应作如是观" — 金刚经
|
||||
|
||||
## Key Concepts
|
||||
- [[空性智慧]]：一切因缘和合之物皆无独立不变的自性，不执着于幻象
|
||||
- [[中道智慧]]：避免极端，在动态平衡中守持正道（"执两用中"）
|
||||
- [[绝处逢生]]："水穷处"象征困境，"云起时"象征在放下执着后获得新的可能
|
||||
- [[知其不可奈何而安之若命]]：分辨可控与不可控，对不可控之事保持内心平静
|
||||
- [[忘机]]：忘却世俗机巧，以淳朴自然的心态化解纷扰
|
||||
- [[慎独]]：独处时仍保持行为谨慎不苟（《礼记·中庸》）
|
||||
|
||||
## Key Entities
|
||||
- [[王维]]（诗佛）：唐代诗人，"行到水穷处，坐看云起时"作者，仕途多舛后转向佛学
|
||||
- [[曾国藩]]：清代重臣，"唯忘机可以消众机"出处，结合道家无为与儒家诚心
|
||||
- [[老子]]：道家创始人，"大智若拙"/"和光同尘"/"守中"等思想源头
|
||||
- [[庄子]]：道家代表，"知其不可奈何而安之若命"出处
|
||||
- [[佛陀]]：金刚经偈颂来源，阐述"有为法"之虚妄
|
||||
|
||||
## Connections
|
||||
- [[Laozi, Confucius, Buddha Wisdom]] ← 上位概念 ← [[空性智慧]]
|
||||
- [[Diamond Sutra]] ← 同一经典 ← [[一切有为法，如梦幻泡影]]
|
||||
- [[Su Dongpo Perspective]] ← 同类实践 ← [[绝处逢生]]
|
||||
|
||||
## Contradictions
|
||||
- 与现代"积极进取"文化的张力：
|
||||
- 冲突点：东方智慧强调"放下"、"接受"，与现代社会"主动改变"、"征服自然"的叙事存在张力
|
||||
- 当前观点："安之若命"非消极躺平，而是"尽人事后听天命"的智慧
|
||||
- 对方观点：在快速变化的现代职场，过度强调接受可能导致错失主动改善的机会
|
||||
|
||||
## Related Links
|
||||
- 《金刚经》
|
||||
- 《庄子·内篇·人间世》
|
||||
- 《老子》
|
||||
- 《礼记·中庸》
|
||||
- 曾国藩《治心经·诚心篇》
|
||||
54
wiki/sources/Agent-usecases-multi-Agent-Team.md
Normal file
54
wiki/sources/Agent-usecases-multi-Agent-Team.md
Normal file
@@ -0,0 +1,54 @@
|
||||
---
|
||||
title: "Multi-Agent Specialized Team (Solo Founder Setup)"
|
||||
type: source
|
||||
tags: [multi-agent, openclaw, solo-founder, telegram]
|
||||
date: 2026-04-15
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Agent/usecases/multi-agent-team.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：一人公司通过多个专业化 AI Agent 组建虚拟团队，实现 24/7 自动运转
|
||||
- 问题域：创始人身兼数职导致上下文切换成本高、精力耗散、无法深度工作
|
||||
- 方法/机制：多 Agent 分工 + 共享内存 + Telegram 统一入口 + 定时主动汇报
|
||||
- 结论/价值：Agent 团队比单一 Agent 更高效，分工专业化是关键
|
||||
|
||||
## Key Claims
|
||||
- 单一 Agent 无法同时处理战略、代码、营销等多领域任务而不快速填满上下文窗口
|
||||
- 共享记忆（GOALS.md/DECISIONS.md）+ 私有上下文组合是多 Agent 协作的核心机制
|
||||
- 定时主动任务（scheduled daily tasks）是 Agent 团队产生真实价值的飞轮
|
||||
- 从 2 个 Agent 开始（lead + specialist），再按瓶颈扩展至 4 个
|
||||
|
||||
## Key Quotes
|
||||
> "Personality matters more than you'd think: Giving agents distinct names and communication styles makes it natural to 'talk to your team' rather than wrestle with a generic AI" — Trebuh on X
|
||||
> "Start with 2, not 4: Begin with a lead + one specialist, then add agents as you identify bottlenecks"
|
||||
|
||||
## Key Concepts
|
||||
- [[Multi-Agent Hierarchy]]：Supervisor（战略 Lead）+ Worker（领域专家）+ Validator 的层级分工
|
||||
- [[共享内存模式]]：共享 GOALS.md/DECISIONS.md + 私有 notes，实现共同上下文与专业积累
|
||||
- [[Telegram 路由]]：单一 Telegram 群聊，通过 @mention 分发到不同 Agent
|
||||
- [[定时主动任务]]：Agent 不等待指令，而是按日程主动 surface insights
|
||||
|
||||
## Key Entities
|
||||
- [[Trebuh]]：Solo founder，4 Agent 团队（ Milo/Josh/Marketing/Dev）实践者，OpenClaw Showcase 案例
|
||||
- [[OpenClaw]]：多 Agent 控制平面，支持 sessions_spawn/sessions_send 通过 Telegram 协调
|
||||
- [[Claude Opus]]：Milo（Strategy Lead）使用，擅长战略规划和综合协调
|
||||
- [[Claude Sonnet]]：Josh（Business）使用，快速分析能力匹配数字驱动任务
|
||||
- [[Gemini]]：Marketing Agent 使用，强于网页研究和长上下文分析
|
||||
|
||||
## Connections
|
||||
- [[Multi-Agent System Reliability]] ← 扩展 ← [[Multi-Agent Hierarchy]]
|
||||
- [[OpenClaw]] ← 支撑 ← [[Multi-Agent Hierarchy]] 的执行层
|
||||
- [[Agentic AI]] ← 上位概念 ← [[Multi-Agent Hierarchy]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Multi-Agent System Reliability]] 冲突：
|
||||
- 冲突点：Multi-Agent System Reliability 强调可靠性（多数投票/对抗辩论/淘汰制），Solo Founder Setup 强调快速交付和主动性
|
||||
- 当前观点：专业化分工 + 主动汇报优先于冗余可靠性机制
|
||||
- 对方观点：高风险任务需要 Validator/Hierarchy 等可靠性保障机制
|
||||
|
||||
## Related Links
|
||||
- [Trebuh on X](https://x.com/iamtrebuh/status/2011260468975771862)
|
||||
- [OpenClaw Showcase](https://openclaw.ai/showcase)
|
||||
- [Anthropic: Building Effective Agents](https://www.anthropic.com/research/building-effective-agents)
|
||||
@@ -1,54 +0,0 @@
|
||||
---
|
||||
title: "3.2万人收藏的Claude Skills，才是AI这条路最值得研究的一套范式"
|
||||
type: source
|
||||
tags: [AI, Claude-Skills, Vibe-Coding]
|
||||
date: 2026-01-05
|
||||
---
|
||||
|
||||
## Source File
|
||||
- raw/AI/3.2 万人收藏的 Claude Skills，才是 AI 这条路上最值得研究的一套范式！.md
|
||||
- raw/AI/3.2 万人收藏的 Claude Skills，才是 AI 这条路上最值得研究的一套范式！ 1.md
|
||||
|
||||
## Summary
|
||||
- 核心主题：Claude Skills 作为 AI 应用开发的新范式，标志从"提示词工程"迈向"流程工程"
|
||||
- 问题域：如何将 AI 能力真正落地为可复用、可自动执行的生产级工作流
|
||||
- 方法/机制：Skills = 说明书 + SOP，将固定流程任务拆解为 AI 可理解的结构化流程
|
||||
- 结论/价值：真正有价值的不是 Prompt 写得多花哨，而是谁最懂业务流程、能把经验沉淀成 SOP、能把 SOP 交给 AI 稳定执行
|
||||
|
||||
## Key Claims
|
||||
- Claude Skills 是 Anthropic 官方发布的开源项目，本质是官方在教"怎么像我们一样开发 AI 应用"
|
||||
- Skills 即将知识经验封装为可复用工作流，Vibe Coding 的尽头也是 Skills
|
||||
- Anthropic 官方 Skills 仓库（github.com/anthropics/skills）包含生产级技能：办公自动化（Word/PDF/PPT/Excel）、开发者工具箱（MCP Server、Web 测试、Artifacts 构建）、创意类 Skill
|
||||
- 三大 Awesome-Claude-Skills 社区仓库（ComposioHQ/VoltAgent/BehiSecc）系统性整理了各类 LLM Skills 工作流
|
||||
- Skills 聚合站（skillsmp.com、aitmpl.com/skills、claudemarketplaces.com）提供一站式 Skills 选型与二次改造
|
||||
|
||||
## Key Quotes
|
||||
> "Skills 就是一套你写给 Claude 的'说明书'和'SOP（标准作业程序）'" — 核心定义
|
||||
> "这个库本质上是官方在教你，'怎么像我们一样开发 AI 应用'" — 价值定位
|
||||
> "未来真正有价值的，不是谁的 Prompt 写得最花，而是谁最懂业务流程、谁能把经验沉淀成 SOP、谁能把 SOP 交给 AI 稳定执行" — 趋势判断
|
||||
|
||||
## Key Concepts
|
||||
- [[AI技能封装]]：将反复执行、有固定流程的任务，拆解为 AI 能理解、能稳定复用、能自动执行的结构化流程
|
||||
- [[流程工程]]：从提示词工程（Prompt Engineering）进化而来，强调将经验沉淀为 SOP 再交给 AI 执行的新范式
|
||||
- [[AI编程]]：Claude Skills 的核心技术场景之一，使 AI 真正参与工程流程而非仅展示写代码能力
|
||||
|
||||
## Key Entities
|
||||
- [[Anthropic]]：Claude Skills 官方来源，发布 github.com/anthropics/skills 仓库，包含 3.2 万收藏
|
||||
- [[ComposioHQ]]：维护 awesome-claude-skills 仓库，系统性整理 LLM Skills 工作流
|
||||
- [[VoltAgent]]：维护 awesome-claude-skills 仓库
|
||||
- [[BehiSecc]]：维护 awesome-claude-skills 仓库
|
||||
- [[skillsmp.com]]：Skills 聚合站，提供拿来即用的 Skills 集合
|
||||
- [[aitmpl.com]]：Skills 聚合站，支持分类与搜索
|
||||
- [[claudemarketplaces.com]]：Skills 聚合站
|
||||
|
||||
## Connections
|
||||
- [[Anthropic]] ← 发布 ← [[Claude-Skills-研究范式]]
|
||||
- [[Vibe-Kanban]] ← 终点也是 ← [[AI技能封装]]
|
||||
- [[Claude-Skills-研究范式]] ← 收录于 ← [[AI编程]]
|
||||
- [[AI技能封装]] ← 核心机制 ← [[流程工程]]
|
||||
|
||||
## Contradictions
|
||||
- 无明显冲突
|
||||
|
||||
## Related Sources
|
||||
- [[Claude Code 调用方法]]：Claude Code 是 Skills 调用的核心工具链
|
||||
52
wiki/sources/Cloud-DevOp-Maturity-Guideline.md
Normal file
52
wiki/sources/Cloud-DevOp-Maturity-Guideline.md
Normal file
@@ -0,0 +1,52 @@
|
||||
---
|
||||
title: "Cloud DevOp Maturity - Guideline"
|
||||
type: source
|
||||
tags: [DevOps, Cloud, 运维, 成熟度]
|
||||
date: 2026-04-15
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Cloud DevOp Maturity - Guideline.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：企业级 SaaS 公司云 DevOps 成熟度评估框架
|
||||
- 问题域：DevOps 成熟度模型、DORA 指标、CMMI、治理与实践
|
||||
- 方法/机制：四支柱模型（自动化、协作与文化、监控与可观测性、安全集成）
|
||||
- 结论/价值：提供从初始阶段到高度优化的渐进式转型路径
|
||||
|
||||
## Key Claims
|
||||
- DevOps 成熟度评估可降低 time-to-market、提升运营效率、增强产品可靠性
|
||||
- DORA 四指标（部署频率、变更前置时间、变更失败率、平均恢复时间）是核心评估框架
|
||||
- 自动化、协作、文化、监控与可观测性是 DevOps 成熟度四大支柱
|
||||
- DevSecOps 将安全集成到 CI/CD 生命周期实现主动式漏洞管理
|
||||
|
||||
## Key Quotes
|
||||
> "DevOps isn't just about tools or automation; it's a mindset shift that prioritizes collaboration, continuous learning, and customer-centricity."
|
||||
|
||||
## Key Concepts
|
||||
- [[DORA指标]]：部署频率、变更前置时间、变更失败率、平均恢复时间
|
||||
- [[CMMI]]：能力成熟度模型集成
|
||||
- [[CI/CD Pipelines]]：自动化构建、测试、部署流水线
|
||||
- [[Infrastructure as Code]]：以代码管理基础设施
|
||||
- [[DevSecOps]]：安全集成的 DevOps
|
||||
- [[Kaizen]]：持续改进
|
||||
- [[Chaos Engineering]]：主动测试系统韧性
|
||||
|
||||
## Key Entities
|
||||
- [[Jenkins]]：CI/CD 工具
|
||||
- [[GitLab]]：CI/CD 工具
|
||||
- [[GitHub Actions]]：CI/CD 工具
|
||||
- [[Terraform]]：IaC 工具
|
||||
- [[AWS CloudFormation]]：IaC 工具
|
||||
- [[Prometheus]]：监控与可观测性
|
||||
- [[Grafana]]：监控与可观测性
|
||||
- [[Datadog]]：监控与可观测性
|
||||
|
||||
## Connections
|
||||
- [[DevOps Culture and Transformation]] ← relates_to ← [[Cloud-DevOp-Maturity-Guideline]]
|
||||
- [[How Agentic AI for Cloud DevOps]] ← extends ← [[Cloud-DevOp-Maturity-Guideline]]
|
||||
- [[CI/CD Pipelines]] ← depends_on ← [[Infrastructure as Code]]
|
||||
- [[DevSecOps]] ← extends ← [[DevOps Culture and Transformation]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[DevOps Culture and Transformation]] 无冲突，两者互补
|
||||
51
wiki/sources/Cloud-Maturity-Model.md
Normal file
51
wiki/sources/Cloud-Maturity-Model.md
Normal file
@@ -0,0 +1,51 @@
|
||||
---
|
||||
title: "Cloud Maturity Model - 企业云成熟度5级评估框架"
|
||||
type: source
|
||||
tags: [Cloud, Maturity, 云迁移, 评估框架]
|
||||
date: 2026-04-15
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/Cloud Maturity Model A Detailed Guide For Cloud Adoption.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：企业云成熟度模型（CMM）的5级评估框架与最佳实践
|
||||
- 问题域：云采用成熟度评估、云迁移战略、云治理
|
||||
- 方法/机制：5级成熟度模型（0-4：Legacy→Initial→Repeatable→Systematic→Measured→Optimized）
|
||||
- 结论/价值：Forrester 预测2025年全球云成熟度模型市场达15亿美元，60%+组织已实施
|
||||
|
||||
## Key Claims
|
||||
- 云成熟度模型帮助组织从业务和技术两个维度评估云采用准备度
|
||||
- 5级成熟度路径：Legacy（无云准备）→ Initial（初始准备）→ Repeatable（可重复）→ Systematic（系统化文档化）→ Measured（可测量）→ Optimized（优化）
|
||||
- 云成熟度三要素：People（技能与工作方式）、Processes（工作流优化）、Technology（基础设施适配）
|
||||
- 云成熟度最佳实践：设定目标→识别当前级别→选择模型→遵循治理合规→安全管理风险
|
||||
|
||||
## Key Quotes
|
||||
> "The cloud maturity model helps businesses make the most of their cloud journey by guiding them through the different stages of cloud adoption."
|
||||
|
||||
## Key Concepts
|
||||
- [[云成熟度模型]]：评估组织云采用准备度的框架
|
||||
- [[云迁移]]：从本地向云端迁移的过程
|
||||
- [[云治理]]：定义角色、职责、决策流程的框架
|
||||
- [[Cloud Native]]：云原生架构
|
||||
- [[Multi-Cloud]]：多云策略
|
||||
- [[Hybrid Cloud]]：混合云策略
|
||||
- [[CAPEX]]：资本支出
|
||||
- [[OPEX]]：运营支出
|
||||
- [[TCO]]：总拥有成本
|
||||
|
||||
## Key Entities
|
||||
- [[Forrester]]：市场研究机构
|
||||
- [[Gartner]]：市场研究机构
|
||||
- [[AWS]]：云服务提供商
|
||||
- [[Azure]]：云服务提供商
|
||||
- [[Google Cloud]]：云服务提供商
|
||||
- [[Open Alliance for Cloud Adoption]]：云采用联盟
|
||||
|
||||
## Connections
|
||||
- [[Cloud-DevOp-Maturity-Guideline]] ← relates_to ← [[Cloud-Maturity-Model]]
|
||||
- [[DevOps Culture and Transformation]] ← extends ← [[Cloud-Maturity-Model]]
|
||||
- [[How Agentic AI for Cloud DevOps]] ← extends ← [[Cloud-Maturity-Model]]
|
||||
|
||||
## Contradictions
|
||||
- 与 [[DevOps Culture and Transformation]] 无冲突，两者互补（DevOps成熟度 vs 云成熟度）
|
||||
@@ -6,7 +6,7 @@ date: 2025-03-02
|
||||
---
|
||||
|
||||
## Source File
|
||||
- raw/AI/Designing for Agentic AI.md
|
||||
- raw/AI/Designing for Agentic-AI.md
|
||||
|
||||
## Summary
|
||||
- 核心主题：Agentic AI（智能体AI）与 GenAI 的区别，以及为 Agentic AI 设计用户体验的最佳实践
|
||||
|
||||
@@ -0,0 +1,54 @@
|
||||
---
|
||||
title: "DevOps Maturity Model: From Traditional IT to Advanced DevOps"
|
||||
type: source
|
||||
tags: [devops, maturity-model, dora, cloud, transformation]
|
||||
date: 2026-04-15
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Cloud & DevOps/DevOps Maturity Model From Traditional IT to Advanced DevOps.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：DevOps 成熟度 5 阶段评估框架，从传统 IT 到完全成熟 DevOps 的演进路径
|
||||
- 问题域：组织评估当前 DevOps 能力、识别改进方向、制定进阶路线图
|
||||
- 方法/机制：4 大焦点领域（文化/自动化/结构流程/协作）+ 5 阶段成熟度评估
|
||||
- 结论/价值：成熟度模型提供结构化自评工具，帮助组织量化 DevOps 转型进展
|
||||
|
||||
## Key Claims
|
||||
- DevOps 成熟度评估 4 大焦点：Culture & Strategy（文化战略）/ Automation（自动化）/ Structure & Process（结构流程）/ Collaboration（协作）
|
||||
- Phase 1（Ad-Hoc）：团队孤立、瀑布式交付、手动基础设施管理、安全仅在发布前介入
|
||||
- Phase 2（Pockets）：小规模试点、引入 Agile 版本控制、自动化降低发布风险
|
||||
- Phase 3（Defined）：标准化流程、大部分基础设施自动化、安全融入设计阶段
|
||||
- Phase 4（Optimized）：不可变基础设施、CI/CD 流水线成熟、技术债务管理、性能负载测试
|
||||
- Phase 5（Mature）：每天多次部署、零人工干预、安全内嵌、实时数据驱动决策
|
||||
|
||||
## Key Quotes
|
||||
> "The core of DevOps security is merging development, operations, and security into a unified process" — Bacancy Technology
|
||||
> "Companies with advanced DevOps practices can seize new opportunities more effectively. Their capability to rapidly deploy updates and services enables them to introduce innovative products and enter new markets ahead of their competitors"
|
||||
|
||||
## Key Concepts
|
||||
- [[DevOps]]：开发与运维一体化，强调协作、自动化、持续改进
|
||||
- [[DevOps成熟度模型]]：5 阶段评估框架（Ad-Hoc → Pockets → Defined → Optimized → Mature）
|
||||
- [[DORA指标]]：部署频率/变更前置时间/变更失败率/MTTR，Google 提出的 DevOps 效能四指标
|
||||
- [[DevSecOps]]：安全融入 DevOps 全流程，而非单独阶段介入
|
||||
- [[Kaizen]]：持续改进，DevOps 文化的核心原则
|
||||
- [[不可变基础设施]]：不更新旧服务器，而是替换为新服务器，减少配置漂移
|
||||
|
||||
## Key Entities
|
||||
- [[DORA]]（DevOps Research and Assessment）：Google 团队，提出四指标效能评估框架
|
||||
- [[Bacancy Technology]]：内容发布方，提供 DevOps 成熟度模型详细解读
|
||||
|
||||
## Connections
|
||||
- [[DevOps Culture and Transformation]] ← 理论补充 ← [[DevOps成熟度模型]]
|
||||
- [[Cloud DevOp Maturity - Guideline]] ← 同一领域 ← [[DevOps成熟度模型]]
|
||||
- [[Cloud Maturity Model]] ← 关联评估 ← [[DevOps成熟度模型]]
|
||||
- [[CI/CD Pipelines]] ← 核心实践 ← Phase 3-5 的关键使能技术
|
||||
|
||||
## Contradictions
|
||||
- 与 [[Cloud DevOp Maturity - Guideline]] 部分重叠：
|
||||
- 冲突点：该文 5 阶段模型与 Cloud DevOp Maturity Guideline 的 DORA 评估体系表述方式不同
|
||||
- 当前观点：5 阶段成熟度模型更侧重组织文化与流程演进
|
||||
- 对方观点：DORA 四指标更量化、更聚焦交付效能
|
||||
|
||||
## Related Links
|
||||
- [DevOps Maturity Model 原文](https://www.bacancytechnology.com/blog/devops-maturity-model)
|
||||
@@ -0,0 +1,46 @@
|
||||
---
|
||||
title: "NodeWarden - 把 Bitwarden 搬上 Cloudflare Workers，彻底告别服务器"
|
||||
type: source
|
||||
tags: [bitwarden, cloudflare-workers, password-manager, self-hosted, serverless]
|
||||
date: 2026-04-15
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Home Office/NodeWarden - 把 Bitwarden 搬上 Cloudflare Workers，彻底告别服务器.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：NodeWarden 将 Bitwarden 服务器端部署到 Cloudflare Workers，实现零 VPS 的自托管密码管理
|
||||
- 问题域：Bitwarden 官方自托管需要服务器，而许多人希望完全无服务器方案
|
||||
- 方法/机制：Cloudflare Workers（DDoS 防护/全球 CDN/免费额度）+ D1（SQLite 分布式数据库）+ R2（对象存储附件）
|
||||
- 结论/价值：在不付费服务器的情况下，获得支持 TOTP/自动填充/完整同步的开源密码管理方案
|
||||
|
||||
## Key Claims
|
||||
- NodeWarden 在 Cloudflare Workers 上运行，完全零服务器费用（Free Tier 足够个人使用）
|
||||
- 支持单用户保管库完整功能：登录/笔记/卡片/身份/文件夹/附件/R2 存储/网站图标代理
|
||||
- 支持 passkey 和 TOTP（官方需要会员，NodeWarden 免费）
|
||||
- 不支持多用户、组织/集合/成员权限、SSO/SCIM/Send/紧急访问（单用户定位，无需这些功能）
|
||||
|
||||
## Key Quotes
|
||||
> "部署 NodeWarden 之后的效果，就是在无服务器的情况下，也能在手机、电脑上使用 Bitwarden 客户端来保存密码了，支持自动登陆、二次验证之类的功能" — AppInn
|
||||
|
||||
## Key Concepts
|
||||
- [[Cloudflare Workers]]：无服务器边缘计算平台，支持在 200+ 地区运行 JavaScript/TypeScript 代码
|
||||
- [[Cloudflare D1]]：基于 SQLite 的全球分布式数据库，Workers 原生集成
|
||||
- [[Cloudflare R2]]：S3 兼容的对象存储，用于存储密码库附件
|
||||
- [[自托管密码管理]]：自己控制数据，不依赖第三方云服务的密码管理方式
|
||||
- [[无服务器密码学]]：TOTP（Time-based One-Time Password）算法实现二次验证
|
||||
|
||||
## Key Entities
|
||||
- [[Bitwarden]]：开源密码管理系统，客户端和服务器端均开源，支持完整自托管
|
||||
- [[Cloudflare]]：全球网络服务商，提供 Workers/D1/R2 等开发者工具
|
||||
- [[NodeWarden]]：将 Bitwarden 服务器端运行在 Cloudflare Workers 的开源项目（shuaiplus/GitHub）
|
||||
- [[AppInn]]：中文科技博客，内容翻译和本地化介绍
|
||||
|
||||
## Connections
|
||||
- [[Bitwarden]] ← 基础服务 ← [[Cloudflare Workers]] ← 承载层 ← [[NodeWarden]]
|
||||
- [[密码管理器]] ← 上位概念 ← [[自托管密码管理]]
|
||||
|
||||
## Related Links
|
||||
- [NodeWarden GitHub](https://github.com/shuaiplus/NodeWarden)
|
||||
- [AppInn 原文](https://www.appinn.com/nodewarden/)
|
||||
- NodeWarden 实例：https://nodewarden.ishenwei.online/
|
||||
42
wiki/sources/Linux-运维必会的150个命令.md
Normal file
42
wiki/sources/Linux-运维必会的150个命令.md
Normal file
@@ -0,0 +1,42 @@
|
||||
---
|
||||
title: "Linux 运维必会的 150 个命令"
|
||||
type: source
|
||||
tags: [Linux, 运维, 命令, 系统管理]
|
||||
date: 2026-04-15
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Home Office/Linux 运维必会的 150 个命令.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：Linux 系统管理核心命令速查手册
|
||||
- 问题域：文件操作、文本处理、系统监控、压缩解压
|
||||
- 方法/机制：按功能分类的 150 个命令速查表
|
||||
- 结论/价值：Linux 命令是系统管理的核心，熟练掌握是运维基本功
|
||||
|
||||
## Key Claims
|
||||
- Linux 系统一切皆文件（CPU、内存、磁盘、键盘、鼠标、用户）
|
||||
- 命令分为内置 Shell 命令和外部 Linux 命令
|
||||
- 150 个命令覆盖线上查询、文件目录操作、文件内容处理、信息显示等场景
|
||||
- 线上查询命令：man（命令帮助）、help（内置命令帮助）
|
||||
- 文件目录操作：ls/cd/cp/find/mkdir/mv/pwd/rename/rm/rmdir/touch/tree/basename/dirname/chattr/lsattr/file/md5sum
|
||||
- 文件内容处理：cat/tac/more/less/head/tail/cut/split/paste/sort/uniq/wc/iconv/dos2unix/diff/vimdiff/rev/grep/join/tr/vi/vim
|
||||
- 压缩解压：tar/unzip/gzip/zip
|
||||
- 信息显示：uname/hostname/dmesg/uptime/stat/du/df/top/free
|
||||
|
||||
## Key Concepts
|
||||
- [[Shell]]：命令解释器
|
||||
- [[管道]]：将多个命令组合实现复杂功能
|
||||
- [[正则表达式]]：文本匹配模式
|
||||
- [[管道符]]：| 命令连接符
|
||||
|
||||
## Key Entities
|
||||
- [[Linux]]：开源操作系统内核
|
||||
- [[GNU]]：开源软件集合
|
||||
|
||||
## Connections
|
||||
- [[Ubuntu-24.04-enable-SSH]] ← related_to [[Linux-运维必会的150个命令]]
|
||||
- [[用Docker中安装Navidrome]] ← related_to [[Linux-运维必会的150个命令]]
|
||||
|
||||
## Contradictions
|
||||
- 无冲突
|
||||
@@ -1,38 +0,0 @@
|
||||
---
|
||||
title: "Nano Banana 提示词框架"
|
||||
type: source
|
||||
tags: [AI提示词, AI生图, Google]
|
||||
date: 2026-03-15
|
||||
---
|
||||
|
||||
## Source File
|
||||
- raw/AI/Nano Banana 提示词框架.md
|
||||
|
||||
## Summary
|
||||
- 核心主题：Google Nano Banana 图像生成提示词的结构化框架
|
||||
- 问题域：如何精确描述视觉内容以获得高质量 AI 生成图像
|
||||
- 方法/机制：Shot/Subject/Environment/Lighting/Camera/ColorGrade/Style/Quality/Negatives 9 层结构化字段
|
||||
- 结论/价值：将主观审美转化为机器可精确执行的结构化参数，降低 AI 生成不确定性
|
||||
|
||||
## Key Claims
|
||||
- 物件描述与人物描述共用同一框架结构，仅 subject 字段内容不同
|
||||
- negatives（负向提示词）是质量控制的关键字段，必须明确排除不需要的特征
|
||||
- camera 字段（焦距/光圈/角度）提供电影级构图控制能力
|
||||
|
||||
## Key Quotes
|
||||
> "Studio softbox lighting. A key light from the top-left creates clean, sharp reflections on the steel." — 硬光实例
|
||||
> "High contrast, clean and commercial look. Slightly desaturated to emphasize the metallic and monochrome textures." — 色调实例
|
||||
|
||||
## Key Concepts
|
||||
- [[Nano Banana]]：Google 发布的结构化图像提示词框架，通过 9 个标准化字段将创意描述转化为机器可执行参数
|
||||
- [[Prompt工程]]：将主观创意转化为结构化提示词的过程，Nano Banana 是其具体实现
|
||||
- [[负向提示词]]（Negatives）：明确告知 AI 不应生成的内容，用于消除图像缺陷
|
||||
|
||||
## Key Entities
|
||||
- [[Google]]：Nano Banana 框架的发布方
|
||||
|
||||
## Connections
|
||||
- [[Nano Banana]] ← 应用于 ← [[AI生图]]
|
||||
- [[Prompt工程]] ← 支撑 ← [[Nano Banana]]
|
||||
|
||||
## Contradictions
|
||||
@@ -0,0 +1,85 @@
|
||||
---
|
||||
title: "Synology NAS + Xiaoya Alist + CloudDrive2 + Plex to Build Media Platform"
|
||||
type: source
|
||||
tags: [synology, nas, plex, alist, media, self-hosted]
|
||||
date: 2025-02-23
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Home Office/Synology NAS + Xiaoya Alist + CloudDrvie2+ Plex to Build Media Platform.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：利用群晖 NAS 整合阿里云盘资源，构建以 Plex 为前端的私有影视媒体平台
|
||||
- 问题域：如何绕过 NAS 容器管理器的网络限制安装 Docker 应用，并整合云盘资源与本地媒体库
|
||||
- 方法/机制：Plex 安装套件提供媒体管理；Xiaoya Alist（Docker）挂载阿里云盘分享资源；CloudDrive2（套件）将阿里云盘挂载为本地文件系统；Plex 扫描目录进行视频刮削
|
||||
- 结论/价值：完整记录了 Synology DSM 7+ 上通过 Docker 手动加载镜像安装应用、配置阿里云盘 token、并整合 Plex 媒体库的端到端流程
|
||||
|
||||
## Key Claims
|
||||
- 群晖套件中心可直接安装 Plex Media Server，安装后用 Apple ID 登录
|
||||
- Synology Container Manager 无法读取 Docker Hub 时，可通过另一台机器 docker pull 镜像 → docker save tar → 上传 NAS → docker load 导入
|
||||
- Docker 镜像导入需要 NAS 开启 SSH 访问（控制面板 → 终端机）
|
||||
- Xiaoya Alist 需要三个配置文件：myopentoken.txt（阿里云盘 refresh token）、mytoken.txt（Alist 访问 token）、temp_transfer_folder_id.txt（转存目标目录）
|
||||
- Aliyun refresh token 获取需访问 alist.nn.ci/tool/aliyundrive/request.html 并用阿里云盘 App 扫码授权
|
||||
- CloudDrive2 通过群晖套件中心社群频道安装，安装后需执行 sudo sed -i 's/package/root/g' /var/packages/CloudDrive2/conf/privilege 提权
|
||||
- CloudDrive2 挂载阿里云盘时仅授权资源目录，不授权备份目录
|
||||
- Plex 媒体库策略：通过 Xiaoya 选择资源 → 移动到 aliyun-movie/aliyun-tvshows 等目录 → Plex 自动刮削显示
|
||||
- 阿里云盘挂载后，xiaoya 和 CloudDrive2 共用同一阿里云盘账号数据
|
||||
|
||||
## Key Quotes
|
||||
> "用阿里云盘app扫描二维码，并授权，请主要，不要授权备份目录，仅资源目录即可" — CloudDrive2 安全配置要点
|
||||
> "目前我的Plex账号是用Apple ID: ishenwei@hotmail.com来进行登录的" — Plex 账号信息
|
||||
|
||||
## Key Concepts
|
||||
- [[媒体刮削]]：Plex 通过文件名/目录名匹配在线数据库（TheMovieDB/TVDB）自动获取影视元数据（海报、简介、评分）
|
||||
- [[Docker镜像导入]]：通过 docker save/docker load 在离线环境中迁移 Docker 镜像
|
||||
- [[阿里云盘挂载]]：通过 CloudDrive2 将阿里云盘远程挂载为本地文件系统，文件可被本地应用直接访问
|
||||
- [[资源聚合]]：Xiaoya Alist 整合多个公开分享资源，Plex 统一管理本地+云端媒体库
|
||||
- [[NAS Docker权限]]：Synology DSM 7+ 要求对第三方包执行 privilege 修复才可完整访问系统资源
|
||||
|
||||
## Key Entities
|
||||
- [[Plex]]：跨平台媒体服务器，支持视频音频转码、元数据刮削、多设备同步
|
||||
- [[Xiaoya Alist]]：阿里云盘资源聚合平台，支持分享链接转存到阿里云盘
|
||||
- [[CloudDrive2]]：群晖 NAS 套件，将云盘（阿里云盘/115/Google Drive等）挂载为本地文件系统
|
||||
- [[Synology NAS]]：群晖网络附加存储设备，提供 Docker（Container Manager）和套件中心两大应用平台
|
||||
- [[阿里云盘]]：阿里巴巴云存储服务，支持资源分享和 API 访问
|
||||
|
||||
## Connections
|
||||
- [[Plex]] ← 媒体库目录 ← [[CloudDrive2]]（阿里云盘挂载目录）
|
||||
- [[Plex]] ← 媒体库目录 ← NAS 本地存储目录
|
||||
- [[Xiaoya Alist]] ← 转存 ← [[阿里云盘]]
|
||||
- [[CloudDrive2]] ← 挂载 ← [[阿里云盘]]
|
||||
- [[Synology NAS]] ← 容器平台 ← [[Xiaoya Alist]]（Docker 部署）
|
||||
- [[Synology NAS]] ← 套件 ← [[CloudDrive2]] + [[Plex]]
|
||||
|
||||
## Contradictions
|
||||
- 无明显冲突
|
||||
|
||||
## 操作流程摘要
|
||||
|
||||
### 1. Plex 安装
|
||||
群晖套件中心 → 搜索 Plex Media Server → 安装 → 用 Apple ID（ishenwei@hotmail.com）登录
|
||||
|
||||
### 2. Xiaoya Alist 安装（离线镜像导入法）
|
||||
```bash
|
||||
# 在有网络的机器上
|
||||
docker pull xiaoyaliu/alist
|
||||
docker save -o xiaoya.tar xiaoyaliu/alist
|
||||
|
||||
# 上传 xiaoya.tar 到 NAS，通过 SSH 执行
|
||||
docker load < xiaoya.tar
|
||||
```
|
||||
|
||||
### 3. Xiaoya 配置文件准备
|
||||
- myopentoken.txt：访问 https://alist.nn.ci/tool/aliyundrive/request.html 扫码获取
|
||||
- mytoken.txt：访问阿里云盘分享授权页面获取
|
||||
- temp_transfer_folder_id.txt：在阿里云盘资源盘创建目录，将 URL 中的 folder token 写入
|
||||
|
||||
### 4. CloudDrive2 安装（DSM 7+）
|
||||
- 套件中心 → 设置 → 社群 → 添加矿神源
|
||||
- 安装 CloudDrive2 后执行：
|
||||
```bash
|
||||
sudo sed -i 's/package/root/g' /var/packages/CloudDrive2/conf/privilege
|
||||
```
|
||||
|
||||
### 5. Plex 媒体库配置
|
||||
媒体目录结构：aliyun-movie/、aliyun-tvshows/、aliyun-documentory/，由 Xiaoya 转存文件后 Plex 自动刮削
|
||||
105
wiki/sources/可自动化可扩展AI增强的电商数据采集与处理系统.md
Normal file
105
wiki/sources/可自动化可扩展AI增强的电商数据采集与处理系统.md
Normal file
@@ -0,0 +1,105 @@
|
||||
---
|
||||
title: "可自动化、可扩展、AI增强的电商数据采集与处理系统"
|
||||
type: source
|
||||
tags: [e-commerce, scraper, automation, n8n, ai, docker]
|
||||
date: 2025-11-11
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Home Office/可自动化、可扩展、AI增强的电商数据采集与处理系统.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：基于 Docker + Scrapy + Playwright + n8n 构建可自动化运行的电商数据采集与 AI 处理管线
|
||||
- 问题域：如何高效采集多电商平台产品数据，并通过 AI 实现清洗、分类、摘要和结构化输出
|
||||
- 方法/机制：Scrapy 负责结构化抓取和分页调度；Playwright 处理 JS 动态渲染页面；n8n 定时触发爬虫、读取结果、调用 AI（OpenAI/Ollama）处理、写入数据库/文件、发送通知
|
||||
- 结论/价值：提供完整 Docker Compose 架构、Scrapy 项目模板、n8n Workflow JSON 模板，实现从爬取到 AI 分析的全链路自动化
|
||||
|
||||
## Key Claims
|
||||
- Scrapy + Playwright 组合：Scrapy 负责结构化抓取、分页调度、下载媒体；Playwright 负责 JS 动态渲染页面；scrapy-playwright 插件直接集成两者
|
||||
- docker-compose 多容器架构：scraper（Scrapy+Playwright）、n8n（自动化调度），数据通过共享 ./data 目录传递
|
||||
- n8n Workflow 自动化管线：Cron Trigger → Execute Command（运行爬虫）→ Read File → AI 处理（OpenAI/Ollama）→ Database/File → 通知
|
||||
- 本地 AI 处理方案：Ollama（Mistral/Llama3）通过 HTTP Request 调用 http://localhost:11434/api/generate，不依赖外部 API
|
||||
- 防封策略：User-Agent 轮换、代理池（BrightData/ScraperAPI）、下载延迟+随机化访问、分布式调度（Scrapyd）
|
||||
- Scrapy 爬取结果输出为 JSON/CSV 格式，供 n8n 消费处理
|
||||
- 采集数据建议字段：title、price、rating、image_urls、product_url
|
||||
- 长期扩展路径：FastAPI 服务层 + LangChain + Qdrant 向量数据库 + Grafana/Metabase 可视化
|
||||
- Playwright 需安装浏览器：playwright install，支持 headless 模式和 viewport 参数配置
|
||||
|
||||
## Key Quotes
|
||||
> "Scrapy 负责结构化抓取、分页调度、下载媒体；Playwright 负责加载动态页面；两者可通过 Docker Compose 容器化" — 推荐技术组合
|
||||
> "可以本地使用 Ollama (Mistral, Llama3) 模型，通过 n8n 的 HTTP Request 调用本地 http://localhost:11434/api/generate" — 本地 AI 处理方案
|
||||
|
||||
## Key Concepts
|
||||
- [[Scrapy]]：Python 开源爬虫框架，支持异步抓取、中间件扩展、Item Pipeline，适合大规模结构化数据采集
|
||||
- [[Playwright]]：Microsoft 开源浏览器自动化工具，支持 Chromium/Firefox/WebKit，可模拟真实用户操作
|
||||
- [[scrapy-playwright]]：Scrapy 与 Playwright 集成插件，使 Scrapy 爬虫可直接渲染 JS 动态页面
|
||||
- [[n8n Workflow自动化]]：可视化工作流引擎，通过 Cron 定时触发爬虫执行、文件读取、AI 处理、数据存储全流程
|
||||
- [[Ollama]]：本地大模型推理服务，支持 Llama3/Mistral 等模型，通过 REST API 调用
|
||||
- [[电商数据采集]]：从电商平台采集产品标题、价格、评分、图片等结构化信息
|
||||
- [[AI数据处理]]：通过 LLM 对采集数据进行摘要、分类、特征提取、异常检测
|
||||
- [[防封策略]]：User-Agent 轮换、代理池、访问延迟、分布式调度等反爬虫对抗技术
|
||||
- [[Docker容器化爬虫]]：将 Scrapy + Playwright 封装为 Docker 镜像，实现环境一致性部署
|
||||
|
||||
## Key Entities
|
||||
- [[Scrapy]]：Python 爬虫框架
|
||||
- [[Playwright]]：Microsoft 浏览器自动化工具
|
||||
- [[n8n]]：开源工作流自动化平台
|
||||
- [[Ollama]]：本地 LLM 推理引擎
|
||||
- [[BrightData]]：商业代理池服务
|
||||
- [[ScraperAPI]]：爬虫 API 服务
|
||||
|
||||
## Connections
|
||||
- [[Scrapy]] ← 动态渲染 ← [[Playwright]]（通过 scrapy-playwright）
|
||||
- [[n8n Workflow自动化]] ← Cron Trigger ← [[Scrapy]]（执行爬虫命令）
|
||||
- [[n8n Workflow自动化]] ← AI处理 ← [[Ollama]]（本地模型调用）
|
||||
- [[n8n Workflow自动化]] ← 数据写入 ← PostgreSQL/SQLite
|
||||
- [[Scrapy]] ← 输出格式 ← JSON/CSV（data/ 目录）
|
||||
- [[电商数据采集]] ← 工具 ← [[Scrapy]] + [[Playwright]]
|
||||
- [[AI数据处理]] ← 工具 ← [[n8n Workflow自动化]] + [[Ollama]]
|
||||
|
||||
## Contradictions
|
||||
- 无明显冲突
|
||||
|
||||
## 核心架构代码
|
||||
|
||||
### docker-compose.yml
|
||||
|
||||
```yaml
|
||||
services:
|
||||
scraper:
|
||||
build: ./scrapy
|
||||
volumes:
|
||||
- ./data:/app/data
|
||||
depends_on:
|
||||
- playwright
|
||||
environment:
|
||||
- PLAYWRIGHT_BROWSERS_PATH=/ms-playwright
|
||||
playwright:
|
||||
image: mcr.microsoft.com/playwright/python:v1.48.0-jammy
|
||||
shm_size: 2gb
|
||||
```
|
||||
|
||||
### Scrapy settings.py（关键配置）
|
||||
|
||||
```python
|
||||
DOWNLOAD_HANDLERS = {
|
||||
"http": "scrapy_playwright.handler.ScrapyPlaywrightDownloadHandler",
|
||||
"https": "scrapy_playwright.handler.ScrapyPlaywrightDownloadHandler",
|
||||
}
|
||||
TWISTED_REACTOR = "twisted.internet.asyncioreactor.AsyncioSelectorReactor"
|
||||
PLAYWRIGHT_LAUNCH_OPTIONS = {
|
||||
"headless": True,
|
||||
"args": ["--no-sandbox", "--disable-setuid-sandbox"],
|
||||
}
|
||||
FEEDS = {"/app/data/amazon.json": {"format": "json", "overwrite": True}}
|
||||
```
|
||||
|
||||
### n8n Workflow 节点链路
|
||||
|
||||
1. Cron Trigger（每天凌晨 2:00）
|
||||
2. Execute Command（docker exec scraper scrapy crawl amazon）
|
||||
3. Read Binary File（读取 /data/products.json）
|
||||
4. Function Node（解析 JSON）
|
||||
5. OpenAI / HTTP Request（Ollama 本地调用）
|
||||
6. Write Binary File（输出 products_summary.json）
|
||||
7. Email / Telegram（发送日报）
|
||||
@@ -0,0 +1,153 @@
|
||||
---
|
||||
title: "家庭监控方案：Prometheus + Grafana + Node Exporter + cAdvisor + Blackbox"
|
||||
type: source
|
||||
tags: [monitoring, prometheus, grafana, self-hosted]
|
||||
date: 2025-11-11
|
||||
---
|
||||
|
||||
## Source File
|
||||
- [[raw/Home Office/家庭监控方案：Prometheus + Grafana + Node Exporter + cAdvisor +Blackbox.md]]
|
||||
|
||||
## Summary
|
||||
- 核心主题：家庭/小型实验室环境基于 Docker 的可观测性监控方案，覆盖主机层、容器层、服务层和合成监测
|
||||
- 问题域：如何用开源工具低成本构建完整的监控告警体系
|
||||
- 方法/机制：Prometheus 拉模式采集 + Grafana 可视化 + Alertmanager 告警分发；cAdvisor 采集容器指标；blackbox_exporter 做 HTTP/TCP/DNS 合成监测；node_exporter 采集主机指标
|
||||
- 结论/价值：提供两套 docker-compose 模板（轻量/PoC），以及可直接拷贝的 prometheus.yml、告警规则和 Alertmanager 配置
|
||||
|
||||
## Key Claims
|
||||
- Prometheus 拉模式（pull-based）适配多主机监控，通过 scrape_configs 抓取各 exporter 指标
|
||||
- cAdvisor 容器指标需挂载 /var/lib/docker/ 才可完整采集容器资源使用情况
|
||||
- blackbox_exporter 支持 HTTP/TCP/ICMP/DNS 四类探测，可监控内外网服务可用性和 TLS 证书到期
|
||||
- Alertmanager 支持邮件/Slack/Webhook/PagerDuty 分组抑制告警，避免告警风暴
|
||||
- docker-compose 部署 Prometheus + Grafana + cAdvisor + blackbox_exporter + Alertmanager 一键启动
|
||||
- Grafana 导入 Dashboard 只需 ID（Node Exporter Full: 1860、cAdvisor: 14282、Blackbox: 7587）
|
||||
- Docker Socket 挂载存在安全风险，容器可获取宿主机 root 等同权限
|
||||
- TLS 证书到期可通过 probe_ssl_earliest_cert_expiry 指标监控，提前 14 天告警
|
||||
- 建议将监控流量放在管理 VLAN 或通过防火墙限定访问
|
||||
- Prometheus 本地磁盘会持续增长，长期保留需配置 remote_write 到 VictoriaMetrics 等远端存储
|
||||
|
||||
## Key Quotes
|
||||
> "Prometheus 本地磁盘会增长，考虑长期保留要用远端存储或定期 snapshot" — 生产级存储建议
|
||||
> "Prometheus 支持对同一网站设置下载延迟 + 随机化访问，防止被封禁" — 爬虫防封策略
|
||||
|
||||
## Key Concepts
|
||||
- [[Prometheus]]：开源时序数据库和监控告警系统，支持 PromQL 查询语言和告警规则引擎
|
||||
- [[Grafana]]：开源可观测性平台，支持时序数据可视化、仪表盘和告警通知
|
||||
- [[Alertmanager]]：Prometheus 生态告警分发组件，支持分组、抑制和路由
|
||||
- [[cAdvisor]]：Google 开源容器资源监控工具，采集 CPU、内存、网络、磁盘 I/O 指标
|
||||
- [[node_exporter]]：Prometheus 官方主机指标 exporter，采集 CPU、内存、磁盘、网络指标
|
||||
- [[blackbox_exporter]]：Prometheus 官方黑盒监测 exporter，支持 HTTP/TCP/DNS/ICMP 探测
|
||||
- [[PromQL]]：Prometheus Query Language，用于查询和聚合时序指标
|
||||
- [[可观测性]]：监控系统三大支柱（Metrics/Logs/Traces）
|
||||
- [[合成监测]]：Synthetic Monitoring，通过探针模拟用户请求检测服务可用性
|
||||
- [[Prometheus告警规则]]：基于 PromQL 表达式持续评估，达到阈值触发告警
|
||||
- [[Docker Socket安全]]：挂载 /var/run/docker.sock 等同给予容器宿主机 root 权限
|
||||
|
||||
## Key Entities
|
||||
- [[Uptime Kuma]]：自托管网站监控工具，支持 HTTP/TCP/DNS/TLS 探测，适合合成监测外层 UI
|
||||
- [[Loki]]：Grafana Labs 日志聚合系统，与 Prometheus/Grafana 原生集成，轻量级
|
||||
- [[VictoriaMetrics]]：高性能时序数据库，兼容 Prometheus remote_write API，适合长期存储
|
||||
- [[Portainer]]：Docker 可视化管理工具，不替代 Prometheus 但便于运维操作
|
||||
|
||||
## Connections
|
||||
- [[Prometheus]] ← scrape_configs ← [[node_exporter]]
|
||||
- [[Prometheus]] ← scrape_configs ← [[cAdvisor]]
|
||||
- [[Prometheus]] ← scrape_configs ← [[blackbox_exporter]]
|
||||
- [[Grafana]] ← 数据源 ← [[Prometheus]]
|
||||
- [[Alertmanager]] ← 告警接收 ← [[Prometheus]]
|
||||
- [[Grafana]] ← 仪表盘 ← [[cAdvisor]] / [[node_exporter]] / [[blackbox_exporter]]
|
||||
- [[Prometheus]] ← 远端存储 ← [[VictoriaMetrics]]
|
||||
|
||||
## Contradictions
|
||||
- 无明显冲突
|
||||
|
||||
## Infrastructure Code
|
||||
|
||||
### docker-compose.yml 核心配置
|
||||
|
||||
```yaml
|
||||
services:
|
||||
prometheus:
|
||||
image: prom/prometheus:latest
|
||||
ports: ["9090:9090"]
|
||||
volumes:
|
||||
- ./prometheus/prometheus.yml:/etc/prometheus/prometheus.yml:ro
|
||||
- ./prometheus/alerts.yml:/etc/prometheus/alerts.yml:ro
|
||||
- prometheus-data:/prometheus
|
||||
command: ['--config.file=/etc/prometheus/prometheus.yml', '--storage.tsdb.path=/prometheus', '--web.enable-lifecycle']
|
||||
|
||||
grafana:
|
||||
image: grafana/grafana:latest
|
||||
ports: ["3000:3000"]
|
||||
environment:
|
||||
- GF_AUTH_ANONYMOUS_ENABLED=true
|
||||
- GF_AUTH_ANONYMOUS_ORG_ROLE=Viewer
|
||||
|
||||
node_exporter:
|
||||
image: prom/node-exporter:latest
|
||||
network_mode: "host"
|
||||
pid: "host"
|
||||
volumes:
|
||||
- /proc:/host/proc:ro
|
||||
- /sys:/host/sys:ro
|
||||
- /:/rootfs:ro
|
||||
|
||||
cadvisor:
|
||||
image: gcr.io/cadvisor/cadvisor:latest
|
||||
ports: ["8080:8080"]
|
||||
volumes:
|
||||
- /:/rootfs:ro
|
||||
- /var/run:/var/run:ro
|
||||
- /sys:/sys:ro
|
||||
- /var/lib/docker/:/var/lib/docker:ro
|
||||
|
||||
blackbox:
|
||||
image: prom/blackbox-exporter:latest
|
||||
ports: ["9115:9115"]
|
||||
```
|
||||
|
||||
### prometheus.yml scrape_configs
|
||||
|
||||
```yaml
|
||||
scrape_configs:
|
||||
- job_name: 'node_exporter'
|
||||
file_sd_configs:
|
||||
- files: ['/etc/prometheus/targets/node.yml']
|
||||
- job_name: 'cadvisor'
|
||||
file_sd_configs:
|
||||
- files: ['/etc/prometheus/targets/cadvisor.yml']
|
||||
- job_name: 'blackbox_http'
|
||||
metrics_path: /probe
|
||||
params: { module: [http_2xx] }
|
||||
file_sd_configs:
|
||||
- files: ['/etc/prometheus/targets/blackbox.yml']
|
||||
relabel_configs:
|
||||
- source_labels: [__address__]
|
||||
target_label: __param_target
|
||||
- target_label: __address__
|
||||
replacement: blackbox:9115
|
||||
```
|
||||
|
||||
### 核心告警规则
|
||||
|
||||
```yaml
|
||||
- alert: HostHighCPU
|
||||
expr: avg(rate(node_cpu_seconds_total{mode="user"}[2m])) * 100 > 85
|
||||
for: 2m
|
||||
labels:
|
||||
severity: warning
|
||||
annotations:
|
||||
summary: "高 CPU 使用率"
|
||||
|
||||
- alert: HostLowDisk
|
||||
expr: (node_filesystem_avail_bytes{fstype!~"tmpfs|overlay"} / node_filesystem_size_bytes{fstype!~"tmpfs|overlay"}) < 0.10
|
||||
for: 5m
|
||||
labels:
|
||||
severity: critical
|
||||
|
||||
- alert: TLSCertExpiring
|
||||
expr: probe_ssl_earliest_cert_expiry - time() < 86400 * 14
|
||||
for: 1h
|
||||
labels:
|
||||
severity: warning
|
||||
```
|
||||
Reference in New Issue
Block a user