我有超过 100 个使用apc运行php应用程序的 Web 服务器实例，我们偶尔（整个机群中每周一次的顺序）看到其中一个缓存损坏，这会导致一个独特的错误日志消息。
一旦发生这种情况，那么应用程序在该节点上就死了，任何路由到它的事务都将失败。
我编写了一个简单的包装器tail -F，可以在任何时候发现它出现在日志文件中的模式并评估一个 shell 命令（使用bash eval）来做出反应。我使用salt-stacksalt-call中的命令来触发处理自定义模块，该模块会关闭nginx服务器、预热（刷新）缓存，当然，还会重新启动 Web 服务器。（实际上我有两种形式的这个包装器和 Python）。bash
这很好，而且事件的频率如此之高，不太可能成为问题。然而，我的老板相当合理地担心一种常见的模式故障模式......正则表达式可能会同时出现在太多的这些日志中并占据整个站点。
我的第一个想法是将我包装salt-call在一个redis检查中（我们已经有一个用于缓存和某些其他数据结构的 Redis 基础设施）。这将被实现为一个具有过期时间的整数。检查将调用 INCR，检查结果，如果返回的 N 多（或者如果 Redis 服务器无法访问）则休眠。如果结果低于阈值，salt-call则将分派并在服务器备份并运行后调用递减。（Redis 密钥的过期可能会在一天甚至几个小时后终止任何陈旧的增量......我们的警报系统已经通知我们服务器已关闭，并且我们的响应时间对于这样的时间框架来说绰绰有余）。
但是，我正在阅读有关 Saltstack 事件处理功能的信息，并想知道是否使用它会更好。（优势，节点没有redis-cli命令工具，也没有 Python Redis 库，但显然salt-call已经有了它的必要支持）。因此，在 Salt 中使用某些东西可以最大限度地减少向这些系统添加额外包和依赖项的需要。（或者，我可以将所有 Redis 处理编写为单独的 PHP 命令行实用程序，然后让我的 shell 脚本调用它）。
是否有编写简单 Saltstack 模块的 HOWTO？文档似乎深入参考细节，没有任何方向。甚至一些关于搜索哪些术语的建议也会有所帮助（因为他们使用诸如柱子、谷物、奴才等术语似乎有些不透明）。