diff --git a/.github/workflows/main.yml b/.github/workflows/main.yml index dc9c862b..4912404b 100644 --- a/.github/workflows/main.yml +++ b/.github/workflows/main.yml @@ -26,7 +26,7 @@ jobs: #Run check - name: reviewdog - uses: vale-cli/vale-action@v2.1.1 + uses: vale-cli/vale-action@v3.0.0 with: vale_flags: "--glob=*.md" # fail_on_error: true diff --git a/docs/logging.md b/docs/logging.md index 3566e18b..1181404f 100644 --- a/docs/logging.md +++ b/docs/logging.md @@ -45,6 +45,21 @@ pcsm --source --target --log-level=debug PCSM can output logs in two formats: human-readable text (default) and structured JSON. +#### Timestamp format + +!!! admonition "Version added: 0.10.0" + +PCSM writes every log timestamp in [RFC 3339 :octicons-link-external-16:](https://www.rfc-editor.org/rfc/rfc3339){:target="_blank"} format and always in UTC, also known as Zulu time. This applies to both text and JSON output. + +```{.text .no-copy} +2026-06-02T10:43:46.854Z INF POST /start s=http +``` + +The format is `YYYY-MM-DDTHH:MM:SS.mmmZ`. The `T` separates the date from the time, and the trailing `Z` marks the timestamp as UTC, also known as Zulu time. + +Using UTC provides a consistent timestamp regardless of the host's local timezone. This makes it easier to correlate PCSM logs with MongoDB logs, FTDC diagnostics, application logs, and monitoring systems without converting between local timezones. + + #### Text format (default) By default, logs are printed to the console in a color-coded, human-readable format. This is ideal for interactive use and manual inspection. @@ -52,8 +67,8 @@ By default, logs are printed to the console in a color-coded, human-readable for ??? example "Sample output" ```text - 2024-10-26 14:30:01.000 INF s=http Starting HTTP server at http://localhost:2242 - 2024-10-26 14:30:05.123 DBG s=repl:watch op=insert ns=test.coll1 op_ts=1729953005,1 + 2026-06-02T10:43:46.854Z INF s=http Starting HTTP server at http://localhost:2242 + 2026-06-02T10:43:46.955Z DBG s=repl:watch op=insert ns=test.coll1 op_ts=1780397026,1 ``` You can disable the colorization with the `--log-no-color` flag. This is useful when redirecting log output to a file. @@ -81,8 +96,8 @@ For automated processing and integration with log aggregation tools (like the EL ??? example "Sample output" ```json - {"level":"info","s":"http","time":"2024-10-01 14:30:01.000","message":"Starting HTTP server at http://localhost:2242"} - {"level":"debug","s":"repl:watch","op":"insert","ns":"test.coll1","op_ts":[1729953005,1],"time":"2024-10-26 14:30:05.123"} + {"level":"info","s":"http","time":"2026-06-02T10:43:46.854Z","message":"Starting HTTP server at http://localhost:2242"} + {"level":"debug","s":"repl:watch","op":"insert","ns":"test.coll1","op_ts":[1780397026,1],"time":"2026-06-02T10:43:46.955Z"} ``` ### JSON field reference @@ -95,7 +110,7 @@ When `--log-json` is enabled, the following fields may appear in the log entries | `s` | string | The scope or component where the log originated (e.g., http, clone, repl). | | `ns` | string | The MongoDB namespace (database.collection) related to the event. | | `elapsed_secs` | float | The time taken for an operation to complete, in seconds. | -| `time` | string | The timestamp of the log event in YYYY-MM-DD HH:MM:SS.ms format. | +| `time` | string | The timestamp of the log event in RFC 3339 format, always in UTC (`YYYY-MM-DDTHH:MM:SS.mmmZ`). | | `message` | string | The main log message. | | `error` | string | The error message, if an error occurred. | | `op` | string | The type of operation (e.g., insert, createIndexes). | diff --git a/docs/troubleshooting.md b/docs/troubleshooting.md index fe972f16..af69cc51 100644 --- a/docs/troubleshooting.md +++ b/docs/troubleshooting.md @@ -13,9 +13,9 @@ After subsequently starting the service, you may see such messages: ??? example "Sample error messages" ```{.text .no-copy} - 2025-06-02 21:25:38.927 INF Found Recovery Data. Recovering... s=recovery + 2026-06-02T10:43:46.854Z INF Found Recovery Data. Recovering... s=recovery Error: new server: recover Percona ClusterSync for MongoDB: recover: cannot resume: replication is not started or not resuming from failure - 2025-06-02 21:25:38.929 FTL error="new server: recover Percona ClusterSync for MongoDB: recover: cannot resume: replication is not started or not resuming from failure" + 2026-06-02T10:43:46.856Z FTL error="new server: recover Percona ClusterSync for MongoDB: recover: cannot resume: replication is not started or not resuming from failure" ``` ### Recovery steps @@ -64,10 +64,10 @@ If PCSM exits abnormally or is stopped unexpectedly, restart the `pcsm` service. ??? example "Example logs" ```{.text .no-copy} - 2025-06-02 21:32:04.592 INF Starting Cluster Replication s=pcsm - 2025-06-02 21:32:04.592 DBG Change Replication is resuming s=repl - 2025-06-02 21:32:04.592 INF Change Replication resumed op_ts=[1748887947,1] s=repl - 2025-06-02 21:32:04.594 DBG Checkpoint saved s=checkpointing + 2026-06-02T10:43:46.854Z INF Starting Cluster Replication s=pcsm + 2026-06-02T10:43:46.854Z DBG Change Replication is resuming s=repl + 2026-06-02T10:43:46.854Z INF Change Replication resumed op_ts=[1748887947,1] s=repl + 2026-06-02T10:43:46.856Z DBG Checkpoint saved s=checkpointing ``` ### Replication fails while PCSM is running