Logging with new format and named logger

[gxuu]

READY FOR REVIEW.

• Unify log format to <time> <level> <process_name>[<pid>]: <msg> across Python and C++ (Better logging #691) — makes it easy to tell which subprocess emitted which line under scaler_all.
• Migrate scaler off the root logger onto a named scaler logger with propagate=False + NullHandler (Scaler log output can be silently suppressed by third-party libraries that reconfigure the root logger #653) — third-party code (e.g. ORB) can no longer suppress scaler output.

LOGGING MIGRATION GUIDE FOR PRIVATE WORKER MANAGERS (FOR HUMAN):

• Log format has been changed, no action is required if your worker managers running through worker manager entry point.
• Global logging is no longer being used, please use a named logger instead. Consult orb worker manager for the usage.
• If your adapter lives outside this repo, name your logger under the scaler tree so it inherits scaler's handlers:
  logger = logging.getLogger(f"scaler.external.{__name__}") — otherwise your logs will silently go nowhere.

HUMAN SHOULD STOP READING HERE

LOGGING MIGRATION GUIDE FOR PRIVATE WORKER MANAGERS (FOR AI):

Context

Two recent changes in opengris-scaler (PRs #691 and #653) affect every
worker-manager adapter that logs output. Internal / out-of-repo adapters
must be updated to match, or their log output will either (a) not appear,
or (b) drift from the unified scaler format.

What changed upstream

1. Unified log format (Better logging #691) — all scaler processes emit:
   <timestamp> <level> <process_name>[<pid>]: <message>
   The <process_name> is set by setup_logger(..., process_name=...),
   called once in scaler.entry_points.scaler._run_worker_manager before
   your adapter's run() executes. You do NOT call setup_logger yourself.

2. Named loggers, off the root logger (Scaler log output can be silently suppressed by third-party libraries that reconfigure the root logger #653) — scaler no longer
   configures the root logger. It configures the named logger "scaler"
   with propagate=False. Any logger whose dotted name starts with
   scaler. inherits scaler's handlers and format; anything outside that
   tree does not.

3. ORB workaround removed. Calls like:
   setup_logger(self._logging_paths, self._logging_config_file, self._logging_level)
   inside __aenter__ (or anywhere inside an adapter) are now dead. The
   reason the workaround existed — third-party SDKs mutating root after
   scaler configured it — is no longer relevant because scaler no longer
   uses root.

Required changes for an internal worker-manager adapter

Step 1 — Add a module-level named logger

At the top of every .py file in the adapter that currently uses
logging.<method>(...) module-level calls, add:

import logging

logger = logging.getLogger(f"scaler.external.{__name__}")

The scaler.external. prefix places the logger under the scaler tree
so it inherits scaler's handlers, format, and level automatically. If
your adapter is already under the scaler. namespace (unlikely for
out-of-repo code), use logging.getLogger(__name__) directly.

Step 2 — Replace module-level logging calls

Mechanical substitution across every .py in the adapter:

logging.info(...)       → logger.info(...)
logging.warning(...)    → logger.warning(...)
logging.error(...)      → logger.error(...)
logging.exception(...)  → logger.exception(...)
logging.debug(...)      → logger.debug(...)

Leave import logging — it's still needed for the logging.getLogger
call and any logging.INFO-level constants.

Step 3 — Remove dead logging-setup code

Delete the following patterns wherever they appear in the adapter:

# In __init__ — remove these lines:
self._logging_paths       = config.logging_config.paths
self._logging_level       = config.logging_config.level
self._logging_config_file = config.logging_config.config_file

# In __aenter__ / run() / similar — remove:
setup_logger(self._logging_paths, self._logging_config_file, self._logging_level)

# Remove the import if now unused:
from scaler.utility.logging.utility import setup_logger

Step 4 — Do not call setup_logger from the adapter

_run_worker_manager in scaler.entry_points.scaler calls
setup_logger(..., process_name=config._tag) as the first statement of
the subprocess. Adapters MUST NOT call it again — doing so resets the
format with the wrong process_name.

Step 5 — Verify

Run the adapter and confirm:

1. Log lines appear in the unified format
   <time> <level> <process_name>[<pid>]: <message>
   with <process_name> equal to config._tag.
2. No warnings about "no handler attached to logger …".
3. A third-party library calling logging.basicConfig(...) from within
   the subprocess does NOT change scaler's log output.

Verification checklist

• Every .py in the adapter has logger = logging.getLogger("scaler.external." + __name__) (or equivalent scaler-prefixed name).
• grep -rn 'logging\.\(info\|warning\|error\|exception\|debug\)(' <adapter> returns zero matches.
• No setup_logger call remains in adapter code.
• No self._logging_paths / _logging_level / _logging_config_file field storage in adapter classes.
• Running the adapter under scaler_all produces log lines whose process-name prefix matches the configured _tag.

What NOT to change

• Do NOT change logging.INFO, logging.WARNING, etc. constants — only the method calls.
• Do NOT rename the logger variable — stick to this convention for grep-ability.
• Do NOT attach handlers to your adapter's logger manually. The scaler
  logger already has them; propagation handles the rest.
• Do NOT set logger.propagate = False on the adapter's logger. You want
  it to propagate up to the scaler parent logger.

[sharpener6]

__name__ will varies based on different name, are you sure they will use same named logger "scaler" every time?

I think better solution to getLogger each time is define the logger as module variable in utility, then import it

e.g.:

from scaler.utility.logging.logger import logger

logger.info()

[magniloquency]

I think __name__ is the name of the current module, so logging calls from processor.py will use the name processor for example

[gxuu]

@sharpener6,

@magniloquency is right. We want to print out components' name:

2026-04-20 09:13:34+0800 INFO scheduler[2340581]: VanillaInformationController: exited
2026-04-20 09:13:34+0800 INFO object_storage_server[2340577]: ObjectStorageServer: stopped by user

[sharpener6]

This to be honest, I would like that logger to have some process_name passing to setup_logger, to show it's scheduler or object_storage_server, like

setup_logger(process_name="scheduler", logging_level=...)

all files that have logger = logging.getLogger(__name__) is not very elegant

[gxuu]

• The existing implementation follows what official document recommends.
• setup_logger is called for each process already and it must be called only once. This, and getLogger are orthogonal.