github.com/mattyr/nomad@v0.3.3-0.20160919021406-3485a065154a/website/source/docs/jobops/logs.html.md (about)

     1  ---
     2  layout: "docs"
     3  page_title: "Operating a Job: Accessing Logs"
     4  sidebar_current: "docs-jobops-logs"
     5  description: |-
     6    Learn how to operate a Nomad Job.
     7  ---
     8  
     9  # Accessing Logs
    10  
    11  Accessing applications logs is critical when debugging issues, performance
    12  problems or even for verifying the application is starting correctly. To make
    13  this as simple as possible, Nomad provides [log
    14  rotation](/docs/jobspec/index.html#log_rotation) in the jobspec, provides a [CLI
    15  command](/docs/commands/logs.html) and an [API](/docs/http/client-fs.html#logs)
    16  for accessing application logs and data files.
    17  
    18  To see this in action we can just run the example job which created using `nomad
    19  init`:
    20  
    21  ```
    22  $ nomad init
    23  Example job file written to example.nomad
    24  ```
    25  
    26  This job will start a redis instance in a Docker container. We can run it now:
    27  
    28  ```
    29  $ nomad run example.nomad
    30  ==> Monitoring evaluation "7a3b78c0"
    31      Evaluation triggered by job "example"
    32      Allocation "c3c58508" created: node "b5320e2d", group "cache"
    33      Evaluation status changed: "pending" -> "complete"
    34  ==> Evaluation "7a3b78c0" finished with status "complete"
    35  ```
    36  
    37  We can grab the allocation ID from above and use the [`nomad logs`
    38  command](/docs/commands/logs.html) to access the applications logs. The `logs`
    39  command supports both displaying the logs as well as following logs, blocking
    40  for more output. 
    41  
    42  Thus to access the `stdout` we can issue the below command:
    43  
    44  ```
    45  $ nomad logs c3c58508 redis
    46                   _._
    47              _.-``__ ''-._
    48         _.-``    `.  `_.  ''-._           Redis 3.2.1 (00000000/0) 64 bit
    49     .-`` .-```.  ```\/    _.,_ ''-._
    50    (    '      ,       .-`  | `,    )     Running in standalone mode
    51    |`-._`-...-` __...-.``-._|'` _.-'|     Port: 6379
    52    |    `-._   `._    /     _.-'    |     PID: 1
    53     `-._    `-._  `-./  _.-'    _.-'
    54    |`-._`-._    `-.__.-'    _.-'_.-'|
    55    |    `-._`-._        _.-'_.-'    |           http://redis.io
    56     `-._    `-._`-.__.-'_.-'    _.-'
    57    |`-._`-._    `-.__.-'    _.-'_.-'|
    58    |    `-._`-._        _.-'_.-'    |
    59     `-._    `-._`-.__.-'_.-'    _.-'
    60         `-._    `-.__.-'    _.-'
    61             `-._        _.-'
    62                 `-.__.-'
    63  
    64   1:M 28 Jun 19:49:30.504 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
    65   1:M 28 Jun 19:49:30.505 # Server started, Redis version 3.2.1
    66   1:M 28 Jun 19:49:30.505 # WARNING overcommit_memory is set to 0! Background save may fail under low memory condition. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
    67   1:M 28 Jun 19:49:30.505 # WARNING you have Transparent Huge Pages (THP) support enabled in your kernel. This will create latency and memory usage issues with Redis. To fix this issue run the command 'echo never > /sys/kernel/mm/transparent_hugepage/enabled' as root, and add it to your /etc/rc.local in order to retain the setting after a reboot. Redis must be restarted after THP is disabled.
    68   1:M 28 Jun 19:49:30.505 * The server is now ready to accept connections on port 6379
    69  ```
    70  
    71  To display the `stderr` for the task we would run the following: 
    72  
    73  ```
    74  $ nomad logs -stderr c3c58508 redis
    75  ```
    76  
    77  While this works well for quickly accessing logs, we recommend running a
    78  log-shipper for long term storage of logs. In many cases this will not be needed
    79  and the above will suffice but for use cases in which log retention is needed
    80  Nomad can accommodate.
    81  
    82  Since we place application logs inside the `alloc/` directory, all tasks within
    83  the same task group have access to each others logs. Thus we can have a task
    84  group as follows:
    85  
    86  ```
    87  group "my-group" {
    88      task "log-producer" {...}
    89      task "log-shipper" {...}
    90  }
    91  ```
    92  
    93  In the above example, the `log-producer` task is the application that should be
    94  run and will be producing the logs we would like to ship and the `log-shipper`
    95  reads these logs from the `alloc/logs/` directory and ships them to a long term
    96  storage such as S3.