bbrazil

17 ms·

31.
by bbrazil 9y ago
There's no hard timeline as we're an open source project, but hopefully in the next 6-12 months. If this is holding you back from seriously Prometheus, then Prometheus is possibly not the right tool for you. Prometheus is about th
32.
by bbrazil 9y ago
Bulk imports are planned: https://github.com/prometheus/prometheus/issues/535 Note that bulk really means bulk. This is for one-off loads, not doing push.
33.
by bbrazil 9y ago
If you just want to compare the database aspects that works. Once you get into other features that gets messier as functionality is split across components in different ways. For example Prometheus vs InfluxDB is not a great comparison, whe
34.
by bbrazil 9y ago
You can use comm from coreutils for that too: `comm -1 file1 file2`
35.
by bbrazil 9y ago
> I don't believe this will work out well because it will introduce read amplification during query time (compared to file per series approach that they're using now). It'll end up about the same in practice, only the time
36.
by bbrazil 9y ago
Prometheus is fundamentally a TSDB, see https://fabxc.org/blog/2017-04-10-writing-a-tsdb/ for the design of the next version.
37.
by bbrazil 9y ago
Rhubarb crumble is what I had growing up. I just baked one today in fact.
38.
by bbrazil 9y ago
Durability is not a requirement in that sense. Consider that a regular scrape has happened and that data has been accepted by the DB but not yet flushed to disk. Whether the database dies just before or just after the scrape produces the sa
39.
by bbrazil 9y ago
> Suddenly instead of loading a billion rows and averaging the value in one column, you're just accesing the column itself to answer the question. From an IO perspective that's a huge savings. The other side of this is that wri
40.
by bbrazil 9y ago
That was the 1st InfluxDB storage engine, things have evolved in the intervening years. The latest InfluxDB design is actually quite similar to the latest Prometheus design, what's different is our approaches to reliability and cluster
41.
Writing a Time Series Database from Scratch(fabxc.org)
3 points by bbrazil 9y ago|0 comments
42.
by bbrazil 10y ago
That sounds like how Ireland used to work, before 2000 when things were deregulated. We've gone from a shortage of taxis, to an overabundance. When Uber launched, it wasn't interesting as our taxi system (which Uber appears to com
43.
by bbrazil 10y ago
> I personally found that runbooks were even worse for small size teams (like our four person reddit team) because they would get out of data even quicker than at the bigger places due to the rapidly changing environment. My experience i
44.
by bbrazil 10y ago
That's already (roughly) the law in the EU.
45.
by bbrazil 10y ago
I've had new several hard drives turn out to be in fact refurbished (and in one case quickly failed). I got refunds but nothing beyond that, even with in one case offering evidence that this looked like deliberate fraud due to half-cle
46.
Translating between monitoring languages(robustperception.io)
2 points by bbrazil 10y ago|0 comments
47.
by bbrazil 10y ago
Any AP knows your MAC, as that's the basis of how Ethernet works.
48.
by bbrazil 10y ago
If you look at your latency histogram and are seeing a bump at around 200ms above normal (which was the default minimum wait time a few years back anyway), it's probably retransmits.
49.
by bbrazil 10y ago
> Combining them into one graph will likely conceal the difference in the two cases, as you describe Indeed. The first order issue is locating the problem though. If you don't spot which of your microservices is the culprit due to o
50.
by bbrazil 10y ago
By default you can only get that per-kernel from /proc/net/netsnmp. BPF may allow something more granular. The other way of approaching it is to look for the additional latency it causes, which you can spot on a per-service b
51.
by bbrazil 10y ago
The duration metric as recommended by the article, but not broken out by success/failure.
52.
by bbrazil 10y ago
> A histogram of the duration it took to serve a response to a request, also labelled by successes or errors. I recommend against this, rather have one overall duration metric and another metric tracking a count of failures. The reason f
53.
by bbrazil 10y ago
Does cut(1) work for you?
54.
by bbrazil 10y ago
> seems like you're trying to say that this situation requires 30K IOPS. That would be really naive :) If you want fast reads, it'd take at least that many IOPS for a naieve solution where each timeseries had its own block you
55.
by bbrazil 10y ago
While metrics are often evenly spaced, that's not always the case. Good resolution on the timestamps helps avoid graph artifacts and other weirdness, even if you're only collecting them once a minute. Millisecond accuracy seems to
56.
by bbrazil 10y ago
That's two separate dimensions. One is metrics vs. event logging. The other is consistency vs. availability. There's many types of logs, and you don't need the consistency that'd be required for billing-related logs as f
57.
by bbrazil 10y ago
There's several, depending on use case. Each make different tradeoffs, so you have to decide what's important for you. For example Prometheus (which I work on) is great at reliable monitoring and powerful processing of metrics at
58.
by bbrazil 10y ago
> If you're operating on FB-scale, then sure that's what you have to do, but in most cases your database (especially Postgres) is a far superior option. > Time series is "unusual" in the sense that most people don&
59.
by bbrazil 10y ago
I run a consulting/support business around Prometheus. I've found that giving talks and weekly writing blog posts ( https://www.robustperception.io/blog/ ) are great for acquiring customers. Beware though it&#x
60.
by bbrazil 10y ago
Bananas are the 2nd most radioactive food, due to their Potassium content. Brazil nuts are the most radioactive. https://en.wikipedia.org/wiki/Banana_equivalent_dose

More ›