Google Stackdriver 中基于日志的指标如何定价？
How are log-based metrics priced in Google Stackdriver?
我正在评估应用程序日志记录解决方案，但我不清楚 stackdriver 的定价。
现在，我的日志是 node.js apps -> fluentd server -> hosted elasticsearch -> kibana
在我的应用程序中，我在 json 中记录事件，键入 eventType 字段，例如
{
eventType: 'ARBITRARY_JOB_COMPLETE',
field2: 'etc'
//...
}
那么，在Kibana中，将那些事件queries变为filter/count/etc是一件小事。并构建仪表板。总而言之，我目前正在为仪表板统计大约 30 个不同的事件。
我正在尝试将其转化为 stackdriver 的定价模型。根据他们目前的pricing page（斜体强调是我的）：
Basic Tier: [=27=].10 per time series/month, and .00 per metric descriptor/month.
To understand the allotment and overage charges, you must understand
how Stackdriver uses metric descriptors and time series:
A metric descriptor defines a metric type and any associated labels
used to parameterize the metric. A single metric descriptor can be
responsible for any number of time series. For example, only a single
descriptor is needed for time series data from all of your VM
instances.
A time series holds time-stamped data for the combination
of a metric type, a monitored resource such as a VM instance or
database, and values for any labels the metric defines. Data points in
a time series expire at the end of their retention period. A
logs-based metric is a custom metric descriptor created by Stackdriver
Logging. It counts the number of log entries that match a filter.
For
example, suppose you have 180 VM instances and you want to write a
custom measurement for each of them every minute. You define a custom
metric descriptor, custom.googleapis.com/my_measurement. On each VM
instance, every minute, you write a data point to this metric,
specifying both the metric's name and the name of the VM instance.
This will create a separate time series for each VM instance. In the
Premium Tier, you have used one time series (out of 500) in each of
your 180 chargeable resources, and one metric descriptor (out of 250)
in your project. In the Basic Tier, the overage cost for this custom
data is .00 per month: .00 for the metric descriptor, and .00
for the 180 time series. If you stop writing data to the metric, all
the time series eventually expire and you are left with the .00 per
month charge for the descriptor, which you can delete.
该示例涉及 VM，因此很难应用于我的用例。我可以想到 2 种可能的解释：
- 我计算的每个
eventType 成本为 1.10 美元/月（描述符为 1 美元，结果时间序列为 0.10 美元）。所以，30 个事件 = 33.00 美元/月
- 我计算的每个
eventType 都被视为一个单独的 time series，导致 descriptor 每月 1 美元，每个 eventType 每月 0.10 * 30 美元' s time-series。
数字 2 似乎是一个合理的解释，以 VM 为例（即 1 'descriptor' 和 180 'series'，每个 VM 1），但我知道我可能只是乐观在我的阅读中。
我是 Stackdriver 团队的项目经理。如果我理解正确 - 您想要从过滤器创建一个指标，以便为每个不同的 eventType 值获得一个单独的时间序列。
今天，这将为我提供不同的指标描述符和时间序列。我们正在积极致力于对标签的支持，因此将来您可以拥有一个带有 eventType 标签的单个指标描述符，这样您就可以使用该单个描述符获得各种时间序列。
另请注意：
1. 今天，在第一季度末之前，一般不会对任何基于日志或用户定义的指标收费。
2. 在高级层中，这些将包含最多 250 个指标描述符（正如您在上面指出的那样）。
谢谢，
迪帕克
我正在评估应用程序日志记录解决方案，但我不清楚 stackdriver 的定价。
现在，我的日志是 node.js apps -> fluentd server -> hosted elasticsearch -> kibana
在我的应用程序中，我在 json 中记录事件，键入 eventType 字段，例如
{
eventType: 'ARBITRARY_JOB_COMPLETE',
field2: 'etc'
//...
}
那么，在Kibana中，将那些事件queries变为filter/count/etc是一件小事。并构建仪表板。总而言之，我目前正在为仪表板统计大约 30 个不同的事件。
我正在尝试将其转化为 stackdriver 的定价模型。根据他们目前的pricing page（斜体强调是我的）：
Basic Tier: [=27=].10 per time series/month, and .00 per metric descriptor/month.
To understand the allotment and overage charges, you must understand how Stackdriver uses metric descriptors and time series:
A metric descriptor defines a metric type and any associated labels used to parameterize the metric. A single metric descriptor can be responsible for any number of time series. For example, only a single descriptor is needed for time series data from all of your VM instances.
A time series holds time-stamped data for the combination of a metric type, a monitored resource such as a VM instance or database, and values for any labels the metric defines. Data points in a time series expire at the end of their retention period. A logs-based metric is a custom metric descriptor created by Stackdriver Logging. It counts the number of log entries that match a filter.
For example, suppose you have 180 VM instances and you want to write a custom measurement for each of them every minute. You define a custom metric descriptor, custom.googleapis.com/my_measurement. On each VM instance, every minute, you write a data point to this metric, specifying both the metric's name and the name of the VM instance. This will create a separate time series for each VM instance. In the Premium Tier, you have used one time series (out of 500) in each of your 180 chargeable resources, and one metric descriptor (out of 250) in your project. In the Basic Tier, the overage cost for this custom data is .00 per month: .00 for the metric descriptor, and .00 for the 180 time series. If you stop writing data to the metric, all the time series eventually expire and you are left with the .00 per month charge for the descriptor, which you can delete.
该示例涉及 VM，因此很难应用于我的用例。我可以想到 2 种可能的解释：
- 我计算的每个
eventType成本为 1.10 美元/月（描述符为 1 美元，结果时间序列为 0.10 美元）。所以，30 个事件 = 33.00 美元/月 - 我计算的每个
eventType都被视为一个单独的time series，导致descriptor每月 1 美元，每个eventType每月 0.10 * 30 美元' stime-series。
数字 2 似乎是一个合理的解释，以 VM 为例（即 1 'descriptor' 和 180 'series'，每个 VM 1），但我知道我可能只是乐观在我的阅读中。
我是 Stackdriver 团队的项目经理。如果我理解正确 - 您想要从过滤器创建一个指标，以便为每个不同的 eventType 值获得一个单独的时间序列。
今天，这将为我提供不同的指标描述符和时间序列。我们正在积极致力于对标签的支持，因此将来您可以拥有一个带有 eventType 标签的单个指标描述符，这样您就可以使用该单个描述符获得各种时间序列。
另请注意： 1. 今天，在第一季度末之前，一般不会对任何基于日志或用户定义的指标收费。 2. 在高级层中，这些将包含最多 250 个指标描述符（正如您在上面指出的那样）。
谢谢， 迪帕克