``Target`` will be refactored down the road to support various
nuanced endpoint types. Thusly incorporating the scheduling
behavior within it will be problematic. To that end, the scheduling
behavior has been moved into a separate assistance type to improve
conciseness and testability.
``make format`` was also run.
This implementation needs to be cleaned up considerably, but it
should hopefully provide some breathing room. Ultimately this will
be extracted out of the storage layer---specifically the LevelDB
hierarchy---to interface with a generic set of abstractions for a
storage system, but this will be where it remains for now.
``Target`` will be refactored down the road to support various
nuanced endpoint types. Thusly incorporating the scheduling
behavior within it will be problematic. To that end, the scheduling
behavior has been moved into a separate assistance type to improve
conciseness and testability.
``make format`` was also run.
This fixes a bug that has been annoying me minorly for some time now:
sometimes, after parse errors, a subsequent parser run would fail. The reason
is that yylex() modifies some global variables (yytext, yydata) during its run
to keep state. To make subsequent parser runs correct, these have to be reset
before each run.
Also, close files after reading them.
The LevelDB stochastic tests could take a long time.
Original:
```
Matt:prometheus mtp$ make test
make -C model
protoc --go_out=generated/ data.proto
go build ./...
go test ./...
warning: building out-of-date packages:
github.com/matttproud/golang_instrumentation/maths
github.com/matttproud/golang_instrumentation/utility
github.com/matttproud/golang_instrumentation/metrics
github.com/matttproud/golang_instrumentation
installing these packages with 'go test -i ./...' will speed future tests.
? github.com/matttproud/prometheus [no test files]
? github.com/matttproud/prometheus/coding [no test files]
ok github.com/matttproud/prometheus/coding/indexable 0.012s
? github.com/matttproud/prometheus/model [no test files]
? github.com/matttproud/prometheus/model/generated [no test files]
? github.com/matttproud/prometheus/retrieval [no test files]
? github.com/matttproud/prometheus/storage/metric [no test files]
ok github.com/matttproud/prometheus/storage/metric/leveldb 70.800s
? github.com/matttproud/prometheus/storage/raw [no test files]
? github.com/matttproud/prometheus/storage/raw/index [no test files]
ok github.com/matttproud/prometheus/storage/raw/index/leveldb 0.012s
ok github.com/matttproud/prometheus/storage/raw/leveldb 0.016s
ok github.com/matttproud/prometheus/utility 0.012s
? github.com/matttproud/prometheus/utility/test [no test files]
```
to
```
Matt:prometheus mtp$ make test
make -C model
protoc --go_out=generated/ data.proto
go build ./...
go test ./...
warning: building out-of-date packages:
github.com/matttproud/golang_instrumentation/maths
github.com/matttproud/golang_instrumentation/utility
github.com/matttproud/golang_instrumentation/metrics
github.com/matttproud/golang_instrumentation
installing these packages with 'go test -i ./...' will speed future tests.
? github.com/matttproud/prometheus [no test files]
? github.com/matttproud/prometheus/coding [no test files]
ok github.com/matttproud/prometheus/coding/indexable 0.011s
? github.com/matttproud/prometheus/model [no test files]
? github.com/matttproud/prometheus/model/generated [no test files]
? github.com/matttproud/prometheus/retrieval [no test files]
? github.com/matttproud/prometheus/storage/metric [no test files]
ok github.com/matttproud/prometheus/storage/metric/leveldb 2.158s
? github.com/matttproud/prometheus/storage/raw [no test files]
? github.com/matttproud/prometheus/storage/raw/index [no test files]
ok github.com/matttproud/prometheus/storage/raw/index/leveldb 0.013s
ok github.com/matttproud/prometheus/storage/raw/leveldb 0.013s
ok github.com/matttproud/prometheus/utility 0.013s
? github.com/matttproud/prometheus/utility/test [no test files]
```
``TargetPool`` is a pool of targets pending scraping. For now, it
uses the ``heap.Interface`` from ``container/heap`` to provide a
priority queue for the system to scrape from the next target.
It is my supposition that we'll use a model whereby we create a
``TargetPool`` for each scrape interval, into which ``Target``
instances are registered.
Kill LevelDB watermarks due to redundancy.
General interface documentation has begun.
Creating custom types for the model to prevent errors down the
road.
Renaming of components for easier comprehension.
Exposition of interface in LevelDB.
Slew of simple refactorings.
