使用Kiro Dashboard上的User Report 查询Kiro CLI/IDE用量

更新：2026年3月份存在数据异常，请参考本文章节五。

一、背景

之前介绍过使用AWS计费系统CUR V2（Cost Usage Report）的计费数据查询每个用户Kiro的Credit用量（以及价格）。随着Kiro不断完善，Kiro现在支持输出用户使用credit的数据到S3存储桶中并保存为CSV格式，直接检索这些文件即可获得用户Credit用量信息。因为这部分数据结构更简单，因此少了很多需要过滤的无效字段，检索起来步骤比CUR V2更简单。本文介绍如何操作。

二、开启User Report并了解数据格式

1、创建S3存储桶

进入S3控制台，创建一个存储桶用于接收Kiro的User Report数据。存储桶名称可自定义，例如kiro-activity-123456789012。区域选择us-east-1，其他选项保持默认即可。

2、在Kiro控制台中打开User Report

登录Kiro管理控制台，进入Settings页面，找到User Report选项。开启User Report功能，填入上一步创建的S3存储桶名称。保存后，Kiro会每天自动将用户的Credit使用数据以CSV格式写入该存储桶。

数据存储路径格式为：

s3://<bucket>/AWSLogs/<account-id>/KiroLogs/user_report/<region>/<year>/<month>/<day>/00/

每天会生成CLI和IDE两个独立的CSV文件，文件名格式为：

KIRO_CLI_<account-id>_user_report_<yyyyMMdd>0000.csv
KIRO_IDE_<account-id>_user_report_<yyyyMMdd>0000.csv

3、数据解读

数据样本如下：

Date,UserId,Client_Type,Chat_Conversations,Credits_Used,Overage_Cap,Overage_Credits_Used,Overage_Enabled,ProfileId,Subscription_Tier,Total_Messages
2026-02-16,"843884c8-00c1-7046-e4e8-7ba5acc6cfc7",KIRO_CLI,4,8.365127258002758,10000.0,0.0,true,"arn:aws:codewhisperer:us-east-1:133129065110:profile/PQEGG7YEGNDK",PRO,73

每天生成两个文件，CLI和IDE的日志分别保存。以上字段含义如下：

字段名	含义
Date	数据日期
UserId	IAM Identity Center中的用户ID
Client_Type	客户端类型，KIRO_CLI或KIRO_IDE
Chat_Conversations	当天的对话会话数
Credits_Used	当天消耗的Credit数量
Overage_Cap	超额使用的Credit上限
Overage_Credits_Used	超额使用的Credit数量
Overage_Enabled	是否开启超额使用
ProfileId	Kiro Profile的ARN
Subscription_Tier	订阅等级（FREE/PRO/PRO_PLUS）
Total_Messages	当天的消息总数

这里边需要额外注意的是Overage_Cap字段，解读如下：

`Overage_Cap`是超额使用的Credit上限，即用户用完当月计划内Credit后，
最多还能额外使用的Credit数量。以PRO计划为例：
- 订阅等级：PRO（每月包含1,000 credits）
- Overage_Enabled：true（已开启超额）
- Overage_Cap：10,000（超额上限为10,000 credits）

这一项是开启超额后，用户用完PRO计划的1,000 credits后，系统允许额外使用最多10,000 credits，超额部分按$0.04/credit计费。理论上单月最大花费 = $20（PRO订阅费）+ 10,000 × $0.04 = $420。10,000是管理员在Kiro控制台中设置的默认超额上限值。当Overage_Credits_Used为0.0时，表示该用户当月用量未超出计划额度，超额计费未触发。

三、使用Athena进行组合查询

1、创建Athena表的SQL、并使用动态分区

创建SQL脚本如下。本表使用Athena的Partition Projection（动态分区投影）功能，无需手动执行MSCK REPAIR TABLE加载分区，Athena会根据S3路径自动推断分区。请替换Location中的S3存储桶名称和路径为您实际的存储桶名。

CREATE EXTERNAL TABLE IF NOT EXISTS kiro_user_report (
  date_col STRING,
  userid STRING,
  client_type STRING,
  chat_conversations INT,
  credits_used DOUBLE,
  overage_cap DOUBLE,
  overage_credits_used DOUBLE,
  overage_enabled BOOLEAN,
  profileid STRING,
  subscription_tier STRING,
  total_messages INT
)
PARTITIONED BY (
  region STRING,
  year STRING,
  month STRING,
  day STRING
)
ROW FORMAT SERDE 'org.apache.hadoop.hive.serde2.OpenCSVSerde'
WITH SERDEPROPERTIES (
  'separatorChar' = ',',
  'quoteChar' = '\"',
  'escapeChar' = '\\'
)
STORED AS TEXTFILE
LOCATION 's3://kiro-activity-123456789012/AWSLogs/123456789012/KiroLogs/user_report/'
TBLPROPERTIES (
  'skip.header.line.count' = '1',
  'projection.enabled' = 'true',
  'projection.region.type' = 'enum',
  'projection.region.values' = 'us-east-1',
  'projection.year.type' = 'integer',
  'projection.year.range' = '2025,2030',
  'projection.month.type' = 'integer',
  'projection.month.range' = '1,12',
  'projection.month.digits' = '2',
  'projection.day.type' = 'integer',
  'projection.day.range' = '1,31',
  'projection.day.digits' = '2',
  'storage.location.template' = 's3://kiro-activity-123456789012/AWSLogs/123456789012/KiroLogs/user_report/${region}/${year}/${month}/${day}/00'
);

2、查询本月所有用户的Credit用量汇总

构建一个查询，预期的列名如下：

月份
user id
订阅Plan
本Plan包含的Credit量
CLI的Credit用量
IDE的Credit用量
总用量
是否超出本月Credit量（Y表示超过，N表示未超过）

SQL脚本如下：

SELECT
  DATE_FORMAT(DATE_PARSE(CONCAT(year, '-', month, '-01'), '%Y-%m-%d'), '%Y-%m') AS billing_month,
  userid,
  subscription_tier,
  CASE
    WHEN subscription_tier = 'PRO' THEN 1000
    WHEN subscription_tier = 'PRO_PLUS' THEN 3000
    WHEN subscription_tier = 'FREE' THEN 50
    ELSE 0
  END AS plan_credits,
  ROUND(SUM(CASE WHEN client_type = 'KIRO_CLI' THEN credits_used ELSE 0 END), 2) AS cli_credits,
  ROUND(SUM(CASE WHEN client_type = 'KIRO_IDE' THEN credits_used ELSE 0 END), 2) AS ide_credits,
  ROUND(SUM(credits_used), 2) AS total_credits,
  CASE
    WHEN SUM(credits_used) > (CASE WHEN subscription_tier = 'PRO' THEN 1000 WHEN subscription_tier = 'PRO_PLUS' THEN 3000 WHEN subscription_tier = 'FREE' THEN 50 ELSE 0 END) THEN 'Y'
    ELSE 'N'
  END AS over_limit
FROM kiro_user_report
GROUP BY
  DATE_FORMAT(DATE_PARSE(CONCAT(year, '-', month, '-01'), '%Y-%m-%d'), '%Y-%m'),
  userid,
  subscription_tier
ORDER BY billing_month DESC, total_credits DESC;

查询结果如下：

billing_month | userid                                | subscription_tier | plan_credits | cli_credits | ide_credits | total_credits | over_limit
2026-02       | 843884c8-00c1-7046-e4e8-7ba5acc6cfc7  | PRO               | 1000         | 576.25      | 15.08       | 591.33        | N

注意：2月份是新开启User Report的第一个月，因此已知2月10日、11日、12日数据可能存在异常，请以后续月份数据为准。

3、查询某个特定用户本月每日消耗

如果只希望查询某单个用户本月第一天到月末最后一天的每天使用量，那么可以使用如下SQL查询：

SELECT
  CONCAT(year, '-', month, '-', day) AS date,
  userid,
  ROUND(SUM(CASE WHEN client_type = 'KIRO_CLI' THEN credits_used ELSE 0 END), 2) AS cli_credits,
  ROUND(SUM(CASE WHEN client_type = 'KIRO_IDE' THEN credits_used ELSE 0 END), 2) AS ide_credits,
  ROUND(SUM(credits_used), 2) AS total_credits
FROM kiro_user_report
WHERE year = '2026' AND month = '02' AND
  userid = '843884c8-00c1-7046-e4e8-7ba5acc6cfc7'
GROUP BY year, month, day, userid
ORDER BY day, total_credits DESC;

执行结果返回如下：

#	date	userid	cli_credits	ide_credits	total_credits
1	2026-02-10	843884c8-00c1-7046-e4e8-7ba5acc6cfc7	90.49	0.0	90.49
2	2026-02-11	843884c8-00c1-7046-e4e8-7ba5acc6cfc7	377.48	10.39	387.86
3	2026-02-12	843884c8-00c1-7046-e4e8-7ba5acc6cfc7	8.44	0.0	8.44
4	2026-02-13	843884c8-00c1-7046-e4e8-7ba5acc6cfc7	26.2	1.3	27.5
5	2026-02-14	843884c8-00c1-7046-e4e8-7ba5acc6cfc7	30.2	2.57	32.77
6	2026-02-15	843884c8-00c1-7046-e4e8-7ba5acc6cfc7	35.08	0.0	35.08
7	2026-02-16	843884c8-00c1-7046-e4e8-7ba5acc6cfc7	8.37	0.83	9.19
8	2026-02-17	843884c8-00c1-7046-e4e8-7ba5acc6cfc7	12.19	63.59	75.79
9	2026-02-18	843884c8-00c1-7046-e4e8-7ba5acc6cfc7	6.37	32.28	38.64
10	2026-02-19	843884c8-00c1-7046-e4e8-7ba5acc6cfc7	1.95	136.07	138.01

四、将Userid映射为用户名查询

在之前的博客中介绍了关联用户名查询的办法，那就是从IAM Identity Center中导出用户名、userid信息为CSV文件，然后在Athena中创建一个用户名和userid的映射表。再执行联合查询，即可查看。

导出用户名、userid信息、创建用户表的步骤参考这篇博客：

https://blog.bitipcman.com/post/kiro-credit-usage-analyzing-by-using-aws-cur-v2/

现在假设用户表已经创建好，那么创建一个Athena查询，查询字段如下：

- 月份
- 用户名（从userid自动关联）
- 订阅Plan
- 本Plan包含的Credit量
- CLI的Credit用量
- IDE的Credit用量
- 总用量
- 是否超出本月Credit量（Y表示超过，N表示未超过）

SQL脚本如下：

SELECT
  DATE_FORMAT(DATE_PARSE(CONCAT(r.year, '-', r.month, '-01'), '%Y-%m-%d'), '%Y-%m') AS billing_month,
  u.username,
  r.subscription_tier,
  CASE
    WHEN r.subscription_tier = 'PRO' THEN 1000
    WHEN r.subscription_tier = 'PRO_PLUS' THEN 3000
    WHEN r.subscription_tier = 'FREE' THEN 50
    ELSE 0
  END AS plan_credits,
  ROUND(SUM(CASE WHEN r.client_type = 'KIRO_CLI' THEN r.credits_used ELSE 0 END), 2) AS cli_credits,
  ROUND(SUM(CASE WHEN r.client_type = 'KIRO_IDE' THEN r.credits_used ELSE 0 END), 2) AS ide_credits,
  ROUND(SUM(r.credits_used), 2) AS total_credits,
  CASE
    WHEN SUM(r.credits_used) > (CASE WHEN r.subscription_tier = 'PRO' THEN 1000 WHEN r.subscription_tier = 'PRO_PLUS' THEN 3000 WHEN r.subscription_tier = 'FREE' THEN 50 ELSE 0 END) THEN 'Y'
    ELSE 'N'
  END AS over_limit
FROM kiro_user_report r
LEFT JOIN identity_center_users u ON r.userid = u.userid
GROUP BY
  DATE_FORMAT(DATE_PARSE(CONCAT(r.year, '-', r.month, '-01'), '%Y-%m-%d'), '%Y-%m'),
  u.username,
  r.subscription_tier
ORDER BY billing_month DESC, total_credits DESC;

查询结果如下：

billing_month | username | subscription_tier | plan_credits | cli_credits | ide_credits | total_credits | over_limit
2026-02       | user01   | PRO               | 1000         | 576.25      | 15.08       | 591.33        | N

可以看到，userid已被自动映射为用户名user01，查询结果清晰展示了每个用户的月度Credit使用情况。

五、关于2026年3月的数据异常问题

通过对比S3存储桶中2026年2月（基准）、3月、4月的CSV原始文件，发现3月10日~12日期间数据格式出现了短暂变更，随后恢复为原格式。以下是详细分析。

1、2026年2月份基准格式（11列）

2月份的CSV表头为11列，格式如下：

Date,UserId,Client_Type,Chat_Conversations,Credits_Used,Overage_Cap,Overage_Credits_Used,Overage_Enabled,ProfileId,Subscription_Tier,Total_Messages

数据特征：

UserId格式："843884c8-00c1-7046-e4e8-7ba5acc6cfc7"（带双引号）
Overage_Enabled值：true（小写）
ProfileId值：带双引号

2、2026年3月10日12日格式异常（1213列）

这几天的数据出现了新增列和字段格式变化：

变化项	2月格式（正常）	3月10日~12日格式（异常）
列数	11列	12~13列（新增了额外列）
UserId	`"843884c8-..."`	`d-9066195b8c.843884c8-...`（加了目录ID前缀，无引号）
Overage_Enabled	`true`（小写）	`TRUE`（大写）
ProfileId	带双引号	无双引号

新增列的具体情况因CLI和IDE而异：

3月10日CLI：新增auto_messages（共12列）
3月10日IDE：新增claude_opus_4.6_messages、simple_task_messages（共13列）
3月12日CLI：新增auto_messages、claude_opus_4.6_messages（共13列）
3月12日IDE：新增auto_messages、simple_task_messages（共13列）

以3月10日IDE数据为例，表头变为：

Date,UserId,Client_Type,Chat_Conversations,Credits_Used,Overage_Cap,Overage_Credits_Used,Overage_Enabled,ProfileId,Subscription_Tier,Total_Messages,claude_opus_4.6_messages,simple_task_messages

3、2026年3月13日之后恢复正常

从3月13日开始，格式回退到与2月份完全一致的11列旧格式。4月份数据也沿用了11列格式，没有新增列。推测Kiro后端在3月10日~12日期间进行了一次格式升级测试，随后回滚。

4、对Athena查询的影响

(1) UserId前缀问题

3月10日~12日的UserId带有d-9066195b8c.前缀（即IAM Identity Center的Directory ID），如果使用LEFT JOIN identity_center_users做用户名映射，这几天的数据会因为UserId不匹配而关联失败。如需处理，可在查询中使用REGEXP_REPLACE去掉前缀：

REGEXP_REPLACE(r.userid, '^d-[^.]+\.', '')

(2) 新增列被忽略

由于Athena的OpenCSVSerde按位置映射列，本文第三章定义的表结构只有11列，3月10日~12日多出的列（auto_messages等）会被自动忽略，不会导致查询报错，但这些新增字段的数据也无法被查询到。

(3) 建议

3月10日~~12日的数据异常与2月10日~~12日类似，属于短暂的格式波动。建议在使用数据时注意排除或特殊处理这几天的记录。如果需要精确统计3月份用量，可在WHERE条件中排除这几天：

WHERE NOT (year = '2026' AND month = '03' AND day IN ('10', '11', '12'))

六、参考文档

Viewing per-user activity

https://kiro.dev/docs/enterprise/monitor-and-track/user-activity/

最后修改于 2026-04-15