HTTP API

GreptimeDB provides HTTP APIs for interacting with the database.

Headers

Authentication

GreptimeDB supports the built-in Basic authentication scheme in the HTTP API. To set up authentication, follow these steps:

  1. Encode your username and password using the <username>:<password> format and the Base64 algorithm.
  2. Attach your encoded credentials to the HTTP request header using the Authorization: Basic <base64-encoded-credentials> format.

Here’s an example. If you want to connect to GreptimeDB using the username greptime_user and password greptime_pwd, use the following command:

  1. curl -X POST \
  2. -H 'Authorization: Basic Z3JlcHRpbWVfdXNlcjpncmVwdGltZV9wd2Q=' \
  3. -H 'Content-Type: application/x-www-form-urlencoded' \
  4. -d 'sql=show tables' \
  5. http://localhost:4000/v1/sql

In this example, Z3JlcHRpbWVfdXNlcjpncmVwdGltZV9wd2Q= represents the Base64-encoded value of greptime_user:greptime_pwd. Make sure to replace it with your own configured username and password, and encode them using Base64.

HTTP API - 图1NOTE

InfluxDB uses its own authentication format, see InfluxDB for details.

Time zone

GreptimeDB supports the X-Greptime-Timezone header in HTTP requests. It is used to specify the timezone for the current SQL query.

For example, the following request uses the time zone +1:00 for the query:

  1. curl -X POST \
  2. -H 'X-Greptime-Timezone: +1:00' \
  3. -H 'Content-Type: application/x-www-form-urlencoded' \
  4. -d 'sql=SHOW VARIABLES time_zone;' \
  5. http://localhost:4000/v1/sql

After the query, the result will be:

  1. {
  2. "output": [
  3. {
  4. "records": {
  5. "schema": {
  6. "column_schemas": [
  7. {
  8. "name": "TIME_ZONE",
  9. "data_type": "String"
  10. }
  11. ]
  12. },
  13. "rows": [
  14. [
  15. "+01:00"
  16. ]
  17. ]
  18. }
  19. }
  20. ],
  21. "execution_time_ms": 27
  22. }

For information on how the time zone affects data inserts and queries, please refer to the SQL documents in the Ingest Data and Query Data sections.

POST SQL statements

You can use the GreptimeDB HTTP API to post SQL statements and interact with the database. For example, to insert data into the monitor table, use the following command:

  1. curl -X POST \
  2. -H 'Authorization: Basic {{authorization if exists}}' \
  3. -H 'Content-Type: application/x-www-form-urlencoded' \
  4. -d 'sql=INSERT INTO monitor VALUES ("127.0.0.1", 1667446797450, 0.1, 0.4), ("127.0.0.2", 1667446798450, 0.2, 0.3), ("127.0.0.1", 1667446798450, 0.5, 0.2)' \
  5. http://localhost:4000/v1/sql?db=public
  • The API endpoint is /v1/sql.
  • The authentication header is optional. For more information, refer to the Authentication section.
  • The SQL statement should be included in the body of the request as sql parameter.
  • The db parameter in the URL is optional and specifies the database to use. The default value is public.

You can also use the HTTP API to execute other SQL statements. For example, to retrieve data from the monitor table:

  1. curl -X POST \
  2. -H 'Authorization: Basic {{authorization if exists}}' \
  3. -H 'Content-Type: application/x-www-form-urlencoded' \
  4. -d "sql=SELECT * FROM monitor" \
  5. http://localhost:4000/v1/sql?db=public

The response will contain the queried data in JSON format:

  1. {
  2. "output": [
  3. {
  4. "records": {
  5. "schema": {
  6. "column_schemas": [
  7. {
  8. "name": "host",
  9. "data_type": "String"
  10. },
  11. {
  12. "name": "ts",
  13. "data_type": "TimestampMillisecond"
  14. },
  15. {
  16. "name": "cpu",
  17. "data_type": "Float64"
  18. },
  19. {
  20. "name": "memory",
  21. "data_type": "Float64"
  22. }
  23. ]
  24. },
  25. "rows": [
  26. [
  27. "127.0.0.1",
  28. 1720728000000,
  29. 0.5,
  30. 0.1
  31. ]
  32. ],
  33. "total_rows": 1
  34. }
  35. }
  36. ],
  37. "execution_time_ms": 7
  38. }

The response contains the following fields:

  • output: The execution result.
    • records: The query result.
      • schema: The schema of the result, including the schema of each column.
      • rows: The rows of the query result, where each row is an array containing the corresponding values of the columns in the schema.
  • execution_time_ms: The execution time of the statement in milliseconds.

POST PromQL Queries

GreptimeDB also exposes an custom HTTP API for querying with PromQL, and returning GreptimeDB’s data frame output. You can find it on /promql path under the current stable API version /v1. For example:

  1. curl -X GET \
  2. -H 'Authorization: Basic {{authorization if exists}}' \
  3. -G \
  4. --data-urlencode 'db=public' \
  5. --data-urlencode 'query=avg(system_metrics{idc="idc_a"})' \
  6. --data-urlencode 'start=1667446797' \
  7. --data-urlencode 'end=1667446799' \
  8. --data-urlencode 'step=1s' \
  9. http://localhost:4000/v1/promql

The input parameters are similar to the range_query in Prometheus’ HTTP API:

  • db=<database name>: Required when using GreptimeDB with authorization, otherwise can be omitted if you are using the default public database.
  • query=<string>: Required. Prometheus expression query string.
  • start=<rfc3339 | unix_timestamp>: Required. The start timestamp, which is inclusive. It is used to set the range of time in TIME INDEX column.
  • end=<rfc3339 | unix_timestamp>: Required. The end timestamp, which is inclusive. It is used to set the range of time in TIME INDEX column.
  • step=<duration | float>: Required. Query resolution step width in duration format or float number of seconds.

Here are some examples for each type of parameter:

  • rfc3339
    • 2015-07-01T20:11:00Z (default to seconds resolution)
    • 2015-07-01T20:11:00.781Z (with milliseconds resolution)
    • 2015-07-02T04:11:00+08:00 (with timezone offset)
  • unix timestamp
    • 1435781460 (default to seconds resolution)
    • 1435781460.781 (with milliseconds resolution)
  • duration
    • 1h (1 hour)
    • 5d1m (5 days and 1 minute)
    • 2 (2 seconds)
    • 2s (also 2 seconds)

The result format is the same as /sql interface described in Post SQL statements section.

  1. {
  2. "code": 0,
  3. "output": [
  4. {
  5. "records": {
  6. "schema": {
  7. "column_schemas": [
  8. {
  9. "name": "ts",
  10. "data_type": "TimestampMillisecond"
  11. },
  12. {
  13. "name": "AVG(system_metrics.cpu_util)",
  14. "data_type": "Float64"
  15. },
  16. {
  17. "name": "AVG(system_metrics.memory_util)",
  18. "data_type": "Float64"
  19. },
  20. {
  21. "name": "AVG(system_metrics.disk_util)",
  22. "data_type": "Float64"
  23. }
  24. ]
  25. },
  26. "rows": [
  27. [
  28. 1667446798000,
  29. 80.1,
  30. 70.3,
  31. 90
  32. ],
  33. [
  34. 1667446799000,
  35. 80.1,
  36. 70.3,
  37. 90
  38. ]
  39. ]
  40. }
  41. }
  42. ],
  43. "execution_time_ms": 5
  44. }