3 ms·

3 years ago I started a company (Stackify) with the hopes of building a better nagios. But it doesn't seem like developers really wanted it. They wanted and nee

3 years ago I started a company (Stackify) with the hopes of building a better nagios. But it doesn't seem like developers really wanted it. They wanted and needed a lot more as basic server metrics didn't really tell much of a story about application health. The shift to cloud based services also makes a lot of basic monitoring tools unnecessary. Cloud based apps don't really need to monitor servers or infrastructure beyond simple CPU and memory measurement. Developers need to monitor the app itself. Which can really only be done by code profiling, custom metrics, and analyzing errors and log statements. So we since pivoted a little bit and have focused heavily on true application monitoring via basic server metrics, custom app metrics, error tracking, log management, and true APM code profiling. All of this together provides a lot of power when it comes to monitoring and finding application problems. A lot of companies we talk to barely monitor anything about their apps. So many IT teams work in such a reactive mode they aren't very proactive when it comes to monitoring application health and behavior. Would love to get anyone's feedback about this topic. Do you just use basic server monitoring? How detailed do you monitor the actual behavior and health of your application? How do you do it? If you're curious you can check out our product. http://stackify.com http://stackify.com

cbaleanu 11y ago
Just curious, how is this related to the article on which you're commenting?
- spo81rty 11y ago
  Most developers in most IT departments don't even have access to monitoring tools and very little of developer/application importance is monitored beyond server up/down, cpu, and memory usage. A lot of the most important monitoring I do for my own application is looking at page load times, slow DB queries, custom app metrics, error rates, and looking for specific log statements. Many of these things can't even be done in basic monitoring systems. Bosun's alerting rules look awesome. But most people don't even know what to monitor, let alone figure out how to write javascript expressions to do so.
  - KyleBrandt 11y ago
    Bosun uses a custom DSL, not javascript. What you are saying is fair - bosun is currently targeted at an advanced audience currently. There is active discussion about making alerts GUI creatable to make it more accessible. Can hopefully be less vague about that in a few weeks.
Tiksi 11y ago
I don't wanna derail the comments here, since as cbaleanu mentioned it's pretty off topic, so I'll try to stay brief here. If you would like some more input, my email is in my profile. > But it doesn't seem like developers really wanted it. I don't see why (most) developers would want a monitoring system. Why not target sysadmins / devops? In my experience developers really just want a trace of their app when it breaks, or maybe some performance profiling. > The shift to cloud based services also makes a lot of basic monitoring tools unnecessary. Even though on HN it might seem like everyone is using "the cloud" for everything, the reality is quite different. There's a pretty sizable market for server monitoring, even in the case of cloud services, someone is managing the metal. > code profiling, custom metrics, and analyzing errors and log statements. newrelic provides a lot of these, although I'm personally not a fan (it seems like their daemon is the main thing causing resource alerts), and has a free tier. >So many IT teams ... aren't very proactive when it comes to monitoring application health and behavior. Well if you're talking to IT teams, they may not be able to do anything proactive regarding health / behavior of applications. In many cases the team making sure the service stays up has no control over the code or inner working of the application. They're limited to configuring and changing supporting servers (database, lb, web server), and not the application itself, and the application state is treated as a binary "is it up or down", with "turn it off and back on again" being a common "fix". Looking at the product, it does look quite nice, but collectd, icinga, nagios, zabbix (and now bosun which I'll likely be switching to) is free and open source server monitoring, and newrelic with all its in depth monitoring has a free tier. Assuming that virtual servers (xen) are considered a separate server, I definitely can't see paying $15/mo per server/instance. I'd be paying an order of magnitude more than the colo for my servers costs me. However with 5 physical servers, $75/mo is a lot more reasonable than (at minimum) $600 I'd be paying per instance. At work, our 4000+ servers would cost $60000 a month, more than enough that we could hire developers to write a custom system. With so many free and/or open options, it'd really have to blow me away to be worth it. Additionally a free trial for something like monitoring is a hard sell. The time and effort invested into the setup of a new monitoring system is definitely not free. All that being said, I do like it, and it seems like a nice product. From what you say I feel like you just haven't found the right target market for it.
couchand 11y ago
At Stack Exchange we use Bosun to monitor both system and application metrics. As an application developer I get pretty much everything I need on the system side out of the box with scollector. We spend a fair amount of time on projects now developing application-level metrics, which we use BosunReporter [0] to send to the same instance. It's quite useful to have application and system metrics on the same tool. [0]: github.com/bretcope/BosunReporter.NET
lmm 11y ago
It really needs to be minimal-effort to get started. I use newrelic and takipi where I can, and the most crucial thing is that they don't need any ahead-of-time configuration - I can slap them on in a generic configuration and be confident that they'll alert appropriately (newrelic) or collect the right information about failures (takipi).

cbaleanu 11y ago

Just curious, how is this related to the article on which you're commenting?

spo81rty 11y ago
Most developers in most IT departments don't even have access to monitoring tools and very little of developer/application importance is monitored beyond server up/down, cpu, and memory usage. A lot of the most important monitoring I do for my own application is looking at page load times, slow DB queries, custom app metrics, error rates, and looking for specific log statements. Many of these things can't even be done in basic monitoring systems. Bosun's alerting rules look awesome. But most people don't even know what to monitor, let alone figure out how to write javascript expressions to do so.
- KyleBrandt 11y ago
  Bosun uses a custom DSL, not javascript. What you are saying is fair - bosun is currently targeted at an advanced audience currently. There is active discussion about making alerts GUI creatable to make it more accessible. Can hopefully be less vague about that in a few weeks.

Tiksi 11y ago

I don't wanna derail the comments here, since as cbaleanu mentioned it's pretty off topic, so I'll try to stay brief here. If you would like some more input, my email is in my profile. > But it doesn't seem like developers really wanted it. I don't see why (most) developers would want a monitoring system. Why not target sysadmins / devops? In my experience developers really just want a trace of their app when it breaks, or maybe some performance profiling. > The shift to cloud based services also makes a lot of basic monitoring tools unnecessary. Even though on HN it might seem like everyone is using "the cloud" for everything, the reality is quite different. There's a pretty sizable market for server monitoring, even in the case of cloud services, someone is managing the metal. > code profiling, custom metrics, and analyzing errors and log statements. newrelic provides a lot of these, although I'm personally not a fan (it seems like their daemon is the main thing causing resource alerts), and has a free tier. >So many IT teams ... aren't very proactive when it comes to monitoring application health and behavior. Well if you're talking to IT teams, they may not be able to do anything proactive regarding health / behavior of applications. In many cases the team making sure the service stays up has no control over the code or inner working of the application. They're limited to configuring and changing supporting servers (database, lb, web server), and not the application itself, and the application state is treated as a binary "is it up or down", with "turn it off and back on again" being a common "fix". Looking at the product, it does look quite nice, but collectd, icinga, nagios, zabbix (and now bosun which I'll likely be switching to) is free and open source server monitoring, and newrelic with all its in depth monitoring has a free tier. Assuming that virtual servers (xen) are considered a separate server, I definitely can't see paying $15/mo per server/instance. I'd be paying an order of magnitude more than the colo for my servers costs me. However with 5 physical servers, $75/mo is a lot more reasonable than (at minimum) $600 I'd be paying per instance. At work, our 4000+ servers would cost $60000 a month, more than enough that we could hire developers to write a custom system. With so many free and/or open options, it'd really have to blow me away to be worth it. Additionally a free trial for something like monitoring is a hard sell. The time and effort invested into the setup of a new monitoring system is definitely not free. All that being said, I do like it, and it seems like a nice product. From what you say I feel like you just haven't found the right target market for it.

couchand 11y ago

At Stack Exchange we use Bosun to monitor both system and application metrics. As an application developer I get pretty much everything I need on the system side out of the box with scollector. We spend a fair amount of time on projects now developing application-level metrics, which we use BosunReporter [0] to send to the same instance. It's quite useful to have application and system metrics on the same tool. [0]: github.com/bretcope/BosunReporter.NET

lmm 11y ago

It really needs to be minimal-effort to get started. I use newrelic and takipi where I can, and the most crucial thing is that they don't need any ahead-of-time configuration - I can slap them on in a generic configuration and be confident that they'll alert appropriately (newrelic) or collect the right information about failures (takipi).