我有100多个web服务器实例使用apc运行php应用程序，我们偶尔(在整个团队中每周一次)会看到其中一个缓存损坏，从而导致一条独特的错误日志消息。
一旦发生这种情况，那么应用程序在该节点上就死了——路由到它的任何事务都将失败。
我已经围绕tail -F编写了一个简单的包装器，它可以在模式出现在日志文件中的任何时候发现它，并评估shell命令(使用basheval)以做出反应。我使用salt stack中的salt-call命令触发处理一个自定义模块，该模块关闭nginx服务器，预热(刷新)缓存，当然，还重新启动web服务器。(实际上我有两种形式的包装器，bash和Python)。
这很好，而且事件的频率很高，不太可能成为问题。然而，我的老板非常合理地担心共模故障模式。。。正则表达式可能同时出现在太多的日志中，并占据整个站点。
我的第一个想法是将我的salt-call封装在redis检查中(我们已经有了用于缓存和某些其他数据结构的redis基础设施)。这将被实现为一个带有过期的整数。如果返回N个以上(或者Redis服务器无法访问)，则检查将调用INCR，检查结果并休眠。如果结果低于阈值，则将调度salt-call，并在服务器备份并运行后调用减量。(Redis密钥的到期可能会在一天甚至几个小时后杀死任何过时的增量……我们的警报系统已经通知我们服务器停机，我们的响应时间足以满足这种时间范围)。
然而，我读到了关于Saltstack事件处理功能的文章，并想知道使用它是否会更好。(优点是，节点既没有redis-cli命令工具，也没有Python Redis库，但很明显，salt-call已经具备了必要的支持)。因此，在Salt中使用某些东西可以最大限度地减少向这些系统添加额外包和依赖项的需要。(或者，我可以将所有Redis处理作为一个单独的PHP命令行实用程序编写，并让我的shell脚本调用它)。
有没有HOWTO用于编写简单的Saltstack模块？这些文件似乎在没有任何方向的情况下深入参考细节。甚至一些关于搜索哪些术语的建议也会很有帮助(因为它们对支柱、谷物、小黄人等术语的使用似乎有些不透明)。
编写Salt模块的主文档如下：http://docs.saltstack.com/en/latest/ref/modules/index.html
Salt附带了许多模块，这些模块可能有助于获得灵感。你可以在这里找到它们：https://github.com/saltstack/salt/tree/develop/salt/modules
需要记住的一件事是，除非你让盐小兵做点什么，否则它什么都不做。因此，您可以创建一个模块来检查您提到的错误模式，但您需要将其添加到Salt Scheduler或cron中，以确保它能够频繁运行。
如果你需要更多帮助，你会在freenode上的#salt中找到IRC上有帮助的人。