Issues with Timestamp Format in Zinc-Observe API Query
TLDR Rex faced an issue with the timestamp format in Zinc-Observe API query. Hengfei pointed out that start and end times should be in i64 and in microseconds as per the search document.
Prabhat
Mon, 27 Feb 2023 01:19:25 UTCCan you share your query
Prabhat
Mon, 27 Feb 2023 01:19:38 UTCin json format
Prabhat
Mon, 27 Feb 2023 01:20:00 UTCare you able to use the query using postman?
Hengfei
Mon, 27 Feb 2023 01:28:57 UTCWe already have it in the search document, you should have a look the description table, it said start_time and end_time should be i64 and unit is micro timestamp
Rex
Mon, 27 Feb 2023 01:49:02 UTCThanks for the replies. I did not try in postman, I was building the timestamps dynamically in python. I can see the reference to microseconds in the docs now. Cheers
OpenObserve
Indexed 419 threads
OpenObserve is an open-source, petabyte-scale observability platform for the cloud native realm, offering a 10x cost reduction and 140x less storage use compared to competitors like Elasticsearch or Splunk. Built in Rust for exceptional performance, it offers comprehensive features like logs, metrics, traces, dashboards, and more | Knowledge Base powered by Struct.AI
View in App
Rex
Sun, 26 Feb 2023 20:45:08 UTCAfternoon everyone, using as a reference im trying to do a query against the (zinc-observe) api. It seems to want the start and end times in a specific format, but doesn't return an error if it is given a timestamp that does not conform to that format (and if theres a specific format, should it be documented?). should i open a issue for this?
Using timestamps in this form: `start.timestamp()` returns:
invalid type: floating point `1677441308.789123`, expected i64 at line 1 column 82
Using _`int(start.timestamp())` :_
{"took":19,"hits":[],"total":0,"from":0,"size":10,"scan_size":0}
Using: _`int(f"{int(start.timestamp())}006000")` returns the expected results_