链路可视化如果是基于进程级别的,其实不是特别在意是容器环境还是虚拟机环境,都是向下屏蔽的。如果预算有限,建议使用开源的skywalking方案,该方案无入侵,功能强大,社区活跃,建议使用。
收起APM (ApplicationPerformance Management) 即应用性能管理,属于IT运维管理((ITOM))范畴。主要是针对企业关键业务的IT应用性能和用户体验的监测、优化,提高企业IT应用的可靠性和质量,保证用户得到良好的服务,降低IT总拥有成本((TCO))。
基于微服务的端到端的监控是比较复杂的,链路可视化的目的为了构建一个闭环系统,以监控应用本身的性能为主,,应用性能管理的重点也开始聚焦于应用本身的性能与管理上。做到可视化管理的目的和运维的方向
针对微服务的链路分析的场景,容器环境对比虚拟机基本类似,比较典型的差异还是来自容器化本身,如:
(1)容器可以快速扩容出多个副本,也有可能比较快的完成缩容
(2)容器的网络环境可能是overlay、underlay或者routing,因此ip不能作为唯一标识
因此,工具的选择大体上与虚拟机上运行微服务类似,主要是对语言的兼容性、自定义标识的扩展性以及可视化能力,如果是Java应用,个人比较推荐使用skywalking作为采集端,如果没有特殊的需求,可以直接使用skywalking的服务端,否则也可以选择分析和可视化部分进行自研。
针对容器的环境下,需要注意如何更好的定义服务的标识以便更好的标识链路数据,基于pod name是个比较好的办法,但也需要全局做好naming的规范,避免在后续分析时的障碍。
收起近年来随着容器和微服务发展,各种链路监控产品层出不穷,像Jaeger、Zipkin、SkyWalking、 Pinpoint、Elastic APM、CAT等 ,一般建议参考几个方面:
1、侵入性
2、扩展性
3、性能损耗
4、界面图标
5、业务能否hold住
6、OpenTracing 标准
CNCF 推出 OpenTracing 标准,统一了 Trace 数据结构和格式,通过提供平台无关的 API,使得开发人员能够方便的添加追踪系统的实现,建议选型参考这个标准。
综上,建议Jaeger或者SkyWalking:
1、Jaeger 部分侵入,go语言,遵循CNCF组织规范;
2、SkyWalking 侵入性低,java语言,国内当当、华为使用;
在容器中发布微服务,对微服务链路可视化,目前有两种方式:
1、通过埋设探针对微服务各个服务进行监控与数据收集,简单、易上手。
2、通过旁路探测的方式对请求服务进行监控,复杂、工作量大。
下面介绍通过探针的方式对微服务进行链路监测与可视化,目前市场上开源框架基本都是从openAPM框架演化而来,如:Zipkin、SkyWalking、 Pinpoint、ElasticAPM、CAT等。
目前市面上比较流行SkyWalking、Zipkin、Pinpoint这个比较主流,功能比较完善,支持分布式跟踪、监控、各种性能指标,与周边其他开源项目融合比较紧密,接口完善、数据打通、支持可视化展示与扩展接口。
全链路监控可视化解决哪些问题:
• 请求链路追踪:通过分析服务调用关系,绘制运行时拓扑信息,可视化展示。
• 调用情况衡量:各个调用环节的性能分析,例如吞吐量、响应时间、错误次数。
• 容器规划参考:扩容/缩容、服务降级、流量控制。
• 运行情况反馈:告警,通过调用链结合业务日志快速定位错误信息。
优势:APM工具对代码侵入性比较小或无侵入的集成到现有微服务当中,减少开发人员工作负担与透明接口。
我们是进行了分类,微服务的监控使用的skywalk进行链路监控;容器的监控使用另一套监控,即将容器一定程度上作为基础架构进行的监控。
还有就是,容器的名称和微服务名称保持一致,这样可以更好地监控和管理。
1、数据采集
数据采集主要包括日志、监控指标以及链路的数据采集。
日志类:通过文件和Logstash采集
监控指标类:对接监控平台和日志平台
链路:异构系统通过kafka统一上报链路topic,java类应用可以通过SDK方式采集。
容器:容器中的日志和指标通过Kafka统一上报。
2、实时计算
通过实时流计算引擎,对采集的数据解析、数据存储、指标聚合、调用拓扑计算等实时计算功能,形成展示数据。
3、可视化
实时监控系统的门户,可通过Echart和D3统一展示链路和实时告警。
如果不需要深入到代码级别的监控,可以考虑Sysdig及Sysdig monitor。
Sysdig Monitor使用eBPF协议直接从内核获取所有系统调用的信息,应用程序无需在代码中或容器运行时进行任何修改。相较于APM深度代码级别的监控更加轻量,对应用的影响也会更少。
系统调用可以提供有关正在运行的进程,内存分配,网络连接,对文件系统的访问以及资源使用情况等信息。能够展示容器环境下应用和服务的调用链,也包括请求、延迟、错误、分位数等信息。足够用于故障的定界,快速判断是基础设施、网络、应用还是容器本身的问题导致的故障。
当然,如果需要进一步找到是哪行代码出了问题,还是需要APM的能力。