Timeline for Monitoring checklist - What things should I be monitoring?
Current License: CC BY-SA 3.0
5 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 12, 2017 at 6:10 | comment | added | krisy | Thank you; yes, this data if vital - but I do not feel it is enough/complete (it covers the hardware data layer I mentioned in the question) | |
| Jul 11, 2017 at 19:52 | comment | added | Adrian | If a single node is acting up, it should be automatically terminated and replaced, so I don't need to know about it. Monitoring instance-level metrics for auto-scaling is done by the scaling controller, not by the IT monitoring system. | |
| Jul 11, 2017 at 19:44 | comment | added | James Shewey | You should care - it makes a better product and customer experience. If you don't monitor each specific instance in the cluster, how do you know if a single node is unhealthy? How you prevent a partial outage and customer impact if a single node is acting up, but the average between two nodes hides the issue? How can you even decide what your average is in order to enlarge or shrink the cluster without monitoring each instance? | |
| Jul 11, 2017 at 19:31 | comment | added | Adrian | If you're using auto-scaling, all of the listed metrics are useless for monitoring in the majority of cases on a per-instance basis. I don't care what the CPU usage of any one instance is, because if load is high enough, instances will be added, and if it's low enough, instances will be terminated. Monitoring is very situational. | |
| Jul 11, 2017 at 19:23 | history | answered | James Shewey | CC BY-SA 3.0 |