在远程监控基础知识和故障排除中，我们探讨了
Windows Azure 平台提供的基础指标、信息源、工具和脚本，介绍了有关监控和应用程序运行状况的基本原则。我们演示了如何利用这些基本原则对在 Windows Azure 上部署的简单解决方案（少数几个计算节点实例，单个 Windows Azure SQL 数据库实例）进行故障排除。在本文章中，我们将详述该主题并讨论在
Windows Azure 中的云服务基础项目中实施的远程监控系统的应用程序运行状况测量。在本博客随附的详细 Wiki 文章中，我们将向您演示如何使用 CSF 测量框架，该框架与
Windows Azure Diagnostics (WAD) 集成，可为您的应用程序提供统一的运行状况测量体验。CSF 应用程序中使用的技术的可靠性已在大规模 Azure 部署上得到证实。
关于您的应用程序的最佳信息来源是应用程序本身。虽然可以凭借良好的工具和强大的远程监控系统更轻松地获取信息，但如果不首先测量应用程序运行状况，则根本无法获取信息。此外，如果您没有持续测量所有应用程序组件的运行状况，则在生产中开始伸缩时不太可能达到运营效率。（故障排除问题变得复杂得多，个人甚至团队都无法立即解决。）只有持续测量整个应用程序的运行状况并使用该测量进行远程监控，才能相对高效轻松地大规模提取维护应用程序正常运行所需的信息。
CSF 提供了一些组件，可用于快速测量应用程序运行状况，并构建一个有效的远程监控系统：
· 数据访问层提供了重试逻辑、并提供专为伸缩而设计的合理重试策略。
· 构建于 NLOG 之上的日志记录框架
· WAD 的可伸缩自定义配置，支持伸缩。
· 将此信息收集和移动到可查询的远程监控系统中的数据管道。
· 运营远程监控报告的样本集，可用于监控应用程序
通过采用这些做法及使用所提供的组件和配置，有助于系统进行伸缩，并让您深入了解如何制定更精确的开发计划和提高运营效率，从而达到使用的资源更少，客户满意度更高的最终目的。这让您可以提供高品质的用户体验，并先于用户预测即将发生的问题。请参阅相应的 Wiki 文章，深入了解“远程监控：应用程序运行状况测量”
该文章可轻松读完，但您可能一直忙于增加用户群和部署新的代码功能而未能阅读。
不要相信这种感觉。许许多多企业的一些热门产品或服务都在某些时候无法伸缩，并出现过一次或多次长时间停机。用户往往很少会长期使用一个不可靠的系统，他们可能会选择改用其他系统，也许会使用试图与您竞争并抢夺市场的创业公司的系统。
当然，有些人可能已经构建了自己的应用程序运行状况测量框架并实施了许多最佳做法。出于该原因，我们在 codeplex.com 上提供了将所有远程监控组件作为源代码的完整
CSF 应用程序。在应用程序中实施运行状况测量时，请注意以下关键事项：
· 为大批量（高容量、高延迟、精细数据）和零碎（低容量、低延迟、高价值数据）创建分开的通道。
· 对于零碎信息使用标准 Windows Azure Diagnostics 信息源（如性能计数器和跟踪）。
· 记录对外部服务的所有 API 调用，包括上下文、目标位置、方法、计时信息（延迟）和结果（成功/失败/重试）。使用大批量日志记录通道，以避免因测量信息过多而导致远程监控系统崩溃。
· 记录完整的异常详细信息，但请勿使用 exception.ToString()
· 写入表存储中的数据（性能计数器、事件日志、跟踪事件）都写入到一个临时分区中， 60秒后再真正上传到存储服务器。试图写入过多数据（点来源过多，收集间隔过低）会导致分区崩溃。确保错误突增不会触发大量试图插入表存储的操作，因为这可能会触发限制事件。
· 使用记秒表方法收集数据库和其他服务的响应时间
· 使用常用的日志记录库（如 Enterprise Application FrameworkLibrary、log4net 或 NLog）对本地文件进行批量日志记录。使用诊断监控配置中的自定义数据源，定期将此信息复制到 Blob 存储。
· 请勿将实时站点数据和远程监控信息发布到同一个存储帐户中，而应使用专用的存储帐户进行诊断。
· 选择适当的收集间隔（5 分钟至 15 分钟），以减少必须传输和分析的数据量，例如，“PT5M”。
· 确保可以在运行时修改日志记录配置，而不必强制重置实例。还要验证配置是否足够精细，以便能够记录系统的具体方面，如数据库、缓存或其他服务。
感谢您抽出时间阅读本博客文章。若要了解如何在应用程序中实施 CSF 测量组件的详细信息，请参阅相应的 Wiki 文章，深入了解“远程监控：应用程序运行状况测量”。在本系列的下一篇文章中，我们将探讨我们已实施的数据管道，以全面介绍整体
CSF 应用程序及其性能特点，包括我们如何在跨越了整个 Azure 平台的关系运营存储中获取此信息。
本文翻译自：