Logging Instead of Print: Structured, Secret-Safe Output

print() doesn't scale past one file

Every capstone's print() calls worked because there was one file, run once, watched by one person. Once code is split across modules (Lesson 2) and possibly run concurrently (Lesson 7), print() has no levels, no timestamps, and no way to tell which module a message came from.

network_automation/logging_config.py

import logging

def configure_logging(level=logging.INFO):
  logging.basicConfig(
      level=level,
      format="%(asctime)s %(levelname)s %(name)s: %(message)s",
  )

def get_logger(name):
  return logging.getLogger(name)

configure_logging() is called once, at startup. get_logger(__name__) gives each module its own named logger -- %(name)s in the format string is what makes the source of each message visible.

Quick checkConcept check

What does print() lack that becomes a real problem once code is split across multiple modules?

print() can't output stringsLevels (info vs warning vs error), timestamps, and a way to tell which module produced a given messageprint() is slower than loggingprint() only works in one file at a time

Real output, from real code

using it in automation.py

from network_automation.logging_config import get_logger

logger = get_logger(__name__)

def check_device(connection, device):
  hostname = device.hostname
  try:
      actual_vlans = get_state_with_retry(connection, hostname)
  except DeviceUnreachableError as e:
      logger.warning(f"{hostname}: unreachable ({e})")
      return AutomationResult(hostname=hostname, status=Status.UNREACHABLE, detail=str(e))
  # ...
  logger.info(f"{hostname}: already compliant")
  return AutomationResult(hostname=hostname, status=Status.ALREADY_COMPLIANT, detail="no change needed")

logger.info() for the normal case, logger.warning() for a device-level failure that isn't a bug — the same expected-failure-vs-real-bug distinction from Lesson 3, now reflected in which level gets used.

output — real run against all 5 devices

2026-08-26 13:00:20,139 INFO network_automation.automation: SW1: already compliant
2026-08-26 13:00:20,447 INFO network_automation.automation: SW2: missing VLANs [10]
2026-08-26 13:00:21,573 INFO network_automation.automation: SW3: missing VLANs [30]
2026-08-26 13:00:28,612 WARNING network_automation.automation: SW4: unreachable (SW4 timed out)
2026-08-26 13:00:28,919 WARNING network_automation.automation: SW5: authentication failed (SW5 rejected the credentials)

Real, verified output. Every line carries a timestamp, a level, and network_automation.automation as the source — %(name)s reflecting get_logger(__name__) exactly.

Quick checkIdentify the correct code

Which level is correct for logging that SW4 is unreachable — a real, expected operational failure, not a bug?

logger.debug()logger.info()logger.warning()logger.critical()

Quick checkPredict output

Given the format string "%(asctime)s %(levelname)s %(name)s: %(message)s", what does %(name)s resolve to for a log call made from automation.py via get_logger(__name__)?

"automation.py""network_automation.automation" — the module's dotted import path, exactly as verified above"AutomationResult"The hostname being checked

What must never appear in a log line

A token in a log file is a leaked credential

It's tempting to log a request for debugging, headers and all. Don't. A log file is often kept longer, read by more people, and stored less carefully than the code itself — logging an Authorization header is functionally the same mistake as hardcoding the credential in source, the rule every module since Netmiko Fundamentals has held. This module's own logger.info()/logger.warning() calls above log hostnames and statuses only — never a token, never a password.

Quick checkMyth check

Is it acceptable to log the full request, including the Authorization header, when debugging a connection issue?

Yes — logs are private, so it's safeNo — a token in a log line is a leaked credential, exactly like hardcoding it in source; log the hostname and status, never the headerYes, but only at debug levelNo, but only in production, not during development

Key takeaways

print() lacks levels, timestamps, and a source module — all real problems once code is split across files (Lesson 2) or run concurrently (Lesson 7).
configure_logging() runs once at startup; get_logger(__name__) gives each module its own named logger.
logger.info() for the normal/expected case, logger.warning() for an operational failure — verified directly against all 5 devices' real output.
A token or password must never appear in a log line — the same no-hardcoded-credentials rule since Netmiko Fundamentals, applied to logging output specifically.

What you'll learn

print() doesn't scale past one file

Real output, from real code

What must never appear in a log line