PaaS 对 APM 有何影响？

理论上，由于可以使用通用标准和工具构建 PaaS 应用程序，因此构建监控这些应用程序的功能应该是相同的。减少定制应该更容易监控，对吧？好吧，如果这篇文章的内容“研究：PaaS 市场到 2018 年将达到 $6.94B”，作者是 Chris Talbot 在 Talkin' Cloud 确实如此，公司实际上希望仔细评估他们的 APM 工具是否能够在 PaaS 环境中通过测试。原因如下：

1. PaaS 平台往往专注于某种编程语言，因此如果 APM 解决方案不监控该语言，它就无法帮助该 PaaS 环境中的任何人。如果支持不如那里的竞争对手好，那么即使他们进行集成工作，他们也确实无法在该环境中竞争。但是，如果 APM 解决方案确实支持该语言并且支持得很好，那么它添加的任何特定于该 PaaS 环境的见解都将非常有用。

2. PaaS 平台有很多抽象和隐藏层，因此在这些环境中存在监控解决方案无法捕获洞察力的区域：

• 路由： Heroku 的路由系统是这些领域之一，但监控其性能非常重要，如《驯服队列》一文中所述。

• 机器配置： APM 解决方案可能无法监控的另一个领域是文件同步的配置，因为它无法获得对机器的完全访问权限。它可能有权访问在其内部运行的编程语言，但无法访问服务器上发生的所有事情。

• 专有扩展： PaaS 环境可能具有专有组件——服务器的自定义版本和语言的自定义扩展。 PaaS 提供商对他们的组件有些保密，因为这就是他们能够扩展该环境而不用担心竞争对手的方式。因此，除非能够与 PaaS 提供商合作，否则 APM 供应商将无法监控这些组件。

• 多租户服务： 许多 PaaS 环境包含共享服务，这对于某些类型的监控工具来说可能是一个问题。多租户数据库实例相当普遍。如果监控工具代理需要与数据库对话以从中获取数据并且它是多租户的，则该工具可能没有访问权限来执行此操作。如果它没有其他方式在该 PaaS 环境中获取数据库信息，它将永远无法提供数据库指标。

• 外部服务： PaaS 环境还倾向于使用许多外部 API，这是监控工具可能会丢失数据的另一个领域。开发人员选择 PaaS 是因为它很方便，他们转向 API 是因为服务器和 PaaS 往往更小、功能更弱——这是卸载它们工作的好方法。如果 APM 解决方案没有监控 API 的能力，或者它的能力不是很强，那么这将是 PaaS 环境中的一个弱点。

监控 PaaS 的案例

如果您在 PaaS 之上运行，则有一个令人信服的内部监控案例。 PaaS 上的每个单独服务都由平台构建和扩展，但应用程序本身不是他们的责任。无论您标准化多少，总会有性能问题需要监控，您需要一个工具来做到这一点。

PaaS 提供商在内部也有其自身的复杂性。他们将拥有多种服务——一个账户系统和一个用于对 PaaS 计费的 Web GUI，另一个用于管理配置的附加组件的 Web GUI 系统，以及一个用于管理 PaaS 服务器上的配置的服务。即使服务器正在运行，如果无法将新的配置设置推送给它们，服务也会降级。该公司甚至可能使用一项服务来访问其绩效数据。 PaaS 生态系统中有很多服务值得监控，因此内部用例是保持所有服务器运行，同时优化所有基础设施部分，使 PaaS 变得如此易于使用。

下一代 PaaS

展望未来，趋势是 PaaS 服务器变得越来越小，但您确实需要监控所有这些服务器。如果您公司的监控工具不是以支持许多小型环境为导向，它的成本效益可能会降低，或者可能会出现扩展问题。此外，单个服务器比以前更短暂。它们可能只存在几个小时甚至不到一个小时，而不是像以前那样存在几天。因此，如果您的监控工具围绕着长期存在的服务器的想法，您实际上可能无法很好地应对服务器消失和重新出现而没有任何人明确说明这一点的环境。

无论您如何切片，每个应用程序都在不断发展，需要仔细规划才能有效扩展。 PaaS 供应商可以提供帮助，但这并不意味着监控没有它的位置。