~rogpeppe/juju-core/themue-058-debug-log-api

« back to all changes in this revision

Viewing changes to cmd/juju/help_topics.go

  • Committer: Frank Mueller
  • Date: 2014-01-23 14:14:49 UTC
  • mfrom: (2152.1.95 juju-core)
  • Revision ID: frank.mueller@canonical.com-20140123141449-b30l57y7gs3wjkpw
debugger: merged trunk and fixed permission and interface problems

Show diffs side-by-side

added added

removed removed

Lines of Context:
421
421
  Software which manages all the lifecycle of a single Service Unit.
422
422
 
423
423
`
 
424
 
 
425
const helpLogging = `
 
426
Juju  has logging available for both client and server components. Most
 
427
users' exposure to the logging mechanism is through either the 'debug-log'
 
428
command, or through the log file stored on the bootstrap node at
 
429
/var/log/juju/all-machines.log.
 
430
 
 
431
All the agents have their own log files on the individual machines. So
 
432
for the bootstrap node, there is the machine agent log file at
 
433
/var/log/juju/machine-0.log.  When a unit is deployed on a machine,
 
434
a unit agent is started. This agent also logs to /var/log/juju and the
 
435
name of the log file is based on the id of the unit, so for wordpress/0
 
436
the log file is unit-wordpress-0.log.
 
437
 
 
438
Juju uses rsyslog to forward the content of all the log files on the machine
 
439
back to the bootstrap node, and they are accumulated into the all-machines.log
 
440
file.  Each line is prefixed with the source agent tag (also the same as
 
441
the filename without the extension).
 
442
 
 
443
Juju has a hierarchical logging system internally, and as a user you can
 
444
control how much information is logged out.
 
445
 
 
446
Output from the charm hook execution comes under the log name "unit".
 
447
By default Juju makes sure that this information is logged out at
 
448
the DEBUG level.  If you explicitly specify a value for unit, then
 
449
this is used instead.
 
450
 
 
451
Juju internal logging comes under the log name "juju".  Different areas
 
452
of the codebase have different anmes. For example:
 
453
  providers are under juju.provider
 
454
  workers are under juju.worker
 
455
  database parts are under juju.state
 
456
 
 
457
All the agents are started with all logging set to DEBUG. Which means you
 
458
see all the internal juju logging statements until the logging worker starts
 
459
and updates the logging configuration to be what is stored for the environment.
 
460
 
 
461
You can set the logging levels using a number of different mechanisms.
 
462
 
 
463
environments.yaml
 
464
 - all environments support 'logging-config' as a key
 
465
 - logging-config: ...
 
466
environment variable
 
467
 - export JUJU_LOGGING_CONFIG='...'
 
468
setting the logging-config at bootstrap time
 
469
 - juju bootstrap --logging-config='...'
 
470
juju set-environment logging-config='...'
 
471
 
 
472
Configuration values are separated by semicolons.
 
473
 
 
474
Examples:
 
475
 
 
476
  juju set-environment logging-config "juju=WARNING; unit=INFO"
 
477
 
 
478
Developers may well like:
 
479
 
 
480
  export JUJU_LOGGING_CONFIG='juju=INFO; juju.current.work.area=TRACE'
 
481
 
 
482
Valid logging levels:
 
483
  CRITICAL
 
484
  ERROR
 
485
  WARNING
 
486
  INFO
 
487
  DEBUG
 
488
  TRACE
 
489
`