日志服务是针对日志类数据的一站式服务，提供了海量的日志处理能力。用户在使用日志服务的过程中，经常会遇到如下问题：
- 数据写入之后查询不到，是不是数据有丢失；
- 怎么查看每天写入的数据量；
- 各个Shard数据写入和消费是否均衡；
- 怎么看消费组的消费进度，消费速度能否赶上写入速度；
- Logtail数据没有采集成功是什么原因；
为了便于用户解决这些问题，现在日志服务支持用户以Project为单位开通运行日志。用户在使用日志服务过程中的所有操作，日志采集和消费过程中产生的日志都会被记录下来，如图1所示。用户可以基于这些日志，对日志的采集和消费进行监控，排查使用过程中遇到问题，操作审计等。
图 1. 用户日志和使用场景
开通了运行日志功能的Project产生的所有日志会保存到用户指定的Project中，并且按照日志类型自动分类保存。该部分日志与用户采集到的其他日志数据一样，支持设置索引和查询分析、流式消费等。用户可以通过查询分析实时查看日志服务用户的访问信息、操作和Logtail错误记录等数据，提高运维效率。
如图2所示，目前日志服务支持记录操作日志、消费组日志、Logtail告警日志、Logtal采集日志和计量日志等五种日志类型。
图2. 运行日志包含的日志类型
配置步骤
步骤1. RAM授权。
日志服务需要主账户授权才能将运行日志写入到您指定的Project。单击快捷授权完成授权。
步骤2. 登录日志服务控制台首页，单击右上角的创建Project。
对于已存在的Project，可以单击修改，在修改Project页面中开启运行日志功能。
图 3. 运行日志操作
步骤3. 在弹出页面中，填写Project名称等信息。
步骤4. 选择所属地域。
步骤5. 选择日志存储位置。
步骤6. 点击确认创建Project同时开通运行日志。
开通运行日志之后，当前项目下所有资源的操作日志、访问日志和计量日志等数据都会保存到该Project中，您可以选择当前Project或当前地域下其他已创建的Project。
图 4. 开通运行日志
配置完成后，若您需要修改保存日志的Project，请在修改Project步骤中修改。
应用场景举例
1. 查看单次请求详情
以Java SDK为例，用户的每次请求都会在响应头中返回一个唯一的RequestId，这个RequestId对应一条唯一的请求日志。开通运行日志后，所有的请求日志都保存在internal-operation_log这个LogStore中。用户可以根据RequestId查询对应请求的日志，根据Status这个字段查看响应状态。如果Status为200则请求成功，否则请求失败。
图 5. 根据RequestId查询请求日志
根据日志中对应的Shard Id和写入时间，用户可以把对应时间段内的日志通过PullLogs API找到对应的日志。
2. 判断Shard写入和消费是否均衡
您可以通过对比Shard数据写入趋势和消费趋势判断Shard写入和消费是否均衡。当您的LogStore存在多个Shard时，可以通过仪表盘 operation_statistics中查看shard的写入数据趋势。如图6所示，X轴为时间，左图Y轴为每分钟每个shard写入的流量，单位为字节，右图Y轴为每分钟每个shard的写入行数。
图 6. 查看shard的写入数据趋势
仪表盘 consumer_group_monitoring 中的Shard消费趋势图展示了所有Shard的消费状况。X轴为时间，Y轴为每个shard每分钟的读请求次数。
图 7. Shard消费趋势
注意：如果Project中存在多个LogStore，不同的LogStore可能会存在重复的Shard Id，因此如果需要查看某个LogStore的Shard写入分布，需要在仪表盘左上角的过滤条件增加Project和LogStore名字作为过滤条件。
3. API请求异常状态监控
用户在向服务端写入日志时，API请求是否成功将直接关系到用户的数据是否被成功接受。如果API请求出现异常，用户如何在第一时间内知晓呢？开启运行日志后，所有的API请求日志都会实时保存到internal-operation_log这个LogStore中，用户可以对于该部分日志配置快速查询和监控告警。
如下图所示，查询API请求状态码为200及以上的请求个数。您可以将查询结果另存为快速查询，并配置对应的告警。参考 设置告警。
图 8. 监控API请求异常
查询语句：
Status > 200 | SELECT COUNT(1) as errorCount 4. 查看消费组延时
在使用consumer group消费日志时，消费的速度能否赶上日志的写入速度是用户关系的核心问题之一。在internal-consumergroup_log这个LogStore中，记录了每个消费组当前的消费延时快照日志，每两分钟上报一条。我们可以使用max_by这个函数针对某个消费组查询各个shard上的延时，单位为秒。
图 9. 查询消费组延时
查询语句：project: myproject and logstore: mylogstore and consumer_group: myconsumergroup | SELECT shard, max_by(fallbehind, __time__) as latency GROUP BY shard ORDER BY latency DESC
5. 查看当日数据写入量
internal-operation_log这个LogStore中的Method字段表示每次请求执行的操作。以最新的SDK为例，写入数据时Method为PostLogStoreLogs。对于WebTracking写入的数据，Method为WebTracking。我们只需要根据Method统计写入的操作一共写入了多少流量即可，如下图10所示。用户也可以自定义时间区间。
图 10. 查看当天日志写入量
查询语句：Method: PostLogStoreLogs | SELECT sum(NetInflow) as IncomingBytes
6. 查看Logtail状态
用户在创建Logtail配置之后，Logtail运行正常与否直接关系到用户的数据完整性。然而对于用户看来，Logtail整个运行过程是一个黑盒，无法有效监控内部的状态。在用户开通运行日志后，Logtail上报的状态和错误日志将实时发送到用户的LogStore，这些日志对于用户日志采集监控和排查问题具有重要意义。
如下图所示，用户可以统计Logtail不同错误类型发生次数。同时可以参考官方文档中关于不同的错误类型的处理方式 进行处理。
图 11. Logtail错误类型统计
查询语句：
* | SELECT sum(alarm_count) AS alarm_count, alarm_type GROUP BY alarm_type ORDER BY alarm_count DESC 7. 查看当前时间存储用量
开通运行日志之后，用户消费相关的计量日志自动保存到internal-metering这个LogStore中。对于每个LogStore，每小时统计一次当前使用的日志和索引使用的存储空间，和这一小时窗口内API的读写次数。用户可以使用max_by这个函数查询最新的一条计量日志。
storage_index和storage_raw这两个字段分别表示索引和日志所占用的存储空间，单位为字节。
图 12. 查看消耗存储空间
查询语句：
| SELECT project, logstore, max_by(storage_index+storage_raw, __time__) as storage GROUP BY project,logstore ORDER BY storage DESC 除此之外，用户还可以根据默认创建的仪表盘查看更多有价值的信息。可以参考帮助文档了解更多内容。