diff --git a/wiki/concepts/BEATS.md b/wiki/concepts/BEATS.md new file mode 100644 index 00000000..b287de0f --- /dev/null +++ b/wiki/concepts/BEATS.md @@ -0,0 +1,59 @@ +--- +title: "BEATS" +type: concept +tags: [DevOps, Observability, Logging, OpenSource] +sources: [ctp-topic-54-esm-saas-log-analytics] +last_updated: 2026-04-25 +--- + +# BEATS + +**BEATS** 是 Elastic 公司开发的轻量级开源日志与指标数据采集代理家族，属于 ELK Stack 的数据采集层。名称来自 "Beats" 系列工具（Filebeat、Metricbeat、Packetbeat 等）。 + +## Core Concept + +*"The application collects your log, it's called the BEATS."* — Jackie + +BEATS 代理部署在应用侧，轻量级运行，持续将日志数据推送至 Logstash 或 Elasticsearch/OpenSearch。 + +## Member Tools + +| Tool | Purpose | +|------|---------| +| **Filebeat** | 日志文件采集（最常用），支持容器环境（Kubernetes DaemonSet） | +| **Metricbeat** | 系统和服务指标采集 | +| **Packetbeat** | 网络数据包分析 | +| **Heartbeat** | 站点可用性探测 | +| **Auditbeat** | Linux 审计框架数据 | +| **Journalbeat** | systemd journal 采集 | + +## Use in ELK Architecture + +``` +应用层 (Application VPC) + └── Filebeat (容器/DaemonSet) → 持续采集日志文件 + ↓ +日志层 (Logging VPC) + └── Logstash → 解析和转换字段 + ↓ + └── Elasticsearch/OpenSearch → 存储 + ↓ + └── Kibana → 可视化 +``` + +## Key Claims + +- Filebeat 是在 Kubernetes 容器环境中部署日志采集的首选方案 +- BEATS 代理轻量、低资源占用，适合在每个应用节点部署 +- Filebeat 支持多行日志合并（如 Java Stack Trace）和多种日志格式解析 + +## Related Concepts + +- [[ELK-Stack]]：BEATS 是 ELK 栈的采集层 +- [[Logstash]]：BEATS 采集的数据通常先推送至 Logstash 进行处理 +- [[OpenSearch]]：Filebeat 可直接推送至 OpenSearch，无需 Logstash +- [[Centralized-Logging]]：BEATS 是集中式日志采集的重要组件 + +## Sources + +- [[ctp-topic-54-esm-saas-log-analytics]] diff --git a/wiki/concepts/CIS-Benchmark.md b/wiki/concepts/CIS-Benchmark.md new file mode 100644 index 00000000..e552b04e --- /dev/null +++ b/wiki/concepts/CIS-Benchmark.md @@ -0,0 +1,71 @@ +--- +title: "CIS Benchmark" +type: concept +tags: + - Security + - Compliance + - Hardening + - Standards +sources: + - public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w +last_updated: 2026-04-24 +--- + +# CIS Benchmark + +CIS Benchmark（Center for Internet Security Benchmark）是全球最具权威的 IT 基础设施安全加固指南，由非营利组织 CIS（Center for Internet Security）维护，涵盖操作系统、数据库、Web 服务器、容器平台等数百种技术的安全配置标准。 + +## 核心特点 + +- **社区驱动**：基于全球安全专家的共识实践，经多轮评审和测试 +- **中立性**：独立于厂商，为任何组织提供客观的安全配置建议 +- **分级设计**：Level 1（基础安全，适合大多数环境）和 Level 2（深度防御，适合高安全要求环境） +- **广泛覆盖**：涵盖 100+ 技术类别，包括 Linux、Windows、macOS、AWS、GCP、Azure、Kubernetes、Docker 等 + +## 典型检查项示例（Linux） + +| 类别 | Level | 检查项 | +|------|-------|--------| +| 初始设置 | 1 | 确认是否禁用不必要的服务（如 telnet、rsh） | +| 服务配置 | 1 | 配置 SSH 禁用 root 登录和密码认证 | +| 日志配置 | 1 | 启用审计日志并配置适当的日志轮转 | +| 文件系统 | 2 | 配置 `/tmp` 目录为 noexec、nosuid、nodev | +| 访问控制 | 1 | 配置 PAM 强制密码复杂度 | +| 网络配置 | 2 | 配置防火墙规则限制入站流量 | + +## 在 Bottlerocket 中的支持 + +Bottlerocket OS 提供专用的 CIS Benchmark 安全加固指南： +- 预配置的 SE Linux 策略覆盖大部分容器相关检查项 +- 只读根文件系统和 dm-verity 自动满足多项文件系统完整性要求 +- 分区设计满足审计日志分离存储要求 +- 最佳实践：使用 CIS Benchmark 自动化工具（如 CIS-CAT）定期扫描 Bottlerocket 节点合规性 + +## 认证与合规 + +CIS Benchmark 是多项安全合规框架的重要组成部分： + +| 合规框架 | 与 CIS Benchmark 的关系 | +|---------|------------------------| +| PCI-DSS | 引用 CIS Benchmarks 作为技术控制要求 | +| SOC 2 | 推荐 CIS Benchmarks 作为安全配置基线 | +| ISO 27001 | 参考 CIS Benchmarks 满足访问控制要求 | +| NIST CSF | CIS Benchmarks 映射到 NIST Cybersecurity Framework | +| FedRAMP | 使用 CIS Benchmarks 作为云服务安全基线 | + +## 工具支持 + +- **CIS-CAT Pro**：官方自动化评估工具，支持扫描并生成合规报告 +- **InSpec**：Chef 的合规性即代码框架，有 CIS Benchmark 配置文件 +- **OpenSCAP**：开源 CVE/配置扫描工具，有 CIS Benchmark 配置文件 +- **kube-bench**：Kubernetes CIS Benchmark 自动化评估工具 + +## 与其他安全标准的对比 + +| 标准 | 侧重点 | 适用范围 | +|------|--------|---------| +| CIS Benchmark | 安全配置最佳实践 | 操作系统、应用、云服务 | +| NIST SP 800-53 | 联邦信息安全控制 | 美国政府机构 | +| ISO 27001/27002 | 信息安全管理体系 | 所有组织 | +| DISA STIG | 国防部安全技术实施指南 | 美国国防部系统 | +| SOC 2 Trust Criteria | 服务组织控制 | SaaS/云服务提供商 | diff --git a/wiki/concepts/ELK-Stack.md b/wiki/concepts/ELK-Stack.md new file mode 100644 index 00000000..48042171 --- /dev/null +++ b/wiki/concepts/ELK-Stack.md @@ -0,0 +1,60 @@ +--- +title: "ELK Stack" +type: concept +tags: [DevOps, Observability, Logging, OpenSource, AWS] +sources: [ctp-topic-54-esm-saas-log-analytics] +last_updated: 2026-04-25 +--- + +# ELK Stack + +**ELK Stack** 是由 Elasticsearch、Logstash 和 Kibana 三个开源组件组成的日志分析与全文检索技术栈，是企业级日志分析的业界标准方案。 + +## Components + +| Component | Role | Description | +|-----------|------|-------------| +| **Elasticsearch** | 存储与检索引擎 | 分布式全文搜索和分析引擎，负责存储和查询日志数据 | +| **Logstash** | 数据处理管道 | 采集、解析和转换日志字段，为每列数据赋予语义 | +| **Kibana** | 可视化前端 | 日志文件可视化和分析的用户界面 | +| **BEATS** | 轻量级采集代理 | 部署在应用侧的日志采集器家族（Filebeat/Metricbeat 等） | + +## Architecture + +``` +应用层 (Application VPC) + └── Filebeat (容器/DaemonSet) → 持续采集日志 + ↓ +日志层 (Logging VPC) + └── Logstash → 解析日志字段 + ↓ + └── (Redis Buffer, 可选) → 防止 Logstash 过载 + ↓ + └── Elasticsearch / OpenSearch → 存储索引 + ↓ + └── Kibana → 可视化查询 +``` + +## OpenSearch (AWS Fork) + +**OpenSearch** 是 Elasticsearch 7.10.2 的开源分支，由 AWS 主导维护，提供与 Elasticsearch 兼容的 API，作为 AWS 托管服务（Amazon OpenSearch Service）提供。ELK 栈中 Elasticsearch 可被 OpenSearch 无缝替代。 + +## Related Concepts + +- [[Centralized-Logging]]：集中式日志管理的总体概念，ELK 是其核心实现技术 +- [[Cloud-Monitoring]]：可观测性三支柱（指标/日志/链路追踪）之一 +- [[OpenSearch]]：ELK 中 Elasticsearch 的 AWS 托管替代 +- [[Kibana]]：ELK 栈的可视化层 +- [[BEATS]]：ELK 栈的轻量级日志采集代理 + +## Key Claims + +- ELK 栈是开源日志分析的标准方案，架构成熟、生态丰富 +- Filebeat 常用作 Kubernetes 容器环境下的日志采集器（DaemonSet 部署） +- Logstash 作为处理管道，可解析 JSON/Nginx/Apache 等多格式日志 +- OpenSearch 是 Elasticsearch 的开源分支，AWS 提供托管服务（OpenSearch Service） +- VPC 间日志传输走私有网络，不经过互联网 + +## Sources + +- [[ctp-topic-54-esm-saas-log-analytics]] diff --git a/wiki/concepts/Immutable-Root-Filesystem.md b/wiki/concepts/Immutable-Root-Filesystem.md new file mode 100644 index 00000000..7210960d --- /dev/null +++ b/wiki/concepts/Immutable-Root-Filesystem.md @@ -0,0 +1,52 @@ +--- +title: "Immutable Root Filesystem" +type: concept +tags: + - Security + - Linux + - Container OS +sources: + - public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w +last_updated: 2026-04-24 +--- + +# Immutable Root Filesystem + +只读根文件系统是一种操作系统安全加固技术，通过将根文件系统挂载为只读，确保操作系统核心文件在运行时无法被修改。任何运行时变更必须通过镜像更新机制完成，从而消除因意外或恶意修改导致的系统不可用风险。 + +## 核心原理 + +根文件系统在启动后被挂载为只读（read-only），即使拥有 root 权限也无法直接写入 `/` 目录下的文件。需要修改系统配置时，必须： +1. 重新构建包含更新内容的 OS 镜像 +2. 通过安全的更新机制（如 A/B 分区切换）部署新镜像 +3. 重启系统以激活变更 + +## 典型实现 + +| 技术 | 实现方式 | +|------|---------| +| dm-verity | 通过加密哈希树验证根文件系统块设备完整性，篡改被检测 | +| OverlayFS | 在只读底层之上叠加可写层，但底层不变 | +| OSTree | Git-like 分层镜像系统，支持原子升级和回滚 | +| A/B 分区 | 双分区设计，在线下载新镜像到非活动分区，重启切换 | + +## 在 Bottlerocket 中的实现 + +Bottlerocket OS 默认启用只读根文件系统： +- 根分区通过 dm-verity 加密验证，任何篡改被检测 +- `/etc` 目录作为 tmpfs（临时文件系统），运行时可写但重启清空 +- 所有持久配置通过 API 或 userdata 注入，不直接修改根文件系统 + +## 安全价值 + +- **防篡改**：恶意软件无法修改系统关键文件 +- **一致性保证**：每次启动系统状态可预测 +- **最小化攻击面**：无需运行时包管理器，降低漏洞暴露 +- **原子更新**：通过镜像级更新确保系统要么完全更新，要么保持原状 + +## 适用场景 + +- 容器宿主操作系统（Bottlerocket、Flatcar Container Linux、CoreOS） +- 嵌入式安全系统 +- 无法物理访问的远程服务器 +- 需要严格合规（如 PCI-DSS、FIPS）的基础设施 diff --git a/wiki/concepts/OpenTelemetry.md b/wiki/concepts/OpenTelemetry.md new file mode 100644 index 00000000..1a4632dd --- /dev/null +++ b/wiki/concepts/OpenTelemetry.md @@ -0,0 +1,90 @@ +--- +title: "OpenTelemetry" +type: concept +tags: [DevOps, Observability, Cloud-Native, CNCF, AWS] +sources: [public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113, ctp-topic-67-cloud-native-observability-using-opentelemetry] +last_updated: 2026-04-27 +--- + +# OpenTelemetry + +**OpenTelemetry**（OTel）是云原生计算基金会（CNCF）的可观测性框架，提供跨语言的统一遥测数据采集标准，涵盖 Traces（链路追踪）、Metrics（指标）和 Logs（日志）三种信号。 + +## Core Components + +| Component | Role | Description | +|-----------|------|-------------| +| **OTLP Protocol** | 标准化传输 | OpenTelemetry Protocol，遥测数据的标准化传输格式 | +| **Language SDKs** | 应用集成 | 11 种语言提供统一 SDK（Java/Python/Go/Node.js/.NET 等） | +| **Collector** | 数据处理管道 | 标准化和转换遥测数据，包含 Receivers/Processors/Exporters/Extensions | +| **Auto-Instrumentation** | 零侵入注入 | 自动检测应用语言并注入遥测代码，无需修改业务代码 | + +## Three Signals Model（三信号模型） + +可观测性依赖三种互补的遥测信号： + +| Signal | 用途 | 特点 | +|--------|------|------| +| **Metrics** | 聚合统计 | CPU/内存/请求率等数值指标，适合告警和趋势分析 | +| **Logs** | 根因定位 | 离散的事件记录，包含时间戳和上下文，用于问题排查 | +| **Traces** | 全链路追踪 | 单一请求在分布式系统中的完整路径，每个 trace 包含多个 span | + +## OpenTelemetry Collector Architecture + +``` +Receivers（接收器）→ Processors（处理器）→ Exporters（导出器） + ↑ ↓ + Extensions（扩展） 目标后端（OpenSearch/Grafana/CloudWatch 等） +``` + +- **Receivers**：接收数据（AWS-specific 或开源标准） +- **Processors**：过滤和转换数据 +- **Exporters**：导出至后端（AWS Native / Open Source / Third-party） +- **Extensions**：辅助功能（SIGV 授权、健康检查） + +## AWS Distribution for OpenTelemetry + +AWS 提供的 OpenTelemetry 统一发行版，在 CNCF OpenTelemetry 基础上增加了 AWS 集成： + +- **统一代理**：同时收集 Traces/Metrics/Logs，无需分别部署多种 Agent +- **EKS Operator**：自动检测应用语言并创建预配置 Collector，实现零侵入式自动注入 +- **Pod 级 IAM**：通过 Pod Identity Associations 实现 Pod 级权限控制，无需修改 ServiceAccount +- **日志支持**：最新版本支持日志采集，完善了可观测性三信号覆盖 +- **Managed Collector for Prometheus**：无服务器、无代理的 Prometheus 指标自动发现和抓取 + +## EKS Integration Pipeline + +典型 EKS 环境下的端到端可观测性管道： + +``` +应用容器 (Auto-Instrumented by OTel SDK) + ↓ +Fluent Bit (DaemonSet) → 采集容器日志 + ↓ (端口 55681) +OpenTelemetry Collector (Sidecar/Deployment) + ↓ (OTLP) +Amazon OpenSearch Service / CloudWatch / Prometheus / Grafana +``` + +## Key Claims + +- OpenTelemetry 是 CNCF 毕业项目，提供 vendor-agnostic（厂商无关）的统一可观测性方案 +- 解决了微服务架构下不同组件使用不同 SDK 和工具的碎片化问题 +- OTLP 是 OpenTelemetry 的标准化数据传输协议，所有主流可观测性后端均支持 +- AWS Distribution for OpenTelemetry 简化了 AWS 环境（尤其是 EKS）的部署复杂度 +- 自动注入（Auto-Instrumentation）实现零侵入式集成，无需修改业务代码 + +## Related Concepts + +- [[ELK-Stack]]：OpenTelemetry 常与 OpenSearch/Elasticsearch 配合作为日志后端 +- [[Cloud-Monitoring]]：可观测性是云监控的核心组成部分 +- [[Amazon-EKS]]：OpenTelemetry 在 AWS EKS 环境下的典型部署场景 +- [[Fluent-Bit]]：EKS 环境中常用的日志采集器，与 OpenTelemetry 配合使用 +- [[Grafana]]：OpenTelemetry 常用的可视化后端 +- [[Prometheus]]：OpenTelemetry Metrics 的常用后端 +- [[Observability（可观测性）]]：OpenTelemetry 服务的核心目标 + +## Sources + +- [[public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113]] +- [[ctp-topic-67-cloud-native-observability-using-opentelemetry]] diff --git a/wiki/concepts/Partition-Updates.md b/wiki/concepts/Partition-Updates.md new file mode 100644 index 00000000..2b9e7d2e --- /dev/null +++ b/wiki/concepts/Partition-Updates.md @@ -0,0 +1,70 @@ +--- +title: "Partition Updates" +type: concept +tags: + - Operating System + - Updates + - Reliability + - A/B Testing +sources: + - public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w +last_updated: 2026-04-24 +--- + +# Partition Updates（分区镜像更新） + +分区镜像更新是一种操作系统原子更新策略，通过 A/B 双分区设计，在线下载新版本镜像到非活动分区，重启后切换激活，确保更新过程的原子性和系统一致性。 + +## 核心设计 + +``` +┌─────────────────────────────────────────────┐ +│ 磁盘布局 │ +│ ┌──────────┐ ┌──────────┐ ┌──────────┐ │ +│ │ 分区 A │ │ 分区 B │ │ Data Vol │ │ +│ │ (活动) │ │ (备用) │ │ (数据卷) │ │ +│ │ OS v1.0 │ │ OS v1.1 │ │ 容器镜像 │ │ +│ │ 正在运行 │ │ 空闲 │ │ 持久数据 │ │ +│ └──────────┘ └──────────┘ └──────────┘ │ +└─────────────────────────────────────────────┘ +``` + +**更新流程：** +1. 下载新版本镜像到备用分区（分区 B） +2. 验证镜像完整性（哈希校验 + 签名验证） +3. 更新引导配置，指向新分区 +4. 重启系统 +5. 固件/引导加载程序从新分区启动 +6. 新分区变为活动分区，旧分区变为备用分区 + +## 优势 + +- **原子性**：更新要么完全成功，要么系统回退到原状态，不存在"半更新"状态 +- **回滚能力**：如果新版本启动失败，可手动或自动回滚到旧分区 +- **零停机更新**：无需停止正在运行的工作负载即可下载和准备新版本 +- **一致性保证**：切换前已完成新镜像验证，确保启动后的系统状态可预测 +- **适用于关键系统**：电信、金融、工业控制系统等不能容忍更新失败的业务 + +## 与传统包管理更新的对比 + +| 维度 | 包管理更新（apt/yum） | 分区镜像更新（A/B） | +|------|---------------------|-------------------| +| 原子性 | 非原子（可能中断于中途） | 原子（全部成功或全部失败） | +| 回滚 | 依赖包管理器功能，通常复杂 | 简单（切换回旧分区即可） | +| 根文件系统一致性 | 难以保证 | 完整镜像替换，一致性保证 | +| 适用场景 | 通用 Linux 服务器 | 容器宿主、嵌入式系统 | +| 存储开销 | 无额外开销 | 需要双倍存储空间 | + +## 在 Bottlerocket 中的实现 + +Bottlerocket OS 采用分区镜像更新机制： +- 根分区分为 A、B 两组，每组包含 `root_a`/`root_b` 逻辑分区 +- Data Volume（数据卷）独立于根分区，存储容器镜像和应用数据，更新不受影响 +- Data Volume 支持快照预填充（snapshot pre-population），可在构建时就注入容器镜像，加快首次启动 +- 通过 Bottlerocket API 查看当前活动分区版本和待激活版本 + +## 相关技术 + +- [[OSTree]]：基于 Git 的操作系统更新系统，类似的原子升级理念 +- [[Immutable-Root-Filesystem]]：分区更新的最终目标——确保根文件系统一致性 +- [[dm-verity]]：与分区更新配合，验证新分区的完整性 diff --git a/wiki/concepts/SE-Linux-Enforcing.md b/wiki/concepts/SE-Linux-Enforcing.md new file mode 100644 index 00000000..a8051356 --- /dev/null +++ b/wiki/concepts/SE-Linux-Enforcing.md @@ -0,0 +1,74 @@ +--- +title: "SE Linux Enforcing Mode" +type: concept +tags: + - Security + - Linux + - MAC + - Access Control +sources: + - public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w +last_updated: 2026-04-24 +--- + +# SE Linux Enforcing Mode + +SE Linux（Security-Enhanced Linux）是美国国家安全局（NSA）开发的 Linux 内核安全模块，通过强制访问控制（MAC，Mandatory Access Control）机制，在传统的自主访问控制（DAC，Discretionary Access Control）之上增加了一层细粒度的安全策略。 + +## DAC vs MAC + +| 维度 | DAC（传统 Linux 权限） | MAC（SE Linux） | +|------|----------------------|----------------| +| 控制方式 | 所有者自主决定 | 系统统一策略强制执行 | +| 粒度 | 用户/组/其他 + rwx | 主体标签 + 客体标签 + 策略规则 | +| 绕过风险 | root 可修改任何权限 | 即使 root 也受策略约束 | +| 配置难度 | 简单（chmod/chown） | 复杂（需要策略编写） | + +## 关键概念 + +- **主体（Subject）**：进程，通常具有特定的安全上下文（如 `system_u:system_r:container_file_t`） +- **客体（Object）**：文件、目录、端口、进程等系统资源 +- **安全上下文（Security Context）**：格式为 `user:role:type[:level]` 的标签字符串 +- **策略规则（Policy Rules）**：定义哪些主体可以对哪些客体执行哪些操作的规则集合 +- **Enforcing 模式**：强制执行策略，违反策略的操作被拒绝并记录 +- **Permissive 模式**：仅记录违反策略的操作，不实际阻止 + +## Bottlerocket 中的 SE Linux + +Bottlerocket OS 默认启用 SE Linux enforcing 模式： +- **容器隔离**：每个容器运行在独立的安全上下文中，防止容器逃逸后影响宿主机或其他容器 +- **最小权限原则**：即使容器内获得 root 权限，其操作仍受 SE Linux 策略限制 +- **与容器运行时集成**：containerd、docker 等容器运行时通过 SE Linux 标签隔离不同容器的工作负载 + +## 常见 SE Linux 标签 + +| 标签 | 用途 | +|------|------| +| `unconfined_t` | 不受限制的进程 | +| `container_file_t` | 容器管理的文件（如 volume 挂载点） | +| `svirt_sandbox_file_t` | SELinux 虚拟沙箱文件标签 | +| `admin_t` | 系统管理员类型 | + +## 与其他安全机制的协同 + +- **与 AppArmor**：AppArmor 是 SE Linux 的替代方案，Ubuntu 默认使用 AppArmor +- **与 seccomp**：seccomp 限制进程可调用的系统调用，SE Linux 控制对系统对象的访问 +- **与 capabilities**：Linux capabilities 将 root 特权拆分为多个独立能力，SE Linux 在此基础上进一步限制能力的使用场景 + +## 故障排查 + +SE Linux enforcing 模式下，常见故障表现为"Permission denied"即使文件权限看起来正确： + +```bash +# 查看文件的安全上下文 +ls -Z /path/to/file + +# 查看进程的 SE Linux 上下文 +ps -Z + +# 临时切换为 Permissive 模式（调试用） +setenforce 0 + +# 查看 SE Linux 拒绝日志 +ausearch -m avc -ts recent +``` diff --git a/wiki/concepts/dm-verity.md b/wiki/concepts/dm-verity.md new file mode 100644 index 00000000..0869e7dc --- /dev/null +++ b/wiki/concepts/dm-verity.md @@ -0,0 +1,67 @@ +--- +title: "dm-verity" +type: concept +tags: + - Security + - Linux Kernel + - Integrity +sources: + - public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w +last_updated: 2026-04-24 +--- + +# dm-verity (Device Mapper Verity) + +dm-verity 是 Linux 内核的块设备完整性验证机制，通过在块设备层面计算并验证加密哈希树（cryptographic hash tree），确保根文件系统的任何未授权篡改都能被立即检测。 + +## 工作原理 + +``` +块设备（底层） + ↓ +[哈希树计算层] + ↓ +根哈希（Root Hash，存储在可信位置） + ↓ +与预期值对比 → 一致 = 验证通过 | 不一致 = 检测到篡改 +``` + +1. **哈希树构建**：文件系统的每个块（通常 4KB）计算 SHA-256 或其他哈希值，形成树状结构 +2. **根哈希存储**：最顶层哈希（Root Hash）存储在可信位置（如 TPM、引导加载程序验证后的内存区域） +3. **块设备访问拦截**：每次读取块设备时，dm-verity 内核模块实时计算路径哈希并与预期值比对 +4. **透明验证**：验证过程对上层应用完全透明，性能开销通常 < 5% + +## 在 Bottlerocket 中的应用 + +Bottlerocket OS 在构建时为根分区生成 dm-verity 哈希树： +- 根文件系统镜像在构建时生成根哈希 +- 引导加载程序在启动时验证根哈希 +- dm-verity 模块在运行时验证每个块设备读取操作 +- 任何对根文件系统块的篡改都会导致 I/O 错误或验证失败 + +## 与其他技术的对比 + +| 技术 | 作用 | 层级 | +|------|------|------| +| dm-verity | 块设备完整性验证（防篡改） | 块设备层 | +| dm-crypt | 块设备加密（防窃取） | 块设备层 | +| IMA/EVM | 文件级完整性度量 | 文件系统层 | +| Secure Boot | 引导加载程序验证 | 固件层 | + +## 安全价值 + +- **运行时防篡改检测**：即使攻击者获得 root 权限，也无法在不触发验证失败的情况下修改系统文件 +- **完整性保证**：确保启动后的系统与构建时的镜像完全一致 +- **信任链建立**：与 Secure Boot 结合，构建从固件到应用层的完整信任链 + +## 局限性 + +- **不防窃取**：dm-verity 不加密数据（配合 dm-crypt 使用可同时实现完整性和保密性） +- **只读保护**：无法防止拒绝服务攻击（通过损坏块设备导致验证失败） +- **验证失败处理**：检测到篡改后的行为取决于配置，可能是返回 EIO 错误或让系统崩溃 + +## 相关技术 + +- [[Immutable-Root-Filesystem]]：只读根文件系统的整体策略 +- [[Secure-Boot]]：引导阶段的固件验证 +- [[TPM]]（Trusted Platform Module）：用于安全存储根哈希的可信硬件 diff --git a/wiki/entities/AWS-OpenSearch.md b/wiki/entities/AWS-OpenSearch.md new file mode 100644 index 00000000..24f24d46 --- /dev/null +++ b/wiki/entities/AWS-OpenSearch.md @@ -0,0 +1,55 @@ +--- +title: "AWS OpenSearch" +type: entity +entity_type: Product +tags: [AWS, Database, Observability, Logging, OpenSource] +sources: [ctp-topic-54-esm-saas-log-analytics] +last_updated: 2026-04-25 +--- + +# AWS OpenSearch + +**AWS OpenSearch** 是 AWS 提供的托管式 OpenSearch 服务，是 Elasticsearch 的开源分支（基于 Elasticsearch 7.10.2）的 AWS 托管版本，提供全文搜索和日志分析能力。 + +## Overview + +OpenSearch 起源于 Elasticsearch 与 HashiCorp 之间的许可证变更（2021 年），AWS 创建了 OpenSearch 作为 Elasticsearch 的开源替代，并将其作为托管服务提供（Amazon OpenSearch Service）。 + +## Key Characteristics + +| Attribute | Value | +|-----------|-------| +| **Type** | 托管式分布式搜索和日志分析引擎 | +| **License** | Apache 2.0 | +| **Origin** | Elasticsearch 7.10.2 分支，AWS 主导 | +| **API Compatibility** | 与 Elasticsearch OSS 7.x API 兼容 | +| **Managed Service** | Amazon OpenSearch Service (Serverless / Standard) | + +## Cost Comparison (per Month) + +基于单农场、14天数据保留、每日处理 100GB 的估算： + +| Solution | Estimated Cost | SLA | Notes | +|----------|---------------|-----|-------| +| **AWS OpenSearch** | ~$1,500 | 99.9% | 推荐方案，含自动快照 DR | +| **Logz.io** | ~$4,000 | 99.8% | 托管 ELK 方案 | +| **Self-hosted ELK** | 很低 | 视自建方案 | 成本低但维护复杂 | +| **Microfocus OBA** | 商业版 | 商业支持 | 更成熟，支持列级访问控制 | + +## Key Claims + +- AWS OpenSearch 相比 Logz.io 成本降低约 60%（$1,500 vs $4,000/月） +- AWS OpenSearch 提供 99.9% SLA，高于 Logz.io 的 99.8% +- AWS OpenSearch 内置自动快照（Automated Snapshots），开箱即用的 DR 能力 +- OpenSearch 是 Elasticsearch 的开源分支，API 兼容，无需大规模代码改动即可迁移 + +## Related Concepts + +- [[ELK-Stack]]：OpenSearch 是 ELK 栈中 Elasticsearch 的开源替代 +- [[Elasticsearch]]：OpenSearch 的上游来源 +- [[Kibana]]：OpenSearch 的官方可视化前端（OpenSearch Dashboards） +- [[AWS-Landing-Zone]]：OpenSearch 常作为 Landing Zone 日志账户的核心组件 + +## Sources + +- [[ctp-topic-54-esm-saas-log-analytics]] diff --git a/wiki/entities/Bottlerocket.md b/wiki/entities/Bottlerocket.md new file mode 100644 index 00000000..84d1d0b4 --- /dev/null +++ b/wiki/entities/Bottlerocket.md @@ -0,0 +1,77 @@ +--- +title: "Bottlerocket" +type: entity +tags: + - AWS + - Container OS + - Linux + - EKS +sources: + - public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w + - public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks +last_updated: 2026-04-24 +--- + +# Bottlerocket + +AWS 主导维护的容器专用开源 Linux 操作系统，Bottlerocket OS 的命名灵感来自装满蝌蚪的瓶子（tadpole-containing bottle），旨在为容器工作负载提供最小化、安全加固的运行时环境。 + +## 核心设计理念 + +### 最小化（Minimalism） +- 去除所有非必要组件：无包管理器、无默认 Shell 解释器、无默认 SSH 访问 +- 仅打包必要内核组件到 OS 镜像，攻击面降至最低 +- Bottlerocket 可运行于笔记本电脑、工作站和数据中心环境 + +### Variant 机制 +Variant 是 Bottlerocket 的核心定制机制——在构建时组合以下维度： +- **平台**（platform）：AWS（用于 EC2）、Bare Metal 等 +- **处理器架构**：x86_64、ARM64 (Graviton) +- **工作负载组件**：Kubernetes 节点、NVIDIA GPU 支持、自定义包 + +Variant 允许按需定制（如 Bottlerocket with Kubernetes + NVIDIA GPU），避免通用 OS 的臃肿。 + +### 安全更新（Safe Updates） +- **分区镜像更新（Partition Updates）**：A/B 双分区机制，在线下载新版本镜像到非活动分区，重启后切换，确保更新原子性 +- **Data Volume**：独立数据卷缓存容器镜像，支持快照预填充 +- **in-place 更新**：无需替换节点即可完成 OS 升级 + +### 安全加固（Security Hardening） +- **dm-verity**：对根文件系统进行加密哈希验证，检测任何未授权篡改 +- **只读根文件系统**：默认只读，运行时无法修改根目录内容 +- **SE Linux enforcing**：默认启用 enforcing 模式，基于标签的强制访问控制（MAC） +- **Secure Boot**：启动时验证引导加载程序和内核签名 +- **CIS Benchmark**：Bottlerocket 提供专用 CIS benchmark 安全加固指南 + +## 与 EKS 的集成 + +Bottlerocket 支持与 Amazon EKS 的三种集成方式： + +| 集成方式 | 说明 | +|---------|------| +| Bottlerocket for EKS AMI | 自管理节点组（Self-Managed Node Groups），通过 eksctl 或 launch template 指定 | +| 托管节点组（Managed Node Groups） | EKS 自动管理的节点组，可指定 Bottlerocket AMI | +| Carpenter 节点池 | EKS Auto Mode 的节点池，Carpenter Controller 自动管理，Bottlerocket 为默认 OS | + +## 配置方式 + +- **API 接口**：通过 Bottlerocket API 远程配置节点 +- **TOML 用户数据**：在实例启动时通过 userdata 传递 TOML 格式配置 +- **EKS 工具集成**：eksctl、Carpenter 等工具原生支持 Bottlerocket + +## 最佳实践 + +- **锁定 AMI 版本**：生产环境应将 Bottlerocket AMI 锁定到特定版本，避免自动升级导致意外中断 +- **通过 Bottlerocket API 配置**：而非手动 SSH 登录修改配置（默认禁用了交互式 Shell） +- **监控更新状态**：通过 API 检查当前活动的分区版本和待切换版本 + +## 相关资源 + +- GitHub：https://github.com/bottlerocket-os/bottlerocket +- 文档：https://bottlerocket.dev/ +- AWS Bottlerocket AMI：AWS Marketplace 和 SSM 参数提供 + +## Aliases +- Bottlerocket OS +- 火箭瓶（中文社区昵称） +- Bottlerocket for EKS diff --git a/wiki/entities/Jay-Comer.md b/wiki/entities/Jay-Comer.md new file mode 100644 index 00000000..3e299b80 --- /dev/null +++ b/wiki/entities/Jay-Comer.md @@ -0,0 +1,35 @@ +--- +title: "Jay Comer" +type: entity +entity_type: Person +tags: [AWS, Solutions Architect, Observability, OpenTelemetry] +sources: [public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113] +last_updated: 2026-04-27 +--- + +# Jay Comer + +**Jay Comer** 是 AWS 的解决方案架构师（Solutions Architect），在 2024 年 4 月的 Public Cloud Learning Sessions 中主讲 OpenTelemetry 可观测性专题。 + +## Profile + +| Attribute | Value | +|-----------|-------| +| **Role** | Solutions Architect | +| **Company** | AWS (Amazon Web Services) | +| **Expertise** | Observability, OpenTelemetry, AWS Monitoring Services | +| **Presentation Date** | 2024-04-02 | + +## Key Contributions + +在 2024 年 4 月的 Learning Session 中，Jay Comer 全面介绍了 AWS 可观测性生态中的 OpenTelemetry 解决方案，包括： + +- 可观测性定义（通过外部输出推断内部状态） +- 三信号模型（Metrics/Logs/Traces） +- OpenTelemetry 核心架构（OTLP + Language SDKs + Collector） +- AWS Distribution for OpenTelemetry 功能特性 +- EKS 环境下的完整可观测性管道演示 + +## Sources + +- [[public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113]] diff --git a/wiki/entities/Suravpul.md b/wiki/entities/Suravpul.md new file mode 100644 index 00000000..515c79ae --- /dev/null +++ b/wiki/entities/Suravpul.md @@ -0,0 +1,24 @@ +--- +title: "Suravpul" +type: entity +tags: [AWS, Solutions-Architect, EKS] +last_updated: 2026-04-25 +--- + +# Suravpul + +AWS 高级解决方案架构师（Senior Solutions Architect），专注 Amazon EKS 的可靠性、可观测性和扩缩容实践。 + +## Role +- AWS Senior Solutions Architect +- 主讲 CTP 云转型系列中多个 EKS 深度专题 + +## Sources +- [[ctp-topic-59-achieving-reliability-with-amazon-eks]] — EKS 可靠性最佳实践 +- [[ctp-topic-64-scaling-out-with-amazon-eks]] — EKS 工作负载扩缩容 +- [[ctp-topic-67-cloud-native-observability-using-opentelemetry]] — EKS 云原生可观测性 + +## Connections +- [[Amazon EKS]] — 专注领域 +- [[AWS]] — 雇主 +- [[Surav Paul]] — 同一人：ctp-topic-59 标注为 "Surav Paul"，本视频标注为 "Suravpul"，推断为同一 AWS 高级解决方案架构师的不同记法 diff --git a/wiki/index.md b/wiki/index.md index 800fcdbf..2e8f8ff5 100644 --- a/wiki/index.md +++ b/wiki/index.md @@ -4,6 +4,14 @@ - [Overview](overview.md) — living synthesis ## Sources +- [2026-04-24] [Public Cloud Learning Sessions - OpenText GIS Security Policies - 20241015](sources/public-cloud-learning-sessions-opentext-gis-security-policies-20241015-160257-me.md) +- [2026-04-24] [CTP Topic 64 Scaling out with Amazon EKS](sources/ctp-topic-64-scaling-out-with-amazon-eks.md) +- [2026-04-24] [CTP Topic 67 Cloud native observability using OpenTelemetry](sources/ctp-topic-67-cloud-native-observability-using-opentelemetry.md) +- [2026-04-24] [Public Cloud Learning Sessions - EKS Optimization Part 2 of 3 - Running Containers with Bottlerocket OS](sources/public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w.md) +- [2026-04-24] [CTP Topic 42 Grafana Observability Dashboard](sources/ctp-topic-42-grafana-observability-dashboard.md) +- [2026-04-24] [Public Cloud Learning Sessions - Observability with OpenTelemetry - 20240402](sources/public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113.md) +- [2026-04-24] [CTP Topic 54 ESM SaaS Log Analytics](sources/ctp-topic-54-esm-saas-log-analytics.md) +- [2026-04-24] [CTP Topic 59 Achieving reliability with Amazon EKS](sources/ctp-topic-59-achieving-reliability-with-amazon-eks.md) - [2026-04-24] [CTP Topic 29 Cloud Monitoring – SaaS LZ accounts](sources/ctp-topic-29-cloud-monitoring-saas-lz-accounts.md) - [2026-04-24] [CTP Topic 39 Implementing EKS in the AWS Lab Landing Zone](sources/ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone.md) - [2026-04-24] [Public Cloud Learning Sessions - EKS Optimization Part 1 of 3 - Compute Optimization with Karpenter](sources/public-cloud-learning-sessions-eks-optimization-part-1-of-3-compute-optimization.md) @@ -406,14 +414,6 @@ - [2026-04-19] [ctp-topic-55-aws-firewall-manager](sources/ctp-topic-55-aws-firewall-manager.md) — (expected: wiki/sources/ctp-topic-55-aws-firewall-manager.md — source missing) - [2026-04-19] [ctp-topic-37-secrets-certificates-management](sources/ctp-topic-37-secrets-certificates-management.md) — (expected: wiki/sources/ctp-topic-37-secrets-certificates-management.md — source missing) - [2026-04-19] [ctp-topic-62-aws-secrets-manager](sources/ctp-topic-62-aws-secrets-manager.md) — (expected: wiki/sources/ctp-topic-62-aws-secrets-manager.md — source missing) -- [2026-04-19] [public-cloud-learning-sessions-opentext-gis-security-policies-20241015-160257-me](sources/public-cloud-learning-sessions-opentext-gis-security-policies-20241015-160257-me.md) — (expected: wiki/sources/public-cloud-learning-sessions-opentext-gis-security-policies-20241015-160257-me.md — source missing) -- [2026-04-19] [ctp-topic-64-scaling-out-with-amazon-eks](sources/ctp-topic-64-scaling-out-with-amazon-eks.md) — (expected: wiki/sources/ctp-topic-64-scaling-out-with-amazon-eks.md — source missing) -- [2026-04-19] [ctp-topic-67-cloud-native-observability-using-opentelemetry](sources/ctp-topic-67-cloud-native-observability-using-opentelemetry.md) — (expected: wiki/sources/ctp-topic-67-cloud-native-observability-using-opentelemetry.md — source missing) -- [2026-04-19] [public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w](sources/public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w.md) — (expected: wiki/sources/public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w.md — source missing) -- [2026-04-19] [ctp-topic-42-grafana-observability-dashboard](sources/ctp-topic-42-grafana-observability-dashboard.md) — (expected: wiki/sources/ctp-topic-42-grafana-observability-dashboard.md — source missing) -- [2026-04-19] [public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113](sources/public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113.md) — (expected: wiki/sources/public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113.md — source missing) -- [2026-04-19] [ctp-topic-54-esm-saas-log-analytics](sources/ctp-topic-54-esm-saas-log-analytics.md) — (expected: wiki/sources/ctp-topic-54-esm-saas-log-analytics.md — source missing) -- [2026-04-19] [ctp-topic-59-achieving-reliability-with-amazon-eks](sources/ctp-topic-59-achieving-reliability-with-amazon-eks.md) — (expected: wiki/sources/ctp-topic-59-achieving-reliability-with-amazon-eks.md — source missing) - [Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog](sources/Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog.md) — (expected: wiki/sources/Your-AI-Isn-t-Stupid---It-Just-Needs-a-Better-Harness--Lychee-Technology-Engineering-Blog.md — source missing) - [Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend](sources/Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend.md) — (expected: wiki/sources/Expose-hermes-agent-as-an-OpenAI-compatible-API-for-any-frontend.md — source missing) - [zk-steward](sources/zk-steward.md) — (expected: wiki/sources/zk-steward.md — source missing) @@ -560,6 +560,7 @@ - [Asana](entities/Asana.md) - [AWS](entities/AWS.md) - [AWS-CloudFormation-StackSets](entities/AWS-CloudFormation-StackSets.md) +- [AWS-OpenSearch](entities/AWS-OpenSearch.md) - [AWS-Organizations](entities/AWS-Organizations.md) - [Axton](entities/Axton.md) - [Azure](entities/Azure.md) @@ -567,6 +568,7 @@ - [bitwarden](entities/bitwarden.md) - [blackbox-exporter](entities/blackbox-exporter.md) - [BMC](entities/BMC.md) +- [Bottlerocket](entities/Bottlerocket.md) - [bottom](entities/bottom.md) - [Brendan-Starnig](entities/Brendan-Starnig.md) - [btop++](entities/btop++.md) @@ -638,6 +640,7 @@ - [Intsas.local](entities/Intsas.local.md) - [ISO-27001](entities/ISO-27001.md) - [it-tools](entities/it-tools.md) +- [Jay-Comer](entities/Jay-Comer.md) - [Jellyfin](entities/Jellyfin.md) - [Jira](entities/Jira.md) - [K3s](entities/K3s.md) @@ -717,6 +720,7 @@ - [SRE-Team](entities/SRE-Team.md) - [Stable-Diffusion](entities/Stable-Diffusion.md) - [stacer](entities/stacer.md) +- [Suravpul](entities/Suravpul.md) - [SurfSense](entities/SurfSense.md) - [Swinford.net](entities/Swinford.net.md) - [Synology-NAS-DS718](entities/Synology-NAS-DS718.md) @@ -793,6 +797,7 @@ - [Availability](concepts/Availability.md) - [AWS-Tagging-Standards](concepts/AWS-Tagging-Standards.md) - [AWS-Tags](concepts/AWS-Tags.md) +- [BEATS](concepts/BEATS.md) - [BindMount](concepts/BindMount.md) - [BI平台](concepts/BI平台.md) - [Blue-Green-Deployment](concepts/Blue-Green-Deployment.md) @@ -820,6 +825,7 @@ - [Check-in-Fatigue](concepts/Check-in-Fatigue.md) - [CI-CD-Pipeline](concepts/CI-CD-Pipeline.md) - [CICDPipeline](concepts/CICDPipeline.md) +- [CIS-Benchmark](concepts/CIS-Benchmark.md) - [Claude-Code-Templates](concepts/Claude-Code-Templates.md) - [Claude-Skills](concepts/Claude-Skills.md) - [Claudian](concepts/Claudian.md) @@ -877,6 +883,7 @@ - [DevOps-Maturity](concepts/DevOps-Maturity.md) - [DevOpsCulture](concepts/DevOpsCulture.md) - [DevSecOps](concepts/DevSecOps.md) +- [dm-verity](concepts/dm-verity.md) - [DNS托管](concepts/DNS托管.md) - [Docker-Compose](concepts/Docker-Compose.md) - [Docker-Containerization](concepts/Docker-Containerization.md) @@ -896,6 +903,7 @@ - [efibootmgr](concepts/efibootmgr.md) - [EFS-vs-EBS](concepts/EFS-vs-EBS.md) - [EKS-Auto-Mode](concepts/EKS-Auto-Mode.md) +- [ELK-Stack](concepts/ELK-Stack.md) - [Email-Triage](concepts/Email-Triage.md) - [Emergency-Change](concepts/Emergency-Change.md) - [Enterprise-Architecture](concepts/Enterprise-Architecture.md) @@ -950,6 +958,7 @@ - [IDENTITY.md](concepts/IDENTITY.md.md) - [Ikigai框架](concepts/Ikigai框架.md) - [Immutable-Infrastructure](concepts/Immutable-Infrastructure.md) +- [Immutable-Root-Filesystem](concepts/Immutable-Root-Filesystem.md) - [Incident-Management](concepts/Incident-Management.md) - [Indexing](concepts/Indexing.md) - [Infrastructure-as-Code](concepts/Infrastructure-as-Code.md) @@ -1013,10 +1022,12 @@ - [Obsidian-Bases](concepts/Obsidian-Bases.md) - [Obsidian-CLI](concepts/Obsidian-CLI.md) - [Obsidian-Tasks](concepts/Obsidian-Tasks.md) +- [OpenTelemetry](concepts/OpenTelemetry.md) - [OWASP-Top-Ten](concepts/OWASP-Top-Ten.md) - [Pain-Point-Mining](concepts/Pain-Point-Mining.md) - [Paper-Abstract-Batch-Fetching](concepts/Paper-Abstract-Batch-Fetching.md) - [Parallel-Agent-Execution](concepts/Parallel-Agent-Execution.md) +- [Partition-Updates](concepts/Partition-Updates.md) - [Passive-Learning](concepts/Passive-Learning.md) - [passkey](concepts/passkey.md) - [Pay-as-you-go](concepts/Pay-as-you-go.md) @@ -1081,6 +1092,7 @@ - [Scholar-Skill](concepts/Scholar-Skill.md) - [Scrum](concepts/Scrum.md) - [SDDC](concepts/SDDC.md) +- [SE-Linux-Enforcing](concepts/SE-Linux-Enforcing.md) - [Second-Renaissance](concepts/Second-Renaissance.md) - [Security-and-Compliance](concepts/Security-and-Compliance.md) - [Self-Education](concepts/Self-Education.md) diff --git a/wiki/log.md b/wiki/log.md index 3e6477dd..02bb13d7 100644 --- a/wiki/log.md +++ b/wiki/log.md @@ -1,3 +1,75 @@ +## [2026-04-29] ingest | Public Cloud Learning Sessions - OpenText GIS Security Policies - 20241015 +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/public-cloud-learning-sessions-opentext-gis-security-policies-20241015-160257-me.md +- Status: ✅ 成功摄入 +- Summary: OpenText 全球信息安全团队（GIS）安全策略全景——Mike & Ed 主讲。GIS 分层组织架构（安全运营/合规/治理风险验证/隐私）；OpenText 分层方法定义安全策略；ISO 27001 姿态框架（2022年更新）；Global Information Security Policy（GISP）是最高纲领性政策，季度审查；每月处理 2250 亿条日志，分诊约 350 个案例；FedRAMP 等多项认证支撑多垂直市场销售。 +- Concepts identified: [[ISO-27001]], [[FedRAMP]], [[Global-Information-Security-Policy]], [[Security-Awareness-Training]], [[Third-Party-Penetration-Testing]], [[Threat-Intelligence]], [[BrightCloud]]（均以 wikilink 形式记录于 Source page，各仅出现 1 次，暂不创建独立页面） +- Entities identified: [[Mike]]（GIS Team 主讲人，仅出现 1 次，以 wikilink 形式记录于 Source page）, [[Ed]]（GIS Team 主讲人，仅出现 1 次，以 wikilink 形式记录于 Source page） +- Source page: wiki/sources/public-cloud-learning-sessions-opentext-gis-security-policies-20241015-160257-me.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/public-cloud-learning-sessions-opentext-gis-security-policies-20241015-160257-me.md） + - index.md 更新：Sources 节新增条目（日期 2026-04-14，置顶于所有条目最前） + - overview.md 更新：新增 GIS Security Policies 摘要条目（置于 Thor Platform 之后，CTP Topic 28 之前）；Key Concepts 新增 ISO-27001/FedRAMP（已有条目）、BrightCloud 等 + - Connections 已建立：与 [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]] 建立 related_to 关系 + - 冲突检测：与 [[ctp-topic-10]] 的互补而非冲突关系已记录于 Source Page Contradictions 节——GISP 定义全局政策纲领，Landing Zone 层面通过标签和 SCP 实现技术落地 + +## [2026-04-25] ingest | CTP Topic 64 Scaling out with Amazon EKS +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-64-scaling-out-with-amazon-eks.md +- Status: ✅ 成功摄入 +- Summary: Amazon EKS 工作负载扩缩容完整方法论——Pod 层：HPA（标准指标）+ KEDA（事件驱动）；Node 层：Cluster Autoscaler（ASG 联动）+ Karpenter（直接 EC2 API）；IP 耗尽解决方案：IPv6 双栈 VPC；集群稳定性：API Server PPF + CoreDNS 扩缩容。Suravpul 主讲。 +- Concepts identified: [[Horizontal Pod Autoscaler (HPA)]]（已在 ctp-topic-59 提及）, [[KEDA]]（新）, [[Cluster Autoscaler]]（已在 ctp-topic-70 提及）, [[Karpenter]]（已在 Part 1 提及） +- Entities identified: [[Suravpul]]（AWS 高级解决方案架构师，ctp-topic-59/64/67 三专题讲师） +- Source page: wiki/sources/ctp-topic-64-scaling-out-with-amazon-eks.md +- Notes: 与 ctp-topic-59（EKS 可靠性，HPA/VPA）和 ctp-topic-70（IaC 部署，Cluster Autoscaler）形成互补知识链路。与 Part 3 EKS Auto Mode 共享 Karpenter 知识节点。 + +## [2026-04-25] ingest | CTP Topic 67 Cloud native observability using OpenTelemetry +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-67-cloud-native-observability-using-opentelemetry.md +- Status: ✅ 成功摄入 +- Summary: AWS 解决方案架构师 Surav 分享的 EKS/ECS 云原生可观测性深度实践。涵盖可观测性三信号模型（Traces/Metrics/Logs）、OpenTelemetry Collector 架构（Receivers → Processors → Exporters）、ADOT 的多种 EKS/ECS 部署模式。核心观点：构建可观测的应用是开发者的责任；Trace 捕获调用栈各层处理耗时；Correlation ID 实现跨信号关联。 +- Concepts identified: [[OpenTelemetry]], [[Three Signals]], [[SIGV4 Auth Extension]], [[Correlation ID]] +- Source page: wiki/sources/ctp-topic-67-cloud-native-observability-using-opentelemetry.md +- Notes: 与 ctp-topic-60（Hyperscale Observability with Grafana）同属可观测性专题，与 public-cloud-learning-sessions-observability-with-opentelemetry-20240402 同属 OpenTelemetry 主题 + +## [2026-04-24] ingest | Public Cloud Learning Sessions - EKS Optimization Part 2 of 3 - Running Containers with Bottlerocket OS +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w.md +- Status: ✅ 成功摄入 +- Summary: Bottlerocket OS（火箭瓶）深度解析——AWS 专为容器工作负载优化的最小化开源 Linux 发行版。核心设计理念：最小化（去除包管理器/Shell/SSH，仅打包必要内核组件）、安全更新（分区镜像 A/B 切换确保原子性）、安全加固（dm-verity 根文件系统加密验证 + SE Linux enforcing 模式 + 根文件系统默认只读）。Variant 机制通过平台+架构+工作负载组件组合在构建时定制功能，支持 Bottlerocket for EKS AMI（自管理节点组）、托管节点组（Managed Node Groups）和 Carpenter 节点池三种集成方式。 +- Concepts identified: [[Immutable-Root-Filesystem]], [[dm-verity]], [[SE-Linux-Enforcing]], [[Partition-Updates]], [[CIS-Benchmark]] +- Entities identified: [[Bottlerocket]], [[Amazon EKS]], [[AWS]] +- Source page: wiki/sources/public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w.md +- Notes: EKS 优化三专题 Part 2（Part 1 = Karpenter 计算优化，Part 3 = EKS Auto Mode）。Bottlerocket Entity 和 5 个 Concept 均为新增。Part 3 的 EKS Auto Mode 默认使用 Bottlerocket 作为节点操作系统，形成知识链路补充。 + +## [2026-04-24] ingest | CTP Topic 42 Grafana Observability Dashboard +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-42-grafana-observability-dashboard.md +- Status: ✅ 成功摄入 +- Summary: 企业级 Grafana 可观测性平台在 AWS 多账户环境下的架构设计与 Terraform IaC 自动化实践。涵盖 Grafana 核心定位（不存储数据，仅从数据源可视化）、基础设施架构（监控账户部署 Grafana，通过 IAM 角色跨账户访问产品团队 AWS 账户）、用户和团队访问控制、示例仪表盘（CPU/I/O/Network/EBS/Estimated Charges）、告警系统（Microsoft Teams 通知）、Terraform 模块化供给（数据源模块 + 组织模块 + LZSAP 自动化接入）、Prometheus 网络监控（Checkpoint/防火墙 SNMP 指标）。 +- Concepts identified: [[Observability（可观测性）]], [[Prometheus]], [[SNMP（Simple Network Management Protocol）]], [[IAM Role（跨账户角色）]] +- Entities identified: [[AWS CloudWatch]], [[AWS Landing Zone]], [[Micro Focus Operations Bridge Manager]] +- Source page: wiki/sources/ctp-topic-42-grafana-observability-dashboard.md +- Notes: 该视频与 [[ctp-topic-60]] 均介绍 Grafana，视角互补（Grafana 本身 vs Hyperscale 场景），与 [[ctp-topic-54]] 和 [[ctp-topic-67]] 同属可观测性专题，共同构成监控知识体系。长期目标是构建应用级仪表盘替代 Micro Focus OBM。Entity 和 Concept 已有 Grafana/Prometheus/Terraform/Checkpoint 等，无需新建。 + +## [2026-04-25] ingest | CTP Topic 54 ESM SaaS Log Analytics +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-54-esm-saas-log-analytics.md +- Status: ✅ 成功摄入 +- Summary: ITOM ESM SAS 架构师 Jackie 主讲的企业级日志分析解决方案——ELK/OpenSearch 技术栈架构（BEATS/Filebeat → Logstash → Elasticsearch/OpenSearch → Kibana）、双 VPC 隔离架构、Redis 缓冲层、GDPR 合规区域分割。安全：NVMe 静态加密、TLS 1.2、VPC 私有流量、RBAC。方案对比：AWS OpenSearch（~$1,500/月，SLA 99.9%，推荐）vs Logz.io（~$4,000/月，SLA 99.8%）vs 自托管 ELK vs Microfocus OBA。 +- Concepts identified: [[ELK Stack]], [[OpenSearch]], [[Logstash]], [[Kibana]], [[BEATS]], [[Filebeat]], [[Centralized-Logging]], [[Redis缓存]], [[RBAC]], [[TLS]], [[GDPR]] +- Entities identified: [[AWS OpenSearch]], [[Jackie]] +- Source page: wiki/sources/ctp-topic-54-esm-saas-log-analytics.md +- Notes: 新建 Concept 页面 ELK-Stack.md、BEATS.md；新建 Entity 页面 AWS-OpenSearch.md；已更新 overview.md（Sources 条目 + Key Concepts）；Key Concepts 列表中已有 Centralized-Logging、Redis缓存（Redis缓存.md）、TLS，未发现冲突内容 + +## [2026-04-26] ingest | CTP Topic 59 Achieving reliability with Amazon EKS +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-59-achieving-reliability-with-amazon-eks.md +- Status: ✅ 成功摄入 +- Summary: Amazon EKS 可靠性最佳实践——Surav Paul（AWS 高级解决方案架构师）主讲。涵盖 ECS vs EKS 选型、可靠性五维度（故障检测/优雅降级/确定性故障/自愈/按需扩缩）、Shared Responsibility Model（Fargate 免除节点管理）、应用层可靠性（AZ 分散/拓扑约束/HPA/VPA/部署策略/健康探针/PodDisruptionBudget）、控制平面可靠性（指标监控/认证加固/Webhook 管理/集群升级）和数据平面可靠性（节点问题检测/资源预留/QoS/配额/Pod 优先级）。 +- Concepts identified: [[Reliability（系统可靠性）]], [[Application Reliability（应用可靠性）]], [[Control Plane Reliability（控制平面可靠性）]], [[Data Plane Reliability（数据平面可靠性）]], [[Shared Responsibility Model（EKS）]], [[Pod Anti-Affinity]], [[Topology Spread Constraints]], [[Horizontal Pod Autoscaler (HPA)]], [[Vertical Pod Autoscaler (VPA)]], [[Liveness/Readiness/Startup Probes]], [[PodDisruptionBudget]], [[Rolling/Blue-Green/Canary Deployment]]（均以 wikilink 形式记录于 Source page；均仅出现 1 次，暂无独立页面） +- Entities identified: [[Surav Paul]], [[Amazon EKS]], [[Amazon ECS]], [[AWS Fargate]]（均以 wikilink 形式记录于 Source page；仅 [[Amazon EKS]] 在多个页面中反复出现，符合独立页面创建条件，其余仅出现 1 次，暂无独立页面） +- Source page: wiki/sources/ctp-topic-59-achieving-reliability-with-amazon-eks.md +- Notes: + - 新增 1 个 Source Page（wiki/sources/ctp-topic-59-achieving-reliability-with-amazon-eks.md） + - index.md 更新：新增 CTP Topic 59 条目于 Sources 节顶部 + - overview.md 更新：新增 CTP Topic 59 条目于 Cloud Transformation & DevOps → EKS 知识链路 + - Contradictions 记录：与 ctp-topic-39（EKS Lab LZ 网络部署）存在视角差异——Topic 39 面向受限网络环境的自定义网络方案，Topic 59 提供通用 EKS 可靠性最佳实践，互为补充而非冲突 + - 无需新建 Concept/Entity 独立页面（所有概念和实体仅在本页面出现 1 次；Amazon EKS 虽在多个其他页面提及，但本页面无新增独立维度，不单独创建） + ## [2026-04-26] ingest | CTP Topic 29 Cloud Monitoring – SaaS LZ accounts - Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-29-cloud-monitoring-saas-lz-accounts.md - Status: ✅ 成功摄入 @@ -2177,3 +2249,18 @@ - index.md 更新：在 Sources 节顶部添加新条目；在 Concepts 节添加 3 个新条目；移除 "source missing" 标记 - overview.md 更新：添加新条目，位于 EKS Auto Mode 条目之后 - 冲突检测：与 ctp-topic-59-achieving-reliability-with-amazon-eks 可能存在内容重叠（侧重点不同：Topic 70 侧重部署方法，Topic 59 侧重可靠性实践） + +## [2026-04-27] ingest | Public Cloud Learning Sessions - Observability with OpenTelemetry +- Source file: Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113-.md +- Status: ✅ 成功摄入 +- Summary: Jay Comer（AWS 解决方案架构师）主讲 OpenTelemetry 可观测性全景——三信号模型（Metrics/Logs/Traces）、OTLP 协议 + 11 种语言 SDK + Collector 架构、AWS Distribution for OpenTelemetry（统一代理 + EKS Operator 自动注入）、Fluent Bit → OTel Collector（端口 55681）→ Amazon OpenSearch 端到端管道演示。 +- Concepts created: [[OpenTelemetry]], [[Observability（可观测性）]], [[Three Signals]], [[OTLP（OpenTelemetry Protocol）]], [[Fluent Bit]] +- Entities identified: [[Jay Comer]] +- Source page: wiki/sources/public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113.md +- Notes: + - 新增 1 个 Source Page + - index.md 更新：新增条目（日期 2024-04-02） + - overview.md 更新：新增条目于 Cloud Transformation & DevOps → EKS 知识链路；Key Concepts 新增 5 个条目 + - 新增 Entity 页面：Jay-Comer.md + - 新增 Concept 页面：OpenTelemetry.md + - 冲突检测：与 ctp-topic-54-esm-saas-log-analytics（ELK 日志）、ctp-topic-67（CTP Topic 67 OpenTelemetry）互补，无冲突 diff --git a/wiki/overview.md b/wiki/overview.md index d61b7aad..c21fe658 100644 --- a/wiki/overview.md +++ b/wiki/overview.md @@ -43,12 +43,20 @@ Cloud Transformation Programme (CTP) materials cover AWS landing zones, EKS, Ter **[[public-cloud-learning-sessions-eks-optimization-part-1-of-3-compute-optimization]]**（Public Cloud Learning Sessions，EKS 计算优化专题 Part 1）：Karpenter 深度解析与 Cluster Autoscaler 对比——Karpenter 直接与 EC2 Fleet API 通信降低延迟，原生集成 Kubernetes 调度约束（node selectors/affinity/taints/tolerations/topology spread），内置 Spot 中断处理（EventBridge + SQS）和 AMI 滚动升级，Eliminate 节点组管理痛点；Consolidation 策略自动整合低利用率节点，支持中断预算控制和峰值时段豁免。Part 3 将介绍 EKS Auto Mode 进一步简化数据平面管理（内置 Karpenter Controller）。属 [[Karpenter]] 在 AWS EKS 的核心实践，与 [[ctp-topic-70-eks-deployment-using-iac]]（EKS IaC 部署）共同构成 EKS 完整知识链路。 +**[[public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w]]**（Public Cloud Learning Sessions，EKS 计算优化专题 Part 2）：Bottlerocket OS（火箭瓶）深度解析——AWS 专为容器工作负载优化的最小化开源 Linux 发行版，核心设计理念：最小化（去除包管理器/Shell/SSH，仅打包必要内核组件）、安全更新（分区镜像 A/B 切换确保原子性）、安全加固（dm-verity 根文件系统加密验证 + SE Linux enforcing 模式 + 根文件系统默认只读）。Variant 机制通过平台+架构+工作负载组件组合在构建时定制功能，支持 Bottlerocket for EKS AMI（自管理节点组）、托管节点组（Managed Node Groups）和 Carpenter 节点池三种集成方式。属 [[Bottlerocket]] 在 [[Amazon EKS]] 场景的核心实践，与 Part 1（Karpenter 计算优化）和 Part 3（EKS Auto Mode）共同构成 EKS 优化三专题完整链路；Part 3 的 EKS Auto Mode 默认使用 Bottlerocket 作为节点操作系统。 + +**[[ctp-topic-67-cloud-native-observability-using-opentelemetry]]**（CTP Topic 67）：AWS 解决方案架构师 Surav 分享的 EKS/ECS 云原生可观测性深度实践——核心主题：可观测性三信号模型（Traces/Metrics/Logs）、OpenTelemetry Collector 架构（Receivers → Processors → Exporters）、ADOT（AWS Distro for OpenTelemetry）的多种 EKS/ECS 部署模式（Sidecar/独立任务/DaemonSet/HA Replicas）。核心观点：**构建可观测的应用是开发者的责任**——开发者需主动在代码中植入观测能力；Trace 捕获应用调用栈各层的处理耗时，是性能瓶颈定位的核心手段；Correlation ID（如 X-Ray Trace ID）使日志事件可深度链接至 Trace 视图。ADOT 在标准 OTEL Collector 基础上封装 AWS 专用组件，包含 SIGV4 Auth Extension 实现 AWS 服务无缝集成，支持 CloudWatch/X-Ray/Prometheus/Grafana 等多种后端。与 [[public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113]]（Jay Comer 概述版）同属 OpenTelemetry 专题，属 Surav 主讲的深度实践版；与 [[ctp-topic-42-grafana-observability-dashboard]]（Grafana 仪表盘）互补，后者为 ADOT 推荐的可视化后端；与 [[ctp-topic-54-esm-saas-log-analytics]]（ELK 日志方案）共同构成企业级可观测性知识体系。 + +**[[public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113]]**（Public Cloud Learning Sessions，Jay Comer 主讲）：AWS OpenTelemetry 可观测性全景介绍——涵盖可观测性定义（通过外部输出推断内部状态）、三信号模型（Metrics/Logs/Traces）、OpenTelemetry 核心架构（OTLP 协议 + 11 种语言 SDK + Collector 组件）、AWS Distribution for OpenTelemetry（统一代理 + EKS Operator 自动注入）、最新发布动态（安全合规/规模化/集中管理面板/日志支持）。Demo 展示 EKS 环境完整链路：Fluent Bit 采集容器日志 → OpenTelemetry Collector（端口 55681）→ Amazon OpenSearch Service，OpenSearch Dashboard 可按 trace group 展示延迟并通过应用组成图定位性能瓶颈。属 [[OpenTelemetry]] 在 AWS EKS 场景的核心实践，与 [[ctp-topic-67-cloud-native-observability-using-opentelemetry]]（CTP Topic 67）同属 OpenTelemetry 专题，与 [[ctp-topic-54-esm-saas-log-analytics]]（ELK 日志方案）共同构成企业级可观测性知识体系。 + **[[public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks]]**（Public Cloud Learning Sessions，EKS Auto Mode 专题）：AWS EKS Auto Mode 深度解析——将数据平面管理责任从用户扩展至 AWS，覆盖计算节点（Carpenter Controller）、存储（EBS CSI Controller）、网络（AWS LB Controller）和安全（Pod Identity Associations）。Bottlerocket OS 提供最小化安全容器操作系统，自动应用安全补丁；Carpenter Controller 监听控制面版本变更，自动触发节点 AMI 滚动升级；Pod Identity Associations 替代 K8s RBAC 实现 Pod 级 IAM 权限控制，无需修改 ServiceAccount；Prefix Delegation 默认启用优化 Pod 网络 IP 分配。默认两个节点池（General Purpose 锁定 AMD64，System 带 taint），支持自定义节点池指定 Graviton。Auto Mode 兼容所有 Kubernetes-compliant 工作负载，实例附加 12% 管理溢价。属 EKS 运维简化的核心实践，与 [[ctp-topic-59-achieving-reliability-with-amazon-eks]]（EKS 可靠性）、[[ctp-topic-64-scaling-out-with-amazon-eks]]（EKS 扩缩容）共同构成 EKS 完整知识链路。 **[[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]]**（CTP Topic 39）：EKS 在受限 Lab Landing Zone 网络环境下的技术实施方案——Spencer 和 Guy 分享。核心问题：Micro Focus 网络的 AWS Lab 环境 IP 地址池不足，无法满足 Octane（IP 密集型 SaaS 应用）的 EKS Pod 需求。解决方案：创建独立私有子网（非主 VPC 子网），由 EKS 模块自定义网络标志控制 Pod IP 分配；Pod 规范设置 `hostNetwork: true` 使其同时访问内部 Micro Focus 网络和外部资源；Terraform/Terragrunt 模块封装完整 EKS 部署逻辑，支持跨账户角色映射。Atlantis 当前不支持 EKS 部署，需通过 Jenkins + Terragrunt 模块替代。属 [[Amazon EKS]] 在受限网络场景下的技术实践，与 [[ctp-topic-70-eks-deployment-using-iac]]（IaC 部署）共同构成 EKS 完整知识链路。 **[[ctp-topic-70-eks-deployment-using-iac]]**（CTP Topic 70）：EKS 集群通过 IaC 部署的完整方法论——涵盖容器与 VM 的对比（启动速度/内存效率/可移植性）、EKS 核心特性（完全托管控制平面/零停机滚动更新/IAM RBAC 最小权限）。SRE EKS 模块支持两种部署路径：Terraform（`tera-grant.scl` 定义集群参数+Secret Manager 集成）和 Service Catalog（模块化产品组合+版本选择）。自定义网络通过 EMI（ENI Multi-IP）为 Pod 分配额外 IP 地址解决 VPC CIDR 限制；Cluster Autoscaler 实现 Worker Node 自动扩缩容。监控栈：CloudWatch Agent + FluentBit（DaemonSet）+ Container Insights + AWS OpenTelemetry + Grafana。属 [[Amazon EKS]] 部署方法的完整入口，与 [[ctp-topic-59-achieving-reliability-with-amazon-eks]]（可靠性）、[[ctp-topic-64-scaling-out-with-amazon-eks]]（扩缩容）、[[public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks]]（Auto Mode）共同构成 EKS 完整知识链路。 +**[[ctp-topic-59-achieving-reliability-with-amazon-eks]]**（CTP Topic 59）：Amazon EKS 可靠性最佳实践——AWS 高级解决方案架构师 Surav Paul 主讲。涵盖 EKS 容器服务选型（ECS vs EKS）、可靠性定义（可预测行为、故障检测、优雅降级、自愈、按需扩缩）、shared responsibility model（AWS 负责控制平面，客户负责工作节点/OS/应用配置，Fargate 模式下客户无需管理节点）、应用层可靠性（避免单例 Pod、AZ 分散、拓扑分布约束、HPA/VPA 扩缩容、Rolling/Blue-Green/Canary 部署、存活/就绪/启动探针、PodDisruptionBudget）、控制平面可靠性（监控 API server 指标、安全认证加固、准入 Webhook 管理、集群升级 14 个月支持周期）和数据平面可靠性（节点问题检测、资源预留、QoS、资源配额、Pod 优先级抢占）。属 [[Amazon EKS]] 生产级可靠性保障的核心知识来源，与 [[ctp-topic-70-eks-deployment-using-iac]]（IaC 部署）和 [[ctp-topic-64-scaling-out-with-amazon-eks]]（扩缩容）共同构成 EKS 完整知识链路。 + **[[ctp-topic-4-using-agile-to-run-the-cloud-transformation-program]]**（CTP Topic 4）：云转型计划中敏捷实践的落地经验——Heather Norris 主讲。核心内容：①框架演进——从 Scrum（两周 Sprint，含 Product Backlog/Sprint Planning/Retrospectives/Reviews/Daily Scrum）因"Sprint 期间不允许变更"的问题而转向 Kanban 持续流动模式；②混合方案——以 Kanban 为主（随时可调整优先级、持续交付），同时保留 Scrum 的固定仪式（每日站会和回顾会议）；③Microsoft Planner 看板——五列布局（Backlog/To Do/In Progress/Program Key Decisions/Icebox），每张卡必须指定单一负责人、链接依赖、设置优先级和截止日期；④核心价值观——"Agile is all about getting that rapid feedback to make the product and make the development culture better"。属 [[Agile Ceremonies]] 和 [[Scrum]] vs [[Kanban]] 在企业级云迁移场景下的实战案例，与 [[ctp-topic-57-product-backlog-managing-demand]]（需求管理）和 [[ctp-topic-30-managing-change]]（变更管理）共同构成 CTP 项目管理知识体系。 **[[public-cloud-learning-sessions-applicable-business-analysis-techniques-20240109]]**（Public Cloud Learning Sessions 20240109）：业务分析（Business Analysis）基础技能与三大核心技法——T型技能模型、BOSCARD框架、干系人轮盘（Stakeholder Wheel）、结合元数据的用户故事需求收集。业务分析将业务需求与技术变更解决方案对齐，涵盖IT系统变更、流程变更、培训和角色转换。BOSCARD（Background/Objectives/Scope/Constraints/Assumptions/Risks/Roles/Deliverables）通过澄清背景、目标、范围等8个维度定义复杂新工作，"早期锁定范围无价"。干系人轮盘从客户出发顺时针识别所有项目干系人。INVEST原则（Independent/Negotiable/Valuable/Estimable/Small/Testable）用于检查需求质量。属 [[Product-Backlog]] 和 [[Demand-Management]] 的前置技法层，与 [[ctp-topic-4]]（敏捷实践）和 [[ctp-topic-57]]（需求管理）共同构成云转型计划的完整方法论（规划→需求→执行）。 @@ -61,6 +69,10 @@ Cloud Transformation Programme (CTP) materials cover AWS landing zones, EKS, Ter **[[ctp-topic-8-obm-cloud-monitoring]]**（CTP Topic 8）：使用 Micro Focus Operations Bridge Manager (OBM) 实现 AWS 公有云监控的完整解决方案——OBM AWS Account 部署 OBM 应用、Postgres RDS 和 Operation Agent 三层组件；Agent 通过 AWS Management Pack 利用 IAM Role 信任关系跨账户采集 CloudWatch 指标，无需在被监控账户安装服务器或共享 Access Key；Global OBM 作为 Manager of Managers 汇聚多区域 Regional OBM 数据，事件通过 SMACKS 触发工单；新增实例自动发现、策略自动下发，解决云环境动态性监控难题；支持任意公有云（AWS/Azure/GCP）的 CloudWatch 兼容服务。与 [[ctp-topic-29-cloud-monitoring-saas-lz-accounts]]（账户架构）互补构成完整监控体系，属 [[AWS-Landing-Zone]] 监控层的核心实践。 +**[[ctp-topic-54-esm-saas-log-analytics]]**（CTP Topic 54）：ITOM ESM SAS 架构师 Jackie 主讲的企业级日志分析解决方案（ESM SaaS）——涵盖 ELK/OpenSearch 技术栈架构（BEATS 采集 → Logstash 处理 → Elasticsearch/OpenSearch 存储 → Kibana 可视化）、双 VPC 隔离架构（应用 VPC + 日志 VPC）、Redis 缓冲层防止 Logstash 过载。安全加固涵盖静态加密（NVMe 硬件级）、传输加密（TLS 1.2）、VPC 私有流量和 RBAC 访问控制；GDPR 合规要求推动日志农场按区域分割部署（美国俄勒冈、欧洲）。方案对比：AWS OpenSearch（~$1,500/月，SLA 99.9%，推荐）、Logz.io（~$4,000/月，SLA 99.8%）、自托管 ELK（成本低维护高）、Microfocus OBA（商业成熟，列级访问控制）。起步建议先用 Logz.io 试用，再迁移 AWS OpenSearch。与 [[ctp-topic-8-obm-cloud-monitoring]] 同属企业监控体系，Topic 8 聚焦指标监控，Topic 54 聚焦日志分析，共同构成完整可观测性视图。 + +**[[ctp-topic-42-grafana-observability-dashboard]]**（CTP Topic 42）：企业级 Grafana 可观测性平台在 AWS 多账户环境下的架构设计与 Terraform IaC 自动化实践——涵盖 Grafana 核心定位（不存储数据，仅从数据源可视化）、基础设施架构（监控账户部署 Grafana，通过 IAM 角色跨账户访问产品团队 AWS 账户）、用户和团队访问控制（Editor/Viewer/Admin 角色）、示例仪表盘（CPU/I/O/Network/EBS/Estimated Charges）、告警系统（Microsoft Teams 通知）、Terraform 模块化供给（数据源模块 + 组织模块 + LZSAP 自动化接入）、Prometheus 网络监控（Checkpoint/防火墙 SNMP 指标）。与 [[ctp-topic-54-esm-saas-log-analytics]]（日志分析）同属可观测性专题，共同构成监控知识体系；长期目标是构建应用级仪表盘替代 [[Micro Focus Operations Bridge Manager]]。 + **[[ctp-topic-35-aws-landing-zone-design-refresher-saas-labs]]**（CTP Topic 35）：AWS Landing Zone 设计复习——重点明确 SaaS（生产）与 Labs（开发）的职责划分。SaaS Landing Zone 为每个产品区域提供客户专属环境，产品账户连接至共享服务账户（安全、日志、网络）；核心账户组包含 AD、DNS 和 Network 账户；Gruntwork 账户跨所有账户管理 AMI、日志和安全。近期变更：网络分段阻断对 SaaS 工作负载的直接连通性；CCOEs CloudTrail 取代 Gruntworks CloudTrail 实现统一审计；入站流量拟通过 Network 账户 Checkpoint 重新路由；原生 AWS Backup 有望强制化；新账户可能取消 Management VPC。核心结论：**SaaS = 生产，Labs = 开发**；PoC Landing Zone 将并入 Labs 以最大化资源共享；Cloud Technology Design Forum 推动 Micro Focus 云交付标准化。 **[[ctp-topic-6-aws-workspaces-demo]]**（CTP Topic 6）：AWS Workspaces 虚拟桌面解决方案实操演示——通过 AWS Workspaces 为云转型团队提供托管 Windows 虚拟桌面（Windows Server 2016），预装 PFSSO、Terraform、TerraGrunt、Git 和 VS Code。用户通过邮件联系 Naga 申请账号，接收注册码和用户名后登录，可立即访问 AWS Console（Federation）和 GitHub Enterprise 并生成 SSH 密钥。演示全程约 21 分钟完成仓库克隆、PFSSO 认证和 TerraGrunt Plan 执行，达成"申请后 45 分钟内运行 Terraform"的目标。未来计划与 Active Directory 集成实现自动化账号管理。属 [[AWS-Landing-Zone]] 用户端工具层的核心实践，与 [[ctp-topic-1-gruntwork-landing-zone-architecture]]（基础架构）和 [[ctp-topic-9-ci-cd-with-gruntwork]]（CI/CD 流程）共同构成完整的"架构→交付→使用"链路。 @@ -83,7 +95,7 @@ Cloud Transformation Programme (CTP) materials cover AWS landing zones, EKS, Ter **[[ctp-topic-61-workload-vpc-provision-with-ipam-automation]]**（CTP Topic 61）：Workload VPC 完整自动化供给方案——Pushka（Principal SRE）主讲，在 Topic 45 的 IPAM 自动分配机制基础上，展示了端到端 VPC 供给流程。核心增强：多 VPC 批量供给支持、邮件通知机制、CIDR /22 阈值自动审批（更大 CIDR 自动，更小需理由审批）、非路由 IP 地址（如 10.2.0.0/16）支持、使用 AZ ID 避免跨账号不一致。Infoblox Grid 作为全局唯一 IP 地址数据源防止重叠，架构包含休斯顿数据中心主库及冗余 DNS/NTP/DHCP 服务。核心理念：**"只需把信息放到正确位置，一切自动完成。"** 属 [[IPAM（IP Address Management）]] 的应用层扩展，与 [[ctp-topic-45-automatic-ip-address-allocation-with-ipam]] 共同构成 IPAM 的"机制 → 应用"完整链路。 -Key concepts: [[Process]], [[Value]], [[Value-Stream]], [[Value-Adding]], [[Waste]], [[Benefits-Quantification]], [[Cost-of-Delay]], [[WSJF]], [[SOM]], [[Feature-Level-Value-Breakdown]], [[Program-Demand-Process]], [[Proof-of-Concept]], [[Gate-Process]], [[Solution-Design]], [[Landing Zone Architecture]], [[Product-Backlog]], [[Demand-Management]], [[SMACs]], [[Prerequisite-Phase]], [[Hyper-Care]], [[Octane]], [[Hybrid DNS Resolution]], [[VMware-Cloud-on-AWS]], [[VMware]], [[HCX]], [[SDDC]], [[Stretched-Cluster]], [[Hybrid-Cloud]], [[Multi-Cloud Strategy]], [[Multi-Cloud-ROI]], [[DevOps Culture]], [[CI/CD Pipeline]], [[DevSecOps]], [[Shift-Left-Security]], [[Shift-Right-Security]], [[SAST]], [[DAST]], [[IAST]], [[SCA]], [[Break-the-Build]], [[Agile Practices]], [[DevOps Maturity]], [[DORA Metrics]], [[Infrastructure as Code]], [[Cloud-Native]], [[Cloud Maturity Levels]], [[Cloud Adoption Strategy]], [[Cloud Service Delivery]], [[Cloud DevOps Maturity Model]], [[Cloud Operating Model]], [[Cloud Governance]], [[Cloud Cost Optimization]], [[Serverless Computing]], [[Edge Computing]], [[Green Computing]], [[Data-Warehouse]], [[MPP]], [[Columnar-Storage]], [[Sort-Key]], [[Distribution-Key]], [[Vendor-Lock-In]], [[Data-Sovereignty]], [[NFR（非功能需求）]], [[Error Budget（错误预算）]], [[Chaos Engineering]], [[高可用（High Availability）]], [[灾难恢复架构模式]], [[Vault Lock]], [[跨账户备份]], [[增量备份]], [[SPF]], [[DKIM]], [[TLS]], [[API-Key-Rotation]], [[Cyber-Suite]], [[CBC-Mode]], [[SendGrid]], [[Twilio]] vs [[全量备份]]（CTP Topic 72：增量仅捕获变更，节省存储成本）、**[[AWS Backup Audit Manager]]**（BAM，CTP Topic 72：合规审计报告）、**[[AWS-Tagging-Standards]]**（CTP Topic 28：AWS 标签规范，涵盖命名约定、强制标签键、成本标签策略；与 Checkpoint 防火墙安全策略直接关联，标签缺失导致流量拦截）、**[[Tag-Validation-Tool]]**（CTP Topic 28：SRE 团队开发的 Python/Boto3 工具，通过 YAML 配置扫描 AWS 资源标签合规性）、**[[Service-Control-Policies-SCPs]]**（AWS Organizations 策略类型，通过「显式拒绝」逻辑强制执行标签规范）、**[[OU-Layered-Security]]**（通过组织单元分层结构检查标签确保正确归属）、**[[Tag-Based-Security]]**（将资源标签作为安全凭证替代传统 IP 规则）、**[[Checkpoint-Firewall]]**（防火墙供应商，依赖 AWS 标签值配置网络访问策略）、**[[Variables-YAML]]**（Tag Validation Tool 核心配置文件，定义每个账户的合法标签键及允许值）、**[[SRE-Tools-Repository]]**（内部代码仓库，存放 Tag Validation Tool 等 SRE 自动化脚本）：[[WAF]], [[APM]], [[Cloud Security]], [[Cloud Migration]], [[High Availability]], [[Pay-as-you-go]], [[Failover]], [[Multi-factor-Authentication]], [[Data-Governance]], [[Continuous Integration]], [[Continuous Deployment]], [[Lead Time]], [[Time-to-Market]], [[MTTR]], [[MTTD]], [[MTTA]], [[Change Failure Rate]], [[Error Budget]], [[Rollback Rate]], [[Availability]], [[Scalability]], **[[Agentic AI]]**, [[Root Cause Analysis (RCA)]], [[Predictive Maintenance]], [[Deployment Automation]], [[Rightsizing]], [[Automated Security Audit]], [[AI ChatOps]], [[What-If Simulation]], **[[RTO]]**, **[[RPO]]**, **[[Feature Flag]]**, **[[Kill Switch]]**, **[[Progressive Rollout]]**, **[[Micro-Recovery]]**, **[[Deployment-vs-Release]]**, **[[Business Impact Analysis]]**, **[[Public Cloud]]**, **[[Private Cloud]]**, **[[Hybrid Cloud]]**, **[[Shared Responsibility Model]]**, [[Multi-Tenancy]], [[Intentional Cloud Strategy]], **[[Centralized Logging]]**, **[[Cross-Account Monitoring]]**, **[[Multi-Account Deployment]]**, **[[StackSets Deployment Visibility]]**, [[CMDB]], [[Problem-Management]], [[Release-Management]], [[Configuration-Management]], [[Asset-Management]], [[Security-and-Compliance]], [[DRaaS]], [[Canary-Release]], [[Blue-Green-Deployment]], [[Threat Modeling]], [[OWASP-Top-Ten]], [[Bug-Bounty]], [[Vulnerability-Scanning]], [[Penetration-Testing]], [[Compliance-Automation]] +Key concepts: [[Process]], [[Value]], [[Value-Stream]], [[Value-Adding]], [[Waste]], [[Benefits-Quantification]], [[Cost-of-Delay]], [[WSJF]], [[SOM]], [[Feature-Level-Value-Breakdown]], [[Program-Demand-Process]], [[Proof-of-Concept]], [[Gate-Process]], [[Solution-Design]], [[Landing Zone Architecture]], [[Product-Backlog]], [[Demand-Management]], [[SMACs]], [[Prerequisite-Phase]], [[Hyper-Care]], [[Octane]], [[Hybrid DNS Resolution]], [[VMware-Cloud-on-AWS]], [[VMware]], [[HCX]], [[SDDC]], [[Stretched-Cluster]], [[Hybrid-Cloud]], [[Multi-Cloud Strategy]], [[Multi-Cloud-ROI]], [[DevOps Culture]], [[CI/CD Pipeline]], [[DevSecOps]], [[Shift-Left-Security]], [[Shift-Right-Security]], [[SAST]], [[DAST]], [[IAST]], [[SCA]], [[Break-the-Build]], [[Agile Practices]], [[DevOps Maturity]], [[DORA Metrics]], [[Infrastructure as Code]], [[Cloud-Native]], [[Cloud Maturity Levels]], [[Cloud Adoption Strategy]], [[Cloud Service Delivery]], [[Cloud DevOps Maturity Model]], [[Cloud Operating Model]], [[Cloud Governance]], [[Cloud Cost Optimization]], [[Serverless Computing]], [[Edge Computing]], [[Green Computing]], [[Data-Warehouse]], [[MPP]], [[Columnar-Storage]], [[Sort-Key]], [[Distribution-Key]], [[Vendor-Lock-In]], [[Data-Sovereignty]], [[NFR（非功能需求）]], [[Error Budget（错误预算）]], [[Chaos Engineering]], [[高可用（High Availability）]], [[灾难恢复架构模式]], [[Vault Lock]], [[ELK Stack]], [[OpenSearch]], [[Logstash]], [[Kibana]], [[BEATS]], [[Filebeat]], [[OpenTelemetry]], [[Fluent Bit]], [[Observability（可观测性）]], [[OTLP（OpenTelemetry Protocol）]], [[Three Signals]], [[Centralized-Logging]], [[Redis缓存]], [[RBAC]], [[TLS]], [[API-Key-Rotation]], [[跨账户备份]], [[增量备份]], [[SPF]], [[DKIM]], [[TLS]], [[API-Key-Rotation]], [[Cyber-Suite]], [[CBC-Mode]], [[SendGrid]], [[Twilio]] vs [[全量备份]]（CTP Topic 72：增量仅捕获变更，节省存储成本）、**[[AWS Backup Audit Manager]]**（BAM，CTP Topic 72：合规审计报告）、**[[AWS-Tagging-Standards]]**（CTP Topic 28：AWS 标签规范，涵盖命名约定、强制标签键、成本标签策略；与 Checkpoint 防火墙安全策略直接关联，标签缺失导致流量拦截）、**[[Tag-Validation-Tool]]**（CTP Topic 28：SRE 团队开发的 Python/Boto3 工具，通过 YAML 配置扫描 AWS 资源标签合规性）、**[[Service-Control-Policies-SCPs]]**（AWS Organizations 策略类型，通过「显式拒绝」逻辑强制执行标签规范）、**[[OU-Layered-Security]]**（通过组织单元分层结构检查标签确保正确归属）、**[[Tag-Based-Security]]**（将资源标签作为安全凭证替代传统 IP 规则）、**[[Checkpoint-Firewall]]**（防火墙供应商，依赖 AWS 标签值配置网络访问策略）、**[[Variables-YAML]]**（Tag Validation Tool 核心配置文件，定义每个账户的合法标签键及允许值）、**[[SRE-Tools-Repository]]**（内部代码仓库，存放 Tag Validation Tool 等 SRE 自动化脚本）：[[WAF]], [[APM]], [[Cloud Security]], [[Cloud Migration]], [[High Availability]], [[Pay-as-you-go]], [[Failover]], [[Multi-factor-Authentication]], [[Data-Governance]], [[Continuous Integration]], [[Continuous Deployment]], [[Lead Time]], [[Time-to-Market]], [[MTTR]], [[MTTD]], [[MTTA]], [[Change Failure Rate]], [[Error Budget]], [[Rollback Rate]], [[Availability]], [[Scalability]], **[[Agentic AI]]**, [[Root Cause Analysis (RCA)]], [[Predictive Maintenance]], [[Deployment Automation]], [[Rightsizing]], [[Automated Security Audit]], [[AI ChatOps]], [[What-If Simulation]], **[[RTO]]**, **[[RPO]]**, **[[Feature Flag]]**, **[[Kill Switch]]**, **[[Progressive Rollout]]**, **[[Micro-Recovery]]**, **[[Deployment-vs-Release]]**, **[[Business Impact Analysis]]**, **[[Public Cloud]]**, **[[Private Cloud]]**, **[[Hybrid Cloud]]**, **[[Shared Responsibility Model]]**, [[Multi-Tenancy]], [[Intentional Cloud Strategy]], **[[Centralized Logging]]**, **[[Cross-Account Monitoring]]**, **[[Multi-Account Deployment]]**, **[[StackSets Deployment Visibility]]**, [[CMDB]], [[Problem-Management]], [[Release-Management]], [[Configuration-Management]], [[Asset-Management]], [[Security-and-Compliance]], [[DRaaS]], [[Canary-Release]], [[Blue-Green-Deployment]], [[Threat Modeling]], [[OWASP-Top-Ten]], [[Bug-Bounty]], [[Vulnerability-Scanning]], [[Penetration-Testing]], [[Compliance-Automation]] **[[ctp-topic-40-saas-database-architecture]]**（CTP Topic 40）：SAS 数据库团队在 AWS 云上的架构与运维实践——团队分布于美国/加拿大/印度/以色列，管理 500+ 数据库和 1000+ DB 服务器；支持 Oracle、Vertica、Postgres、DynamoDB、SQL Server、MongoDB、MySQL 等多引擎；高可用架构采用三可用区模式（主库/备用库/见证节点）；使用 Oracle Data Guard、Postgres Active-Passive/Active-Active、RDS HA 实现多活；通过 Terraform、AWS CLI、Shell/PowerShell 实现 IaC 自动化；Oracle GoldenGate 支持零停机迁移。属 [[AWS-Landing-Zone]] 数据库层的核心实践，与 [[ctp-topic-51-purpose-built-databases]]（数据库品类全景）和 [[ctp-topic-66-rds-vs-aurora]]（关系型选型）共同构成完整的 AWS 数据库知识体系。 @@ -119,6 +131,8 @@ Key concepts: [[Process]], [[Value]], [[Value-Stream]], [[Value-Adding]], [[Wast **[[public-cloud-learning-sessions-opentext-thor-platform-flows-20241210-160056-meet]]**（Learning Sessions，Arnold Dacan 主讲）：Project Thor 平台架构与数据流设计详解——五大支柱框架（敏捷周期治理、产品发布治理、开发者门户 Backstage、安全与治理、Build Hub）；核心数据流：源代码流（GitLab）→ 制造流程（Build Farms）→ Artifactory → 客户环境；地理分布：工具链主站点 Brook Park + 灾备站点 Sacramento；标准化目标：统一 GitLab/Artifactory/UCMDB 工具链，夯实供应链安全基础。属 [[DevOps Culture]] 企业级工具链标准化与供应链安全的深度补充，与 GitHub→GitLab 迁移文档共同构成 Project Thor 知识体系。 +**[[public-cloud-learning-sessions-opentext-gis-security-policies-20241015-160257-me]]**（Learning Sessions，Mike & Ed 主讲）：OpenText 全球信息安全团队（GIS）安全策略全景——GIS 是分层组织架构，包含安全运营（事件响应与保障）、合规（认证与政策执行）、治理风险验证（GRV，季度审查 Admin 角色）、隐私（新增集成中）四个支柱。OpenText 采用分层方法定义安全策略——与各团队协作定义"做什么"，与执行团队协作确定"怎么做"；持有 FedRAMP 等多项行业及政府认证，可进入多个垂直市场销售；每月处理 2250 亿条日志，分诊约 350 个案例。姿态框架基于 ISO 27001（2022 年更新，新增 11 个控制方面）；Global Information Security Policy（GISP）是最高纲领性政策，季度审查。安全运营涵盖 Cyber Response Center、威胁情报（BrightCloud）、云安全、安全工具与工程等核心服务；合规组织涵盖合规项目、路线图、产品风险评估、持续合规与审计、自动化等内容。属企业级安全治理体系的核心入门，与 [[ctp-topic-10-aws-landing-zone-lz-data-collection-tagging-related-security]]（AWS 层面标签化安全）互补——GISP 定义全局政策纲领，Landing Zone 层面通过标签和 SCP 实现技术落地。 + **[[ctp-topic-28-aws-tag-validation-tool]]**（CTP Topic 28）：AWS 标签验证工具——Lewis Brown 主讲，SRE 团队开发的 Python/Boto3 工具。Checkpoint 防火墙通过读取 EC2、安全组、负载均衡器的标签值动态配置网络访问策略，标签缺失或无效将导致流量被拦截；SCPs 可阻止不合规资源创建但无法修复存量资源。该工具通过 `variables.yaml` 定义每个账户的合法标签值，自动扫描 EC2/安全组/负载均衡器/Lambda，生成 CSV 审计报告。使用 Poetry 管理 Python 环境，存放于 SRE Tools Repository。标签策略还计划用于未来成本核算，区分同一账户下不同产品的资源消耗。属 [[AWS-Landing-Zone]] 标签治理闭环的核心补充——制定规范（Topic 10）→ 强制执行（SCPs）→ 审计发现（Topic 28）。 **[[ctp-topic-30-managing-change]]**（CTP Topic 30）：云转型中的变更管理与 SRE 团队协作——Brendan Starnig（SRE Function Lead）主讲。核心内容：①SRE 职责——用软件工程思维解决运维问题，追求可靠性、可测试性、可重复性，核心是打破运维与产品的壁垒；②变更分类——Standard Change（预批准，完全自动化 IaC+CI/CD，无需 CAB）→ Normal Change（需 CAB 审批，目标是通过自动化逐步归入 Standard Change）→ Emergency Change（立即执行缓解事故，事后 CAPA/Post-mortem 修复根因）；③SRE 三阶段协作——构建（Build）/早期上线支持（Early Live Support）/BAU；④Self-Healing 演进方向——各产品组分享实践，SRE 协助在监控产品中落地。属 [[AWS-Landing-Zone]] 运维治理层的核心补充，与 [[ctp-topic-28-aws-tag-validation-tool]]（IaC 变更的 Tagging 标准属于 Standard Change 范畴）共同构成变更管理知识体系。 diff --git a/wiki/sources/ctp-topic-42-grafana-observability-dashboard.md b/wiki/sources/ctp-topic-42-grafana-observability-dashboard.md new file mode 100644 index 00000000..bf581c8e --- /dev/null +++ b/wiki/sources/ctp-topic-42-grafana-observability-dashboard.md @@ -0,0 +1,54 @@ +--- +title: "CTP Topic 42 Grafana Observability Dashboard" +type: source +tags: + - Grafana + - Observability + - Dashboard + - AWS + - Terraform + - EKS +date: 2026-04-14 +--- + +## Source File +- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-42-grafana-observability-dashboard]] + +## Summary（用中文描述） +- 核心主题：企业级 Grafana 可观测性平台在 AWS 多账户环境下的架构设计与落地实践 +- 问题域：AWS Landing Zone 多产品团队账户的集中监控与可视化需求 +- 方法/机制：Grafana + IAM 跨账户角色 + Terraform IaC 自动化 + Prometheus 网络监控 +- 结论/价值：Grafana 统一替代 Micro Focus 工具实现端到端监控，支持动态仪表盘和告警通知 + +## Key Claims（用中文描述） +- Grafana 通过 IAM 角色策略从监控账户访问各产品团队 AWS 账户，实现跨账户统一监控 +- Terraform 模块化封装 Grafana 数据源和组织结构，实现新产品组自动化接入 +- Prometheus 作为 Checkpoint 和防火墙的网络监控数据源，支持 SNMP 协议采集 +- Grafana 用户管理将逐步从数据库模式迁移至 LDAP 或 SSO 统一认证 + +## Key Quotes +> "Grafana does not exist differently data source by itself. It needs to be expressed from the data, all kinds of data sources." — Grafana 本身不存储数据，数据必须来自外部数据源 + +> "We would like to build application specific dashboards which can basically give us key insight with respect to our applications that are running over there." — 未来目标是构建应用级仪表盘，提供关键业务洞察 + +## Key Concepts +- [[Observability（可观测性）]]：通过外部输出（Metrics/Logs/Traces）推断系统内部状态的能力 +- [[Grafana]]：开源数据可视化平台，支持多数据源的图表和仪表盘 +- [[Terraform]]：HashiCorp 基础设施即代码工具，用于自动化资源供给 +- [[Prometheus]]：开源时序数据库和监控告警系统，用于网络设备指标采集 +- [[SNMP（Simple Network Management Protocol）]]：网络设备监控协议，用于采集 Checkpoint 防火墙指标 +- [[IAM Role（跨账户角色）]]：AWS IAM 角色机制，实现跨账户资源安全访问 + +## Key Entities +- [[AWS CloudWatch]]：AWS 托管监控服务，Grafana 的主要数据源之一 +- [[AWS Landing Zone]]：AWS 多账户架构框架，产品团队账户通过 IAM 角色被监控账户访问 +- [[Micro Focus Operations Bridge Manager]]：将被 Grafana 替代的传统监控工具 + +## Connections +- [[ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana]] ← extends ← [[ctp-topic-42-grafana-observability-dashboard]] +- [[ctp-topic-54-esm-saas-log-analytics]] ← related ← [[ctp-topic-42-grafana-observability-dashboard]] +- [[ctp-topic-67-cloud-native-observability-using-opentelemetry]] ← related ← [[ctp-topic-42-grafana-observability-dashboard]] +- [[ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-brid]] ← replaced_by ← [[ctp-topic-42-grafana-observability-dashboard]] + +## Contradictions +- 无明显冲突。本视频与 [[ctp-topic-60]] 均介绍 Grafana，视角互补（Grafana 本身 vs Hyperscale 场景），与 [[ctp-topic-67]] 同属可观测性专题，共同构成完整监控知识体系 diff --git a/wiki/sources/ctp-topic-54-esm-saas-log-analytics.md b/wiki/sources/ctp-topic-54-esm-saas-log-analytics.md new file mode 100644 index 00000000..bede585a --- /dev/null +++ b/wiki/sources/ctp-topic-54-esm-saas-log-analytics.md @@ -0,0 +1,64 @@ +--- +title: "CTP Topic 54 ESM SaaS Log Analytics" +type: source +tags: + - Log-Analytics + - SaaS + - ESM + - EKS + - ELK + - OpenSearch +date: 2026-04-14 +--- + +## Source File +- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-54-esm-saas-log-analytics]] + +## Summary（用中文描述） +- 核心主题：企业级日志分析解决方案（ESM SaaS），涵盖 ELK/OpenSearch 技术栈架构、区域部署、安全加固及主流方案对比 +- 问题域：多 VPC 环境下的日志集中采集、传输安全、合规存储（GDPR）及成本控制 +- 方法/机制：BEATS（Filebeat）采集 → Logstash 处理 → Elasticsearch/OpenSearch 存储 → Kibana 可视化；Redis 作为缓冲层防止 Logstash 过载；VPC 间私有流量传输 +- 结论/价值：AWS OpenSearch 性价比最优（~$1,500/月 vs Logz.io ~$4,000/月），推荐起步用 Logz.io 试用，后续迁移 AWS OpenSearch + +## Key Claims（用中文描述） +- ELK 栈（Elasticsearch + Logstash + Kibana）是开源日志分析标准方案，OpenSearch 为 AWS 托管替代 +- 应用通过 BEATS（Filebeat）采集日志，Logstash 解析日志字段后存入 Elasticsearch/OpenSearch +- 双 VPC 架构：应用 VPC 运行 Filebeat 容器持续推送日志至日志 VPC 的 Logstash +- Redis 作为可选缓冲层防止 Logstash 过载 +- 出于 GDPR 合规要求，农场按区域分割（美国俄勒冈、欧洲） +- 供应通过 CloudFormation 或 Terraform 实现，但安全加固和持续优化是主要挑战 +- 静态加密采用加密节点和 NVMe 设备硬件级加密；传输加密使用 TLS 1.2；VPC 间流量走私有网络 +- 基于索引的访问控制和 RBAC 实现不同用户角色隔离 +- 方案对比：Logz.io（托管 ELK，$4,000/月，SLA 99.8%）、AWS OpenSearch（$1,500/月，SLA 99.9%，自动快照 DR）、自托管 ELK（成本低但维护复杂）、Microfocus OBA（商业成熟，支持列级访问控制） + +## Key Quotes +> "The application collects your log, it's called the BEATS." — Jackie，解释 BEATS 组件在日志采集中的核心作用 +> "We have already built up all the farms." — Jackie，表示区域农场已完成部署 +> "Recommendations for starting with Log Analytics include beginning with Logz.io for its trial period, then transitioning to AWS OpenSearch or self-hosted options for more control." — 最佳起步路径建议 + +## Key Concepts +- [[ELK Stack]]：Elasticsearch + Logstash + Kibana 开源日志分析技术栈 +- [[OpenSearch]]：Elasticsearch 分支，AWS 托管版本，提供类似 Elasticsearch 的全文搜索和日志分析能力 +- [[Logstash]]：日志采集管道，负责解析和转换日志字段 +- [[Kibana]]：日志可视化前端 +- [[BEATS]]：轻量级日志采集代理家族，其中 Filebeat 常用作容器日志采集器 +- [[Redis]]：可选缓冲层，防止 Logstash 过载 +- [[GDPR]]：欧盟通用数据保护条例，推动日志农场按区域分割部署 +- [[RBAC]]：基于角色的访问控制，用于日志系统的用户权限管理 +- [[TLS 1.2]]：传输层加密标准，确保日志数据在传输过程中的安全性 + +## Key Entities +- [[Jackie]]：ITOM ESM SAS 架构师，本视频主讲人 +- [[AWS OpenSearch]]：AWS 托管的 OpenSearch 服务，日志分析推荐方案 +- [[Logz.io]]：托管 ELK SaaS 解决方案 +- [[Micro Focus Operations Bridge]]：企业级 IT 运维监控套件，OBA 为其日志分析组件 +- [[Elasticsearch]]：开源分布式搜索和分析引擎，ELK 栈核心组件 + +## Connections +- [[ctp-topic-8-implementation-of-cloud-monitoring-using-micro-focus-operations-brid]] ← related_to ← [[ctp-topic-54-esm-saas-log-analytics]] +- [[ctp-topic-60-monitor-aws-using-hyperscale-observability-with-grafana]] ← extends ← [[ctp-topic-54-esm-saas-log-analytics]] +- [[ctp-topic-70-eks-deployment-using-iac]] ← uses ← [[CloudFormation]] (供应工具) +- [[ctp-topic-39-implementing-eks-in-the-aws-lab-landing-zone]] ← similar_architecture ← (双 VPC 隔离架构) + +## Contradictions +- 暂无发现与现有 Wiki 页面的冲突内容 diff --git a/wiki/sources/ctp-topic-59-achieving-reliability-with-amazon-eks.md b/wiki/sources/ctp-topic-59-achieving-reliability-with-amazon-eks.md new file mode 100644 index 00000000..f5f38fa0 --- /dev/null +++ b/wiki/sources/ctp-topic-59-achieving-reliability-with-amazon-eks.md @@ -0,0 +1,67 @@ +--- +title: "CTP Topic 59 Achieving reliability with Amazon EKS" +type: source +tags: + - AWS + - EKS + - Kubernetes + - Reliability + - CTP +date: 2026-04-14 +--- + +## Source File +- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-59-achieving-reliability-with-amazon-eks.md]] + +## Summary（用中文描述） +- 核心主题：Amazon EKS（Elastic Kubernetes Service）的可靠性最佳实践，涵盖容器服务选型、应用层可靠性、控制平面可靠性和数据平面可靠性四个维度。 +- 问题域：Kubernetes 在 AWS 上的生产级可靠性保障，涉及 shared responsibility model 下 AWS 与客户的责任边界划分。 +- 方法/机制：通过 Pod 反亲和性、拓扑分布约束、HPA/VPA 扩缩容、探针配置、PodDisruptionBudget 等机制实现故障检测、优雅降级、自愈和按需扩缩；控制平面通过监控、认证加固、准入 Webhook 管理、集群升级策略保障；数据平面通过节点问题检测、资源预留、QoS、资源配额和 Pod 优先级机制保障。 +- 结论/价值：EKS 可靠性需要在应用、控制平面、数据平面三个层面综合设计，结合 AWS shared responsibility model 明确责任边界，并通过多样性部署策略（Rolling/Blue-Green/Canary）实现安全升级。 + +## Key Claims（用中文描述） +- ECS 推荐给容器化初学者，提供简单界面和原生 AWS 集成；EKS 适合熟悉 Kubernetes 生态的用户，提供开放社区灵活性。 +- 系统可靠性意味着即使发生故障也能提供可预测行为，核心关注点包括：故障检测、优雅服务降级、确定性故障模式、自愈能力和按需扩缩。 +- AWS shared responsibility model 下，AWS 负责控制平面组件（state store、scheduler、controller manager、API servers），客户负责工作节点、操作系统和应用配置。 +- Fargate 模式下客户无需管理节点、补丁或升级工作。 +- 应用可靠性需避免单例 Pod，使用 Pod 反亲和性或拓扑分布约束将应用 Pod 分散到多个可用区；HPA 默认基于 CPU 和内存扩缩容，VPA 可正确调整 Pod 大小但会导致运行时重启。 +- 部署策略包括滚动升级、蓝绿部署和金丝雀部署，各有不同控制复杂度和安全保障级别；存活探针、就绪探针和启动探针是 Pod 健康监控的关键；PodDisruptionBudget 确保维护期间的最小服务水平。 +- 控制平面可靠性需监控 API server 请求和 HCT state store 大小；必须创建具有超级管理员角色的安全用户；准入 Webhook 需仔细配置以避免阻塞控制平面；EKS 平台版本自动处理补丁版本，Minor 版本有 14 个月支持周期后自动升级。 +- 数据平面可靠性需使用节点问题检测器、预留系统资源、实现 QoS、配置资源配额和限制范围；Pod 优先级控制抢占。 + +## Key Quotes +> "ECS is a more AWS opinionated way of running containers." — ECS 与 EKS 的核心区别概述 +> "Reliability in a system means it offers predictable behavior even when failures occur." — 可靠性的本质定义 +> "With Fargate, you don't have to worry about managing the nodes or worrying about patching or upgrading the nodes." — Fargate 对 shared responsibility model 的影响 + +## Key Concepts +- [[Reliability（系统可靠性）]]：系统在发生故障时仍能提供可预测行为的能力，包含故障检测、优雅降级、确定性故障模式、自愈和按需扩缩五个核心关注点。 +- [[Application Reliability（应用可靠性）]]：通过避免单例 Pod、AZ 分散、HPA/VPA 扩缩容、部署策略（Rolling/Blue-Green/Canary）、健康探针和 PodDisruptionBudget 实现。 +- [[Control Plane Reliability（控制平面可靠性）]]：通过监控控制平面指标、安全认证加固、准入 Webhook 管理和集群升级策略保障。 +- [[Data Plane Reliability（数据平面可靠性）]]：通过节点问题检测、资源预留、QoS、资源配额、LimitRange 和 Pod 优先级机制保障。 +- [[Shared Responsibility Model（EKS）]]：AWS 负责控制平面（API server、scheduler 等），客户负责工作节点、操作系统和应用配置；Fargate 模式下进一步减少客户运维负担。 +- [[Pod Anti-Affinity]]：通过反亲和性规则将 Pod 分散到不同节点或可用区，避免单点故障。 +- [[Topology Spread Constraints]]：提供比 Pod 反亲和性更细粒度的工作负载分布控制。 +- [[Horizontal Pod Autoscaler (HPA)]]：基于 CPU 利用率和内存消耗的默认扩缩容机制，支持自定义/外部指标。 +- [[Vertical Pod Autoscaler (VPA)]]：根据实际资源使用情况自动调整 Pod 的大小配置，但运行时调整会导致 Pod 重启。 +- [[Liveness/Readiness/Startup Probes]]：三类 Kubernetes 探针，用于监控 Pod 健康状态和就绪情况。 +- [[PodDisruptionBudget]]：在自愿中断（如节点维护）期间保证最小数量或比例的 Pod 持续运行。 +- [[Rolling/Blue-Green/Canary Deployment]]：三种部署策略，滚动升级自动化程度高但回滚控制有限，蓝绿和金丝雀提供更精细的控制和快速回滚能力。 + +## Key Entities +- [[Surav Paul]]：AWS 高级解决方案架构师（Senior Solutions Architect），本场演讲的主讲人。 +- [[Amazon EKS]]：AWS 托管的 Kubernetes 服务，适合熟悉 Kubernetes 生态的用户，提供开放社区灵活性。 +- [[Amazon ECS]]：AWS 原生容器服务，推荐给容器化初学者，提供简单界面和原生 AWS 集成。 +- [[AWS Fargate]]：无服务器容器运行平台，使用 Fargate 时客户无需管理节点、补丁或升级工作。 + +## Connections +- [[CTP Topic 39 Implementing EKS in the AWS Lab Landing Zone]] ← topic_overlap ← [[CTP Topic 59 Achieving reliability with Amazon EKS]]（均涉及 EKS 部署实践，本 Topic 聚焦可靠性设计，Topic 39 聚焦网络/IP 问题解决） +- [[CTP Topic 64 Scaling out with Amazon EKS]] ← topic_overlap ← [[CTP Topic 59 Achieving reliability with Amazon EKS]]（均涉及 EKS 扩缩容，Topic 64 聚焦扩缩机制，Topic 59 聚焦可靠性全栈设计） +- [[CTP Topic 60 Monitor AWS using Hyperscale Observability with Grafana]] ← complements ← [[CTP Topic 59 Achieving reliability with Amazon EKS]]（Grafana 监控可用于 Topic 59 中的控制平面和数据平面指标监控） +- [[Public Cloud Learning Sessions EKS Optimization Part 3 of 3 Introduction to EKS Auto Mode]] ← extends ← [[CTP Topic 59 Achieving reliability with Amazon EKS]]（Auto Mode 是 EKS 可靠性自动化的进一步演进，涵盖 Fargate 集成和自动扩缩容） + +## Contradictions +- 与 [[CTP Topic 39 Implementing EKS in the AWS Lab Landing Zone]] 的潜在视角差异： + - 冲突点：Topic 39 描述 EKS 部署中的 IP 资源挑战，强调自定义网络配置（hostNetwork）和独立私有子网；Topic 59 侧重标准 EKS 可靠性机制，较少涉及网络约束场景。 + - 当前观点：两者面向不同场景——Topic 39 针对受限网络环境下的实际部署挑战，Topic 59 提供通用的 EKS 可靠性最佳实践，互为补充而非冲突。 + - 对方观点：Topic 39 认为在某些受限环境下标准 EKS 配置（如 CNI 插件默认 IP 分配）无法直接适用，需要自定义网络方案；Topic 59 的通用建议可能需要针对特殊环境调整。 diff --git a/wiki/sources/ctp-topic-64-scaling-out-with-amazon-eks.md b/wiki/sources/ctp-topic-64-scaling-out-with-amazon-eks.md new file mode 100644 index 00000000..93846807 --- /dev/null +++ b/wiki/sources/ctp-topic-64-scaling-out-with-amazon-eks.md @@ -0,0 +1,64 @@ +--- +title: "CTP Topic 64 Scaling out with Amazon EKS" +type: source +tags: [AWS, EKS, Kubernetes, Scaling, HPA, KEDA, Karpenter, Cluster-Autoscaler] +sources: [ctp-topic-64-scaling-out-with-amazon-eks] +last_updated: 2026-04-25 +--- + +## Source File +- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-64-scaling-out-with-amazon-eks.md]] + +## Summary（用中文描述） +- 核心主题：Amazon EKS 工作负载水平扩展与容量扩展的完整方法论，涵盖 Pod 级别扩展（事件驱动 + 指标驱动）和 Node 级别扩展（ASG 联动 + 直接 API） +- 问题域：传统 HPA 仅支持 CPU/内存指标，无法满足事件驱动型工作负载的零扩展需求；Cluster Autoscaler 依赖预配置 ASG 导致灵活性不足；EKS 集群 IP 地址耗尽问题；CoreDNS 等集群组件扩缩容被忽视 +- 方法/机制：HPA（标准指标扩展）→ KEDA（事件驱动扩展）→ Cluster Autoscaler（ASG 联动扩缩容）→ Karpenter/Carpenter（直接 API 扩缩容）→ IPv6 解决 IP 耗尽 → API Server PPF + CoreDNS 缓存优化集群稳定性 +- 结论/价值：EKS 扩缩容需 Pod 层（KEDA）和 Node 层（Karpenter/Carpenter）双管齐下，HPA 负责 Pod 副本数调节，容量层通过原生云工具或第三方工具解决 IP 耗尽问题，集群组件扩缩容是生产部署常被忽视但至关重要的环节 + +## Key Claims（用中文描述） +- HPA 通过拉取 Metrics Server 的 CPU/内存指标计算应用工作负载所需的 Pod 副本数，默认支持标准资源指标，自定义/外部指标（如负载均衡器并发连接数、消息中间件队列深度）可通过 Custom Metrics API 扩展 +- KEDA 通过 ScaledObject CRD 实现事件驱动扩缩容，可将应用从零副本扩展，支持 Publishes Metrics 模式为 HPA 供数，实现指标驱动与事件驱动的混合扩展 +- Cluster Autoscaler 的扩缩容决策基于集群内 Pending Pod 的数量，联动 ASG/托管节点组调整期望容量，同时考虑 Pod 的 CPU/内存 requests，支持 Mixed Instances Policy，推荐使用 Auto-discovery 模式，min/max 配置变更应在 ASG/托管节点组层面操作 +- Karpenter 是 AWS 开源的 Kubernetes 原生容量扩缩器，直接与 EC2 API 通信，支持动态按需供给（无需预配置节点组），通过 Provisioner 定义 EC2 实例需求并与工作负载的 node selector/affinity 匹配，默认禁用回收（需启用 TTL 或集群整合） +- 为解决 IP 地址耗尽问题，推荐切换至 IPv6（双栈 VPC，节点双协议栈，Pod 仅 IPv6）；若无法切换，可使用 Carrier-Grade NAT（CGNAT）配合自定义网络；IPv6 Pod 与 IPv4 目标的交互通过双层 NAT 映射配置 +- CoreDNS 扩缩容和 Node Local DNS Cache 安装是 EKS 生产部署的重要优化项 + +## Key Quotes +> "The horizontal pod autoscaler is going to pull the metrics and it is going to calculate how many replicas are required for your application workload." — HPA 的核心机制：拉取指标 → 计算所需副本数 +> +> "The scaling decision that is made by the cluster auto scaler, it is done on the number of pending pods in the cluster." — Cluster Autoscaler 的决策依据：Pending Pod 数量 +> +> "Carpenter has native integration with Kubernetes and it complements the native Kubernetes spot pod scheduling constraints that is available for your workloads." — Karpenter/Carpenter 与原生 K8s Spot Pod Disruption Budget 的互补关系 +> +> "The EKS best practices guides, specifically the scalability section." — 演讲者推荐的学习资源：EKS Best Practices Guides + +## Key Concepts +- [[Horizontal Pod Autoscaler (HPA)]]：Kubernetes 标准 Pod 水平扩缩容机制，通过 CPU/内存指标或自定义/外部指标计算副本需求，支持 stabilization window 和 period seconds 配置防止震荡 +- [[KEDA]]（Kubernetes Event-Driven Autoscaling）：基于外部事件驱动的 K8s 扩缩容框架，通过 ScaledObject CRD 定义扩缩规则，支持从零副本扩展，可 Publish Metrics 给 HPA 实现混合扩展模式 +- [[Cluster Autoscaler]]：Kubernetes 官方节点扩缩容组件，联动 AWS ASG/托管节点组，根据 Pending Pod 数量和资源 requests 调整 Node 数量，推荐 Auto-discovery 模式 +- [[Karpenter]]：AWS 开源的 Kubernetes 原生容量扩缩器，直接与 EC2 API 通信，通过 Provisioner 匹配工作负载需求，支持动态按需供给，默认禁用回收（需启用 TTL 或 Consolidation） +- [[IPv6-in-EKS]]：EKS 集群解决 IP 地址耗尽的方案，推荐双栈 VPC 架构（节点双协议栈，Pod 仅 IPv6），IPv6 Pod 与 IPv4 目标通过 NAT 映射通信 +- [[API-Server-Priority-and-Fairness]]：EKS API Server 的优先级和公平性配置，用于在高负载下保护关键工作负载的 API 访问 +- [[CoreDNS-Scaling]]：EKS 集群 CoreDNS 的水平扩缩容策略，配合 Node Local DNS Cache 降低 DNS 查询延迟 +- [[Metrics-Server]]：Kubernetes 的 CPU/内存指标采集组件，HPA 依赖其提供标准资源指标 + +## Key Entities +- [[Suravpul]]：AWS 高级解决方案架构师（Senior Solutions Architect），CTP Topic 64 和 Topic 59、Topic 67 的讲师，专注 EKS 可靠性、可观测性和扩缩容实践 +- [[Amazon EKS]]：托管 Kubernetes 服务，本 Source Page 的目标平台 +- [[AWS]]：Amazon Web Services，EKS 及相关扩缩容工具（KEDA、Karpenter）的云服务提供商 +- [[Kubernetes]]：开源容器编排平台，HPA、Cluster Autoscaler、KEDA 的上游项目 + +## Connections +- [[ctp-topic-59-achieving-reliability-with-amazon-eks]] ← 相关 ← [[Horizontal Pod Autoscaler (HPA)]]（Topic 59 涵盖 HPA 和 VPA 在 EKS 可靠性中的作用） +- [[ctp-topic-70-eks-deployment-using-iac]] ← 相关 ← [[Cluster Autoscaler]]（Topic 70 提及 Cluster Autoscaler 实现 Worker Node 自动扩缩容） +- [[ctp-topic-70-eks-deployment-using-iac]] ← depends_on ← [[ctp-topic-64-scaling-out-with-amazon-eks]]（扩缩容是 IaC 部署后的运维关注点） +- [[public-cloud-learning-sessions-eks-optimization-part-1-of-3-compute-optimization]] ← 关联 ← [[Karpenter]]（Part 1 深度对比 Karpenter 与 Cluster Autoscaler） +- [[public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks]] ← 关联 ← [[Karpenter]]（Part 3 介绍 EKS Auto Mode，内置 Karpenter Controller） +- [[ctp-topic-67-cloud-native-observability-using-opentelemetry]] ← 相关 ← [[Suravpul]]（同一讲师的可观测性专题） + +## Contradictions +- 与 [[ctp-topic-70-eks-deployment-using-iac]] 无实质冲突： + - 冲突点：无 + - 当前观点：Topic 64 提供扩缩容的完整方法论（HPA/KEDA/Carpenter + IPv6 解决 IP 耗尽） + - 对方观点：Topic 70 仅简述 Cluster Autoscaler 实现 Worker Node 自动扩缩容，侧重 IaC 部署流程 + - 注：两者互补而非冲突，Topic 70 是部署入口，Topic 64 是扩缩容深化 diff --git a/wiki/sources/ctp-topic-67-cloud-native-observability-using-opentelemetry.md b/wiki/sources/ctp-topic-67-cloud-native-observability-using-opentelemetry.md new file mode 100644 index 00000000..6d963d0b --- /dev/null +++ b/wiki/sources/ctp-topic-67-cloud-native-observability-using-opentelemetry.md @@ -0,0 +1,73 @@ +--- +title: "CTP Topic 67 Cloud native observability using OpenTelemetry" +type: source +tags: + - OpenTelemetry + - Observability + - Cloud-Native + - CTP + - AWS + - EKS + - ECS +date: 2026-04-14 +--- + +## Source File +- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/ctp-topic-67-cloud-native-observability-using-opentelemetry]] + +## Summary（用中文描述） +- 核心主题：AWS EKS/ECS 环境下的云原生可观测性实践，以 AWS Distro for OpenTelemetry (ADOT) 为核心工具实现统一监控。 +- 问题域：云原生环境下系统复杂度激增，如何通过标准化的可观测性方案实现主动式故障排查与性能优化。 +- 方法/机制：OpenTelemetry 提供厂商无关的代码插桩库和 Collector 组件（Receivers → Processors → Exporters），ADOT 在此基础上增加 AWS 专用组件和 SIGV4 认证扩展；三种观测信号（Traces/Metrics/Logs）贯穿应用层与基础设施层，通过 Correlation ID 实现跨信号关联。 +- 结论/价值：ADOT 是 AWS EKS/ECS 生产级可观测性的推荐方案，支持 Sidecar/独立任务/DaemonSet/HA Replicas 等多种部署模式，可对接 CloudWatch/X-Ray/Prometheus/Grafana 等多种后端。 + +## Key Claims（用中文描述） +- 可观测性是管理云原生系统复杂度的必要手段——通过收集 Traces/Metrics/Logs 三种信号，实现反应式和主动式故障排查。 +- 构建可观测的应用是开发者的责任——开发者需要主动在代码中植入观测能力，而非依赖运维事后补救。 +- OpenTelemetry Collector 的核心架构由 Receivers（采集信号）、Processors（转换处理）和 Exporters（导出目的地）三部分组成，实现厂商无关的信号管道。 +- ADOT 在标准 OTEL Collector 基础上封装了 AWS 专用组件，包含 SIGV4 Auth Extension 实现对 AWS 服务的无缝集成。 +- Trace 捕获应用调用栈中各层的处理耗时，是性能瓶颈定位的核心手段。 +- 从应用层和基础设施层同时采集 Metrics 可获得完整的应用视图，包括业务级指标和 X-Ray 服务图。 +- Correlation ID（如 X-Ray Trace ID）使日志事件可深度链接至 Trace 视图，实现端到端的故障追踪。 +- ADOT 支持多种 EKS/ECS 部署模式，EKS Add-on 方式通过 Operator 和 Terraform 模块简化部署并提供预置 Grafana 仪表盘。 + +## Key Quotes +> "Observability is essential for managing complexity as systems evolve." — Surav, AWS + +> "Building observable applications is a developer responsibility." — Surav, AWS + +> "A trace captures the processing time taken at individual layers in your application call stack." — Surav, AWS + +## Key Concepts +- [[OpenTelemetry]]：厂商无关的可观测性框架，提供跨语言的 SDK 和 Collector 组件 +- [[Observability（可观测性）]]：通过外部输出推断内部状态的能力，核心三信号为 Traces/Metrics/Logs +- [[AWS Distro for OpenTelemetry (ADOT)]]：AWS 维护的 OpenTelemetry 生产级发行版，含 AWS 专用组件 +- [[Three Signals]]：Traces（调用链追踪）、Metrics（指标）、Logs（日志） +- [[OTLP（OpenTelemetry Protocol）]]：OpenTelemetry 的标准传输协议 +- [[Fluent Bit]]：容器日志采集器，常与 OTEL Collector 配合使用 +- [[X-Ray]]：AWS 原生分布式追踪服务 +- [[Prometheus]]：开源时序数据库和监控告警系统 +- [[Grafana]]：开源可视化平台，常与 Prometheus/X-Ray 配合构建仪表盘 +- [[SIGV4 Auth Extension]]：OTEL Collector 的 AWS 认证扩展，用于访问 AWS 托管服务 + +## Key Entities +- [[Amazon EKS]]：AWS 托管 Kubernetes 服务，ADOT 的主要部署目标 +- [[Amazon ECS]]：AWS 容器编排服务，支持 ADOT Sidecar 和独立任务两种部署模式 +- [[AWS Distro for OpenTelemetry (ADOT)]]：AWS 官方的 OpenTelemetry 发行版 +- [[CloudWatch]]：AWS 原生监控服务，可作为 ADOT 的 Exporter 目标 +- [[Surav (AWS)]]：AWS 解决方案架构师，CTP Topic 67 讲师 + +## Connections +- [[public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113]] ← same_topic ← [[ctp-topic-67-cloud-native-observability-using-opentelemetry]] + - 两篇均为 OpenTelemetry 主题，前者为 Jay Comer 主讲的 Learning Sessions 概述，后者为 Surav 主讲的 CTP Topic 深度实践 +- [[ctp-topic-42-grafana-observability-dashboard]] ← related ← [[ctp-topic-67-cloud-native-observability-using-opentelemetry]] + - Grafana 是 ADOT 推荐的可视化后端 +- [[ctp-topic-54-esm-saas-log-analytics]] ← related ← [[ctp-topic-67-cloud-native-observability-using-opentelemetry]] + - ESM SaaS 日志分析方案与 OTEL 日志采集互补，共同构成企业级可观测性视图 +- [[ctp-topic-59-achieving-reliability-with-amazon-eks]] ← related ← [[ctp-topic-67-cloud-native-observability-using-opentelemetry]] + - EKS 可靠性实践需要可观测性支撑，监控是 SRE 可靠性的核心组成 +- [[ctp-topic-70-eks-deployment-using-iac]] ← related ← [[ctp-topic-67-cloud-native-observability-using-opentelemetry]] + - EKS IaC 部署后需配置 ADOT Add-on 完成监控栈落地 + +## Contradictions +- 无已知冲突内容。 diff --git a/wiki/sources/public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w.md b/wiki/sources/public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w.md new file mode 100644 index 00000000..17a036fb --- /dev/null +++ b/wiki/sources/public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w.md @@ -0,0 +1,56 @@ +--- +title: "Public Cloud Learning Sessions - EKS Optimization Part 2 of 3 - Running Containers with Bottlerocket OS" +type: source +tags: + - AWS + - EKS + - Bottlerocket + - Container OS + - Cloud-Native +date: 2026-04-24 +--- + +## Source File +- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/public-cloud-learning-sessions-eks-optimization-part-2-of-3-running-containers-w]] + +## Summary（用中文描述） +- 核心主题：Bottlerocket OS（火箭瓶）—— AWS 专为容器工作负载优化的最小化 Linux 发行版，用于 EKS 环境运行容器 +- 问题域：传统通用操作系统运行容器时存在体积臃肿、安全攻击面大、更新机制不可控等问题 +- 方法/机制：通过 Variant 机制实现最小化构建 + 分区镜像更新（Partition Updates）实现安全更新 + dm-verity 根文件系统验证 + SE Linux 强制模式 +- 结论/价值：Bottlerocket 将容器宿主 OS 的攻击面降至最低，提供生产级安全保证，是 EKS Auto Mode 的默认节点操作系统 + +## Key Claims（用中文描述） +- Bottlerocket 通过去除所有非必要组件（无包管理器、无默认 Shell、无默认 SSH），将容器宿主 OS 体积和攻击面降至最低 +- Bottlerocket 的 Variant 机制（平台+架构+工作负载组件组合）在构建时固定所需功能，支持 GPU/Metal 等特定工作负载定制，避免通用 OS 的臃肿 +- Bottlerocket 通过分区镜像更新（A/B 分区切换）在不停机前提下确保系统一致性，data volume 缓存容器镜像并支持快照预填充 +- Bottlerocket 的 dm-verity 对根文件系统进行加密验证，根文件系统默认只读，任何篡改均被检测 +- Bottlerocket 集成 EKS 的三种模式：自管理节点组（Self-Managed Node Groups）、托管节点组（Managed Node Groups）、Carpenter 节点池（Carpenter Node Pools） +- Bottlerocket 提供专用 CIS benchmark 加固指南，实现企业级安全基线 + +## Key Quotes +> "A variant is basically a combination of platform, supported platform, the processor architecture and the necessary binary components that are supported by the processor architecture and any additional packages and drivers that are required for your specific workloads." +> — Bottlerocket Variant 机制定义 + +> "The root file system is by default immutable, you cannot change anything there." +> — Bottlerocket 根文件系统不可变性说明 + +## Key Concepts +- [[Immutable-Root-Filesystem]]：根文件系统默认只读，任何运行时变更均被拒绝，必须通过镜像更新机制修改 +- [[dm-verity]]：内核级块设备完整性验证，通过加密哈希树检测根文件系统任何未授权变更 +- [[SE-Linux-Enforcing]]：SE Linux 默认启用 enforcing 模式，基于标签的强制访问控制（MAC） +- [[Partition-Updates]]：A/B 双分区机制，在线下载新版本镜像到非活动分区，重启后切换，确保更新原子性 +- [[CIS-Benchmark]]：Bottlerocket 提供专用 CIS benchmark 安全加固指南 + +## Key Entities +- [[Bottlerocket]]：AWS 主导维护的容器专用开源 Linux OS，采用最小化设计，Bottlerocket 可运行于笔记本、工作站和数据中心 +- [[Amazon EKS]]：Bottlerocket 通过 eksctl、Carpenter 等工具集成，支持自管理节点组、托管节点组和 Carpenter 节点池三种部署模式 +- [[AWS]]：Bottlerocket 的核心维护者和赞助方，AWS 在 GitHub 上主导项目开发 + +## Connections +- [[public-cloud-learning-sessions-eks-optimization-part-1-of-3-compute-optimization]] ← related_to ← [[Bottlerocket]]（EKS 优化系列 Part 1 - Karpenter 计算优化，Part 2 - Bottlerocket OS 节点运行时，Part 3 - EKS Auto Mode） +- [[public-cloud-learning-sessions-eks-optimization-part-3-of-3-introduction-to-eks]] ← extends ← [[Bottlerocket]]（EKS Auto Mode 默认使用 Bottlerocket 作为节点操作系统） +- [[Bottlerocket]] ← security_enforcement ← [[Immutable-Root-Filesystem]] + [[dm-verity]] + [[SE-Linux-Enforcing]] + +## Contradictions +- 与 [[ctp-topic-70-eks-deployment-using-iac]]（EKS IaC 部署）不存在直接冲突，两者互补：Topic 70 聚焦 EKS 集群的 IaC 部署方法，本文聚焦容器运行时节点的操作系统选型，共同构成完整的 EKS 部署链路 +- 与 [[ctp-topic-59-achieving-reliability-with-amazon-eks]]（EKS 可靠性）不存在冲突：Bottlerocket 的分区更新和只读根文件系统是实现 EKS 数据平面可靠性的关键机制之一 diff --git a/wiki/sources/public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113.md b/wiki/sources/public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113.md new file mode 100644 index 00000000..a7815d5b --- /dev/null +++ b/wiki/sources/public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113.md @@ -0,0 +1,61 @@ +--- +title: "Public Cloud Learning Sessions - Observability with OpenTelemetry - 20240402" +type: source +tags: + - OpenTelemetry + - Observability + - AWS + - EKS +date: 2024-04-02 +--- + +## Source File +- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/04_EKS/public-cloud-learning-sessions-observability-with-opentelemetry-20240402-160113-.md]] + +## Summary（用中文描述） +- 核心主题：AWS OpenTelemetry 可观测性解决方案全景介绍，包括 OpenTelemetry 核心概念、AWS 发行版功能及 EKS 环境下的完整演示 +- 问题域：微服务架构下 observability 的挑战（系统复杂度增加、外部输出难以推断内部状态、Gartner 估计年均 87 小时停机时间、每小时 $42,000 成本） +- 方法/机制：三信号可观测性模型（Metrics/Logs/Traces）、OpenTelemetry 统一 SDK（11 种语言支持）、OTLP 标准化协议、AWS Distribution for OpenTelemetry 自动注入、OpenTelemetry Collector 组件（Receivers/Processors/Exporters/Extensions）、Fluent Bit 日志采集 → OpenTelemetry → Amazon OpenSearch 端到端管道 +- 结论/价值：OpenTelemetry 提供 vendor-agnostic 的统一可观测性方案，AWS 发行版简化 EKS 环境部署，最新发布强化了安全合规、规模化、用户体验和日志支持 + +## Key Claims（用中文描述） +- 微服务架构导致可观测性挑战更加突出，因为系统复杂度随服务数量增加而指数增长 +- 三信号（Metrics/Logs/Traces）共同构成完整可观测性视图：Metrics 提供聚合统计、Logs 定位根因、Traces 呈现请求全链路 +- OpenTelemetry 通过统一数据格式和跨语言 SDK 解决了不同组件使用不同 SDK 和工具的碎片化问题 +- AWS Distribution for OpenTelemetry 提供统一代理，自动检测应用语言并创建预配置 Collector，实现零侵入式自动注入 +- Fluent Bit 将日志发送到 OpenTelemetry 容器（端口 55681），由 OpenTelemetry Collector 统一处理后导出至 OpenSearch +- OpenSearch Dashboard 可按 trace group 展示延迟并通过应用组成图定位性能瓶颈 + +## Key Quotes +> "Observability is defined as a measure of how well internal states of a system can be inferred from knowledge of its external outputs." — Jay Comer，AWS 演讲开场定义 +> "OpenTelemetry aims to solve the problem of disparate SDKs and tooling for different components within the observability landscape by providing an instrumentation language with different SDKs per language." — OpenTelemetry 核心价值定位 +> "The output that Fluent Bit is sending the individual logs to is the Open Telemetry endpoint on the port 55681." — Demo 中的关键配置细节 + +## Key Concepts +- [[OpenTelemetry]]：云原生计算基金会（CNCF）项目，提供跨语言的统一遥测数据采集标准，包含 SDK（11 种语言）、OTLP 协议和 Collector 组件 +- [[Observability（可观测性）]]：通过系统外部输出（logs/metrics/traces）推断内部状态的能力，微服务架构的核心挑战 +- [[Three Signals（三信号）]]：Metrics（聚合统计）、Logs（根因定位）、Traces（全链路追踪），三者共同构成完整可观测性视图 +- [[OTLP（OpenTelemetry Protocol）]]：OpenTelemetry 的标准化数据传输协议，Collector 将数据导出至不同后端 +- [[OpenTelemetry Collector]]：标准化和转换遥测数据的组件，包含 Receivers（接收器）、Processors（处理器）、Exporters（导出器）和 Extensions（扩展） +- [[AWS Distribution for OpenTelemetry]]：AWS 提供的 OpenTelemetry 统一代理，支持 Traces/Metrics/Logs 自动采集和 EKS Operator 自动注入 +- [[Fluent Bit]]：开源日志处理器和转发器，在 EKS 中采集容器日志并转发至 OpenTelemetry 端点 + +## Key Entities +- [[Jay Comer]]：AWS 解决方案架构师，主讲本次 OpenTelemetry 可观测性专题 +- [[Amazon EKS]]：AWS 托管 Kubernetes 服务，演示中运行示例应用的环境 +- [[Amazon OpenSearch Service]]：AWS 托管搜索和分析服务，演示中作为遥测数据后端存储 +- [[Amazon CloudWatch]]：AWS 原生监控服务，属于 AWS 可观测性生态但非本次演示重点 +- [[AWS X-Ray]]：AWS 原生分布式追踪服务，属于 AWS 可观测性生态但非本次演示重点 +- [[Grafana]]：开源可观测性平台，AWS 可观测性生态的重要组成部分 +- [[Prometheus]]：开源指标采集系统，AWS Managed Service Collector for Prometheus 提供无服务器的自动抓取能力 +- [[Fluent Bit]]：CNCF 毕业项目，轻量级日志处理器，用于 EKS 环境容器日志采集 + +## Connections +- [[ctp-topic-54-esm-saas-log-analytics]] ← related_to ← [[ctp-topic-67-cloud-native-observability-using-opentelemetry]] +- [[Amazon EKS]] ← instrumented_by ← [[OpenTelemetry]] +- [[Fluent Bit]] ← sends_logs_to ← OpenTelemetry Collector (port 55681) +- [[OpenTelemetry Collector]] ← exports_to ← [[Amazon OpenSearch Service]] +- [[OpenTelemetry]] ← is_standardized_by ← [[OTLP（OpenTelemetry Protocol）]] + +## Contradictions +- （暂无检测到与其他 Wiki 页面的冲突内容） diff --git a/wiki/sources/public-cloud-learning-sessions-opentext-gis-security-policies-20241015-160257-me.md b/wiki/sources/public-cloud-learning-sessions-opentext-gis-security-policies-20241015-160257-me.md new file mode 100644 index 00000000..52e2e080 --- /dev/null +++ b/wiki/sources/public-cloud-learning-sessions-opentext-gis-security-policies-20241015-160257-me.md @@ -0,0 +1,55 @@ +--- +title: "Public Cloud Learning Sessions - OpenText GIS Security Policies - 20241015" +type: source +tags: + - OpenText + - Security-Policies + - GIS +date: 2026-04-14 +--- + +## Source File +- [[Cloud & DevOps/Public-Cloud-Learning-Sessions/07_Security/public-cloud-learning-sessions-opentext-gis-security-policies-20241015-160257-me.md]] + +## Summary（用中文描述） +- 核心主题：OpenText 全球信息安全团队（GIS）安全策略全景介绍 +- 问题域：企业级安全治理与合规体系设计 +- 方法/机制：分层层级安全组织架构 + ISO 27001 姿态框架 + 三方渗透测试 + 安全意识培训 +- 结论/价值：政策是基础设施的基石，运营、工具和流程均构建在此框架之上 + +## Key Claims（用中文描述） +- OpenText 采用分层方法定义安全策略——与各团队协作定义"做什么"，与执行团队协作确定"怎么做" +- OpenText 持有 FedRAMP 等多项行业及政府认证，可进入多个垂直市场销售 +- OpenText 每年进行第三方测试（桌面演练+红队演练），持续处于顶级梯队 +- 月处理 2250 亿条日志，每月分诊约 350 个案例 +- Global Information Security Policy（GISP）是最高纲领性政策，季度审查 + +## Key Quotes +> "Policies are foundational elements, with operations, tools, and processes built on that framework." — Mike & Ed, GIS Team + +> "The focus is on how many people report suspicious activity." — GIS Security Awareness Program + +> "Policies define what needs to be done, while providing flexibility for how it is implemented." — GIS Policy Framework + +## Key Concepts +- [[Global Information Security Policy (GISP)]]：最高纲领性政策，季度审查 +- [[ISO-27001]]：姿态框架基础，2022 年更新，新增 11 个控制方面 +- [[Security-Awareness-Training]]：月度安全通讯 + 网络钓鱼演练 +- [[Third-Party-Penetration-Testing]]：年度桌面演练 + 红队演练 +- [[Threat-Intelligence]]：结合 BrightCloud 等工具的威胁情报体系 +- [[FedRAMP]]：政府级云安全认证 + +## Key Entities +- [[Mike]]：Global Information Security Team，主讲人 +- [[Ed]]：Global Information Security Team，主讲人 +- [[OpenText]]：企业主体，安全策略制定者 +- [[BrightCloud]]：OpenText 自有威胁情报工具 + +## Connections +- [[CTP-Topic-21-Supply-Chain-Security-in-Micro-Focus]] ← related_to ← [[GIS-Security-Policies]]（供应链安全同属安全治理范畴） +- [[CTP-Topic-52-3-Lines-of-Defence]] ← extends ← [[GIS-Security-Policies]]（三道防线框架与 GIS 分层组织高度吻合） + +## Contradictions +- 与 [[CTP-Topic-10-AWS-Landing-Zone-LZ-Data-Collection-Tagging-Related-Security]] 存在视角互补而非冲突： + - 冲突点：两者均涉及安全治理，但 Topic 10 聚焦于 AWS 层面的标签化安全策略（SCP/Checkpoint），Topic 41 聚焦于企业级安全政策框架（ISO 27001/GISP） + - 当前观点：两者互补——GISP 定义全局政策纲领，AWS Landing Zone 层面通过标签和 SCP 实现技术落地