【免费下载链接】ipblocklistIP lists full of bad IPs - Updated every 2H项目地址https://gitcode.com/gh_mirrors/ip/ipblocklist点击查看免费下载开源项目 ipblocklist 是一个每 2 小时自动聚合更新的 IP 黑名单inbound/outbound 双列表项目。更难得的是它没有引入任何第三方库仅凭 Python 标准库和两个脚本就为整条数据管道搭起了完整的数据可观测性每次运行生成带时间戳的 stats 统计快照再滚动聚合出每日趋势文件 history.json让“黑名单规模变化”全程可见。本文带你完整拆解这套 stats 与 history 机制的设计与实现。为什么 IP 黑名单需要数据可观测性ipblocklist 聚合了数十个外部威胁情报源Spamhaus、blocklist.de、Tor 出口节点等合并去重后产出两份名单文件用途当前规模inbound.txt入站拦截恶意扫描、爆破、僵尸网络来源 IP约 464 万行outbound.txt出站拦截C2 服务器、钓鱼站点等恶意目的地 IP约 9.2 万行对于这种“数据来自几十家外部源、每 2 小时全量重算”的项目可观测性回答的是三个关键问题每次更新抓到了多少数据—— 有没有源悄悄失效、数据断崖下跌⏱️处理耗时多久—— 性能是否退化名单总量趋势如何—— 长期是在增长还是萎缩ipblocklist 的答案很朴素用 JSON 快照 每日趋势两个文件把答案写进仓库。项目 requirements.txt 里只有一行注释# No third-party dependencies — stdlib only (urllib, ipaddress, concurrent.futures)也就是说整条统计链路零第三方依赖任何有 Python 的环境都能跑。项目结构3 个目录 2 个脚本看懂全局ipblocklist/ ├── update_tables.py # 主更新脚本抓取 → 过滤 → 输出名单 stats 快照 ├── generate_history.py # 历史脚本把 stats 快照聚合为 90 天每日趋势 ├── inbound.txt # 最终产出的入站黑名单 ├── outbound.txt # 最终产出的出站黑名单 ├── tables/ │ ├── inbound/ # 入站源清单与中间结果ipv6.txt、networks.txt、single_ips.txt │ └── outbound/ └── stats/ ├── stats_YYYYMMDD_HHMMSS.json # 每次更新的统计快照 ├── latest.json # 最近一次更新永远是最新快照的副本 ├── history.json # 90 天每日趋势 └── archived/ # 历史快照归档约 2600 个文件数据流向一目了然tables/inbound/urltable_inbound源 URL 清单→update_tables.py抓取解析 →inbound.txt/outbound.txtstats/快照 →generate_history.py聚合 →stats/history.json第一道防线stats 统计快照的生成机制一次更新产出 3 类数据文件核心逻辑在 update_tables.py 的main()中。它先构建一个空的dashboard_data骨架包含timestamp、execution_duration_seconds、inbound、outbound四个字段dashboard_data { timestamp: datetime.now(timezone.utc).isoformat(), execution_duration_seconds: 0, inbound: {}, outbound: {} }随后对 inbound/outbound 分别执行“抓取 → 排除 → 输出”每处理完一条方向就填充对应分支见 update_tables.py#L544-L566dashboard_data[inbound] { sources: inbound_sources, # 每个源 URL 各自贡献的 IP 数量 raw_total: sum(inbound_sources.values()), unique_pre_collapse: len(inbound_ips), stats: inbound_stats # 压缩后的细分统计 }处理完成后脚本按“时间戳文件 latest.json”双写模式落盘update_tables.py#L571-L579timestamp_str datetime.now(timezone.utc).strftime(%Y%m%d_%H%M%S) with open(os.path.join(stats_dir, fstats_{timestamp_str}.json), w) as f: json.dump(dashboard_data, f, indent4) with open(os.path.join(stats_dir, latest.json), w) as f: json.dump(dashboard_data, f, indent4)文件角色特点stats/stats_20261022_145311.json历史快照文件名自带 UTC 时间戳每 2 小时新增一个stats/latest.json最新快照固定路径方便仪表盘/监控直接读取无需 globstats/history.json每日趋势由第二个脚本聚合生成这种“快照 最新指针”双写是标准库里实现观测数据发布的经典模式历史数据不可变、最新数据零查找成本。一份 stats 快照里到底记录了什么以 stats/latest.json 为例一次真实更新的记录包括字段示例值观测价值timestamp2026-10-22T14:43:1100:00更新时刻UTCexecution_duration_seconds600.79本轮耗时性能退化一眼可见inbound.sources约 90 个 URL → 各自条数最细粒度定位哪个源贡献多少inbound.raw_total9108192原始抓到的总条数inbound.unique_pre_collapse4646862去重排除后的唯一网络数inbound.stats.total_optimized_count4646862最终优化输出的条目数inbound.stats.top_metrics.total_ipv4_addresses_covered20356785覆盖的 IPv4 地址总数inbound.stats.top_metrics.cidr_distribution{32: 4381371, 24: 1035, ...}按前缀长度分布反映名单“粒度”结构其中sources字段最有排查价值inbound.sources中每个源都记了独立条数例如某源突然从数万条变成0快照里确实存在https://www.darklist.de/raw.php: 0这样的记录就意味着该源失效运维可以立即告警——这就是“源级数据质量监控”。top_metrics则在 write_files() 中顺手计算遍历压缩后的 IPv4 网络累加num_addresses得到覆盖地址总数并按prefixlen分桶得到 CIDR 分布几乎零额外成本。第二道防线history 历史趋势的生成机制90 天窗口 每日采样generate_history.py 是一个可以独立运行的小脚本generate_history()的文档注释写得很直白generate_history.py#L20-L30Parses stats json files to generate a history of total_ipv4_addresses_covered for the last 3 months. Only keeps one entry (the latest) per day in the output JSON.它的核心规则有三条扫描范围同时扫stats/和stats/archived/两个目录保证趋势完整90 天窗口cutoff_date datetime.now() - timedelta(days90)早于截止日期的文件直接跳过generate_history.py#L35每日只留一条以YYYY-MM-DD为键写入daily_records字典同一天的多次更新每天约 12 次后写的自然覆盖先写的最终每天只保留最新一次快照的值。提取的指标由extract_ipv4_covered()完成——把 inbound 与 outbound 的total_ipv4_addresses_covered相加generate_history.py#L10-L17并对 JSON 缺失做了try/except容错坏文件只会打一条 Warning 而不会中断整个任务。最终产出的 stats/history.json 是一个按日期排序的数组每个元素只有 3 个字段{ date: 2026-07-24T22:55:47, timestamp: 1784933747.0, total_ipv4_addresses_covered: 23921068 }目前文件里已有约 90 天、440 行的记录数值从 7 月底的 2392 万缓慢增长到 10 月下旬的 2422 万——这条曲线就是整个黑名单项目的“生命线指标”任何断崖或异常跳变都会在图上无所遁形。自动归档让 stats 目录永远保持轻量generate_history.py还有一个容易被忽略的职责——归档。它把stats/根目录下所有stats_开头的快照移动到stats/archived/generate_history.py#L93-L100for filepath in files_to_archive: try: shutil.move(filepath, archive_dir) except Exception as e: print(fError moving {os.path.basename(filepath)}: {e})这带来了两个好处✅目录干净stats/根目录任意时刻只有最近一个周期3 个左右的快照 latest.jsonhistory.json仓库浏览体验很好✅历史不丢archived/下已积累约 2600 个文件每 2 小时一个 × 数周趋势重建永远有据可查单文件归档失败也只是打印错误而不影响其他文件。值得注意的小细节归档逻辑用shutil.move而非重命名且对latest.json/history.json显式排除ignored_files集合避免把“指针文件”当数据文件处理。快速上手本地复现整套统计机制由于零第三方依赖复现整套 stats/history 流程只需要标准库。如果希望 clone 仓库git clone https://gitcode.com/gh_mirrors/ip/ipblocklist cd ipblocklist步骤命令产物1. 执行全量更新python update_tables.py更新 inbound.txt、outbound.txt新增stats/stats_*.json并刷新 stats/latest.json2. 生成每日趋势python generate_history.py重建 stats/history.json旧快照移入stats/archived/3. 调试排查python update_tables.py --debug输出 DEBUG 级日志加--no-mp可关闭多进程便于断点 说明完整跑一次需要遍历几十家外部数据源并做大规模并集/排除计算参考latest.json官方单次约 10 分钟本地体验建议直接阅读仓库中已生成的stats/文件来理解数据形态。关键启示标准库也能做出专业的数据可观测性回顾 ipblocklist 的 stats 与 history 机制可以提炼出 4 条可直接搬走的实践观测数据与业务数据同仓统计快照直接随代码仓库提交无需额外存储设施git log天然就是数据变更审计日志“时间戳快照 latest.json 指针”双写历史不可变、最新零成本读取监控和仪表盘各取所需源级明细是排查的命脉sources字段让“哪个数据源坏了”从猜谜变成查表趋势与明细分层stats_*.json存全量细节可按需归档history.json只存每日单值兼顾回溯深度与读取轻量。整套机制只用了json、os、glob、shutil、datetime、concurrent.futures、ipaddress、urllib这些标准库模块证明了数据可观测性不需要昂贵的技术栈——清晰的指标定义 可靠的落盘纪律才是可观测性的核心。赞分享【免费下载链接】ipblocklistIP lists full of bad IPs - Updated every 2H项目地址https://gitcode.com/gh_mirrors/ip/ipblocklist点击查看免费下载相关推荐Headroom 可观测性实战/stats、/stats-history、Prometheus 与 OTEL 指标体系详解Headroom 可观测性实战/stats、/stats history、Prometheus 与 OTEL 指标体系详解 Headroom 把“省了多少 t人工智能大模型LLM网关AI Agent终极指南如何使用Nightingale与OpenTelemetry构建统一可观测性平台终极指南如何使用Nightingale与OpenTelemetry构建统一可观测性平台 Nightingale作为一款集成Prometheus和Grafana后端可观测性指标监控告警AI AgentPython 标准库 xmlrpc.server 详解用 SimpleXMLRPCServer 与 CGIXMLRPCRequestHandler 搭建 XML-RPC 服务Python 标准库 xmlrpc.server 详解用 SimpleXMLRPCServer 与 CGIXMLRPCRequestHandler 搭建 XM编程语言语言运行时标准库解释器创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
