proxy.golang.org : github.com/open-telemetry/opentelemetry-collector-contrib/processor/k8sprocessor

RBAC TODO: mention the required RBAC rules. TODO: example config. The processor supports running both in agent and collector mode. When running as an agent, the processor detects IP addresses of pods sending spans, metrics or logs to the agent and uses this information to extract metadata from pods. When running as an agent, it is important to apply a discovery filter so that the processor only discovers pods from the same host that it is running on. Not using such a filter can result in unnecessary resource usage especially on very large clusters. Once the filter is applied, each processor will only query the k8s API for pods running on it's own node. Node filter can be applied by setting the `filter.node` config option to the name of a k8s node. While this works as expected, it cannot be used to automatically filter pods by the same node that the processor is running on in most cases as it is not know before hand which node a pod will be scheduled on. Luckily, kubernetes has a solution for this called the downward API. To automatically filter pods by the node the processor is running on, you'll need to complete the following steps: 1. Use the downward API to inject the node name as an environment variable. Add the following snippet under the pod env section of the OpenTelemetry container. This will inject a new environment variable to the OpenTelemetry container with the value as the name of the node the pod was scheduled to run on. 2. Set "filter.node_from_env_var" to the name of the environment variable holding the node name. This will restrict each OpenTelemetry agent to query pods running on the same node only dramatically reducing resource requirements for very large clusters. The processor can be deployed both as an agent or as a collector. When running as a collector, the processor cannot correctly detect the IP address of the pods generating the telemetry data without any of the well-known IP attributes, when it receives them from an agent instead of receiving them directly from the pods. To workaround this issue, agents deployed with the k8s_tagger processor can be configured to detect the IP addresses and forward them along with the telemetry data resources. Collector can then match this IP address with k8s pods and enrich the records with the metadata. In order to set this up, you'll need to complete the following steps: 1. Setup agents in passthrough mode Configure the agents' k8s_tagger processors to run in passthrough mode. This will ensure that the agents detect the IP address as add it as an attribute to all telemetry resources. Agents will not make any k8s API calls, do any discovery of pods or extract any metadata. 2. Configure the collector as usual No special configuration changes are needed to be made on the collector. It'll automatically detect the IP address of spans, logs and metrics sent by the agents as well as directly by other services/pods. There are some edge-cases and scenarios where k8s_tagger will not work properly. The processor cannot correct identify pods running in the host network mode and enriching telemetry data generated by such pods is not supported at the moment, unless the attributes contain information about the source IP. The processor does not support detecting containers from the same pods when running as a sidecar. While this can be done, we think it is simpler to just use the kubernetes downward API to inject environment variables into the pods and directly use their values as tags.

Registry - Source - Documentation - JSON
purl: pkg:golang/github.com/open-telemetry/opentelemetry-collector-contrib/processor/k8sprocessor
Keywords: open-telemetry , opentelemetry
License: Apache-2.0
Latest release: over 3 years ago
First release: almost 5 years ago
Namespace: github.com/open-telemetry/opentelemetry-collector-contrib/processor
Dependent packages: 137
Dependent repositories: 61
Stars: 1,560 on GitHub
Forks: 1,325 on GitHub
See more repository details: repos.ecosyste.ms
Last synced: about 3 hours ago

• Versions 36
• Dependent Packages 137
• Related Packages 401
• Sort

  • Name
  • Versions
  • Latest Release
  • Oldest Release
  • Dependent packages
  • Dependent repositories
  • Downloads
  • Maintainers
  • Most Stars
  • Least Stars