imbajin commented on code in PR #509: URL: https://github.com/apache/hugegraph-doc/pull/509#discussion_r4224185972
########## content/en/docs/guides/hugegraph-docker-cluster.md: ########## @@ -293,7 +293,29 @@ Standalone publishes only `8080` and `8088`; minimal HStore publishes `8620` (PD 5. **Unexpected retained data**: `docker compose down` keeps named volumes. To delete topology data too, use `docker compose down -v`. -**Runtime logs**: `docker logs <container-name>` (for example, `docker logs hg-pd0`) shows logs without entering containers. Standalone `hugegraph/hugegraph` sets `STDOUT_MODE=true` and sends service logs to stdout. The HStore `hugegraph/server` image does not set this variable: `docker logs` shows only entrypoint output; inspect `logs/hugegraph-server.log` inside the container for service logs. +**Runtime logs**: `docker logs <container-name>` (for example, `docker logs hg-pd0`) shows logs without entering containers. In images built from current +master, the PD, Store and both Server images (`hugegraph/hugegraph` and the HStore `hugegraph/server`) set `STDOUT_MODE=true` and send service logs to stdout. +For the Server, WARN and above from Hadoop, ZooKeeper, SOFA, Netty and Commons also reaches stdout; INFO from Hadoop, Netty and Commons and the audit and +slow-query logs stay in files, and ZooKeeper and SOFA log nothing below WARN. `/hugegraph-server/logs` holds `hugegraph-server.log`, JVM crash logs +(`hs_err_pid*.log`) and out-of-memory heap dumps (`heapdump_*/java_pid*.hprof`, one directory per start, so the Server and the JVMs it starts get separate +files). Both images declare `VOLUME /hugegraph-server`, so `docker restart` and a Compose recreate keep them; `docker compose down` leaves that anonymous volume +behind unattached until `down -v` deletes it, so use a named volume or bind mount to keep them reachable. Kubernetes starts a new container on every restart, so +mount an `emptyDir` or a PersistentVolumeClaim at `/hugegraph-server/logs`. Give each pod its own volume, or a per-pod directory on a shared PVC +(`subPathExpr: $(POD_NAME)`, with `POD_NAME` passed in from `metadata.name` through the Downward API; the Helm chart sets neither): crash files get distinct +names, but the log files themselves have fixed names. The Helm chart does not mount a logs volume yet. A heap dump can be as large as the JVM heap, and every +start uses a new directory, so a Server that keeps running out of memory fills the volume; size it for the dumps you want to keep, keep it within any +`ephemeral-storage` limit or `emptyDir` `sizeLimit` (eviction deletes the `emptyDir` with the dump), and do not use `medium: Memory`. The launcher never deletes Review Comment: ⚠️ This Kubernetes storage guidance covers eviction, but omits the liveness-probe case: if the probe restarts the container while HotSpot is still writing a large dump, the file can be truncated. The paired Server guide documents this failure mode in `apache/hugegraph#3258` `docker/README.md`; please add the caveat here in both EN and CN and advise allowing enough time before a liveness restart. Evidence: the paired guide’s exact-head text and [Kubernetes liveness-probe behavior](https://kubernetes.io/docs/concepts/workloads/pods/pod-lifecycle/). -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
