跨云可观测这么建：一套架构，成本砍 87%

2026-04-06 6 纸飞机账号购买

客户诉求1.1 多云日志统一分析

在多云场景之中，其常见的形态呈现为，海外边缘的安全以及访问能力是由Cloudflare来承担的（涵盖WAF/CDN/Access），详细的日志借助Logpush统一落在AWS S3那里做低成本的归档还有合规留存；与此同时，总部的核心业务以及可观测体系常常已经在阿里云一侧运行了（像是应用/网关/业务日志进入SLS，告警与值班/工单体系也依据阿里云一侧来建设）。其结果便是，针对同一条用户请求，以及同一次攻击，还有同一次发布变更所形成的“证据链”，分别分布于 AWS 与阿里云两边，在一个平台内部难以达成统一检索，也难以进行关联分析，更难以实现闭环处置。

针对平台工程团队来讲，这当前情形致使的关键矛盾并非是“日志存放于何处”，而绝对是“分析以及运营行为在哪个地方达成闭环”。

1.2 降本与简化运维

若将 S3 用作日志存储，欲使数据得以“运用”（涵盖查询分析、可视化、告警联动等方面），通常而言还需额外的查询组件、ETL 组件，以及指标与告警组件协同配合，如此一来链路会变长，配置以及排障需跨越多个系统，进而运维复杂度会显著上升。

假设要将数据径直接入CloudWatch，那么采用CloudWatch Logs来进行采集以及存储，运用Logs Insights去做查询分析，借助Dashboards/Alarms来打造仪表盘以及告警闭环，整体成本常常是颇高的。

SLS 解决方案

紧接着，会一步一步地进行拆解，去介绍这一整套 SLS 解决方案里的数据导入功能，数据加工功能，数据查询分析功能，仪表盘展示功能，以及告警功能。

2.1 从 S3 将数据导入 SLS

于不少人眼中，数据导入难道不就是那“读取，传输，写入”这简单的三板斧么？然而当你所面对的竟是：

你会发现，这绝非一个简单的“复制粘贴”操作。

随后，会先将实际导入进程里碰到的难点阐释明晰，接着，把相对应的落地实行办法予以说明：

挑战一，海量小文件要做到“实时发现”并非易事，其中存在全量遍历与实时性的考量，还有增量遍历与完整性的权衡。

S3的ListObjects仅支持依照字典序展开遍历，并不支持“按照时间进行过滤”。在bucket/目录的历史文件数量非常庞大的时候，完成全量扫描一次或许会耗费很长时间；然而仅仅开展增量扫描又有可能因为文件名呈现乱序状态而导致遗漏文件。

其后果表现为，有可能新文件没能即刻被发现，而是出现延迟升高的状况，又或是在极端情景下会有所遗失，进而产生完整性方面的风险。

挑战二：吞吐得能够跟得上峰值，然而绝不能依靠“人工调参”（流量突发进而加上长尾拖累），挑战三：格式呈现为“混合大礼包”（压缩格式能够被识别，可是数据格式没办法自动去猜），挑战四：正确性需要可以进行交付（不会丢失数据、能够被补偿、能够定位到“究竟是哪个文件遭遇了问题”）

针对这些难点我们的设计方案：

对比维度双模式遍历SQS 事件驱动

新文件发现实时性

分钟级

秒级

配置复杂度

简单，无需额外配置

需配置 S3 事件通知和 SQS

可靠性

高（全量兜底）

依赖 SQS 可靠性

成本

仅 S3 API 调用

额外 SQS 费用

适用场景

标准日志导入

高实时性、文件名不规则

设计要点之四：点位以及状态的管理，加上重试还有隔离，再加上文件级别的追踪，使得“补数”能够得以落地实现。

2.2 一站式数据分析

被导入的数据仅仅是起始的第一个步骤，而完整的、具备可观测特性的闭合环路，还需要针对数据展开治理工作，进行交互式查询行为，实现可视化的展示效果以及具备智能告警功能。SLS把这些相关能力整合于统一的平台之上，以下对各环节所拥有的核心原理予以介绍。

数据加工：全托管流式 ETL

SLS数据加工是基于托管的实时消费任务，借助SPL语法来对日志开展流式处理，它具备全托管免运维的特性，拥有弹性伸缩能力，数据能在秒级呈现，还支持按行调试以及代码提示。

SLS 于日志 Pipeline 之上，将 SPL 引擎用作内核，此内核具备列式计算优势，拥有 SIMD 加速优势，是以 C++ 语言实现的优势。基于 SPL 引擎构建分布式架构时，我们重新设计了弹性机制，该机制并非只是存在于通常意义里按实例（K8s Pod 或是服务 CU）粒度的伸缩情况，而是能够按照 DataBlock 粒度（MB 级别）实现快速弹性。

场景能力：

查询分析：高性能引擎，秒级响应

高性能查询引擎由 SLS 提供，其支持索引模式，索引模式具备秒级响应百亿级数据的特性，同时也支持扫描模式，扫描模式用于轻量级分析。查询直接对索引起作用，不需要预建数据集，也不存在刷新延迟的情况。面临超大规模数据分析场景时，SLS 会提供 SQL 独享版，此版本涵盖SQL 增强和 SQL 完全精确两种模式。

查询引擎与能力：

仪表盘：丰富可视化，开箱即用

日志服务所提供的数据可视化工具是SLS仪表盘，它会把查询分析结果借助图形化界面去展示，仪表盘一般含有多个统计图表，这些统计图会对关键性能指标、重要数据以及分析结果进行汇总且呈现。

可视化能力：

告警：一站式智能运维平台

SLS告警乃是具备一站式告警监控、降噪、事务管理以及通知分派功能的智能运维平台，它是由告警监控、告警管理、通知（行动）管理这些子系统所构成的。当接入日志或者时序数据之后，在数分钟以内就能够创建监控任务、通知渠道以及告警策略。

功能优势：

2.运维进行简化，采用一体化来替代多产品组合，2.3.1提到AWS多产品组合，那么为了达成同样的闭环，通常需要哪些组件呢。

组件数量多，这并不必然就不好，然而，当你所具有的诉求乃是做到“统一口径”，做到 “分钟级闭环”，做到“低成本可控”的时候，多组件进而就意味着：

2.3.2 SLS 一体化 vs AWS 多产品组合

将“导入、加工、索引、查询、仪表盘、告警/事务”于 SLS 之内铸造成一个能被复用的工程模板，拿此模板提供首版交付，经策略去迭代成本以及效果。

出海企业日志分析架构升级案例背景与解决方案

有一家规模很大的、走向全球进行出海经营的企业，它的业务范围涵盖了欧洲、亚太以及北美等好多不同的区域，借助主流的CDN以及安全服务达成了全球范围内的访问加速以及Web应用防护。为了能够满足海外的数据合规还有审计方面的要求这个企业把它的安全以及访问日志凭借平台原有的日志推送能力也就是Logpush持续不断地归档到公有云对象存储当中，以此来用于长期的留存以及后续的分析。

此刻于 AWS 之上，借由多组件组合达成海外日志的分析跟监控，碰到了如下这般的问题：

除此之外，ETL要依靠Glue/Lambda，还得自己去维护，QuickSight进行可视化，需要另外授权，并且存在着同步延迟的情况，CloudWatch Alarms的配置比较分散，缺少统一的降噪能力，多种产品组合在一起，导致运维的复杂度很高，成本也无法控制等一系列问题。

基于阿里云 SLS 构建统一的可观测分析平台，实现：

3.1 数据链路

数据借助Cloudflare Logpush推送送往AWS S3海外各个Region进行归档，SLS凭借事件驱动或者定时扫描导入同一地域的Logstore，经过SPL加工之后汇聚到国内中心Logstore，以此支撑统一的查询分析、仪表盘以及告警。

3.1.1 SPL 数据加工示例

示例原始日志（Cloudflare WAF 日志）

Cloudflare WAF的原始日志示例，当中含有ClientIP、SecurityAction、SecuritySources等敏感以及安全字段，涵盖block/allow/challenge这三种安全动作场景，这些日志能够直接用以测试SPL加工语句。

{
  "EdgeStartTimestamp": "2024-12-25T10:30:00Z",
  "RayID": "abc123def456",
  "ClientIP": "203.0.113.50",
  "OriginIP": "10.0.0.100",
  "ClientRequestURI": "/api/v1/users?id=123",
  "ClientRequestMethod": "POST",
  "ClientRequestReferer": null,
  "SecurityAction": "block",
  "SecurityRuleID": "rule_001",
  "SecuritySources": "[{\"source\":\"waf\",\"action\":\"block\"}]",
  "OriginResponseStatus": 200,
  "OriginResponseTime": 150,
  "ResponseHeaders": "{\"x-cache\":\"MISS\"}"
}

海外侧完成数据治理，其中包括时间标准化，是关于IP转Geo地理信息，还涉及IP脱敏变成匿名指纹，以及安全元数据解析与风险标签化。最终借助project - away移除ClientIP、OriginIP等敏感字段，仅保留黄金字段用于跨境传输。

-- 核心追踪与时间标准化
* 
| extend __time__ = cast(to_unixtime(date_parse(EdgeStartTimestamp, '%Y-%m-%dT%H:%i:%SZ')) as bigint)
| extend RequestId = RayID
| extend RequestPath = url_extract_path(ClientRequestURI)
-- IP -> Geo（在海外完成）
| extend
    GeoCountry = ip_to_country(ClientIP),
    GeoRegion  = ip_to_province(ClientIP),
    GeoCity    = ip_to_city(ClientIP)
-- IP 脱敏：保留匿名指纹（可选），不跨境携带原始 IP
| extend ClientFingerprint = to_base64(sha256(to_utf8(ClientIP)))
-- 安全元数据解析/标签化
| expand-values -keep SecuritySources
| parse-json -prefix='Security' SecuritySources
| extend IsHighRisk = if(ClientRequestMethod = 'POST' and (ClientRequestReferer is null or SecurityAction = 'block'), 1, 0)
-- 最终降噪与字段投影
| project-away ClientIP, OriginIP, ResponseHeaders, RayID

加工后示例数据

加工完成的数据，已然达成了Geo富化，同样完成了IP脱敏，又实现了风险标签化，并且敏感字段给移除掉了，能直接用以供下游进行查询分析以及告警：

{
    "RequestPath": "/api/v1/users",
    "__time__": "1735122600",
    "RequestId": "abc123def456",
    "ClientFingerprint": "O1zTaFfLyH1ZqEHS03UiLSNMzwMX+4ZW7OsIVsDGgEg=",
    "OriginResponseTime": "150",
    "GeoCity": "理查森",
    "ClientRequestURI": "/api/v1/users?id=123",
    "IsHighRisk": "1",
    "EdgeStartTimestamp": "2024-12-25T10:30:00Z",
    "SecurityAction": "block",
    "SecurityRuleID": "rule_001",
    "Securityaction": "block",
    "GeoCountry": "美国",
    "GeoRegion": "德克萨斯州",
    "OriginResponseStatus": "200",
    "Securitysource": "waf",
    "ClientRequestMethod": "POST"
}

3.1.2 查询分析示例

WAF规则命中情况进行统计，按照规则，归集命中的次数，计算高风险所占的比例，统计独立攻击者的数量。

* | SELECT 
  SecurityRuleID,
  count(*) AS TotalHits,
  count_if(IsHighRisk = 1) AS HighRiskHits,
  approx_distinct(ClientFingerprint) AS UniqueClients
FROM log
WHERE SecurityRuleID IS NOT NULL AND SecurityRuleID <> ''
GROUP BY SecurityRuleID 
ORDER BY TotalHits DESC

攻击源地域排位在前十位的情况，是按照国家和城市来进行聚合，从而得出拦截的次数以及独立攻击者的数量。

* | SELECT 
  GeoCountry,
  GeoCity,
  count(*) AS AttackCount,
  approx_distinct(ClientFingerprint) AS UniqueAttackers
FROM log
WHERE SecurityAction = 'block'
GROUP BY GeoCountry, GeoCity
ORDER BY AttackCount DESC
LIMIT 10

示例 3：源站 5xx 的错误趋势是，要这般操作，即依照分钟去聚合错误的次数，还有错误率以及总的请求量。

* | SELECT 
  time_series(__time__, '1m', '%Y-%m-%d %H:%i:%s', '0') AS TimeBucket,
  count_if(OriginResponseStatus >= 500) AS Origin5xxCount,
  count_if(OriginResponseStatus >= 500) * 100.0 / count(*) AS Origin5xxRate,
  count(*) AS TotalRequests
FROM log
GROUP BY TimeBucket
ORDER BY TimeBucket

示例 4：针对请求延迟进行分位分析，此分析是按照路径来聚合 P50、P90 以及 P99 的延迟情况，进而实现对慢接口的定位。

* | SELECT 
  RequestPath,
  count(*) AS RequestCount,
  approx_percentile(OriginResponseTime, 0.50) AS LatencyP50,
  approx_percentile(OriginResponseTime, 0.90) AS LatencyP90,
  approx_percentile(OriginResponseTime, 0.99) AS LatencyP99
FROM log
WHERE OriginResponseTime IS NOT NULL
GROUP BY RequestPath
HAVING count(*) > 100
ORDER BY LatencyP99 DESC
LIMIT 20

3.1.3 告警规则示例

告警一，源站出现五百xx突然增多的情况，当错误占比超过百分之五的时候就会触发，能够迅速发觉源站存在异常。

* | SELECT
    count_if(OriginResponseStatus >= 500) * 100.0 / count(*) AS Origin5xxRate
  FROM log
  HAVING Origin5xxRate > 5

对了，有个告警2，是这样的，当高风险请求突然增加，次数超过100或者占比超过10%的时候，就会触发，然后还要识别潜在攻击，就是这样。

* | SELECT
    count_if(IsHighRisk = 1) AS HighRiskCount,
    count_if(IsHighRisk = 1) * 100.0 / count(*) AS HighRiskRate
  FROM log
  HAVING HighRiskCount > 100 OR HighRiskRate > 10

告警三：WAF拦截量突然增多，当拦截超过1000次或者独立攻击者超过50个的时候触发，能察觉到攻击的态势。

* | SELECT
    count_if(SecurityAction = 'block') AS BlockCount,
    approx_distinct(ClientFingerprint) AS UniqueAttackers
  FROM log
  HAVING BlockCount > 1000 OR UniqueAttackers > 50

3.2 成本对比

在此节当中，采用“能力对齐”这种方式来开展端到端 TCO 对比，其覆盖了 SLS 在该方案里所承担的完整闭环能力，其中包括数据传输，也就是 S3 导入，还有数据加工，即 SPL，以及存储与索引，随后是查询分析，接着是告警，最后是可视化，大约有 100 个仪表盘。为了使结论不因“只算存储/只算查询”而出现失真的情况，AWS 侧挑选了与之最为接近的 CloudWatch 一体化口径当作对标，此对标涵盖 Logs、Logs Insights、Dashboards、Alarms。

3.二点一的口径，以及具体参数，三点二点二呢，是单价来源的说明，再者三点二点三哟，是分能力的对齐，与计算。

1）数据传输 / 导入（把 S3 归档变为可检索数据）

有这么一种计费方式，它是按照写入的数据量来完成计费的，这种计费方式被应用于SLS，也就是Pay-by-ingested-data。

1 TB = 1,024 GB
20 TB/天 = 20,480 GB/天
月费用 = 20,480 GB/天 × 0.061 USD/GB × 30 天/月
      = 37,478.40 USD/月

公网的网络方面的费用，是从S3向SLS拉取时产生的，这个费用会计入到SLS方案的TCO当中。

说明：从 S3 拉取的是压缩对象，按“压缩后约为原始 1/10”估算网络出站流量
公网出站量（GB/天）= 20,480 GB/天 ÷ 10 = 2,048 GB/天
公网出站量（GB/月）= 2,048 GB/天 × 30 天/月 = 61,440 GB/月
按 AWS 口径：每月前 100 GB 公网出站免费 → 计费量 = 61,440 - 100 = 61,340 GB/月
分段计费示例（以 AWS 定价页 Data transfer 表格为准）：
- First 10 TB / Month：10,240 GB × 0.09 USD/GB = 921.60 USD
- Next 40 TB / Month：40,960 GB × 0.085 USD/GB = 3,481.60 USD
- Next 100 TB / Month： (61,340 - 51,200) GB = 10,140 GB × 0.07 USD/GB = 709.80 USD
月费用合计 = 921.60 + 3,481.60 + 709.80 = 5,113.00 USD/月

亚马逊网络服务（云观察日志摄取），这是一种服务，它涉及到云观察日志的摄取，属于亚马逊网络服务范畴。

月费用 = 20,480 GB/天 × 0.50 USD/GB × 30 天/月
      = 307,200.00 USD/月

2）数据加工（过滤 / 清洗 / 分发）

3）存储（14 天保留）

稳态存储量（14 天保留）= 20,480 GB/天 × 14 天 = 286,720 GB
月费用 = 286,720 GB × 0.03 USD/(GB×month)
      = 8,601.60 USD/月

4）查询分析

100 TB/天 × 1,024 GB/TB = 102,400 GB/天
月费用 = 102,400 GB/天 × 0.005 USD/GB × 30 天/月
      = 15,360.00 USD/月

5）告警

月费用 = 20 个告警 × 0.10 USD/个/月
      = 2.00 USD/月

6）仪表盘可视化（约 100 个 Dashboard）

月费用 = 100 个 Dashboard × 3.00 USD/个/月
      = 300.00 USD/月

3.2.4 费用汇总

SLS（月度）≈ 37,478.40（写入）+ 5,113.00（S3 公网出站）= 42,591.40 USD/月
AWS（月度）= 307,200.00（ingestion）
          + 8,601.60（storage）
          + 15,360.00（Logs Insights scanned）
          + 2.00（Alarms）
          + 300.00（Dashboards）
          = 331,463.60 USD/月

因此，在本节口径与参数下：

月度节省金额 = 331,463.60 - 42,591.40
            = 288,872.20 USD/月
成本降低 = 1 - (SLS / AWS)
        = 1 - (42,591.40 / 331,463.60)
        ≈ 87.15%

3.2.5 结论

日志文件一般是经过压缩然后归档的，本文是按照压缩比为10比1，也就是压缩之后大概是原始大小的十分之一来进行估算的。在这样的假设之下，SLS方案从端到端的角度来看，相较AWS（CloudWatch一体化），TCO降低了百分之八十七点一五；与此同时呢，因为SLS根据写入量来计费，30天的存储是免费的，这一节是按照14天来计算的，就相当于额外得到了16天的免费存储。

除了这些之外，SLS的数据加工能力，在这种计费模式之下，是不用另外计费的，其投递与告警等能力同样如此，Dashboard也不会按照“个数”来单独收取费用；然而在AWS那边常常是要为Dashboards、Alarms以及与之配套的ETL、投递组件分别进行计费的，这就表明用户能够免费获取到更多的额外能力。

总结展望

数据迁移时，跨云或者跨境传输的网络质量不能被忽略，费用同样不可以无视，为此，我们造就出致使云/跨境传输费用减少的能力，借助CloudFront，供用户挑选。

与此同时，在后续阶段，我们还进一步拓展了 GCP/Azure 的数据导入工作，以此来达成支持多云数据进行统一观测的目的。

参考：