Nearly All Indices UNASSIGNED and All Are Red

Mark. No translogs have been deleted (at least not by a human, to my knowledge). Thanks for stopping me from doing that. I would have had to figure out how to do it, anyway. :wink:
As for what do the logs say.... nothing, since 1/14, when I last restarted all the services. Here is an excerpt...
[2016-01-14 11:36:41,628][INFO ][cluster.routing.allocation.decider] [Captain Universe] low disk watermark [85%] exceeded on [SYXHSEqLTPeElwJ0thmVjg][Captain Universe][G:\ELK_Stack\elasticsearch-2.0.0\data\elasticsearch\nodes\0] free: 291.5gb[14.9%], replicas will not be assigned to this node
[2016-01-14 11:37:12,182][INFO ][cluster.routing.allocation.decider] [Captain Universe] rerouting shards: [one or more nodes has gone under the high or low watermark]
[2016-01-14 14:40:13,044][INFO ][node ] [Captain Universe] stopping ...

then a bunch of DEBUG entries for Captain Universe "failed to execute" and "no such index" messages for index folders that still do exist for the Captain Universe shutdown... pretty much all of them, but I didn't do a full check/inventory of that.

(I hope that was relevant info)

Then...
[2016-01-14 14:40:14,122][WARN ][transport ] [Captain Universe] Transport response handler not found of id [6250]
[2016-01-14 14:40:14,325][INFO ][node ] [Captain Universe] stopped
[2016-01-14 14:40:14,325][INFO ][node ] [Captain Universe] closing ...
[2016-01-14 14:40:14,325][INFO ][node ] [Captain Universe] closed
[2016-01-14 14:40:16,078][INFO ][node ] [Vibraxas] version[2.0.0], pid[7892], build[de54438/2015-10-22T08:09:48Z]
[2016-01-14 14:40:16,078][INFO ][node ] [Vibraxas] initializing ...
[2016-01-14 14:40:16,188][INFO ][plugins ] [Vibraxas] loaded [], sites []
[2016-01-14 14:40:16,344][INFO ][env ] [Vibraxas] using [1] data paths, mounts [[EVA2_1950GB (G:)]], net usable_space [324.8gb], net total_space [1.9tb], spins? [unknown], types [NTFS]
[2016-01-14 14:40:19,953][INFO ][node ] [Vibraxas] initialized
[2016-01-14 14:40:19,953][INFO ][node ] [Vibraxas] starting ...
[2016-01-14 14:40:20,219][INFO ][transport ] [Vibraxas] publish_address {10.48.32.123:9300}, bound_addresses {10.48.32.123:9300}
[2016-01-14 14:40:20,219][INFO ][discovery ] [Vibraxas] elasticsearch/5MWU_9vSSUqjQ6Fgpis_OQ
[2016-01-14 14:40:24,313][INFO ][cluster.service ] [Vibraxas] new_master {Vibraxas}{5MWU_9vSSUqjQ6Fgpis_OQ}{10.48.32.123}{10.48.32.123:9300}, reason: zen-disco-join(elected_as_master, [0] joins received)
[2016-01-14 14:40:24,688][INFO ][http ] [Vibraxas] publish_address {10.48.32.123:9200}, bound_addresses {10.48.32.123:9200}
[2016-01-14 14:40:24,688][INFO ][node ] [Vibraxas] started
[2016-01-14 14:40:26,016][INFO ][gateway ] [Vibraxas] recovered [44] indices into cluster_state

and nothing after that.

What's _cat/state and _cat/indices show?

_cat/state results in error, no feature for name [state], status 400. I tried stats, _stats, and _state, as well, but all resulted in some form of error.
_cat/indices lists 44 lines of logstash file names, all green and open. I also happen to have 44 logstash folders on the disk.

Err, dunno what I was thinking with _cat/state, maybe _cat/allocation?

Can we actually see the ouput?

_cat/allocation returns the following (IP address obfuscated).
220 1.5tb 324.8gb 1.9tb 83 AA.BB.CC.DD AA.BB.CC.DD Vibraxas

Did you want to see the output of the _cat/indices, too? Here's an excerpt. Note: all dates in January are supposed to be 2016.
green open logstash-2015.12.10 5 0 55336255 0 35.7gb 35.7gb
green open logstash-2015.12.17 5 0 55317850 0 35.8gb 35.8gb
green open logstash-2015.01.01 5 0 33542704 0 21gb 21gb
green open logstash-2015.12.06 5 0 43955294 0 27.6gb 27.6gb
green open logstash-2015.12.16 5 0 55482842 0 35.9gb 35.9gb
green open logstash-2015.12.26 5 0 43452017 0 27.3gb 27.3gb
green open logstash-2015.11.29 5 0 43266795 0 27.1gb 27.1gb

@warkolm, do you have any other advice or direction for me?

I am not seeing anything red in that output?

Nope... there isn't. I stated in my post on Jan 19 that all logstash files were green and opening. I resolved the "unassigned" and "red" status a while back. The issue, now, is no new logstash files (folders) are getting created.

Oh, right.
Can you create one manually -curl -XPUT HOST:9200/testindex.

yes, I can... I accidentally created one before, and then deleted it... but, yes, I can create a new index, and it creates a new folder.

So then it's probably an LS problem, try restarting it.

I apologize, I am still too new to know all the lingo. LS? If that means local service, I have restarted all of them immediately after I freed up the disk space below the high watermark, and then again, the following day. No joy.
If LS doesn't mean local services, then you'll have to translate for me.

Logstash. Make sure things are flowing through there.

I have restarted the logstash service several times over the days... sometimes by itself (with Kibana restarted at the same time, as it is dependent on LS), and sometimes as part of a restart of the elasticsearch service (and dependents). It has never helped. I restarted it just now, and still, no joy. I am also having a hard time finding any logs related to logstash (this is a windows server; I can't see any log files in the logstash-2.0.0 folder and its subfolders).

In addition, tonight is "patch night" and the server has been patched and rebooted, so all services have been restarted. Still no joy on new logstash indices or folders.

It's probably worth making a new thread in the LS area with configs so we can dig further.

Mark,
I tried getting help over in logstash forum, and made some progress. I decided to run back to this forum when it appears the problem might still be in my elasticsearch configuration.

Short (hopefully) recap:
At one point, the logstash was doing it's thing, and elasticsearch was doing it's thing. I don't believe I had "control" of elasticsearch (via curl commands or the Sense plugin) as I had never tried that before.
The disks filled up.
I started looking into how to get things functioning again, and just "using" the environment.
At some point, I changed the elasticsearch.yml config file to include:
network.host: aa.bb.cc.dd
where aa.bb.cc.dd is the public IP of this Windows-based ELK server.
I was now able to control the elasticsearch environment, but both logstash and kibana stopped working.
It turns out by putting that entry in, it only listens on that IP, and no longer listens on localhost (as far as I can determine).

I found the following page.

I was unable to get what was suggested on that page to work. In the end, I have removed the network.host entry, completely, so the system is now working, but I am unable to control (query, delete, etc) via curl commands on a separate linux server or the Sense plugin (and I have yet to figure out how to control things locally on the Windows ELK server).
Can you either suggest articles etc on how to control the elasticsearch environment on the Windows 2012 R2 ELK server (without loading Chrome and Sense on it), or configure the elasticsearch environment to listen on both localhost and public IPs?

Take a gander at Connectivity issues with a new/upgraded 2.X cluster? Read here first :)

Perused, and digested. No help, darn it! By reading over that, the linked Network Changes, and the linked Network Settings pages, I did determine I had a typo in my settings; I had bind.host instead of bind_host. Regardless, after correcting that, trying with and without quotes, with and without a space between the two IP addresses, I still have no joy. Logstash is still functioning, but I am unable to connect to and control elasticsearch from another linux server or from Chrome and the Sense plugin, both of those are systems off of the local host box.
Still stuck.
Here are my current settings.
network.bind_host : [10.1.2.3,127.0.0.1]
network.publish_host: 10.1.2.3