16. Telemetry - Using Jaeger UI

So that's the background of Yeager, I've had the system running for a while now.

And the Jaeger UI is essentially a search engine.

And this search engine allows us to search for traces based on particular criteria, let me take you through the search box, there is one compulsory field that you have to fill in here.

And that's the service field.

And notice, I can't find traces that buttons not active until I've selected a service here.

So this is just the list of services that you have in your system.

And by selecting a service from here, for example, the webapp, you're saying that you want to find all traces that have a span that have crossed through that particular service.

So this doesn't mean that you're looking for traces that start from that service or ending that service, it will be all traces that have in some way visited the service you've chosen.

Now, I'm not seeing any services in this drop down list.

And that's purely because I started up this Jaeger UI, before I started this application running.

So it's just that when I launched this UI, Jaeger hadn't received any data yet.

So I'm just saying, really, if you don't see anything there, you might want to try refreshing.

And sure enough, now the system's up and running, I am getting eight services in that list.

So what I'm wanting to do in this demo is I'm wanting to do a little bit of investigation as to what happens when I click on one of these vehicles on the left hand side, clearly, the screen refreshes, and we get a new vehicle.

But we also get the photograph and name of the driver of that vehicle.

And let's say we've got some problems with that performance problems or whatever.

I think the sort of really only slightly difficult thing about working with distributed tracing is actually finding your traces.

So we know that the trace we're looking for does go through the web app components, we'll look at some of these other search fields in a moment.

But if I click find traces, then I'm getting back quite a lot of traces.

Here, it's 20 of them.

And in fact, that was the limit.

So there was probably more of these then and they've been filtered out, however many you get will depend on how much you've been doing with that front end.

So we've got to kind of go through these results and work out the one we're looking for, which can be a little bit daunting, but we often do in real life, rather than worrying about individual traces is, we'll probably work with this histogram up at the top, which shows the duration of the traces.

So that's how long an entire request going all the way through the system and back took.

And we've got quite a well behaved system in this section of the course.

So the longest duration we're seeing here is something around the 300 milliseconds mark, which I don't think is particularly worrying.

But in real life, if you were doing this, you could obviously, very easily spot any outliers, any particularly slow traces.

And that will allow you to drill down, so you can click on any of these circles, and go straight to the corresponding trace, I want to look for the specific trace, though, which is relating to finding this driver's photograph.

How to do that? Well, I would suggest, first of all, just to show you a few more of these boxes, we can, for example, change the look back period, the options actually only allow you to extend the period, two hours, three hours, and so on.

But you do have the option of a custom time range.

Now just looking at the clock, The clock, the time for me right now is 1832.

So I think I'll do is I'll set this custom range just to look at old traces from 1832.

onwards, and then we want to search for all traces that have happened after that time.

I'm not sure if there's a clever way of doing this, I did try what I what I always do here is just switch the end dates, find the day and just tick that up by one.

Or you could change the year or whatever.

And I just tried off camera, hitting the X button here to clear this field in the hope that would mean to search forwards.

But it didn't work.

Just got an error back.

It didn't look nice.

So I've edited that out.

I hope you get the point.

What I'm doing here is I'm saying look for all all traces that have gone through the web app components from 1832 onwards.

And I think if I click find traces and hoping for perfect will getting no results.

Now that's certainly working in this system because if the if a user doesn't do anything with them, front end, when the web app component doesn't get any requests, there are requests firing around inside the system going from various micro services to other micro services.

It's just that the web app is only going to respond to a user's interactions.

I really don't want to get into the implementation of this system.

And I wrote this system so long ago, I can't remember myself.

But you might be wondering, how is this vehicle moving by itself? While the web app isn't doing anything, they're actually these are WebSocket messages that are being passed straight to this JavaScript application.

So anyway, the web app does nothing unless you refresh here, or select a vehicle.

So I've just done that.

So we can be absolutely sure.

If I click find traces again, yeah, just to prove it, nothing there no new traces.

And I want to do that just so I can correlate what is going to happen.

When I click on a vehicle, I'll go for the city truck, and I just clicked once we've seen the screen refresh, we've got the vehicle being followed.

And we've got this red line tracking where it's been.

If I now switch across to Yeager and simply repeat that previous search, we're now getting three results returned, you might be surprised that we're getting three results back.

Basically, what's happened as a result of that single click on the user interface, we've ended up with three separate HTTP requests running through the system.

I'll try to explain why there's three towards the end of this video.

But very helpfully on each of these three traces, there's a summary as to which services each traces run through, it looks at first glance, this one in the middle isn't really doing very much, it's just some kind of request that simply gone to the web app.

Whereas the other two traces, the requests have visited several services.

So the one at the bottom here, appears to have gone through the API gateway, and then gone to the position tracker.

Whereas with the other trace, yeah, it's gone through the API gateway.

But this time, it's also visited the staff service, which, if you remember, that's the one I said, imagine we're having problems with, we've got bad performance or something on the staff service.

So I'll come back to the other two traces.

But it looks like it's this Trace here, that we're interested in.

So just click anywhere in this area to expand out the full detail.

By the way, the checkbox here is for if you've got several traces that are similar, you can select them, and then you can compare them, which is sometimes useful.

But in our case, we're not comparing spans, we just want the details.

So don't click the checkbox, just click anywhere in this area.

And you recognise this graph.

Now from the made up graph that I showed you in the previous video.

There's obviously quite a bit more detail on here.

But the principle is exactly the same.

The first thing I'll address is, and I still find this confusing is that you are going to see repetitions of services here, I mentioned that at the end of the last video, that's because of the presence of the proxies.

Now, when you're working with more complicated systems than this, I do find this graph can be a little bit overwhelming at first.

So don't worry if you have to sit down with a graph for quite a long time studying it and looking at it from different angles and trying to work out exactly what's going on.

I mean, this is a very simple system.

But even here, there are a few confusing aspects.

A little bit of advice here is I do find it useful to collapse this diagram at first.

And for example, if I collapse this arrow here, I think that's showing quite a useful view really.

And it's similar to what I did on the caption in the previous video, I'm just looking now at the top level detail, I can see that the request overall, even if it's gone through lots of micro services along the way, the total aggregates of that request this this bar here running across the entire length of the screen, it's only 10 and a half milliseconds in this case, but that's the entire duration of a single request going all the way through the system.

And the second line giving the next level of detail.

It's saying that the next thing that happened was that the web app passed on a request to another micro service, this one called the API gateway.

And notice it's got its own colour.

And the graph here is showing that the web app spent a short amount of time doing something and then the API gateway took over.

Now can tell you what that little bit of something is there is actually the proxy doing its work and that's why I'm Previously, that that's why we're seeing two entries for the web app.

It's just really so you can see the actions of the proxy as the request is being sent out.

And there's also some action from the proxy, when the API gateway is returned back to the web app.

Now, you're not usually interested in that detail.

So I must admit, I find that a little bit confusing on this graph.

Really, if I expand it back, we were only expecting three spans because there are three microservices in the chain here.

But as I mentioned, for everyone along the way, apart from the last one, you will see this doubling up.

But really, as long as you've understood the caption in the previous video, then this should be pretty straightforward.

If we had timing problems with that staff service, then it would be apparent here, from the length of this bar, were running with what I think is a well performing version of this application.

So we're actually seeing nothing worrying here.

But it would be that line that we're interested in.

Now useful user interface detail here is, if this is the area of concern, this is the thing we're interested in, then you can always hover on the timeline here at the top.

If you want to focus in on a particular area of the timeline, you can swipe your mouse, just across the area you're interested in, and then everything will zoom into that area.

This plan here at the top is showing you all of the spans, but this time without any detail on so you can get a very good kind of high level plan of what's going on.

And again, you can select areas of that timeline by swiping your mouse.

And finally there is a button on there called reset selection, which will expand the timeline to the full extent of the request.

So lots of really useful information there.

But the last thing I want to address is why did we see three separate traces when I only clicked once on the user interface? Well, it's an implementation detail, really, it's something that I would ask the developer about.

And they will tell me that, well, when you click on one of these vehicles, then the implementation of this user interfaces, it sends out three separate HTTP requests.

And again, you can give us some further information about why there are three separate HTTP requests.

Actually one of them isn't very interesting.

That's this one here with just one span inside it.

If we do drill into this one, yeah, there's nothing interesting, because with only one span, we can just see that there was a request.

And it only lasted for looks like about half a millisecond.

But one other thing we can do, and it won't be useful here, but it will be useful for the other two traces, is we can take any of these spans, and click on them.

And we get the full information about that HTTP request.

And it's via these tags here.

If you click on the arrow, then you get a nice table.

And that will show you all the details of that HTTP request.

So we can see that this was HTTP GET request.

It happens return http 200.

And most usefully of all, is this is the URL that was requested.

And there's some further flags down here, but I'll focus on the URL that is often going to give some really useful information.

It's a long time ago that I wrote this app.

And I actually can't remember why it's sending a request to the URL here ending in a question mark.

It's something actually I wasn't expecting to pop up on the recording just off camera, I've been scratching my head a little bit.

And it's certainly something potentially for further investigation.

But you know what, I just don't think it's very interesting.

I suspect, it's the framework that I use to develop this user interface, it happens to be Angular, I think it's just sending some kind of a request for some resource when I'm clicking on those links.

Whatever it is, it's not very interesting.

And I don't think it's a bug or anything I think it's expected.

However, we can use exactly the same technique to find out more information about the other two traces, these two traces are clearly doing something interesting.

If we're going to the trace that we were working on before the one that goes into the staff service.

I click on that, then again, for any of these, I can click on them, and then drop down the table.

And I get all that really useful information such as I can see the user agents here is Java.

So I know now the implementation of this service, but also really usefully, I can see its URL, and the URL is ending forward slash driver forward slash city truck.

Now we know from the user interface that when we click on any of the vehicles, we get information about the driver, we get the name of the driver and we also get a photograph of the driver.

So it looks very likely that the reason for this request being generated was to get details of the driver.

But if I go back, why was there another separate request? Well, again, by going into that we've got the full trace, we can look at all the timing data.

But this time around, actually, if we click on any of these, we're going to see the URLs that are being requested gives us a good clue.

The URL here looks like it's a REST request for a resource called history.

And in this case, it was the history of the city truck.

Even if you're not familiar with this system, you might have noticed that whenever we're selecting these vehicles, we are getting the history of where that truck has been.

Even if you've not looked at a single line of code of this system, using Yeager, we've been able to find out not just timing problems and where there might be bottlenecks in the system.

But we can also see that that single click that we made on the user interface has generated three requests, one of which doesn't look very useful.

One of them was generating the history line, and one of them was getting the information that's being presented down here, I realise you're probably not very interested in the implementation of this system, but you are interested in your own systems.

I hope with a little bit of practice, it's not always easy to understand what the trace is telling you, you sometimes need to sit and study them in some detail, but I hope you're going to find this a really useful tool.

Now, that was the sales pitch for Yeager.

And distributed tracing in general, do experiment for yourself.

But unfortunately, there is one big problem with tracing in Istio This is one area where this isn't going to work for you unless you make it happen.

So in the next video, I'm going to talk about the fact that you need to make sure you propagate some headers through your system if you want this to work.

If that doesn't mean anything to you, then stay tuned.

In the next video we'll look at that in detail.

But from this part of the videos, I hope you've got a good feel for what distributed tracing can do for you a very powerful telemetry feature

그게 예거의 배경입니다. 저는 한동안 시스템을 작동시켜 왔습니다.

그리고 Jeger UI는 본질적으로 검색 엔진입니다.

이 검색엔진을 통해 특정 기준에 따라 흔적을 찾을 수 있습니다. 검색란을 살펴보도록 하죠. 여기에 기입해야 할 필수 항목이 하나 있습니다.

그리고 그것이 서비스 분야입니다.

여기서 서비스를 선택하기 전에는 버튼이 활성화되지 않은 흔적을 찾을 수 없습니다.

이 목록은 시스템에 있는 서비스 목록입니다.

웹앱과 같은 서비스를 선택함으로써 특정 서비스를 통해 전달되는 모든 흔적을 찾고자 하는 것입니다.

따라서 이는 해당 서비스에서 출발하거나 서비스를 종료하는 추적을 찾는다는 뜻이 아닙니다. 선택한 서비스를 방문한 모든 추적입니다.

이 드롭다운 목록에는 서비스가 없습니다.

그리고 그것은 순전히 제가 이 Jeger UI를 시작했기 때문입니다. 제가 이 애플리케이션을 실행하기 전에 말이죠.

제가 이 UI를 시작했을 때, Jaeger는 아직 데이터를 받지 못했습니다.

그러니까 제 말은, 만약 여러분이 아무것도 보지 못한다면, 여러분은 상쾌하게 해 보고 싶을지도 모른다는 겁니다.

물론, 이제 시스템이 가동되고 있습니다. 이 목록에서 8개의 서비스를 받고 있습니다.

그래서 제가 이 데모에서 하고 싶은 것은 왼쪽에 있는 이 차량들 중 하나를 클릭했을 때 어떤 일이 일어나는지 조사하려고 합니다. 화면이 새로 고쳐지고, 새로운 차량이 등장합니다.

하지만 우리는 또한 그 차량의 운전기사의 사진과 이름도 알아냅니다.

성능 문제나 기타 문제에 문제가 있다고 가정해 보겠습니다.

저는 분산 추적을 하는 데 있어서 아주 조금 어려운 점은 실제로 여러분의 흔적을 찾는 것이라고 생각합니다.

우리가 찾고 있는 추적이 웹 앱 구성 요소를 통과한다는 것을 알고 있습니다. 잠시 후에 다른 검색 필드를 살펴보도록 하겠습니다.

하지만 만약 내가 흔적 찾기를 클릭한다면, 나는 꽤 많은 흔적들을 되찾을 수 있을 것이다.

자, 20개입니다.

그리고 사실, 그것이 한계였습니다.

아마 그때에는 이것들이 더 많았을 것이고 그것들은 걸러졌을 것입니다. 하지만 여러분이 얻는 많은 것들이 여러분이 그 프런트 엔드로 얼마나 많은 것을 해왔는지에 달려 있을 것입니다.

그래서 우리는 이러한 결과를 통해 우리가 찾고자 하는 결과를 알아내야 합니다. 조금 부담스러울 수 있지만, 우리는 종종 실제 생활에서 합니다. 개인의 흔적을 걱정하기 보다는, 우리는 아마도 이 히스토그램을 맨 위에 올려놓고 그 흔적들의 지속시간을 보여주는 작업을 할 것입니다.

그래서 모든 요청이 시스템을 통과하고 되돌아오는 데 걸린 시간이 바로 그것입니다.

그리고 우리는 이 코스의 이 부분에서 꽤 잘 동작하는 시스템을 가지고 있습니다.

여기서 우리가 볼 수 있는 가장 긴 시간은 약 300밀리초 정도입니다. 특별히 걱정되는 것은 아닙니다.

하지만 현실에서, 만약 여러분이 이렇게 한다면, 여러분은 분명히 어떤 특이치, 특히 느린 흔적을 쉽게 발견할 수 있을 것입니다.

이렇게 하면 드릴다운을 할 수 있습니다. 이 원들 중 아무거나 클릭하면 해당 자취로 바로 갈 수 있습니다. 저는 이 운전자의 사진을 찾는 것과 관련된 구체적인 자취를 찾고 싶습니다.

어떻게 하는 거야? 우선, 이 상자들 중 몇 개를 더 보여드리기 위해서, 예를 들어, 우리는 되돌아보는 기간을 바꿀 수 있습니다. 그 옵션들은 단지 기간을 2시간, 3시간 등만 연장할 수 있습니다.

하지만 사용자 지정 시간 범위 옵션이 있습니다.

지금 시계를 보니, 지금 제 시각은 1832년입니다.

그래서 저는 1832년의 옛 흔적을 보기 위해 이 맞춤식 범위를 정해야 한다고 생각합니다.

이후 발생한 모든 흔적을 찾고자 합니다

이걸 하는 영리한 방법이 있을지 모르겠어요. 제가 항상 여기서 하는 일은 그냥 날짜를 바꾸고, 날짜를 찾고, 하나씩 체크하는 거예요.

아니면 연도를 바꿀 수도 있고 뭐 그런 걸 바꿀 수도 있어요.

저는 카메라를 끄고 X버튼을 눌러 이 필드를 지우는 것을 희망합니다. 앞으로 검색해 보라는 뜻이죠.

하지만 그것은 작동하지 않았다.

방금 오류가 반환되었습니다.

별로 안 좋아 보이던데.

그래서 내가 그걸 편집했어.

당신이 요점을 알아냈으면 좋겠어요.

제가 여기서 하는 일은 1832년 이후 웹 앱 구성 요소를 통해 모든 흔적을 찾는 것입니다.

그리고 만약 내가 흔적 찾기를 클릭하고 완벽하기를 바란다면 아무런 결과도 얻지 못할 것이라고 생각한다.

이 시스템은 사용자가 아무것도 하지 않는다면 프런트엔드에서 웹 앱 구성 요소에 대한 요청이 없을 때 시스템 내부에서 다양한 마이크로 서비스에서 다른 마이크로 서비스로 이동하기 때문에 작동합니다.

웹 앱은 사용자의 상호 작용에만 응답합니다.

나는 정말로 이 제도의 시행에 관여하고 싶지 않다.

저는 이 시스템을 아주 오래전에 썼는데, 제 자신이 기억나지 않습니다.

하지만 여러분은 궁금하실지도 모릅니다. 이 차량이 스스로 어떻게 움직이고 있을까? 웹 앱은 아무 것도 하지 않지만, 실제로 이러한 메시지는 이 JavaScript 애플리케이션에 바로 전달되는 웹 소켓 메시지입니다.

따라서 여기서 새로 고침을 하거나 차량을 선택하지 않는 한 웹 앱은 아무 작업도 수행하지 않습니다.

그래서 그냥 해버렸습니다.

그래서 우리는 절대적으로 확신할 수 있다.

다시 한번 흔적을 찾으면, 네, 그걸 증명하기 위해서요, 새로운 흔적들은 하나도 없어요.

그리고 저는 앞으로 일어날 일들의 상관관계를 파악하기 위해 그렇게 하고 싶습니다.

차량을 클릭하면 시내 트럭을 찾을 수 있습니다. 화면을 새로 고친 후 바로 클릭하면 차량이 따라옵니다.

그리고 빨간색 선이 어디에 있었는지 추적할 수 있습니다.

이제 Yeager로 전환하여 이전 검색을 반복하면 이제 3개의 결과가 반환됩니다. 3개의 결과가 반환된다는 사실에 놀라실 수 있습니다.

기본적으로 사용자 인터페이스를 한 번 클릭했을 때 발생하는 동작은 세 개의 개별 HTTP 요청을 시스템에서 실행하는 것으로 끝났습니다.

저는 왜 이 비디오가 끝날 무렵에 세 개가 있는지 설명하려고 노력할께요.

하지만 이 세 가지 추적 각각에 대한 매우 유용한 정보가 있습니다. 각각의 추적은 어떤 서비스를 통해 실행되는지 요약하고 있습니다. 언뜻 보기에, 이것은 별로 하는 것이 없습니다. 단지 웹 앱으로 가는 일종의 요청일 뿐입니다.

다른 두 개의 추적은 여러 개의 서비스를 방문했습니다.

여기 아래쪽에 있는 것은 API 게이트웨이를 통해 위치 추적기로 이동한 것으로 보입니다.

반면 다른 추적에서는 API 게이트웨이를 통과합니다.

하지만 이번에는 직원 서비스도 방문했습니다. 기억하실지 모르겠지만, 직원 서비스에 문제가 있다고 생각하시면 됩니다.

그래서 저는 다른 두 개의 흔적들로 돌아갈 것입니다.

하지만 우리가 관심을 갖고 있는 것은 여기 이 트레이스인 것 같습니다.

이 영역의 아무 곳이나 클릭하면 전체 세부 정보가 확장됩니다.

그런데, 여기 체크박스는 비슷한 트레이스가 여러 개 있는 경우, 선택해서 비교할 수 있는데, 이것은 때때로 유용합니다.

하지만 우리의 경우, 우리는 범위를 비교하는 것이 아니라 단지 세부사항을 원할 뿐입니다.

따라서 확인란을 클릭하지 말고 이 영역의 아무 곳이나 클릭하십시오.

그리고 이 그래프를 알아보실 수 있습니다.

자, 앞서 보여드린 영상으로 만든 그래프에서 보시죠.

여기 분명히 좀 더 자세한 내용이 있습니다.

하지만 그 원리는 정확히 똑같다.

제가 제일 먼저 말씀드리고 싶은 것은, 여전히 혼란스럽다는 것입니다. 여기서 서비스의 반복을 보게 될 거라는 겁니다. 제가 지난 비디오의 마지막에 언급했듯이, 그것은 바로 대리인의 존재 때문입니다.

자, 여러분이 이것보다 더 복잡한 시스템을 다룰 때, 저는 이 그래프가 처음에는 약간 압도적일 수 있다는 것을 알았습니다.

따라서 그래프를 오랫동안 연구해서 다른 각도에서 보고 정확히 무슨 일이 일어나고 있는지 알아내려고 해도 걱정하지 마세요.

제 말은, 이것은 매우 간단한 시스템입니다.

하지만 여기에서도 몇 가지 혼란스러운 부분이 있습니다.

여기 약간의 조언이 있습니다. 처음에는 이 도표를 접는 것이 유용하다고 생각합니다.

예를 들어, 제가 여기서 이 화살표를 꺾으면, 제 생각엔 꽤 유용한 관점을 보여주고 있는 것 같습니다.

이전 비디오의 캡션에서 했던 것과 비슷하죠. 이제 최상위 세부 사항을 보고 있습니다. 요청이 많은 마이크로 서비스를 거치더라도 전체 화면 길이에 걸쳐서 이 막대의 총합은 10.5밀리초밖에 되지 않습니다.이 경우에도 마찬가지지만 단일 요청이 시스템을 통과하는 전체 기간입니다.

그리고 두 번째 줄은 다음 단계의 세부사항을 제공합니다.

그 다음에 일어난 일은 웹 앱이 다른 마이크로 서비스, 즉 API 게이트웨이로 요청을 전달했다는 것입니다.

그리고 그것만의 색깔이 있다는 것을 알아라.

여기 그래프는 웹 앱이 무언가를 하는데 짧은 시간을 소비하고 API 게이트웨이를 이어받은 것을 보여줍니다.

이제 그 작은 무언가가 실제로 대리인이 일을 하고 있다는 것을 알려드릴 수 있습니다. 그래서 저는 이전입니다. 그것이 우리가 웹 앱에 대한 두 개의 항목이 있는 이유입니다.

요청이 발송될 때 프록시의 작업을 볼 수 있도록 하기 위한 것입니다.

또한 API 게이트웨이가 웹 앱으로 반환될 때 프록시에서 일부 작업이 수행됩니다.

자, 여러분은 보통 그 세세한 부분에는 관심이 없습니다.

그래서 저는 이 그래프에서 약간 혼란스럽다는 것을 인정해야 합니다.

다시 확장하면 3개의 스팬만 예상할 수 있습니다. 왜냐하면 여기 체인에 3개의 마이크로서비스가 있기 때문입니다.

하지만 제가 언급했듯이, 지난 번 것을 제외하고, 여러분은 이것이 두 배로 늘어나는 것을 볼 수 있을 것입니다.

하지만 사실, 이전 비디오의 캡션을 이해한 이상, 이것은 매우 간단할 것입니다.

만약 우리가 그 직원 서비스에 타이밍에 문제가 있다면, 이 바의 길이부터, 제가 생각하기에 이 애플리케이션의 성능이 좋은 버전으로 실행된다는 것은 명백할 것입니다.

그래서 우리는 여기서 아무것도 걱정하지 않습니다.

하지만 우리가 관심있는 것은 그 대사일 것이다.

여기서 유용한 사용자 인터페이스 세부 정보는 관심 영역인 경우 항상 여기 맨 위에 있는 시간 표시줄을 가리키면 됩니다.

시간 표시 막대의 특정 영역에 초점을 맞추려면 관심 영역을 가로질러 마우스를 움직이면 모든 항목이 해당 영역으로 확대됩니다.

여기 맨 위에 있는 이 계획은 여러분에게 모든 범위를 보여주고 있습니다. 하지만 이번에는 자세히 설명하지 않고 진행 상황에 대한 아주 좋은 수준의 계획을 세울 수 있습니다.

다시 마우스를 움직여 해당 시간 표시 막대의 영역을 선택할 수 있습니다.

마지막으로 리셋 선택이라는 버튼이 있습니다. 이 버튼은 요청의 전체 범위까지 타임라인을 확장합니다.

정말 유용한 정보들이 많이 있습니다.

하지만 마지막으로 언급하고 싶은 것은 내가 사용자 인터페이스를 한 번만 클릭했을 때 왜 우리는 세 개의 다른 흔적을 보았는가 하는 것이다. 구현 세부 사항입니다. 개발자에게 물어보고 싶은 사항입니다.

그리고 그들은 저에게 이런 차량들 중 하나를 클릭하면 이 사용자 인터페이스의 구현이 세 개의 HTTP 요청을 보낸다고 말할 것입니다.

그리고 다시, 당신은 왜 3개의 HTTP 요청이 있는지 우리에게 더 많은 정보를 줄 수 있습니다.

사실 그것들 중 하나는 별로 흥미롭지 않다.

여기 이 안에 한 칸만 있는 것이 있습니다.

만약 우리가 이걸 뚫어본다면, 네, 흥미로운 것은 아무것도 없습니다. 왜냐하면 우리는 단지 하나의 범위만 가지고도 요청이 있었다는 것을 알 수 있기 때문입니다.

약 0.5 밀리초 정도밖에 지속되지 않았습니다.

하지만 우리가 할 수 있는 또 다른 한가지는, 여기에서는 유용하지 않겠지만, 다른 두 개의 흔적에는 유용하게 쓰일 것입니다. 이 두 개의 흔적들 중 어떤 것을 클릭해도 됩니다.

HTTP 요청에 대한 전체 정보를 얻을 수 있습니다.

여기 있는 태그를 통해서요.

화살표를 클릭하면 멋진 테이블이 나타납니다.

그러면 HTTP 요청에 대한 모든 세부 정보가 표시됩니다.

이것이 HTTP GET 요청이었다는 것을 알 수 있습니다.

우연히 http 200을 반환하게 됩니다.

그리고 가장 유용한 것은 이것이 요청했던 URL이라는 것입니다.

여기 아래에 몇 개의 깃발이 더 있습니다. 하지만 저는 종종 유용한 정보를 제공하는 URL에 초점을 맞추겠습니다.

내가 이 앱을 만든 것은 오래 전 일이야.

저는 사실 왜 여기 URL에 요청을 보내는지 물음표로 끝나는지 기억나지 않습니다.

사실 제가 카메라 바로 앞에서 녹화를 할 줄 몰랐던 건데, 머리를 좀 긁적거렸어요.

그리고 그것은 확실히 추가적인 조사를 위한 무언가일 수 있습니다.

하지만 전 그게 별로 흥미롭지 않다고 생각해요

제가 이 사용자 인터페이스를 개발하기 위해 사용하는 프레임워크인 것 같습니다. Angular(각각)입니다. 링크를 클릭할 때 어떤 종류의 리소스를 요청하는 것 같습니다.

그게 뭐든 간에, 별로 흥미롭지 않아요.

그리고 나는 그것이 벌레라거나 기대된다고 생각하지 않는다.

그러나, 우리는 다른 두 추적에 대한 더 많은 정보를 찾기 위해 정확히 같은 기술을 사용할 수 있다. 이 두 추적은 분명히 흥미로운 일을 하고 있다.

만약에 우리가 작업하던 흔적을 찾아간다면, 직원 서비스에 들어가기 전에 말이죠.

이걸 클릭해서 다시 한번 말씀드리면, 저는 그것들을 클릭해서 표를 내려놓을 수 있습니다.

그리고 사용자 에이전트가 자바라는 것을 볼 수 있는 것과 같이 정말 유용한 정보를 얻을 수 있습니다.

그래서 저는 이제 이 서비스의 구현을 알고 있습니다. 하지만 또한 정말 유용하게, 저는 그것의 URL을 볼 수 있습니다. 그리고 URL은 슬래시 드라이버 포워드 슬래시 시티 트럭을 끝냅니다.

사용자 인터페이스를 통해 우리가 어떤 차량이라도 클릭할 때, 우리는 운전자에 대한 정보를 얻을 수 있고, 운전자의 이름도 얻을 수 있고, 운전자의 사진도 얻을 수 있다는 것을 알 수 있습니다.

따라서 이 요청이 생성된 이유는 드라이버의 세부 정보를 얻기 위해서였을 가능성이 매우 커 보입니다.

그런데 돌아가면 왜 또 다른 요청이 있었을까요? 자, 다시 말씀드리지만, 우리는 모든 타이밍 데이터를 볼 수 있습니다.

하지만 이번에는 이 중 하나를 클릭하면 요청되는 URL이 우리에게 좋은 단서가 될 것입니다.

여기 URL은 history라는 리소스에 대한 REST 요청으로 보입니다.

그리고 이 사건에서, 그것은 도시 트럭의 역사였습니다.

이 시스템을 잘 모르시더라도 저희가 이 차량을 선택할 때마다 그 트럭이 어디에 있었는지 알게 되실 겁니다.

Yeager를 사용하여 이 시스템의 코드 라인을 한 줄도 살펴보지 않았더라도, 우리는 단순히 타이밍 문제뿐만 아니라 시스템에 병목 현상이 발생할 수 있는 부분을 파악할 수 있었습니다.

하지만 사용자 인터페이스에서 클릭 한 번으로 세 가지 요청을 생성했는데, 그 중 하나는 그다지 유용해 보이지 않습니다.

그 중 하나는 역사 라인을 생성하는 것이었고, 그 중 하나는 여기 아래에 제시되어 있는 정보를 얻는 것이었습니다. 아마 여러분이 이 시스템의 구현에 별로 관심이 없으리라는 것을 압니다. 하지만 여러분 자신의 시스템에 관심이 있습니다.

조금만 연습하면, 그 흔적을 이해하는 것이 항상 쉽지는 않길 바랍니다. 때때로 앉아서 그것들을 자세히 연구해야 할 필요가 있습니다. 하지만 저는 여러분이 이것을 정말 유용한 도구로 발견하기를 바랍니다.

예거의 판매 촉진제입니다.

그리고 일반적으로 분산 추적은 자신을 위해 실험을 합니다.

하지만 불행히도, 추적에 한가지 큰 문제가 있습니다. 이 부분은 여러분이 그것을 실현시키지 않는다면 여러분에게 효과가 없을 것입니다.

다음 영상에서는 이 기능이 작동하려면 시스템을 통해 일부 헤더를 전파해야 한다는 사실에 대해 이야기하고자 합니다.

그것이 당신에게 아무런 의미가 없다면, 채널을 고정하세요.

다음 영상에서 자세히 살펴보겠습니다.

하지만 비디오의 이 부분에서 분산 추적이 여러분에게 매우 강력한 원격 측정 기능을 제공할 수 있는 방법에 대해 잘 느끼셨으면 합니다.