乐趣区

关于阿里云:ARMS实践｜日志在可观测场景下的应用

jiezi

作者：陈陈

日志在可观测场景下的利用

随着 IT 架构扭转与云原生技术实际，融入开发与业务部门视角，运维团队具备比原有监控更宽泛、更被动的可观测能力。日志作为可观测三支柱（Tracing、Metrics、Logs）之一，帮忙运维团队追踪程序运行状态、定位故障根因、还原故障现场。以故障发现和故障定位为目标应用日志场景可大抵分为日志搜寻和日志剖析两类：

  1. 日志搜寻：
  • 通过日志关键字搜寻日志；
  • 通过线程名、类名搜寻日志；
  • 联合 Trace 上下文信息，衍生出依据 TraceID、依据 spanName、parentSpanName、serviceName、parentServiceName 搜寻日志。
  1. 日志剖析：
  • 查看、剖析指定日志数量的趋势；
  • 依据日志内容生成指标（比方每次交易胜利打印一条日志，能够生成对于交易额的一个指标）；
  • 自动识别日志模式（比方查看不同模式的日志数量的变动，占比）。

在理论生产中，通过灵便组合以上几种应用形式，运维团队能够很好地排除日常观测、故障定位过程中的烦扰因素，更快的定界甚至定位问题根因。

常见开源日志解决方案的有余

常见的日志解决方案多是利用主机上安装日志采集 Agent，通过配置日志采集门路的形式将日志采集到第三方零碎存储、查问、展现、剖析。较为成熟的有 ELK(Elasticsearch、Logstash、Kibana) 开源计划，其沉闷的社区、简略的装置流程、便捷应用形式等劣势吸引了不少用户。

但 ELK 计划也存在着些许有余：

  1. 运维老本高 ：搭建一套残缺的 ELK 零碎须要部署 ES 集群，kafka 集群以及 logstash 组件等等，以及随着日志规模的增长带来多集群拆分、多集群降级、稳定性等问题，往往须要投入更多人力。
  2. 资源开销大 ：ELK 架构中简直所有组件的资源开销都会随着日志规模的增长线性增长，占用极大老本。
  3. 企业级能力不足 ：日志中往往蕴含业务要害信息，须要一套齐备的多租户隔离以及细粒度的权限管制计划，这在开源收费 ELK 架构中是不足的。

基于 ARMS 的日志解决方案

相较于 ELK 开源自建计划，是否能够有更轻量、更容易运维的日志解决方案呢？

目前，利用实时监控服务 ARMS 提供一套简略易用的日志解决方案，让运维团队能够一键集成利用日志。相较于开源计划，丰盛功能性、压降老本的同时，进一步晋升易用性。

功能性

1. 主动富化日志

关联调用链上下文包含 TraceID、ServerIP、spanName，parentSpanName，serviceName，parentServiceName。全面满足依据 TraceID 搜寻日志、查找触发异样日志打印的上游利用、上游接口等须要将 Tracing 和 Logs 进行关联剖析的可观测场景。

2. 提供智能日志聚类能力

针对规模大、内容杂、且格局也难以做到对立标准的日志进行汇总、形象聚类，使运维人员迅速发现异常日志与失常日志“类别”上的不同，从而疾速定位异样日志、发现问题。

3. 提供 LiveTail 能力

针对线上日志进行实时监控剖析，毫秒级别提早上报日志，最贴近 tail - f 的日志查看体验，无效加重运维压力。

4. 基于 ARMS 的 Arthas 能力，运行时调整 logger 输入级别

5. 一键生成基于日志的报警、日志转指标的能力（内测中 行将上线）。

易用性

  • ARMS 控制台一键开明，即可应用日志相干全套性能；
  • 无需装置额定日志采集组件，防止利用革新；
  • 无需治理运维日志服务端以及日志，升高日常运维工作量；
  • 反对日志服务 SLS、及 ARMS 间接采集的日志。

运维老本

  • 日志性能处于公测阶段，完全免费；
  • 提供灵便可配置的日志抛弃策略，从源头上缩小大量有效日志；
  • 提供灵便可配置的日志存储策略，可依据利用重要水平配置日志存储时长。

ARMS 日志性能展现 & 场景最佳实际

前置要求

  1. 降级到 2.7.1.4 以及更高版本的 Agent（K8s 利用重启后会降级到 2.7.1.4 版本 agent，非 K8s 利用须要用户手动下载最新版本 Agent 并挂载）。
  1. 在 ARMS 控制台利用列表页，点开须要开启日志采集性能的利用，点击左侧最下方利用设置，点到自定义配置页，关上日志采集开关并依据理论场景配置相应参数，最初点击保留。
  • 对于间接采集的日志，是通过 ARMS 探针采集日志框架的输入并间接推送到 ARMS 的日志剖析核心。
  • 如果您须要将利用的日志采集到日志服务 SLS，并在 ARMS 利用配置中配置相应的 Project 和 Logstore，ARMS 会内嵌日志服务的页面不便您进行日志剖析。

性能利用演示

  1. 依据 TraceID 搜寻日志
  1. 查看蕴含置顶关键字的日志条数变化趋势
  1. LiveTail

视频

  1. 日志聚类下图中上方左侧是辨认进去不同模式的日志条数变化趋势，右图是不同模式日志抉择时间段内总条数降序排序，下方是不同模式下的日志原文，可通过在 search 中搜寻不同日志模式查看该模式下的日志原文样本。

ARMS 日志性能更多案例可查看 ARMS 官网文档：

https://help.aliyun.com/docum…

最佳实际

上面简略介绍两个阿里云可观测团队在云服务 SRE 场景下利用应用 ARMS 日志性能的最佳实际。

案例：指标上涨问题排查

  • 背景

利用 A 次要负责接管业务利用通过 RPC 上报流量信息、解析信息、简略解决后写存储。其中业务的流量信息包含工夫戳、业务利用名、接口名、一分钟的接口申请量、一分钟的接口申请总耗时。写入存储后，可在控制台查看该业务利用的流量监控信息。某日 某业务利用 B 反馈扩容后流量监控信息上涨，随即开始排查问题。

  • 排查计划
  1. 首先关上日志平台。查看利用 A 相干日志。看到较多写存储限流异样，统计该异样数量最近 3 小时趋势发现无明显增加，阐明该异样态大量呈现，无影响，持续排查。
  2. 狐疑利用 A 局部节点  hang 死，导致利用 B 上报数据失败，随即查看利用 A 不同实例日志输出量。发现根本平均，该狐疑排除。
  3. 此时，根本排除利用 A 的问题，开始狐疑数据上报异样。因为利用 B 的流量监控信息只是上涨并未跌 0，狐疑利用 B 局部节点数据上报异样。通过日志剖析，取得以后利用 B 以后失常上报数据的 IP 列表，给到用户，发现利用 B 新扩容机器均未胜利上报数据，狐疑新扩容机器网络异样。
  4. 通过日志平台查看利用 B 日志，看到较多网络异样，查看该异样散布机器，均散布在新扩容机器上，与上一步论断吻合。随即登陆一台机器，发现到利用 A 的网络的确不通，随即分割网络同学复原该问题。
  • 场景总结

通过日志检索与日志剖析联合应用，最终定位到问题根因。

案例:  日志存储老本升高

  • 背景

利用 C 因为开发人员泛滥，日志打印级别设置不合理，日志量很大，日志性能老本开销很高，急需降本提效。

  • 治理计划
  1. 基于过往日志排查问题教训，很少须要查看一周前日志。因而，将日志存储时长策略缩短，由一个月调整为一周。
  2. 通过 ARMS 日志模式自动识别的性能，查看以后 top-k 的日志模式，发现较多模式的日志属于有效日志。设置日志抛弃策略，将有效的日志抛弃。
  • 场景总结

联合存储时长调整和日志模式自辨认，日志整体老本升高到以前的十分之一。目前，ARMS 日志利用性能已全面凋谢，让运维团队疾速领有日志剖析与搜寻能力！

利用实时监控服务 ARMS 7 月产品能力动静

点击此处，立刻收费试用！

退出移动版