prometheus

Commit Graph

Author	SHA1	Message	Date
Brian Brazil	89c43dd0d7	Sort targets on the status page. Change-Id: I6b59c97ab50093c50b608e29be2304475bc5d9f6	10 years ago
Johannes 'fish' Ziemke	ff95a52b0f	Rename Address to URL The "Address" is actually a URL which may contain username and password. Calling this Address is misleading so we rename it. Change-Id: I441c7ab9dfa2ceedc67cde7a47e6843a65f60511	10 years ago
Bjoern Rabenstein	b1e4956142	Apply a giant code cleanup. Essentially: - Remove unused code. - Make it 'go vet' clean. The only remaining warnings are in generated code. - Make it 'golint' clean. The only remaining warnings are in gerenated code. - Smoothed out same minor things. Change-Id: I3fe5c1fbead27b0e7a9c247fee2f5a45bc2d42c6	10 years ago
Bjoern Rabenstein	fee88a7a77	Remove the remaining races, new and old. Also, resolve a few other TODOs. Change-Id: Icb39b5a5e8ca22ebcb48771cd8951c5d9e112691	10 years ago
Bjoern Rabenstein	74c143c4c9	Improve scraper shutdown time. - Stop target pools in parallel. - Stop individual scrapers in goroutines, too. - Timing tweaks. Change-Id: I9dff1ee18616694f14b04408eaf1625d0f989696	10 years ago
Bjoern Rabenstein	b3ed9aa7a2	Clean up start-up and shut-down. Change-Id: Idff4bbb0a15a9f879bfbb3da5b1025179cab5e2c	10 years ago
Bjoern Rabenstein	4447708c9f	Fix a race in target.go. Also, fix problems in shutdown. Starting serving and shutdown still has to be cleaned up properly. It's a mess. Change-Id: I51061db12064e434066446e6fceac32741c4f84c	10 years ago
Julius Volz	7f5d3c2c29	Fix and improve the fp locker. Benchmark: $ go test -bench 'Fingerprint' -test.run 'Fingerprint' -test.cpu=1,2,4 OLD BenchmarkFingerprintLockerParallel 500000 3618 ns/op BenchmarkFingerprintLockerParallel-2 100000 12257 ns/op BenchmarkFingerprintLockerParallel-4 500000 10164 ns/op BenchmarkFingerprintLockerSerial 10000000 283 ns/op BenchmarkFingerprintLockerSerial-2 10000000 284 ns/op BenchmarkFingerprintLockerSerial-4 10000000 288 ns/op NEW BenchmarkFingerprintLockerParallel 1000000 1018 ns/op BenchmarkFingerprintLockerParallel-2 1000000 1164 ns/op BenchmarkFingerprintLockerParallel-4 2000000 910 ns/op BenchmarkFingerprintLockerSerial 50000000 56.0 ns/op BenchmarkFingerprintLockerSerial-2 50000000 47.9 ns/op BenchmarkFingerprintLockerSerial-4 50000000 54.5 ns/op Change-Id: I3c65a43822840e7e64c3c3cfe759e1de51272581	10 years ago
Brian Brazil	5edf689133	Stagger scrapes to spread out load. Change-Id: Ib141b271e4adfb817886871f86051c207b05cf35	10 years ago
Bjoern Rabenstein	1909686789	Make metrics exported by the Prometheus server itself more consistent. - Always spell out the time unit (e.g. milliseconds instead of ms). - Remove "_total" from the names of metrics that are not counters. - Make use of the "Namespace" and "Subsystem" fields in the options. - Removed the "capacity" facet from all metrics about channels/queues. These are all fixed via command line flags and will never change during the runtime of a process. Also, they should not be part of the same metric family. I have added separate metrics for the capacity of queues as convenience. (They will never change and are only set once.) - I left "metric_disk_latency_microseconds" unchanged, although that metric measures the latency of the storage device, even if it is not a spinning disk. "SSD" is read by many as "solid state disk", so it's not too far off. (It should be "solid state drive", of course, but "metric_drive_latency_microseconds" is probably confusing.) - Brian suggested to not mix "failure" and "success" outcome in the same metric family (distinguished by labels). For now, I left it as it is. We are touching some bigger issue here, especially as other parts in the Prometheus ecosystem are following the same principle. We still need to come to terms here and then change things consistently everywhere. Change-Id: If799458b450d18f78500f05990301c12525197d3	10 years ago
Brian Brazil	4a2b96f848	Remove backoff on scrape failure. Having metrics with variable timestamps inconsistently spaced when things fail will make it harder to write correct rules. Update status page, requires some refactoring to insert a function. Change-Id: Ie1c586cca53b8f3b318af8c21c418873063738a8	10 years ago
Bjoern Rabenstein	8956faeccb	Migrate to new client_golang. This change will only be submitted when the new client_golang has been moved to the new version. Change-Id: Ifceb59333072a08286a8ac910709a8ba2e3a1581	10 years ago
Julius Volz	fb44580110	Cleanup/fix program termination sequence. Change-Id: I2bc58a2583fb079c9ef383cfc7a5e0fbe613f1cd	11 years ago
Julius Volz	d69b85e6c9	Add global label support via Ingesters.	11 years ago
Julius Volz	0003027dce	Add needed trailing spaces in logs.	11 years ago
Julius Volz	aa5d251f8d	Use github.com/golang/glog for all logging.	11 years ago
Matt T. Proud	06b4a40661	Represent targets in a tabular interface. This commit represents a target group's endpoints in a tabular fashion for better differentiation of their state in a concise manner.	12 years ago
Julius Volz	9a48f57b66	Continue scraping old targets on SD fail. When we have trouble resolving the targets for a job via service discovery, we shouldn't just stop scraping the targets we currently have.	12 years ago
Matt T. Proud	30b1cf80b5	WIP - Snapshot of Moving to Client Model.	12 years ago
Julius Volz	d9b4f98b44	Integrate DNS-SD support for discovering job targets.	12 years ago
Matt T. Proud	d4db3cf00b	Code Review: Last replacement wins.	12 years ago
Matt T. Proud	9cde48754b	Fix race conditions in TargetPool. The race condition detector found a few anomalies whereby a TargetPool could be read during a mutation. This has been fixed.	12 years ago
Matt T. Proud	8f4c7ece92	Destroy naked returns in half of corpus. The use of naked return values is frowned upon. This is the first of two bulk updates to remove them.	12 years ago
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)	12 years ago
Julius Volz	3537edee9f	Fix targetpool iteration deadlock.	12 years ago
Matt T. Proud	e01b6cdb44	Duration statistics for each target pool. We have an open question of how long does it take for each target pool to have the state retrieved from all participating elements. This commit starts by providing insight into this.	12 years ago
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.	12 years ago
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.	12 years ago
Matt T. Proud	190e4e3fa3	``TargetManager`` and ``TargetPool`` ass pointers.	12 years ago
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.	12 years ago
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.	12 years ago
Matt T. Proud	2922def8d0	Use the ``TargetManager`` for targets.	12 years ago
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.	12 years ago

33 Commits (39d20140c88de16570c7c8f26b3be6ca30860a43)