You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
QCG (Quality Control GUI) is deployed in multiple production instances, each serving a separate QCDB database. To ensure clear separation of logs and traceability across deployments, developers must follow specific logging conventions.
6
+
7
+
## Logging with LogManager and LOG_FACILITY
8
+
9
+
Logging in QCG should use the O2 Logging application from the `@aliceo2/web-ui` framework. This wraps the Winston library and O2's InfoLogger project, providing a unified logging interface.
10
+
11
+
### Why Use LOG_FACILITY?
12
+
13
+
Each QCG deployment (e.g., `qcg`, `qcg-mc`, `qcg-async`) should have its own log label. This allows logs to be easily attributed to the correct deployment and QCDB instance.
14
+
The standard for the log_facility is: `<application_name>/<file>`
15
+
The standard for the log_facility is: `<application_name>/<service>`
16
+
17
+
> **Note:** The `<service>` portion should be a descriptive name for the service, module, or controller (e.g., `bkp-service`, `obj-controller`). This helps make logs more readable and traceable. Avoid using generic filenames; prefer meaningful service names as shown in the examples below.
18
+
### Setting the Log Facility
19
+
20
+
The log facility string should be built using the `process.env.npm_config_log_label` environment variable. If not set, a sensible default (e.g., `qcg`) should be used.
21
+
22
+
### Example: Setting Up Logging in BookkeepingService
23
+
24
+
```js
25
+
import { LogManager } from'@aliceo2/web-ui';
26
+
27
+
// Use the environment variable or a default value
0 commit comments