36-云原生监控体系建设-秦晓辉云原生监控体系建设 秦晓辉 快猫星云 联合创始人 个人介绍 秦晓辉,常用网名龙渊秦五、UlricQin,山东人,12年 毕业自山东大学,10年经验一直是在运维研发相关方向, 是Open-Falcon、Nightingale、Categraf 等开源软件 的核心研发,快猫星云联合创始人,当前在创业,为客 户提供稳定性保障相关的产品 个人主页:https://ulricqin.github.io/ io/ 大纲 • 云原生之后监控需求的变化 • 从Kubernetes架构来看要监控的组件 • Kubernetes所在宿主的监控 • Kubernetes Node组件监控 • Kubernetes控制面组件监控 • Kubernetes资源对象的监控 • Pod内的业务应用的监控 • 业务应用依赖的中间件的监控 云原生之后监控需求的 变化 云原生之后监控需求的变化 •相比物理机虚拟机时 •原来使用资产视角管理监控对象的系统不再适用 •要么使用注册中心来自动发现,要么就是采集器和被监控对象通过sidecar模式捆绑一体 指标生命周期变短 •微服务的流行,要监控的服务数量大幅增长,是之前的指标数量十倍都不止 •广大研发工程师也更加重视可观测能力的建设,更愿意埋点 •各种采集器层出不穷,都是本着可采尽采的原则,一个中间件实例动辄采集几千个指标 指标数量大幅增长 •老一代监控系统更多的是关注机0 码力 | 32 页 | 3.27 MB | 6 月前3
25-云原生应用可观测性实践-向阳complexity © 2021, YUNSHAN Networks Technology Co., Ltd. All rights reserved. 业界动向 —— 云监控扛把子 Datadog 零侵入 == 全覆盖 == 监控入口 Datadog Universal Service Monitoring 要点: 1、Alerts and SLOs for every service 2、No code the growing complexity © 2021, YUNSHAN Networks Technology Co., Ltd. All rights reserved. 业界动向 —— 云厂商监控 阿里云ARMS 问题:依赖于eBPF,仅支持Kernel 4.15+、仅阿里云(K8s需托管) simplify the growing complexity © 2021, YUNSHAN 应用连接方式的变化 应用监控的变化 传统的方法: 开发人员埋点, 标准SDK/JavaAgent, 流量分光镜像。 云原生下的难题: 微服务迭代快, 侵入式监控效率低; 云网络虚拟化, 东西向流量监控难。 挑战/必要性:网络的动态性和复杂性,不监控流量谈何应用可观测 机遇/有效性:云网络连接API/函数,监控流量可零侵入实现应用可观测 è 云原生应用可观测“原力”,流量监控能力是机遇、基石 simplify0 码力 | 39 页 | 8.44 MB | 6 月前3
24-云原生中间件之道-高磊支持PB级数据存储 高并发: 千亿数据实时分析 数据源 设备监控 传感器 轨迹数据 车联网 业务集群 物联网套件写入 云原生 DB 轨迹查 询|实时 监测 MR 云原 生DB 统计 分析 物联网数据存储和查询 将车联网数据、设备监控数据、客流分析管控数据、交通数据、传感器数据实时 写入HBase中,分析结果输出到用户的监控前端系统展示,实现物联网数据的实时 监控分析。 优势 易接入: 轻松对接消息系统、流计算系统 少人为干预; • 提供更加灵活的卷大小配置能力。 2. 监控能力需求 • 多数存储服务在底层文件系统级别已经提供了监控能力,然后从云原生数据卷角度的监控能力仍需要加强,目前提供的PV监控数据维度较 少、监控力度较低; 具体需求: • 提供更细力度(目录)的监控能力; • 提供更多维度的监控指标:读写时延、读写频率、IO 分布等指标; 3. 性能要求 • 在大数据计算场景同时大量应用访问 集群管理能力的 Operator。其使用 CRD 方式来对 Ceph、Minio 等存储资源进 行部署和管理。 Ceph文件存储 MiniO对象存储 • Operator:实现自动启动存储集群,并监控存储守护进程,并确保存储 集群的健康; • Agent:在每个存储节点上运行,并部署一个 CSI / FlexVolume 插件, 和 Kubernetes 的存储卷控制框架进行集成。Agent 处理所有的存储操0 码力 | 22 页 | 4.39 MB | 6 月前3
构建统一的云原生应用 可观测性数据平台complexity. 数据打通并不简单 ② 应用、系统、网络的Metrics之间 例如:某个Service的Pod的QPS、IOPS、BPS分别是多少? 例如:Pod所在的KVM宿主机的CPU、内存指标? ② 看云网更清晰 Simplify the growing complexity. 数据打通并不简单 ③ Metrics与「非Aggregatable」的Log 例如:QPS降低与进程、服务器的日志有关联吗? =5000) 25 (Card.=10000) int LowCard 看云网更清晰 Simplify the growing complexity. 生产环境数据:Server端资源消耗<1% • 监控600+个K8s Node(~8000个POD),共600*16vCPU • 每秒写入1M Row(50MB字节),每行100~150 Column • Server端共6*16vCPU,总计CPU消耗<150%,总计Load<60 数据分析 解析 聚合 关联 压缩 零侵扰的采集与分析 发送 零侵扰的云原生应用可观测性 Flow 数据节点 云原生,水平扩展 监控数据 性能指标 调用日志 网络链路 由业务代码驱动的可观测性数据、云API数据 调用关系 知识图谱 链路追踪 黄金指标 关联 应用链路(Tracing) 应用日志(Logging) 应用链路 TraceID N F V 公 有 云 / 私 有0 码力 | 35 页 | 6.75 MB | 1 年前3
23-云原生观察性、自动化交付和 IaC 等之道-高磊驱动研发、发布 或者实施与自己 APP的集成。 • API作为产品,可 以给订阅、可以 被交易。 标准化能力-微服务PAAS-从监控到可观测-研发人员的第五感-1 知道 知道的 不知道 不知道的 主动性 被动性 监控 可观察 健康检查 告警 指标 日志 追踪 问题和根因 预警 监控&稳定性 分析&追踪&排错&探索 • 从稳定性目标出发,首先需要有提示应用出问题的手段 • 当提示出现问题后,就需要有定位问题位置的手段,进 拓扑流量图:是不是按预期运行 分布式跟踪:哪些调用 故障或者拖慢了系统 监控与告警: 主动告诉我 问题发生了! 微服务部署后就像个黑盒子,如何发现问题并在 远端运维是主要的课题,那么就需要从宏观告知 研发人员,并且提供日志、跟踪、问题根因分析 等工具进一步从微观帮助研发人员定位和解决问 题,这是这里在业务上的价值-稳定性赋能。 标准化能力-微服务PAAS-从监控到可观测-研发人员的第五感-2 可观察性是云原生特 可观察性是云原生特别关注的运维支撑能力,因为它的主动性,正符合云原生对碎片变化的稳定性保障的思想 数据的全面采集 数据的关联分析 统一监控视图与展现 Metric 是指在多个连 续的时间周期 内用于度量的 KPI数值 Tracing 通过TraceId来 标识记录并还 原发生一次分 布式调用的完 整过程和细节 Logging 通过日志记录 执行过程、代 码调试、错误 异常微观信息 数据之间存在很多关联,通过0 码力 | 24 页 | 5.96 MB | 6 月前3
基于Consul的多Beats接入管控与多ES搜索编排化、界面化、自动化的日志接入方案 5 案例:1000+业务10000+台 主机如何快速实现日志接入? 业务规模 1000+业务、 10000+业务主机、每天百T日志增量 日志需求 收集业务日志文件用于故障分析与告警监控 收集主机性能数据做容量分析 日志热数据保存七天 历史数据冷备一个月 其他诉求 日志上报不能影响核心业务 数据上报延时可感知 准备ES 安装Filebeat 编写Filebeat配置文件 测试并下发配置 准 • 快速接入(5min) • 配置UI化标准化 • 配置变更实时感知 • 部署全自动化 • 多Beats支持 • Beats运行时cpu/mem可控 • Agent监控视图 • 离线/容量/延时监控 • 分布式集群管理 • 异常快速定位 • 关联公司CMDB • 资源权限管理 • 配置灰度控制发布 • 配置一致性检测 • 日志覆盖率 12 案例:如何管控整个日志数据流相关资源性能与容量? 案例:如何管控整个日志数据流相关资源性能与容量? 资源限制 cgroup cpulimit 定时检测 kill nice值 beats优化 缓存设置 工作协程 设置 资源配额 调整 Agent运行时监控 日志延时分析 Beats cpu/mem管控 ES/kafka容量管理 日志覆盖率分析 13 案例:高并发写入场景下Beats与ES性能优化 日志上报是 否有延时? Filebeat资0 码力 | 23 页 | 6.65 MB | 1 年前3
01. MOSN 高性能网络扩展实践 - 王发康Request MOSN 做业务扩展 • 扩展非 xDS 服务发现 • 扩展 L4/L7 filter • 扩展 Xprotocol 支持 • Debug 及 Admin 管理 • Metrics 监控统计 Envoy 复用基础能力 • 复用高效 Eventloop 模型 • 复用 xDS 服务元数据通道 • 复用 L4/L7 filter • 复用 Cluster LB • 复用 State • Debug log • Request/Connection metrics MOSN(GoLang) • Admin API • Debug log • GoLang runtime 指标 Envoy 和 MOSN 交互层 • MOSN(GoLang) 侧执行时间统计 • 交互异常数统计 • GoLang 程序异常场景下的容灾处理 MoE 方案介绍 — 方案总结 研发 效能 Envoy 生态 拉通 • 实现多个社区技术共享,增强 Service Mesh、Dapr 等领域的 生态 性能 较高 MoE 运行效果 MoE 部署架构 MoE 为运行效果 MoE 相关指标 MoE 方案介绍 — 部署架构 A 机房 B 机房 C 机房 A 机房 DNS DNS B 机房 C 机房 D 机房 E 机房 A 机房 App B0 码力 | 29 页 | 2.80 MB | 1 年前3
02. Kubevela 以应用为中心的渐进式发布 - 孙健波经验才能开发 某游戏公司自定义workload Pinterest 构建一个渐进式发布能力需要解决哪些 问题? • 版本化 • 分批发布 • 滚动发布/原地发布 • 发布暂停 • 发布回滚 • 日志监控 • 健康检查 • 多版本部署 • 多版本流量灰度 • 多集群/多环境灰度 • … KubeVela 具备全部发布能力 的标准化应用管理引擎 KubeVela 简介 第二部分 What is Running Instances 注册 工作负载类型 运维特征 发布/部署 CRD 注册中心 KubeVela 的 Application 对象 镜像与启动参数 多组件 如何扩容 扩容指标,实例数范围 组件类型 可灵活扩展的其 他能力 • 一个完整的应用描述文件(以 应用为中心) • 灵活的“schema”(参数由 能力模板自由组合) • 放置于应用代码库中(gitops 其他封装 Trait 自身 CRD对象 使用方式 (json schema) 示例:上线新功能 metrics 平台研发团队: ● 开发了一个新 Operator 叫做 metrics(监控) ● 编写一个 K8s 能力描述文件 metrics.yaml 平台管理员: ● 执行 $ kubectl apply -f metrics.yaml 用户: ● 立刻就可以在 Application0 码力 | 26 页 | 9.20 MB | 1 年前3
中国移动磐舟DevSecOps平台云原生安全实践CODE DEPLOY OPERATE MONITOR RELEASE TEST BUILD DEV BUILD TIME OPS RUN TIME 上线即安全(安全左移)+ 自适应安全(持续监控&响应) SEC 安全需求 业务需求进来以后从五个维度对业务需求进行安全分析 威胁分析模型 威胁资源库 安全需求基线 威胁情报库 病例库 安全开发-安全需求分析 安全需求分析通过将安全策 程 安全测试-灰盒扫描IAST ① ① 灰盒审计与需求安全分析呼应,保障安全设计的落地 与CI/CD流水线集成,常态化检测,研发自行修复 IAST扫描结果提供DevSecOps常态化安全运营指标 通过将IAST集成到CI/CD流水线,在测试环境的构建过程中自动部署IAST检测逻辑,可以实现与功能测试同步进行的自动化 安全测试,给出漏洞的实际触发路径并提供实际可落地的修复建议。根据需求阶 检测维度丰富,包括漏洞、软件许可、恶 意文件、敏感信息等 • 策略可深度自定义 • 自动生成评分,对安全进行评级 • 提供整体修复建议 安全运营-容器入侵检测 未 知 威 胁 监 控 风险事件列表 容器内行为 实时监控 产生 告警处置 人工安全标记 响应处置 内置风险策略 木马病毒上传 恶意命令执行 容器逃逸 其他风险策略 已 知 威 胁 监 控 进程 网络连接 系统调用 文件 配置0 码力 | 22 页 | 5.47 MB | 1 年前3
27-云原生赋能 AIoT 和边缘计算、云形态以及成熟度模型之道-高磊coding,依旧是别人熬夜,你来拖拉拽,这不叫低代码,这叫劳动力外包。国内这类 伪低代码产品,靠着模板走量批发的模式。客户买的是人工,不是技术 • 低代码平台与企业技术 栈的融合能力成为一个 重要的考验指标 • 有的企业系统已经运行 了几十年,拥有自己的 UI 体系、数据库体系和 中台体系,完全更改是 不现实的,低代码平台 要做的是与这么多技术 融合,帮助企业更好地 改进。 • 降本增效是最初级的成 亿美元,去中心化云计算市场约100亿美元。未来,10 年到20年,去中心化云计算、云储存市场有望实现10年 100倍的增长,达到 的规模。 高级能力-精益化运维-云原生AIOps • 传统云原生的运维,虽然依赖于度量, 但是通过监控、日志分析、跟踪链等发 现问题根因所在周期长,依靠人的经验 (并且人的经验无法数据化沉淀),而 得到问题根因后,只能通过人工去修复 或者管理 • 而大数据或者基于监督的AI技术的成熟、 运维领域模型趋于完整、云原生底座也 等资源费用,包括BCC、CDS、EIP、BLB等。 这些资源将按照对应的云服务的计费标准单独计费,不会体现在PaaS的账单中。 • 在使用PaaS的过程中,为了保存您的应用元数据和状态信息、提供应用监控和日志采集、服务注册 和配置中心等功能,PaaS需要消耗公共的计算、存储和数据库等资源为您提供服务,因此PaaS将根据 您使用的工作空间的规格向您收取管理费用,直接体现在PaaS的账单中。 • 服务0 码力 | 20 页 | 5.17 MB | 6 月前3
共 17 条
- 1
- 2













