开发人员经验
无服务器软件开发生命周期
快速构建，测试和部署基于AWS Lambda的应用程序，以及如何为成功做好准备。
艾米·阿拉姆布洛·尼格莱特（Amy Arambulo Negrette） | 2020年4月24日
2018年9月24日星期一
这是有关在AWS中监视生产工作负载的系列文章中的第三篇。在第一篇文章中 我们对云监控做了一个高层次的概述 并将其分为六种您应监控的指标，第二种 我们深入到CloudWatch。今天，我们将再次深入探讨自定义指标。
尽管自定义指标是许多人在最初操作其系统时的事后考虑，但我们将自定义指标视为将“良好”操作与“出色”操作区分开的一件事。
让我们看一下实现自定义指标的两个关键问题：您应该生成什么指标，以及如何生成它们？与以往的文章一样，“方法”将考虑两种以AWS为中心的方法，并引入Trek10最喜欢的运营洞察力工具Datadog的一些选项。
首先，您应该创建哪些自定义指标？您可能要考虑以下四个方面：
这已成为“重要事项”的核心。在您的应用程序和业务中。 确定平台上产生业务价值的活动。 可能是用户注册，完成了交易或提取了数据行。密切关注这一高级目标是一个安全网-如果您的系统中存在某些gemmlin，而您的系统指标都无法捕获，那么KPI将显示真实情况。
跟踪KPI的好处是可以很轻松地为您的业务主管构建仪表板。办公显示器的好草料！
假设您具有详尽的系统指标（Cloudwatch和VM，如果适用）和APM指标，那么最终您几乎可以看到系统中的任何基本行为。但是，它可能并不总是那么简单或明显，并且可能无法设置适当的警报。
为了简化问题，请添加自定义指标以跟踪特定重点领域的效果。 例如，众所周知，当您的应用程序向外部服务提供商发出请求并使用一组特定参数时，服务提供商的响应时间就会成问题。仅在那种情况下的代码中添加自定义指标，您就可以立即了解行为并对其发出警报。
This one is an easy win. Whenever you have background jobs run, have them submit a custom 公制 like JobSuccess=1 after they have completed. Almost every monitoring system has an option to alert on no 数据, so you simply create alerts for when the 公制 is zero or no 数据, 和 瞧，您将获得一个简单且高度可靠的作业监控系统。添加作业持续时间和其他指标，您可以轻松构建完整的后台作业仪表板。
不要只关注指标：考虑一下系统中哪些离散事件可能对警报或叠加在图表上以进行相关性有价值。 在您的应用程序或部署自动化中添加自定义代码，以将这些事件放入监视平台。
一个明显的事件就是部署事件：Datadog和许多其他监视平台提供了与工具等直接集成的能力 詹金斯 和 Github。如果您不可用，请在部署管道中添加脚本以发布自定义事件。其他有意义的事件可能是ETL作业开始和结束或定期进行修补时。
重要的是，您的自定义指标应尽可能轻巧：您想要的最后一件事是要管理的大型新代码库或新基础架构。因此，我们强烈建议您使用AWS CloudWatch或SaaS，我们最喜欢的是 数据狗。在Trek10，我们倾向于将大多数东西放到Datadog中。我们发现代码更简单，就像将所有内容都放在一个地方。但是，如果这不是您的选择，CloudWatch会做的很好。我们还将讨论第三个有趣的选项：记录您的自定义指标。
您可以使用CloudWatch记录指标和事件，尽管当前事件无法覆盖在图表上&仪表板。 （侧边栏……出于其他许多原因，CloudWatch 大事记是一项非常强大的服务。 这个帖子 让我们开始思考它的可能性。）
The approach is straightforward… just use your AWS SDK of choice 和 the API calls PutMetricData 和 PutEvents. In our favorite SDK, boto3，那将是 放 公制数据 和 放 _events. Make sure of course that your IAM user/role has the permission for cloudwatch:PutMetricData or events:PutEvents.
放置度量标准数据时，每个度量标准最多可以包含150个值。另外请注意，如果您有大量指标，则可能需要考虑发布 统计集 而不是每个单独的数据点。
数据狗中的自定义指标有两个主要选项（不包括我们下面讨论的日志记录选项）：
如果您的代码在安装了Datadog代理的VM上运行，则最简单的选择是使用 dogstatsd，Datadog对流行的改编 统计。这会将指标中继到代理，然后由代理将其与典型系统指标一起发送给Datadog。这是一种非常高效和高吞吐量的方法，并且还具有不需要配置其他安全性的额外好处，因为Datadog代理已经具有密钥。如果您在Linux Shell中运行，甚至可以很方便 重击一线 向代理发送指标。
如果您没有Datadog代理（即在Lambda函数中）运行，则需要使用Datadog API来 发布指标。有一个方便 Python库 以及对其他语言的支持，或者尝试 无 带有原始SDK的SDK HTTP发布.
如果您想进一步深入，这里有一个 数据狗的精彩摘要.
Structured logging is an interesting third option for pushing custom 公制s. Just drop your 公制s into your logs in some structured form like METRIC|{NAME}|{VALUE} 和 then configure your logging platform to extract those 公制s. 数据狗 has a slick feature to automatically parse these 公制s from AWS Lambda logs if they come in the form 在这里定义。也许最大的好处就是代码的简单性。完全没有额外的程序包...每个指标的一行简单的日志记录代码。但是，日志记录平台端的配置可能更复杂。另一个要考虑的缺点是成本……根据您的平台，这可能会产生额外的成本。
大多数日志记录平台（如Datadog Logs，Splunk和SumoLogic）将支持此功能，ElasticSearch的开源选项也将支持此功能。但是，如果您尝试使用CloudWatch Logs的低成本AWS本机选项，则将无法执行此操作。
这是一些可供选择的简短摘要。我们很高兴听到您对此的看法……您正在使用哪种平台来定制指标，以及您要针对哪种事件发送指标？在发起对话 @ Trek10Inc.
这是有关监视AWS中生产工作负载的系列文章中的第三篇。相关文章包括。