Roberto Thanks for these rapid fixes and your comment in the other thread. 1.4.9 is working very well for us.
We run a couple of applications; two of them are fairly large. Their load profiles don't match, so we're able to run them on the same servers as they scale up at different times. We configure uWSGI to have a handful of workers at any time, but allow for each site to summon zergs on demand. A single emperor runs per box, and it picks up and loads app vassal files when we symlink them to a certain dir. Each vassal file defines an app and whether or not that app will act as a broodlord. The config is nice and easy, and I imagine that this is a fairly common setup for uWSGI. So... I'd love to be able to easily get stats on what uWSGI is doing. With your fix, as of 1.4.9, I could have a script which polled the sockets of the workers and zergs for a given app, mashed the data together and proxied it on. But it seems like a pain to have so many sockets floating around for what is essentially the same app, especially where the workers and zergs are running under the same emperor. I can only run `uwsgitop` on one of the sockets at a time. Before I started looking into this, I assumed I could monitor a single socket and get info on everything. Making stats server or `uwsgitop` work usefully in production feels difficult and a bit hacky, which makes me think that I might be approaching it the wrong way. How would you expect users to do it? Best Aidan On 6 March 2013 17:30, Roberto De Ioris <[email protected]> wrote: > > > Hello > > > > I have been trying to monitor stats in our uWSGI instance. Our config -- > > without the stats stuff -- looks like this: > > > >>> > > env UWSGI_VASSAL_MODULE=wsgi_app > > env UWSGI_VASSAL_CHMOD=666 > > env UWSGI_VASSAL_DISABLE-LOGGING=true > > setuid www-data > > setgid www-data > > exec /usr/local/bin/uwsgi --log-syslog emperor --emperor > > /etc/uwsgi/vassals > > --emperor-broodlord 10 > > << > > > >>> > > [uwsgi] > > log-syslog=uwsgi-keepcalm > > socket=:3031 > > pythonpath=/var/www-hosts/keepcalm > > processes=4 > > zerg-server=/var/www-hosts/keepcalm/restricted/broodlord.sock > > vassal-sos-backlog=5 > > > > [zerg] > > log-syslog=uwsgi-keepcalm-zerg > > zerg=/var/www-hosts/keepcalm/restricted/broodlord.sock > > pythonpath=/var/www-hosts/keepcalm > > << > > > > This means we have an emperor process, then a [uwsgi] master with four > > workers underneath it. Under load, zerg masters will spawn, each with a > > single worker underneath them. > > > > > http://uwsgi-docs.readthedocs.org/en/latest/Options.html#emperor-stats-emperor-stats-server > > > > So, first off I tried `-emperor-stats` on :1717 in the main config. That > > was kinda useless, because all it told me was that there was there was a > > single Emperor doing very little. I expected it would return stats on all > > of the children underneath the emperor, but it doesn't. > > > > http://uwsgi-docs.readthedocs.org/en/latest/StatsServer.html > > > > So I then I tried `stats=:1717` in the [uwsgi] section. That conflicted > > with the emperor's use of the port, so I stopped the emperor from serving > > stats. That was great, it told me what the four normal workers were doing > > -- but it didn't give me the zerg stats. Of course, if I tell the zergs > to > > use :1717 they conflict with each other, the normal [uwsgi] workers and > > the > > Emperor. > > > > > Each instance (standard, or zerg), has to bind to a different address. > > Using unix socket is a good trick, and you can dinamically generate their > name for each vassal using magic vars: > > [uwsgi] > ... > stats = %n.stats.socket > > [zerg] > ... > stats = %s-zerg.stats.socket > > The problem arises if you have multiple zerg instances running. > > The only solution i can think of, is adding another magic var exporting > the zerg instance number in the config (%z ?) > > -- > Roberto De Ioris > http://unbit.it > _______________________________________________ > uWSGI mailing list > [email protected] > http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi >
_______________________________________________ uWSGI mailing list [email protected] http://lists.unbit.it/cgi-bin/mailman/listinfo/uwsgi
