Delve into advanced Kubernetes features like monitoring, alerting, logging, and auto-scaling. Gain insights into creating resilient, self-adaptive clusters and applications with minimal manual intervention.

The world of DevOps has exploded with the help of technologies like Kubernetes and Docker.  
In this course, you will learn about more advanced Kubernetes features such as monitoring, alerting, logging, and scaling - crucial concepts for any DevOps professional. You will learn how to monitor clusters, how to send alerts when potential issues arise, and how to query the whole system’s metrics and logs. 
By the end of this course, you will have the required knowledge to make your clusters and applications truly dynamic and resilient, so that they require minimal manual involvement and are self-adaptive.

Advanced Kubernetes Techniques: Monitoring, Logging, Auto-Scaling


We explored how to create a dashboard with a graph and a single stat (semaphore). Both are based on similar queries, and the significant difference is in the way they display the results. We'll assume that the primary purpose of the dashboard we started building is available on a big screen, visible to many, and not as something we keep open on our laptops. At least, not continuously.

# Importing a dashboard

What should be the primary purpose of such a dashboard? Before I answer that question, we'll import a dashboard I created for this chapter.

Please click the *+* button from the left-hand menu and select *Import*. Type *9132* as the *Grafana.com Dashboard* and press the *Load* button. *Select a Prometheus data source*. Feel free to change any of the values to suit your needs. Nevertheless, you might want to postpone that until you get more familiar with the dashboard. In any case, click the *Import* button once you're finished.


## Configuration of resources in our cluster

You are likely to see one or more red semaphores. That's normal since some of the resources in our cluster are not configured properly. For example, `Prometheus` is likely to have less memory requested than it needs. That's OK because it allows us to see the dashboard in action. The definitions used in the Gists are not supposed to be production-ready, and you already know that you have to adjust their resources, and likely a few other things.

You'll notice that the dashboard we imported consists only of semaphores. At least, on the first look. Even though they might not be as appealing as graphs and other types of panels, they are much more effective as indicators of the health of our system. We do not need to look at that dashboard. It's enough if it's displayed on a big screen, while we work on something else. If one of the boxes turns red, we'll notice that. It will be a call to action. Or, to be more precise, we'll need to do something if a red box continues being red for longer, thus excluding the possibility that it's a false positive that will be resolved by itself after a few moments.

## Supplement to `Prometheus`'s alerts

You can think of this dashboard as a supplement to `Prometheus`'s alerts. It does not replace them, since there are some subtle, yet significant differences we'll discuss later.

I won't describe each of the panels since they are a reflection of the `Prometheus`'s alerts we created earlier. You should be familiar with them by now. If in doubt, please click on the "*i*" icon in the top-left corner of a panel. If the description is not enough, enter the panel's edit mode and check the query and the coloring options.

## Changing some variable values

Please note that the dashboard might not be the perfect fit as-is. You might need to change some of the variable values or the coloring thresholds. For example, the threshold of the *Nodes* panel is set to *4.5*. Judging by the colors, we can see that it'll turn orange (warning) if the number of nodes jumps to four, and red (panic) if it goes to five. Your values are likely to be different. Ideally, we should use variables instead of hard-coded thresholds, but that is currently not possible with `Grafana`. Variables are not supported everywhere. You, as a supporter of open source projects, should make a PR.

Does all that mean that all our dashboards should be green and red boxes with a single number inside them? I do believe that semaphores should be the "default" display. When they are green, there's no need for anything else. If that's not the case, we should extend the number of semaphores, instead of cluttering our monitors with random graphs. However, that begs the question; What should we do when some of the boxes turn red or even orange?

Below the boxes, you'll find the *Graph* row with additional panels. They are not visible by default for a reason. There is no justification for seeing them under normal circumstances. But, if one of the semaphores does raise an alert, we can expand *Graphs* and see more details about the issue.


In this lesson, we will see a better dashboard which I prepared for big screens.

Before Getting Started

Autoscaling Deployments and StatefulSets

Auto-Scaling Nodes Of A Kubernetes Cluster

Collecting and Querying Metrics and Sending Alerts

Debugging Issues Discovered Through Metrics and Alerts

Extending HorizontalPodAutoscaler With Custom Metrics

Visualizing Metrics And Alerts

Collecting And Querying Logs

Conclusion

A Better Dashboard for Big Screens

Importing a dashboard #