mcclymont
commented
8 years ago This library actually uses the TCP/telnet API, not the HTTP one. http://opentsdb.net/docs/build/html/user_guide/writing.html#telnet
The Telnet method of writing is discouraged as it doesn't provide a way of determining which data points failed to write due to formatting or storage errors. Instead use the HTTP API.
So there is no information about whether storing the metric succeeded or not. We only know if we succeeded in sending the request to OpenTSDB.
potsdb will warn you if it can't connect to the OpenTSDB server when you instantiate the client, and it will print a warning to stdout if the queue gets full. Therefore as it stands I don't think there is much benefit in adding a queue to collect the metric sending results.
It would however make sense to keep the latest N responses if we were to switch to the HTTP API. I would only consider that if the performance impact were negligible. With keepalive, it shouldn't make too much of a difference.
Unfortunately we are quite busy here at orionvm and can't prioritise a feature enhancement like this when the current solution is working fine and as intended for us.
Out of interest, what would you do with the information if the latest N responses were available?
It's good idea to handle the http request by multi threading, but that result in no response to the request. Can u add the a deque to persist the latest N response?