Hacker Newsnew | past | comments | ask | show | jobs | submit | more bbrazil's commentslogin

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.


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

I don't know about that - self checkouts are both more space-dense and require far less staff to support so each individual store could support way more customers.

Replacing human workers with robots should be considered a good thing, it's a problem with our system of economics, not with the companies increasing their level of automation.


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.


In Ireland you have had enough time for parties to trend towards the biggest chunk of votes, which is what I’m labelling “centrist” though perhaps this is really “populist” :(

Naming things isn’t easy.


> 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.


Do people on Ireland use townlands on the ground? They could be a more human kind of postal sector. See Townlands.ie


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.


The problem is (as you know) that single machines are in practice still too reliable and Prometheus is still too good at storing data for long times that many people have come to rely on it despite warnings :)


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.


> 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.

While this is the traditional way of looking at them, 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.

I've written and spoken about this approach before: https://medium.com/@chimeracoder/dont-read-your-logs-13586c7... and https://vimeo.com/221049715


> 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


https://youtu.be/hCBGyLRJ1qo?t=6m45s

[edit]

So I watched a few minutes into this, Brian, and it seems to me that either an expert system, or some form of rudimentary AI, that observes the monitoring system can be the driver of an intelligent alerting system. In other words, it seems 'alerts' are, in the final analysis, the higher value proposition.

And I fully agree with you: it really is a waste of talent to have engineers glued to screens watching graphs.


> 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:

Quite the opposite - the "some purposes" I'm talking about are precisely the small scale. As scale grows, the use case of logs and metrics converges, and metrics become a strictly better tool.


The question is about tracking and storing individual events (logs) with arbitrary per-item detail vs. dimensionally limited aggregations (time series / metrics). In either case, I think we agree that the data should be recorded in a structured way, and when I say "logs" I just mean a record of individual items, not of sampled/aggregated metrics.

Given that, you need both logs (individual events) and metrics. Logs give you crucial insight into individual interesting events such as single requests that bring your service down, but logs are orders of magnitude more expensive than metrics in tracking, storage, and processing. So that's why you use metrics for a much wider scope and for longer time periods.


Not for high cardinality events like what happened to a particular user during a single session. Metrics will never help with that type of problem.


> Not for high cardinality events like what happened to a particular user during a single session. Metrics will never help with that type of problem.

No, and as I explain in both that article and the video, logs aren't the best solution for that use case either.


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.


Seek time is not relevant, our stuff is on SSDs. Thanks for the link, I've known about the transition feature.


Consider applying for YC's Fall 2026 batch! Applications are open till July 27.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: