Project: Vector (Observability and Analysis / Observability)
File: monitoring.md

title: Monitoring and observing Vector description: Use logs and metrics generated by Vector itself in your Vector topology short: Monitoring weight: 2 tags: ["admin", "logs", "metrics"] Although Vector is primarily used to handle observability data from a wide variety of sources, we also strive to make Vector highly observable itself. To that end, Vector provides two and , that you can use to handle logs and metrics produced by Vector just like you would logs and metrics from any other source. Vector provides clear, informative, well-structured logs via the source. This section shows you how to use them in your Vector topology. Which logs Vector pipes through the `internal_logs` source is determined by the , which defaults to `info`. In addition to the `internal_logs` source, Vector also writes its logs to , which can be captured by Kubernetes, SystemD, or however you are running Vector. You can access Vector's logs by adding an source to your [topology]. Here's an example configuration that takes Vector's logs and pipes them to the console as plain text: ```toml [sources.vector_logs] type = "internal_logs" [sinks.console] type = "console" inputs = ["vector_logs"] encoding.codec = "text" ``` Once Vector logs enter your topology through the `internal_logs` source, you can treat them like logs from any other system, i.e. you can [transform] them and send them off to any number of [sinks]. The configuration below, for example, transforms Vector's logs using the and and then stores those logs in [ClickHouse]: ```toml [sources.vector_logs] type = "internal_logs" [transforms.modify] type = "remap" inputs = ["vector_logs"] source = ''' .timestamp = tounixtimestamp!(to_timestamp!(.timestamp)) ''' [sinks.database] type = "clickhouse" inputs = ["modify"] host = "http://localhost:8123" table = "vector-log-data" ``` Vector logs at the `info` level by default. You can set a different level when [starting] up your instance using either command-line flags or the `VECTOR_LOG` environment variable. The table below details these options: Method | Description :|:-- `-v` flag | Drops the log level to `debug` `-vv` flag | Drops the log level to `trace` `-q` flag | Raises the log level to `warn` `-qq` flag | Raises the log level to `error` `-qqq` flag | Disables logging `VECTOR_LOG=<level>` environment variable | Set the log level. Must be one of `trace`, `debug`, `info`, `warn`, `error`, `off`. You can enable full error backtraces by setting the `RUST_BACKTRACE=full` environment variable. More on this in the . You can monitor metrics produced by Vector using the source. As with Vector's , you can configure an `internal_metrics` source and use the piped-in metrics however you wish. Here's an example configuration that delivers Vector's metrics to a Prometheus remote write endpoint. ```toml [sources.vector_metrics] type = "internal_metrics" [sinks.prometheus] type = ["prometheusremotewrite"] endpoint = ["https://localhost:8087/"] inputs = ["vector_metrics"] ``` The table below provides a list of internal metrics provided by Vector. See the docs for the [`internal_metrics` source][output] for more detailed information about the available metrics. {{< internal-metrics-list >}} More information in our troubleshooting guide: {{< jump "/guides/level-up/troubleshooting" >}} Vector employs an event-driven observability strategy that ensures consistent and correlated telemetry data. You can read more about our approach in . Vector rate limits log events in the hot path. This enables you to get granular insight without the risk of saturating IO and disrupting the service. The trade-off is that repetitive logs aren't logged.