我支持基于 Google Cloud Platform 构建的数据管理解决方案。随着我们产品的成熟，越来越多的团队和个人正在采用它，这意味着越来越多的人正在存储和搜索数据并增加成本。我们需要更好地了解这些用户/工作流程中的每一个给我们带来了多少成本，以便我们最终可以开始向他们收取使用我们服务的费用。
我已经将运行我们的解决方案的 Google Cloud Platform 项目的计费数据导出到 BigQuery。我观察到，我们针对该项目的 Google Cloud Platform 账单的 70-80% 归功于 App Engine（作为产品），因此我目前专注于分摊 App Engine 成本。以下是该项目一天的 App Engine 费用的简明视图（来自 BigQuery）：
Row product resource_type start_time end_time cost usage_amount usage_unit
1 App Engine Simple Searches 2017-08-20 07:00:00 UTC 2017-08-20 08:00:00 UTC 0.1473 3946.0 requests
2 App Engine Flex Instance RAM 2017-08-20 07:00:00 UTC 2017-08-20 08:00:00 UTC 0.6816 3.710851743744E14 byte-seconds
3 App Engine Search Document Storage 2017-08-20 07:00:00 UTC 2017-08-20 08:00:00 UTC 0.505028 8.0921704558464E15 byte-seconds
4 App Engine Code and Static File Storage 2017-08-20 07:00:00 UTC 2017-08-20 08:00:00 UTC 0.0 5.96811043008E13 byte-seconds
5 App Engine Datastore Entity Writes 2017-08-20 07:00:00 UTC 2017-08-20 08:00:00 UTC 0.085804 67669.0 requests
6 App Engine Other Search Ops 2017-08-20 07:00:00 UTC 2017-08-20 08:00:00 UTC 0.0 1732.0 requests
7 App Engine Out Bandwidth 2017-08-20 07:00:00 UTC 2017-08-20 08:00:00 UTC 0.273014 3.516638423E9 bytes
8 App Engine Datastore Read Ops 2017-08-20 07:00:00 UTC 2017-08-20 08:00:00 UTC 1.494541 2540902.0 requests
9 App Engine Search Document Indexing 2017-08-20 07:00:00 UTC 2017-08-20 08:00:00 UTC 0.05012 3.7645832E7 bytes
10 App Engine Datastore Storage 2017-08-20 07:00:00 UTC 2017-08-20 08:00:00 UTC 1.72891 2.7716055728688E16 byte-seconds
11 App Engine Flex Instance Core Hours 2017-08-20 07:00:00 UTC 2017-08-20 08:00:00 UTC 5.0496 345600.0 seconds
12 App Engine Task Queue Storage 2017-08-20 07:00:00 UTC 2017-08-20 08:00:00 UTC 0.0 5.14512E8 byte-seconds
13 App Engine Datastore Small Ops 2017-08-20 07:00:00 UTC 2017-08-20 08:00:00 UTC 0.0 16166.0 requests
14 App Engine Backend Instances 2017-08-20 07:00:00 UTC 2017-08-20 08:00:00 UTC 206.080588 1.4870202339153E7 seconds
15 App Engine Frontend Instances 2017-08-20 07:00:00 UTC 2017-08-20 08:00:00 UTC 1.35596 198429.126958 seconds
问题 1：顺便说一下，对于熟悉 Google Cloud Platform 计费导出的任何人，输入start_time 2017-08-20 07:00:00 UTC并end_time 2017-08-20 08:00:00 UTC反映 2017 年 8 月 20 日产生的费用，而不是 2017 年 8 月 19 日，对吗？
现在，我知道将这些 App Engine 成本与 App Engine 活动关联起来并不是一个精确的映射——Google Cloud Platform 不会按操作计费，并且会有固定的，我猜是共享的资源成本（请纠正我，如果我错了！）——但我仍然想得到一个合理的估计。我的第一次尝试涉及检查Google 记录的每个请求的估计成本。因此，我为 App Engine 请求日志创建了一个接收器，并等待数字滚入。但是，使用这种方法在给定日期的所有请求的总估计成本非常低：
SELECT SUM(protoPayload.cost) AS cost_total
FROM [my-data-management-solution:request_log.appengine_googleapis_com_request_log_20170820];
产量
Row cost_total
1 3.2711573326337837
这仅占 App Engine 总成本的 1.5%！
问题 2：请求日志成本估算对应或有助于什么resource_type（来自 Google Cloud Platform 计费导出）？
我大约 95% 的 App Engine 成本归因于后端实例resource_type。我对它们是什么做了一些粗略的研究（包括这段视频，声称谷歌正在摆脱整个后端/前端实例的区别）。我假设（或可能已经读过）谷歌依赖任何秘密算法来启动、关闭和以其他方式管理这些实例。这样……</p>
问题 3（大问题）：我如何才能了解单个用户/工作流操作（仅限于通过 App Engine 可以）对 Google Cloud 的总 App Engine 成本或最低 App Engine 后端实例成本的贡献程度项目？如果没有诸如根据用户活动回归成本和创建 ML 模型之类的东西，是否有可能？深入了解这个黑匣子（从扩展和定价的角度）是如何工作的，或者认为 App Engine 成本在某种程度上与用户活动直接相关的想法是否合理？
附加信息
我们的数据管理解决方案使用了自己的身份概念，我并不指望 Google 会神奇地弄清楚这一点。我目前可以
request_log通过解析 Stackdriver 日志将项目链接到用户，我将计算出用户-工作流关联或从其他工具获取它们。以防万一，开箱即用这些东西有什么可做的吗？一条 StackOverflow 评论提到了Potamus，但该存储库不再可用，而且几乎没有任何关于它开始做什么的信息。
如果 App Engine 成本分摊不是什么大问题，那么 Cloud Storage 等其他产品呢？这将是我的下一个目标，尽管此时将云存储成本（实际的、可能可以忽略不计的存储成本和更昂贵的 I/O 成本）与 App Engine 活动相关联的挑战似乎更不合理。