mirror of https://github.com/istio/istio.io.git
Document our logging framework and ControlZ. (#2000)
This commit is contained in:
parent
3b3c43eb0b
commit
d055fac156
|
|
@ -5,4 +5,67 @@ weight: 10
|
|||
keywords: [ops]
|
||||
---
|
||||
|
||||
Logging is good.
|
||||
Istio components are built with a flexible logging framework which provides a number of features and controls to
|
||||
help operate these components and facilitate diagnostics. You control these logging features by passing
|
||||
command-line options when starting the components.
|
||||
|
||||
## Logging scopes
|
||||
|
||||
Logging messages output by a component are categorized by *scopes*. A scope represents a set of related log messages which
|
||||
you can control as a whole. Different components have different scopes, depending on the features the component
|
||||
provides. All components have the `default` scope, which is used for non-categorized log messages.
|
||||
|
||||
As an example, as of this writing, Mixer has 5 scopes, representing different functional areas within Mixer:
|
||||
|
||||
- `adapters`
|
||||
- `api`
|
||||
- `attributes`
|
||||
- `default`
|
||||
- `grpcAdapter`
|
||||
|
||||
Pilot, Citadel, and Galley have their own scopes which you can discover by looking at their [reference documentation](/docs/reference/commands/).
|
||||
|
||||
Each scope has a unique output level which is one of:
|
||||
|
||||
1. none
|
||||
1. error
|
||||
1. warning
|
||||
1. info
|
||||
1. debug
|
||||
|
||||
where `none` produces no output for the scope, and `debug` produces the maximum amount of output. The default level for all scopes
|
||||
is `info` which is intended to provide the right amount of logging information for operating Istio in normal conditions.
|
||||
|
||||
To control the output level, you use the `--log_output_level` command-line option. For example:
|
||||
|
||||
{{< text bash >}}
|
||||
$ mixs server --log_output_level attributes=debug,adapters=warning
|
||||
{{< /text >}}
|
||||
|
||||
In addition to controlling the output level from the command-line, you can also control the output level of a running component
|
||||
by using its [ControlZ](/help/ops/controlz) interface.
|
||||
|
||||
## Controlling output
|
||||
|
||||
Log messages are normally sent to a component's standard output stream. The `--log_target` option lets you direct the output to
|
||||
any number of different locations. You give the option a comma-separated list of file system paths, along with the special
|
||||
values `stdout` and `stderr` to indicate the standard output and standard error streams respectively.
|
||||
|
||||
Log messages are normally output in a human-friendly format. The `--log_as_json` option can be used to force the output into JSON,
|
||||
which can be easier for tools to process.
|
||||
|
||||
## Log rotation
|
||||
|
||||
Istio components can automatically manage log rotation, which make it simple to break up large logs into smaller log files.
|
||||
The `--log_rotate` option lets you specify the base file name to use for rotation. Derived names will be used for individual
|
||||
log files.
|
||||
|
||||
The `--log_rotate_max_age` option lets you specify the maximum number of days before file rotation takes place, while the `--log_rotate_max_size` option
|
||||
let you specify the maximum size in megabytes before file rotation takes place. Finally, the `--log_rotate_max_backups` option lets you control
|
||||
the maximum number of rotated files to keep, older files will be automatically deleted.
|
||||
|
||||
## Component debugging
|
||||
|
||||
The `--log_caller` and `--log_stacktrace_level` options let you control whether log information includes
|
||||
programmer-level information. This is useful when trying to track down bugs in a component but is not
|
||||
normally used in day-to-day operation.
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 499 KiB |
|
|
@ -5,4 +5,23 @@ weight: 20
|
|||
keywords: [ops]
|
||||
---
|
||||
|
||||
ControlZ is good.
|
||||
Istio components are built with a flexible introspection framework which makes it easy to inspect and manipulate the internal state
|
||||
of a running component. Components open a port which can be used from a web browser to get an interactive view into the state of the
|
||||
component, or via REST for access and control from external tools.
|
||||
|
||||
Mixer, Pilot, and Galley all implement the ControlZ functionality. When these components start, a message is logged indicating the
|
||||
IP address and port to connect to in order to interact with ControlZ.
|
||||
|
||||
{{< text plain >}}
|
||||
2018-07-26T23:28:48.889370Z info ControlZ available at 100.76.122.230:9876
|
||||
{{< /text >}}
|
||||
|
||||
Here's sample of the ControlZ interface:
|
||||
|
||||
{{< image width="80%" ratio="47.52%"
|
||||
link="./ctrlz.png"
|
||||
caption="ControlZ User Interface"
|
||||
>}}
|
||||
|
||||
The `--ctrlz_port` and `--ctrlz_address` command-line options can be given when starting a component to control the
|
||||
specific address and port where ControlZ should be exposed.
|
||||
|
|
|
|||
Loading…
Reference in New Issue