Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
20 changes: 12 additions & 8 deletions .mise/config.toml
Original file line number Diff line number Diff line change
Expand Up @@ -238,18 +238,22 @@ version = "08a1d6f"

# OpenObserve open-source binary for the o2-native task.
# The same build the o2 docker image runs (its Dockerfile is just `CMD ["/openobserve"]`), pinned to the same
# version. Direct upstream download, no checksum. No Windows build exists (downloads.openobserve.ai 403s the
# windows asset), so os-scoped to linux + macos.
# version. Direct upstream, per-version immutable URLs, so no checksum. Every supported platform has a prebuilt:
# the Windows asset is a `.zip` (holding `openobserve.exe`) rather than the `.tar.gz` the others use -- probing the
# `.tar.gz` name is what previously read as "no Windows build". windows-arm64 has no prebuilt but is not a target.
[tools."http:openobserve"]
bin = "openobserve"
os = ["linux", "macos"]
version = "0.70.3"
version = "0.91.5"
[tools."http:openobserve".platforms.linux-arm64]
url = "https://downloads.openobserve.ai/releases/openobserve/v0.70.3/openobserve-v0.70.3-linux-arm64.tar.gz"
url = "https://downloads.openobserve.ai/releases/openobserve/v0.91.5/openobserve-v0.91.5-linux-arm64.tar.gz"
[tools."http:openobserve".platforms.linux-x64]
url = "https://downloads.openobserve.ai/releases/openobserve/v0.70.3/openobserve-v0.70.3-linux-amd64.tar.gz"
url = "https://downloads.openobserve.ai/releases/openobserve/v0.91.5/openobserve-v0.91.5-linux-amd64.tar.gz"
[tools."http:openobserve".platforms.macos-arm64]
url = "https://downloads.openobserve.ai/releases/openobserve/v0.70.3/openobserve-v0.70.3-darwin-arm64.tar.gz"
url = "https://downloads.openobserve.ai/releases/openobserve/v0.91.5/openobserve-v0.91.5-darwin-arm64.tar.gz"
[tools."http:openobserve".platforms.macos-x64]
url = "https://downloads.openobserve.ai/releases/openobserve/v0.91.5/openobserve-v0.91.5-darwin-amd64.tar.gz"
[tools."http:openobserve".platforms.windows-x64]
url = "https://downloads.openobserve.ai/releases/openobserve/v0.91.5/openobserve-v0.91.5-windows-amd64.zip"

# chromedriver from Google's Chrome for Testing CDN, for the headless-browser wasm-bindgen tests.
# The `os` list uses mise's os/arch compound syntax (mise >= 2026.4, jdx/mise#9088) to skip linux-arm64: Chrome
Expand Down Expand Up @@ -484,7 +488,7 @@ a_rp_wasm_short = "08a1d6f"
actionlint_args = ""
gh_http = "--http-url https://github.com --progress --ignore-existing"
# OpenObserve docker image for the openobserve/o2 dev-observability task.
o2_image = "openobserve/openobserve:v0.70.3"
o2_image = "openobserve/openobserve:v0.91.5"

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🩺 Stability & Availability | 🟠 Major | ⚡ Quick win

🧩 Analysis chain

🏁 Script executed:

#!/usr/bin/env bash
set -euo pipefail

image='openobserve/openobserve:v0.91.5'
name='o2-review-openobserve'
health_cmd='/openobserve node status'

trap 'docker rm -f "$name" >/dev/null 2>&1 || true' EXIT

docker pull "$image"
docker run --rm --env-file config/o2.env --entrypoint /openobserve "$image" node status
docker run --detach --name "$name" --env-file config/o2.env \
  --publish 5080:5080 \
  --health-cmd "$health_cmd" \
  --health-interval 5s \
  --health-timeout 3s \
  --health-retries 20 \
  --health-start-period 10s \
  "$image" >/dev/null

for ((attempt = 0; attempt < 60; attempt += 1)); do
  state="$(docker inspect --format '{{.State.Health.Status}}' "$name")"
  [[ "$state" == healthy ]] && exit 0
  sleep 1
done

echo "OpenObserve image did not become healthy" >&2
exit 1

Repository: edge-toolkit/core

Length of output: 200


🏁 Script executed:

#!/usr/bin/env bash
set -euo pipefail

echo "## .mise/config.toml relevant lines"
sed -n '480,500p' .mise/config.toml || true

echo
echo "## deployment docker image entries"
rg -n "openobserve/openobserve|o2_image|healthcheck|health" .mise/config.toml utilities/cli/src/deployment_types/docker_compose.rs services/ws-wasi-runner/tests/o2_ingest_search.rs || true

Repository: edge-toolkit/core

Length of output: 4137


🏁 Script executed:

#!/usr/bin/env bash
set -euo pipefail

echo "## .mise/config.toml relevant lines:"
sed -n '480,500p' .mise/config.toml || true

echo
echo "## deployment docker image entries:"
rg -n "openobserve/openobserve|o2_image|healthcheck|health" .mise/config.toml utilities/cli/src/deployment_types/docker_compose.rs services/ws-wasi-runner/tests/o2_ingest_search.rs || true

Repository: edge-toolkit/core

Length of output: 4139


🌐 Web query:

openobserve/openobserve:v0.91.5 Dockerfile healthcheck /openobserve node status

💡 Result:

In OpenObserve v0.91.5, the official endpoint for system health checks is /healthz [1][2]. This endpoint performs a basic liveness check, returning a JSON response indicating the status, typically {"status": "ok"} [1][3][4]. Regarding Docker health checks, the standard OpenObserve Docker image (based on debian:trixie-slim) does not include curl or other command-line utilities by default [5][6]. Consequently, if you attempt to define a Docker HEALTHCHECK using curl inside the standard container, it will fail with an error stating the executable is not found [5]. To implement a health check in Docker for OpenObserve, you have two primary options: 1. Use a Debug Image: Use a -debug version of the OpenObserve image (e.g., openobserve/openobserve:v0.91.5-debug), which includes tools like curl [5][7]. 2. External Health Checking: Perform the health check from outside the container (e.g., via a sidecar or orchestration platform like Kubernetes or Docker Compose) to avoid relying on shell utilities inside the runtime container [5]. For cluster environments, OpenObserve also utilizes a /schedulez endpoint to check node availability for task scheduling [1][8][4]. This endpoint verifies if a node is both online and enabled for task scheduling, returning a 200 OK status only if the node is actively available for workload distribution [1][4]. Internal cluster management uses these health checks to proactively remove unresponsive nodes from the consistent hash ring [9].

Citations:


🌐 Web query:

openobserve v0.91.5 /openobserve node status command

💡 Result:

In OpenObserve v0.91.5, there is no direct command-line interface (CLI) command named "node status" within the primary openobserve binary or the o2 CLI [1][2][3][4]. Monitoring node health and status in OpenObserve is primarily handled through the following methods: 1. Web UI: You can monitor node health directly in the OpenObserve dashboard by navigating to the node management section [5]. This provides status indicators (Online, Prepare, Offline) along with metrics such as CPU usage, memory usage, and TCP connections [5]. 2. Internal API: The OpenObserve codebase includes internal logic for node status reporting (e.g., /node/status endpoints) [6][7], but these are intended for system-level communication rather than direct user-invoked CLI commands. 3. O2 CLI: The o2 CLI is the designated tool for imperative management of OpenObserve resources, but its commands are focused on managing entities like organizations, dashboards, alerts, and templates rather than low-level node health status [1][2]. If you are attempting to check cluster or node status, ensure you are using the Web UI's administration interface, which is the documented and supported method for monitoring node health and infrastructure performance [5].

Citations:


🌐 Web query:

site:github.com/openobserve/openobserve "node status" "/openobserve" v0.91.5

💡 Result:

As of August 7, 2026, there is no official release versioned "v0.91.5" for OpenObserve [1]. The OpenObserve release history shows that the 0.91.x branch progressed through v0.91.3 [2], which was published on July 21, 2026 [2]. Subsequent development activity has moved toward the 0.92.0 release cycle [3]. Regarding node status functionality in OpenObserve: 1. API Endpoint: OpenObserve provides a /node/status API endpoint [4]. This endpoint exposes detailed internal node metrics, including cache information such as the parquet metadata cache size [4]. 2. CLI Command: Users can access this information via the CLI using the command openobserve node status [4]. This command invokes the /node/status API and displays the retrieved information in a formatted, human-readable table [4][5]. 3. Health Monitoring: Separate from general status reporting, the system includes health check mechanisms (such as /healthz and /schedulez) to monitor node connectivity, operational status, and scheduling availability for cluster management [6][7]. For the most current information or to confirm if a specific fix or feature was backported to a version matching your requirements, it is recommended to check the official OpenObserve GitHub releases page [1].

Citations:


🌐 Web query:

OpenObserve v0.91.5 Dockerfile HEALTHCHECK curl openobserve/node/status

💡 Result:

In OpenObserve, the correct endpoint for health checks is /healthz, not /node/status [1][2][3]. The standard OpenObserve Docker image is built from a slim Debian base, which does not include the curl utility [4][5][1]. Consequently, attempting to use curl in a HEALTHCHECK instruction will fail with an OCI runtime error unless the image is customized or a debug image is used [1]. To implement a health check for OpenObserve: 1. Use the /healthz endpoint, which returns a 200 OK status with {"status": "ok"} when the service is running [2][3]. 2. Because the standard production image lacks curl, you have two primary options: - Use a debug variant of the image (e.g., openobserve/openobserve:v0.91.5-debug), which includes tools like curl [1][6]. - If using the standard image, you must either install curl via a custom Dockerfile (e.g., RUN apt-get update && apt-get install -y curl) or implement the health check using available shell built-ins if possible, though installing curl is the standard approach for this requirement [1]. Example of a working HEALTHCHECK configuration (assuming curl is present): HEALTHCHECK --interval=5s --timeout=5s --retries=5 CMD curl --fail http://localhost:5080/healthz || exit 1 [1]

Citations:


🏁 Script executed:

#!/usr/bin/env bash
set -euo pipefail

echo "## docker_compose.rs OpenObserve service definition"
sed -n '1,50p' utilities/cli/src/deployment_types/docker_compose.rs || true

echo
echo "## o2_ingest_search.rs binary command and health wait"
sed -n '1,130p' services/ws-wasi-runner/tests/o2_ingest_search.rs || true

Repository: edge-toolkit/core

Length of output: 9018


Use a healthcheck that the OpenObserve image can run.

The generated healthcheck uses CMD /openobserve node status, but the native openobserve test starts the local Command::new("openobserve") binary separately and waits on /healthz. If openobserve/openobserve:v0.91.5 does not support this CLI node-status command, the generated Docker Compose service can fail Docker health checks immediately after startup. Make the image-level healthcheck contract an explicit test with the pinned image and config/o2.env.

🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In @.mise/config.toml at line 491, Update the OpenObserve image configuration
around o2_image to define an explicit healthcheck test using the pinned image
and config/o2.env, matching the native openobserve health behavior by checking
/healthz rather than invoking `/openobserve node status`. Ensure the generated
Docker Compose healthcheck can run directly in openobserve/openobserve:v0.91.5.

# OpenTelemetry Collector image for the o2-hostmetrics / o2-macmon / o2-nvidia / o2-winmetrics tasks.
otelcol_image = "otel/opentelemetry-collector-contrib:0.156.0"
rp_wasm_dir = '''{% if os() == "windows" -%}
Expand Down
Loading
Loading