open-telemetry
/
opentelemetry.io
mirror of https://github.com/open-telemetry/opentelemetry.io.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
opentelemetry.io/content/en/docs/kubernetes/collector/components.md

806 lines
32 KiB
Markdown
Raw Blame History

---
title: Important Components for Kubernetes
linkTitle: Components
# prettier-ignore
cSpell:ignore: alertmanagers containerd crio filelog gotime horizontalpodautoscalers hostfs hostmetrics iostream k8sattributes kubelet kubeletstats logtag replicasets replicationcontrollers resourcequotas statefulsets varlibdockercontainers varlogpods
---
The [OpenTelemetry Collector](/docs/collector/) supports many different
receivers and processors to facilitate monitoring Kubernetes. This section
covers the components that are most important for collecting Kubernetes data and
enhancing it.
Components covered in this page:
- [Kubernetes Attributes Processor](#kubernetes-attributes-processor): adds
Kubernetes metadata to incoming application telemetry.
- [Kubeletstats Receiver](#kubeletstats-receiver): pulls node, pod, and
container metrics from the API server on a kubelet.
- [Filelog Receiver](#filelog-receiver): collects Kubernetes logs and
application logs written to stdout/stderr.
- [Kubernetes Cluster Receiver](#kubernetes-cluster-receiver): collects
cluster-level metrics and entity events.
- [Kubernetes Objects Receiver](#kubernetes-objects-receiver): collects objects,
such as events, from the Kubernetes API server.
- [Prometheus Receiver](#prometheus-receiver): receives metrics in
[Prometheus](https://prometheus.io/) format.
- [Host Metrics Receiver](#host-metrics-receiver): scrapes host metrics from
Kubernetes nodes.
For application traces, metrics, or logs, we recommend the
[OTLP receiver](https://github.com/open-telemetry/opentelemetry-collector/tree/main/receiver/otlpreceiver),
but any receiver that fits your data is appropriate.
## Kubernetes Attributes Processor
| Deployment Pattern | Usable |
| -------------------- | ------ |
| DaemonSet (agent) | Yes |
| Deployment (gateway) | Yes |
| Sidecar | No |
The Kubernetes Attributes Processor automatically discovers Kubernetes pods,
extracts their metadata, and adds the extracted metadata to spans, metrics, and
logs as resource attributes.
**The Kubernetes Attributes Processor is one of the most important components
for a collector running in Kubernetes. Any collector receiving application data
should use it.** Because it adds Kubernetes context to your telemetry, the
Kubernetes Attributes Processor lets you correlate your application's traces,
metrics, and logs signals with your Kubernetes telemetry, such as pod metrics
and traces.
The Kubernetes Attributes Processor uses the Kubernetes API to discover all pods
running in a cluster and keeps a record of their IP addresses, pod UIDs, and
interesting metadata. By default, data passing through the processor is
associated to a pod via the incoming request's IP address, but different rules
can be configured. Since the processor uses the Kubernetes API, it requires
special permissions (see example below). If you're using the
[OpenTelemetry Collector Helm chart](../../helm/collector/) you can use the
[`kubernetesAttributes` preset](../../helm/collector/#kubernetes-attributes-preset)
to get started.
The following attributes are added by default:
- `k8s.namespace.name`
- `k8s.pod.name`
- `k8s.pod.uid`
- `k8s.pod.start_time`
- `k8s.deployment.name`
- `k8s.node.name`
The Kubernetes Attributes Processor can also set custom resource attributes for
traces, metrics, and logs using the Kubernetes labels and Kubernetes annotations
you've added to your pods and namespaces.
```yaml
k8sattributes:
auth_type: 'serviceAccount'
extract:
metadata: # extracted from the pod
- k8s.namespace.name
- k8s.pod.name
- k8s.pod.start_time
- k8s.pod.uid
- k8s.deployment.name
- k8s.node.name
annotations:
# Extracts the value of a pod annotation with key `annotation-one` and inserts it as a resource attribute with key `a1`
- tag_name: a1
key: annotation-one
from: pod
# Extracts the value of a namespaces annotation with key `annotation-two` with regexp and inserts it as a resource with key `a2`
- tag_name: a2
key: annotation-two
regex: field=(?P<value>.+)
from: namespace
labels:
# Extracts the value of a namespaces label with key `label1` and inserts it as a resource attribute with key `l1`
- tag_name: l1
key: label1
from: namespace
# Extracts the value of a pod label with key `label2` with regexp and inserts it as a resource attribute with key `l2`
- tag_name: l2
key: label2
regex: field=(?P<value>.+)
from: pod
pod_association: # How to associate the data to a pod (order matters)
- sources: # First try to use the value of the resource attribute k8s.pod.ip
- from: resource_attribute
name: k8s.pod.ip
- sources: # Then try to use the value of the resource attribute k8s.pod.uid
- from: resource_attribute
name: k8s.pod.uid
- sources: # If neither of those work, use the request's connection to get the pod IP.
- from: connection
```
There are also special configuration options for when the collector is deployed
as a Kubernetes DaemonSet (agent) or as a Kubernetes Deployment (gateway). For
details, see
[Deployment Scenarios](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/k8sattributesprocessor#deployment-scenarios)
For Kubernetes Attributes Processor configuration details, see
[Kubernetes Attributes Processor](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/processor/k8sattributesprocessor).
Since the processor uses the Kubernetes API, it needs the correct permission to
work correctly. For most use cases, you should give the service account running
the collector the following permissions via a ClusterRole.
```yaml
apiVersion: v1
kind: ServiceAccount
metadata:
name: collector
namespace: <OTEL_COL_NAMESPACE>
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: otel-collector
rules:
- apiGroups:
- ''
resources:
- 'pods'
- 'namespaces'
verbs:
- 'get'
- 'watch'
- 'list'
- apiGroups:
- 'apps'
resources:
- 'replicasets'
verbs:
- 'get'
- 'list'
- 'watch'
- apiGroups:
- 'extensions'
resources:
- 'replicasets'
verbs:
- 'get'
- 'list'
- 'watch'
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: otel-collector
subjects:
- kind: ServiceAccount
name: collector
namespace: <OTEL_COL_NAMESPACE>
roleRef:
kind: ClusterRole
name: otel-collector
apiGroup: rbac.authorization.k8s.io
```
## Kubeletstats Receiver
| Deployment Pattern | Usable |
| -------------------- | ------------------------------------------------------------------ |
| DaemonSet (agent) | Preferred |
| Deployment (gateway) | Yes, but will only collect metrics from the node it is deployed on |
| Sidecar | No |
Each Kubernetes node runs a kubelet that includes an API server. The Kubernetes
Receiver connects to that kubelet via the API server to collect metrics about
the node and the workloads running on the node.
There are different methods for authentication, but typically a service account
is used. The service account will also need proper permissions to pull data from
the Kubelet (see below). If you're using the
[OpenTelemetry Collector Helm chart](../../helm/collector/) you can use the
[`kubeletMetrics` preset](../../helm/collector/#kubelet-metrics-preset) to get
started.
By default, metrics will be collected for pods and nodes, but you can configure
the receiver to collect container and volume metrics as well. The receiver also
allows configuring how often the metrics are collected:
```yaml
receivers:
kubeletstats:
collection_interval: 10s
auth_type: 'serviceAccount'
endpoint: '${env:K8S_NODE_NAME}:10250'
insecure_skip_verify: true
metric_groups:
- node
- pod
- container
```
For specific details about which metrics are collected, see
[Default Metrics](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/receiver/kubeletstatsreceiver/documentation.md).
For specific configuration details, see
[Kubeletstats Receiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/receiver/kubeletstatsreceiver).
Since the processor uses the Kubernetes API, it needs the correct permission to
work correctly. For most use cases, you should give the service account running
the Collector the following permissions via a ClusterRole.
```yaml
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: otel-collector
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: otel-collector
rules:
- apiGroups: ['']
resources: ['nodes/stats']
verbs: ['get', 'watch', 'list']
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: otel-collector
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: otel-collector
subjects:
- kind: ServiceAccount
name: otel-collector
namespace: default
```
## Filelog Receiver
| Deployment Pattern | Usable |
| -------------------- | --------------------------------------------------------------- |
| DaemonSet (agent) | Preferred |
| Deployment (gateway) | Yes, but will only collect logs from the node it is deployed on |
| Sidecar | Yes, but this would be considered advanced configuration |
The Filelog Receiver tails and parses logs from files. Although it's not a
Kubernetes-specific receiver, it is still the de facto solution for collecting
any logs from Kubernetes.
The Filelog Receiver is composed of Operators that are chained together to
process a log. Each Operator performs a simple responsibility, such as parsing a
timestamp or JSON. Configuring a Filelog Receiver is not trivial. If you're
using the [OpenTelemetry Collector Helm chart](../../helm/collector/) you can
use the [`logsCollection` preset](../../helm/collector/#logs-collection-preset)
to get started.
Since Kubernetes logs normally fit a set of standard formats, a typical Filelog
Receiver configuration for Kubernetes looks like:
```yaml
filelog:
include:
- /var/log/pods/*/*/*.log
exclude:
# Exclude logs from all containers named otel-collector
- /var/log/pods/*/otel-collector/*.log
start_at: beginning
include_file_path: true
include_file_name: false
operators:
# Find out which format is used by kubernetes
- type: router
id: get-format
routes:
- output: parser-docker
expr: 'body matches "^\\{"'
- output: parser-crio
expr: 'body matches "^[^ Z]+ "'
- output: parser-containerd
expr: 'body matches "^[^ Z]+Z"'
# Parse CRI-O format
- type: regex_parser
id: parser-crio
regex:
'^(?P<time>[^ Z]+) (?P<stream>stdout|stderr) (?P<logtag>[^ ]*)
?(?P<log>.*)$'
output: extract_metadata_from_filepath
timestamp:
parse_from: attributes.time
layout_type: gotime
layout: '2006-01-02T15:04:05.999999999Z07:00'
# Parse CRI-Containerd format
- type: regex_parser
id: parser-containerd
regex:
'^(?P<time>[^ ^Z]+Z) (?P<stream>stdout|stderr) (?P<logtag>[^ ]*)
?(?P<log>.*)$'
output: extract_metadata_from_filepath
timestamp:
parse_from: attributes.time
layout: '%Y-%m-%dT%H:%M:%S.%LZ'
# Parse Docker format
- type: json_parser
id: parser-docker
output: extract_metadata_from_filepath
timestamp:
parse_from: attributes.time
layout: '%Y-%m-%dT%H:%M:%S.%LZ'
- type: move
from: attributes.log
to: body
# Extract metadata from file path
- type: regex_parser
id: extract_metadata_from_filepath
regex: '^.*\/(?P<namespace>[^_]+)_(?P<pod_name>[^_]+)_(?P<uid>[a-f0-9\-]{36})\/(?P<container_name>[^\._]+)\/(?P<restart_count>\d+)\.log$'
parse_from: attributes["log.file.path"]
cache:
size: 128 # default maximum amount of Pods per Node is 110
# Rename attributes
- type: move
from: attributes.stream
to: attributes["log.iostream"]
- type: move
from: attributes.container_name
to: resource["k8s.container.name"]
- type: move
from: attributes.namespace
to: resource["k8s.namespace.name"]
- type: move
from: attributes.pod_name
to: resource["k8s.pod.name"]
- type: move
from: attributes.restart_count
to: resource["k8s.container.restart_count"]
- type: move
from: attributes.uid
to: resource["k8s.pod.uid"]
```
For Filelog Receiver configuration details, see
[Filelog Receiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/filelogreceiver).
In addition to the Filelog Receiver configuration, your OpenTelemetry Collector
installation in Kubernetes will need access to the logs it wants to collect.
Typically this means adding some volumes and volumeMounts to your collector
manifest:
```yaml
---
apiVersion: apps/v1
kind: DaemonSet
...
spec:
...
template:
...
spec:
...
containers:
- name: opentelemetry-collector
...
volumeMounts:
...
# Mount the volumes to the collector container
- name: varlogpods
mountPath: /var/log/pods
readOnly: true
- name: varlibdockercontainers
mountPath: /var/lib/docker/containers
readOnly: true
...
volumes:
...
# Typically the collector will want access to pod logs and container logs
- name: varlogpods
hostPath:
path: /var/log/pods
- name: varlibdockercontainers
hostPath:
path: /var/lib/docker/containers
...
```
## Kubernetes Cluster Receiver
| Deployment Pattern | Usable |
| -------------------- | -------------------------------------------------------- |
| DaemonSet (agent) | Yes, but will result in duplicate data |
| Deployment (gateway) | Yes, but more than one replica results in duplicate data |
| Sidecar | No |
The Kubernetes Cluster Receiver collects metrics and entity events about the
cluster as a whole using the Kubernetes API server. Use this receiver to answer
questions about pod phases, node conditions, and other cluster-wide questions.
Since the receiver gathers telemetry for the cluster as a whole, only one
instance of the receiver is needed across the cluster in order to collect all
the data.
There are different methods for authentication, but typically a service account
is used. The service account also needs proper permissions to pull data from the
Kubernetes API server (see below). If you're using the
[OpenTelemetry Collector Helm chart](../../helm/collector/) you can use the
[`clusterMetrics` preset](../../helm/collector/#cluster-metrics-preset) to get
started.
For node conditions, the receiver only collects `Ready` by default, but it can
be configured to collect more. The receiver can also be configured to report a
set of allocatable resources, such as `cpu` and `memory`:
```yaml
k8s_cluster:
auth_type: serviceAccount
node_conditions_to_report:
- Ready
- MemoryPressure
allocatable_types_to_report:
- cpu
- memory
```
To learn more about the metrics that are collected, see
[Default Metrics](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/receiver/k8sclusterreceiver/documentation.md)
For configuration details, see
[Kubernetes Cluster Receiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/k8sclusterreceiver).
Since the processor uses the Kubernetes API, it needs the correct permission to
work correctly. For most use cases, you should give the service account running
the Collector the following permissions via a ClusterRole.
```yaml
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: otel-collector-opentelemetry-collector
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: otel-collector-opentelemetry-collector
rules:
- apiGroups:
- ''
resources:
- events
- namespaces
- namespaces/status
- nodes
- nodes/spec
- pods
- pods/status
- replicationcontrollers
- replicationcontrollers/status
- resourcequotas
- services
verbs:
- get
- list
- watch
- apiGroups:
- apps
resources:
- daemonsets
- deployments
- replicasets
- statefulsets
verbs:
- get
- list
- watch
- apiGroups:
- extensions
resources:
- daemonsets
- deployments
- replicasets
verbs:
- get
- list
- watch
- apiGroups:
- batch
resources:
- jobs
- cronjobs
verbs:
- get
- list
- watch
- apiGroups:
- autoscaling
resources:
- horizontalpodautoscalers
verbs:
- get
- list
- watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: otel-collector-opentelemetry-collector
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: otel-collector-opentelemetry-collector
subjects:
- kind: ServiceAccount
name: otel-collector-opentelemetry-collector
namespace: default
```
## Kubernetes Objects Receiver
| Deployment Pattern | Usable |
| -------------------- | -------------------------------------------------------- |
| DaemonSet (agent) | Yes, but will result in duplicate data |
| Deployment (gateway) | Yes, but more than one replica results in duplicate data |
| Sidecar | No |
The Kubernetes Objects receiver collects, either by pulling or watching, objects
from the Kubernetes API server. The most common use case for this receiver is
watching Kubernetes events, but it can be used to collect any type of Kubernetes
object. Since the receiver gathers telemetry for the cluster as a whole, only
one instance of the receiver is needed across the cluster in order to collect
all the data.
Currently only a service account can be used for authentication. The service
account also needs proper permissions to pull data from the Kubernetes API
server (see below). If you're using the
[OpenTelemetry Collector Helm chart](../../helm/collector/) and you want to
ingest events, you can use the
[`kubernetesEvents` preset](../../helm/collector/#cluster-metrics-preset) to get
started.
For objects configuring for pulling, the receiver will use the Kubernetes API to
periodically list all the objects in the Cluster. Each object will be converted
to its own log. For objects configured for watching, the receiver creates a a
stream with the Kubernetes API and which receives updates as the objects change.
To see which objects are available for collection run in your cluster run
`kubectl api-resources`:
<!-- cspell:disable -->
```console
kubeclt api-resources
NAME SHORTNAMES APIVERSION NAMESPACED KIND
bindings v1 true Binding
componentstatuses cs v1 false ComponentStatus
configmaps cm v1 true ConfigMap
endpoints ep v1 true Endpoints
events ev v1 true Event
limitranges limits v1 true LimitRange
namespaces ns v1 false Namespace
nodes no v1 false Node
persistentvolumeclaims pvc v1 true PersistentVolumeClaim
persistentvolumes pv v1 false PersistentVolume
pods po v1 true Pod
podtemplates v1 true PodTemplate
replicationcontrollers rc v1 true ReplicationController
resourcequotas quota v1 true ResourceQuota
secrets v1 true Secret
serviceaccounts sa v1 true ServiceAccount
services svc v1 true Service
mutatingwebhookconfigurations admissionregistration.k8s.io/v1 false MutatingWebhookConfiguration
validatingwebhookconfigurations admissionregistration.k8s.io/v1 false ValidatingWebhookConfiguration
customresourcedefinitions crd,crds apiextensions.k8s.io/v1 false CustomResourceDefinition
apiservices apiregistration.k8s.io/v1 false APIService
controllerrevisions apps/v1 true ControllerRevision
daemonsets ds apps/v1 true DaemonSet
deployments deploy apps/v1 true Deployment
replicasets rs apps/v1 true ReplicaSet
statefulsets sts apps/v1 true StatefulSet
tokenreviews authentication.k8s.io/v1 false TokenReview
localsubjectaccessreviews authorization.k8s.io/v1 true LocalSubjectAccessReview
selfsubjectaccessreviews authorization.k8s.io/v1 false SelfSubjectAccessReview
selfsubjectrulesreviews authorization.k8s.io/v1 false SelfSubjectRulesReview
subjectaccessreviews authorization.k8s.io/v1 false SubjectAccessReview
horizontalpodautoscalers hpa autoscaling/v2 true HorizontalPodAutoscaler
cronjobs cj batch/v1 true CronJob
jobs batch/v1 true Job
certificatesigningrequests csr certificates.k8s.io/v1 false CertificateSigningRequest
leases coordination.k8s.io/v1 true Lease
endpointslices discovery.k8s.io/v1 true EndpointSlice
events ev events.k8s.io/v1 true Event
flowschemas flowcontrol.apiserver.k8s.io/v1beta2 false FlowSchema
prioritylevelconfigurations flowcontrol.apiserver.k8s.io/v1beta2 false PriorityLevelConfiguration
ingressclasses networking.k8s.io/v1 false IngressClass
ingresses ing networking.k8s.io/v1 true Ingress
networkpolicies netpol networking.k8s.io/v1 true NetworkPolicy
runtimeclasses node.k8s.io/v1 false RuntimeClass
poddisruptionbudgets pdb policy/v1 true PodDisruptionBudget
clusterrolebindings rbac.authorization.k8s.io/v1 false ClusterRoleBinding
clusterroles rbac.authorization.k8s.io/v1 false ClusterRole
rolebindings rbac.authorization.k8s.io/v1 true RoleBinding
roles rbac.authorization.k8s.io/v1 true Role
priorityclasses pc scheduling.k8s.io/v1 false PriorityClass
csidrivers storage.k8s.io/v1 false CSIDriver
csinodes storage.k8s.io/v1 false CSINode
csistoragecapacities storage.k8s.io/v1 true CSIStorageCapacity
storageclasses sc storage.k8s.io/v1 false StorageClass
volumeattachments storage.k8s.io/v1 false VolumeAttachment
```
<!-- cspell:enable -->
For specific configuration details, see
[Kubernetes Objects Receiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/k8sobjectsreceiver).
Since the processor uses the Kubernetes API, it needs the correct permission to
work correctly. Since service accounts are the only authentication option you
must give the service account the proper access. For any object you want to
collect you need to ensure the name is added to the cluster role. For example,
if you wanted to collect pods then the cluster role would look like:
```yaml
---
apiVersion: v1
kind: ServiceAccount
metadata:
name: otel-collector-opentelemetry-collector
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
name: otel-collector-opentelemetry-collector
rules:
- apiGroups:
- ''
resources:
- pods
verbs:
- get
- list
- watch
---
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
name: otel-collector-opentelemetry-collector
roleRef:
apiGroup: rbac.authorization.k8s.io
kind: ClusterRole
name: otel-collector-opentelemetry-collector
subjects:
- kind: ServiceAccount
name: otel-collector-opentelemetry-collector
namespace: default
```
## Prometheus Receiver
| Deployment Pattern | Usable |
| -------------------- | ------ |
| DaemonSet (agent) | Yes |
| Deployment (gateway) | Yes |
| Sidecar | No |
Prometheus is a common metrics format for both Kubernetes and services running
on Kubernetes. The Prometheus receiver is a minimal drop-in replacement for the
collection of those metrics. It supports the full set of Prometheus
[`scrape_config` options](https://prometheus.io/docs/prometheus/1.8/configuration/configuration/#scrape_config).
There are a few advanced Prometheus features that the receiver does not support.
The receiver returns an error if the configuration YAML/code contains any of the
following:
- `alert_config.alertmanagers`
- `alert_config.relabel_configs`
- `remote_read`
- `remote_write`
- `rule_files`
For specific configuration details, see
[Prometheus Receiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/prometheusreceiver).
The Prometheus receiver is
[Stateful](https://github.com/open-telemetry/opentelemetry-collector/blob/main/docs/standard-warnings.md#statefulness),
which means there are important details to consider when using it:
- The collector cannot auto-scale the scraping process when multiple replicas of
the collector are run.
- When running multiple replicas of the collector with the same config, it will
scrape the targets multiple times.
- Users need to configure each replica with a different scraping configuration
if they want to manually shard the scraping process.
To make configuring the Prometheus receiver easier, the OpenTelemetry Operator
includes an optional component called the
[Target Allocator](../../operator/target-allocator). This component can be used
to tell a collector which Prometheus endpoints it should scrape.
For more information on the design of the receiver, see
[Design](https://github.com/open-telemetry/opentelemetry-collector-contrib/blob/main/receiver/prometheusreceiver/DESIGN.md).
## Host Metrics Receiver
| Deployment Pattern | Usable |
| -------------------- | -------------------------------------------------------------- |
| DaemonSet (agent) | Preferred |
| Deployment (gateway) | Yes, but only collects metrics from the node it is deployed on |
| Sidecar | No |
The Host Metrics Receiver collects metrics from a host using a variety of
scrapers. There is some overlap with the
[Kubeletstats Receiver](#kubeletstats-receiver) so if you decide to use both, it
may be worth it to disable these duplicate metrics.
In Kubernetes, the receiver needs access to the `hostfs` volume to work
properly. If you're using the
[OpenTelemetry Collector Helm chart](../../helm/collector/) you can use the
[`hostMetrics` preset](../../helm/collector/#host-metrics-preset) to get
started.
The available scrapers are:
| Scraper | Supported OSs | Description |
| ---------- | ------------------- | ------------------------------------------------------ |
| cpu | All except Mac[^1] | CPU utilization metrics |
| disk | All except Mac[^1] | Disk I/O metrics |
| load | All | CPU load metrics |
| filesystem | All | File System utilization metrics |
| memory | All | Memory utilization metrics |
| network | All | Network interface I/O metrics & TCP connection metrics |
| paging | All | Paging/Swap space utilization and I/O metrics |
| processes | Linux, Mac | Process count metrics |
| process | Linux, Windows, Mac | Per process CPU, Memory, and Disk I/O metrics |
[^1]:
Not supported on Mac when compiled without cgo, which is the default for the
images released by the Collector SIG.
For specific details about which metrics are collected and specific
configuration details, see
[Host Metrics Receiver](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/hostmetricsreceiver).
If you need to configure the component yourself, make sure to mount the `hostfs`
volume if you want to collect the node's metrics and not the container's.
```yaml
---
apiVersion: apps/v1
kind: DaemonSet
...
spec:
...
template:
...
spec:
...
containers:
- name: opentelemetry-collector
...
volumeMounts:
...
- name: hostfs
mountPath: /hostfs
readOnly: true
mountPropagation: HostToContainer
volumes:
...
- name: hostfs
hostPath:
path: /
...
```
and then configure the Host Metrics Receiver to use the `volumeMount`:
```yaml
receivers:
hostmetrics:
root_path: /hostfs
collection_interval: 10s
scrapers:
cpu:
load:
memory:
disk:
filesystem:
network:
```
For more details about using the receiver in a container, see
[Collecting host metrics from inside a container (Linux only)](https://github.com/open-telemetry/opentelemetry-collector-contrib/tree/main/receiver/hostmetricsreceiver#collecting-host-metrics-from-inside-a-container-linux-only)
Reference in New Issue View Git Blame Copy Permalink