Azure Service Fabric 的监视和诊断最佳做法

在任何云环境中开发、测试和部署工作负荷时,监视和诊断至关重要。 例如,可以跟踪应用程序的使用方式、Service Fabric 平台所采取的操作、带性能计数器的资源利用率以及群集的总体运行状况。 可以使用此信息来诊断和更正问题,避免将来发生此类问题。

应用程序监视

应用程序监视跟踪应用程序的功能和组件的使用方式。 监视应用程序可以确保捕获影响用户的问题。 应用程序监视是开发应用程序及其服务的人员的责任,因为它特定于应用程序的业务逻辑。 建议使用 Application Insights(Azure 的应用程序监视工具)来设置应用程序监视。

群集监视

Service Fabric 的目标之一是使应用程序能够灵活应对硬件故障。 为了实现此目的,可以通过平台的系统服务功能检测基础结构问题,并快速将工作负荷故障转移到群集中的其他节点。 但是,系统服务本身出现问题该怎么办? 或者,在尝试部署或移动工作负荷时,如果违反服务位置的规则该怎么办? Service Fabric 为这些问题以及其他问题提供诊断,确保你了解 Service Fabric 平台与应用程序、服务、容器和节点的交互情况。

对于 Windows 群集,建议使用诊断代理Azure Monitor 日志来设置群集监视。

对于 Linux 群集,Azure Monitor 日志也是建议用于 Azure 平台和基础结构监视的工具。 Linux 平台诊断要求不同的配置,详见 Syslog 中的 Service Fabric Linux 群集事件

基础结构监视

若要监视群集级别的事件,建议使用 Azure Monitor 日志。 使用上一链接中介绍的工作区配置 Log Analytics 代理以后,即可收集性能指标,例如:CPU 使用率、.NET 性能计数器(例如进程级别的 CPU 使用率)、Service Fabric 性能计数器(例如来自 Reliable Service 的异常数),以及容器指标(例如 CPU 使用率)。 需将容器日志写入 stdout 或 stderr,使之在 Azure Monitor 日志中可用。

监视器

监视器通常是一个独立的服务,用于监视各个服务的运行状况和负载、ping 终结点,以及报告群集中的异常运行状况事件。 这有助于防止出现仅基于单个服务的性能所检测不到的错误。 监视器也是一个托管代码的好选择,无需用户交互即可执行补救措施,例如每隔特定时间就清理一次存储中的日志文件。 如果需要完全实现的开源 SF 监视服务,其中包括易于使用的监视器可扩展性模型,同时在 Windows 和 Linux 群集中都能运行,请参阅 FabricObserver 项目。 FabricObserver 是生产就绪软件。 建议将 FabricObserver 部署到测试和生产群集,并通过其插件模型或者通过分支并编写自己的内置观察器对其扩展,以满足你的需求。 建议采用前一种(插件)方法。

后续步骤