运维和SRE团队，承载着重要的职责，其工作内容复杂而广泛，从应用部署、性能和可用性监控、告警、值班，到容量规划、业务支撑等都有涉及。随着云原生、容器化和微服务的快速发展，迭代节奏愈发加快，对于运维和SRE也提出了更多的挑战，以下几个也是国内运维和SRE团队面临常见困境：
- 支持业务线广
- 业务线分布广泛，客户端、前端web、应用后端
- 同时支持几个甚至数十条业务线
- 人力严重短缺
- 相对开发人员，不少公司运维和SRE团队人员不到1%，甚至更低
- 线上稳定性压力大
- 经常扮演"救火队员"的角色
- 业务复杂，组件众多，快速排障和业务恢复的难度陡增
- 缺乏统一而有效监控分析平台
- 从不同的维度，对各类数据进行监控，脚本泛滥，工具纵多，烟囱林立
- 各类数据落在不同的系统中，关联分析欠缺，无法快速进行根因定位
- 阈值告警缺乏灵活性，一个系统可能出现数千告警规则，管理成本高昂，也容易造成告警泛滥，引起误判、漏判
因此，一套简单易用、高效、分析能力强的监控分析平台，对于提高运维和SRE工作效率，快速而准确进行根因定位，保证业务连续性至关重要。
监控分析平台需要解决的数据问题
运维和SRE为了保证业务稳定和支持业务发展，需要对大量的数据进行收集和分析，从机器硬件、网络指标到业务、用户行为等多方面数据，在完成数据采集后，还需要有一套合适的系统进行转换、存储、处理、分析，满足多样的需求。数据问题主要包括：
- 数据多样
- 各类系统数据 ：cpu、mem、net、disk等通用硬件指标，系统syslog
- 业务黄金指标：延时、流量、错误、饱和度
- 业务访问日志 ：Access Log
- 应用日志 : 如Java应用日志、错误日志
- 用户行为数据：web click
- App埋点数据：Android、IOS app中埋点统计
- 各类框架数据：如被广泛使用的k8s框架产生的数据
- 服务调用链 ：各类Tracing数据
- 需求多样
对于收集的各类数据，运维和SRE团队不光是为了保障业务稳定，还需要支持其他业务团队进行数据的使用，对于数据的使用也是多样的，常见需求如：
- 监控、报警 ：实时处理（流式，小批量），秒级~分钟级延时
- 客服、问题排查：快速检索，如通过关键词过滤，秒级延时
- 风控：实时流量处理，亚秒延时
- 运营、分析：大规模数据分析，如OLAP场景，秒级到小时级延时
- 资源需求估算难
对于快速发展的业务，各类数据的规模在一开始是很难准确估算的，经常遇到:
- 新业务接入，数据量无准确估算参考
- 业务快速发展，数据暴增
- 数据使用需求变动，原有存储方式，保存时间不符合使用需求
构建监控分析平台方案选择
由于数据来源广、样式杂，需求多，运维和SRE团队往往需要使用和维护多套系统，组合使用，才能满足多样的监控和业务需求，常见的开源组合如：
- Telegraf+Influxdb+Grafana
Telegraf是一个轻量级的采集框架，通过丰富插件对操作系统、数据库、中间件等各类指标进行采集，配合Influxdb对时序数据进行高效读写、存储、和query，最终可在grafana上进行可视化展示和交互式查询 - Promethues
在云原生k8s的生态中， Prometheus基本上作为时序数据的标配，配合灵活的exporter可以非常方便完成Metric采集，同时Promethues也可以和Grafana集成 - ELK
在日志数据多维度查询和分析上，ELK套件是最常用的开源组件，提供快速、灵活、强大的查询能力，可满足研发、运维、客服的大部分查询需求 - Tracing 类
在微服务、分布式的系统中，请求调用链路复杂，没有一套合适的Tracing系统，很难进行高效的问题根因定位，从最开始的Zipkin、Jeager到逐渐形成行业标准的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、并发进行合理的分配和管理，必要时进行降级处理，否则某个业务的使用可能导致其他业务性能受损，而这在开源组件中，一般都很少考虑
- 成本控制
- 资源成本：各类组件的部署都需要消耗硬件资源，特别是当数据同时存在多个系统中的时候，硬件的资源消耗将更加严重; 另外一个常见问题是，业务往往很难准确对数据量进行估算，很多时候，会采用相对保守手段，来降低系统水位，这又造成资源浪费
- 接入成本：支持各业务线数据接入也是一个繁重的工作，涉及到数据格式的适配、环境管理、配置设置和维护、资源的估算等一些列工作，需要有工具或平台帮助业务线自主完成，否则运维和SRE将陷入大量的琐事中
- 支持成本：对各系统的使用，难免会遇到各类问题，必要的技术支持必不可缺，但问题种类多样，如使用模式不合适、参数配置不合理等，也有遇到开源软件本身bug导致的问题，这对于维护这些系统的运维和SRE来说，又是一笔额外的代价
- 运维成本: 各系统的软硬件难免会出故障，硬件替换、缩扩容、软件版本升级，也需要投入不小的人力和精力
- 费用分摊：只有地将资源消耗清晰准确分摊到实际业务线，运维和SRE，才能更有效利用资源，制定合理的预算和规划。这也就需要能提供有效计量数据进行费用分摊。
从上面的挑战来看，为了保证系统连续性和支撑好业务，运维和SRE团队维护好多套系统，可并不是一个轻松的事。下面以某公司实际场景为例，看看实践中可能遇到的问题和需要注意的内容。
实际场景模拟
业务背景 ：
- 公司有100多应用，每个应用有Nginx访问日志，以及Java应用服务日志
- 各应用日志规模变化巨大，从单日1GB到1TB不等，每天新增10TB数据，需保存7天至90天， 平均15天
- 日志数据主要用于业务监控和报警、线上问题排查，以及实时风控使用
业务架构选型：
- Filebeats ：实时采集数据，发送至kafka
- Kafka : 数据临时存储，供实时Flink实时消费，和导入ES
- Flink : 对业务数据实时分析，进行实时监控、风控
- ES : 日志查询分析，问题排查
在以上看似最简单和直白的架构中，也隐藏了大量细节需要关注，以ES为例：
- 容量规划：原始数据 * 膨胀系数 *（1 + 副本数) * (1 + 预留空间) ， 一般膨胀系数取1.1 ~ 1.3， 1个副本，25%的预留（剩余空间，临时文件等）， 实际磁盘空间最终是原始空间的 2.75~3.5倍。如果需要开启_all 参数设置的话，数据膨胀会更严重，也需要预留更多空间
- 冷热分离：所有数据全部保留到SSD上成本会过高，需要根据数据的重要程度和时间因素，可以将部分Index直接保存至HDD磁盘，或使用Rollover功能将Index迁移
- Index设置 : 每个应用的2类日志，分别按照时间周期性创建Index，根据数据大小合理设置shard数， 单shard以30~50GB为宜，但是各应用的日志量很难准确估计，常在遇到写入或查询问题后再调整， 然而reindex的消耗又非常大
- Kafka消费设置：通常使用logstash消费kafka再写入ES，需要kafka topic的patition数和logconsumer_threads相匹配，否则容易导致各partition消费不均
- ES参数调优：对写入吞吐，可见性延时，数据安全性，以及查询性能等多方面因素进行综合评估和权衡后，结合集群CPU、内存，对ES一些列参数进行调优，才能更好发挥ES的特性，常见的参数包括线程数、内存控制、translog设置、队列长度、各类操作间隔interval、merge参数等
- 内存问题：通常JVM 堆内存大小在32GB以内，剩余的留个OS缓存使用，如果频繁gc 会严重影响性能，甚至直接导致服务不可用。
- master节点内存占用和集群中shard数直接相关，一般集群shard需要控制在10W以内，ES默认配置中，单节点shard数上限为1000，需要合理控制index和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工作中对于监控分析平台的需求，以及平台搭建过程中遇到的种种问题， 阿里云SLS团队希望在云上提供一套简单易用、稳定可靠、高性能而又具有良好性价比的解决方案，以支持运维和SRE更高效地工作。SLS从原本只支持阿里+蚂蚁的内部日志系统开始，逐步完善，演进成为同时支持Log、Metric、Tracing的PB级云原生观测分析平台：
- 极其简便接入
- Logtail : 多年百万级服务器锤炼，简便、可靠、高性能，web端可视化管理
- SDK/Producer : 各类移动端 java/c/go/ios/android/web tracking接入
- 云原生 ：云上ACS原生支持，自建CRD一键接入
- 实时消费和生态对接
- 秒级扩容能力，支持PB级数据实时写入和消费
- 原生支持flink/storm/spark streaming等主流系统
- 海量数据查询分析力
- 百亿规模秒级查询
- 支持SQL92、交互式查询、机器学习、安全特色函数
- 数据加工
- 先比传统ETL，可节省90%的开发代价
- 纯托管、高可用、高弹性扩展
- Metric 时序数据
- 云原生Metric接入，支持亿级时间线的Prometheus存储
- 统一的Tracing方案
- 完美支持OpenTelemetry协议，兼容Jaeger、Zipkin等OpenTracing协议、OpenCensus、SkyWalking等方案
- 完善的监控和报警
- 站式完成告警监控、降噪、事务管理、通知分派
- 异常智能诊断
- 高效的无监督流式诊断和人工打标反馈机制，大大提高了监控效率很准确率
相比开源多套系统的方案， SLS采用了All in one的模式，在一个系统中，完整支持了运维和SRE工作中对于监控分析平台的需求，可以直接替代搭建kafka、ES、Prometheus、OLAP等多套系统的组合，这样带来了明显的好处：
- 运维复杂度
- 云上服务，开箱即用，0运维成本，无需再维护和调优多套系统
- 可视化管理，5分钟完成接入，业务支持代价大大降低
- 成本优化
- 数据只保留一份，无需将数据在多套系统中流转
- 按量使用，无预留资源的浪费
- 提供完善的技术支持，人力成本大大降低
- 资源权限管理
- 提供完整的消费数据，助力完成内部分账和成本优化
- 完整的权限控制和资源隔离，避免重要信息泄露
SLS 希望通过自身的不断进步，为Log/Metric/Trace等数据提供大规模、低成本、实时平台化服务，助力运维和SRE更高效工作，更有效支持业务快速发展。
