DANDI S3 日志解析器

从综合的原始S3日志中提取最小信息以供公开共享和绘图。

为 DANDI Archive 开发。

了解更多关于 AWS上的S3日志。

2024年的一些摘要事实

• 原始S3日志文件的一行可以介于400-1000+字节之间。
• 档案中一些最繁忙的日常日志可以有约5,014,386行。
• 总共收集了超过6 TB的日志文件。
• 该解析器将总数据量减少到小于25 GB的最终必要信息（NWB大小待定）。

安装

pip install dandi_s3_log_parser

工作流程

该过程由三个模块化步骤组成。

1. 减少

过滤掉

• 非成功状态代码。
• 排除的IP地址。
• 除了指定的操作类型之外的操作类型（默认为REST.GET.OBJECT）。

然后，只提取原始日志的每一行中的少数指定字段的数据；默认为object_key、timestamp、ip_address和bytes_sent。

在2024年夏季，这个步骤将6 TB的原始日志减少到不到170 GB。

该过程设计为易于并行化和中断，这意味着您可以在运行过程中随时终止任何进程，稍后再重新启动而不会丢失大部分进度。

2. 分类

为了使Dandisets的映射更加高效，减少后的日志根据其对象键（资产blob ID）进行分类，以便快速查找。Zarr资产特别按父blob ID分组，例如，对zarr/abcdefg/group1/dataset1/0的请求将按zarr/abcdefg进行分类。

这一步骤通过减少重复的对象键进一步减少了步骤（1）中的总文件大小，尽管这会创建大量的小文件。

在2024年夏季，这使得170 GB的减少日志减少到不到80 GB（20 GB的blobs分布在253,676个文件中，60 GB的zarr分布在4,775个文件中）。

3. 映射

最后一步，应定期运行以保持每个Dandiset所需的日志更新，是扫描所有当前已知的Dandiset及其版本，将资产blob ID映射到其文件名，并生成可以公开共享的最近解析的日志。

在2024年夏季，这使得80 GB的分类日志减少到大约20 GB的Dandiset日志。

使用方法

减少

减少

reduce_all_dandi_raw_s3_logs \
  --raw_s3_logs_folder_path < base raw S3 logs folder > \
  --reduced_s3_logs_folder_path < reduced S3 logs folder path > \
  --maximum_number_of_workers < number of workers to use > \
  --maximum_buffer_size_in_mb < approximate amount of RAM to use > \
  --excluded_ips < comma-separated list of known IPs to exclude >

例如，在Drogon上

reduce_all_dandi_raw_s3_logs \
  --raw_s3_logs_folder_path /mnt/backup/dandi/dandiarchive-logs \
  --reduced_s3_logs_folder_path /mnt/backup/dandi/dandiarchive-logs-reduced \
  --maximum_number_of_workers 3 \
  --maximum_buffer_size_in_mb 3000 \
  --excluded_ips < Drogons IP >

在2024年夏季，此过程处理所有6 TB的原始日志数据（使用3个工人，每个3 GB的缓冲区大小）耗时不到10小时。

分类

分类

bin_all_reduced_s3_logs_by_object_key \
  --reduced_s3_logs_folder_path < reduced S3 logs folder path > \
  --binned_s3_logs_folder_path < binned S3 logs folder path >

例如，在Drogon上

bin_all_reduced_s3_logs_by_object_key \
  --reduced_s3_logs_folder_path /mnt/backup/dandi/dandiarchive-logs-reduced \
  --binned_s3_logs_folder_path /mnt/backup/dandi/dandiarchive-logs-binned

此过程对随机中断不如减少步骤友好。如果检测到损坏，必须在重新尝试之前清理目标分类文件夹。

可以使用--file_processing_limit <整数>标志限制单次运行中处理的文件数量，这可以将过程分解成更小的部分，例如

bin_all_reduced_s3_logs_by_object_key \
  --reduced_s3_logs_folder_path /mnt/backup/dandi/dandiarchive-logs-reduced \
  --binned_s3_logs_folder_path /mnt/backup/dandi/dandiarchive-logs-binned \

在2024年夏季，此过程将170 GB的减少日志分类到每个对象键80 GB的数据中耗时不到5小时。

映射

映射

map_binned_s3_logs_to_dandisets \
  --binned_s3_logs_folder_path < binned S3 logs folder path > \
  --mapped_s3_logs_folder_path < mapped Dandiset logs folder > \
  --excluded_dandisets < comma-separated list of six-digit IDs to exclude > \
  --restrict_to_dandisets < comma-separated list of six-digit IDs to restrict mapping to >

例如，在Drogon上

map_binned_s3_logs_to_dandisets \
  --binned_s3_logs_folder_path /mnt/backup/dandi/dandiarchive-logs-binned \
  --mapped_s3_logs_folder_path /mnt/backup/dandi/dandiarchive-logs-mapped \
  --excluded_dandisets 000108

在2024年夏季，此blob过程（使用缓存；无缓存为10小时）以一个工人的速度完成，耗时不到8小时。

某些Dandiset的处理时间可能比其他Dandiset长得多。因此，该命令还接受--excluded_dandisets和--restrict_to_dandisets。

强烈建议在主运行中跳过000108，并单独处理它（可能在完全不同的CRON周期中）。

map_binned_s3_logs_to_dandisets \
  --binned_s3_logs_folder_path /mnt/backup/dandi/dandiarchive-logs-binned \
  --mapped_s3_logs_folder_path /mnt/backup/dandi/dandiarchive-logs-mapped \
  --restrict_to_dandisets 000108

在2024年夏季，此过程耗时不到15小时。

理论上可以设计映射过程并行工作（从而更快），但这需要一些努力来设计。如果您感兴趣，请打开问题请求此功能。

提交行解码错误

请在提出问题或提交PR之前，将收集自本地配置文件（位于~/.dandi_s3_log_parser/errors）的行解码错误发送给核心维护者，以更容易地纠正可能需要匿名化的任何方面。