19. Telemetry - Metrics with Grafana

So we're coming to the end.

Now on this section where we've been focusing on telemetry features, we started with kiali promise, you really don't need to do anything special to make kiali work, as long as you have Istio running, and kiali will work, you don't need to do anything special to your code that gives a good high level view of exactly how your microservices or containers or pods are connected together.

And the traffic lines between them are incredibly valuable, we will be going into some more detail on kiali.

When we come to traffic management later in the course, in fact, I'll constantly be using lists to show the results of any changes that we make very, very powerful.

And we've seen Yeager distributed tracing incredibly useful and powerful with the potentially massive problem that unfortunately, do have to make changes to your code for this to work, or at least for it to work in a meaningful way.

So all of that is great.

But once you've identified that you have a problem with a particular service, let's say this staff service pod is performing really badly, then you can in kiali, go into the details of that service.

And you can look at the inbound metrics, which will give you graphs showing the request volume request durations, request and response sizes.

And you get the same data for the outbound metrics as well, it looks like on this particular service, the staff service is the end of a chain.

And it's not making any outbound calls by the look of it.

But there is another user interface that you can use.

And that's Grafana.

And you will find this by visiting your minikube IP address, colon 31 002.

Once again, that's just a node port that I've set up for you on the chapter towards the end of the course on installing Istio.

I'll show you how I did that.

But it's really not very complicated at all.

Now, I'm not going to talk very long at all about Grafana.

Because I'm sure many of you will have already used grafana.

Grafana is a very popular open source graphing framework that can show things such as charts, and graphs.

And it presents everything in the form of lovely dashboards, you can integrate grafana with a million different applications.

It's not just for Kubernetes.

But many of you will be familiar with the fact that often when we want to monitor a Kubernetes cluster, we want to monitor the health of the nodes, for example, in the cluster, then it's very, very common to use grafana connected to Prometheus, Prometheus, if you don't know it, is deployed into a cluster.

And it's responsible for scraping metrics.

So it will find out things like for example, the CPU usage of all of the physical nodes in your cluster, Prometheus gathers that together, and you connect grafana to it to give you some lovely charts.

So if you're not familiar with that, then I recommend you check out any good Kubernetes course, which might well have a section on Prometheus and grafana.

If you have used it, then you might be thinking, Well, why is this do also ship with refiner? The reason is that this is just a different set of monitoring tools, you're probably have been using it for monitoring, as I say, the physical hardware infrastructure that you've deployed, your Kubernetes cluster to Istio is concerned with much lower level details of the traffic moving between your pods.

And so they've produced a set of sort of standalone Grafana charts that giving you information about the traffic between the pots.

And that's what we have here.

So even if you've used it before, you will find this a different set of charts.

It's fairly self explanatory how to use this.

So I do invite you to have a play around for yourself with this and you'll soon get to grips with it.

But I will just in case you've not used it before, go through the basics of profiler.

And the main thing is you'll find a link top left here, the home link which if you drop that down, you will find a folder for Istio.

Now I've just clicked on there.

Don't be surprised if your minkube is struggling.

And you should kind of shorter resources you might get some slow responses here I've noticed in rehearsing that it can be a bit sluggish.

But assuming it's working, okay, you have what looks like a large collection of dashboards here at the time of recording.

There are eight of them.

Actually, from your applications point of view, really only two of them are useful.

That is the Istio service dashboard, and the Istio workload dashboard.

And it's a bit like kiali and that they've got this distinction between services and workloads.

Let's start with the work.

load.So for example

So Istio workload dashboard.

And first thing you want to do is to set the correct namespace for as its default.

And you will find then a list of all of your workloads.

Now remember, that doesn't quite mean pod, it means collection of pods that are grouped together for a particular service.

So for example, I could look at the staff service right here.

One minor change that they've made in the recent version of these dashboards, is they've compacted all of the information that appears on this chart into three sub headings.

And by default, these three sub headings have not been expanded.

So to get all the information, you'll need to click on each of these headers, to get information on the outbound services, the inbound workloads, and the general information.

And really, there's a lot of duplication across these user interfaces, you could probably have got this information from kiali.

But it's down to your own taste, really many people prefer grafana.

For this level of detail, the charts are nicer, they refresh better, and they and it can show a wider range of data.

But it's showing things such as the incoming request volumes and durations, the success rates definitely useful.

How many returned non 500 responses.

At present, this is healthy, with 100%.

So that's good.

I'll let you explore all of the little graphs in detail.

But some very important points about refiner.

The top right is showing the period that we're monitoring here, by default, it's just the last five minutes.

If you want the last hour, for example, then you need to drop this down and select the last hour.

And the refresh period is set by default to 10 seconds, I did find in rehearsing again, I was running out of resources on minkube and everything started slowing down.

And I thought it was wise to extend that to maybe refresh every 30 seconds or every minute.

And you do that using this drop down here.

So I'll set that to 30 seconds.

Now if you have a particular graph that you're interested in, such as the request duration, you can hover here, drop down, and select the View button.

And that will zoom into that particular graph.

And if you repeat that, then it will minimise it back onto the dashboard.

So this could be very useful and helpful.

You can see a big gap here, for example, I think that was just when I redeployed all of my pods to remove that automatic header propagation.

And then when the system came back, it looked like there was a kind of a period of thrashing as the new pods came in.

Let's zoom into a smaller region.

And you can do this on any of the graphs by clicking and dragging a particular area of interest.

And that's zoomed me in and it will actually change the range up here.

It's going a little further down more detail basically further down.

So I'd like to go into detail about this graph, incoming request duration by source, this will actually split the requests into separate graphs, depending on where the requests came from.

Now I've picked a bad one actually thinking about it for the staff service.

Because going back to kiali.

Actually, it looks like all the requests staff service come from a single source this position tracker.

But the position tracker looks more interesting because it's getting requests from the position simulator workload, and the API, gateway workload, whatever they are, you don't need to worry about what they are.

But we can see there's two routes traffic coming into position tracker.

So we can verify that if we switch to position tracker.

And we've got very similar data and very similar information here.

But just to show you this incoming request, duration by source, zoom in on that.

This is a potentially a bit more interesting, but it's also quite cluttered.

Just to get rid of this peak, I think I'll zoom into this middle section here.

Yeah, it's definitely cluttered this but the reason it's cluttered is we've got 12345678 different lines.

And the reason there's so many, is it showing me the fifth 95th 95th and 99th percentile.

I'm not entirely sure why they do the 95th here, but they do so we've got four different percentiles, but it's also split up by where the requests came from.

So we've got the 95th percentile, for example of the traffic coming in from From API gateway, and if I click on this key here, it will just show me that.

But I've also got the 95th percentile for the position simulator, which is right here.

So two different incoming routes.

If I wanted to compare these 290 fifth percentile, so I could hold down, I'm on Windows, so I'm holding down the Ctrl key here, I guess it would be the Command key on Mac.

If I click that, then it's allowing me to compare those two metrics, which could be quite useful if you know there's something in particular not performing.

So that's pretty much it really, there's a corresponding, again, going to the Istio folder here, there's a corresponding service dashboard, and you need to select the service you're interested in, we'll just look at one of our services, let's go for, I don't know the Fleetman staff service, it's pretty much duplicated information, really, you could get all of this from the workloads view as well.

So that's really it for those two dashboards.

And I would suggest you probably going to be using these dashboards, if you want to drill into a particular area of concern.

Maybe after you've used kiali.

Maybe after you've used Jaeger, the remaining dashboards are more concerned with monitoring Istio itself.

For example, there is at the time of recording a dashboard for the control plane.

Now on earlier versions of this course, actually, this particular dashboard was spread across I don't know four or five different dashboards, which reflected at the time the architecture of Istio.

But now that the architecture of the control plane is simpler than Soto is this dashboard, this isn't really a dashboard that I really need to look at too often, it's pretty low level, to be honest.

However, having said that, if you have any kind of performance problems with Istio, let's say it's taking up too much memory, or CPU on your cluster, I think you might find the istio performance dashboard to be useful.

Now this has given the kind of information that you actually get from a standard monitoring package.

So it's kind of things you're going to be familiar with memory usage, CPU usage, and disk usage, and so on.

So you could get that from a standard monitoring package.

But if you do have problems with stos performance, you might find this useful.

Again, it's not something that I've particularly used extensively.

Certainly in the more recent versions, Istio just performs pretty well.

However, there is one new dashboard, I don't know at what point this was introduced.

But I do find this one particularly useful.

It's called the Istio mesh dashboard.

And if we look at that one, it's a very simple dashboard.

But it gives you a very good top level view of what's happening across your entire architecture.

Just at a glance, I can see that in this system right now, the global success rates.

In other words, all of the non 500 responses from all of the requests that are pinging around my system is currently running at 100%.

So that is a very useful metric.

It's also going to give you information about the virtual services and destination roles that you have set up.

We don't have any yet purely because we haven't got there yet, that's coming up in the next section of the course on traffic management.

In fact, most of these knots applicables on row two, and three are the kinds of things we're going to be adding as we go through the course.

I think this is a very useful top level dashboard to give you a very quick and very rough overview of the health of your entire system.

And that really completes all of the dashboards, there is one further one called the w a s m.

Extension dashboard.

Now this is a method of extending Istio, which is a very advanced feature.

It's not something I'm currently planning to cover on this course, it might be something I add in the future, or would probably more likely be something that would fit well on an advanced this do course, for me the day to day dashboards of the service dashboard, and the workload dashboard.

And as I say, you might also find the very high level is the mesh dashboard useful as well.

That's it for this section of the course I hope you'll find these telemetry features to be really useful for any project.

But in the next section of the course, we're going to start looking at the features of Istio that allow us to influence the behaviour of our system.

We're going to start by looking at how to manage the traffic flow through your system in the section called traffic routing.

I'll see you for that

이제 마지막을 향해 갑니다.

원격 측정 기능에 초점을 맞춘 이 섹션에서는 키알리 약속부터 시작했는데, 키알리 작업을 위해 특별한 작업을 할 필요가 없습니다. Istio를 실행하는 한, 키알리가 작동하는 한, 마이크로 서비스나 마이크로 서비스를 포함하는 방법에 대해 높은 수준의 정보를 제공하는 코드에서 특별한 작업을 수행할 필요가 없습니다.er 또는 팟이 서로 연결되어 있습니다.

그리고 그들 사이의 교통 회선들은 믿을 수 없을 정도로 가치가 있습니다. 우리는 키알리에 대해 좀 더 자세히 알아볼 것입니다.

사실, 나중에 교통 관리에 관해 이야기 할 때, 저는 계속해서 목록을 사용하여 우리가 아주, 아주 강력하게 변화시킨 결과를 보여드릴 것입니다.

그리고 우리는 Yeager가 잠재적으로 엄청난 문제를 가지고 추적하는 것을 보았습니다. 불행히도 이 문제가 작동하기 위해서는 코드를 변경해야 합니다. 적어도 의미있는 방법으로 작동하려면 말이죠.

그래서 그 모든 것이 훌륭하다.

하지만 특정 서비스에 문제가 있는 것으로 확인되면, 이 직원 서비스 포드의 성능이 매우 나쁘다고 가정해 보겠습니다. 그러면 키알리를 통해 해당 서비스의 세부 사항을 살펴볼 수 있습니다.

또한 요청 볼륨 기간, 요청 및 응답 크기를 보여주는 그래프를 제공하는 인바운드 메트릭을 확인할 수 있습니다.

아웃바운드 메트릭에 대한 동일한 데이터도 얻을 수 있습니다. 이 특정 서비스에서는 직원 서비스가 체인의 끝인 것처럼 보입니다.

외견상으로는 어떤 외부 전화도 하지 않습니다.

그러나 사용할 수 있는 다른 사용자 인터페이스가 있습니다.

그라파나입니다.

그리고 당신은 당신의 미니큐브 IP 주소인 콜론 31002를 방문하면 이것을 찾을 수 있을 것이다.

다시 한 번 말씀드리지만, 이 포트는 Istio 설치 과정의 마지막 장을 향해 설정한 노드 포트입니다.

내가 어떻게 했는지 보여줄게.

하지만 그것은 전혀 복잡하지 않습니다.

이제, 저는 그라파나에 대해 그리 길게 얘기하지 않겠습니다.

왜냐하면 여러분 중 많은 분들이 그라파나를 이미 사용했을 것이기 때문입니다.

그라파나는 차트, 그래프와 같은 것들을 보여줄 수 있는 매우 인기 있는 오픈 소스 그래프 프레임워크이다.

그리고 모든 것을 멋진 대시보드의 형태로 보여주며, 그라파나와 백만 개의 다양한 애플리케이션을 통합할 수 있습니다.

이건 쿠베르네테스만을 위한 것이 아니다.

하지만 여러분 중 대부분은 Kubernetes 클러스터를 모니터링하고자 할 때, 예를 들어 클러스터에서 노드의 상태를 모니터링하려고 합니다. Prometeus, Prometheus에 연결된 Grafana를 사용하는 것이 매우 일반적입니다. 잘 모르면 클러스터에 배포됩니다.

그리고 메트릭스 스크랩을 담당합니다.

예를 들어, 클러스터에 있는 모든 물리적 노드의 CPU 사용량, Prometheus가 이를 한데 모아 Grafana를 연결하여 멋진 차트를 제공하는 등의 작업을 수행할 수 있습니다.

그래서 만약 여러분이 그것에 대해 잘 모르신다면, 저는 여러분이 프로메테우스와 그라파나에 관한 섹션이 있을 수 있는 어떤 좋은 쿠베르네테스 코스든지 확인해 보시기를 권합니다.

만약 그것을 사용했다면, 여러분은 아마 이렇게 생각할지도 모릅니다. 음, 왜 이것이 또한 정유사와 함께 선적되는 것일까요? 그 이유는 이것이 단지 모니터링 툴의 다른 집합이기 때문입니다. 아마도 여러분은 이 툴을 모니터링에 사용해왔을 것입니다. 여러분이 구축한 물리적 하드웨어 인프라와 같은 Kubernetes 클러스터를 Istio로 이동하는 트래픽의 훨씬 더 낮은 세부 정보와 관련이 있을 것입니다.

그래서 그들은 항아리들 사이의 트래픽에 대한 정보를 제공하는 일련의 독립 실행형 Grafana 차트를 만들었습니다.

그리고 그것이 우리가 여기 가지고 있는 것입니다.

이전에 사용하셨더라도 다른 차트 집합을 찾을 수 있습니다.

이것을 어떻게 사용하는지는 꽤 자명하다.

그래서 저는 여러분이 이것을 가지고 놀도록 초대합니다. 그러면 여러분은 곧 그것을 이해할 수 있을 것입니다.

하지만 혹시 전에 사용하지 않으셨다면 프로파일러의 기본 사항을 살펴보도록 하겠습니다.

그리고 중요한 것은 여기 왼쪽의 링크 상단을 찾을 수 있고, 홈 링크를 내려놓으면 Istio를 위한 폴더가 있다는 것입니다.

이제 막 클릭을 했습니다.

당신의 밍크튜브가 힘들어도 놀라지 마세요.

그리고 좀 더 짧은 리소스는 제가 리허설에서 알아본 바로는 좀 느릴 수 있습니다.

하지만 작동한다고 가정하면, 녹화할 때 여기에 있는 많은 대시보드 모음처럼 보이는 것이 있습니다.

8명이에요.

실제로 애플리케이션 관점에서 볼 때 두 가지 애플리케이션만 유용합니다.

이것이 Istio 서비스 대시보드와 Istio 워크로드 대시보드입니다.

Kiali와 비슷하며 서비스와 워크로드의 차이를 가지고 있습니다.

그 일부터 시작합시다.

짐을 싣다

Istio 워크로드 대시보드입니다.

먼저 올바른 네임스페이스를 기본값으로 설정하는 것이 좋습니다.

그러면 모든 워크로드 목록이 표시됩니다.

기억하십시오. 이것은 팟을 의미하는 것이 아닙니다. 특정 서비스를 위해 함께 묶인 팟을 의미합니다.

예를 들어, 여기 직원 서비스를 볼 수 있습니다.

이러한 대시보드의 최근 버전에서 수행한 사소한 변경 사항 중 하나는 이 차트에 표시되는 모든 정보를 세 개의 하위 제목으로 압축했다는 것입니다.

기본적으로 이 세 개의 하위 제목은 확장되지 않았습니다.

따라서 모든 정보를 얻으려면 각 헤더를 클릭하여 아웃바운드 서비스, 인바운드 워크로드 및 일반 정보를 확인해야 합니다.

그리고 실제로 이러한 사용자 인터페이스에는 많은 중복이 있습니다. 아마 키알리에서 이러한 정보를 얻을 수 있었을 것입니다.

하지만 그건 당신 취향에 따라 달라, 정말 많은 사람들이 그라파나를 선호해요.

이 수준의 세부 정보를 위해 차트가 더 좋고, 새로 고침이 더 잘되며, 차트와 차트가 더 넓은 범위의 데이터를 표시할 수 있습니다.

그러나 수신 요청 볼륨과 기간, 성공률 등과 같은 것들을 보여주고 있습니다.

500개가 아닌 반환된 응답 수입니다.

현재, 이것은 100%로 건강합니다.

그래서, 그거 좋네요.

모든 작은 그래프를 자세히 살펴보도록 하겠습니다.

하지만 정유사에 관한 아주 중요한 점들이 있습니다.

오른쪽 상단에는 우리가 감시하고 있는 기간이 나와 있습니다. 기본적으로 마지막 5분입니다.

예를 들어, 마지막 시간을 원하는 경우 이 시간을 삭제하고 마지막 시간을 선택해야 합니다.

리프레쉬 기간은 기본적으로 10초로 설정되어 있습니다. 리허설을 다시 해보니 밍큐브에 대한 자원이 부족했고 모든 것이 느려지기 시작했습니다.

30초마다 또는 매분마다 새로 고치는 것이 현명하다고 생각했습니다.

그리고 여기 이 방울을 이용해서 이렇게 합니다.

30초로 설정하겠습니다.

이제 요청 기간과 같이 관심 있는 특정 그래프가 있는 경우 여기를 마우스 오른쪽 단추로 클릭하고 드롭다운을 클릭한 다음 보기 버튼을 선택할 수 있습니다.

그러면 특정 그래프가 확대됩니다.

이 작업을 반복하면 대시보드에 최소화됩니다.

그래서 이것은 매우 유용하고 도움이 될 수 있습니다.

예를 들어, 제가 자동 헤더 전파를 제거하기 위해 모든 포드를 재배치했을 때처럼 큰 차이를 볼 수 있습니다.

그리고 시스템이 다시 돌아왔을 때, 새로운 꼬투리가 들어올 때 일종의 격돌의 시기가 있는 것처럼 보였습니다.

좀 더 작은 지역으로 확대해보죠.

특정 관심 영역을 클릭하여 끌어다 놓으면 그래프에서 이 작업을 수행할 수 있습니다.

그리고 그것이 저를 확대시켜주었고, 실제로 여기까지의 범위를 변화시킬 것입니다.

기본적으로 좀 더 세부적으로 내려가고 있습니다.

그래서 저는 이 그래프에 대해 자세히 설명하고자 합니다. 소스별로 들어오는 요청 지속시간입니다. 이 그래프에서는 요청을 보낸 위치에 따라 요청을 별도의 그래프로 분할합니다.

사실 직원 서비스를 위해 고민하고 있는 나쁜 사람을 골랐어요.

왜냐하면 키알리로 돌아가기 때문이다.

사실, 직원 서비스는 이 위치 추적기의 단일 소스에서 온 것 같습니다.

하지만 위치 추적기는 위치 시뮬레이터 워크로드, API, 게이트웨이 워크로드 등으로부터 요청을 받기 때문에 어떤 작업인지 걱정할 필요가 없기 때문에 더 흥미로워 보입니다.

하지만 위치추적기로 들어오는 두 가지 경로를 볼 수 있습니다.

그래서 위치추적기로 바꾸면 확인할 수 있습니다.

그리고 우리는 매우 유사한 자료와 매우 유사한 정보를 가지고 있습니다.

하지만 들어오는 요청을 보여드리기 위해서, 소스별로 기간을 확대해서 보여드리겠습니다.

이것은 잠재적으로 좀 더 흥미로울 수 있지만, 또한 꽤 어수선하다.

이 봉우리를 없애기 위해, 여기 가운데 부분을 좀 더 확대해야겠어요.

네, 확실히 어수선한데 어수선한 이유는 12345678개의 다른 회선이 있기 때문이에요.

많은 사람들이 있는 이유는 95번째와 99번째 백분위수를 보여주기 때문입니다.

95번째 백분위수를 왜 사용하는지는 잘 모르겠습니다만, 4개의 백분위수를 가지고 있습니다. 하지만 요청사항이 어디서 왔는지에 따라서도 분할됩니다.

95번째 백분위수가 있습니다. 예를 들어, API 게이트웨이에서 들어오는 트래픽의 예를 들자면, 여기서 이 키를 클릭하면, 이 값이 표시됩니다.

하지만 여기 위치 시뮬레이터의 95번째 백분위수도 있습니다.

두 개의 다른 경로입니다.

만약 제가 이 290개의 5분의 1 백분위수를 비교하고 싶다면, 저는 윈도우에 있고, 여기 Ctrl 키를 누르고 있습니다. 이것이 Mac의 Command 키일 것입니다.

이 버튼을 클릭하면 이 두 가지 측정 기준을 비교할 수 있습니다. 특히 수행되지 않는 것이 있다는 것을 아실 경우 매우 유용할 수 있습니다.

이것이 거의 다입니다. 여기 Istio 폴더에도 해당됩니다. 여기에 해당하는 서비스 대시보드가 있습니다. 그리고 관심 있는 서비스를 선택하시면 됩니다. 저희 서비스 중 하나를 살펴보도록 하죠. 플리트먼 직원 서비스는 잘 모릅니다. 정말 중복된 정보입니다. 이 모든 것을 워크로드 뷰에서도 확인할 수 있습니다.

이제 이 두 대시보드에 대한 설명입니다.

특정 관심 분야를 자세히 살펴보려면 이 대시보드를 사용할 것을 제안합니다.

아마 키알리를 사용한 후에.

Jaeger를 사용한 후에는 나머지 대시보드가 Istio 자체 모니터링에 더 관심을 가질 수 있습니다.

예를 들어 제어 평면에 대한 대시보드를 기록할 때가 있습니다.

이 과정의 이전 버전에서는, 실제로 이 특정 대시보드가 4~5개의 다른 대시보드에 분산되어 있었습니다. 이 대시보드는 Istio의 아키텍처를 반영했습니다.

하지만 이제 제어면의 구조는 이 대시보드보다 더 간단해졌습니다. 사실 이것은 제가 너무 자주 볼 필요가 있는 대시보드는 아닙니다. 솔직히 말하자면 상당히 낮은 수준이죠.

하지만 Istio에 성능 문제가 있는 경우 클러스터의 CPU나 메모리를 너무 많이 소모한다고 가정해 보면 Istio 성능 대시보드가 유용할 수 있습니다.

이제 표준 모니터링 패키지에서 실제로 얻을 수 있는 정보를 제공합니다.

메모리 사용량, CPU 사용량, 디스크 사용량 등에 익숙해질 것입니다.

따라서 표준 모니터링 패키지에서 얻을 수 있습니다.

그러나 stos 성능에 문제가 있는 경우 이 기능이 유용할 수 있습니다.

다시 말씀드리지만, 제가 특별히 많이 사용한 것은 아닙니다.

확실히 더 최신 버전에서는 Istio가 꽤 좋은 성능을 발휘합니다.

하지만 새로운 대시보드가 하나 있습니다. 이 대시보드가 어느 시점에 도입되었는지 모르겠습니다.

하지만 저는 이것이 특히 유용하다고 생각합니다.

이것은 Istio mesh 대시보드라고 불립니다.

이걸 보시면, 매우 간단한 대시보드입니다.

하지만 전체 아키텍처에서 발생하는 상황을 매우 잘 파악할 수 있습니다.

한 눈에, 저는 지금 이 시스템에서 세계적인 성공률을 볼 수 있습니다.

즉, 시스템에서 ping을 수행하는 모든 요청의 500개 미만의 응답은 모두 현재 100%로 실행되고 있습니다.

그래서 그것은 매우 유용한 지표이다.

또한 설정한 가상 서비스 및 대상 역할에 대한 정보도 제공합니다.

아직 도착하지 않았기 때문에 아직 순수하게 아무것도 없어요, 교통 관리에 관한 다음 코너에 나올 거예요.

사실, 이 매듭의 대부분은 2열과 3열에서 적용되고 있습니다. 우리가 이 과정을 거치면서 추가하게 될 것들입니다.

이 대시보드는 전체 시스템의 상태를 매우 빠르고 대략적으로 살펴볼 수 있는 매우 유용한 대시보드라고 생각합니다.

이렇게 하면 모든 대시보드가 완성됩니다. Wash라고 불리는 또 다른 대시보드가 있습니다.

확장 대시보드.

이제 이것은 Istio를 확장하는 방법인데, 이것은 매우 진보된 기능입니다.

현재 본 코스에서 다루려고 하는 것은 아니며, 향후에 추가할 수도 있고, 서비스 대시보드의 일상적인 대시보드와 워크로드 대시보드에 적합한 고급 작업 코스가 될 수도 있습니다.

제가 말씀드린 것처럼, 여러분은 또한 매우 높은 레벨은 메쉬 대시보드도 유용하다는 것을 알게 될 것입니다.

여기까지입니다. 원격 측정 기능이 모든 프로젝트에 매우 유용하게 사용되었으면 합니다.

하지만 이 과정의 다음 섹션에서는 시스템의 행동에 영향을 미칠 수 있는 Istio의 기능에 대해 알아보겠습니다.

먼저 트래픽 라우팅 섹션에서 시스템을 통과하는 트래픽 흐름을 관리하는 방법을 살펴보겠습니다.

그것 때문에 보자.