github.com/thanos-io/thanos@v0.32.5/docs/proposals-done/202203-grpc-query-api.md (about)

     1  ## Introduce a Query gRPC API
     2  
     3  * **Owners:**
     4    * `@fpetkovski`
     5    * `@mzardab`
     6  
     7  > TL;DR: Introducing a new gRPC API for `/query` and `/query_range`
     8  
     9  ## Why
    10  
    11  We want to be able to distinguish between gRPC Store APIs and other Queriers in the query path. Currently, Thanos Query implements the gRPC Store API and the root Querier does not distinguish between Store targets and other Queriers that are capable of processing a PromQL expression before returning the result. The new gRPC Query API will allow a querier to fan out query execution, in addition to Store API selects.
    12  
    13  This is useful for a few reasons:
    14  
    15  * When Queriers register disjoint Store targets, they should be able to deduplicate series and then execute the query without concerns of duplicate data from other queriers. This new API would enable users to effectively partition by Querier, and avoid shipping raw series back from each disjointed Querier to the root Querier.
    16  * If Queriers register Store targets with overlapping series, users would be able to express a query sharding strategy between Queriers to more effectively distribute query load amongst a fleet of homogenous Queriers.
    17  * The proposed Query API utilizes gRPC instead of HTTP, which would enable gRPC streaming from root Querier all the way to the underlying Store targets (Query API -> Store API) and unlock the performance benefits of gRPC over HTTP.
    18  * When there is only one StoreAPI connected to Thanos Query which completely covers the requested range of the original user's query, then it is more optimal to execute the query directly in the store, instead of sending raw samples to the querier. This scenario is not unlikely given query-frontend's sharding capabilities.
    19  
    20  ### Pitfalls of the current solution
    21  
    22  Thanos Query currently allows for `query` and `query_range` operations through HTTP only. Various query strategies can be implemented using the HTTP API, an analogous gRPC API would allow for a more resource efficient and expressive query execution path. The two main reasons are the streaming capabilities that come out of the box with gRPC, statically typed API spec, as well as the lower bandwidth utilization which protobuf enables.
    23  
    24  ## Goals
    25  * Introduce a gRPC Query API implementation equivalent to the current Querier HTTP API (`query` for instant queries, `query_range` for range queries)
    26  
    27  ## Non-Goals
    28  
    29  * Implementation of potential query sharding strategies described in this proposal.
    30  * Streaming implementations for `query` and `query_range` rpc's, these will be introduced as additional `QueryStream` and `QueryRangeStream` rpc's subsequently.
    31  * Response series ordering equivalent to the current Prometheus Query HTTP API behaviour
    32  
    33  ### Audience
    34  * Thanos Maintainers
    35  * Thanos Users
    36  
    37  ## How
    38  
    39  We propose defining the following gRPC API:
    40  
    41  ```protobuf
    42  service Query {
    43    rpc Query(QueryRequest) returns (stream QueryResponse);
    44  
    45    rpc QueryRange(QueryRangeRequest) returns (stream QueryRangeResponse);
    46  }
    47  ```
    48  
    49  Where the `QueryRequest`, `QueryResponse`, `QueryRangeRequest` and `Query RangeResponse` are defined as follows:
    50  
    51  ```protobuf
    52  message QueryRequest {
    53    string query = 1;
    54  
    55    int64 time_seconds = 2;
    56    int64 timeout_seconds = 3;
    57    int64 max_resolution_seconds = 4;
    58  
    59    repeated string replica_labels = 5;
    60  
    61    repeated StoreMatchers storeMatchers = 6 [(gogoproto.nullable) = false];
    62  
    63    bool enableDedup = 7;
    64    bool enablePartialResponse = 8;
    65    bool enableQueryPushdown = 9;
    66    bool skipChunks = 10;
    67  }
    68  
    69  message QueryResponse {
    70    oneof result {
    71      /// warnings are additional messages coming from the PromQL engine.
    72      string warnings = 1;
    73  
    74      /// timeseries is one series from the result of the executed query.
    75      prometheus_copy.TimeSeries timeseries = 2;
    76    }
    77  }
    78  
    79  message QueryRangeRequest {
    80    string query = 1;
    81  
    82    int64 start_time_seconds = 2;
    83    int64 end_time_seconds = 3;
    84    int64 interval_seconds = 4;
    85  
    86    int64 timeout_seconds = 5;
    87    int64 max_resolution_seconds = 6;
    88  
    89    repeated string replica_labels = 7;
    90  
    91    repeated StoreMatchers storeMatchers = 8 [(gogoproto.nullable) = false];
    92  
    93    bool enableDedup = 9;
    94    bool enablePartialResponse = 10;
    95    bool enableQueryPushdown = 11;
    96    bool skipChunks = 12;
    97  }
    98  
    99  message QueryRangeResponse {
   100    oneof result {
   101      /// warnings are additional messages coming from the PromQL engine.
   102      string warnings = 1;
   103  
   104      /// timeseries is one series from the result of the executed query.
   105      prometheus_copy.TimeSeries timeseries = 2;
   106    }
   107  }
   108  ```
   109  
   110  The `Query` Service will be implemented by the gRPC server which is started via the `thanos query` command.
   111  
   112  ## Alternatives
   113  
   114  The alternative to expressing a gRPC Query API would be to use the HTTP APIs and distinguish Queriers via configuration on startup. This would be suboptimal for the following reasons:
   115  * No statically typed API definition, we would need to rely on HTTP API versioning to manage changes to the API that is intended to enable advanced query execution strategies.
   116  * HTTP not as performant as gRPC/HTTP2, gRPC/HTTP2 allows us to use streaming(less connection overhead) and protobuf(smaller response sizes), the current HTTP API does not.
   117  * Ergonomics, gRPC allows us to express a functional API with parameters, HTTP requires request parameter marshalling/unmarshalling which is very error-prone.
   118  
   119  ## Action Plan
   120  
   121  * [X] Define the QueryServer gRPC Service
   122  * [X] Implement the QueryServer gRPC Service in the Thanos Query