客户挑战

• 基础设施使用Zabbix，UI 交互比较原始，不易使用，不便于分析数据；
• 日志管理曾使用阿里云SLS，前端观测使用 Bugly 收集的信息不准确；
• 监控告警不及时，仅收集崩溃等错误信息，无法做用户行为分析。

解决方案

针对监控平台对于性能、采集、实时监控告警的诉求，观测云提供了相应解决方案帮助客户解决上线后的数据采集、查询、分析和监控告警等问题。

• 观测云的日志服务提供日志提取，聚合，可视化，异常检测和告警等能力，帮助极致游戏实现异常业务日志分析，快速识别登录异常，玩家掉线，操作报错等错误，并提供实时电话告警能力；
• 观测云前端 SDK 兼容 Unity，实时收集游戏用户行为数据，包括崩溃，Error，前端日志，Action等信息。

客户价值

• 通过强大的日志字段提取和监测能力，实现故障及时告警，降低对业务的影响；
• 通过对用户行为数据追踪和分析，持续优化游戏用户体验，增加用户留存，减少流失率；
• 在新开服期间，通过观测云赋能压力测试，快速识别压测期间性能瓶颈，定位根因，确保新服上线成功。

客户挑战

• 为了应对可能成为爆款的游戏会存在瞬间出现大量的登录请求的情况，客户尝试通过服务的容器化部署，并利用 HPA（Horizontal Pod Autoscaling）的功能，在请求量突增的情况下，通过快速的弹性自动扩容来提高系统的承载能力。 IT 人员亦是如此，甚至开发与运维间相互看不懂数据；
• 使用公有云上 Kubernetes 集群，期望通过容器服务的自动弹性扩容功能，让业务相关服务能达到瞬时 5W RPS 的承载能力。通过压力测试，发现 6 个 Pod 的情况下，RPS 的承载峰值为 2W 左右。增加到 12 个 Pod（相同资源配置），RPS 的承载峰值为 2.4W 左右，继续扩展性能几乎不再提高。

解决方案

• 在容器服务环境中部署 DataKit，接入链路和日志数据；
• 在压测的过程中通过观测云应用性能监测的服务概览页面，可以快速定位疑似性能瓶颈的服务和相关资源。结合云上 Redis 的分析，对 Redis 的使用请求基本达到了配置规格能支持量的峰值；
• 在观测云中开启 Profile 的采集功能，结合应用链路进行性能分析，主要关注在“Lock Wait Time” 和 “Socket I/O Read Time” 的指标上，从而定位到代码中通过不同的实现方法频繁调用Redis来完成相关的操作。将其反馈给研发人员，进行代码的调优。

客户价值

• 代码迭代上线新版本后，在新一轮的压测中，不改变原有资源配置的情况下，RPS 峰值达到 8W 左右，超出客户原来的预期。