Thanks for starting this topic - it's one that is very close to my heart!
Resin helps with the deploy of the gateways (see this recent post for more details on how to do it), however, monitoring what is going on inside the gateway software itself is more of an issue.
At the moment, I've built SNMP into the image I use with Resin and I have a collector that queries the devices via the local network and feeds data on CPU/RAM/Disk back into LibreNMS along with all of my other networking infrastructure, however visibility into what the packet forwarder itself is doing is very limited.
Whilst Salt is good for configuration management and deployment, I'd recommend against it for monitoring and instead suggest installing a dedicated monitoring tool like collectd and configure it to use the StatsD output plugin to send the data to a monitoring solution such as Graphite.
What would be really nice is for the developers of the official TTN packet forwarder to implement a StatsD client in the forwarder itself that sends the metrics that are currently written to the logs to a StatsD server of the deployer's choosing - this would allow for all sorts of things to be graphed and monitored via a free home-brew Graphite solution or a commercial monitoring as a service option such as Outlyer or Datadog, both of whom support StatsD natively.
Finally, whilst Resin is currently "proprietary", they will be moving to a model in the near future where you can host your own solution based on an open-source version of their product. I'm not 100% sure what that looks like yet, as not all of the details have been released, however I'm reasonably sure that just like the TTN On-site deployment it probably won't have a shiny console but will have 99% of the other functionality.
 Yes, I'm aware it's OpenSource and I could patch it myself, but that would require me to learn GO, which I've not quite managed to do yet - if I get there before the Devs do, then I'll add the feature myself