Markdown linting

Author: rcastley

content/en/ninja-workshops/6-lambda-kinesis/2-auto-instrumentation.md

@@ -7,40 +7,49 @@ weight: 2
 The first part of our workshop will demonstrate how auto-instrumentation with OpenTelemetry allows the OpenTelemetry Collector to auto-detect what language your function is written in, and start capturing traces for those applications.
 
 ### The Auto-Instrumentation Workshop Directory & Contents
+
 First, let us take a look at the `o11y-lambda-workshop/auto` directory, and some of its files. This is where all the content for the auto-instrumentation portion of our workshop resides.
 
 #### The `auto` Directory
+
 - Run the following command to get into the `o11y-lambda-workshop/auto` directory:
+
   ```bash
   cd ~/o11y-lambda-workshop/auto
   ```
 
 - Inspect the contents of this directory:
+
   ```bash
   ls
   ```
+
   - _The output should include the following files and directories:_
+
     ```bash
     get_logs.py    main.tf       send_message.py
     handler        outputs.tf    terraform.tf
     ```
 
 #### The `main.tf` file
+
 - Take a closer look at the `main.tf` file:
+
   ```bash
   cat main.tf
   ```
 
 {{% notice title="Workshop Questions" style="tip" icon="question" %}}
 
-* Can you identify which AWS resources are being created by this template?
-* Can you identify where OpenTelemetry instrumentation is being set up?
-  * _Hint: study the lambda function definitions_
-* Can you determine which instrumentation information is being provided by the environment variables we set earlier?
+- Can you identify which AWS resources are being created by this template?
+- Can you identify where OpenTelemetry instrumentation is being set up?
+  - _Hint: study the lambda function definitions_
+- Can you determine which instrumentation information is being provided by the environment variables we set earlier?
 
 {{% /notice %}}
 
 You should see a section where the environment variables for each lambda function are being set.
+
   ```bash
   environment {
     variables = {
@@ -55,44 +64,53 @@ You should see a section where the environment variables for each lambda functio
   ```
 
 By using these environment variables, we are configuring our auto-instrumentation in a few ways:
+
 - We are setting environment variables to inform the OpenTelemetry collector of which Splunk Observability Cloud organization we would like to have our data exported to.
+
   ```bash
   SPLUNK_ACCESS_TOKEN = var.o11y_access_token
   SPLUNK_ACCESS_TOKEN = var.o11y_realm
   ```
 
 - We are also setting variables that help OpenTelemetry identify our function/service, as well as the environment/application it is a part of.
+
   ```bash
   OTEL_SERVICE_NAME = "producer-lambda" # consumer-lambda in the case of the consumer function
   OTEL_RESOURCE_ATTRIBUTES = "deployment.environment=${var.prefix}-lambda-shop"
   ```
 
 - We are setting an environment variable that lets OpenTelemetry know what wrappers it needs to apply to our function's handler so as to capture trace data automatically, based on our code language.
+
   ```bash
   AWS_LAMBDA_EXEC_WRAPPER - "/opt/nodejs-otel-handler"
   ```
 
 - In the case of the `producer-lambda` function, we are setting an environment variable to let the function know what Kinesis Stream to put our record to.
+
   ```bash
   KINESIS_STREAM = aws_kinesis_stream.lambda_streamer.name
   ```
 
 - These values are sourced from the environment variables we set in the Prerequisites section, as well as resources that will be deployed as a part of this Terraform configuration file.
 
 You should also see an argument for setting the Splunk OpenTelemetry Lambda layer on each function
+
   ```bash
   layers = var.otel_lambda_layer
   ```
+
 - The OpenTelemetry Lambda layer is a package that contains the libraries and dependencies necessary to collector, process and export telemetry data for Lambda functions at the moment of invocation.
 
 - While there is a general OTel Lambda layer that has all the libraries and dependencies for all OpenTelemetry-supported languages, there are also language-specific Lambda layers, to help make your function even more lightweight.
 
   - _You can see the relevant Splunk OpenTelemetry Lambda layer ARNs (Amazon Resource Name) and latest versions for each AWS region [HERE](https://github.com/signalfx/lambda-layer-versions/blob/main/splunk-apm/splunk-apm.md)_
 
 #### The `producer.mjs` file
+
 Next, let's take a look at the `producer-lambda` function code:
 
 - Run the following command to view the contents of the `producer.mjs` file:
+
   ```bash
   cat ~/o11y-lambda-workshop/auto/handler/producer.mjs
   ```
@@ -101,26 +119,33 @@ Next, let's take a look at the `producer-lambda` function code:
   - Essentially, this function receives a message, and puts that message as a record to the targeted Kinesis Stream
 
 ### Deploying the Lambda Functions & Generating Trace Data
+
 Now that we are familiar with the contents of our `auto` directory, we can deploy the resources for our workshop, and generate some trace data from our Lambda functions.
 
 #### Initialize Terraform in the `auto` directory
+
 In order to deploy the resources defined in the `main.tf` file, you first need to make sure that Terraform is initialized in the same folder as that file.
 
 - Ensure you are in the `auto` directory:
+
   ```bash
   pwd
   ```
-    - _The expected output would be **~/o11y-lambda-workshop/auto**_
+
+  - _The expected output would be **~/o11y-lambda-workshop/auto**_
 
 - If you are not in the `auto` directory, run the following command:
+
   ```bash
   cd ~/o11y-lambda-workshop/auto
   ```
 
 - Run the following command to initialize Terraform in this directory
+
   ```bash
   terraform init
   ```
+
   - This command will create a number of elements in the same folder:
     - `.terraform.lock.hcl` file: to record the providers it will use to provide resources
     - `.terraform` directory: to store the provider configurations
@@ -130,15 +155,19 @@ In order to deploy the resources defined in the `main.tf` file, you first need t
   - This enables Terraform to manage the creation, state and destruction of resources, as defined within the `main.tf` file of the `auto` directory
 
 #### Deploy the Lambda functions and other AWS resources
+
 Once we've initialized Terraform in this directory, we can go ahead and deploy our resources.
 
 - Run the Terraform command to have the Lambda function and other supporting resources deployed from the `main.tf` file:
+
   ```bash
   terraform apply
   ```
+
   - respond `yes` when you see the `Enter a value:` prompt
 
   - This will result in the following outputs:
+
     ```bash
     Outputs:
 
@@ -152,75 +181,90 @@ Once we've initialized Terraform in this directory, we can go ahead and deploy o
     ```
 
 #### Send some traffic to the `producer-lambda` endpoint (`base_url`)
+
 To start getting some traces from our deployed Lambda functions, we would need to generate some traffic. We will send a message to our `producer-lambda` function's endpoint, which should be put as a record into our Kinesis Stream, and then pulled from the Stream by the `consumer-lambda` function.
 
 - Ensure you are in the `auto` directory:
+
   ```bash
   pwd
   ```
-    - _The expected output would be **~/o11y-lambda-workshop/auto**_
+
+  - _The expected output would be **~/o11y-lambda-workshop/auto**_
 
 - If you are not in the `auto` directory, run the following command
-```bash
-cd ~/o11y-lambda-workshop/auto
-```
+
+  ```bash
+  cd ~/o11y-lambda-workshop/auto
+  ```
 
 The `send_message.py` script is a Python script that will take input at the command line, add it to a JSON dictionary, and send it to your `producer-lambda` function's endpoint repeatedly, as part of a while loop.
 
 - Run the `send_message.py` script as a background process
   - _It requires the `--name` and `--superpower` arguments_
+
   ```bash
   nohup ./send_message.py --name CHANGEME --superpower CHANGEME &
   ```
+
   - You should see an output similar to the following if your message is successful
+
     ```bash
     [1] 79829
     user@host manual % appending output to nohup.out
     ```
+
     - _The two most import bits of information here are:_
       - _The process ID on the first line (`79829` in the case of my example), and_
       - _The `appending output to nohup.out` message_
-    
     - _The `nohup` command ensures the script will not hang up when sent to the background. It also captures any output from our command in a nohup.out file in the same folder as the one you're currently in._
-
     - _The `&` tells our shell process to run this process in the background, thus freeing our shell to run other commands._
 
 - Next, check the contents of the `nohup.out` file, to ensure your output confirms your requests to your `producer-lambda` endpoint are successful:
+
   ```bash
   cat nohup.out
   ```
+
   - You should see the following output among the lines printed to your screen if your message is successful:
-    ```bash
-    {"message": "Message placed in the Event Stream: hostname-eventStream"}
-    ```
+
+  ```bash
+  {"message": "Message placed in the Event Stream: hostname-eventStream"}
+  ```
 
   - If unsuccessful, you will see:
-    ```bash
-    {"message": "Internal server error"}
-    ```
+
+  ```bash
+  {"message": "Internal server error"}
+  ```
 
 > [!IMPORTANT]
 > If this occurs, ask one of the workshop facilitators for assistance.
 
 #### View the Lambda Function Logs
+
 Next, let's take a look at the logs for our Lambda functions.
 
 - Run the following script to view your `producer-lambda` logs:
+
   ```bash
   ./get_logs.py --function producer
   ```
+
   - Hit `[CONTROL-C]` to stop the live stream after some log events show up
 
 - Run the following to view your `consumer-lambda` logs:
+
   ```bash
   ./get_logs.py --function consumer
   ```
+
   - Hit `[CONTROL-C]` to stop the live stream after some log events show up
 
 Examine the logs carefully.
 
 {{% notice title="Workshop Question" style="tip" icon="question" %}}
 
-* Do you see OpenTelemetry being loaded? Look out for the lines with `splunk-extension-wrapper`
+- Do you see OpenTelemetry being loaded? Look out for the lines with `splunk-extension-wrapper`
 
 {{% /notice %}}

content/en/ninja-workshops/6-lambda-kinesis/3-lambdas-in-splunk.md

@@ -7,9 +7,11 @@ weight: 3
 The Lambda functions should be generating a sizeable amount of trace data, which we would need to take a look at. Through the combination of environment variables and the OpenTelemetry Lambda layer configured in the resource definition for our Lambda functions, we should now be ready to view our functions and traces in Splunk APM.
 
 #### View your Environment name in the Splunk APM Overview
+
 Let's start by making sure that Splunk APM is aware of our `Environment` from the trace data it is receiving. This is the `deployment.name` we set as part of the `OTEL_RESOURCE_ATTRIBUTES` variable we set on our Lambda function definitions in `main.tf`.
 
 In Splunk Observability Cloud:
+
 - Click on the `APM` Button from the Main Menu on the left. This will take you to the Splunk APM Overview.
 
 - Select your APM Environment from the `Environment:` dropdown.
@@ -21,6 +23,7 @@ In Splunk Observability Cloud:
 ![Splunk APM, Environment Name](../images/02-Auto-APM-EnvironmentName.png)
 
 #### View your Environment's Service Map
+
 Once you've selected your Environment name from the Environment drop down, you can take a look at the Service Map for your Lambda functions.
 
 - Click the `Service Map` Button on the right side of the APM Overview page. This will take you to your Service Map view.
@@ -58,35 +61,46 @@ Not yet, at least...
 Let's see how we work around this in the next section of this workshop. But before that, let's clean up after ourselves!
 
 ### Clean Up
+
 The resources we deployed as part of this auto-instrumenation exercise need to be cleaned. Likewise, the script that was generating traffice against our `producer-lambda` endpoint needs to be stopped, if it's still running. Follow the below steps to clean up.
 
 #### Kill the `send_message`
+
 - If the `send_message.py` script is still running, stop it with the follwing commands:
+
   ```bash
   fg
   ```
+
   - This brings your background process to the foreground.
   - Next you can hit `[CONTROL-C]` to kill the process.
 
 #### Destroy all AWS resources
+
 Terraform is great at managing the state of our resources individually, and as a deployment. It can even update deployed resources with any changes to their definitions. But to start afresh, we will destroy the resources and redeploy them as part of the manual instrumentation portion of this workshop.
 
 Please follow these steps to destroy your resources:
+
 - Ensure you are in the `auto` directory:
+
   ```bash
   pwd
   ```
+
   - _The expected output would be **~/o11y-lambda-workshop/auto**_
 
 - If you are not in the `auto` directory, run the following command:
+
   ```bash
   cd ~/o11y-lambda-workshop/auto
   ```
 
 - Destroy the Lambda functions and other AWS resources you deployed earlier:
+
   ```bash
   terraform destroy
   ```
+
   - respond `yes` when you see the `Enter a value:` prompt
   - This will result in the resources being destroyed, leaving you with a clean environment