From: Ramsey G. <ram...@gm...> - 2013-02-23 02:49:24
|
On Feb 22, 2013, at 6:28 PM, Pascal Robert wrote: > > Le 2013-02-22 à 20:07, Ramsey Gurley <rg...@sm...> a écrit : > >> >> On Feb 22, 2013, at 5:45 PM, Pascal Robert wrote: >> >>> >>> Le 2013-02-22 à 19:37, Ramsey Gurley <rg...@sm...> a écrit : >>> >>>> >>>> On Feb 22, 2013, at 5:34 PM, Pascal Robert wrote: >>>> >>>>> >>>>> Le 2013-02-22 à 19:33, Ramsey Gurley <rg...@sm...> a écrit : >>>>> >>>>>> Hey Guys, >>>>>> >>>>>> I have a great idea. Let's put an ssh server into wotaskd. I'm sure no one has ever thought of this before and it is totally my original idea :P >>>>>> >>>>>> But seriously, I remember reading some list chatter about Pascal rolling ssh into wotaskd for sftp. I don't see it in latest integration. Is that happening soon? Inquiring minds. >>>>> >>>>> https://github.com/pascalrobert/wonder/commits/wotaskd_ftp >>>> >>>> So only pascalrobert/wonder and not on projectwonder/wonder? Not ready yet? >>> >>> Ready for me, but looks like it's ideologic. I added it to wotaskd to make it easier for people to deploy, and it's enabled by default. But looks being enabled by default is a "problem", and the "solution" was to have two different startup scripts, one that don't enable the SSH server, one that does. So it will confuse people, and I will again get people contact me directly for deployment help because permission issues (the main reason why I added the SSH server into wotaskd) is one of the two common mistakes for deployment. >>> >>> See https://github.com/projectwonder/wonder/pull/269 >> >> I guess I should have been paying closer attention. I'm at a loss. How is enabled by default a security risk? > > Brute force attack for denial of service… But if someone close the wotaskd port (1085), logically they can close the port for the SSH server too… Yeah. This sounds like a configuration over convention argument. Show of hands. Anyone running wotaskd without a firewall between it and the internet? Anyone, anyone? Bueller? Who's going to have 6022 open? I thought there must be some other argument. >> I'm thinking it would be nice if java monitor actually monitored something. Sorta like nagios but better. > > Personally, I don't see the need of JavaMonitor anymore. A JavaScript app that connects to the REST APIs of wotaskd to manage the apps would be cool. I think the monitor is way more durable in the long run. JavaScript has a way of becoming dated. What works great now becomes sucktacular in as little as two years. http://calendar.perfplanet.com/2012/snow-in-canvas-land/ >> Maybe ssh over to the host and grab a snapshot of 'top' every 30 seconds or so. Archive that in a database. Then, when I have users complaining an app is slow, I can figure out why, instead of being in the dark. "Oh look... "Backup 18 kajillion GBs of data" runs at peak hours. No wonder there are complaints. Let's update crontab!" >> >> Feel free to point out if nagios can actually do this already :D > > Dunno about grabbing top usage, but you can collect CPU and memory usage and have graphs. Well, I have the memory graph for java procs at work, but it's pretty useless for diagnosing "Why is my apps slow this mornins!!!11!ONE!!" And the cpu monitor doesn't even graph. I just get a box with red, yellow, or green. Sucks tremendously. I need it to capture more info than I'm getting. >> In fact, it would be really cool if we could go one step further. Instead of just memory and cpu from procs, it would be really nice if we could look at memory allocated vs memory in use on apps, # of threads, you know, the kind of stuff jvisualvm dumps out. So maybe we can haz not just ssh but also jstat or some nice jmx stuff? > > JMX integration into Monitor or another tool would make sense. > > What I would really like to see is a tool that can detect usage in the apps and start instances/hosts when needed. Yeah, that would be the next step. Once we can detect whatever is "too much load," we can set up rules to kick up more instances on amazon or something. Ramsey |