From d6c069401bb014e0104138d69d6efce9ef52508b Mon Sep 17 00:00:00 2001 From: Rauno Viskus Date: Fri, 23 Aug 2024 13:23:02 +0300 Subject: [PATCH 1/2] feat: add architecture overview page to VM Agent's docs --- docs/mint.json | 1 + docs/vmagent/architecture.mdx | 34 ++++++++++++++++++++++++++++++++++ 2 files changed, 35 insertions(+) create mode 100644 docs/vmagent/architecture.mdx diff --git a/docs/mint.json b/docs/mint.json index f7ae3ec2c..1189efd4e 100644 --- a/docs/mint.json +++ b/docs/mint.json @@ -240,6 +240,7 @@ "group": "VM Agent", "pages": [ "vmagent/overview", + "vmagent/architecture", { "group": "Quickstart", "pages": [ diff --git a/docs/vmagent/architecture.mdx b/docs/vmagent/architecture.mdx new file mode 100644 index 000000000..039e93f07 --- /dev/null +++ b/docs/vmagent/architecture.mdx @@ -0,0 +1,34 @@ +--- +title: "Architecture" +sidebarTitle: "Architecture" +--- + +VM Agent is mainly built on the same components as Odigos' k8s distribution. See [the architectural overview](/architecture) for it to get an overview of what those components are and how they interact. + +However, since the environment is very different from k8s, there are significant differences as well. This document tries to list the most important ones. + +VM Agent constists of following components: + +- SystemD manager, +- Instrumentor, +- eBPF directors, +- Configuration manager. + +## SystemD manager + +SystemD manager watches changes to service files, service runtime statuses and provides necessary information for Instrumentor. + +## Instrumentor + +Instrumentor updates the service files when required and automatically instruments configured services. + +## eBPF directors + +The directors are each responsible for a set language. These are the components that do the last mile of instrumentation injecting tracing and exporting telemetry to the local collector. + +## Configuration manager + +Configuration managers watch configuration changes and reconfigure instrumentations or the collector whenever necessary. The configuration for VM Agent is split between two files: + +- `/etc/odigos-vmagent/service.yaml`: Odigos Pro token configuration; +- `/etc/odigos-vmagent/agent.yaml`: Agent configuration specifying the collector pipeline(processors and destinations), and instrumentation configuration - SystemD services to instrument and to ignore. From a33b7d2ab0209174b8ad6529b148e36af49b156c Mon Sep 17 00:00:00 2001 From: Rauno Viskus Date: Fri, 23 Aug 2024 13:24:38 +0300 Subject: [PATCH 2/2] docs: delete the most outdated bits of "architecture" docs of Odigos --- docs/architecture.mdx | 39 ++++++++++++++++++--------------------- 1 file changed, 18 insertions(+), 21 deletions(-) diff --git a/docs/architecture.mdx b/docs/architecture.mdx index 53dde7071..0537ca7bf 100644 --- a/docs/architecture.mdx +++ b/docs/architecture.mdx @@ -22,14 +22,15 @@ is responsible for: ## High Level Architecture -These tasks are performed by 4 microservices: +These tasks are performed by following components: - Instrumentor +- Odiglet - Autoscaler - Scheduler - UI -The different microservices communicate via Kubernetes API server (see +The different components communicate via Kubernetes API server (see [Custom Resources](/custom-resources) for more details). The following diagram shows the architecture of the Odigos observability system. @@ -40,37 +41,33 @@ The following diagram shows the architecture of the Odigos observability system. ## Instrumentor -The instrumentor microservice is responsible for automatic detection of -applications in the cluster and instrumentation of them. Automatic +Instrumentor is responsible for automatic detection of +applications in the cluster and providing necessary setup for Odiglet to instrument them. Automatic instrumentation is done according to the applications selected by the user in -the UI. The instrumentor may change the arguments passed to the instrumentation +the UI. Instrumentor may change the arguments passed to the instrumentation SDK to reflect the following changes: - A configuration change made by the user (for example changing the sampling rate in the UI) - Rescheduling done by the scheduler (when the collectors pipeline changes) -### Language Detection +### Odiglet + +Odiglet does the heavy lifting of instrumenting the running application. A key part of being able to automatically instrument every new application is to be able to detect the language of the application. After the language is detected Odigos will perform automatic instrumentation according to the language. For runtime languages Odigos uses the appropriate OpenTelemetry -instrumentation. For compiled languages Odigos uses eBPF instrumentation. In -order to detect the language of the application Odigos deploys a lang detection -pod that analyzes one of the target application instances. This pod is deployed -on the same node as the target instance and is able to look into the target pod -filesystem. - -The lang detection pod uses the following heuristics in order to detect the -language of the application: +instrumentation. For compiled languages Odigos uses eBPF instrumentation. -- process name -- environment variables -- dynamically loaded libraries +Following heuristics are used to detect the language and the suitable instrumentations +for the application: -The lang detection pod reports the detected language by leveraging the -`TerminationMessagePath` field of the Pod resource. +- process name, +- the command, +- environment variables, +- dynamically loaded libraries. ## Autoscaler @@ -84,8 +81,8 @@ Deployment of collectors is done in two scenarios: ## Scheduler -The scheduler service assigns applications discovered by the instrumentor to the -collectors pipeline create by the autoscaler. +Scheduler service assigns applications discovered by Instrumentor to the +collectors pipeline created by the autoscaler. ## UI