Two things to consider:
The authentication model is pretty different for a network connection to the daemon vs. a local socket connection. It may in fact be preferable to do from the network connection, although I assume we want to keep the socket as well for "my machine is in bad shape but I need daemon info" debugging path.
Also, Calamari offers a way to access this information remotely, either summarized in various ways or actually even directly:
sudo salt 'mira102*' ceph.admin_socket /var/run/ceph/ceph-osd.8.asok '[help]'
mira102.front.sepia.ceph.com:
{ "config get": "config get <field>: get the config value",
"config set": "config set <field> <val> [<val> ...]: set a config variable",
"config show": "dump current config settings",
"dump_blacklist": "dump blacklisted clients and times",
"dump_historic_ops": "show slowest recent ops",
"dump_op_pq_state": "dump op priority queue state",
"dump_ops_in_flight": "show the ops currently in flight",
"dump_watchers": "show clients which have active watches, and on which objects",
"get_command_descriptions": "list available commands",
"getomap": "output entire object map",
"git_version": "get git sha1",
"help": "list available commands",
"injectdataerr": "inject data error into omap",
"injectmdataerr": "inject metadata error",
"log dump": "dump recent log entries to log file",
"log flush": "flush log entries to log file",
"log reopen": "reopen log file",
"perf dump": "dump perfcounters value",
"perf schema": "dump perfcounters schema",
"rmomapkey": "remove omap key",
"setomapheader": "set omap header",
"setomapval": "set omap key",
"truncobj": "truncate object to length",
"version": "get ceph version"}
This communication uses the normal Calamari salt remote-execution. It might be useful/helpful, and could be added to the Calamari REST API easily as well.