August 31, 2021

Tutorial: [Monitoring and Observability] How to Send Kubernetes Delegate Logs to Splunk

Table of Contents

This tutorial guides you through sending Kubernetes delegate logs to Splunk using Harness. It covers configuring Splunk HEC, setting up Helm charts, and deploying with Harness. The process ensures effective log management and monitoring for improved observability in Kubernetes environments.

So… you're living the dream, right? You have your workload running in Kubernetes, you have Splunk in your SRE/Monitoring/Observability Tech Stack. And the best thing: you are a happy Harness user.

Naturally, you decide to run your Harness Delegate as a K8s StatefulSet. You are reading this amazing documentation from Kubernetes.io, and you are still not sure how to achieve a good logging-and-forwarding design yet.

Worry no more, my noble SRE. That integration is only one file descriptor away from you! Ahh, with automatic fields detection + removing the coloring and other control characters that can mess with the Event. 

Buckle up! 

Tutorial

Requirement

First Step

Let’s configure our Splunk HEC and then store the Token in Harness as a Secret.

1-) HEC UI - An example:

image

2-) And then there’s the safely stored token (the one we get in Splunk’s HEC setup):

image

With that, you can see that index=harness_deployed_apps will be the home for our Delegate Logs.

Second Step

Alright, time to configure Splunk with Harness.

You can see that this is a very easy to understand Splunk-managed Helm Chart. For a deeper dive regarding the mechanism, please check the README.md.

In this step, we create a Harness Service:

image

And the trick starts here:


1-) Let’s create a Source Repo that points to the Splunk’s Project:

image

2-) Back to the Service UI - Let’s link that nice Helm Chart called splunk-kubernetes-logging like this:


Branch: main
File/Folder path: helm-chart/splunk-connect-for-kubernetes/charts/splunk-kubernetes-logging/
Helm Version: v3

image

Alright, looking good!

Third Step

We’ll use Harness' powerful Override Engine so we don’t need to manage a fork from that project. We can do all the steps we need by overriding a few entries in the default (the one that is in the GH Project) values.yaml.

Important: The Harness Delegate Pod will stdout the logs, so we can use it with very few customization.


You can read the values.yaml to confirm if you need to change anything. You may also need to ask a Splunk Admin to review it with you, but it’s pretty straightforward!

This is my Override section, at Harness UI:

# Local splunk configurations
splunk:
# Configurations for HEC (HTTP Event Collector)
hec:
# host is required and should be provided by user
host: "<SPLUNK_HEC_HOSTNAME>"
# port to HEC, optional, default 8088
port: "8088"
# token is required and should be provided by user
token: "${secrets.getValue("splunk_hec_delegate_logs")}"
# protocol has two options: "http" and "https", default is "https"
protocol: "http"
# indexName tells which index to use, this is optional. If it's not present, will use the "main".
indexName: "harness_deployed_apps"

fluentd:
# path of logfiles, default /var/log/containers/*.log
path: /var/log/containers/*delegate*.log

Fourth Step

Hey, let’s use props.conf to remove any coloring log characters that might blow your readability in the Splunk’s Search Head.

To make this easier, I’ll map our Harness Delegate Source Type (Splunk) to a very nice SED command, in “System Local.” This will do the trick for us! Your Splunk Admin might have a Deployer + Apps + etc to organize it for you.

Let's keep going!

1-) If you did not change much from the starting values YAML, this is our source type:

image

2-) Please write this file:

vim /opt/splunk/etc/system/local/props.conf

3-) And let’s append our very smart and magical sed command:

[kube:container:harness-delegate-instance]
SEDCMD-Harness = s/\x1B\[[0-9;]*[a-zA-Z]//g

Fifth Step

Now let’s deploy that! I’ll use a very simple Rolling Deployment!

Here it goes:

image

Last Step

Alright, time to check if this is working. I’ll jump into my Search Head Lab.

I’ll run a bad Splunk query, but I’m the only one in my Lab Cluster. So, no harm done! Here:

image

Outcome:

That looks amazing! Let’s deploy a dummy NGINX, and then we can put our well-known TaskID to make sure we're not doing anything crazy:

image

Let’s get our Task ID:

image

I’m so lucky to have this tech stack! Check it out:

image

Any questions or comments? Let me know - I'm always happy to help.

Gabriel

You might also like
No items found.

Similar Blogs

No items found.
Gitness
Code Repository
Software Supply Chain Assurance
Infrastructure as Code Management
AIDA
Continuous Error Tracking
Internal Developer Portal
Software Engineering Insights
Platform
Cloud Cost Management
Chaos Engineering
Continuous Delivery & GitOps
Security Testing Orchestration
Service Reliability Management
Feature Flags
Continuous Integration