Files changed (8)
-* ./reset.bash && python util/simplepoller.py # *resets database to latest scheme, loads data, and runs poller*
+ ./reset.bash && python util/simplepoller.py # *resets database to latest scheme, loads data, and runs poller*
-** does a local ping (initial data model loaded from modeltestdata.json) and stores the results into RRD files
+ does a local ping (initial data model loaded from modeltestdata.json) and stores the results into RRD files
while a project is under active development. South will only track applications for schema migration
* * if you've made a model change that can lead to inconsistencies, the result might be an error that will request that you make some decisions about the model and try again.
Before you can use Eyes, you'll need to get it installed. This guide will guide you to a simple, minimal installation that'll work while you walk through the introduction.
-* Go to http://192.168.239.130/admin/sites/site/1/ and update the site name to your local site name
Eyes is a project to enable quick, simple, and API enabled monitoring and data collection. Eyes (in it's current form) takes advantage of nagios plugins and wraps them with a Django web framework instead of the Nagios framework - intended to make dynamically creating, updating, and processing of monitor points far easier than it exists today.
+First and foremost, Eyes has been created to enable systems and infrastructure with a very high rate of change. Fundamentally, this means being API driven from the base and going up - enabling the creation, destruction, and update of monitors and data sources at an API level so they can be programmatically manipulated.
+Eyes is also built to be a component in a larger system, processing information and doing its work asynchronously from other components in the system.
The core of eyes is a poll-based system, but the REST API design allows for passive consumption of monitoring data as well (i.e. agent based mechanisms).
+ * attributes (such as associated CI, priority/impact if monitor is triggered, thresholds if set centrally)
+ * api to deploy a given monitor across 1..N additional servers/CI’s (maybe services in some cases)
+ * api to create all elements of a monitor from scratch programmatically so that we can generate monitors when we deploy applications
+ * be able to associate, list, and report on what monitors exist against which servers & services (by CI in a CMDB)
+ * Given a monitor template or collection of monitors, I want to know all the nodes it has been deployed to.
+ * * update that monitor with new critical attributes (links to wiki articles, priority and/or impact of incidents on a failure, associations for the monitor to other systems)
+ * In order to do delegated access properly we need to provide a feedback loop to whomever will be using/creating/editing monitors. The users need to be able to see their alert, see that it is correct or incorrect, and be able to get feedback without intervention. ie. They need to be able to debug and fix their own problems.
+ * integration flow verification from multiple remote data centers to any central consoles/servicedesk
+ * monitor, but not generate events during operator or engineering invoked "shut up, I'm doing maintenance" time
+ * engineering (non core monitoring administrators) create templates for groups of monitors that can be applied to servers or services
+ * For instance I would want to create a standard set of “DB SAN Server monitors” that would monitor HBAs, SQL queues, etc that would be added in addition to standard server monitors.