案例精彩导读
成都华律网络服务有限公司
简称「华律网」www.hualv.com，成立于 2004 年，深耕互联网 + 法律行业 18 年，是全国最大的一站式在线法律服务平台。截至 2022 年 1 月，平台当前注册用户 1.6 亿，注册律师 40 万，占全国律师总人数三分之二，注册律所 1.5 万家，新媒体粉丝超 2000 万；日独立用户访问量 1100 万，日咨询量 16.5 万，累计咨询服务人次达 4 亿；优质法律知识内容超 9 亿条，年普法人次达 50 亿；成立至今累计注册企业数量达 400 万左右，年注册量 30 万左右。
案例亮点
（1）大型门户网站可观测最佳实践
（2）RUM + 容器监控 + APM + 日志分析 + 可视化面板，全功能一体化可观测体验
（3）实时快速定位故障点
（4）SaaS 交付，按量计费，实现成本优化
1.简单介绍一下贵公司
成都华律网络服务有限公司（简称华律网）成立于 2004 年，深耕互联网 + 法律行业 18 年。依托「普法服务」「咨询服务」「非诉法律服务」和「线下律师匹配服务」四大核心功能，为个人、企业和政府提供一站式法律服务。以「让所有人享受到普惠、优质、高效的法律服务」为使命，致力于成为全球知名的一站式法律服务平台。
截至 2022 年 1 月，平台当前注册用户 1.6 亿，注册律师 40 万，占全国律师总人数三分之二，注册律所 1.5 万家，新媒体粉丝超 2000 万；日独立用户访问量 1100 万，日咨询量 16.5 万，累计咨询服务人次达4亿；优质法律知识内容超 9 亿条，年普法人次达 50 亿；成立至今累计注册企业数量达 400 万左右，年注册量 30 万左右。旗下拥有三家国家认证的高新技术企业，主要荣誉包括 2021 年种子期雏鹰企业首次认证， 2021 年省级瞪羚企业认证， 2019 年成都上规入统企业， 2019 年高新区首批瞪羚企业，中国电子商务行业最具影响力奖，移动互联网行业最具投资价值奖等认证及奖项。目前为四川省互联网行业联合会成员，成都市互联网界联合会成员单位。
2.监控平台的建设思路是怎么样的？
自华律网 IT 业务系统建设开始，我们就一直在探索如何更高效的感知系统整体，做到对软硬件各层级组件运行状态的准确把控。之前可观测性这个概念在国内并不成熟，出于理论基础、技术成熟度、实施成本、团队技术成长等方面的考虑，我们主要使用一些开源组件，例如 Prometheus + Grafana 等开源工具，对现有系统进行监控和分析。监控的维度基于我们整个业务平台来做设计，但受限于工具本身的能力，实际只收集了 VM 和 Pod 级别的基础指标，实现了部分指标的监控。
这样监控其实是相对简陋的，在早期系统规模不大，应用体系不是很复杂的条件下还算够用。随着华律网业务的持续扩张，用户访问规模的不断扩大，应用构建方式也需要适应业务高速的发展，逐步向容器化、微服务化迁移，如果继续使用基础监控排查问题就有点捉襟见肘了。比如我们收到了客户的故障反馈，只能通过工具先简单地排查一下基础设施资源的占用，看看 CPU / 内存等硬指标有没有问题；如果没有异常，再进一步排查云厂商的各项服务有没有告警；如果还是没有线索，就只能回到比较原始的故障分析方式——打日志 + 复现。
而在分布式微服务的语境下，先不讨论能否重现故障，或是否能通过新增日志准确捕获这个故障，且日志打印刚好提供了足够的诊断信息。我们首先需要解决的问题就是，识别出故障点在哪里，发生故障的是哪个服务？我们应该为「谁」增加定位日志？
在故障发生时，无法有效定位故障点，一直是影响我们在线业务恢复及故障修复效率的最大痛点。针对这个问题，整个团队也一直在持续探索新的解决方案。
3.怎么会关注到观测云的？
在新的业务平台整体监控方案探索中，我们初步明确了所需监控工具的几个重点技术特征：
（1）监控维度必须全面，具备在系统各个层级收集数据的能力，特别是应用链路数据，可以很好地补充故障发生时的各种信息；
（2）支持分布式微服务追踪，这个也是我们现在在使用的业务架构；
（3）数据实时性高（及时发现问题），业务系统侵入小（降低引入成本）；
（4）如果可以的话，最好能自动整合指标、自建日志和云原生服务的数据，放在一个界面上大盘展示出来，或者至少在一个工具界面通过简单的操作就可以看到所有信息。这样就不需要在 Grafana 和云监控的界面之间反复横跳了，能够提升一些效率。
其中，链路追踪（APM）的部分相对复杂，也是我们技术方案选型工作的切入点。APM 不是一个新概念，市面上也有很多成熟的产品可以使用。由于我们后端服务是混合技术栈 Java + .NET ，对 .NET 的支持友好程度是一个比较重要的考虑点。
我们考察了很多方案，如开源的 SkyWalking 、Jaeger 、 Zipkin 以及一些商业方案等。除了 DataDog 的 dd-trace-agent 外，其他 APM 探针对 .NET 的支持都不太全面，而且有一定的开发工作量。因此，我们最理想的工具选型，要有不弱于 dd-trace-agent 探针的能力（或直接可以复用），来实现分布式全链路追踪，还要具备上述提到的其他技术特征，来提升我们的整体监控效能。观测云就是在这样的背景下进入了我们的视野。
4.观测云是怎样帮助您快速定位故障的？
在确定新的监控平台建设方向后我们就开始了对观测云的试用和研究。首先从产品功能层面来讲，除了传统监控层面的指标、日志数据外，观测云还支持 dd-trace-agent 的接入，可以实现应用链路追踪功能。再通过他们的前端插件，可以将网站和小程序的访问情况收集下来。其次，收集到的所有数据都可以通过数据标签体系进行关联，在一套界面上展示所有的信息。
现在遇到问题时，比如我们发现用户的一些请求比较缓慢，就可以直接在链路中定位到具体的位置了。这个位置可能是某个接口，某个云服务比如 Redis ，或者某个数据库服务。以前加日志找问题来来回回可能要几个小时，现在我们几分钟就可以定位到问题了。
而且观测云提供了开箱即用的各种预制面板，我们可以快速地发现当前有哪些服务是有问题的，哪些接口的响应时间比较高，哪些接口经常出错。对问题处理效率提升很大。
这个效率的提升是基于业务系统全层面数据的实时收集能力实现的。观测云展示的是故障发生时的数据，帮助我们全面清晰地了解「当时」发生了什么，而不是「之后」再去尝试拼接复现。要知道单从技术层面去复现某个问题有些时候是非常困难的，而拥有业务全层面数据采集能力，就可以很好地解决这个问题，所有的状态信息都被有序有关联的记录下来了，等于我们有了一段段事故现场影像，避免无效地研发定位投入。
另外，对观测云产品团队的迭代效率印象也非常深刻。其实我们算是观测云比较早期的用户，非常早期的那种，早期到当时的产品还不叫观测云，也不支持 K8S 接入（笑）。数据源的部署也有一些不方便的地方。但是观测云产品开发团队的响应速度很快，通过不断的产品迭代，修复各种试用过程中的问题，实现用户反馈的试用意见，开发新的功能来支持更加复杂的业务系统。到今天我们正式上线时，已经成长为一个全功能平台，并且还在不断地发布更新来满足更多的需求。
5.您对观测云还有什么建议？
目前观测云产品已经引入到我们的生产环境中进行常态化使用，对于长期使用的产品我们也比较关注功能和成本的平衡。近期观测云进行了一些计费策略的调整，这个非常好。观测云可能是我们看到的国内仅有的全 SaaS 化交付，且按量计费的可观测工具，加上产品本身在持续优化采集策略，我们现在能看到的数据更多了，但好像综合使用成本反而更低了。希望后续能有更多的类似策略帮我们以最优的成本使用各项观测功能。
我们开发运维团队近期在逐步探索将服务治理引入到华律网微服务体系中，希望观测云在服务治理方向上能够有更多的产品功能和最佳实践提供出来。
作者｜华律网运维技术专家 ——方志鹏
观测云产品技术专家——张田
关于观测云
观测云（ www.guance.com） ，新一代 SaaS 化全链路数据可观测平台，国内首批获得中国信通院颁发的「可观测性平台技术能力」最高级别「先进级」认证，实现统一采集、统一标签、统一存储和统一界面，带来全功能的一体化可观测体验。观测云能全环境高基数采集数据，支持多维度信息智能检索分析，及提供强大的自定义可编程能力，使系统运行状态尽在掌控，故障根因无所遁形。
