-
Notifications
You must be signed in to change notification settings - Fork 0
Add o2 on Windows #108
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Add o2 on Windows #108
Changes from all commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
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:
Repository: edge-toolkit/core
Length of output: 200
🏁 Script executed:
Repository: edge-toolkit/core
Length of output: 4137
🏁 Script executed:
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
openobservebinary or theo2CLI [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/statusendpoints) [6][7], but these are intended for system-level communication rather than direct user-invoked CLI commands. 3. O2 CLI: Theo2CLI 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:
Repository: edge-toolkit/core
Length of output: 9018
Use a healthcheck that the OpenObserve image can run.
The generated
healthcheckusesCMD /openobserve node status, but the nativeopenobservetest starts the localCommand::new("openobserve")binary separately and waits on/healthz. Ifopenobserve/openobserve:v0.91.5does 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 andconfig/o2.env.🤖 Prompt for AI Agents