-
Notifications
You must be signed in to change notification settings - Fork 4
Database Structure
Healthcheck stores its data in a CouchDB instance. To do this, it creates and uses several databases within that instance. All of them have names beginning with the string "zonestat", to reduce the risk of name collision.
This is the main database, that holds all the data that has been gathered. The documents in it have id:s on the form "(testrun id)-(domain name)". The content of a document will vary depending on which gathering options were active at the time, and which succeeded. The general structure is documented in Zonestat::Collect.
This database holds the information on domain sets. The document id:s are on the form "(set name)-(domain name)" (so it's impossible for domain names to be duplicated in a set). The content of the documents are simple the set and domain names.
This database exists to work around one of the things a key-value database is not good at, which is answering questions on the form "SELECT COUNT(DISTINCT(whatever)) FROM some_table". The database holds the IP addresses for all nameservers seen during a particular gathering run, so we can easily count them and extract information like how many domains share a particular server. The documents id:s are on the form "(testrun id)-(ip address)". The document data is just the testrun id, the IP address and the IP version number (that is, one of the constants 4 or 6).
Normally contains a single document called "testruncounter". It keeps track of what the next testrun ID should be.
This database holds the queue of domain names to be gathered. The document id:s are auto-generated by CouchdDB (so a domain can be queued multiply). The document contents are things the dispatcher needs, like the domain name, testrun id, priority level and re-queueing count. In practice, these documents should be considered opaque and not messed around with.
This database holds information needed to translate from AS numbers to AS names. The document id:s are AS numbers, and the documents predictably contain the corresponding names. The database is most easily populated using the update_asn_table_from_ripe() method in Zonestat::Prepare, which will download the most recent AS list from RIPE, parse it and rewrite the database accordingly.
This database does not necessarily exist. It will be created if you use the db_import_zone() method in Zonestat::Prepare, and will then have one document for every domain name found in the zone file. The documents themselves will be empty (except if one of them is named exactly 'se', in which case it will have a key "time_t" which is the Unix time when the .SE zone file loaded was created, taken from the zone's relevant TXT record).