当我的 Amazon Web Service 使用量超过一定数量时,如何编写警报脚本?

发布于 2024-08-23 10:24:37 字数 186 浏览 8 评论 0原文

我们在一个相当复杂的项目中使用 S3、SimpleDB 和 SQS。

我希望能够自动跟踪它们的使用情况,以确保我们不会在无意时突然花费大量金钱(可能是因为错误)。

有没有办法从脚本中读取所有 Amazon Web Services 的使用数据和/或帐户的当前实时美元成本?

或者任何基于此提供警报的服务或脚本?

We're using S3, SimpleDB and SQS on quite a complicated project.

I'd like to be able to automatically track their usage, to be sure we don't suddenly spend large amounts of money when we didn't intend to (perhaps because of a bug).

Is there a way of reading the usage figures of all Amazon Web Services and/or the current real time dollar cost of an account from a script?

Or any service or script which provides alerts based on that?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

岁月染过的梦 2024-08-30 10:24:37

亚马逊刚刚宣布,您现在可以“为 Amazon CloudWatch 监控的任何指标设置警报”(CPU 利用率、磁盘读写、网络流量等)。此外,所有实例现在都免费提供基本监控。

Amazon just announced that you can now "set alarms for any metric that Amazon CloudWatch monitors" (CPU utilization, disk reads and writes, and network traffic, etc). Also, all instances now come with basic monitoring for free.

风吹短裙飘 2024-08-30 10:24:37

我们刚刚发布了一项实验室管理服务,该服务为 AWS 使用添加了策略:时间限制、最大实例数量、最大机器大小等。您可能想尝试一下,看看它是否有帮助:http://LabSlice.com。由于这是一家初创公司,我们非常重视有关如何解决像您这样的问题的反馈(即,如果您认为可以更好地修改应用程序以满足您的要求,请给我发送电子邮件)。

我不认为有任何直接的方法可以控制 AWS 的美元成本。我怀疑亚马逊是否提供了 API 来获取有关使用情况的深入指标,因为帮助您降低成本显然不符合他们的利益。我实际上遇到过两个例子,由于脚本配置错误,公司(银行)出现了意外成本,所以我知道这可能是一个问题。

We just released a Lab Management service that adds policies to AWS usage: time limits, max number of instance, max machine sizes etc. You may want to try that and see if it helps: http://LabSlice.com. As this is a startup, we would really value feedback about how to resolve issues such as yours (ie. email me if you think the app could be better modified to meet your requirements).

I don't believe there is any direct way to control AWS costs to the dollar. I doubt that Amazon provides an API to get in-depth metrics on usage, as it's obviously not going to be in their interest to help you reduce costs. I actually ran into two instances where surprise costs arose in a company (bank) due to mis-configured scripts, so I know that it can be a problem.

梦里的微风 2024-08-30 10:24:37

我在使用 EC2 实例时遇到了同样的问题,但以不同的方式解决了这个问题——我没有监控实例,而是让它们在设定的时间后自动终止。从您的描述来看,听起来这在您的环境中可能不切实际,但我想我会分享以防万一它有帮助。我的 AMI 基于 Fedora,因此我创建了以下 bash 脚本,将其注册为服务,并让它在启动时运行:

#!/bin/bash
# chkconfig: 2345 68 20
# description: 50 Minute Kill
# Source Functions
. /etc/rc.d/init.d/functions

start()
{
    # Shut down 50 minutes after starting up
    at now + 50 minutes < /root/atshutdown
}

stop()
{
    # Remove all jobs from the at queue because I'm not using at for anything else
    for job in $(atq | awk '{print $1}')
    do
        atrm $job
    done
}

case "$1" in
    start)
        start && success || failure
        echo
        ;;
    stop)
        stop && success || failure
        echo
        ;;
    restart)
        stop && start && success || failure
        echo
        ;;
    status)
        echo $"`atq`"
        ;;
    *)
        echo $"Usage: $0 {start | stop | restart}"
        RETVAL=1
esac    

exit $RETVAL

您可能会考虑执行类似的操作来满足您的需求。 如果您这样做,请特别小心,在修改映像之前停止服务,以便在您有机会重新捆绑之前实例不会关闭。

如果您愿意,您可以拥有这些实例在固定时间关闭(在每个人下班后?),或者您可以通过 -d-f 参数将保持活动长度/关闭时间传递给 < code>ec2-run-instances 并将其解析到脚本中。

I ran into the same issue with EC2 instances, but addressed it in a different way -- instead of monitoring the instances, I had them automatically kill themselves after a set amount of time. From your description, it sounds like this may not be practical in your environment, but I thought I would share just in case it helps. My AMI was Fedora-based, so I created the following bash script, registered it as a service, and had it run at startup:

#!/bin/bash
# chkconfig: 2345 68 20
# description: 50 Minute Kill
# Source Functions
. /etc/rc.d/init.d/functions

start()
{
    # Shut down 50 minutes after starting up
    at now + 50 minutes < /root/atshutdown
}

stop()
{
    # Remove all jobs from the at queue because I'm not using at for anything else
    for job in $(atq | awk '{print $1}')
    do
        atrm $job
    done
}

case "$1" in
    start)
        start && success || failure
        echo
        ;;
    stop)
        stop && success || failure
        echo
        ;;
    restart)
        stop && start && success || failure
        echo
        ;;
    status)
        echo $"`atq`"
        ;;
    *)
        echo $"Usage: $0 {start | stop | restart}"
        RETVAL=1
esac    

exit $RETVAL

You might consider doing something similar to suit your needs. If you do this, be especially careful that you stop the service before modifying your image so that the instance does not shutdown before you get a chance to re-bundle.

If you wanted, you could have the instances shutdown at a fixed time (after everyone leaves work?), or you could pass in a keep-alive length/shutdown time via the -d or -f parameters to ec2-run-instances and parse it out into the script.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文