天津市神州商龙科技股份有限公司成立于1998年，是一家专为餐饮行业提供数字化整体解决方案及咨询业务的高新技术企业。秉承着“产品是第一生产力”的发展理念，神州商龙凭借过硬的产品与服务质量，为呷哺呷哺、大董、新荣记、刘一手、巴庄、小龙坎、五谷渔粉、陶陶居等10万余家知名餐饮企业的用餐体验保驾护航。
在千万百姓线下用餐体验背后，是容不得一分一秒的服务中断。因此，业务稳定性成为重中之重。一路走来，从IT自建到迁移到阿里云。神州商龙团队在探索云原生化的同时，也在积极探索如何借助可观测提升业务稳定性。
神州商龙探索容器化、微服务化过程中，可观测性建设遇到了什么挑战？
● 业务技术架构多样性，如何打通数据孤岛构建统一监控技术栈
神州商龙作为餐饮 SaaS 领域的龙头企业，借助阿里云的算力和 PaaS 服务支撑了几十套在线 SaaS 业务应用。每套业务应用由于需求不同、不同时期研发、业务属性不同等特点，技术架构差异较大。有些业务使用 PaaS 云服务较多，有些应用使用自建中间件多，整体上运维管理痛点突出。与此同时，随着新项目全部上云，部分存量项目还在自建基础设施中。如何让处在不同基础设施上的业务可以使用相对一致的监控技术栈，是团队一直追求和研发的方向。
● 海量业务背后的高可用要求，性能监控与异常检测困难
神州商龙服务10万余家餐饮厂商，一旦业务出现问题影响范围巨大。良好的可观测性建设可以更快地发现风险、定位故障、解决问题。与此同时，为了实现更加敏捷的应用开发，神州商龙尝试微服务架构，但随着微服务数量不断增加，单个服务性能监控和故障诊断变得越来越复杂。传统的监控工具在实时性和准确性上都不太能够满足需求，特别是在大规模分布式系统中。当系统出现性能瓶颈时，很难快速定位问题所在的微服务或具体的方法。
● 如何提升资源利用率，更清晰的进行成本核算
随着企业不断发展，如何更高效的控制IT成本、持续优化资源利用率成为技术团队不断挑战的目标。传统工具在多租户、大规模环境下，资源监控粒度和准确性都存在不足，导致资源利用率不高，运营成本增加。需要实时监控并分析资源的使用情况，以确保资源的高效利用。然而不同的项目对于运营团队来说需要独立核算成本，控制资源使用。良好的可观测数据为控制成本带来了数据抓手。我们需要在可观测数据中能够清晰、简单地隔离不同的项目或业务。
面对这些业务痛点，神州商龙尝试了哪些方案？
● 自建 Prometheus 监控
在进行业务容器化改造过程中，我们接触到了 Prometheus 及生态项目。它非常适合于容器部署的应用和基础设施。结合 Grafana 实现整套的数据采集、存储、告警和可视化。开源社区提供了很多 Exporter，让我们可以很方便地建立起对各种中间件的监控。因此我们很快就把整套平台搭建起来了。 但随着监控规模扩大，问题又出现了：
1. 可用性难以保障
面对大量数据存储，虽然社区提供了 Thanos 等方案来实现横向扩容，但我们在实践过程中发现技术门槛越来越高，管理和配置成本逐渐超过团队可负担范围。数据安全逐步不可控，也出现过多次数据无法查询的故障。
2. 查询性能出现瓶颈
我们的业务团队需要稳定、快速的数据查询。但自建 Prometheus 服务随着数据规模变大数据查询出现性能问题。遇到较大范围的数据查询总是让 Prometheus Server 内存占用和磁盘 IO 变得很高，我们不得不更换更高性能的磁盘。
3. 数据割裂
随着我们业务陆续云原生化并使用各种中间件云服务。阿里云上容器和部分云服务监控数据已经存储到云上 Prometheus 实例，这种情况下数据就产生了一定割裂。
● 自建 SkyWalking 监控
随着业务团队逐步使用微服务架构，传统的监控手段已经难以满足现代分布式系统的监控需求。对于应用的链路追踪和 APM，我们首先选择了 SkyWalking 方案。该项目我们认为有以下优势：
1. SkyWalking 是 APM 领域开源社区非常成熟、活跃的项目，我们可以找到较多的实践方案参考。
2. 功能丰富，覆盖了我们使用的所有开发语言，具有较低的代码侵入性。
3. 我们可以把它产生的应用指标导出到 Prometheus 体系，从而实现告警能力和可视化能力的一致性。
虽然这些优势突出，但使用开源平台依然有很多挑战，总结下来我们主要遇到以下问题：
1. 数据采样/存储问题，数据采样能力的应用难度较高，算法单一，使得我们不得不付出更多的存储成本。我们使用 Elasticsearch 作为 SkyWalking 的存储，存储层经常出现磁盘占用过大、磁盘IO 过高而导致数据查询受阻。这里需要具备较深的专家经验来调整各种配置使其工作良好。
2. 性能开销问题，SkyWalking Agent可能会对微服务性能造成一定程度的影响，但我们不具备 Agent 优化能力。
3. 配置管理问题，随着微服务数量的增加，管理每个服务中的Agent配置文件变得复杂。
整体总结来看，我们尝试过各种开源可观测工具，每个都各有所长，也各有挑战。随着我们业务上云进入深水区，不同业务团队的架构差异逐步加大，自建中间件服务逐步减少。对于运维团队来说，愈发体会到能够全链路地获得高质量的可观测数据，建立起统一的可观测规范，这件事情比去离散地搭建不同的可观测平台显得更加重要。
具体我们考虑以下几个维度：
● 全链路覆盖且高质量的可观测数据
为了确保业务稳定、成本可控。在出现故障时能够及时定位和解决。项目需要能够从客户端、安全网关、业务网关到业务应用、依赖中间件或 PaaS 服务建立全方位的可观测数据。全链路资产与可观测数据需要能够自动关联，继而能够从各种维度去应用数据。整体上可观测数据需要可读、及时、可信、可靠。
● 标准的数据规范，控制学习成本
不同的项目对于可观测的需求往往是趋同的，我们需要统一建设可观测平台来服务不同的项目。不同的项目开发者在使用可观测数据分析或调试其业务代码时，需要较低的学习门槛。这就意味着企业在选型平台时需要完全基于开源且社区取得一致性共识的数据规范。
● 全局视图和统一的数据管理
建立全链路观测能力的基础是需要一个能够整合所有监控和日志数据的平台，以实现全局视图和深入的关联分析。这对于提高问题排查效率和整体系统的可操作性至关重要。
● 需要高效、实时的性能监控工具
鉴于微服务架构的复杂性，我们需要能够实时捕捉和分析性能数据的工具，这样才能快速定位并解决系统中的性能瓶颈和异常。
● 要求细粒度的资源监控和优化
为了提高资源利用率并降低运营成本，需要细粒度资源监控和管理工具。通过这些工具，更加准确地调配资源，实现动态扩展和自动调整。
神州商龙选型阿里云 Prometheus、日志服务等可观测产品搭建统一可观测平台
● 完善的可观测数据池
选用阿里云全栈可观测产品，让我们可以专注于挖掘数据价值而不用再考虑工具建设。上面这个架构图是在跟阿里云同事交流时一张数据统一化的架构图，这张图的思想完美切合商龙运维团队的思考和目标。我们需要一种能覆盖客户端到服务端、中间件到应用、指标到日志的统一数据架构。总结下来，我们主要认为以下几点至关重要：
● 统一的可观测数据平台（集中管理、全局视图、关联分析）
Prometheus 和日志服务 SLS 为我们提供了一个集中化的可观测数据平台，可以覆盖我们需要的所有数据类型。这大大减轻了我们管理多个独立系统的负担。通过统一的平台，我们可以获得从应用性能到系统资源使用情况的全局视图，有助于进行全面的分析和优化。通过统一的数据视图，可以轻松关联不同服务之间的监控数据和日志，有助于快速定位和解决复杂问题。
● 高性能和高扩展性的监控能力（实时性、大规模、自动化）
日志服务 SLS 和Prometheus 提供了高效的实时数据采集和存储能力，能够及时捕捉和处理性能数据，以及快速发出报警。同时，Prometheus 和 SLS 都具备高扩展性，能够轻松应对我们不断增长的微服务数量和日志数据量。这让我们能够从容应对业务扩展时所带来的监控需求增加。
● 灵活的查询和分析能力
Prometheus 提供的 PromQL 查询语言，和 SLS 的 SPL 查询使得我们能够灵活地定义和检索监控指标，进行深入分析。SLS 支持复杂的查询功能，可以对日志数据进行深度分析和过滤，帮助定位问题根源。整体查询性能很好，这使得问题排查更加高效，减少故障解决时间。另外平台也基于不同场景提供的开箱即用的分析视图，包括应用分析、链路追踪分析、各种云服务性能分析、自建中间件和基础设施分析等。我们只需要根据业务自身需要定义一些聚合分析大盘和偏向于业务的分析大盘即可。
● 数据打标能力
对于从客户端到应用到后台中间件的监控指标数据、链路追踪数据。都需要将所属监控对象、业务标签、项目标签等基础数据与监控指标关联。从而实现从不同维度的数据分析和数据利用，这是实现不同项目、不同业务精细化观测和成本控制的关键。我们在使用阿里云提供的监控数据时发现其已经具备了较为完善的标签。例如我们每一个项目使用的基础设施和中间件服务都会在云资源上打上项目标签，当我们分析应用或服务的监控数据时，需要能够基于项目的维度进行分析，这就要求基础监控指标、应用指标和中间件服务指标都可以具备项目标签。
在这个过程中我们也参与了共同建设，我们使用到的一些服务初期存在标签不足、监控数据不足的情况。阿里云侧对于数据的需求响应很快。基本上都可以在很短的时间内得以实现。
● 数据采集 Serverless 化
对于项目组和运维团队来说，由于云上的技术架构多样性，数据采集难度很高。希望能够平台实现端到端的数据采集，对于企业来说不需要关注数据采集端的稳定性和性能等。正好阿里云的全栈可观测方案将应用、服务、计算资源的数据采集探针尽可能 Serverless 化或自动化。我们基本上不需要关注数据采集，只需要根据标准的标签去标注需要采集的目标即可。
● 优化成本
可观测数据越多、成本越大，甚至在有些情况下数据发散，导致远远超出算力成本。这对于我们来说是不能接受的。因此我们主要从几个方面来控制成本：
1. 只选择重要数据。我们对于指标池中的数据进行优先级打标。默认情况下只获取重要的数据，其他数据按需获取。这就依赖于阿里云提供的数据说明和数据按需取用能力。
2. 应用自埋点指标按照最佳实践指南，杜绝出现发散指标。
3. 应用日志区分业务日志和 Debug 日志，只针对有价值的结构化日志建立索引。
4. 充分进行采样，对于不同业务、不同应用的 APM 应用差异化采样规则。
对原有技术架构进行了何种改造/升级/重构，如何解决了前面提到的痛点？
● 引入日志服务 SLS 和 Prometheus
由于我们的业务经历过 Prometheus 和 Elasticsearch 自建过程，存量应用大多都已经遵循了 Prometheus 规范进行了业务埋点，团队对于 Prometheus 的使用经验积累也较为充足。因此所有业务线切换到阿里云 Prometheus 几乎没有架构改造和升级。我们主要做的就是制定了一套多项目、多应用关联的标签规范，在云上将所有资源进行打标以丰富可观测数据的维度。
在日志数据这一块我们主要要求业务线合理区分日志类型，切分出业务日志做主要治理和应用。
● 实现数据的打通和关联分析
我们建立了统一的数据收集和处理系统，针对部分线下业务和自建业务，实现指标、日志数据统一到阿里云。所有监控指标和日志数据都中央化存储和管理，通过统一界面进行查看和关联分析。这让我们可以轻松地跨服务、跨系统进行排查和分析，提高故障排查效率。
● 优化资源监控和管理
结合阿里云可观测产品，我们建立了细粒度的资源监控框架。通过 Prometheus监控每个容器、每台服务器资源使用情况，包括 CPU、内存、网络和存储等。SLS 则用于分析日志资源，确保日志数据完整性和一致性。我们利用阿里云自动化调度和扩展策略对资源进行动态调整。例如，在负载高峰期，系统可以自动扩展更多的计算资源，而当负载降低时，系统会自动缩减资源，确保资源利用率最大化，降低运营成本。
● 自动化告警和响应机制
通过日志服务SLS和 Prometheus 的智能报警能力，针对各类异常情况（如 CPU 使用率过高、内存泄漏、请求延迟增加等）进行实时报警。例如网络拥堵或资源不足时，可以自动进行扩容、重新部署或触发其他响应措施，确保系统持续稳定运行。
通过 Prometheus 和 SLS 的统一监控和日志平台，不同团队可以共享和分析同一套数据。这使得开发、运维和技术支持团队能够协同工作，快速解决问题，并实现跨团队协作的数据共享和工作流整合。当某个异常报警触发时，可以自动生成问题工单并分派给相关团队进行处理，确保问题得到及时有效解决。这些改造和升级不仅解决数据孤岛问题，同时也大幅提升性能监控能力，优化资源利用并改善跨团队协作效率。通过这些改造，我们建立了一个高效、可扩展、智能的可观测体系，为业务稳定运行提供强有力支持。
针对神州龙商痛点，在使用可观测产品方案后，对业务产生哪些价值？
- 监控效率的提升
通过统一监控平台，运维人员不再需要在不同的监控系统之间频繁切换，显著提升整体监控的效率和准确性。
- 有效缩短故障排查时间
借助实时性能监控和日志分析，我们能够快速定位问题根源，将故障排查时间缩短。这不仅提高系统可用性，也大大减少因故障导致的业务中断时间。
- 大幅提升系统稳定性
通过自动报警和实时响应机制，系统整体稳定性与服务可用性得到显著提升，这种改进对于我们提供不间断服务至关重要。
- 有效优化资源利用率
通过精细资源监控和管理策略，资源利用率的提高不仅减少不必要的资源浪费，也显著降低运营开支。
在未来，神州商龙对可观测性还有哪些期待和规划
● 引入机器学习和 AI 技术，全面增强智能化能力
希望在现有监控系统中集成更多的机器学习和人工智能技术。通过分析历史数据和实时监控数据，预测潜在的性能问题和异常行为，做到提前预警和预防。例如通过训练模型识别异常模式，可以在问题发生前采取措施，减少故障发生率和影响范围。
● 提升自动化运维水平
希望进一步深化自动化运维的实践，通过自动化工具和编排系统，实现从监控、报警到响应、恢复的全流程自动化管理。当系统检测到异常时，自动触发恢复脚本和扩容策略，尽量减少人工干预，提高系统的自愈能力。
● 更深入的可观测性集成
希望将更多业务系统和第三方服务的监控数据整合到统一平台中，实现更全面的可观测性。通过打通不同来源数据，实现更精准的关联分析和全局监控。
● 更低的平台使用门槛
随着企业业务规模持续扩大，项目越来越多。不同项目从立项到上线，可观测能力希望可以智能识别，一键接入。无需运维管理人员反复梳理技术架构也可观测需求，平台能够按照项目技术架构直接提供最佳实践。
