SlideShare utilise les cookies pour améliorer les fonctionnalités et les performances, et également pour vous montrer des publicités pertinentes. Si vous continuez à naviguer sur ce site, vous acceptez l’utilisation de cookies. Consultez nos Conditions d’utilisation et notre Politique de confidentialité.
SlideShare utilise les cookies pour améliorer les fonctionnalités et les performances, et également pour vous montrer des publicités pertinentes. Si vous continuez à naviguer sur ce site, vous acceptez l’utilisation de cookies. Consultez notre Politique de confidentialité et nos Conditions d’utilisation pour en savoir plus.
A little bit about me, I’m an engineer at Circonus.com
I’ve been an open source developer for almost twenty years.
You can find me on twitter as phredmoyer with a p, and also follow us at irondb
So what is IRONdb?
We designed it to be a direct replacement for the time series database that you use today.
No changes to the way you ingest data.
No changes to the way you want to read or visualize your data.
With the design goal of taking care of all the stuff that you don’t want to deal with, Scalability, Reliability, Operational headaches.
You just want your time series database to work. You don’t want missing data, empty graphs, cluster downtime.
A customer of ours has over 300 million metrics, data is replicated 3 times. They have a cluster of about 30 machines, dozens of users pulling graphs, and some very complicated queries on those graphs
They KEY for them is they did not have to change their ingestion pipeline, OR re-write any of their dashboards.
It was designed for low operational overhead. There are some great presentations here by smart people about scaling other TSDBs to huge levels. We designed IRONdb so that you can do the same thing without specialized operational expertise.
IRONdb is distributed.
IRONdb can scale across dozens of nodes. It doesn’t use consensus protocols, which has allowed us to focus on operational efficiency and performance.
IRONdb is replicated.
It allows you to keep as many copies of the data as you need. We typically recommend three copies.
IRONdb is reliable.
If a node dies, you just replace the hardware and IRONdb does the rest. You don’t need to bring the cluster down. Oh by the way, if you want to increase your cluster size, just add another node and IRONdb will take care of rebalancing.
IRONdb is multi datacenter
It scales across data centers without needing specialized operator knowledge - just configure a node and it takes care of everything.
You don’t need expensive load balancers or complicated HAProxy setups. If you use graphite, you don’t need a complicated carbon relay setup.
Today we are pleased to announce the beta release of our IRONdb Grafana Data Source.
Our data source unlocks the cool new features of Grafana’s heatmaps and histograms.
We store histogram data natively in IRONdb, and you can use the Grafana heatmap to display that directly.
In IRONdb, along with the average we store the derivative, standard deviation of the derivative, the count, the counter (positive derivative), the standard deviation of that counter, as well as the standard deviation of the average.
That’s a ton of data; the reason we do that is so that you don’t have to calculate that in your dashboard.
Lastly we have integrated the Circonus Analytics Query Language, CAQL, into Grafana. Everybody tracks the 95th percentile, but nobody can tell you how many users got screwed over in that 5 percent beyond it. We can. You can also do day over day, week over week, comparison and forecasting of your traffic.
We are also pleased to announce that we will be open sourcing our RED dashboard. RED stands for rate, errors, and duration, an emerging paradigm for visualizing service health.
There’s a great talk here by Tom Wilkie about RED dashboards that you should go see.
Rate - how many requests per second is your service doing
Errors - how many errors per second is your service experiencing.
This graph shows zero - that’s a good service.
Duration - what is the latency of your service requests?
This histogram view in Grafana shows the request latency over a time period as a histogram.
This view of the duration shows a heatmap in Grafana, which is basically a histogram over time.
We love Grafana, and this new visualization is one of our favorites.
We will also be open sourcing our USE dashboard for the IRONdb data source.
USE is a paradigm for visualizing host health metrics. USE stands for Utilization, Saturation, and Errors.
Utilization - what is the current utilization of CPU, memory, network, and disk on your system.
Saturation - how saturated are those resources?
This network saturation graph shows packets dropped and tcp retransmits, indicators of network resource saturation.
Errors - this graph shows network errors
A quick sneak peek at IRONdb features dropping soon.
You’ll be able to drop IRONdb in as a Prometheus storage backend
And we’ll be releasing metrics stream tags
You can sign up for early access to our grafana data source at our booth downstairs.
And we’ll have preview accounts for free metrics for folks here.
Our VP of Engineering Riley is here, as is our Data Scientist Heinrich.
Thanks, and have a great conference.
GrafanaCon EU 2018
IRONdb + Grafana
Fred Moyer - Engineer @Circonus.com
Open source developer since 2000
Twitter => @phredmoyer, @irondb
Replacement for you existing TSDB
- No change to your ingestion pipeline
- No change to your visualizations
Takes care of Scale, Reliability, ease of
Customers like AppNexus 300M+ metrics
Data replicated X times (recommended 3)
Clusters Two-sided (multi-datacenter)