Skip to content

Commit

Permalink
Merge pull request #290 from splunk/conf24
Browse files Browse the repository at this point in the history
Hide Node Dependencies in S4R ... changed to automatic discovery and configuration
  • Loading branch information
hagen-p authored May 14, 2024
2 parents c5e749f + a6b31f3 commit 46fe945
Show file tree
Hide file tree
Showing 16 changed files with 39 additions and 39 deletions.
4 changes: 2 additions & 2 deletions content/en/conf24/1-zero-config-k8s/1-architecture/_index.md
Original file line number Diff line number Diff line change
Expand Up @@ -5,11 +5,11 @@ weight: 2
time: 5 minutes
---

The diagram below details the architecture of the Spring PetClinic Java application running in Kubernetes with the Splunk OpenTelemetry Operator and Auto Instrumentation enabled.
The diagram below details the architecture of the Spring PetClinic Java application running in Kubernetes with the Splunk OpenTelemetry Operator and automatic discovery and configuration enabled.

The Spring PetClinic Java application is a simple microservices application that consists of a frontend and backend services. The frontend service is a Spring Boot application that serves a web interface to interact with the backend services. The backend services are Spring Boot applications that serve RESTful API's to interact with a MySQL database.

By the end of this workshop, you will have a better understanding of how to enable **Splunk OpenTelemetry Zero Configuration Auto Instrumentation** for your Java-based applications running in Kubernetes.
By the end of this workshop, you will have a better understanding of how to enable **Splunk OpenTelemetry automatic discovery and configuration** for your Java-based applications running in Kubernetes.

![Splunk Otel Architecture](../images/auto-instrumentation-java-diagram.png)

Expand Down
4 changes: 2 additions & 2 deletions content/en/conf24/1-zero-config-k8s/2-preparation/1-otel.md
Original file line number Diff line number Diff line change
Expand Up @@ -32,9 +32,9 @@ Update Complete. ⎈Happy Helming!⎈
{{% /tab %}}
{{< /tabs >}}

**Splunk Observability Cloud** offers wizards in the UI to walk you through the setup of the OpenTelemetry Collector on Kubernetes, but in the interest of time, we will use the Helm command below. Some additional parameters are set to enable the operator and Zero Configuration Auto Instrumentation.
**Splunk Observability Cloud** offers wizards in the UI to walk you through the setup of the OpenTelemetry Collector on Kubernetes, but in the interest of time, we will use the Helm command below. Some additional parameters are set to enable the operator and automatic discovery and configuration.

* `--set="operator.enabled=true"` - this will install the Opentelemetry operator that will be used to handle Auto Instrumentation.
* `--set="operator.enabled=true"` - this will install the Opentelemetry operator that will be used to handle automatic discovery and configuration.
* `--set="certmanager.enabled=true"` - this will install the required certificate manager for the operator.
* `--set="splunkObservability.profilingEnabled=true"` - this enables Code Profiling via the operator.

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -84,7 +84,7 @@ Once they are running, the application will take a few minutes to fully start up

#### Verify the local Private Registry

Later on, when we test our **Zero Configuration Auto Instrumentation** we are going to build new containers to highlight some of the additional features of Splunk Observability Cloud.
Later on, when we test our **automatic discovery and configuration** we are going to build new containers to highlight some of the additional features of Splunk Observability Cloud.

As configuration files and source code will be changed, the containers will need to be built and stored in a local private registry (which has already been enabled for you).

Expand Down
Original file line number Diff line number Diff line change
@@ -1,10 +1,10 @@
---
title: Zero Configuration Setup
linkTitle: 1. Zero Configuration Setup
title: Automatic Discovery and Configuration
linkTitle: 1. Automatic Discovery and Configuration
weight: 1
---

To see how Zero Configuration works with a single pod we will patch the `api-gateway`. Once patched, the OpenTelemetry Collector will inject the Auto Instrumentation library and the Pod will be restarted in order to start sending traces and profiling data. To show what happens when you enable Auto Instrumentation, let's do a *before and after* of the configuration:
To see how automatic discovery and configuration works with a single pod we will patch the `api-gateway`. Once patched, the OpenTelemetry Collector will inject the automatic discovery and configuration library and the Pod will be restarted in order to start sending traces and profiling data. To show what happens when you enable automatic discovery and configuration, let's do a *before and after* of the configuration:

{{< tabs >}}
{P}{{% tab title="Describe api-gateway" %}}
Expand All @@ -23,7 +23,7 @@ Image: quay.io/phagen/spring-petclinic-api-gateway:0.0.2
{{% /tab %}}
{{< /tabs >}}

This container was pulled from a remote repository `quay.io` and was not built to send traces to **Splunk Observability Cloud**. To enable the Java auto instrumentation on the api-gateway service add the `inject-java` annotation to Kubernetes with the `kubectl patch deployment` command.
This container was pulled from a remote repository `quay.io` and was not built to send traces to **Splunk Observability Cloud**. To enable the Java automatic discovery and configuration on the api-gateway service add the `inject-java` annotation to Kubernetes with the `kubectl patch deployment` command.

{{< tabs >}}
{{% tab title="Patch api-gateway" %}}
Expand Down Expand Up @@ -90,6 +90,6 @@ deployment.apps/api-gateway patched (no change)
{{% /tab %}}
{{< /tabs >}}

Navigate back to the Kubernetes Navigator in **Splunk Observability Cloud**. After a couple of minutes you will see that the Pods are being restarted by the operator and the Zero config container will be added. This will look similar to the screenshot below:
Navigate back to the Kubernetes Navigator in **Splunk Observability Cloud**. After a couple of minutes you will see that the Pods are being restarted by the operator and the automatic discovery and configuration container will be added. This will look similar to the screenshot below:

![restart](../../images/k8s-navigator-restarted-pods.png)
10 changes: 5 additions & 5 deletions content/en/conf24/1-zero-config-k8s/4-zero-config/_index.md
Original file line number Diff line number Diff line change
@@ -1,15 +1,15 @@
---
title: Setting up Zero configuration Auto instrumentation for APM
linkTitle: 4. Auto Instrumentation & Metrics
title: Setting up automatic discovery and configuration for APM
linkTitle: 4. automatic discovery and configuration & Metrics
weight: 5
time: 10 minutes
---

In this section we will enable **Zero Configuration Auto Instrumentation** for the Java services running in Kubernetes. This means that the OpenTelemetry Collector will look for Pod annotations that indicate that the Java application should be instrumented with the Splunk OpenTelemetry Java agent. This will allow us to get traces, spans, and profiling data from the Java services running on the cluster.
In this section we will enable **automatic discovery and configuration** for the Java services running in Kubernetes. This means that the OpenTelemetry Collector will look for Pod annotations that indicate that the Java application should be instrumented with the Splunk OpenTelemetry Java agent. This will allow us to get traces, spans, and profiling data from the Java services running on the cluster.

{{% notice title="Zero Configuration Auto Instrumentation" style="note" %}}
{{% notice title="automatic discovery and configuration" style="note" %}}

It is important to understand that Zero Configuration Auto Instrumentation is designed to get **trace, span & profiling** data out of your application, without requiring code changes or recompilation.
It is important to understand that automatic discovery and configuration is designed to get **trace, span & profiling** data out of your application, without requiring code changes or recompilation.

This is a great way to get started with APM, but it is **not** a replacement for manual instrumentation. Manual instrumentation allows you to add custom spans, tags, and logs to your application, which can provide more context and detail to your traces.

Expand Down
4 changes: 2 additions & 2 deletions content/en/conf24/1-zero-config-k8s/5-traces/2-spans.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ linkTitle: 2. APM Spans
weight: 2
---

While we examine our spans, let's look at several features that you get out of the box without code modifications when using **Zero Configuration Auto Instrumentation** on top of tracing:
While we examine our spans, let's look at several features that you get out of the box without code modifications when using **automatic discovery and configuration** on top of tracing:

Due to the fact there are several different routes
First, in the Waterfall Pane, make sure the `customers-service:SELECT petclinic.owners` or similar span is selected as shown in the screenshot below:
Expand All @@ -14,7 +14,7 @@ First, in the Waterfall Pane, make sure the `customers-service:SELECT petclinic.
* The basic latency information is shown as a bar for the instrumented function or call, in our example, it took 6.3 Milliseconds.
* Several similar Spans **(1**)**, are only visible if the span is repeated multiple times. In this case, there are 10 repeats in our example. (You can show/hide them all by clicking on the `10x` and all spans will show in order)
* Inferred Services, Calls done to external systems that are not instrumented, show up as a gray 'inferred' span. The Inferred Service or span in our case here is a call to the Mysql Database `mysql:petclinic SELECT petclinic` **(2)** as shown below our selected span.
* Span Tags in the Tag Pane, standard tags produced by the auto instrumentation agent. In this case, the span is calling a Database, so it includes the `db.statement` tag **(3)**. This tag will hold the DB query statement and is used by the Database call performed during this span. This will be used by the DB-Query Performance feature. We look at DB-Query Performance in the next section.
* Span Tags in the Tag Pane, standard tags produced by the automatic discovery and configuration. In this case, the span is calling a Database, so it includes the `db.statement` tag **(3)**. This tag will hold the DB query statement and is used by the Database call performed during this span. This will be used by the DB-Query Performance feature. We look at DB-Query Performance in the next section.
* Always-on Profiling, **IF** the system is configured to, and has captured Profiling data during a Spans life cycle, it will show the number of Call Stacks captured in the Spans timeline. (15 Call Stacks for the `customers-service:SELECT petclinic.`owners` Span shown above). We will look at Profiling in the next section.

<!--
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -17,7 +17,7 @@ This dashboard, which is available for each of your instrumented services, offer
As the dashboards allow you to go back in time with the *Time picker* window **(1)**, it's the perfect spot to identify the behavior you wish to be alerted on, and with a click on one of the bell icons **(2)** available in each chart, you can set up an alert to do just that.

If you scroll down the page, you get host and Kubernetes metrics related to your service as well.
Let's move on to look at some of the traces generated by the Zero Config Auto instrumentation.
Let's move on to look at some of the traces generated by the automatic discovery and configuration.
<!--
{{< tabs >}}
{{% tab title="Tail Log" %}}
Expand Down
2 changes: 1 addition & 1 deletion content/en/conf24/1-zero-config-k8s/5-traces/_index.md
Original file line number Diff line number Diff line change
Expand Up @@ -6,7 +6,7 @@ archetype: chapter
time: 15 minutes
---

As we have seen in the previous section, once you enable **Zero Configuration Auto Instrumentation** on your services traces are sent to **Splunk Observability Cloud**.
As we have seen in the previous section, once you enable **automatic discovery and configuration** on your services, traces are sent to **Splunk Observability Cloud**.

With these traces, Splunk will automatically generate **Service Maps** and **RED Metrics**. These are the first steps in understanding the behavior of your services and how they interact with each other.

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,7 @@ When we installed the Splunk Distribution of the OpenTelemetry Collector using t

When you deploy the PetClinic application and set the annotation, the collector automatically detects the application and instruments it for traces and profiling. We can verify this by examining the startup logs of one of the Java containers we are instrumenting by running the following script:

The logs should show what flags were picked up by the Java Auto instrumentation agent:
The logs should show what flags were picked up by the Java automatic discovery and configuration:

{{< tabs >}}
{{% tab title="Run the script" %}}
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -8,7 +8,7 @@ time: 15 minutes

As we have seen in the previous chapter, you can trace your interactions between the various services using APM without touching your code, which will allow you to identify issues faster.

However, besides tracing **Splunk Zero Configuration Auto Instrumentation** offers additional features out of the box that can help you find issues even faster. In this section we are going to look at two of them:
However, besides tracing **automatic discovery and configuration** offers additional features out of the box that can help you find issues even faster. In this section we are going to look at two of them:

- **Always-on Profiling and Java Metrics**
- **Database Query Performance**
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -34,7 +34,7 @@ The resulting output will show `localhost:9999`:
Image: localhost:9999/spring-petclinic-api-gateway:local
```

However, as we only patched the deployment before, the new deployment does not have the right annotations for the **Zero Configuration Auto Instrumentation**, so let's fix that now by running the patch command again:
However, as we only patched the deployment before, the new deployment does not have the right annotations for the **automatic discovery and configuration**, so let's fix that now by running the patch command again:

{{% notice note %}}

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -10,7 +10,7 @@ Up until this point, there have been no code changes, yet tracing, profiling and

Next we will add the **Splunk Log Observer** to the mix to obtain log data from the Spring PetClinic application.

This change will update the configuration of [**logback**](https://logback.qos.ch/) in the Spring PetClinic application. This will allow the Auto Instrumentation to add OpenTelemetry relevant information into the logs.
This change will update the configuration of [**logback**](https://logback.qos.ch/) in the Spring PetClinic application. This will allow the automatic discovery and configuration to add OpenTelemetry relevant information into the logs.

The **Splunk Log Observer** is then used to view the logs and with the changes to the log format the platform can automatically correlate log information with services and traces.

Expand Down
10 changes: 5 additions & 5 deletions content/en/conf24/1-zero-config-k8s/8-rum/1-rebuild-app.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,9 +4,9 @@ linkTitle: 1. Rebuild PetClinic
weight: 1
---

At the top of the previous code snippet, there is a reference to the file `/static/env.js`, which contains/sets the variables used by the RUM, currently these are not configured and therefore no RUM traces are currently being sent.
At the top of the previous code snippet, there is a reference to the file `/static/env.js`, which contains/sets the variables used by RUM, currently these are not configured and therefore no RUM traces are currently being sent.

So, let's run the script that will update variables to enable RUM traces so they can be viewable in the **Splunk Observability Cloud** RUM UI. Note, that the Env.js script contains a deliberate Java script error, so we have one detected by Splunk RUM:
Run the script that will update variables to enable RUM traces so they are viewable in **Splunk Observability Cloud**. Note, that the `env.js` script contains a deliberate JavaScript error, that will be picked up in RUM:

{{< tabs >}}
{{% tab title="Update env.js for RUM" %}}
Expand Down Expand Up @@ -52,7 +52,7 @@ if (env.RUM_REALM != "") {
}
```

Let's move into the api-gateway directory and force a build for just the api-gateway service.
Change into the `api-gateway` directory and force a new build for just the `api-gateway` service:

{{% /tab %}}
{{< /tabs >}}
Expand All @@ -66,7 +66,7 @@ cd ~/spring-petclinic-microservices/spring-petclinic-api-gateway
. ~/workshop/petclinic/scripts/push_docker.sh
```

As soon as the containers are pushed into the repository, just restart the `api-gateway` to apply the changes:
As soon as the container is pushed into the repository, just restart the `api-gateway` to apply the changes:

``` bash
kubectl rollout restart deployment api-gateway
Expand All @@ -76,4 +76,4 @@ Validate that the application is running by visiting **http://<IP_ADDRESS>:81**

![pet](../../images/petclinic-pet.png)

If you want, you can access this website on your phone as well. This will also show up in RUM.
If you want, you can access this website on your phone/tablet as well as this data will also show up in RUM.
9 changes: 4 additions & 5 deletions content/en/conf24/1-zero-config-k8s/8-rum/2-rum-tour.md
Original file line number Diff line number Diff line change
@@ -1,22 +1,21 @@
---
title: Select the RUM view for the Petclinic App
linkTitle: 2.Select Rum env
linkTitle: 2. Verify RUM traces
weight: 2
---

Once the RUM has been configured an you have added a visit for a pet, you can log in to **Splunk Observability Cloud** and verify that the RUM traces are flowing in from you app.
Once RUM has been configured and you have added a visit for a pet, you can log in to **Splunk Observability Cloud** and verify that RUM traces are flowing in.

From the left-hand menu click on **RUM** ![RUM](../../images/rum-icon.png?classes=inline&height=25px) and change the **Environment** filter **(1)** to the name of your workshop instance from the dropdown box, it will be **`<INSTANCE>-workshop`** **(1)**(where **`INSTANCE`** is the value from the shell script you ran earlier). Make sure it is the only one selected.

Then change the **App** **(2)** dropdown box to the name of your app, it will be **`<INSTANCE>-store`**

![rum select](../../images/rum-env-select.png)

If you have selected your Environment and App, you see an overview page showing the RUM status of you App (IF your Summary Dashboard is just a single row of numbers, you are looking at the condensed view. You can expadn it by clicking on the **>** in front of the Application name).
Once you have selected your **Environment** and **App**, you will see an overview page showing the RUM status of your App (if your Summary Dashboard is just a single row of numbers, you are looking at the condensed view. You can expand it by clicking on the **>** in front of the Application name).

![rum overview](../../images/rum-overview.png)

Click on the blue link to get to the details page

![rum main](../../images/rum-main.png)


8 changes: 4 additions & 4 deletions content/en/conf24/1-zero-config-k8s/_index.md
Original file line number Diff line number Diff line change
Expand Up @@ -3,16 +3,16 @@ title: Spring PetClinic SpringBoot Based Microservices On Kubernetes
linkTitle: PetClinic Kubernetes Workshop
weight: 1
archetype: chapter
description: Learn how to enable Open Telemetry Zero Configuration Auto-Instrumentation for your Java-based application running in Kubernetes. Experience real-time monitoring to help you maximize application behavior with end-to-end visibility.
description: Learn how to enable automatic discovery and configuration for your Java-based application running in Kubernetes. Experience real-time monitoring to help you maximize application behavior with end-to-end visibility.
authors: ["Pieter Hagen"]
time: 90 minutes
---

The goal of this workshop is to introduce the features of Splunk's **Zero Configuration Auto Instrumentation** for Java.
The goal of this workshop is to introduce the features of Splunk's **automatic discovery and configuration** for Java.

The workshop scenario will be created by installing a simple (**un-instrumented**) Java microservices application in Kubernetes.

By following the simple steps to install the Splunk OpenTelemetry Collector and enabling Zero Configuration Auto Instrumentation for existing Java based deployments you will learn how easy it is to send metrics, traces and logs to **Splunk Observability Cloud**.
By following the simple steps to install the Splunk OpenTelemetry Collector and enabling automatic discovery and configuration for existing Java based deployments you will learn how easy it is to send metrics, traces and logs to **Splunk Observability Cloud**.

{{% notice title="Prerequisites" style="primary" icon="info" %}}

Expand All @@ -25,7 +25,7 @@ By following the simple steps to install the Splunk OpenTelemetry Collector and
During this workshop we will cover the following components:

* Splunk Infrastructure Monitoring (**IM**)
* Splunk Auto Instrumentation for Java (**APM**)
* Splunk automatic discovery and configuration for Java (**APM**)
* Database Query Performance
* AlwaysOn Profiling
* Splunk Log Observer (**LO**)
Expand Down
Loading

0 comments on commit 46fe945

Please sign in to comment.