bbrazil

> I would even take it a step further and allow maintainers the ability to cherry pick certain issues they'd like to put up for hacktober.

At least for Prometheus the ones we tagged with hacktoberfest are ones we'd expect a new developer to have a good chance to be able to complete.

I don't think we should be disincentive people who attempt to instead tackle more thorny issues.

I bought it for €10 5 years ago, in terms for gaming value for money I think only the €10 I spent on Minecraft beats it.

> Even more fundamental than privacy, though, is do people even know that these apps exist?

Speaking for Ireland the app was heavily publicised, and there's even a prominent "Share app" feature in the app itself.

Indeed, and it's early days yet.

From the article:

> It also reveals that, whatever the people of Ireland have been told, their app is collecting centralised data on them.

The signup flow has a very obvious and well written opt-in for collection of anonymised data to help track how well the app is working, which was mentioned by the BBC article linked. I don't think people are being mislead.

I personally decided not to enable that, but did give the app my phone number to be shared in the event I'm a close contact.

> it has been in use, it is claimed to have resulted in 91 “close contact exposure alerts”, which is remarkably few.

That they know of, as those users either opted in to the anonymous tracking or (possibly) gave their phone number. It'd be useful to know how the install base per the usual Android/iOS stats compare with the anonymous tracking enablement, but those numbers haven't been shared as far as I'm aware.

Right now our overall case numbers are low enough (around 20 per day) that it's likely hard to tell how effective the app is. However our R is currently estimated at 1.1, so even a little help from the app could help keep us below 1.

I don't think there's any clear standard. There's many confusions about push vs pull that make the discussions hard to follow, as they often make apples to oranges comparisons. For example the push you're talking about in your comment is events, whereas a fair comparison for Prometheus would be with pushing metrics to Graphite. https://www.robustperception.io/which-kind-of-push-events-or... covers this in more detail.

Taking your example you could push without sending a packet on every event by instead accumulating a counter in memory, and pushing out the current total every N seconds to your preferred push-based monitoring system. You could even do this on top of a Prometheus client library, some of the official ones even as a demo allow pushing to Graphite with just two lines of code: https://github.com/prometheus/client_python#graphite

In my personal opinion, pull is overall better than push but only very slightly. Each have their own problems you'll hit as you scale, but those problems can be engineered around in both cases.

Disclaimer: Prometheus developer

Seconding this. Out of all games in that general category Rimworld is scratching my DF itch, without me having to dig all the way back into full DF complexity.

> It's not purely used for video games, mind you.

Indeed. I also use it to stream sports with the scores as an overlay, and to record training videos.

Basically if you're doing anything "live" with video, it's the tool you want.

This isn't about getting input from a camera (which works fine), but making the output of OBS appear as a camera to the rest of the system.

At a previous company (30-40 employees) the main thing was having a blog setup somewhere that engineers could post to - clearly distinguished from the main product blog. Actually getting engineers to write up blog posts was a separate problem. Besides me there were only a handful, even when it was made clear that it could be about a very small topic. A few hundred words is plenty.

They had that too: https://en.wikipedia.org/wiki/Microsoft_V-Chat

It seems to work fine for the Irish presidential elections, which are single winner.

The Irish presidency is almost entirely a ceremonial role.

"Dry weight" is what you're thinking of.

That works until there's ~only self-checkouts, then it gets slow again.

There's a knack to using them, and unless you have a generous number of them (I know of only two local stores that do), you end up getting stuck while the single staff member assigned to the self-checkouts assists customers having issues.

Plus it's not unusual for a significant number of them to be out of order, not accepting credit cards, only accepting credit cards, or just being generally temperamental.

The deal isn't a hard Brexit for the Brexiters, and isn't a remain for the remainers.

16k samples/s is not a lot. There are many Prometheus users with hundreds of thousands of samples/s on a single Prometheus server.

Across their organisations it can be much more, Fastly has reported 2.2M/s (https://promcon.io/2018-munich/slides/monitoring-at-scale-mi...) for example.

We've a STV system in Ireland, I'm not sure you'd classify our independents as centrist (by the Irish definition of centrist - by the US definition almost all our politicians are far left).

Overall the system works quite well, and the proportion of representatives a party has in parliament roughly aligns with first preference votes.

> But as stated by others (about Ireland in their example), even companies that had their hq there asked for zip code at a time there was not any.

Post codes are not generally used in Ireland. The launch was not really successful and even An Post (the government-run postal service) doesn't use them.

Irish counties are fun, as the traditional 26 counties (in the Republic) don't align with the thirty-something administrative counties that now exist.

> I strongly disagree that metrics and logs are different toolsets, or that you would need both of them in order to properly observe your systems.

And from the link:

> Logging can be useful for some purposes. However, it’s rare that they’re the only tool for monitoring your code. And it’s even rarer that they’re the best tool.

Metrics are a tool that take a different approach to logs, once you get beyond small systems you need both. I talked about this earlier in the year: https://www.youtube.com/watch?v=hCBGyLRJ1qo

Prometheus is not intended as durable long term storage, it's fundamentally limited to the size of a machine. You should also design your monitoring be able to tolerate completely losing the data of a Prometheus.

We recommend using another system for long term data, see https://prometheus.io/docs/operating/integrations/#remote-en... for some examples.

Splunk is a event logging system, compared to Prometheus which is metrics based. You need both types of systems to be able to properly observe your systems, they're complementary.

There is a transition feature: https://www.robustperception.io/accessing-data-from-promethe...

The problem with data migration is that the two versions of the system lay out the data quite differently, so converting from one to the other would take a lot of disk seeks. In the worst case you could be looking potentially at days to convert the data over, which isn't really an option for most systems that care about older data.

The third version of the InfluxDB database is basically the same core design as Prometheus's third database version which 2.0 uses. I'd expect performance to be broadly similar, maybe a little better with Prometheus as we can take advantage of the characteristics of our domain.

We do have a comparison to Influx on our website: https://prometheus.io/docs/introduction/comparison/#promethe... Which is the right choice really depends on the use case. If you're doing metrics-based operational monitoring, Prometheus is generally best.

Disclaimer: Prometheus developer.

> alternatives have been developed

Such as Prometheus :) Even some teams in Google use it.

> What if you want to keep time-series data for accounting purposes forever?

Prometheus is not recommended for uses where 100% accuracy is required, see https://prometheus.io/docs/introduction/overview/#when-does-...?

I'd also be wary of using Graphite for such a use case. For billing a more traditional database is probably best.

That's a short lived batch job, for which a different approach is needed - basically push is the sane option there as pull won't cut it. Prometheus has the Pushgateway for this.

The push vs pull debate is relevant for longer running daemons, not batch jobs.

> But yes it is possible to miss some requests if a node goes down without Prometheus collecting the latest stats.

The rate() function allows for this, you'll get the right answer on average.

You will note that Prometheus explicitly does not have a macro system.

There's already a two-way integration between Prometheus and TimescaleDB: https://github.com/timescale/pg_prometheus

There's two issues with that, first the statsd event approach has scaling problems as relative to an instrumentation event a UDP packet is actually quite heavyweight (https://www.robustperception.io/which-kind-of-push-events-or...) and secondly how do you know that all devices that are meant to be sending are sending (https://www.robustperception.io/push-needs-service-discovery...).

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 the here and now.