0:05 Introduction

0:05 Hello, and welcome back to the Rawkode Academy. I'm your host, David Flanagan, although you may know me from across the Internet as Rawkode. Today, we're continuing on our Komodor tutorial. If you haven't seen part one, pause this and go watch it now. In part one, I show you how to deploy the Komodor agent to your Kubernetes cluster. From there, we're able to use the Komodor UI to troubleshoot and debug our Kubernetes cluster. We get really rich context aware user interface that allows us to browse our workloads and work out what is wrong based on the

0:41 events within the system. And as we all know, when things go wrong, the more information at hand you have, the easier your job is. So Komodor also ships with a whole bunch of integrations. We're going to take a look at a few of them today. The first one I wanna take a look at is Sentry. Sentry is something that if you're an application developer, you probably already know. It's an open source tool that you integrate into your application. They support pretty much every runtime available. And whenever things go wrong, it sends an alert with a stack trace

0:57 Sentry Integration Introduction

1:18 to the Sentry system. Meaning, you can log in to Sentry, see the stack traces, how many times have happened, when the last one happened, and more information about the request depending on where it runs. It could be mobile, desktop, browser, who knows. But everything that you need to handle that exception should be at your fingertips. So of course, Komodor provide a way to present that information as part of their UI. Let's take a look. So here's the Komodor UI and our pretty healthy cluster that we've seen in the first tutorial. The first thing I want to do is

1:47 Sentry Setup Process

1:57 pop down to integrations where you'll see that I've already added Sentry to my Komodor setup. However, I'm gonna quickly walk you through the steps involved. So first, you need to go to Sentry. Sign up for an account. There is a free tier. Enjoy. From there, we go to settings and then developer settings. And here, you'll be able to add a new internal integration. You click next and fill in just a few details. Give it a name. I called mine Komodor. Not very inventive, but fit for purpose. From the Komodor side, when you go to add the Sentry integration, it will give you

2:42 a URL to use as the webhook URL. So don't make it up. Copy and paste. Next, you'll need to select project, read, and issue an event, read. Lastly, select tick box, on issue, and save. And you're good to go. From the Komodor side, scroll down, click install integration, and the URL that you need to copy is here. If you get confused at any point, jump to the Komodor documentation. Select integrations and Sentry, and I'll walk you through step by step. Now that we've done the setup, we need to cause a little bit of panic, pun intended,

3:24 Demonstrating Sentry Events in Komodor

3:30 as you'll see. First, you need to modify the deployment resource for your application. Here, I have a very simple deployment dot YAML for my application called Go Crash. In order to have Komodor connect the dots with Sentry, you will have to provide the Sentry DSN as an environment variable. I'm doing that as a hard coded value. As you can see, I would strongly encourage you to store this as a secret and mount it inappropriately. You can also set the Sentry environment to which I set it to production. So let's deploy this to my cluster with

4:16 the Komodor agent installed. We can run kubectl apply example app deployment.jaml. From here, we can run kubectl get pods to watch the rollout status of our application. And already, we can see that our application is in a crash loop back off. Let's head over to Komodor and see why. Alright. So here we are in the Komodor UI, and we can actually see that currently, Go Crash appears to be healthy. But if we click on it, we can see that this application has failed, had a brief stunt as maybe healthy, which I think was just being rescheduled on another node,

5:05 and then began to crash again. So in a moment, this will change to GoCrash being an unhealthy application. But we can already see down here that we have two notifications from Sentry itself. Now we'll see the code in a minute and why Sentry says, hey. It works. But this is me sending a default capture message or event to the Sentry system. And then we also see this is a test panic. So if we click on this, we get some more context. We can see that a Sentry issue was created, example three, with level fatal. And we can see that this is currently

5:44 unresolved. So if we click view issue on center, it takes us to here, where we can see the go run time for application is 01:19.5 running on a Linux machine, which is AMD sixty four. If you scroll down, we see the message that this is a test panic, as well as the packages available and the Go SDK version. Now these events are as rich as you want them to be by your instrumentation and the Go application. So let's take a look at that. If we open main.Go, you'll see my hard code is sent to DSN, which you really

6:25 Reviewing the Application Code

6:34 shouldn't do. Trust me. Do not do that. And then we'll see that we have the capture message I sent as a test to ensure that the central integration was working, followed by a panic. I'm explicitly telling this application to crash. So let's remove that and replace it with a hello world. Now I'm not going to go through the motions of committing, rebuilding the image, pushing this to cluster, pushing out a new deployment. Instead, I'm just gonna pop over and resolve. Now we can refresh the Komodor page and we'll see that this is a test panic has been resolved.

6:55 Resolving a Sentry Issue

7:27 Now this is a contrived situation, but it's important to know that if you instrument your application with a tool like Sentri, integrate it with Komodor, you can get real time information with that integration directly in the Komodor UI, and that is a cool feature. So it's time to say goodbye to Go Crash, and we'll move on to the next integration. So another tool that developers love to use well, I love to use, but I'll speak for all developers now, is Grafana, especially in coordination with Prometheus and Alert Manager. So let's pop down the integration list,

8:03 Prometheus Alert Manager Setup

8:06 And you'll see at the bottom left, we have an integration with Prometheus Alert Manager. If we click on this, we'll get another URL that we can hook up to our alert manager to inform Komodor when things are alerting. So let's copy this URL like so. So if you're not familiar with configuring alert manager, it all happens through a Kubernetes secret. Here's the one that I pulled out of my cluster. This is this generic Kube Prometheus install. However, to the receivers list, I've added one more. So all I need to do to get this into the alert manager in my cluster

8:51 is first secure it. And by secure, I mean, 64 encode. So let's cat my alert manager configuration, pipe it through base 64, and copy it in to my buffer. From here, I can edit the secret in my monitoring namespace called alert manager main. I can use my VIM shortcuts to say I want to change to the end of the line and drop in our new base 64 encoded config map and save. We can now pull the pods from the monitor namespace and delete all the alert manager pods forcing the configuration to be reloaded. Like so.

10:02 Next, we run a git and we'll see that our alert managers are coming up quite nicely. Now we can go to the alert manager UI by port forwarding to the service on port nine zero nine three. And if we go to status, scroll all the way down to the bottom, we'll see our Komodor webhook receiver configured. So now we're gonna make one more change to the alert manager config to tell it to start written some of our alerts to Komodor. And we're going to add matters receiver Komodor. This should send all alerts to Komodor like so.

10:49 So we rotate the alert manager pods one more time. So now if we go to status and scroll down, we'll see the Komodor root receiver and our webhook configuration. That's all it takes to start sending the alert manager letters to your Komodor instance. So let's pop back over to Komodor. Let's just get this reload for good measure. And it would appear that everything cell looks green, which is awesome. However, let's pop over to events. So already, we can see the top issue is from alert manager. A cube scheduler has disappeared from the Prometheus target discovery. This alert is still firing,

11:06 Demonstrating Alert Manager Events in Komodor

11:40 and we can see the summary, severity, alert name, and a description and runbook URL. Now because my Prometheus is not exposed on the public Internet, I'm going to right click and copy this address instead of clicking the link directly. From here, I can paste it in and just change the service name to be localhost. Now we have the Prometheus dashboard and the query that is triggering the alert. Now quickly before we finish, I wanna pop over to Grafana. Could Prometheus configures Grafana for us as well? And in fact, if we go to Grafana alerting, we'll see that we have seven filing,

12:14 Grafana Integration Setup

12:24 two pending, and everything else is normal. Now these are pretty much the same alerts from our alert month alert manager instance. So I'm gonna configure Grafana to speak to Komodor. We can click on the bell and go to contact points where we can create a new one. I'll call this Komodor. And this will be a webhook integration. We can drop the URL and click save. Next, we go back to the bell and see notification policies. And I'm gonna modify the root policy. I'm gonna set the default contact point to be Komodor and hit save. Of course, if you're familiar with Grafana, you

13:13 can set specific policies based on labels to match your own requirements. And it's as easy as that. Integrating Sentry, Grafana, and Prometheus with Alert Manager with Komodor brings you unprecedented context when debugging, when things go wrong. So I hope this guide was useful to you. There's one more part still to come where we'll be taking a look at automating the deploy of Komodor and vCluster. I'll see you then. Have a great day.