37 lines
3.8 KiB
Markdown
37 lines
3.8 KiB
Markdown
|
||
|
||
因收到Google相关通知，网站将会择期关闭。相关通知内容
|
||
|
||
|
||
21 结束语 未来的监控是什么样子？
|
||
到这里，专栏的学习就进入尾声了，感谢你一直以来的学习，和我一起走到了这里。
|
||
|
||
课程回顾
|
||
|
||
在整个课程中，我带你认识了可观测性的重要性、如何将告警与可观测性相结合，以及如何将可观测性落地到项目中。这些内容，我将它们一共分成了 3 个模块：
|
||
|
||
在“模块一：可观测性原理”，我介绍了可观测性中的 3 大支柱：日志、统计指标和链路追踪，以及如何将它们结合到你的业务代码开发中，让你的程序更加具有可观测性。高度定制化的可观测性，可以让你更加了解你的程序，出现问题时也可以根据观测中的数据，快速定位问题产生的原因，从而解决问题。
|
||
|
||
在“模块二：告警体系与可观测性”，我带你了解了如何快速感知业务中可能发生的问题，以及问题发生后一般是怎样的处理流程。通过这部分学习，你可以了解到怎么发现问题，发出告警，告警后如何保持高效的处理，并将告警流程实现闭环。
|
||
|
||
在“模块三：可观测性的实践应用”，我列举了目前市面上比较常见的可观测性工具，比如日志系统 ELK、统计指标系统 Prometheus、链路追踪系统 Zipkin和SkyWalking，以及像 ARMS 这样的云观测系统。最后我还带你了解了怎样将可观测系统和你公司内部的系统更好地结合，将可观测性与告警落地到你的业务开发、项目使用上。
|
||
|
||
未来展望
|
||
|
||
随着技术的更新迭代，云原生倡导的范式给开发和运维的方式带来巨大的冲击，比如微服务可以让开发同学更关注自己服务本身的业务，DevOps 利用持续交付、持续集成让开发和运维的协作模式更加一体化等。分布式系统架构不仅使我们的工作变得高效，它也使系统更难被观测，出现问题时，分布式系统架构寻找问题产生的原因往往需要花费高额的时间成本。
|
||
|
||
随着分布式系统架构的普及，开发和运维人员对可观测性越来越重视。无论系统架构怎样变化，唯一不变的是需要对它们进行观测。我相信随着可观测性的普及，会有越来越多的人参与到可观测性系统的开发上。对于业务开发人员来说，了解可观测性中每一个概念的关键原理，并结合公司内部的可观测性框架来编写高度定制化、可观测的代码，让你更快解决问题。
|
||
|
||
现在可观测中，因为目前没有一套完整的成体系化的内容，所以可以看到现在很多有较大规模的厂商都在做不同的尝试。
|
||
|
||
在数据规范协定中，OpenTelemetry 就在尝试将日志、统计指标与链路这 3 个概念融合，让其拥有统一的数据格式；在告警问题归因上，阿里巴巴的鹰眼就在尝试利用可观测性中的数据，做问题的归因判断，减少开发人员发现问题的时间。
|
||
|
||
我相信可观测性在未来肯定还会有更多变化与改进，但这些变化和改进的最终目的都是服务开发人员的，都是用来帮助开发人员定位和解决问题的。计算机再强大，也离不开开发人员。
|
||
|
||
总结
|
||
|
||
可观测性中的每一个环节都是一套完整的系统，在学习可观测性的过程中，你可以了解到系统之间的交互时最通用的底层实现逻辑。我的课程除了带给你所需要的知识外，更希望能给你建立一个知识框架，你可以依据这个框架去学习更多的知识，最终形成你自己的知识体系。
|
||
|
||
|
||
|
||
|