This repository has been archived by the owner. It is now read-only.
Vulcan extends Prometheus adding horizontal scalability and long-term storage
Clone or download
Permalink
Type Name Latest commit message Commit time
Failed to load latest commit information.
.monodraw removes scraper (#50) Sep 8, 2016
bus refactor: removes deprecated bus models (#73) Oct 10, 2016
cacher cacher: use grpc for internal api (#81) Nov 21, 2016
cassandra cassandra: added retry logic for gocql (#85) Dec 5, 2016
cmd removes deprecated ingester component (#88) Dec 5, 2016
convert indexer: in-memory instead of elasticsearch (#83) Nov 21, 2016
downsampler downsampler: switched to RLock in a couple places where Lock was acci… Mar 9, 2017
forwarder Feature/downsampler (#78) Nov 14, 2016
indexer indexer: in-memory instead of elasticsearch (#83) Nov 21, 2016
kafka cacher: in-memory metrics (#79) Nov 15, 2016
model cacher: in-memory metrics (#79) Nov 15, 2016
querier indexer: in-memory instead of elasticsearch (#83) Nov 21, 2016
scripts cacher: use grpc for internal api (#81) Nov 21, 2016
.dockerignore dev: adds docker-compose Aug 2, 2016
.gitignore makefile: simpler; faster; fixes for lint and licensecheck (#71) Oct 6, 2016
.travis.yml set travis glide=v0.12.3; use install -v (#84) Nov 22, 2016
AUTHORS tools: makefile targets instead of scripts Aug 11, 2016
CONTRIBUTING.md tools: makefile targets instead of scripts Aug 11, 2016
Dockerfile makefile: simpler; faster; fixes for lint and licensecheck (#71) Oct 6, 2016
LICENSE init Aug 2, 2016
Makefile set travis glide=v0.12.3; use install -v (#84) Nov 22, 2016
README.md README.md update regarding project maintenance (#96) Jul 10, 2017
architecture.md readme: adds why, updates architecture (#89) Jan 4, 2017
glide.lock indexer: in-memory instead of elasticsearch (#83) Nov 21, 2016
glide.yaml indexer: in-memory instead of elasticsearch (#83) Nov 21, 2016
main.go removes deprecated ingester component (#88) Dec 5, 2016

README.md

Warning: This project is currently not maintained, and there is no plan to do so ATM.

Vulcan Build Status Report Card

Vulcan extends Prometheus adding horizontal scalability and long-term storage.

Vulcan is highly experimental.

Why

Prometheus has an upper-limit on the number of samples it can handle and manually sharding Prometheus is difficult. Prometheus provides no built-in way to rebalance data between nodes once sharded, which makes accommodating additional load via adding nodes a difficult, manual process. Queries against manually-sharded Prometheus servers must be rethought since each Prometheus instance only has a subset of the total metrics.

It is difficult to retain data in Prometheus for long-term storage as there is no built-in way to backup and restore Prometheus data. Mirroring Prometheus (running multiple identically-configured Prometheus servers) is an option for high availability (and good for the role of monitoring), but newly created mirrors lack historical data and therefore don't provide historical data or any additional replication factor.

Vulcan is horizontally scalable and built for long-term storage. In order to accommodate growing load, add more resources to Vulcan. There is no need to think about how to shard data and how sharding will affect queries.

Prometheus (as of v1.2.1) is able to forward metrics to Vulcan. Existing Prometheus deployments can easily reconfigure their Prometheus servers to forward all (or just some) metrics to Vulcan. Prometheus can continue operating as a simple and reliable monitoring system while utilizing Vulcan for long-term storage.

Why the name Vulcan?

Vulcan is the roman god of fire, metalworking and of the forge. Raised in the [digital] ocean, Vulcan was charged with crafting the tools and weaponry.

Vulcan aims to enhance the Prometheus ecosystem. Thank you Prometheus for stealing us fire in the first place.

Architecture

Refer to architecture.md

Contributing

Refer to CONTRIBUTING.md

Contact

The core developers are accessible via the Vulcan Developers Mailinglist

Ethos

Vulcan components should be stateless; state should be handled by open-source databases (e.g. Cassandra, Kafka).

Vulcan should be API-compatible with Prometheus. e.g. PromQL discussions and improvements should happen in the Prometheus community, committed to Prometheus, and then utilized in Vulcan.

License

Apache License 2.0, see LICENSE.