bbrazil

../../Sirupsen/logrus/text_formatter.go:28: undefined: IsTerminal

The logrus library we use for logging doesn't support Solaris.

I do nightly binaries for Prometheus in all the possible archs, while things should compile perfectly there can be small things that prevent things from cross-compiling.

darwin/arm, darwin/arm64, plan9/386, plan9/amd64 and solaris/amd64 don't compile for any of the 11 binaries (e.g. plan9 doesn't work due to logrus not having support for it).

This leaves me with the list at http://www.robustperception.io/prometheus-nightly-binaries/ That's still 20 architectures I can compile almost everything to automatically with an ansible+jenkins setup.

As an Irishman, both announces and announce sound fine to me.

Try out Prometheus, you can get it up and running a few minutes. It supports all the functions Graphite does, bar sin() and the Holt Winters functions which we plan on adding.

Kibana is more logging, but Promethues covers the StatsD and Graphite requirements out of the box. Graphfana is one visualisation option to go with that (http://www.robustperception.io/setting-up-grafana-for-promet...).

The problem with subresource integrity is that it ties you to one version of the code. That's fine for something like jQuery, but doesn't work in this case where you expect the code to change relatively frequently.

As part of my degree 10 years ago we did wire wrapping to make a simple 68332 computer with serial terminals for I/O. The team I was on was weeks ahead of the others, until we were stuck by what turned out to be one wrong wire.

I think it was dropped from the course a few years later.

The definition I like is that it's when the size of the data becomes a significant challenge to solving your problem.

For example 1TB of data won't fit in memory, but if all you need to do is a sequential read in under a day then it's not a problem.

This is basically the approach we take with Prometheus, with the option to add in additional stats like duration and processed records too.

http://www.robustperception.io/monitoring-batch-jobs-in-pyth... is the full Python version, and the simple version is a bash one-liner too.

Syntax and semantics are separate, not having to learn a new syntax is handy.

Syntactically the problem I run into is that it's got it's own DSL in task definitions, so it can be hard to keep in mind what's YAML and what's the DSL.

Semantically loops and conditions are essential features so I don't have a problem with that. The inheritance could use some clarification, I was hit last year by a regression that remains unresolved.

It should read "split up your monolith".

Just because one extreme isn't working for you doesn't automatically mean the other extreme is the right solution.

In Prometheus we solved this by having Histograms where we exported cumulative buckets of latencies, which can be aggregated and then the quantiles calculated from them.

http://prometheus.io/docs/practices/histograms/#quantiles

> Health insurance will inevitably start to care about what you eat and how much you exercise.

This is already happening, I met the founder of http://wesavvy.com/ recently which uses your phone to track exercise and reduce your insurance premium.

At least in terms of configuration management, what you usually end up with have is a complex config generated by something that is Turing complete.

Better to start out and keep the core configuration representation simple (e.g. json, protobuf, ini file) and generated by something powerful like Flabbergast.org.

My personal contribution is http://demo.robustperception.io:9090/consoles/life.html

Who doesn't want a Turing Complete monitoring language?

> Once your engineering org gets to be a certain size the benefits you can obtain by investing in making all your engineers slightly more productive start to swamp the slight gains that one team might get from doing things their own, slightly different way.

I like to think of this idea as group vs. individual velocity. Yes, you personally might be able to go faster by introducing new technologies - but everyone else is slowed down by having to learn it. Knowing which few of these technologies will be an overall win is the tricky bit.

An additional practical difference is that due to tracking less, that metrics can take much fewer resources allowing you to gain insight that's not practical from logs.

I'd expect in a well instrumented system that a single request could easily affect hundreds of metrics. Trying to get that level of information from logging alone isn't practical due to the volume of data it'd require.

If you want to track overall behaviour of hundreds of codepoints then metrics are good, if you want to track behaviour for all of your events at a handful of codepoints then logs are good.

It's not just that, EU startups who currently depend on US-based services are going to be in quite a bit of trouble unless they got consent from their users to put their data in the US.

> I wonder if they use exponential backoff?

More importantly, did they use randomised exponential backoff?

Having all the retires hitting at the same time can lead to a pulses of outages until things settle down.

Given they had ~300 minutes of outage in 3 years, you're looking at ~99.98% reliable in just that region. That's pretty good for a stateful serving system, and indeed you'd be pushed to do better.

Having to deal with different types of enemy at the same time gets interesting, things start to get tricky around level 7-8.

Since starting my own business recently I've been doing a lot of networking at various tech/entrepreneur events. It continues to amaze me just how many people with an idea, or even several months into building product, have yet to talk to a potential customer.

PEP 0475 makes me happy, I've had to workaround interrupted syscalls a few times.

You're not crazy, network problems happen all the time. https://aphyr.com/posts/288-the-network-is-reliable

It's the small blips that cause the most problems, as correctness issues in your C can show up then and they're much more common than full-on partitions.

From experience I think some of the problem is that not everyone appreciates the importance of correctness in this sort of system. At the very least you should clearly documenting your expected failure modes, so that it's possible to build correct things on top of it.

In part it's hard to convince everyone of the importance of spending time on what looks like an unlikely corner case until after the outage - when it also becomes much harder to fix as you usually need to build this into the core design of your system.

Shameless plug: I implemented Conway's Life in Prometheus (the monitoring system) earlier this week: http://www.robustperception.io/conways-life-in-prometheus/

Demo: http://demo.robustperception.io:9090/consoles/life.html

This is a good setup, I had similar years ago to deal with screen.

One general word of warning with ssh-agent: Only use -A to forward it to another host that you completely trust, as anyone with root on that machine will be able to use your private keys.

> It's a felony to tweak your Wifi beyond specs, it causes issues and regulatory bodies react, OpenWRT and DD-WRT could've saved them selves the trouble by developing a mechanism to respect local regulation own their own.

The Linux kernel has such mechanisms and they're not trivial to bypass. You'd as a user have to go out of your way to do so, and the devs are not in favour of users doing this. (source: I had to do so to workaround a card that was configured for completely the wrong regulatory domain).

Doesn't catch "tineh", which is apparently a derogatory term for Indians http://www.urbandictionary.com/define.php?term=tineh, so probably wise to also check UD and Google.

I was going to have that as part of my company name until I discovered that (tineh is a transliteration of the word for "fire" in Irish).

I found it extremely useful when using public transport in Japan, and telling me the last bus time in Dublin is useful too.