Commit graph

15 commits

Author SHA1 Message Date
Matt T. Proud 5a9417f80a Include humanized target state strings.
In the current /status implementation, we cannot divine what the
target's state is but rather get an integer constant for it.  This
commit, stringifies the constants.
2013-03-21 11:52:42 +01:00
Julius Volz f1fc7d717a Allow replacing job targets via HTTP API.
This roughly comprises the following changes:

- index target pools by job instead of scrape interval
- make targets within a pool exchangable while preserving existing
  health state for targets
- allow exchanging targets via HTTP API (PUT)
- show target lists in /status (experimental, for own debug use)
2013-02-28 21:33:29 +01:00
Julius Volz 047eb219e4 Fix target health state update.
Right now, futureState is only used to give hints to the health scheduler, but
nowhere is this future state persisted into the target's state field, so we
don't actually track a target's state over time.
2013-02-25 02:52:52 +01:00
Julius Volz 5d55785936 Fix broken target scrape error propagation. 2013-02-21 19:48:54 +01:00
Matt T. Proud ea54751431 Update import paths to new location.
This repository moved from matttproud/prometheus to
prometheus/prometheus, and all import paths need to be updated.
2013-01-27 18:49:45 +01:00
Matt T. Proud f2ded515b7 Support versioned telemetry providers.
client_golang was updated to support full label-oriented telemetry,
which introduced interface incompatibilities with the previous
version of Prometheus.  To alleviate this, a general fetching and
processing dispatching system has been created, which discriminates
and processes according to the version of input.
2013-01-27 17:45:50 +01:00
Matt T. Proud 88d15373c5 Upgrade Prometheus to new API. 2013-01-23 17:18:45 +01:00
Julius Volz 80cdb0121d Add support for configured job base labels. 2013-01-18 01:10:09 +01:00
Matt T. Proud 9752f1e61d Refactor Target as interface for testability.
Future tests around the ``TargetPool`` and ``TargetManager`` and
friends will be a lot easier when the concrete behaviors of
``Target`` can be extracted out.  Plus, each ``Target``, I suspect,
will have its own resolution and query strategy.
2013-01-15 16:19:51 +01:00
Matt T. Proud efe61c18fa Refactor target scheduling to separate facility.
``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.
2013-01-13 10:43:37 +01:00
Julius Volz 56384bf42a Add initial config and rule language implementation. 2013-01-07 23:43:36 +01:00
Matt T. Proud 52f52a7ee2 Include nascent instrumentation of stack. 2013-01-04 23:32:46 +01:00
Matt T. Proud 2922def8d0 Use the `TargetManager` for targets. 2013-01-04 17:17:23 +01:00
Julius Volz 45a3e0a182 Rename Target Frequency -> Interval. 2013-01-04 13:03:32 +01:00
Matt T. Proud 7a9777b4b5 Create `TargetPool` priority queue.
``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.
2013-01-04 12:17:31 +01:00
Renamed from retrieval/type.go (Browse further)