几乎所有业务都需要经过京东智联云所提供的负载均衡、DNS、CDN 这些系统，那么从这些系统所产生的日志中便能挖掘出非常有价值的信息，也能做到从全局和上帝视角对整个系统的状态和性能进行实时监控。日志服务已然是系统稳定运行必不可少的一部分，成为DevOps中的标配选项。本次大促中，日志服务系统的稳定运行，完美完成了大促的保障任务，为大促新纪录提供了坚实的保障。本篇文章将介绍大促对日志服务所带来的挑战，以及京东智联云日志服务系统架构设计。

大促对日志服务带来的挑战

作为最常用的排障、分析工具，日志服务功能的完善性有着很重要的影响。在大促的场景下，用户的主要场景需求有：

• 现场日志查看

• 日志监控

• 实时分析

• 日志消费

数据作为企业最宝贵的资产，大促的数据更是核心中的核心。

集团及我们服务的相关企业一方面期望数据资产存储越久越好，另一方面又要讲求成本与效益的平衡，这便形成了一种矛盾的现象。

日志服务每天产生以PB计量的数据，形成了一个不可忽视的成本项，如何有效降低其整体成本，是一个最直接的难题。

大促作为京东集团全年唯二的最高级别大型活动，对服务的稳定性有着近乎苛刻的要求。服务上一次不稳定的波动，都会直接导致收入上的损失。日志服务作为集团服务的技术基石，自身服务的稳定性至关重要。

京东智联云日志服务解析

京东智联云日志服务，作为京东内部一站式DevOps解决方案运维域的重要组件之一，为全集团提供统一日志解决方案。通过为研发、运维、运营提供检索、排障、分析等功能，满足各业务系统、运营系统、中间件、底层服务的需求，助力其发挥价值。

作为最常用的排障、分析工具，日志服务提供了完善的产品功能。在确保覆盖各类功能需求的基础上，提供了智能解析、实施分析等增强型功能。为支撑「快速发现问题」-「快速定位问题」-「快速解决问题」的核心目标提供了保障。

日志服务的业务功能架构图如下：

京东智联云日志服务整体架构上实现了存储与计算分离。可进行针对性的调优。

我们先来看一下日志服务应用架构示意图：

（1）存储

存储的使用主要对应应用架构视图的indexer部分。这里主要关注存储相关的两个因素：存储介质、存储内容。

①存储介质

专业的团队干专业的事情，选择专业的存储产品，日志服务层不再干涉存储层的优化。

选取原则为：

1. 足够成熟稳定；

2. 成本廉价。

我们选择了对象存储产品。其特征为：

• 资源弹性伸缩

• 成本低廉

• 高可用性保证

• 安全性

• 兼容标准S3

整个产品使用下来非常稳定，实现了存储介质上的「低成本」。

②存储内容

日志存储方案示意图如下，下面我们来讨论一下在降低存储内容方面做的工作。

日志数据流传输到服务端后，被indexer重组为bucket及index文件，最终被写入共享存储。

index文件用于加速定位检索的文件，bucket部分用于存储日志原始数据。index及bucket均采用了压缩的方式进行存储，实现了存储内容上的「低成本」。

（2）计算

计算资源的使用主要对应应用架构视图中的query indexer部分。

这一部分功能有：

• 按照索引计算需要加载的bucket

• 加载bucket

• 依据bucket中的meta定位待处理的block

• 针对block内容进行解压+计算

• 结果聚合

通过上述功能可以看到，日志检索、分析任务兼具IO密集型及计算密集型特征，这部分是需要我们针对性进行资源优化利用的。

在数据的扫描上，我们通过多级索引，实现bucket文件的精准定位。

采用延迟加载的方式加载bucket进一步降低IO开销。

计算环节采用了优先级任务队列+worker池的方式，通过提升任务的并发度，可以借助更多的计算资源提升计算速度。通过对计算任务进行评分，给予不同的优先级，合理调度计算资源，实现分级保障。

上云的用户最关心的问题就是各个基础服务的稳定性。用户是否可以完全信赖日志服务呢，日志服务是如何保证服务的高可用性的？接下来让我们一起探讨下日志服务的基本实现及在稳定性上所做的一些工作。

先简单介绍日志服务的组成形式及大促备战流程，这是我们进行后续讨论前需要了解的背景信息。

下面借助日志服务职责分层示意图，来了解日志服务的组成形式：

• 采集层：日志agent，适配云主机，k8s等各类环境，提供日志收集功能；

• 存储层：底层复用Database及对象存储的能力，实现数据的高可用存储；

• 计算层：对日志数据进行过滤、转换、统计，支持业务层各个功能模块；

• 业务层：日志产品层。提供检索、分析、监控、消费转储等功能。

大促备战流程：

其中，我们需重点识别如下信息：

• 识别重保租户

• 识别重保系统

• 用户设定的预申请配额

了解以上信息后，我们开始在多个方面讨论稳定性相关工作。

（1）高可用

一套高可用服务的推出，要经历的主要环节如下：

• 存储层

  复用Database及对象存储的能力，直接实现跨AZ高可用、跨region的容灾能力。每个产品都做了大量稳定性相关的工作，这里不再赘述。

• 计算引擎

  ◆  轻量级实时计算服务：自研无状态服务，按照标准的跨AZ、Region部署的原则，可以很轻易地实现高可用及容灾。

  ◆  基于大数据引擎的计算服务：

  
  

  ◇  按照业务进行划分，实现资源隔离；

  ◇  HA+checkpoint，保障作业的恢复；

  ◇  数据流多机房热备，便于任务迁移及恢复；

  ◇  基于自监控的流式热点发现及恢复。

（2）熔断

在依赖系统出现异常时，常常出现雪崩效应，一方面会向上传递放大异常，另一方面巨大的流量也使得下游服务的恢复变得更加困难。

为了避免该问题的出现，各级系统都需要进行熔断处理。当前社区中的「自适应熔断」策略及工具已经十分成熟，这里不再赘述。

（3）限流

限流策略可以有效地保障系统平稳运行，达到削峰填谷的目的。

在日常情况下，日志系统的流量特征为：整体平稳，按天呈周期性起伏状，无突升突降。

针对该特征，日常限流策略为：

• 整体限流n倍：各级系统均需要实现整体限流策略，参数n需要依据自身的数据特征来决定。一般情况下，我们倾向于设置为3；

  
  

• 业务线限流m倍：核心处理系统，均需要实现对业务线限流。参数m的设定，需要依据产品线数据特征决定。一般情况下，m的值应大于 n，我们倾向于设置为10。

在大促的情况下，整体的流量都会有大幅的上涨。我们需要依据用户提报的「预申请配额」进行上调。

（4）伸缩

日常情况下，资源按照实际流量进行伸缩。

在备战的情况下，我们需要提前按照租户在系统中设定的「预申请配额」信息（见上方备战流程）进行预扩容，以消除临时进行大量伸缩可能会带来的问题。

具体执行过程中，需要按照产品架构文档逐个环节进行资源池扩容确认。

（5）监控

监控作为大促最关键的保障，我们通常需要建设的项目有dashboard-盯屏版，dashboard运维版，告警，告警预案。其中「dashboard-盯屏版」需要为大促进行专门内容更新建设，我们重点讨论。

建设原则：

• 全面：需要观测全局性，通过dashboard能够观测服务全局健康状态，不要遗漏。

• 直观：dashboard遵循监控建设规范，能够快速发现问题，一眼看尽。

  ◆  例如：为不同的阈值设置不同的颜色，同类型的指标在相近的位置展开等；

  ◆  强调：dashboard是用来观测整体健康度的，不同于排查问题的趋势图页面。在大促期间盯屏人员是不可能去看到每张图的数据后再判断是否健康的。所以需要按照规范，用负担最轻的方式交付使用。

• 用户视角：用户侧可以感知的指标需要全部添加。

建设内容

• 日常监控review：包括服务整体健康度指标（SLA），黄金指标（PV、平响、错误码），拨测指标。

• 重保用户视图：重保用户的控制面、数据面健康度。

  ◆  dashboard需要平铺展示，不要变量；

  ◆  用户侧可以感知的指标需要全部添加。用户侧无感的指标禁止添加。内部指标需要在研发、运维趋势图中配置；

  ◆  核心指标设置监控。

• 重保服务视图：系统级别的控制面、数据面健康度。

（6）预案

• 按照备战流程中确定的重保系统及其级别，生成分级的兜底配置，作为降级的依据；

• 依据降级配置，生成多个配置固化的预案。并提前进行演练。注意：必须要固化配置，以避免出现现场误操作导致故障的情况；

• 依据细分的监控指标设定待触发自动化预案。如果该预案十分重要，可以仅触发语音告警，届时由主备值班人员复核后执行；

• 执行预案后，系统自动通知被降级业务方。

总结

本文对京东智联云支持11.11流量背后的一部分工作进行了梳理。日志服务帮助京东实现了降低成本与提高效率等重要价值，并通过高可用架构、容灾、熔断、限流、弹性伸缩、监控、预案等流程为大促的稳定运行提供了重要保障。