技术

本地AgentOpenClaw typescript学习 Agent前端 Agent调优 Agent评估 OS Agent Agent与软件开发 提升Agent能力——上下文工程 llm评测 rl微调 分布式Agent与A2A deepresearch梳理 mcp学习 SSE 和 WebSocket 是什么？ AutoGen学习 Python ioc 从0到1构建一个db 上下文记忆——AI Agent native 的任务存储机制 线性RAG的进化——agentic rag 图数据库的一些考量 推理LLM梳理 Agent演进 LLM预训练 向量数据库的一些考量 fastapi+sqlalchemy进行项目开发 LLM微调实践 Python协程实现 Agent Functon Calling LLamaIndex入门 另一种微服务架构Multi-Agent Python虚拟机 LangGraph工作流编排 Python实践 增强型LLM——Agent 激发LLM涌现——提示工程 LLM微调理论 大佬谈LLM LLM外挂知识库 LLMOps 多模态LLM Python一些比较有意思的库 Transformers源码学习 LangChain源码学习 通用分布式计算引擎Ray Python并发 go依赖注入 go collection gc的基本原理 golang性能分析及优化 数据湖 高性能计算与存储 Linux2.1.13网络源代码学习 《大数据经典论文解读》 三驾马车学习 Spark 内存管理及调优 Yarn学习 从Spark部署模式开始讲源码分析 容器狂占内存资源怎么办？ 多角度理解一致性 golang io使用及优化模式 Flink学习 c++学习 学习ebpf go设计哲学 ceph学习 学习mesh kvm虚拟化 学习MQ go编译器以及defer实现 学习go 为什么要有堆栈 汇编语言 计算机组成原理 运行时和库 Prometheus client mysql 事务 mysql 事务的隔离级别 mysql 索引 坏味道 学习分布式 学习网络 学习Linux go堆内存分配 golang 系统调用与阻塞处理 Goroutine 调度过程 重新认识cpu mosn有的没的 负载均衡泛谈 单元测试的新解读 《Redis核心技术与实现》笔记 《Prometheus监控实战》笔记 Prometheus 告警学习 calico源码分析 对容器云平台的理解 Prometheus 源码分析 并发的成本 基础设施优化 hashicorp raft源码学习 docker 架构 mosn细节 与微服务框架整合 Java动态代理 编程范式 并发通信模型 《网络是怎样连接的》笔记 go channel codereview gc分析 jvm 线程实现 go打包机制 go interface及反射 如何学习Kubernetes 《编译原理之美》笔记——后端部分 《编译原理之美》笔记——前端部分 Pilot MCP协议分析 go gc 内存管理玩法汇总 软件机制 istio流量管理 Pilot源码分析 golang io 学习Spring mosn源码浅析 MOSN简介 《datacenter as a computer》笔记 学习JVM Tomcat源码分析 Linux可观测性 学习存储 学计算 Gotty源码分析 kubernetes operator kaggle泰坦尼克问题实践 kubernetes扩缩容 神经网络模型优化 直觉上理解深度学习 如何学习机器学习 TIDB源码分析 什么是云原生 Alibaba Java诊断工具Arthas TIDB存储——TIKV 《Apache Kafka源码分析》——简介 netty中的线程池 guava cache 源码分析 Springboot 启动过程分析 Spring 创建Bean的年代变迁 Linux内存管理 自定义CNI IPAM 共识算法 spring redis 源码分析 kafka实践 spring kafka 源码分析 Linux进程调度 让kafka支持优先级队列 Codis源码分析 Redis源码分析 C语言学习 《趣谈Linux操作系统》笔记 docker和k8s安全访问机制 jvm crash分析 Prometheus 学习 Kubernetes监控 Kubernetes 控制器模型 容器日志采集 容器狂占资源怎么办？ Kubernetes资源调度——scheduler 时序性数据库介绍及对比 influxdb入门 maven的基本概念 《Apache Kafka源码分析》——server Kubernetes类型系统 源码分析体会 《数据结构与算法之美》——算法新解 Kubernetes源码分析——controller mananger Kubernetes源码分析——apiserver Kubernetes源码分析——kubelet Kubernetes介绍 ansible学习 Kubernetes源码分析——从kubectl开始 jib源码分析之Step实现 线程排队 jib源码分析之细节 跨主机容器通信 jib源码分析及应用 为容器选择一个合适的entrypoint kubernetes yaml配置 《持续交付36讲》笔记 mybatis学习 程序猿应该知道的 无锁数据结构和算法 CNI——容器网络是如何打通的 为什么很多业务程序猿觉得数据结构和算法没用？ 串一串一致性协议 当我在说PaaS时，我在说什么 《数据结构与算法之美》——数据结构笔记 PouchContainer技术分享体会 harbor学习 用groovy 来动态化你的代码 精简代码的利器——lombok 学习 《深入剖析kubernetes》笔记 编程语言那些事儿 rxjava3——背压 rxjava2——线程切换 spring cloud 初识 《深入拆解java 虚拟机》笔记 《how tomcat works》笔记 hystrix 学习 rxjava1——概念 Redis 学习 TIDB 学习 如何分发计算 Storm 学习 AQS1——论文学习 Unsafe Spark Stream 学习 linux vfs轮廓 《自己动手写docker》笔记 java8 实践 中本聪比特币白皮书 细读 区块链泛谈 比特币 大杂烩 总纲——如何学习分布式系统 hbase 泛谈 forkjoin 泛谈 看不见摸不着的cdn是啥 《jdk8 in action》笔记 程序猿视角看网络 bgp初识 calico学习 AQS——粗略的代码分析 我们能用反射做什么 web 跨域问题 《clean code》笔记 《Elasticsearch权威指南》笔记 mockito简介及源码分析 2017软件开发小结—— 从做功能到做系统 《Apache Kafka源码分析》——clients dns隐藏的一个坑 《mysql技术内幕》笔记 log4j学习 为什么netty比较难懂？ 递归、回溯、动态规划 apollo client源码分析及看待面向对象设计 学习并发 docker运行java项目的常见问题 OpenTSDB 入门 spring事务小结 分布式事务 javascript应用在哪里 《netty in action》读书笔记 netty对http2协议的解析 ssl证书是什么东西 http那些事 苹果APNs推送框架pushy apple 推送那些事儿 编写java框架的几大利器 java内存模型和jvm内存布局 java exception Linux IO学习 netty内存管理 测试环境docker化实践 netty在框架中的使用套路 Nginx简单使用 《Linux内核设计的艺术》小结 Go并发机制及语言层工具 Linux网络源代码学习——数据包的发送与接收 《docker源码分析》小结 docker namespace和cgroup zookeeper三重奏 数据库的一些知识 Spark 泛谈 链式处理的那些套路 netty回顾 Thrift基本原理与实践（二） Thrift基本原理与实践（一） 回调 异步执行抽象——Executor与Future Docker0.1.0源码分析 java gc Jedis源码分析 深度学习泛谈 Linux网络命令操作 JTA与TCC 换个角度看待设计模式 Scala初识 向Hadoop学习NIO的使用 以新的角度看数据结构 并发控制相关的硬件与内核支持 systemd 简介 quartz 源码分析 基于docker搭建测试环境(二) spring aop 实现原理简述 自己动手写spring（八） 支持AOP 自己动手写spring（七） 类结构设计调整 分析log日志 自己动手写spring（六） 支持FactoryBean 自己动手写spring（九） 总结 自己动手写spring（五） bean的生命周期管理 自己动手写spring（四） 整合xml与注解方式 自己动手写spring（三） 支持注解方式 自己动手写spring（二） 创建一个bean工厂 自己动手写spring（一） 使用digester varnish 简单使用 关于docker image的那点事儿 基于docker搭建测试环境 分布式配置系统 JVM执行 git maven/ant/gradle/make使用 再看tcp kv系统 java nio的多线程扩展 《Concurrency Models》笔记 回头看Spring IOC IntelliJ IDEA使用 Java泛型 vagrant 使用 Go常用的一些库 Python初学 Goroutine 调度模型 虚拟网络 《程序员的自我修养》小结 Kubernetes存储 访问Kubernetes上的Service Kubernetes副本管理 Kubernetes pod 组件 Go基础 JVM类加载 硬币和扑克牌问题 LRU实现 virtualbox 使用 ThreadLocal小结 docker快速入门

架构

rl与sft 大模型infra综述 OpenTelemetry及生态 大模型可观测性 grpo演进 rlhf演进 agent框架 reward演进 大模型RLHF框架 大模型rl后训练系统 GPU与CUDA RL闲谈 MCTS与LLM rl与post-train rl入门 从Transformer到DeepSeek bert rerank微调 大模型推理tips RAG向量检索与微调 dddfirework源码分析 RAG与知识图谱 大模型推理服务框架vLLM 大模型推理服务框架 模型服务化（未完成） 大模型Post-Training 大模型训练 大模型推理 从Attention到Transformer k8s设备管理 ddd从理念到代码 如何应用LLM 语言模型的发展 多类型负载协调员Koordinator controller-runtime细节分析 finops学习 kubevela多集群 kubevela中cue的应用 基于k8s的工作流 kubevela源码分析 容器和CPU那些事儿 数据集管理fluid 应用管理平台kubevela karmada支持crd 多集群管理 AutoML和AutoDL 特征平台 实时训练 分布式链路追踪 K8S YAML 资源清单管理方案 tensorflow原理——python层分析 如何学习tensorflow 数据并行——allreduce 数据并行——ps 推荐系统embedding原理及实践 机器学习中的python调用c 机器学习训练框架概述 tensornet源码分析 大模型训练和推理 X的生成——特征工程 tvm tensorflow原理——core层分析 模型演变 《深度学习推荐系统实战》笔记 keras 和 Estimator tensorflow分布式训练 分布式训练的一些问题 基于Volcano的弹性训练 图神经网络 pytorch弹性分布式训练 从混部到统一调度 对序列建模——从RNN到Attention pytorch分布式训练 CNN 《动手学深度学习》笔记 pytorch与线性回归 多活 volcano特性源码分析 推理服务 kubebuilder 学习 mpi 学习pytorch client-go学习 提高gpu 利用率 GPU与容器的结合 GPU入门 AI云平台梳理 tensorflow学习 tf-operator源码分析 k8s批处理调度/Job调度 喜马拉雅容器化实践 Kubernetes 实践 学习rpc BFF openkruise学习 可观察性和监控系统 监控系统 基于Kubernetes选主及应用 《许式伟的架构课》笔记 Admission Controller 与 Admission Webhook 发布平台系统设计 k8s水平扩缩容 Scheduler如何给Node打分 Scheduler扩展 深入controller openkruise cloneset学习 controller-runtime源码分析 pv与pvc实现 csi学习 client-go informer源码分析 kubelet 组件分析 调度实践 Pod是如何被创建出来的？ 《软件设计之美》笔记 mecha 架构学习 Kubernetes events学习及应用 CRI——kubelet与容器引擎之间的接口 资源调度泛谈 业务系统设计原则 grpc学习 元编程 以应用为中心 istio学习 下一代微服务Service Mesh 《实现领域驱动设计》笔记 概率论 serverless 泛谈 《架构整洁之道》笔记 处理复杂性 那些年追过的并发 服务器端编程 网络通信协议 架构大杂烩 如何学习架构 《反应式设计模式》笔记 项目的演化特点 反应式架构摸索 函数式编程的设计模式 服务化 ddd反模式——CRUD的败笔 研发效能平台 重新看面向对象设计 业务系统设计的一些体会 函数式编程 《左耳听风》笔记 业务程序猿眼中的微服务管理 DDD实践——CQRS 项目隔离——案例研究 《编程的本质》笔记 系统故障排查汇总及教训 平台支持类系统的几个点 代码腾挪的艺术 abtest 系统设计汇总 《从0开始学架构》笔记 初级权限系统设计 领域驱动理念 现有上传协议分析 移动网络下的文件上传要注意的几个问题 推送系统的几个基本问题 做配置中心要想好的几个基本问题 不同层面的异步 分层那些事儿 用户认证问题 资源的分配与回收——池 消息/任务队列

标签

Container 23

Concurrency 14

Life 41

Tool 8

Algorithm 8

JVM 10

Go 21

Kubernetes 65

k8s设备管理 多类型负载协调员Koordinator controller-runtime细节分析 finops学习 kubevela多集群 kubevela中cue的应用 基于k8s的工作流 kubevela源码分析 容器和CPU那些事儿 数据集管理fluid 应用管理平台kubevela karmada支持crd 多集群管理 K8S YAML 资源清单管理方案 从混部到统一调度 volcano特性源码分析 kubebuilder 学习 client-go学习 tf-operator源码分析 k8s批处理调度/Job调度 喜马拉雅容器化实践 Kubernetes 实践 openkruise学习 基于Kubernetes选主及应用 Admission Controller 与 Admission Webhook k8s水平扩缩容 Scheduler如何给Node打分 Scheduler扩展 深入controller openkruise cloneset学习 controller-runtime源码分析 pv与pvc实现 csi学习 client-go informer源码分析 kubelet 组件分析 调度实践 Pod是如何被创建出来的？ Kubernetes events学习及应用 CRI——kubelet与容器引擎之间的接口 资源调度泛谈 如何学习Kubernetes 以应用为中心 kubernetes operator kubernetes扩缩容 serverless 泛谈 什么是云原生 自定义CNI IPAM docker和k8s安全访问机制 Kubernetes监控 Kubernetes 控制器模型 Kubernetes资源调度——scheduler Kubernetes类型系统 Kubernetes源码分析——controller mananger Kubernetes源码分析——apiserver Kubernetes源码分析——kubelet Kubernetes介绍 Kubernetes源码分析——从kubectl开始 kubernetes yaml配置 CNI——容器网络是如何打通的 当我在说PaaS时，我在说什么 《深入剖析kubernetes》笔记 Kubernetes存储 访问Kubernetes上的Service Kubernetes副本管理 Kubernetes pod 组件

Other 5

Network 15

Python 8

Java 20

Spring 17

Netty 10

Storage 25

Distribute 9

MQ 8

WEB 7

Linux 11

Scala 1

Code 9

MachineLearning 103

本地AgentOpenClaw Agent前端 Agent调优 Agent评估 OS Agent rl与sft 大模型infra综述 Agent与软件开发 提升Agent能力——上下文工程 llm评测 大模型可观测性 rl微调 grpo演进 rlhf演进 agent框架 分布式Agent与A2A reward演进 deepresearch梳理 mcp学习 大模型RLHF框架 大模型rl后训练系统 GPU与CUDA RL闲谈 MCTS与LLM rl与post-train rl入门 AutoGen学习 从Transformer到DeepSeek 上下文记忆——AI Agent native 的任务存储机制 线性RAG的进化——agentic rag bert rerank微调 大模型推理tips 推理LLM梳理 Agent演进 LLM预训练 RAG向量检索与微调 LLM微调实践 RAG与知识图谱 大模型推理服务框架vLLM Agent Functon Calling LLamaIndex入门 另一种微服务架构Multi-Agent LangGraph工作流编排 大模型推理服务框架 模型服务化（未完成） 大模型Post-Training 大模型训练 大模型推理 从Attention到Transformer 增强型LLM——Agent 激发LLM涌现——提示工程 LLM微调理论 大佬谈LLM LLM外挂知识库 LLMOps 多模态LLM Transformers源码学习 LangChain源码学习 如何应用LLM 语言模型的发展 AutoML和AutoDL 特征平台 实时训练 tensorflow原理——python层分析 如何学习tensorflow 数据并行——allreduce 数据并行——ps 推荐系统embedding原理及实践 机器学习中的python调用c 机器学习训练框架概述 tensornet源码分析 大模型训练和推理 X的生成——特征工程 tvm tensorflow原理——core层分析 模型演变 《深度学习推荐系统实战》笔记 keras 和 Estimator tensorflow分布式训练 分布式训练的一些问题 基于Volcano的弹性训练 图神经网络 pytorch弹性分布式训练 对序列建模——从RNN到Attention pytorch分布式训练 CNN 《动手学深度学习》笔记 pytorch与线性回归 推理服务 mpi 学习pytorch 提高gpu 利用率 GPU与容器的结合 GPU入门 AI云平台梳理 tensorflow学习 kaggle泰坦尼克问题实践 神经网络模型优化 概率论 直觉上理解深度学习 如何学习机器学习 深度学习泛谈

Practice 15

RPC 6

Compute 11

Architecture 20

DDD 6

Reactive 5

Basic 13

Product 3

Monitor 9

CPP 2

Mesh 12


监控系统

2021年01月13日

简介

一切系统都是分布式的在经典分布式计算理论中，我们学到的一件事情是：分布式系统经常会发生故障，而且 大都是局部而非全局故障。这些故障不仅难于诊断和预测，而且很难复现。应对复杂分布式系统的方法并不是简单地增加测试，或者采用敏捷开发流程，也不是采用 DevOps 或者持续交付（continuous delivery）。任何单一的技术或方法都无法阻止事故再次发生。实际上，类似这样的事情肯定会再次发生。你必须开始：

  1. 接受这样的假设：支撑你的软件运行的系统一定会发生故障
  2. 对为什么会发生故障以及故障可能会以怎样的形式发生做出预案
  3. 针对这些预案设计数据收集方案

这并不是像说一句“我们需要更多测试”那么简单。传统的测试哲学中，假定 所有测试用例都是能够描述出来的，但在分布式系统中这一点不再成立。（这并不是说 测试不重要了，而是说测试不再是万灵药。）当处于一个分布式环境、并且大部分故障模 式都是无法提前预测也无法测试时，监控就成了唯一的理解应用行为的方式。在这个过程中开发者不能再将监控视为纯粹是系统管理员的领 域。

看Netflix如何简化应用程序监控体系

淘宝客户端诊断体系升级实践

2022，我们该如何理解可观测技术我们可以将可观测问题大致分为四类：

  1. 分布式链路追踪技术：可观测的基石。分布式链路追踪技术的核心思想是：在用户一次请求服务的调⽤过程中，无论请求被分发到多少个子系统，子系统又调用了多少其他子系统，我们都要把系统信息和系统间调用关系都追踪记录下来，最终把数据集中起来做可视化展示。
  2. APM：Application Performance Monitoring ，应用性能监控
  3. NPM：Network Performance Monitoring ，网络性能监控。其关键在于实现全网流量的可视化，对数据包、网络接口、流数据进行监控和分析。
  4. RUM：Real User Monitoring，真实用户监控。关键在于端到端反应用户的真实体验，捕捉用户和页面的每一个交互并分析其性能。 同时，可观测存在三个主要的数据源： 聊聊可观测性之数据模型
  5. 指标（metrics），告诉我们是否有故障，它的数据模型：LabelSet + Timestamp + Number
  6. 链路（trace），告诉我们故障在哪里，数据模型：LabelSet + Timestamp + String，和 Metric 类似，只是 Number 换成了 String
  7. 日志（log），告诉我们故障的原因，数据模型：Operation Name + Start / End Timestamp + Attributes + Events + Parent + SpanContext。
    1. Operation Name：操作名
    2. Start / End Timestamp：开始和结束时间
    3. Attributes：KV 对，包括 Status（比如 OK、Cancelled、Permission Denied）、
    4. SpanKind（CLIENT、SERVER、PRODUCER、CONSUMER、INTERNAL 等）、自定义信息等
    5. Events：若干个元组列表，每个元组包括 timestamp、name、Attributes，用于记录一系列重要事件
    6. Parent 包含父亲的 Span ID、Trace ID
    7. SpanContext 包含自身的 Span ID、Trace ID 所处行业不同，对可观测体系的需求也会有较大差异。比如说，电商行业可能对链路和日志监控的联动要求很高，但物联网系统可能很多不需要链路监控。

监控报警

蚂蚁智能监控在设计稳定性架构之初，我们首先应该意识到系统的运行时环境和输入都不会是稳定的。

  1. 运行时环境的不稳定 ，主要体现在机器的故障宕机、网络的抖动，或者更极端的机房光纤被挖断、城市自然灾害等客观因素影响。处理这类问题通常从两方面出发：
    1. 尽可能地提升系统的容灾等级。例如单点、机房级容灾、城市级容灾等
    2. 所有的数据处理流程都应该面向失败进行设计。因为当故障发生后，可能某几个周期的任务已经失败，这时候需要有能力驱动这些任务进行重试
  2. 针对系统输入的不确定性 ，我们也分两种情况进行处理：
    1. 第一种情况是入口数据的错乱，例如脏配置、脏元数据、不合法的数据类型等，错误的数据流入系统可能会导致不可预期的行为，针对此类问题，我们通常需要在入口处进行校验，拒绝非预期的数据流入系统。
    2. 第二种情况是入口数据量级管控，任何系统，其性能都是和容量挂钩的，其设计也都是在一定的性能容量平衡假设下进行的。

一个好的监控报警系统什么样

云原生下的可观察性发展方向当我在说可观察性的时候我在说啥？

典型问题排查过程

在 IT 系统的可观察性上，也可以类似划分 6 级：

  1. 等级 0：手工分析，依靠基础的 Dashboard、告警、日志查询、分布式链路追踪等方式进行手动告警、分析，也是目前绝大部分公司使用的场景
  2. 等级 1：智能告警，能够自动去扫描所有的可观察性数据，利用机器学习的方式去识别一些异常并进行自动告警，免去人工设置 / 调整各种基线告警的工作
  3. 等级 2：异常关联 + 统一视图，对于自动识别的异常，能够进行上下文的关联，形成一个统一的业务视图，便于快速的定位问题
  4. 等级 3：根因分析 + 问题自愈，自动根据异常以及系统的 CMDB 信息直接定位问题的根因，根因定位准确后那边可以去做问题的自愈。这一阶段相当于是一次质的飞跃，在某些场景下可以在人不用参与的情况下实现问题的自愈。
  5. 等级 4：故障预测，故障发生总会有损失，所以最好的情况是避免故障的发生，因此故障预测技术可以更好的来保证系统的可靠性，利用之前积累的一些故障先兆信息做到 “未卜先知”
  6. 等级 5：变更影响预测，我们知道绝大部分的故障都是由变更引起的，因此如果能够模拟出每个变更对系统带来的影响以及可能产生的问题，我们就能够提前评估出是否能够允许此次变更。

vivo统一告警平台建设与实践

阿里可观测性数据引擎的技术实践 统一存储引擎，统一分析引擎，数据编排。

监控的几个反模式

  1. 事后监控，没有把监控作为系统的核心功能
  2. 机械式监控，比如只监控cpu、内存等，程序出事了没报警。只监控http status=200，这样数据出错了也没有报警。
  3. 不够准确的监控
  4. 静态阈值，静态阈值几乎总是错误的，如果主机的CPU使用率超过80%就发出警报。这种检查 通常是不灵活的布尔逻辑或者一段时间内的静态阈值，它们通常会匹配特定的结果或范围，这种模式 没有考虑到大多数复杂系统的动态性。为了更好地监控，我们需要查看数据窗口，而不是静态的时间点。如何在实际场景中使用异常检测？阿里云Prometheus智能检测算子来了
  5. 不频繁的监控
  6. 缺少自动化或自服务

一个良好的监控系统 应该能提供 全局视角，从最高层（业务）依次（到os）展开。同时它应该是：内置于应用程序设计、开发和部署的生命周期中。

很多团队都是按部就班的搭建监控系统：一个常见的例子是监控每台主机上的 CPU、内存和磁盘，但不监控可以指示主机上应用程序是否正常运行的关键服务。如果应用程序在你 没有注意到的情况下发生故障，那么即使进行了监控，你也需要重新考虑正在监控的内容是否合理。根据服务价值设计自上而下（业务逻辑 ==> 应用程序 ==> 操作系统）的监控系统是一个很好的方式，这会帮助明确应用程 序中更有价值的部分，并优先监控这些内容，再从技术堆栈中依次向下推进。从业务逻辑和业务输出开始，向下到应用程序逻辑，最后到基础设施。这并不意味着你不需要收集基础设施或操作系统指标——它们在诊断和容量规划中很有帮助——但你不太可能使用这些来报告应用程序的价值。如果无法从业务指标开始，则可试着从靠近用户侧的地方开始监控。因为他们才是最终的客 户，他们的体验是推动业务发展的动力。PS：只要业务没事，底层os一定没事， 底层os没事，业务逻辑不一定没事，监控要尽量能够反应用户的体验。

Pull or Push？监控系统如何选型

报警哲学

一个好警报的关键是能够在正确的时间、以正确的理由和正确的速度发送，并在其中放入有 用的信息。警报方法中最常见的反模式：

  1. 发送过多的警报。比如故障的主机或服务上游会触发其下游的所有内容的警报。你应确保警报系统识别并抑制这些重复 的相邻警报。关注症状而不是原因（因为引发一个症状的原因有很多）。噪声警报会导致警报疲劳，最终警报会被忽略。修复警报不足比修复过度警报更容易。
  2. 警报的错误分类。比如应设置正确的警报优先级
  3. 发送无用的警报。警报应包括适当的上下文。可自愈的告警不该告警。

监控理念

devops基本理念：

  1. if you can’t measure it,you can’t improve it
  2. you build it,you run it, you monitor it. 谁开发，谁运维，谁监控

监控是分层次的， 以metric 为例

  1. 系统层，比如cpu、内存监控，面向运维人员
  2. 应用层，应用出错、请求延迟等，业务开发、框架开发人员
  3. 业务层，比如下了多少订单等，业务开发人员。蚂蚁指标系统的设计与实践

许式伟：信噪比高，有故障就报警，有报警就直指根因。

采用合适的精度：应该仔细设计度量指标的精确度，这涉及到监控的成本问题。例如，每秒收集 CPU 负载信息可能会产生一些有意思的数据，但是这种高频率收集、存储、分析可能成本很高。如果我们的监控目标需要高精度数据，但是却不需要极低的延迟，可以通过采样 + 汇总的方式降低成本。例如：将当前 CPU 利用率按秒记录。按 5% 粒度分组，将对应的 CPU 利用率计数 +1。将这些值每分钟汇总一次。这种方式使我们可以观测到短暂的 CPU 热点，但是又不需要为此付出高额成本进行收集和保留高精度数据。

将需要立即处理和可以第二天处理的报警规则区分一下。每个紧急状态的报警的处理都应该需要某种智力分析过程。如果某个报警只是需要一个固定的机械化动作，那么它就应该被自动化。

接警后的第一哲学，是尽快消除故障。找根因不是第一位的。如果故障原因未知，我们可以尽量地保留现场，方便故障消除后进行事故的根因分析。一般来说，有清晰的故障场景的监控报警，都应该有故障恢复的预案。而在那些故障原因不清晰的情况下，消除故障的最简方法是基于流量调度，它可以迅速把用户请求从故障域切走，同时保留了故障现场。

常见痛点及解决

基于海量日志和时序数据的质量建设最佳实践

  1. 质量观测的几个痛点：
    1. 海量的异构数据
    2. 依赖规则，缺乏智能
    3. 告警风暴与告警误报 无效告警优化实践总结 跟误告警说再见，Smart Metrics 帮你用算法配告警 被报警大量骚扰？来看看治理方法论 未读。
  2. 针对第一点，数据统一接入和管理，将这些异构的数据进行统一的存储和管理。将日志、指标、Trace等数据全部接入到一个统一的可观测性存储中。然后基于这个统一的存储，进行后续的查询分析、可视化、监控告警、AI 等上层能力，甚至还可以进行数据的加工和规整，一站式地完成异构数据到同构数据的转换过程。基于统一的存储，我们可以构建统一的查询和分析语法，从而一套语法适配不同的数据，并且让不同的数据之间进行联合查询也变成了可能。我们以标准 SQL 为基础，进行了部分 DSL 扩展和 SQL 函数扩展，并融合了 PromQL，从而让不同类型的数据查询和分析变得统一。
  3. 针对第一点， AntMonitor 总结 - 云原生 Prometheus 监控实践 AntMonitor是一款主要以日志方式采集监控数据的监控产品，Prometheus 是 metrics 监控的事实标准，需要将 Prometheus 的主要功能融合进了 AntMonitor 的现有架构
    1. AntMonitor 现有的数据链路大致为由 agent 采集日志数据缓存于内存，由 spark 计算集群从 agent 内存中拉取数据，进行聚合，存储于 CeresDB。 metrics 数据不同于日志数据，，可以跳过计算步骤，直接进行存储。因此，我们根据用户的业务需求，提供了两条数据链路：直接存储metric 源 == 拉取==> 采集agent ==> PushGateway ==> CeresDB存储；需要数据聚合的情况下，走基于 spark 的聚合数据采集。
    2. 日志数据均需要按照某些固定 schema（数据表结构）作切分清洗、计算聚合，但metric 必须由用户配置聚合规则，由于 metrics 数据本身就包含 schema 信息，我们通过自动化的配置项，自动对 Gauge、Counter、Histogram 等 metric type 自动为用户生成了部分聚合配置
    3. 原生 Prometheus 提供多种服务发现机制
    4. 原生 Prometheus 通过 relabeling 功能实现采集目标过滤等，还可以通过 metric relabeling 对拉取到的数据进行编辑。
    5. 存储时， CeresDB 针对这种数据量巨大的情景，按 label 标签进行了分区。 原生 Prometheus 提供了 Recording Rules (RR) 和 Alerting Rules (AR) 功能，将一些指标预计算并存储，方便日常查询。
    6. PromQL 查询数据时，会将查询按选定label维度拆分下推至所在 data 节点进行执行，再由每个 data 节点产出的结果，在 proxy 节点产出最终查询结果，返回至用户。
    7. AntMonitor 的可视化主要为日志监控设计，而社区普遍使用 grafana 来解决metrics监控的可视化问题
  4. 针对第二点，智能巡检。我们采用无监督学习算法，自动识别实体的数据特征，根据数据特征选取不同的算法组合，针对数据流实时建模，完成异常任务检测。并根据用户的打标信息（对告警进行确认或者误报反馈），训练监督模型，对算法进行不断优化，从而提高监控的准确率。目前异常检测我们使用了两种算法：
    1. 流式图算法，适用于一般性时间序列的异常检测场景，包括：机器级别的监控指标的异常巡检，例如CPU占用率、内存利用率、硬盘读写速率等。Time-Series Event Prediction with Evolutionary State Graph
    2. 流式分解算法，适用于对具有周期性的数据序列进行巡检，且要求数据的周期性较为明显。例如游戏的访问量、客户的订单量。RobustSTL: A Robust Seasonal-Trend Decomposition Algorithm for Long Time Series
  5. 针对第三点
    1. 告警智能降噪包含以下几种机制：自动去重；路由合并；告警抑制；告警静默。
    2. 动态分派。多渠道；动态通知；通知升级；值班和代班机制（报警报给值班人）

面对疾风吧，如何搭建高协同的精准告警体系？

  1. 「标准化告警处理流体系」的缺失
    1. 告警源数据缺乏统一标准以及统一维度的标签
    2. 缺乏全局视角的告警数据处理和富化，需要 对告警进行分解、提取和内容增强的工具。
  2. 组织协同处理告警难以落地
    1. 如何通过组织协同灵活处理告警？
    2. 如何避免组织隔离的复杂性灵活处理告警？ 解决
  3. 「标准化告警事件处理流」
    1. 借助告警平台灵活的编排组合能力以及丰富的处理动作，去快速处理多样化告警场景。PS： 也可以拖拖拽拽的编排一个告警的处理？
    2. 内容 CMDB 富化，打破信息孤岛。
    3. 通过 AI 内容识别，快速了解告警分布。报警关联。根据常见告警现象自带 20+ 规则，帮组用户快速压缩告警事件
  4. 「面向告警的组织协同」
    1. 联系人自助注册到告警系统
    2. 复用已有账号体系，避免在工作中使用多个账号系统
    3. 灵活的权限分配方式。
    4. 丰富的可扩展能力。基于钉钉建设的 ChatOps 能力

从 “香农熵” 到 “告警降噪” ，如何提升告警精度？

一文看懂业界在离线混部技术可观测性在分布式及云原生时代，遇到了以下障碍:

  1. 云原生的体系，决定了服务能力和服务规模随时都在动态调整，所以端上数据收集 、传输的成本大大增加，极端情况下甚至对服务本身性能造成侵扰。
  2. 可观测性输出要形成决策意义，需要基于一些维度进行归并、拟合、建模等操作，包括使用决策树到 AI 学习等一系列分析动作。在大服务体量和实时变动的背景下，可观测性输出的分析时延、准确性都面临很大挑战。
  3. 可观测性的可视化以及延展关联分析 (BI 报表等)，需要根据业务形态和需求进行深度定制，复杂性较高，缺乏直接能用的工具和手段。

工程

案例：vivo容器集群监控系统架构与实践

线上故障突突突？如何紧急诊断、排查与恢复 问题实例流量隔离（而不是杀死实例）、内存快照、Arthas UI化、耗时/报错与源代码关联，真是把“故障 1 分钟响应、5 分钟定位、10 分钟恢复” 给做透了。

如何借助Kindling一眼断定生产环境接口响应时间慢是磁盘性能问题引起的?很多公司愿意花高薪招聘资深开发，有很大一部分原因是花钱买他的经验，借助专家能力保障系统的稳定性和性能。但很多普通开发者从业经验深浅不一，我们不是专家，难道我们就只能吭哧吭哧敲CURD代码，一遇到生产故障就毫无头绪，只能找大佬吗？kindling程序摄像头的初衷就是，以标准化步骤，帮助所有开发实现分钟级定位全资源种类故障根因，降低专家门槛。

  1. 以标准化步骤
    1. 找：通过Trace系统，结合时间点，找出相关可能存在问题的关键Trace
    2. 查：通过关键Trace，查询其对应的Span信息
    3. 分析：分析Span信息中的何种指标与预期不符
  2. 大多数情况下，我们都是从故障结果反推过程然后排除各种可能性，最后得到根因。而Kindling程序摄像头以系统内核级别线程事件分析的角度，精准还原程序执行现场。它让我们从过程分析根因，“雁过留痕”，所有故障都会在程序执行过程中产生和正常情况下不同的痕迹，这3条标准步骤就是带我们找到这个痕迹，进而定位根因。
  3. 在以往排障过程中，我们需要在数据库、日志、终端、apm等排查工具来回切换，和运维协作，从海量的数据中筛选组织出有效的信息。这一过程是最耗时、最依赖个人经验的。而恰恰Kindling的程序摄像头技术就是帮开发&运维完成了这一过程，它基于eBPF技术融合了Tracing，logging，metrics。换句话说，它已经把该接口相关的所有数据（比如，mysql、redis等网络请求的连接信息和报文信息、日志、堆栈、锁信息、文件IO信息等等）都筛选捕捉出来，附着在对应的线程事件上。后续也会继续把接口执行时刻的网络指标（比如带宽、rtt等），CPU利用率，磁盘性能指标、内存利用率等等信息捕捉融合到Trace分析中，以实现全资源种类故障根因定位。PS：思维的主线就是：线程的trace，golang pprof、trace 也是在 线程上附着协程、函数名等信息。

AIOps 在小红书的探索与实践 未细读 能力框架

  1. 基础数据能力：为了能进行相关场景探索，基础数据需要提供Metric时序数据、Trace数据、Log数据、拓扑数据、事件数据、以及分析后的知识数据的快速存储和查询能力，为上游实时和离线计算提供数据支撑。
  2. 算法能力：算法能力层，主要解决三个层面的问题，一是根据场景提供响应的基础算法支持，异常检测算法、时序预测算法、分类算法、特征提取算法、因果分析算法、根因分析算法等；在基础算法的基础上，提供样本管理、流程编排、模型训练、模型评估和参数调优等构架模型的能力；有构建模型能力之后，根据运维场景和数据，把场景数据化，数据模型化，对故障管理、变更管理、资源管理输出能力
  3. 运维场景支撑：算法能力不是完全独立构建，而是根据运维场景和需求进行能力的扩展和补充。在故障管理中，主要会有故障发现、故障定位、预案推荐、风险巡检、影响分析、相似故障推荐、告警收敛、故障定级、故障自愈、故障预测、告警抑制等场景，会用到异常检测、时序预测、关联分析、根因分析、相似故障分析、日志模式识别、多维指标分析等算法能力；在变更管理中，主要会有变更检测、智能调度、智能变更、自动修复等场景，会用到单时序异常检测、多时序异常检测等，在资源管理中，主要会有配置推荐、成本优化、容量规划、预算规划、资源调度、性能调优等场景，会用到时序预测、服务画像等。
  4. 助力IasS/PasS：公司IaaS和PaaS层，支持着所有的业务线，而IaaS/PaaS层又包含着各自的专业领域知识和经验，要想整个AIOps体系较好的运转，需与IasS/PaaS层合作，提供已有AIOps能力和经验，加上IasS/PaaS自有的专业领域知识和经验，助力IaaS/PasS层智能化，从而达成整个服务生态的智能化。 可观测 AIOps 的智能监控和诊断实践 非常经典。

AIOps在美团的探索与实践——事件管理篇 未细看

阿里云可观测智能化探索——从智能告警到利用LLM实现自然语言转PromQL

如何利用 AI 算法解决告警配置三大难题？ 有没有合适工具，告诉小 A 应该对哪些指标配告警？有没有合适工具，给小 A 自动推荐合适的告警阈值？有没有合适工具，帮小 A 给起伏不定的指标配告警？

基于LLM的多场景智能运维传统AIOps算法大多依赖统计方法，异常检测&根因诊断大部分算法都依赖于数据的标注。专家的经验很难编码到模型里，而LLM基于检索增强的方式，极大地降低数据标注成本和重新训练的成本。在接入维护方面，传统AIOps当遇到新客户/私域知识/业务经验/数据变动等情况时，通常只能重新训练，而通过多Agent多方式，客户甚至可以将自己的逻辑经验轻松接入。对于未知的故障，由于没有训练过，传统AIOps算法无法推理，但是LLM通过通用知识的学习，可以进行一些简单的推断。最后就是在交互方面，LLM也极大地降低了交互成本，让用户更加易用。