Hi. I found this request https://esi.evetech.net/ui/#/Status/get_status.
But in this response i get everything except TQ online/offline status.
So how can i do it?
P.S.
When TQ is down - Status returns this: {“error”:“Timeout contacting tranquility”,“timeout”:10}
That’s what “status” is it looks like.
you need to query TQ directly, I guess ?
ping 172.65.201.188 -q -c5 -i0.2
PING 172.65.201.188 (172.65.201.188) 56(84) bytes of data.
— 172.65.201.188 ping statistics —
5 packets transmitted, 5 received, 0% packet loss, time 803ms
rtt min/avg/max/mdev = 12.793/13.684/16.229/1.284 ms
Just set the datasource to Tranquility.
This is the URL:
https://esi.evetech.net/latest/status/?datasource=tranquility
using ‘latest’ will use v2 of the API, but any of the alternate routes will work:
https://esi.evetech.net/v2/status/?datasource=tranquility
https://esi.evetech.net/v1/status/?datasource=tranquility
https://esi.evetech.net/legacy/status/?datasource=tranquility
https://esi.evetech.net/dev/status/?datasource=tranquility
Available values : tranquility
Default value : tranquility
you don’t need to set the datasource, it’s set by default to the only one available value.
That’s correct, yes. For querying TQ, the datasource can be left off as it’s TQ by default.
So this also works fine:
https://esi.evetech.net/latest/status
Just needs a properly formed call.
Since you can only set the datasource to TQ, this option is useless anyhow. It was useful when sisi access was provided.
Yeah but now you understand that the path result does not provide the actual status of the server.
That is, when TQ is offline, you can tell because ?
And the answer is, you can’t, because this path is only updated when TQ is up. Instead if the cache expiry is reached you’ll get a 5xx with error 500 internal TQ error (something like that or proxy error). So your information is delayed 15s on this path average (cache is 30s), assuming you handle 5xx in this path correctly, knowing that you can actually receive 5xx even when TQ is up because ESI and TQ are two servers, so for a lot of reasons you should handle 5xx with retries.
So you can have bad result and TQ is up ; you can have good result when TQ is down ; so this path is not reliable to guess the current state of TQ.
Hence why I said ping TQ directly.
Ping only measures you can hit the public gateway and even during downtime, the servers don’t power down for long (just long enough to reboot), so you can still ping it, even when we can’t connect to TQ.
But sure, whichever way you think works best for you, go for it. The endpoint is fine and any internal error can be fixed just by making a call again. A 500 response will primarily occur when the ESI is down, then sure ping TQ.
But yeah, ping it if that is easier. It provides less information, but still useful.
This is unrelated.
If you use this kind of assertion, you are gonna create bugs. Don’t assume that 5xx means TQ is down, sometimes it’s just the path that is down, for internal reasons.
I don’t know if ping will work, and you affirm sometimes it won’t, so I guess there is no solution.
This question is relevant because you may get your account banned if you hammer the ESI (cf pathfinder), which can happen if POST requests fail for example. Sure you should respect the error window but even then if you start a massive chunk of requests they will all fail.
WTF? That would be idiotic and not what I said.
Ping operates at layer 3
The ESI operates at the application layer (5/7 depending on model).
Ping won’t give any sort of http response code, but could timeout. Ping doesn’t tell you anything about the status of the game, only that you can send/receive from the gateway.
The ESI might return an error message, and if not, returns information about the game that ping doesn’t provide.
Both are useful and provide different information.
If you want to talk about something being unrelated, ping is unrelated to the OPs request.
Use whichever approach works, but in relation to the OPs request about the ESI, the urls are above.
Then rate limit yourself in line with the terms (though the ESI has no rate limit and is error limited instead. Some paths have rate limits though).
The status path doesn’t require any account. You might get error limited temporarily, but not an account ban, because your account isn’t passed with the ESI request.
It doesn’t take a genius.
A lot of useful stuff here - and @Anderson_Geten’s warning of not hammering ESI is a good one: both for practical “don’t get banned” reasons and general good manners in using a free resource.
I doubt ping will be a good measure of “is the server up” since the question is really “is the Service running and accessible to clients”. There are many situations when I can see that ping will be acknowledged, but the game itself would be unavailable - downtime is a good example of this: it’s not a hard server restart, but a period when the server is doing housekeeping on the databases. And, of course, there’s an assumption that the component being pinged is actually the component you are interested in - and that’s a poor assumption.
My first reaction to the question “Is Eve Offline?” (different question to “Is the server running?”) and the interface was:
In general, don’t hammer the API to see if the service is up - the equivalent of the child in the car going “are we there yet”. Do it every now and then or when you have a particular need to know the server state (for example on application start-up).
Also after the end of an error window.
Before you release N request, with N being the max amount of concurrent requests, it’s interesting to check if TQ is down - in that case you should delay the sending of the requests until TQ is up.
Since Downtime has just happened, I gave the endpoint a poke during downtime and:
{
“error”: “Timeout contacting tranquility”,
“timeout”: 10
}
I suspect that because the information relates directly to current state of the server (users/restart time/version) then if Tranquillity is off line it can’t obtain the details so it returns an error.
Now that Eve is online again a normal response is being received.
I suspected the API endpoints were not being served directly by Tranquillity but by some Intermediary service (for good reasons) - this seems to confirm that hypothesis. The design nicely behaves when the intermediary giving a nice application error response when it can’t access Tranquillity in the background.
HTTP Status messages relate only to the HTTP connection you are dealing with with, not to things going on in the application behind the HTTP Server, so this is the correct response from the Intermediary. HTTP Status from the API endpoint doesn’t give any information on the state of Tranquillity.
Nothing the OP couldn’t have worked through themselves…
i think this enough for detect TQ down state. But when i creating this topic i expected what exists some GET request special for check TQ online status…