Ahh so it will be mostly a Push interface, that makes it wonderfully simple. 
In that case you’d want to just set up a proper path in your router for them to communicate too, and if it is just status information and you do not care about history then I’d keep the current state of each in mnesia while also broadcasting it out via the Phoenix.PubSub system. A channel can grab the ‘current’ state from mnesia and send that to the client while also subscribing to updates (subscribe to the PubSub topic before grabbing the current state just to make sure no race condition) that the events will be sent over. Assuming some simple kind of event where the msg is just something like a map with keys, one for the server and the other for its state, then very simple, can add more with ease as well. Just have the channels listen to those PubSub messages and re-route them over the channel as necessary.
A persistent channel is always better, and very cheap in Phoenix unlike most web frameworks, so yes, keep it open.
But yep, with the style I mentioned above it would be easy. But I’d definitely say that you’d want to make a unified view of your messages, I’d encapsulate it in a struct, maybe something like:
defmodule TaskState do
@derive [Poison.Encoder] # This makes it so you can auto-serialize it to json
defstruct [:server_id, :state, :comment]
end
And I’d have each just be a binary/string for ease of use since it is mostly for being consumed by clients. I’d maybe add some more parts for things like how long it has been running or so if you want to display that information too. Then just store this even in mnesia with a key of the server_id or so along with also broadcasting it out on the PubSub then have the channels listen for it and re-push it out along their channel (at this step you could easily filter so someone only sees the server_id’s they are interested in too).
You could easily have each server_id have its own page with a listing of its own tasks, if you go more fine grained like that then your mnesia key would be a tuple of, say, server_id and task_id for example.
Mnesia is fine as long as your data stays below 2 gigs, which if you are just storing the current state and little or no history as well as users, that is all fine, definitely use Mnesia though, Mnesia is a wrapper around ETS/DETS that provides transaction support and better look-up abilities. You rarely want to use DETS straight (it forces a disk sync on near every operation), although using ETS straight has many uses (like a global in-memory map).
As long as the total data stays less than 2 gigs it is fine. Regardless of what you choose, mnesia or postgresql, always put all functions that access them in other modules that you call so you can swap it out when you need. If Ecto had an mnesia layer (someone needs to make one) that would be great for abstracting it out, but for now just a module is fine.
Heh, sorry, I have a bad habit of making long posts. ^.^
