构建并保持fedmsg统计信息的守护进程
项目描述
一个用于构建和保持 fedmsg 统计信息的守护进程。
动机：我们有一个名为 datagrepper 的整洁服务，您可以查询 fedmsg 总线的历史记录。它很酷，但对于我们想要进行的某些更高级的报表和分析来说还不够。以 releng-dash 为例。为了渲染页面，它必须向 datagrepper 发出数十次或更多请求，以尝试从大量笨拙的结果页面中找到“最新”的事件。因此，它加载时间很长。
于是出现了 statscache。它是一个 fedmsg-hub 的插件，驻留在我们的基础设施中监听。当新的消息到达时，它会将它们传递给 插件，这些插件将计算和存储各种统计信息。如果我们想要保持新的统计信息，我们就会为它编写一个新的插件。它将附带一个微型的 flask 前端，就像 datagrepper 一样，允许您以各种格式（csv、json，也许还有 html 或 svg，但这可能有点过度了）查询此或彼统计信息。我们的想法是，我们可以构建更整洁、更智能的前端，可以快速渲染基于 fedmsg 的活动，也许以后可以深入挖掘 datagrepper 中保留的 详细信息。
它有点像一个 数据集市。
如何运行它
创建一个 virtualenv，并 git 克隆此目录和 statscache_plugins 仓库。
首先在 statscache 目录中运行 python setup.py develop，然后在 statscache_plugins 中运行它。
在主 statscache 仓库目录中，运行 fedmsg-hub 以启动守护进程。您应该在 stdout 中看到大量有趣的统计数据。要启动 Web 界面（目前只提供 JSON 和 CSV 响应），在同一目录中运行 python statscache/app.py。现在您可以访问 localhost:5000/api/ 查看可用的插件列表（以 JSON 格式），您可以通过将给定插件的标识符附加到该 URL 来检索该插件记录的统计信息。
您可以使用 python setup.py test 运行测试。
它是如何工作的
当消息到达时，fedmsg 消费者 接收它并将副本传递给每个加载的插件进行处理。每个插件内部缓存此消息处理的结果，直到 轮询生产者 指示它更新其数据库模型并清空其缓存。轮询生产者这样做的时间间隔可以在应用程序级别进行配置，默认设置为每秒一次。
每个插件都应该使用基础 sqlalchemy 模型来存储其结果（我们可以根据发现的新需求添加更多类型的基模型）。但关于基模型的重要一点是，它们负责知道如何将自身序列化为不同的格式以供 REST API 使用（例如，渲染 .to_csv() 和 .to_json()）。
尽管statscache旨在作为长期运行的服务，但偶尔重启是不可避免的。然而，fedmsg数据处理历史的中断可能会导致某些插件生成不准确的统计数据。幸运的是，statscache内置了一种机制来透明地处理这种情况。在启动时，statscache会检查每个插件最近数据库更新的时间戳，并查询datagrepper以获取填充任何空白所需的fedmsg数据。另一方面，如果插件不需要连续查看fedmsg历史记录，则它可以指定一个“回溯增量”，这是对它有用的最大fedmsg数据回溯量。
statscache-0.0.4.tar.gz的哈希值
| 算法 | 哈希摘要 | |
|---|---|---|
| SHA256 | 8d54b85db4807732cc9ba510cf3b6729195dc063bb126994cc951f19971575cc |
|
| MD5 | a3b4df109298325a2563dcb2572f9112 |
|
| BLAKE2b-256 | 6a4220ef95bc8f3d23ee34b8517a06f476466b373cad44a5229e434cc62f8636 |