bitflicker64 commented on code in PR #509:
URL: https://github.com/apache/hugegraph-doc/pull/509#discussion_r4222849433
##########
content/cn/docs/guides/hugegraph-docker-cluster.md:
##########
@@ -293,7 +293,22 @@ curl -o /dev/null -w '%{http_code}\n' -u
"admin:${HUGEGRAPH_ADMIN_PASSWORD}" \
5. **数据在意料之外地保留了下来**：`docker compose down` 会保留命名卷。要同时删除该拓扑的数据，请使用 `docker
compose down -v`
-**查看运行时日志**：使用 `docker logs <container-name>`（如 `docker logs
hg-pd0`）可直接查看日志，无需进入容器。单机镜像 `hugegraph/hugegraph` 设置了
`STDOUT_MODE=true`，其服务日志会输出到容器 stdout。`hugegraph/server`（HStore）镜像没有设置该变量，因此对
HStore 拓扑的 Server 执行 `docker logs` 只能看到入口脚本的输出，其余内容需在容器内查看
`logs/hugegraph-server.log`。
+**查看运行时日志**：使用 `docker logs <container-name>`（如 `docker logs
hg-pd0`）可直接查看日志，无需进入容器。基于当前 master 构建的 PD、Store 以及两个 Server
镜像（`hugegraph/hugegraph` 和 HStore 的
+`hugegraph/server`）都设置了 `STDOUT_MODE=true`，服务日志会输出到容器 stdout。对 Server
而言，Hadoop、ZooKeeper、SOFA、Netty 和 Commons 的 WARN 及以上日志也会输出到 stdout；Hadoop、Netty
和 Commons 的
+INFO 日志以及审计日志、慢查询日志仍只写入文件，ZooKeeper 和 SOFA 不输出 WARN
以下的日志。`/hugegraph-server/logs` 中包含 `hugegraph-server.log`、JVM
+崩溃日志（`hs_err_pid*.log`）和内存溢出时的堆转储（`heapdump_*/java_pid*.hprof`，每次启动一个目录，Server
及其启动的 JVM 分别写入各自的文件）。两个镜像都声明了 `VOLUME /hugegraph-server`，因此 `docker restart` 和
+Compose 重新创建容器都会保留这些文件；`docker compose down` 会留下这个匿名卷，但下一次 `up` 不会再挂载它，直到
`down -v` 将其删除，所以请使用具名卷或绑定挂载来保留这些文件。Kubernetes 每次重启都会新建容器，因此需要在
Review Comment:
Minor: Same issue as the EN page (line 302): "直到 `down -v` 将其删除" is not
accurate. After a plain `docker compose down`, the anonymous volume is no
longer attached to any container, and a later `docker compose down -v` does not
remove it (reproduced with Docker 29.5.3 / Compose v5.1.4: after `up`, `down`,
`up`, `down -v`, the first anonymous volume remains). Please say that `down -v`
deletes it only when used instead of `down`, and that an already orphaned
volume must be removed with `docker volume rm` or `docker volume prune`.
##########
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
Review Comment:
Minor: "`docker compose down` leaves that anonymous volume behind unattached
until `down -v` deletes it" is not what Compose does. `down -v` removes only
named volumes declared in the Compose file and anonymous volumes attached to
the containers it is removing. Once a plain `down` has removed the container,
its anonymous `/hugegraph-server` volume is attached to nothing, so a later
`down -v` leaves it in place. I checked with Docker 29.5.3 and Compose v5.1.4
using an image that declares `VOLUME /data`: after `up`, `down`, `up`, `down
-v`, the first anonymous volume still exists and only the second one is gone. A
reader who follows this sentence to free heap-dump space will keep the old
dumps on disk. Please say that `down -v` removes the volume only when run
instead of a plain `down`, and that a volume an earlier `down` left behind has
to be removed with `docker volume rm <name>` (find it with `docker volume ls -f
dangling=true`) or `docker volume prune`. The CN page (line 300) ne
eds the same change. The paired `docker/README.md` text in
apache/hugegraph#3258 makes the same claim ("until `docker compose down -v`
deletes them").
--
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]
