5 ms·

Inspeqtor: easy application infrastructure monitoring

77 points by mperham 12y ago

jameskilton 12y ago
Couldn't help but notice that the config file syntax is almost exactly like Monit. Inspeqtor's definitely is more concise and easier to read (and probably write), was Monit an influence in designing this tool?
- jarod7736 12y ago
  https://github.com/mperham/inspeqtor/wiki/Other-Solutions https://github.com/mperham/inspeqtor/wiki/Other-Solutions
pitr 12y ago
Seems that, unlike Sidekiq, this starts as a heavily commercial solution, and it shows. Landing page has a pretty big "Buy Pro" call-to-action button. Features like support for notifying slack/etc I'd expect to be present in a free version. Open source feels more of an afterthought. I don't feel comfortable using even the free version, simply because if the project fails financially, it is likely to be dropped altogether.
- zrail 12y ago
  The fact that there is a commercial version is proof that mperham wants and expects the project to continue sustainably. That said, the open source version provides more than Monit in a better, easier to deploy package. I think that right there is incentive enough to use it. Plus, if you want to fork it and add your own specific notification channels, here's the source: https://github.com/mperham/inspeqtor/blob/891517cc0edc6dda8d5faa2f6e0bd8ef03a4f27c/actions.go https://github.com/mperham/inspeqtor/blob/891517cc0edc6dda8d...
  - pitr 12y ago
    I agree that ease of use is the strongest reason to use this. Just because mperham wants the project to be sustainable doesn't guarantee it. However, if sidekiq Pro would have failed, Sidekiq would easily survive simply because of huge open source community. With inspeqtor it's not so clear. "Route alerts to your team chat room" is listed as a Pro feature. Any PR implementing it is unlikely to be merge in. And creating a separate fork for a relatively small feature should not really be an answer to an open-source project.
    - zrail 12y ago
      See mperham's reply here: https://news.ycombinator.com/item?id=8401372 https://news.ycombinator.com/item?id=8401372
- mperham 12y ago
  Long story short: I'm new to Go and wasn't sure how to manage the codebases for both an OSS product and commercial product together so I built the two in tandem to work out the kinks. Since the commercial product was already written, why not sell it from day one? The OSS product is targeted to small teams, individuals and hobbyists. Pro was designed to target larger teams and the features they would need.
sbarre 12y ago
I get "Unable to locate package inspeqtor" when trying to install on Ubuntu 13.10. The docs specifically say "12.04 and 14.04" but also "really any Debian system using Upstart". Is 13.10 not supported?
- mperham 12y ago
  I only provide LTS binaries since that's what most people run in production. You can change your distro name to be precise or trusty in the packagecloud repo in /etc/apt/sources.list.d. It's a Go binary so it doesn't depend on anything distro-specific.
  - sbarre 12y ago
    Great, thanks!
mnutt 12y ago
Inspeqtor compares itself to monit, god, supervisord, etc, but it looks like it only handles the monitoring of processes and not stop/start/restart, correct? It seems like it would be difficult to decouple those when we use monit for things like "if mem > 200m for 2 cycles then restart".
- mperham 12y ago
  Inspeqtor uses your init system to restart services. It does not manage arbitrary processes.
michaelmior 12y ago
Curious how you plan on managing a pro version of the product when the free version is open source. Will you just be rejecting pull requests which add features which are in the pro version? Given that the code is licensed GPL, this seems to be inviting a fork which will have additional features which would otherwise be restricted to the pro version.
- mperham 12y ago
  That's a natural question. People are welcome to fork and add their own features. They will need to support and maintain their features just like me. They will need to pull in upstream changes or their fork will rapidly age. I target Inspeqtor Pro at teams and businesses with a real budget. They want a supported, pre-packaged product that solves their problem. If someone is willing to find and use some other person's fork, they were probably never going to pay for the Pro product in the first place and therefore there's little to no real competition here.
  - skrebbel 12y ago
    Good points, but you didn't actually answer the question. Will you reject pull requests that compete with Pro features?
- mperham 12y ago
  Would I reject PRs? Quite possibly; that seems super passive-aggressive to me. It would be more polite to open an issue first and discuss the situation.
  - deleted 12y ago
    [deleted]
  - michaelmior 12y ago
    I wasn't suggesting the case where someone explicitly does all the work and opens a PR which implements a feature of the pro version. I was moreso considering someone who had implemented something that was on the roadmap for the pro version. In either case, it's reasonable to say you would reject PRs. I'm just wondering how governance of the project works. I assume you're already dealing with the same sort of thing with Sidekiq. I just find this sort of business model interesting since the more common approach seems to be providing hosting or priority support.
aorth 12y ago
I just tried to get it to monitor nginx on Ubuntu, but couldn't get it working. I opened a GitHub issue. https://github.com/mperham/inspeqtor/issues/13 https://github.com/mperham/inspeqtor/issues/13 Anyways, it looks simple and I'm looking forward to it maturing. It will be nice to template and deploy via Ansible. I'm interested in monitoring PostgreSQL, Tomcat, etc...

77 points by mperham 12y ago

Couldn't help but notice that the config file syntax is almost exactly like Monit. Inspeqtor's definitely is more concise and easier to read (and probably write), was Monit an influence in designing this tool?

jarod7736 12y ago
https://github.com/mperham/inspeqtor/wiki/Other-Solutions https://github.com/mperham/inspeqtor/wiki/Other-Solutions

pitr 12y ago

Seems that, unlike Sidekiq, this starts as a heavily commercial solution, and it shows. Landing page has a pretty big "Buy Pro" call-to-action button. Features like support for notifying slack/etc I'd expect to be present in a free version. Open source feels more of an afterthought. I don't feel comfortable using even the free version, simply because if the project fails financially, it is likely to be dropped altogether.

zrail 12y ago
The fact that there is a commercial version is proof that mperham wants and expects the project to continue sustainably. That said, the open source version provides more than Monit in a better, easier to deploy package. I think that right there is incentive enough to use it. Plus, if you want to fork it and add your own specific notification channels, here's the source: https://github.com/mperham/inspeqtor/blob/891517cc0edc6dda8d5faa2f6e0bd8ef03a4f27c/actions.go https://github.com/mperham/inspeqtor/blob/891517cc0edc6dda8d...
- pitr 12y ago
  I agree that ease of use is the strongest reason to use this. Just because mperham wants the project to be sustainable doesn't guarantee it. However, if sidekiq Pro would have failed, Sidekiq would easily survive simply because of huge open source community. With inspeqtor it's not so clear. "Route alerts to your team chat room" is listed as a Pro feature. Any PR implementing it is unlikely to be merge in. And creating a separate fork for a relatively small feature should not really be an answer to an open-source project.
  - zrail 12y ago
    See mperham's reply here: https://news.ycombinator.com/item?id=8401372 https://news.ycombinator.com/item?id=8401372
mperham 12y ago
Long story short: I'm new to Go and wasn't sure how to manage the codebases for both an OSS product and commercial product together so I built the two in tandem to work out the kinks. Since the commercial product was already written, why not sell it from day one? The OSS product is targeted to small teams, individuals and hobbyists. Pro was designed to target larger teams and the features they would need.

sbarre 12y ago

I get "Unable to locate package inspeqtor" when trying to install on Ubuntu 13.10. The docs specifically say "12.04 and 14.04" but also "really any Debian system using Upstart". Is 13.10 not supported?

mperham 12y ago
I only provide LTS binaries since that's what most people run in production. You can change your distro name to be precise or trusty in the packagecloud repo in /etc/apt/sources.list.d. It's a Go binary so it doesn't depend on anything distro-specific.
- sbarre 12y ago
  Great, thanks!

mnutt 12y ago

Inspeqtor compares itself to monit, god, supervisord, etc, but it looks like it only handles the monitoring of processes and not stop/start/restart, correct? It seems like it would be difficult to decouple those when we use monit for things like "if mem > 200m for 2 cycles then restart".

mperham 12y ago
Inspeqtor uses your init system to restart services. It does not manage arbitrary processes.

michaelmior 12y ago

Curious how you plan on managing a pro version of the product when the free version is open source. Will you just be rejecting pull requests which add features which are in the pro version? Given that the code is licensed GPL, this seems to be inviting a fork which will have additional features which would otherwise be restricted to the pro version.

mperham 12y ago
That's a natural question. People are welcome to fork and add their own features. They will need to support and maintain their features just like me. They will need to pull in upstream changes or their fork will rapidly age. I target Inspeqtor Pro at teams and businesses with a real budget. They want a supported, pre-packaged product that solves their problem. If someone is willing to find and use some other person's fork, they were probably never going to pay for the Pro product in the first place and therefore there's little to no real competition here.
- skrebbel 12y ago
  Good points, but you didn't actually answer the question. Will you reject pull requests that compete with Pro features?
mperham 12y ago
Would I reject PRs? Quite possibly; that seems super passive-aggressive to me. It would be more polite to open an issue first and discuss the situation.
- deleted 12y ago
  [deleted]
- michaelmior 12y ago
  I wasn't suggesting the case where someone explicitly does all the work and opens a PR which implements a feature of the pro version. I was moreso considering someone who had implemented something that was on the roadmap for the pro version. In either case, it's reasonable to say you would reject PRs. I'm just wondering how governance of the project works. I assume you're already dealing with the same sort of thing with Sidekiq. I just find this sort of business model interesting since the more common approach seems to be providing hosting or priority support.

aorth 12y ago

I just tried to get it to monitor nginx on Ubuntu, but couldn't get it working. I opened a GitHub issue. https://github.com/mperham/inspeqtor/issues/13 https://github.com/mperham/inspeqtor/issues/13 Anyways, it looks simple and I'm looking forward to it maturing. It will be nice to template and deploy via Ansible. I'm interested in monitoring PostgreSQL, Tomcat, etc...