bbrazil

31 ms·

271.
by bbrazil 12y ago
Both. When I switched our production Prometheis over, the consoles rendered more than twice as fast for a simple test case.
272.
by bbrazil 12y ago
> I'm hesitant to cram into a time series database data that I consider boolean. A boolean can be treated as a 1 or a 0. Sometimes you can even go richer than that, such as with a count of affected processes from your example - whic
273.
by bbrazil 12y ago
> However, the pull/scraping model for stats could be problematic for larger scale. From experience of similar systems at massive scale, I expect no scaling problems with pulling in and of itself. Indeed, there's some tactical
274.
by bbrazil 12y ago
> This isn't a time series check; it's just an alert condition. I think you're conflating instrumentation and alerting. Many systems only offer alert conditions on very low-level data that's tightly-bound to the instr
275.
by bbrazil 12y ago
Great! We're over in #prometheus on Freenode if there's anything we can help you with.
276.
by bbrazil 12y ago
The default instrumentation that comes with node_exporter covers far more than what systat provides. Retrieving data from /proc at every scrape also gives you a more accurate timestamp, which helps reduce graph artifacts. As an aside,
277.
by bbrazil 12y ago
> This results in other systems wanting to do alerting, making it tough to compare tools. I'd think you've hit the nail on the head, every monitoring system has to do a bit of everything such as alerting, machine monitoring, an
278.
by bbrazil 12y ago
We support that use case, here's a guide: http://www.boxever.com/monitoring-your-machines-with-prometh...
279.
by bbrazil 12y ago
What you want to do is separately scrape each instance. We're working on service discovery support[1] so that you can dynamically change what hosts/ports Prometheus scrapes. Currently you can use DNS for service discovery, or chan
280.
by bbrazil 12y ago
> Does it shard? Currently you can manually vertically shard, and in future we may have support for some horizontal sharding for when the targets of a given job are too many to be handled by a single server. You should only hit this when
281.
by bbrazil 12y ago
https://github.com/rcrowley/go-metrics is one I've came across while researching potential Prometheus integrations, it seems to support a number of backends including Graphite and InfluxDB. One challenge with that
282.
by bbrazil 12y ago
We favour pull, but we don't force it. The collectd exporter is an integration with a push-based system for example. My full thoughts are up at http://www.boxever.com/push-vs-pull-for-monitoring The short version is th
283.
by bbrazil 12y ago
That'd be a challenge alright. One thing to consider is having each owner run their own Prometheus so that they can take advantage of all it's features, though it's a harder sell than "just push over here". http:&#
284.
by bbrazil 12y ago
(One of the Prometheus authors here) My understanding is that InfluxDB will work for your use case, as it's all push. > I see the pushgateway, but it seems deliberately not a centralized storage. Yeah, the primary use case for the p
285.
by bbrazil 12y ago
Yes, I've got something working at the moment. It needs cleanup, docs, unittests etc. If you want to help out, it's up at https://github.com/brian-brazil/client_python
286.
by bbrazil 12y ago
From my look at Riemann, it seems more aimed as an event monitoring system than a time-series monitoring system. You can (and many do) use Riemann as time-series monitoring system, my understanding is that Prometheus is a bit better for mul
287.
by bbrazil 12y ago
The SoundCloud announcement is a great overview, there's also a series of blog posts I did on http://www.boxever.com/tag/monitoring going into more depth with end-to-end examples.
288.
by bbrazil 12y ago
(One of the authors here) Just last night I wrote the https://github.com/prometheus/collectd_exporter , which you could do SNMP with. I do plan on writing a purpose-designed SNMP exporter in the next a few months to mon
289.
by bbrazil 12y ago
Based on Mikey's G+ posts, it has bi-partisan support.
290.
by bbrazil 12y ago
Something I've repeatedly found useful is that when debugging and you have a conjecture, not only look for evidence that a correlation/causation is present; but also look for evidence that it isn't. Doing a very quick A/
291.
The Power of Multi-Dimensional Labels in Prometheus(boxever.com)
8 points by bbrazil 12y ago|0 comments
292.
Easy Java Instrumentation with Prometheus(boxever.com)
8 points by bbrazil 12y ago|0 comments
293.
by bbrazil 12y ago
Apparently influxdb would take 11x the storage of prometheus's approach: http://prometheus.github.io/docs/introduction/comparison/#pr...
294.
Monitor Docker Containers with Prometheus(5pi.de)
20 points by bbrazil 12y ago|5 comments
295.
by bbrazil 12y ago
Yes, I've written up a blog post on how we do it: http://www.boxever.com/haproxy-monitoring-with-prometheus It's been very useful.
296.
by bbrazil 12y ago
The issues are a bit more fundamental. You can't practically fit 50TB on one machine and have reasonable performance, that means multiple machines with the data spread across them. There's then two potential issues: 1) You're
297.
by bbrazil 12y ago
I've worked on relational databases of similar size. There's two challenges. The first is maintaining the relational model at that scale is quite tricky, tradeoffs need to be made. The second is the systems-level management of th
298.
by bbrazil 12y ago
In practice it's more a marketing term, and how big is big depends on what the nature of the data is and what you're doing with it. If it fits in RAM on your laptop, it isn't big data. If you can't process/handle it
299.
Push vs. Pull for Monitoring(boxever.com)
5 points by bbrazil 12y ago|0 comments
300.
Balancing Based on Utilisation with HAproxy(boxever.com)
6 points by bbrazil 12y ago|0 comments

More ›