AWS CloudWatch解释洞察图-将向多少个读/写IO收费? [英] AWS CloudWatch interpreting insights graph -- how many read/write IOs will be billed?

查看:58
本文介绍了AWS CloudWatch解释洞察图-将向多少个读/写IO收费?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我们正在尝试衡量"在我们不经常使用的Aurora数据库之一上使用特定用例的成本(我们将其用于登台).

We are trying to "measure" the cost of usage of a specific use case on one of our Aurora DBs that is not used very often (we use it for staging).

昨天在18:18时.UTC我们向它发出了一些代表性的查询,今天我们正在通过Amazon CloudWatch Insights检查结果图.

Yesterday at 18:18 hrs. UTC we issued some representative queries to it and today we were examining the resulting graphs via Amazon CloudWatch Insights.

由于我们要为每百万个读/写IO支付0.22美元的费用,因此我们需要知道昨天在我们的小实验中有多少个.

Since we are being billed USD 0.22 per million read/write IOs, we need to know how many of those there were during our little experiment yesterday.

一个复杂的因素是,在成本资源管理器中,无法对每个数据库实例的读/写IO的最终计费成本进行分组!因此,我们唯一可以想到的就是从CLoudwatch Insights上的读写卷IO图来估算成本.

A complicating factor is that in the cost explorer it is not possible to group the final billed costs for read/write IOs per DB instance! Therefore, the only thing we can think of to estimate the cost is from the read/write volume IO graphs on CLoudwatch Insights.

因此,我们转到了CloudWatch Insights,并选择了用于读/写IO的图形.然后,我们选择进行实验的时间段.最后,我们使用不同的选项检查了这些图:和线条".

So we went to the CloudWatch Insights and selected the graphs for read/write IOs. Then we selected the period of time in which we did our experiment. Finaly, we examined the graphs with different options: "Number" and "Lines".

这向我们显示了以下图片,表明可计费IO总数为266 + 510 = 776.由于我们选择了和",指标,那么我们假设这将总共带来约0.00017美元的费用.

This shows us the picture below suggesting a total billable IO count of 266+510=776. Since we have choosen the "Sum" metric, this we assume would indicate a cost of about USD 0.00017 in total.

但是,如果我们选择行"选项,然后我们看到另一张图片,在线上有5个点.第一个和最后一个大约为500(用于读取IO),最后一个大约为.750.建议总共5000个读/写IO.

However, if we choose the "Lines" option, then we see another picture, with 5 points on the line. The first and last around 500 (for read IOs) and the last one at approx. 750. Suggesting a total of 5000 read/write IOs.

我们不确定要使用哪种解释,并且两者之间的区别是很大的.

We are not really sure which interpretation to go with and the difference is significant.

现在我们的问题是:我们的小实验花了我们多少钱,以及等效地如何解释这些图?

So our question is now: How much did our little experiment cost us and, equivalently, how to interpret these graphs?

使用5分钟的间隔(如注释中所建议),在进行实验的整个小时中,我们获得了一条水平线(请参见下文),该水平线的点为255(读取IO).但是实验在世界标准时间19:18花费了不到1分钟的时间.

Using 5 minute intervals (as suggested in the comments) we get (see below) a horizontal line with points at 255 (read IOs) for a whole hour around the time we did our experiment. But the experiment took less than 1 minute at 19:18 (UTC).

(读取的)记帐方式是针对12 * 255个IO还是255 ...(或其他所有计费方式)?

Wil the (read) billing be for 12 * 255 IOs or 255 ... (or something else altogether)?

注意:此问题触发了在此处创建的另一个后续问题:

Note: This question triggered another follow-up question created here: AWS CloudWatch insights graph — read volume IOs are up much longer than actual reading

推荐答案

来自 VolumeReadIOP

VolumeReadIOPs

来自一个群集卷中的计费读I/O操作数每隔5分钟.

The number of billed read I/O operations from a cluster volume within a 5-minute interval.

计费读取操作是在群集卷级别上计算的,从Aurora数据库集群中的所有实例聚合,然后每隔5分钟报告一次.该值是通过将在5分钟内读取操作指标的值.您可以通过执行以下操作确定每秒计费的读操作量账单读取操作指标的值除以300秒.例如,如果账单读取"操作返回13,686,那么每秒的计费读取操作为45(13,686/300 =45.62).

Billed read operations are calculated at the cluster volume level, aggregated from all instances in the Aurora DB cluster, and then reported at 5-minute intervals. The value is calculated by taking the value of the Read operations metric over a 5-minute period. You can determine the amount of billed read operations per second by taking the value of the Billed read operations metric and dividing by 300 seconds. For example, if the Billed read operations returns 13,686, then the billed read operations per second is 45 (13,686 / 300 = 45.62).

对于请求数据库的查询,您将产生计费读取操作页面不在缓冲区缓存中,必须从存储中加载.您可能会看到,随着查询结果的增加,计费读取操作会激增从存储中读取,然后加载到缓冲区缓存中.

You accrue billed read operations for queries that request database pages that aren't in the buffer cache and must be loaded from storage. You might see spikes in billed read operations as query results are read from storage and then loaded into the buffer cache.

想象一下AWS每5分钟报告这些数据[100,150,200,70,140,​​10]

Imagine AWS report these data each 5 minutes [100,150,200,70,140,10]

您使用了15分钟总和统计信息,就像您在图片上看到的一样

And you used the Sum of 15 minutes statistic like what you had on the image

首先,̶的̶"数"̶可视化表示只有最后聚集̶g̶r̶o̶u̶p̶.̶你的情况为15分钟聚合,̶这将是̶(70 + 140 + 10)̶

F̶i̶r̶s̶t̶,̶ ̶t̶h̶e̶ ̶"̶n̶u̶m̶b̶e̶r̶"̶ ̶v̶i̶s̶u̶a̶l̶i̶z̶a̶t̶i̶o̶n̶ ̶r̶e̶p̶r̶e̶s̶e̶n̶t̶ ̶o̶n̶l̶y̶ ̶t̶h̶e̶ ̶l̶a̶s̶t̶ ̶a̶g̶g̶r̶e̶g̶a̶t̶e̶d̶ ̶g̶r̶o̶u̶p̶.̶ ̶I̶n̶ ̶y̶o̶u̶r̶ ̶c̶a̶s̶e̶ ̶o̶f̶ ̶1̶5̶ ̶m̶i̶n̶u̶t̶e̶s̶ ̶a̶g̶g̶r̶e̶g̶a̶t̶i̶o̶n̶,̶ ̶i̶t̶ ̶w̶o̶u̶l̶d̶ ̶b̶e̶ ̶(̶7̶0̶+̶1̶4̶0̶+̶1̶0̶)̶

首先,将数字"设置为0.可视化表示整个选定的持续时间,总计为(100 + 150 + 200 + 70 + 140 + 10)

First, the "number" visualization represent the whole selected duration, aggregated with would be the total of (100+150+200+70+140+10)

行"可视化将代表所有聚合的组.在这种情况下将是2分(100 + 150 + 200)和(70 + 140 + 10)

The "line" visualization will represent all the aggregated groups. which would in this case be 2 points (100+150+200) and (70+140+10)

如果您不习惯于数据点和聚合,一开始可能会有点难以理解.因此,我建议您设置行"图表 5分钟的总和,您将需要获取每个点的价值,并按照文档建议将其除以300,然后将它们全部求和

It can be a little bit hard to understand at first if you are not used to data points and aggregations. So I suggest that you set your "line" chart to Sum of 5 minutes you will need to get value of each points and devide by 300 as suggested by the doc then sum them all

添加了图像以便于可视化

这篇关于AWS CloudWatch解释洞察图-将向多少个读/写IO收费?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆