我正在构建monitoring tool in Erlang。在集群上运行时，它应该在所有节点上运行一组数据收集功能，并在单个“记录器”节点上使用RRD记录该数据。
当前版本的主节点（rolf_node_sup）上运行的主管会尝试在群集中的每个节点上运行第二个主管（rolf_service_sup）。然后，每个节点上的主管应该启动并监视一系列进程，这些进程将消息发送回主节点（rolf_recorder）上的gen_server。
这仅适用于本地。没有在任何远程节点上启动管理程序。我使用following code尝试从记录器节点加载节点上的主管：
rpc:call(Node, supervisor, start_child, [{global, rolf_node_sup}, [Services]])
我发现有几个人建议主管真的只是为本地流程而设计的。 E.g。
实现我的要求的最OTP方式是在集群中的所有节点上运行受监督的代码？
proc_lib:spawn_link在每个节点上启动一个主管。如果某个节点出现问题，代理进程应该死掉，然后由它的主管重新启动，然后主管应该重新启动远程进程。 slave模块在这里非常有用。一些要求：
答案 0 :(得分：4)
有趣的挑战，有多种解决方案。以下是我的建议，希望能让您更好地选择如何编写程序。
据我所知，您希望在启动应用程序时有一个主节点。这将启动集群中节点上的Erlang VM。 pool模块使用slave模块执行此操作，这需要在两个方向上进行基于密钥的ssh通信。它还要求你有适当的dns工作。
slave的一个缺点是，如果主设备死亡，那么从设备也会死亡。这是设计的，因为它可能完全适合原始用例，但在您的情况下它可能是愚蠢的（例如，您可能仍希望仍然收集数据，即使主服务器已关闭）
对于OTP应用程序，每个节点可以运行相同的应用程序。在您的代码中，您可以使用配置或发现来确定群集中的节点角色。
我建议使用一些操作系统工具或daemontools或类似工具来启动Erlang VM。每个VM都会启动相同的应用程序，其中一个将作为主服务器启动，其余的作为从服务器启动。这样做的一个缺点就是标记在集群中的机器上“自动”运行软件就像你使用slave一样，但是它也更加强大。
在每个应用程序中，您可以根据节点的角色拥有合适的监督树。删除节点间监督和产生使系统更加简单。
我还建议将所有节点推送到主节点。这样主机就不需要关心从机中发生的事情，甚至可能忽略节点故障的事实。这也允许添加新节点而无需对主节点进行任何更改。 cookie可以用作身份验证。多个主人或“录音机”也相对容易。
然而，“从”节点需要注意主机停机并启动并采取适当的措施，例如存储监控数据，以便以后在主机备份时发送它。
答案 1 :(得分：3)
我会调查riak_core。它提供了一层基础架构，用于在erlang和otp本身的原始功能之上管理分布式应用程序。在riak_core下，不需要将任何节点指定为主节点。没有节点是otp意义上的中心，任何节点都可以接管其他故障节点。这是容错的本质。此外，riak_core可以优雅地处理加入和离开集群的节点，而无需采用主/从策略。
虽然这种“拓扑”分散是方便的，但分布式应用程序通常需要逻辑上特殊的节点。出于这个原因，riak_core节点可以宣传它们正在提供特定的集群服务，例如，如您的用例，结果收集器节点所体现的那样。
另一个有趣的特性/体系结构后果是riak_core提供了一种机制，通过“八卦”协议维护集群成员可见的全局状态。
基本上，riak_core包含一堆有用的代码来开发高性能，可靠和灵活的分布式系统。您的应用程序听起来很复杂，具有强大的基础将比以后更快地支付股息。
otoh，几乎没有文件。 ：（
这是一个谈论他用riak_core编写的内部AOL应用程序的人：
http://www.progski.net/blog/2011/aol_meet_riak.html
以下是关于钢筋模板的说明：
http://lists.basho.com/pipermail/riak-users_lists.basho.com/2011-March/003632.html
...这里有关于该钢筋模板的一个分支的帖子：
...谈谈riak_core：
http://www.infoq.com/presentations/Riak-Core
... riak_core公告：