2021-08-04
I have mixed views on new DNS top level domains (TLDs)
Over on Twitter I said something related to new TLDs. I have some views on what I said that are for another entry, but for now I want to sort out some views on new TLDs in general.
New top level DNS domains come in two flavours; there are country TLDs (and country-like ones) and what are officially called generic TLDs, things like ".online" and so on. Adding new country TLDs is obviously required and is sensible, and I feel this is also the case for new TLDs for country-like entities that aren't strictly countries, such as the European Union (which is not in ISO 3166-1, although 'EU' is reserved for identifying it and it has .eu as a TLD). I think this is most people's view on country TLDs, since it's hard to argue that new countries should be frozen out of having their own TLD when existing, older ones get TLDs.
(I'm neutral on the use of country TLDs to create attractive looking URLs, for example various domains using .ly and .io.)
What I have mixed feelings about are all of the generic, non-country TLDs (gTLDs), which are sometimes called vanity TLDs. There are a lot of these gTLDs (also) and some number of them wind up getting shut down after a while, among other issues. People can also criticize a number of gTLDs for being either unnecessary or not having a good general use, and some of them have clashed with common unofficial internal use (for example, .dev, which also forces HTTPS for all websites in it). All of this makes it sound like there should be either no new gTLDs at all or at least a lot fewer of them.
However, the choices for how many new gTLDs to have are none, some, or as many as people want. If the choice is "some", IANA is put in the position of deciding which gTLDs and which gTLD purposes are worthy enough to be approved, and which aren't. I doubt there's any broad agreement on what the criteria for this should be, which means that IANA would basically be making arbitrary decisions (either for gTLDs or for the gTLD criteria). The choice of "none" feels unsatisfactory and excessively conservative; it's saying that despite the Internet's evolution since the original gTLDs were picked (and despite the wart of .mil), nothing needs to change. That leaves the choice of allowing as many gTLDs as people want to pay for, which is the current situation.
So on the one hand I don't really like the explosion of gTLDs and the various consequences of that, but on the other hand I'm not sure I see a better practical choice. You could tinker around the edges, for example by saying that all gTLDs have to have a public purpose and not be restricted to a single company (so no .google or .microsoft), but I don't think that would be a big change. And I'm not sure that those company domains are the worst gTLD annoyances.
When you do and don't get stuck query results from a down Prometheus
A while back I wrote about Prometheus and the case of the stuck metrics, where after my home desktop crashed, metrics from its Prometheus instance would be 'stuck' at constant values for a while. This happens because Prometheus will look backward a certain amount of time in order to find the most recent sample in a time series. When my machine crashed, Prometheus obviously stopped writing samples, so for the next roughly five minutes the most recent sample that was returned by queries was the last pre-crash one.
The first thing to know is that this (currently) happens if Prometheus is shut down in an orderly way, not just if Prometheus (or the entire host) crashes. Unlike what it does when a target fails to scrape (where all time series are marked stale on the spot), shutting down Prometheus currently doesn't insert stale markers for metrics (and arguably this is sensible behavior, plus it speeds up shutdowns). This means that things are at least regular; the behavior you see on crashes or freezes is the same behavior that you see if you are merely rebooting your Prometheus host or restarting Prometheus itself (for example to upgrade it).
The second thing to know is that not all PromQL
queries behave this way. As I've observed myself, some queries (and
thus Grafana graphs) will give a constant result, but others will
disappear entirely. The difference in the queries is whether or not
they use range vectors, because range vectors don't look back
outside their time range. If you say you want a '[60s]' range
vector at a particular point in time, Prometheus gives you exactly
what you asked for and no more; you get any samples within those
past sixty seconds and that's it.
Thus, if you ask for just 'some_metric' at a query step where Prometheus was down, it will look back
up to five minutes for the most recent samples of that metric, with
the result that your query 'sticks' for about five minutes, giving
the same result every time. However, if you ask for
'max_over_time(some_metric[60s])' at the same query step and
there isn't a sample within 60 seconds, you get nothing even if
there is a sample within the wider five minute window; your query
gets "empty query result" and the line in your Grafana graph
disappears. If your expression involves a rate() or irate() of
a range vector, you need at least two samples from each time series
within the time range, so your queries will disappear a bit faster
(how much faster depends on the scrape interval).
All of this makes sense now that I've thought about it carefully (and done some testing to confirm it), but the difference in behavior between simple queries and queries with range vectors is a little bit surprising.