本文从运维和SRE团队角度介绍监控分析平台的建设与选择。
背景信息
运维和SRE团队承载着重要的职责，其工作内容复杂而广泛，从应用部署、性能和可用性监控、告警、值班，到容量规划、业务支撑等都有涉及。随着云原生、容器化和微服务的快速发展，迭代节奏愈发加快，运维和SRE团队面临更多挑战，运维和SRE团队面临常见的困境如下：
业务线广泛
业务线分布广泛，包括客户端、前端Web、应用后端。
同时支持几条甚至数十条业务线。
人力严重短缺
相对开发人员，不少公司的运维和SRE团队人员不到1%，甚至更低。
线上稳定性压力大
经常扮演救火队员的角色。
业务复杂、组件众多，快速排障和业务恢复的难度陡增。
缺乏统一而有效监控分析平台
从不同的维度对各类数据进行监控，脚本泛滥、工具众多、烟囱林立。
各类数据落在不同的系统中，欠缺关联分析，无法快速进行根因定位。
阈值告警缺乏灵活性，一个系统可能出现数千条告警规则，管理成本高昂，并且容易造成告警泛滥，引起误判、漏判。
因此，一套简单易用、高效、分析能力强的监控分析平台，对于提高运维和SRE团队的工作效率、快速而准确进行根因定位、保证业务连续性至关重要。
监控分析平台需要解决的数据问题
运维和SRE团队为了保证业务稳定和支持业务发展，需要对大量的数据进行采集和分析，包括机器硬件、网络指标、用户行为等多方面的数据。在完成数据采集后，还需要有一套合适的系统进行转换、存储、处理、分析，满足多样的需求。数据问题主要包括：
数据多样
各类系统数据：cpu、mem、net、disk等通用硬件指标，系统日志。
业务黄金指标：延时、流量、错误、饱和度。
业务访问日志：Access Log。
应用日志：Java应用日志、错误日志。
用户行为数据：Web click。
App埋点数据：Android、iOS App中埋点统计。
各类框架数据：被广泛使用的K8s框架产生的数据。
服务调用链：各类Tracing数据。
需求多样
对于各类数据，运维和SRE团队不仅需要保障业务稳定，还需要支持其他业务团队进行数据的使用，对于数据的使用也是多样的，常见需求如下：
监控、报警：实时处理（流式，小批量），秒级~分钟级延时。
客服、问题排查：快速检索，例如通过关键词过滤，秒级延时。
风控：实时流量处理，秒级延时。
运营、分析：大规模数据分析，如OLAP场景，秒级到小时级延时。
资源需求估算难
对于快速发展的业务，各类数据的规模在一开始是很难准确估算的，经常遇到：
新业务接入，数据量无准确估算参考。
业务快速发展，数据暴增。
数据使用需求变动，原有存储方式，保存时间不符合使用需求。
构建监控分析平台方案选择
由于数据来源广、样式杂，需求多，运维和SRE团队往往需要使用和维护多套系统，才能满足多样的监控和业务需求，常见的开源组合如下：
Telegraf+Influxdb+Grafana
Telegraf是一个轻量级的采集框架，通过丰富的插件采集操作系统、数据库、中间件等各类指标，配合Influxdb对时序数据进行高效读写、存储和分析，然后在Grafana上进行可视化展示和交互式查询。
Prometheus
在云原生K8s的生态中，Prometheus基本上作为时序数据的标配，配合灵活的exporter可以非常方便地采集Metric数据，同时Prometheus也可以和Grafana集成。
ELK
在日志数据多维度查询和分析上，ELK套件是常用的开源组件，提供快速、灵活、强大的查询能力，可满足研发、运维、客服团队的大部分查询需求。
Tracing类工具
在微服务、分布式的系统中，请求调用链路复杂，没有一套合适的Tracing系统，很难进行高效的问题根因定位，从Zipkin、Jaeger到逐渐形成行业标准的OpenTelemetry、SkyWalking都是不错的Tracing系统，而这些Tracing系统并未提供数据存储组件，需要配合ES或Cassandra来存储Tracing数据。
Kafka+Flink
对于数据清洗、风控等需求，需要构建一套实时数据通道和流式系统，支撑数据的全量实时消费，一般使用Kafka和Flink组合。
ClickHouse、Presto、Druid
在运营分析、报表等场景中，为了追求更高的实时响应性，通常还会将数据导入OLAP引擎，在秒级到分钟级内完成海量数据分析需求，以及各类Adhoc的查询。
不同组件面向不同的数据类型和处理需求，数据需要在其中流转，有时候同一份数据需要同时保存在多个系统中，增加系统复杂度和使用成本。
当数据越来越多，使用需求越来越广时，保障这些组件的稳定性、满足多种业务性能需求、进行有效的成本控制，又要对大量业务线进行高效支撑，都是非常繁重而又有挑战的工作。
监控分析平台的挑战
能够维护好多套系统又能有效支持众多业务线，这是一个巨大的挑战。
稳定性保障
依赖系统：数据在多套系统中流转，系统之间又存在依赖关系，当某系统出现问题时，对其他系统造成影响。例如下游ES系统写入变慢后，用于缓存数据的Kafka集群存储水位变高，可能导致集群写满。
Burst问题：在互联网环境下，流量Burst是非常常见的情况。对于监控分析平台也一样，当大量数据需要写入系统时，保证系统不被压垮，同时保证读取功能正常运转，是一项巨大的挑战。
资源隔离：不同数据的优先级有高低，如果过分依赖资源物理隔离将导致集群资源严重浪费和运维成本极大提高，而当数据共享资源时，需要尽可能保证相互之间不受干扰。例如某些系统中，一次超大规模的查询，可能拖垮整个集群。
技术门槛：各类系统都有大量参数需要调优，面对不同的场景和需求，调优模式也不尽相同，需要投入大量的时间和精力，根据实际情况进行对比和优化。
性能可预期
数据规模：对系统的性能有非常大的影响。例如时序数据在千万级到亿级时间线下读写，ES在10亿到100亿行数据中的查询性能保证，都非常有挑战。
QoS控制：任意一个系统的硬件资源都是有限的，需要对不同数据的QPS、并发进行合理的分配和管理，必要时进行降级处理，否则某个业务的使用可能导致其他业务性能受损。而开源组件一般很少考虑QoS的控制。
成本控制
资源成本：各类组件的部署都需要消耗硬件资源，特别是当数据同时存在多个系统中的时候，硬件的资源消耗将更加严重。另外一个常见问题是很难准确估算业务的数据量。很多时候，采用相对保守手段来降低系统水位，这又将造成资源浪费。
接入成本：支持各业务线数据接入也是一个繁重的工作，涉及到数据格式的适配、环境管理、配置设置和维护、资源估算等一系列工作，需要有工具或平台帮助业务线自主完成，否则运维和SRE团队将陷入大量的琐事中。
支持成本：使用各种系统难免会遇到各类问题，必要的技术支持必不可缺，但问题种类多样。例如使用模式不合适、参数配置不合理等。遇到开源软件本身BUG导致的问题，又是一笔额外的成本。
运维成本：各系统的软硬件难免会出故障，硬件替换、缩扩容、软件版本升级，都需要投入不小的人力和精力。
费用分摊：只有将资源消耗清晰准确地分摊到实际业务线中，才能更有效利用资源，制定合理的预算和规划。这也需要监控分析平台能提供有效的计量数据进行费用分摊。
实际场景模拟
业务背景
公司有100多应用，每个应用都有Nginx访问日志和Java应用服务日志。
各应用日志规模变化巨大，单日1 GB到1 TB不等，每天新增10 TB数据，需保存7天~90天，平均15天。
日志数据主要用于业务监控和报警、线上问题排查以及实时风控使用。
业务架构选型
Beats：实时采集数据发送至Kafka。
Kafka：数据临时存储，用于Flink实时消费和导入Elasticsearch。
Flink：对业务数据实时分析，进行实时监控、风控。
Elasticsearch：日志查询与分析，问题排查。
在以上看似简单的架构中，也隐藏了大量细节需要关注，以ES为例：
容量规划：原始数据*膨胀系数*（1+副本数）*（1+预留空间）， 一般膨胀系数取1.1~1.3，1个副本，25%的预留（剩余空间，临时文件等）， 实际磁盘空间是原始空间的2.75~3.5倍。如果需要开启_all参数设置，数据膨胀会更严重，也需要预留更多空间。
冷热分离：所有数据全部保存到SSD上，成本过高。需要根据数据的重要程度和时间因素，将部分索引数据直接保存至HDD磁盘或使用Rollover功能迁移索引数据。
索引设置：每个应用的两类日志，分别按照时间周期性创建索引，根据数据大小合理设置Shard数，单Shard以30~50 GB为宜，但是各应用的日志量很难准确估计，常在遇到写入或查询问题后再调整，然而重建索引的消耗又非常大。
Kafka消费设置：使用Logstash消费Kafka数据再写入到ES，需要Kafka topic的partition数和logconsumer_threads相匹配，否则容易导致各partition消费不均。
ES参数调优：对写入吞吐、可见性延时、数据安全性以及查询性能等多方面因素进行综合评估和权衡后，结合集群CPU、内存，对ES一些列参数进行调优，才能更好发挥ES的特性。常见的参数包括线程数、内存控制、translog设置、队列长度、各类操作的间隔interval、merge参数等。
内存：通常JVM堆内存大小在32 GB以内，剩余的留给OS缓存使用，如果频繁GC会严重影响性能，甚至直接导致服务不可用。
master节点内存占用和集群中Shard数直接相关，一般集群Shard需要控制在10,000个以内，ES默认配置中，单节点Shard数上限为1000个，需要合理控制索引和Shard数量。
data节点的内存由索引数据规模决定，如ES的FST会长期驻留在内存，虽然在7.3及之后版本中，提供了堆外内存方式（mmap)，但缓存被系统回收又会导致查询性能下降，如果使用的是更低版本，则只能控制单节点数据大小。
查询与分析：影响查询与分析性能的因素非常多，需要花费大量时间不断试错和积累。
合理设置mapping，例如text和keyword的选择，尽量避免无必要的nested mapping。
避免过大的查询范围和复杂度（过深的Group by语句等），以免急剧消耗系统资源。对结果集大小进行限制，否则复杂的聚合查询或模糊查询等，在过大数据集上甚至直接导致内存溢出（OOM）。
控制segment数量，必要时进行force merge，也需要评估force merge带来的大量IO和资源消耗。
合理选择Filter和Query。在无需计算的场景中，Filter可以更好使用Query Cache，速度要明显快于Query。
script脚本带来的性能和稳定性问题。
合理使用好routing可以使得单次查询只扫描某个Shard数据，提升性能。
数据损坏：如果遇到异常的crash，可能导致文件损坏。在segment或translog文件受损时，Shard可能无法加载，需要使用工具或手动将有问题的数据清理掉，但这也会导致部分数据丢失。
以上是在使用和运维ES集群中，经常会遇到和需要注意的问题，稳定维护好ES集群可真不是一件容易的事情，特别是当数据逐步扩大到数百TB，又有大量使用需求的情况下。同样的问题也存在其他系统中，这对于平时工作极其繁忙的运维和SRE同学是不小的负担。
云上一体化服务选择
针对运维和SRE团队工作中的监控分析平台需求，以及平台搭建过程中遇到的种种问题，阿里云日志服务团队希望在云上提供一套简单易用、稳定可靠、高性能而又具有良好性价比的解决方案，以支持运维和SRE团队更高效地工作。日志服务从原本只支持阿里巴巴集团和蚂蚁集团内部日志系统开始，逐步完善，演进成为同时支持Log、Metric、Trace的PB级云原生观测分析平台。
接入数据极其简便
Logtail：经过多年百万级服务器锤炼，简便、可靠、高性能，界面化管理。
SDK/Producer：接入各类移动端Java、C、GO、iOS、Android、Web Tracking数据。
云原生：云上ACK原生支持，自建CRD一键接入。
实时消费和生态对接
秒级扩容能力，支持PB级数据实时写入和消费。
原生支持Flink、Storm、Spark Streaming等主流系统。
海量数据查询分析力
百亿规模秒级查询。
支持SQL92语法，支持交互式查询，支持机器学习、安全检测等函数。
数据加工
对比传统的ETL，可节省90%的开发成本。
纯托管、高可用、高弹性扩展。
Metric数据
云原生Metric数据接入，支持亿级时间线的Prometheus存储。
统一的Tracing方案
支持OpenTelemetry协议，兼容Jaeger、Zipkin等OpenTracing协议，支持OpenCensus、SkyWalking等方案。
完善的监控和报警
一站式完成告警监控、降噪、事务管理、通知分派。
异常智能诊断
高效的无监督流式诊断和人工打标反馈机制，大大提高了监控效率和准确率。
相比开源多套系统的方案，日志服务采用All in one模式。在一个系统中，完整支持运维和SRE团队工作中的监控分析平台需求，可以直接替代搭建Kafka、ES、Prometheus、OLAP等多套系统的组合，具有如下优势：
降低运维复杂度
云上服务、开箱即用、零运维成本、无需再维护和调优多套系统。
可视化管理、5分钟完成接入、业务支持成本大大降低。
成本优化
数据只保留一份，无需将数据在多套系统中流转。
按量使用，无预留资源的浪费。
提供完善的技术支持，人力成本大大降低。
完善的资源权限管理
提供完整的消费数据，助力完成内部分账和成本优化。
完整的权限控制和资源隔离，避免重要信息泄露。
日志服务希望通过自身的不断进步，为Log、Metric、Trace等数据提供大规模、低成本、实时平台化服务，助力运维和SRE团队更高效工作，更有效支持业务快速发展。