应用场景
应用场景1：容器监控
业务痛点
Prometheus是容器场景的最佳监控工具，但自建Prometheus对于运维人力有限的中小型企业而言，成本太高。对于业务发展快速的大企业又容易出现性能瓶颈。因而使用云上托管Prometheus已成为越来越多上云企业的第一选择。
解决方案
AOM兼容开源Prometheus生态，提供全托管Prometheus实例，联合CCE服务提供监控中心，可实时监控应用及资源，采集各项指标及事件等数据以分析应用健康状态，提供全面、清晰、多维度数据可视化能力，兼容主流开源组件，并提供快捷故障定位的能力。优势如下：
- 监控中心深度整合云原生基金会（CNCF）的监控项目Prometheus。对关键指标、事件等运维数据进行统一采集、存储和可视化展现，精心打造云原生应用的良好可观测性能力。
- 将云原生基础设施监控和应用负载监控进行关联，提供全栈监控，使用户能够随时随地清晰地感知基础设施和应用负载状态。
- 能够对Kubernetes集群、节点、容器组（Pod）等进行详细监控，对业务提供端到端追踪和可视化，提供集群健康诊断能力，大大缩短问题分析定位时间。
- 提供开箱即用的插件安装、数据采集、云原生监控能力，相比基于开源组件构建的监控能力，在可靠性、高可用、安装部署便捷性上更具有竞争力，能够更好地为您的云原生应用保驾护航。
- 提供了轻量化的指标采集插件，和社区Prometheus相比，资源使用量大大降低，部署模式方便快捷。
应用场景2：应用运维
业务痛点
分布式微服务架构下的应用，虽然丰富多样且开发效率高，但是给传统运维诊断技术带来了巨大挑战。以电商为例，主要遇到如下问题：
- 告警太多，关键信息被淹没
大量告警同时出现，会使真正重要的告警信息被众多无效或低优先级的告警所淹没。运维人员在面对海量告警时，难以快速甄别出关键问题，导致无法及时处理影响业务正常运行的紧急故障，从而延误故障修复时间，扩大故障影响范围。
- 定位问题时间长
客服人员接到用户反馈商品购买出现问题后，会交由技术人员排查解决。而微服务分布式架构中的一个业务请求通常要经过多个服务/节点后返回结果。一旦请求出现错误，往往要在多台机器上反复翻看日志才能初步定位问题，对简单问题的排查也常常涉及多个团队。
- 系统多，缺乏统一运维策略
业务系统100+个，运维数据分散（Log/Metric/Trace）在不同的业务、基础设施和云服务上，缺少统一的平台进行数据的统一采集、统一搜索分析、统一告警。
- 架构梳理难
在业务逻辑变得逐渐复杂以后，很难从代码层面去梳理某个应用依赖了哪些下游服务（数据库、HTTP API、缓存），以及被哪些外部调用所依赖。业务逻辑的梳理、架构的治理和容量的规划（例如：某活动的准备过程中，需要为每个应用准备多少台机器）也变得更加困难。
解决方案
AOM作为统一可观测平台，融合CES/APM/LTS提供指标、链路、日志的关联分析能力。指标以量化的形式呈现系统的关键性能数据，如 CPU使用率、响应时间等，能帮助运维人员快速了解系统的整体运行状态，通过对指标的实时监测和分析，可及时发现性能异常趋势。链路追踪则聚焦于请求在系统各组件间的流转路径，清晰展现数据流向和服务调用关系，当性能指标出现异常时，借助链路追踪能够精准定位到具体的服务或组件，找出导致问题的根源所在。日志记录了系统运行过程中的详细事件信息，包括错误堆栈、业务操作细节等，在链路追踪定位到问题组件后，通过查看相应的日志，可以获取更丰富的上下文信息，进一步深入分析问题产生的具体原因，为解决问题提供详细依据。指标、链路和日志三者相辅相成，指标用于宏观监测，链路用于定位问题范围，日志用于深入剖析问题，共同助力打造一个高度可观测的系统环境。
- 统一数据接入：提供全场景数据接入能力，支持业务层（安卓/IOS/WEB等）、组件层（JAVA/GO等多语言）、中间件层（Redis/Mysql等）、运行环境层（ECS/K8s等）、云服务层、API和开源协议（OpenTelemetry/Kafka等）各种方式接入指标、链路、日志数据。
- 统一监控告警：提供指标、日志统一告警规则管理，统一告警模板管理，统一告警通知对象管理，预置100+告警模板，支持告警分组/抑制/静默等多种降噪方式，支持自定义消息模板和多种通知渠道（邮件/短信/语音/企业微信/钉钉/飞书/Webhook）。
- 统一可视化大盘：支持自定义可视化大盘，提供表格、折线图、饼图、地图等多种可视化图表，预置30+开箱即用仪表盘，用户可以添加自定义变量和过滤器筛选数据，方便对指标/日志数据进行可视化运营分析。
- 可视化拓扑和链路追踪：应用拓扑自发现，异常应用实例无处躲藏，发现异常应用后，通过调用链一键下钻，代码问题根因清晰可见。
- 慢SQL分析：提供数据库、SQL语句的调用次数、响应时间、错误次数等关键指标视图，支持异常SQL语句导致的数据库性能问题分析。
- 百亿级日志秒搜：提供高性能日志搜索引擎，存算分离架构，多租户共享海量弹性计算资源，实现百亿级日志秒级返回搜索结果。
应用场景3：安全合规
业务痛点
大型企业的每个业务部门都有独立的云账户实现资源隔离，每个业务部门的运维人员需要依赖日志监控告警实现故障定位分析，同时集团安全部门需要统一监控日志，因此多账号的统一日志管理成为企业痛点：
- 分业务独立运维：客户每个业务模块都有一个独立的账号做资源隔离，依赖日志服务配置监控告警，快速分析发现故障并定位根因。
- 安全部门统一监控日志：客户使用多账号管理体系，每个业务部门有一个独立的账号，安全部门需要汇聚所有日志到一个账号，并存储180天以上来满足法规要求。
解决方案
AOM作为统一可观测平台，融合云日志服务LTS可以实现：
- 多账号独立管理：每个账号独立采集各自业务的应用日志、云服务日志，资源互相隔离、权限划分清晰；借助日志告警配置，90%问题定位控制在10分钟。
- 日志数据跨账号集中汇聚：使用多账号日志汇聚功能，将各个子账号的日志复制一份到统一监控账号，长期存储180天，便于安全部门集中审计，满足网络安全法规要求。
提供解决方案参考如下图，可以实现统一收集云服务、应用程序日志，支持保存180天以上，满足《网络安全法》、《GDPR》等法律法规要求。
应用场景4：运营分析
业务痛点
企业在日常经营中，可以上报各种业务日志或指标（例如移动端），经过规整、过滤、脱敏、富化等加工处理后，可以融合大数据平台、BI工具进行业务分析，例如获取页面的PV、UV、用户停留时间、交易金额等，用于了解业务运营状况、分析用户行为特征，基于实时的数据分析反馈调整业务决策，提升用户体验，提升经营效率，实现企业的数字化转型。
在业务分析过程中经常遇到如下痛点：
- 移动端数据难采集：难以快速采集多种移动端设备，例如Web浏览器、IOS、安卓、百度小程序、微信小程序、钉钉小程序、快应用等多类端侧日志/指标无法快速采集。
- 数据传输不可靠：移动端日志/指标数据量多且频繁，传输速度慢，也极易出现丢失，对业务分析造成一定影响。
- 数据处理不方便：原始数据不方便处理，不方便快速与大数据平台实现对接。
解决方案
AOM作为统一可观测平台，融合APM/LTS提供多种移动端日志/指标采集能力，借助大数据平台完成业务运营分析，可以实现：
- 端侧日志全面采集接入：提供多种移动端SDK，实现了缓存发送、异常重试、批量发送等稳定功能，用户快速集成即可全面采集移动端日志或指标。
- 秒级上报，高可靠：端侧采集日志或指标后，经传输链路秒级完成上报，数据无丢失，支撑业务做完整性分析。
- 可视化仪表盘：支持自定义可视化大盘，提供表格、折线图、饼图、地图等多种可视化图表，用户可以添加自定义变量和过滤器筛选数据，实现可视化运营分析。
- 数据开放给大数据平台：如果用户需要对原始数据做复杂的处理，支持将指标转储到DMS（KAFKA），日志可转储到OBS/DLI/DWS；用户在大数据平台完成数据处理后，可以对接BI系统做可视化呈现。
提供解决方案参考如下图，可以对日志结构化解析，基于SQL语法分析日志，PromQL语法分析指标，生成可视化图表，并结合大数据平台帮助企业进一步挖掘数据价值，助力企业数字化转型。
应用场景5：用户体验提升
业务痛点
在用户体验至上的互联网时代，即使后台业务稳定运行，仍然无法获悉用户访问系统时的具体情况，因而定位线上用户偶现的前端问题变得非常困难。一个系统上线之后，访问时的大量报错导致用户无法正常使用，如果APM无法及时获知，就会导致流失大量用户。
解决方案
AOM作为统一可观测平台，融合APM提供用户体验监控能力，实时分析应用事务从用户请求、服务器到数据库，再到服务器、用户请求的完整过程，实时感知用户对应用的满意度，帮助您全面了解用户体验状况。对于用户体验差的事务，通过拓扑和调用链完成事务问题定位。
- 通过前端性能监控，提供页面的性能、JS错误请求、API请求、服务的运营相关指标（PV/UV)情况，实时了解并追踪应用性能情况。
- 通过用户会话追踪，定位使用过程中影响用户体验的慢请求、慢加载、慢交互等问题，实时了解用户使用情况。
- 通过页面加载性能分析，提供多维度页面的首屏时间、白屏时间、可交互时间等页面加载指标数据，全面还原用户的体验感受，定位访问慢的原因。
