文具电子商务网站开发内容,哈尔滨网站备案手续,网站添加二级域名,优秀网站psd应用架构与可观测技术演进历程 在软件开发早期#xff0c;单体应用架构因其结构简单#xff0c;便于测试和部署#xff0c;得到了广泛的应用#xff0c;对应的监控诊断技术主要是基于日志和日志关键词的指标监控。随着软件复杂度的不断提升#xff0c;单体应用架构逐步向分…应用架构与可观测技术演进历程 在软件开发早期单体应用架构因其结构简单便于测试和部署得到了广泛的应用对应的监控诊断技术主要是基于日志和日志关键词的指标监控。随着软件复杂度的不断提升单体应用架构逐步向分布式和微服务的架构演进整体的调用环境也越来越复杂仅靠日志和指标渐渐难以快速定位复杂环境下的问题。 因此链路追踪技术应运而生。但早期的链路追踪技术和日志指标的结合比较简单更多的是在应用层以 APM 软件的形式存在。 随着云计算和云原生理念的普及从业务层到应用层容器和基础设施之间的边界不断地被打破研发、运维、安全等工种的职责也不断模糊因此对于全栈可观测的诉求也变得愈加强烈Traces、Metrics 和 Logs 的连接也愈发紧密。 一个典型的云原生架构及可观测诉求 典型的云原生架构往往是混合云的形态出于安全或容灾等方面的考虑可能会将一部分应用部署在公有云另一部分部署在自建机房。而出于软件研发效率和性能的考虑不同的应用又可能采用多种开发语言因此可观测诉求可以被归纳为以下四点 1、全栈立体化统一监控与告警比如可以将业务层的交易量、支付量的业务指标和应用黄金 3 指标、基础设施的 CPU 利用率以及网络情况放在一张大盘上做总体监控这也是大促期间较为常用的方式。 2、前后端/多语言全链路追踪用户请求从端上发起一直到网关再到后端的应用和云组件之间调用轨迹的追踪可以快速定位用户请求在哪里有异常。 3、跨云数据统一可视化将不同类型的数据、不同环境的数据进行统一可视化需要有较强的可视化组件。 4、开源格式数据二次加工出于业务自定义的需求需要有二次加工与分析。如果能够基于开源的数据格式标准很多工作实施起将会比较轻松也可以复用很多现有的东西。 为什么要基于 OPLG 构建统一可观测平台 而传统的监控诊断平台往往存在以下几个痛点 1、很多埋点插桩由用户自己实现这种闭源实现会导致数据格式不统一而且埋点在各个系统之间很难复用接入成本非常高。 2、Metrics 指标孤立地分散在各个监控的子系统比如有的在网络有的在应用有的在容器。排查全链路问题时对开发使用人员的经验要求非常高且效率非常低。 3、Traces 会由于埋点覆盖度不够或协议不统一而无法串联导致经常出现断连。 4、日志或链路数据的明细数据全量上报到服务端也会带非常高的成本而且查询率较低还会引发热点的性能瓶颈。 5、自建控制台的前端开发成本高开发周期长灵活性较差很难跟上业务迭代的效率。 6、各个系统的可观测数据之间缺乏统一的标签管理关联性较差很难做综合性的分析。 为了解决上述问题我们在生产环境中逐渐沉淀下较为可行的方案即基于 OPLG 建设统一可观测平台。此方案主要有以下几点优势 1、开源开放全开源技术栈借助社区共建合力比如可以借助 OpenTelemetry 的 Traces 埋点Prometheus指标的 Metrics Exporters 无需过多开发即可保障大部分通用组件数据的采集生成上报降低了接入成本。 2、统一目标开源且基于统一的一套规范可以很轻松地实现内部各个子系统甚至是和外部三方系统之间的打通和关联分析。 3、自由灵活基于 OPLG 特别是 Grafana 一些比较好的设计可以非常灵活地组织可观测数据能够灵活地定制每一个场景下需要的大盘图表满足自定义的需求。 4、边缘计算基于 OpeTelemetry Collector技术可以将数据处理“左移”到用户集群内。通过边缘计算的技术能够提前提炼数据价值并将提炼好的数据再发送到服务端降低公网传输的成本以及服务端的存储成本。 基于 OPLG 构建云原生可观测平台方案 OPLG 主要由以下四个模块构成 1、端侧数据生成与上报通过 OpenTelemetry 完成 Traces 数据的生成通过 Prometheus 完成指标类的数据通过 Loki 的方式完成日志采用。 2、边缘侧数据统一处理与路由所有数据采集完成之后可以通过 OpenTelemetry Collector 完成数据统一的边缘处理和路由转发。 3、全托管服务端能够提供更好的性能和更稳定的服务而且不会绑定技术栈迁移的自由度和灵活度高。 4、统一可视化可以通过 Grafana 完成统一的自定义灵活监控也可以采用云服务商比如 ARMS 在特定的精细化交互场景提供精细化的交互大盘提高查询体验。此外如若有自己的需求也可以通过开源的数据格式或开放的 OpenAPI 建设自己的控制台。 基于 OpenTelemetry Collector 实现统一数据采集与边缘计算 OpenTelemetry Collector 首先会完成统一的数据采集任何数据类型都可以进行数据采集然后做通用的处理比如格式化、数据的标签打标还可以进行一些指标的预聚合动作最常见的比如调用链可以根据 service IP 等粒度先将数据聚合再进行采样可以保证指标的精准度而且上传到服务端也可以降低成本。 OpenTelemetry Collector 还可提供本地存储的能力可以将一部分最近的数据先临时缓存然后进行比如最近 10 分钟的全量查询、错慢全采等可以更好地利用边缘的存储能力。 针对处理好的数据 OpenTelemetry Collector 提供了非常灵活的转发方式可以支持不同的协议比如 Prometheus 协议、OTLP 协议等也可以支持多数据源的转发可以发送到云服务端也可以转存到边缘存储更加灵活。 基于 ARMS 托管服务端提供快速、稳定的查询体验 基于 ARMS 的托管服务端针对海量的数据场景做了很多查询性能优化加速的技术比如通过算子下推的方式在 70% 以上的场景下查询性能相对于开源提升了 10 倍以上而针对 7-10 天等的长周期查询通过降采样技术又进一步地提升了一个数量级的查询性能针对 URL 等发散维度通过自动收敛的技术很好地解决了热点导致的查询卡顿问题针对链路数据做了对应用和 Traces ID 两级的路由扫描针对链路查询的使用特征做了相应的优化。 除了海量数据的查询性能优化外我们在 HA 侧也做了体系化的建设比如默认支持全球部署、多可用区的容灾避免了单个 region 或 AZ 不可用的风险其次业务经常会遇到突发的流量或用户快速增长如果是自建机房则需要考虑容量问题而使用 ARMS 可以根据流量自适应地做扩充无需担心突发流量带来的性能瓶颈极端情况下也可以通过动态配置下推或自动流控降级保障核心功能的可用性最后提供了全链路 SLA 监控和预警的建设有 7*24 小时的应急响应可及时发现可用性问题并快速恢复。 基于 GrafanaARMS 构建灵活、精细的可视化界面 此外基于 Grafana ARMS 提供了灵活、精细的可视化体验。 Grafana 丰富的仪表盘插件和广泛的数据源支持可以将各种数据都集成在一个大盘里。而且通过 PromQL、LogQL 等灵活的查询语法不需要前端介入。后端的研发测试SRE 等可以通过低代码的形式快速构建自己的场景大盘提升可观测的效率。 得益于 Grafana 的开源属性如果想从自建机房迁移到云上或在云之间互相迁移整个可视化平台都能够通过 JSON 文件或其他方式快速拷贝轻松完成端到端的迁移不会被特定的厂商强绑定。 但是 Grafana 也存在缺陷比如它在交互场景的体验不够好因此 ARMS 在调用链的关联分析、在线诊断、配置管理等强交互的场景提供了更精细化的交互页面。ARMS 还会进一步增强 Grafana 的图表插件提供新的图表插件以提升托管版 Grafana 的可视化能力。 Demo 演示 1如何基于 OpenTemeletry 和 ARMS 实现全链路的追踪和应用诊断 进入 ARMS 控制台-接入中心找到 OpenTelemetry 的接入方式也可以选择其他的接入方式。以 Java 应用为例可以通过 OT Java Aagent 生成数据然后修改启动参数比如接入点或鉴权的 token 。 除了直接上报也可以通过 OT Collector 完成数据转发实现无损统计只需要将 endpoint 改成本地服务。 安装完成后即可通过 ARMS 提供的 Traces Explorer 页面进行调用链的分析。 调用链的分析是强交互场景比如可以通过左侧的快捷筛选快速过滤出异常调用链路然后选择其中一条链路查看端到端的全链路轨迹。 ARMS 在 Java 场景针对接口粒度做了更详细的本地方法埋点能够更好地定位根因。上图右侧可以看到当前 span 相关的附加信息包括 JVM 和主机的监控指标。 与 span 相关的应用日志也能很快速地集成排查业务问题可以结合日志更好地定位。 Traces Explorer 除了调用链的查询外也可以做实时的动态分析。比如可以查看异常链路是否集中在某特定 IP 是否存在单机故障的可能性或是否集中在特定的接口。也可以将很多调用链进行全链路的聚合多条链路可以看到每一个分支的情况也可以看到应用维度更直观的拓扑。 此外ARMS 还针对 Java 提供了较好的交互图表。除了 JVM 监控、主机监控外还包括容器的 Pod 监控、线程池监控等。业务高峰期很容易出现数据库连接池打满等情况以往此类问题难以排查.但有了池化监控即可一眼定位到问题所在。通过上下游的分析能够很轻松地获知当前应用调用方的情况。 在数据库调用里可以看到 SQL 的明细统计以及缓存的操作情况。 ARMS 还提供了高阶的诊断能力比如线程分析可以针对每一类线程池观察线程消耗的 CPU 、耗时以及线程数也可以查看方法栈。 针对 Java 应用的疑难问题可以通过白屏化的 Arthas 诊断实时抓取捕获 JVM 运行态的数据比如查看方法调用的轨迹、参数。 除此之外还可将 APM 的指标数据写到 Prometheus通过 Grafana 做展示。用户可以通过 PromQL 定制自己想要的 APM 大盘可以将 APM 数据和其他指标数据比如业务、基础设施、云组件、数据库服务端、容器等放在一起定制自己的大盘形态。 Demo 演示 2:如何基于 Prometheus 和 Grafana 做统一的监控和告警 首先在接入中心选择要接入的组件有 MySQL 、Redis 、ES 等默认支持阿里云上的很多组件。 以 MySQL 为例首先选择要接入的实例填写 exporter 名称选择地址再写入用户密码此处也可以查看当前 exporter 采集的指标。 如果实例未接入可以选择新建实例。比如针对 ECS 环境或自建机房可以通过下载 ARMS 提供的 helm 安装 Prometheus Agent 也可以通过 Remote Write 的方式直接上报数据。如果希望将多个地域的数据源放在一起查看也可以通过 Global View 全局接口实例将多个数据进行统一展示。 进入集成中心后可以看到当前实例已经安装的组件可以查看组件采集的指标可以更精细化地选择哪些指标需要采集哪些不需要。 大盘列表里ARMS 提供了非常多预置的 Grafana 大盘比如 K8s 的总览视图或 node 详情视图可以查看当前节点各种状态用户也可以基于视图自己编辑新的图表。 因为数据都写到 Prometheus所以告警也可以基于 PromQL 扩展。我们提供了很多默认的告警模板比如节点的 CPU 使用率等。除了可以定制告警内容还可以选择通知策略比如不同的告警发给不同的值班人员。 Grafana ARMS 提供了两种类型的 Grafana分别是共享版本和托管的独占版本。我们更推荐开通独占的托管版本可以做自定义的账号管理也可以得到更好的可用性和安全性保障。 Demo 演示 3基于 Loki 的日志查询分析 由于 ARMS 目前还没有提供商业化的 Loki 服务因此本文将以官网的 Grafana 示例演示 Loki 的接入效果。 完成日志接入之后可以基于 Loki 提供的 LokiQL 快速过滤。它还针对关键的索引字段建立了索引基于这些字段可以进一步提升检索速度。 基于 Loki 可以定制形态较为丰富的图表。上图为官网提供的 Loki Nginx 大盘统计的数值或地域的分布等都可以通过 LogQL 定制非常灵活。 Demo 演示 4基于 RASP 的应用安全防护 危险组件检测应用接入 RUSP 之后可以自动根据 cve 标准扫描出当前应用是否存在危险组件能够快速提示应用当前可能存在的风险。 可以查看实例详情和漏洞详情包括具体的漏洞描述以及相应的修复方案根据这个修复方案即可完成漏洞修复。 除了已知的危险组件也可以基于还未上报或特有的组件做全量组件自查。 应用安全的攻击防护遭到恶意攻击后系统能够自动识别出当前存在的恶意攻击行为且可以看到攻击发生在哪个节点以及请求的参数和调用攻击的堆栈情况。 除了攻击识别外还可以做主动防护将防护模式从监控设置为监控并阻断。 修改防护模式后针对最新的攻击行为平台不只进行监控还能够将它直接阻断不影响业务的具体逻辑。同时抛出异常提示当前风险行为已经被阻断。 Demo 演示 5ARMS 提供的用户体验监控 在接入中心可以针对不同类型的端侧设备进行监控。以 web 端为例可以新建站点选择相应的配置然后通过 CDN 或 NPM 包的方式完成接入。 接入完成后可查看当前控制台 PV、UV 以及 API 的请求成功率并且可以看到请求分布在哪些地理位置、运营商或浏览器。 比如新开发了功能页面可以查看页面 top 20 用户访问的情况也可以选择具体的用户通过会话追踪查看用户如何使用此产品能够更好地观测用户行为。 应用前端监控还可以与拨测结合使用可以通过拨测模拟真实的用户行为对网站质量、网页性能、文件下载或 API 的性能做模拟提前发现问题先于用户感知到可能存在的风险。发现可用性出现异常后可以针对不同的站点自动发送通知。 上图为已创建的 demo 任务可以观测到网站的时延、丢包率以及每一次拨测的状态和结果并且通过多维的报告查看问题聚焦在哪些地区等。 虽然 OPLG 并不能覆盖所有可观测领域但它为可观测提供了非常良好的底座和规范。在这套体系的基础之上可以不断地将其他可观测技术或产品能力集成进来满足各种场景的可观测诉求从而应对愈加复杂多变的环境带来的挑战。 云原生时代可观测技术的趋势与技术选型 云原生时代的可观测技术在软件架构层面会更多地向分布式云和混合云的方向发展。同时容器化、微服务、 DevOps 甚至 DevSecOps 也将逐渐成为主流。 可观测技术趋势包括以下几个方面 1、标准逐渐成型收敛。技术栈会向 OpenTelemetry、Prometheus 等方向收敛。而基于更加标准的数据自动化的成本将会更低效率将会更高。分层之间的监控边界被打破之后监控立体化也将愈发成熟。 2、基于 eBPF 的网络和内核的无侵入探测带来更多观测技术的可能性。 3、去中心化趋势。首先数据去中心化比如基于 OpenTelemetry Collector 可以将很多可观测的预处理左移到用户集群内降低中心化服务端的压力。其次协同去中心化不仅可以在统一的控制台查看可观测数据也可以在即时通讯软件比如钉钉完成整个协作的过程。 原文链接 本文为阿里云原创内容未经允许不得转载。