F-22战斗机是第五代隐身战斗机，其各项能力是世界公认的名列前茅，能够“Control the Sky”。F-22的绰号为“Raptor”，译为“猛禽”。而这正是美团可观测性平台Raptor名称的由来。
Raptor作为美团的可观测性平台，融合了前端监控、基础设施监控、应用层监控，同时也给业务提供指标、链路、部分日志监控能力，并提供丰富大盘报表及实施告警功能。
在WOT全球技术创新大会2023·北京站的《可观测性技术与实践》专场中，来自美团的技术专家任天带来了主题为《美团可观测性平台：Raptor建设与实践》的精彩分享，详细介绍了Raptor的“飞天”建设之路。
如何“Control the Sky”？
如何在互联网中监控一切？什么样的架构设计才能满足可观测性平台的需求？美团首先从可观测性平台的特点和业务使用方式入手，总结出“全、快、准、稳”四个特点，根据特点将整体的可观测性平台分为横向和纵向，通过分层设计和监控能力建设，从而搭建出美团可观测性平台Raptor。
可观测性平台的横向分类是基于业务流量访问图，因此美团从横向进行产品分类时将Raptor分为三层：监控移动端APP、浏览器、H5小程序以及其他容器的大前端监控，面向实际后端业务开发的应用层监控，以及面向基础设施监控的系统层。
纵向分类是从可观测性平台监控的角度出发，分为指标、链路和日志。基于此，美团为Raptor构建了以指标为主的监控体系架构，通过指标体系监控对象的运行状态；而日志和链路更侧重于异常分析或者个案分析。
在Raptor的前端领域中，监控指标分为请求类指标和自定义指标；应用层则拆分成Transaction、Event、Problem和Business四类指标。这些指标可以进行串联，比如将Transaction、Event和Problem串联，从而构成整个进程内的链路监控。除此之外，还有面向主机侧监控的系统层、面向K8s集群内监控的Mps和美团自建的进程间链路的监控系统Mtracer。
而无论是横向还是纵向分类，Raptor都是基于全方位、可扩展和高可用的设计原则。若想满足这些原则，分层设计是最好的选择。因为分层设计的可观测性平台扩展性强、各端领域的监控逻辑相对统一，并且告警、降采样等技术能力可以得到重用。因此Raptor分为采集层、接入层、存储层、分析层和应用层，每层根据应用的特点进行独立设计。
为Raptor建设“飞天”之路
整体介绍完Raptor的设计后，任天着重介绍了Raptor的建设实践之路，以及Raptor如何“飞”上天空。
首先第一个建设是应用层监控——开源版Cat。Cat基于流式的处理流程，实时性很强；其监控类型也非常丰富，能够基本覆盖用户所有的需求。同时，美团对可观测性平台的推广覆盖度较全，对PaaS或中间件都制定了较为严格的埋点规范。基于以上特点，Cat能够生成更加丰富的报表类型。
应用层Cat功能虽强大，但由于Cat是侵入式埋点，所以也会侵入到业务进程中。因此，需要在保证高可用状态的同时，避免影响业务的核心流程。SDK的设计就尤为重要。
美团的SDK设计是通过内存队列和整个处理逻辑进行解耦。当消息通过埋点API构建时，会进行消息采样。被采样到的消息进入内存队列中，后续的Sender线程能够发送数据；没被采样到的指标也会保留，并在本地预聚合。这种设计能够避免因采样失误导致的指标数据不全、不准。
此外， SDK层还能高效上报协议，并且处理逻辑与业务核心线程是独立的，保证在出现问题时业务也能正常运转。
Cat和SDK的建设使后端服务有了监控能力，但这样就能满足业务的可观测性诉求了吗？答案必然是“否”。
如果后端服务正常，中间网络出现问题，用户同样无法正常使用。因此还需要建设大前端领域的监控，从用户端视角观测端到端的链路。
大前端的监控处理数据流程相对简单。首先在APP、Web、小程序中嵌入内置的SDK采集接口性能。数据到处理层后，处理层会统计每个接口的成功率、响应时间以及APP或小程序的性能和开销。如果有错误日志则会采集错误日志。此外，在RN动态容器中也会存在一些自定义监控。
那么现在已经具备了大前端和后端服务的监控能力，应该可以满足开发人员的诉求了吧？答案依旧是“否”。因为后端服务在基础设施中运行，所以还要监控设施。
美团建设了针对基础设施的系统层监控，也称之为Hosts监控。在Hosts监控的流程中，第一步是Agent进程采集本容器中的基础指标，同时对每个进程提供监控能力。在进程内可以通过开放接口调用Agent监控线程池队列；Pass组件则可以监控接口连接、流量等。所以相较于应用层，系统层是从进程外的视角监控整个状态。
对于K8s集群的使用人群，美团还建设了MPS，能够提供K8s集群视角的监控能力。
当这些层次都建设完毕后，Raptor的监控功能已经相对完善，但监控指标散落在各个领域，查看起来非常不方便。所以美团建设了大盘领域。
大盘领域提供数据汇总的能力，通过配置可以将各个领域的监控数据整合在一张图中，展示的图表类型也非常丰富。还可以关联告警，在机房故障或大促时配置大盘值守，从而判断服务是否正常。在运维方面，也可以配置运维大盘进行观测。
加上大盘领域后，Raptor基本覆盖了美团的业务场景，能够一站式解决可观测性诉求。
但可观测性团队没有止步于此。为了更加完善Raptor，团队在实际业务中寻找用户痛点，提取其中共性并进行改善。
团队总结出解决痛点的四个关键词：复用、升级、新建和开放，随后进行完善建设。
完善Raptor的第一个建设是对存储进行分级，也就是冷热分离。同时对数据进行降采样，保证存储旧数据时存储力度足够粗。另外在设计过程中，由于每个领域的监控诉求不一样，所以存储设计也不一样。
第二个建设是针对降低时延设计的架构。当用户Client将可观测数据上报到接入层后，查询层查询存储设备的同时，也能直接在接入层的内存查询，从而保证数据上报后立即展示，整个时延在秒级以内。除此之外还有容灾和隔离性的建设。
Raptor的“实战”表现
综合以上Raptor的所有建设和能力，可以说Raptor从宏观的观测角度到具体细节共分为五个层次：大盘、端到端、应用层、系统层和链路。这五个观测领域能够满足不同观测员、不同阶段的观测需求。当遇到问题时，观测员可以逐级向下使用。
这种观测链路在实际应用中有什么优势？当观测员检查公司Hbase服务的可用率时，不仅可以看到整体的可用率，输入具体集群名称还可以查看具体集群的可用率。从宏观到微观都可以进行观测。
另一个实际案例是故障排查。当观测员收到Hbase可用率告警时，排查思路首先是使用Hbase客户端检查Client服务是否有网络故障或使用参数不符合预期，从Client视角排查报错的监控指标。确认Client正常后，再排查Hbase集群服务指标是否正常。这种方式可以监控整个链路，无论是Client还是Hbase导致的问题都能被排查。
这种故障排查方式应对的是后端问题，偏重后端服务。而端上的故障排查则在大前端领域进行。当发现某URL成功率下降，可以观测该URL对应的具体后端服务指标是否正常。如果后端服务指标正常，则可以基本确定是中间网络层出现问题。这种排查方式可以将自身服务、端上服务和中间网络层服务全部纳入。
在未来，Raptor会“飞”得更高更远
若想飞得更高更远，则需要克服面临的困难并规划好未来路线。在分享的最后，任天谈到了Raptor面临的挑战和未来规划。
第一个挑战是容灾。在容灾过程中，不仅需要保障自身机房容灾性，还要保障外部依赖的机房容灾性，从而确保可观测性平台的可用性和稳定性。所以在未来需要减少外部依赖并提高全链路容灾降级能力。
第二个挑战是建设拓扑链路。现在美团大部分的服务都是微服务，微服务及其接口的调用量巨大，关系复杂，所以需要进行梳理。针对这一挑战，未来需要重点建设全量拓扑链路和技术运营，包括分析根因定位及上下游链路。
除此之外，任天还提及到了其他的三点规划。第一点是精细化可观测性，从分钟力度到秒级力度，甚至到亚秒级力度，以及扩展维度。
各个系统也有规划，比如将指标、链路和日志进一步深度融合，从而更好地定位故障；还有将监控系统与企业内部系统、运营系统打通。
最后是运营规划。可观测性系统不仅用来观测，未来也会用于运营，比如运营人员分析订单量从而运营业务指标。
在未来，期待Raptor“飞”得更高更远！以上内容整理自美团技术专家任天在WOT全球技术创新大会2023·北京站《可观测性技术与实践》专场中的精彩分享。获取完整PPT请关注51CTO技术栈公众号，后台发送【WOT2023PPT】即可直接领取。
