Internally we have are having a discussion around what actually is an environment? What are the classifications of an environment? Should all environments be monitored? Is there really a difference between a dev, ref, qa, prod environment from an operations perspective.<p>It seems that the operational people care about all environments and want to make sure they are up. This is because if one of them goes down, then most likely they are responsible for getting it back up.<p>The developers only care about prod. They do not want to notified if their development environment is having issues.<p>I was wondering how others handle these problems internally or if we are the only ones who are having this discussion?
> Should all environments be monitored?<p>Yes. If you don't collect data about the environment, you can't tell whether
the current behaviour is normal or abnormal. Though not every environment
should send all alerts possible.<p>> I was wondering how others handle these problems internally or if we are the only ones who are having this discussion?<p>Monitoring is a tough topic -- still, after more than twenty years of
development in this field. The problem is that we <i>still</i> treat monitoring
systems as monolithic applications with hardcoded data collection and alerting
logic, instead of making them what they are: event stream processing engines,
with some publish-subscribe capabilities to allow attaching some external
logic.<p>I'm working on a toolbox that helps in building such a system
(<a href="http://seismometer.net/" rel="nofollow">http://seismometer.net/</a>), though it's still lacks tools and its website is
more of a sketch than a project homepage.<p>In the meantime, you should think about how to allow different people to
<i>select</i> or <i>filter out</i> different notifications, possibly in such a manner
that they can process those notifications programmatically.