17. Telemetry - Why you need to "Propagate Headers"

At the beginning of this course, I set out that the design of the course is that you're working on a regular Kubernetes system with no special features added to it.

And I'm demonstrating that Istio can be used as a service mesh.

And we get lots of wonderful features such as telemetry in this section, traffic management coming next, and then policies and security.

And none of that needs you to alter your code, the Kubernetes pods that we're deploying remain on altered.

So Istio aims to be a non invasive service mesh, it doesn't affect your code.

But I did warn you, there is one exception.

And that is, if you want distributed tracing to work, then you do need to make alterations to your code.

And now I can finally confess that in the previous videos where I was demonstrating Jaeger, I had made changes to the running code inside my pods, so that everything worked.

So what have I done? And what do you need to do in your systems, if you want distributed tracing, like yay, go to work, the high level explanation really is that as we have a chain of requests running through your architecture, somehow the distributed tracing mechanism needs to work out that all of these requests are for a single trace.

In other words, it needs to correlate these requests.

The way it does, this is semi automatic, I've gone back to Jaeger here, and I've just picked a particular span from a trace.

And I showed you that you can drill down into these spans.

And you can look into the tags, for example, we can look at the URL and the method that's being called.

But one field that I didn't point out was in every one of these spans, there is a field called x request ID.

And it's good.

It's just a randomly generated, globally unique identifier.

And what you'll find is, if we just make a note of this request ID, it begins 954 and ns three to a, if I pick another one of the spans, such as this one here, which is quite far away from the original one, if I drill down into that one, can you see if you remember, I think this is right, that request ID 954, ending in three to eight is the same x request ID.

And you'll find that all of these spans in this trace have the same request ID.

And that's the mechanism that's going on under the hood here.

If requests have the same request ID, then they're all grouped together into a span.

But there's a big problem.

The problem is where do these request IDs come from, you might be thinking that you've got to go into your code and somehow put these request IDs into your requests actually don't.

These are automatically generated by Istio, you don't have to worry about them.

And then back to this scenario, if I wind everything back, what will happen is when a request comes in to your cluster, such as into the web app, and then the web app makes an outgoing request, in this case, it's making a request to the API gateway.

Well, you know, that those requests are going to be routed are routed through the envoy proxy.

One of the pieces of logic in this proxy is if the incoming request did not contain an X request ID, and it won't, because we've just made in a request from a browser.

Then, when the proxy is calling the target Potts proxy, it will automatically add in a header x request ID and it will automatically generate that gu ID.

I couldn't be bothered to put the gu IDs on here.

So I'm just using a random number.

But the principle still applies.

Here's the big catch.

What will happen next is the target proxy is going to invoke the local containers logic.

So this container will do whatever it needs to do.

Then this container decides it wants to call this staff service container.

So the process continues.

There's going to be an outgoing call, routed or routed through the proxy.

Now you might be expecting well that's great when the ex request ID came into here.

So perhaps automatic It can be sent outwards.

Well, unfortunately, not.

Don't take my word for it.

I'm here in the documentation for Istio under the distributed tracing questions.

And the second question here is what is required for distributed tracing with Istio.

If I follow that link, it says here in order for various trace spans to be stitched together for a complete view, in other words, for a complete trace applications, and that means your code must propagate.

Well, they call it here, the trace context, they really mean that x request ID header.

Now, it's a bit more than that.

It's the x request ID, and also a set of headers beginning x dash B three.

So that means when, for example, this container here made its outgoing request, remember, your containers code will have visibility of this incoming request ID.

But your container has to put that request ID into the outgoing request.

If you don't do that, then what will happen is, when this outgoing request is made, this original request ID is lost.

And that logic is going to kick in again, this proxy here is going to send the request of the target pod.

The logic in this proxy will be Oh, I didn't receive a request ID here, it's this line here that I'm pointing to with my mouse.

If that header isn't in this line, then the proxy here will not receive the header.

So we'll run that logic again, it will say, oh, okay, I don't have an x request, ID or better generate a new one.

And it will be a completely new gu ID that is generated.

So the end result of all of this, if you don't do that work yourself, you'll end up with several traces, each of which are just containing one or two spans.

So it will all be kind of split up, which is not what you want.

So to run through that, again, if you want distributed tracing to work properly, in other words, for the traces to contain all of the spans.

And this is what you're going to have to do.

So we have our initial request here, which goes to the first container.

This is this containers making the request, which is routed or routed through the proxy, the proxy logic is intelligent enough to know there's no request ID on here.

So I need to generate one that will be a big ugly gu ID.

And that big, ugly, gooey sense of the target proxy, a target proxy will invoke the logic in this container.

And I want to be clear here that this x request ID will have been sent into this container.

But then when you make an outgoing request from this container, this line here, you are highlighting this in red here, you have to send that value that you received, and you have to send it in your outgoing request.

So this time around, because the proxies received this x request ID, it will know this time, it doesn't need to generate a new one, it will send it onwards to the next proxy in the chain.

And the fact now that we've got identical request IDs will mean that these spans can be gathered together, I'm really sorry to have to tell you that because this is invasive, it means you have to make changes to your application code.

If you don't do this, then you know the world isn't going to end.

But it will mean that your traces are not going to stitch together.

And the really disappointing news is, of course, really, you have to do this in every single container that you're going to be deploying into your architecture, again, the world world.

And if you forget to do this in one container, it's just that any traffic flowing through there is going to cause breaks in the traces and don't take my word for it.

I'm here on the frequently asked questions for Istio.

And one of the frequently asked questions on the distributed tracing is certainly a big frequently asked question for me.

And that is, why can't istio do this for me? Why can't it propagate the headers instead of the application? Now they don't really go into any detail in the answer other than saying that the Istio sidecar.

In other words, the envoy proxy has no implicit way of correlating the outbound requests to the inbound requests that cause them.

So if you think about it probably makes sense this request coming in here with id 47.

If then this container does some processing and sends an outgoing request, in the absence of that x request ID field, this proxy here has no way of knowing that this request was caused by this incoming request.

And I have to admit that Yeah, although I'm disappointed, that does appear that this isn't really possible.

Now, I wouldn't be surprised if in a future version of Istio, somebody comes up with a way of solving this problem.

And if you have a solution for this problem, then contact the Istio developers because I'm sure they'd love to hear from you.

I think this is definitely the weakest area of Istio.

But it does look like a bit of an unsolvable problem, given the architecture of these proxies.

So for whatever reason, it's certainly the case at the time of recording in 2019, that you do have to manually inside the container logic here.

When you receive a request, you've got to somehow store this value in some variable somewhere or a database.

And then be sure that when you make an outgoing request, you add this header to the new request that you're sending out, got to do it manually.

And we'll keep an eye on this.

And if anytime in the future in a future version of Istio, this no longer becomes a requirement, I will notify everybody and rerecord this video.

But for now, it's necessary.

There are a million different languages out there.

And I don't know what programming languages you're using.

But clearly, every single language will have a different way of enabling you to forward these headers.

I'm hearing the reference manual of Istio.

And if I look under the tasks link, and then follow the link to telemetry and distributed tracing, I think we'll look in the overview.

Yeah.

And in the overview, the first thing they talk about is the trace context propagation.

That's exactly what we're talking about here.

istio needs hints to tie together the entire trace, our applications need to propagate the HTTP headers, they give you a list there of the headers that we need to propagate.

And they're showing here, a code section from their sample application, which happens to be written in Python.

I don't know if you're familiar with Python, I don't use Python very often.

But they've given a block of code here where they're extracting these headers.

Going a little further down, there is a part of their sample application that uses Java.

They're using some technique here, to Yeah, emanate, this is really ugly, because basically, you've got to do this in every single one of your methods inside methods or operations or functions inside your applications.

So what they're doing here is presumably, this is a method that is implementing a REST endpoint.

So this will receive GET requests.

And on receipt of a get request, Java calls this an annotation and the annotation is saying, I want the web framework, the rest framework that we're using here to automatically grab this line here is the important one, grab whatever is contained in the header, x request ID, and store it in a local variable called x rec, then they've gone on to do the other tracing fields.

And then I don't know what they're doing here.

Exactly.

But presumably, this is calling an upstream service.

And they're being careful to send as a parameter, all of those headers, if absolutely horrible, so it isn't pleasant.

And I can't give specific advice for your programming languages.

But if you're using spring boots, and I'm only saying this because the Fleetman application is implemented in spring boots, now I'm here in the GitHub repository for for this course, you'll find this@github.com forward slash dick chest the word forward slash istio dash Fleetman.

So I've got the source code for the Fleetman in here.

Now, if you go to the releases link here, I'm generating a series of Docker images, one for each section of the course.

And the Docker images you've been working with in the previous videos were tagged colon six, and if you look down the releases list, you should find a release, called telemetry.

Now for that release, I've created a GitHub tag.

And I just make the GitHub tags be the same as the Docker image tags.

If you follow this link here to tag sex, I'm doing that just so you get specifically, the source code.

This isn't the master, this isn't the head of the repository.

This is the source code that was used for the system that you've just been monitoring in the previous videos.

And I just want to show you that what I've done to achieve this propagation is a Spring Boot trick.

Now when I came to implement this, I was very lucky in that in all of these microservices, I'm using a library called Fein.

I don't know if you're familiar with fame.

But if you are, it's a library that just enables you to do rest calls.

Without having to make a network request yourself.

It gives you a very high level way of calling URLs, basically.

And I was really lucky that in using Fein, and I didn't use fame for this reason, I just like fame.

But one of the features of Fein is it can do automatic header propagation.

And it means that if I take any one of my microservices, so looking here, the Istio Fleetman API gateway, if I drill down into the source folder, and then the main folder, and then into Java comm, virtual pair programmers, and then into API, we love our folder structures in Java, I'm just looking for anywhere, we're really where I'm making an outgoing request.

So think here in services, I have position tracking external service dot java.

And let's go for, for example, line 27.

Here, this is where I'm calling get history for a vehicle.

And that is going to be an external service.

You'll notice noticed in the previous demos that you saw this call where we get that history track.

And the way that works in fame is we create a file here I've called it remotes position micro service calls dot java.

And it's really nice, we can just write this as if it were in regular Java function, a regular Java method, get history far, this all looks very Java ish.

And just by this annotation on here, Fane will automatically convert that into a network request.

It's very neat.

It's very nice.

But what I'm trying to show you here is, I don't if you noticed, there was no header stuff there at all.

I never mentioned that x request ID.

And the reason for that is and I don't have to, I've just gone up a few levels to find this config folder.

And inside there, there is one Java class called propagate headers, interceptor dot java.

I've put a great big comments on this class, because I know many of you might want to use this in your own projects.

But if I can just run through my comment here, this is what's called an interceptor in fain, this is going to run automatically, I don't have to just have to drop this into the project, and it will automatically fire up whenever there's an incoming REST request.

If there's an incoming request rest requests, we will take all the headers beginning x, and then we'll store them away.

And we'll ask fain to add them to the corresponding outgoing rest requests, provided we do this in every single micro service, then that's going to have the end result of propagating the custom headers that we need for distributed tracing.

The class isn't particularly pleasant, but the great thing is, this is all that's needed.

I don't have to call this class, it will be automatically called by the framework, which is superb.

So what I would do in real life is I would put this class in some kind of library, and then use that library across all of my micro services.

For this system, I've just kept things simple, and I've just made sure that every single one of them has this file in it somewhere.

I've just copied and pasted To be honest, but it works for this demo.

So if I switch across, for example, to the staff service, and going to source main Java There's a config folder again.

And again we have the propagate headers interceptor dot java exactly the same class.

It's never called, but the framework uses it to propagate the headers.

I realised for many of you, that won't make sense if you don't work in Spring Boot, and if you're not working with fain, that's as far as I can go in just saying, whatever programming language you're in, try to have a look around and see if there's a library that will do this for you.

이 강좌의 시작부분에서 저는 이 강좌의 디자인이 특별한 기능이 추가되지 않은 일반적인 쿠버네티스 시스템을 연구하고 있다는 것을 알게 되었습니다.

그리고 저는 Istio가 서비스 메쉬로 사용될 수 있다는 것을 보여주고 있습니다.

이 섹션에는 원격 측정, 다음에 나올 교통 관리, 정책 및 보안과 같은 많은 멋진 기능들이 있습니다.

코드를 변경할 필요가 없는 쿠버네티스 포드는 변경된 상태로 남아 있습니다.

Istio는 비침습적 서비스 메쉬가 되는 것을 목표로 합니다. 여러분의 코드에 영향을 미치지 않습니다.

하지만 경고하는데 한 가지 예외가 있습니다.

즉, 분산 추적이 작동하려면 코드를 변경해야 합니다.

그리고 이제 마침내 제가 Jaeger를 시연했던 이전 비디오에서, 저는 제 포드 안에서 실행 중인 코드를 변경해서 모든 것이 작동되도록 했다는 것을 고백할 수 있습니다.

그래서 내가 뭘 한 거지? 시스템에서 해야 할 일은, 분산 추적을 원하신다면, 예를 들어, 일하러 가십시오, 높은 수준의 설명은 우리가 당신의 아키텍처를 통해 일련의 요청을 실행하고 있기 때문에, 분산 추적 메커니즘은 이 모든 요청이 단일 추적을 위한 것임을 밝혀내야 한다는 것입니다.

즉, 이러한 요청의 상관 관계가 필요합니다.

이렇게 하면, 이것은 반자동입니다. 저는 여기 Jaeger로 돌아왔습니다. 그리고 저는 단지 추적에서 특정한 길이를 선택했을 뿐입니다.

그리고 저는 이 부분들을 드릴다운할 수 있다는 것을 보여드렸습니다.

예를 들어, URL과 호출되는 메소드를 살펴볼 수 있습니다.

하지만 제가 지적하지 않은 한 분야는 이 모든 범위에 x request ID라는 필드가 있습니다.

그리고 그것은 좋다.

이것은 단지 무작위로 생성된, 세계적으로 고유한 식별자일 뿐입니다.

그리고 이 요청 ID를 메모만 하면 954가 시작되고 3에서 3까지가 됩니다. 여기 있는 것과 같은 스팬을 하나 더 선택하면 됩니다. 원래 스팬에서 꽤 멀리 떨어져 있습니다. 제가 드릴다운을 해보면 아시겠지만 954가 3에서 8로 끝나는 요청입니다. 신분증을 요구하다

이 추적의 모든 범위에 동일한 요청 ID가 있습니다.

이게 바로 여기 후드 아래에서 일어나고 있는 메커니즘입니다.

요청에 동일한 요청 ID가 있는 경우 모두 범위로 그룹화됩니다.

하지만 큰 문제가 있어요.

문제는 이러한 요청 ID의 출처가 어디인지입니다. 코드를 입력해서 요청 ID를 입력하지 않아도 된다고 생각할 수 있습니다.

이것들은 Istio에서 자동으로 생성되므로 걱정할 필요가 없습니다.

다시 이 시나리오로 돌아가서 모든 것을 되돌리면 웹 앱과 같은 요청이 클러스터에 들어오면 웹 앱이 발신 요청을 하게 됩니다. 이 경우에는 API 게이트웨이에 요청을 하는 것입니다.

글쎄요, 그런 요청들은 특사 대리인을 통해 전달될 겁니다.

이 프록시의 논리 중 하나는 수신 요청에 X 요청 ID가 포함되어 있지 않은 경우이며, 브라우저의 요청을 방금 작성했기 때문에 그렇지 않은 경우입니다.

그런 다음 프록시가 대상 Potts 프록시를 호출할 때 헤더 x 요청 ID를 자동으로 추가하고 해당 gu ID를 자동으로 생성합니다.

나는 여기에 그 신분증을 붙이는 것을 꺼릴 수 없었다.

그래서 저는 그냥 임의의 숫자를 사용하고 있습니다.

그러나 그 원칙은 여전히 적용된다.

여기 큰 수확이 있습니다.

그 다음에는 대상 프록시가 로컬 컨테이너 로직을 호출할 것입니다.

그래서 이 컨테이너는 필요한 모든 것을 할 수 있습니다.

그런 다음 이 컨테이너는 이 직원 서비스 컨테이너를 호출하기로 결정합니다.

그래서 그 과정은 계속됩니다.

프록시를 통해 라우팅되거나 라우트된 발신 통화가 있을 것입니다.

이제 당신은 엑시퀘스트 ID가 여기 들어왔을 때 아주 좋은 것을 기대하고 있을 거예요.

그래서 아마 자동으로 밖으로 보낼 수 있을 것이다.

음, 불행하게도, 그렇지 않아요.

내 약속을 꼭 믿지는 마세요.

분산 추적 질문으로 Istio 서류에 나와 있습니다.

여기서 두 번째 질문은 Istio를 이용한 분산 추적에 필요한 것입니다.

이 링크를 따라가면 다양한 추적 범위가 함께 연결되어 전체 보기, 즉 전체 추적 응용 프로그램이 적용되고 코드가 전파됩니다.

음, 그들은 이것을 추적 컨텍스트라고 부릅니다. 그들은 정말로 x request ID 헤더를 의미합니다.

자, 그 이상입니다.

x 요청 ID이고 x 대시 B 3을 시작하는 헤더 집합이기도 합니다.

즉, 예를 들어, 이 컨테이너가 송신 요청을 했을 때 컨테이너 코드는 이 수신 요청 ID의 가시성을 가집니다.

그러나 컨테이너는 해당 요청 ID를 발신 요청에 넣어야 합니다.

이렇게 하지 않을 경우 이 발송 요청이 있을 때 원래 요청 ID가 손실됩니다.

그리고 그 논리는 다시 시작될 것이고, 여기 이 대리인은 타겟 포드의 요청을 보낼 것입니다.

이 프록시의 논리는 아, 여기 요청 ID를 받지 못했습니다. 마우스로 가리키고 있는 이 줄입니다.

헤더가 이 줄에 없는 경우 여기서 프록시는 헤더를 수신하지 않습니다.

그래서 그 논리를 다시 한 번 살펴보죠. 오, 좋아요, 저는 x 요청이 없습니다. ID를 찾거나, 아니면 새로 생성하는 것이 더 낫습니다.

그리고 완전히 새로운 가이드 아이디가 생성될 것입니다.

그래서 이 모든 것의 최종 결과는, 만약 여러분이 직접 그 일을 하지 않는다면, 여러분은 몇 개의 흔적들을 갖게 될 것입니다. 각각의 흔적들은 단지 한 두 개의 범위를 포함하고 있습니다.

그래서 이 모든 것이 분열될 것입니다. 여러분이 원하는 것이 아닙니다.

다시 말해, 분산 추적이 제대로 작동하려면 추적에 모든 범위가 포함되도록 해야 합니다.

그리고 이것이 여러분이 해야 할 일입니다.

그래서 우리는 첫 번째 컨테이너에 대한 우리의 초기 요청을 받았습니다.

이 컨테이너는 프록시를 통해 라우트되거나 라우트되는 요청입니다. 프록시 로직은 여기에 요청 ID가 없다는 것을 알 수 있을 만큼 충분히 지능적입니다.

그래서 저는 크고 못생긴 아이디가 될만한 아이디를 만들어야 합니다.

대상 프록시에 대한 크고 추악한 감각의 대상 프록시가 이 컨테이너에 있는 논리를 호출합니다.

그리고 나는 이 x request ID가 이 컨테이너로 보내질 것이라는 것을 확실히 하고 싶다.

그러나 이 컨테이너에서 발신 요청을 할 때, 여기 이 줄은 빨간색으로 강조 표시됩니다. 수신한 값을 전송해야 하며 발신 요청으로 보내야 합니다.

그래서 이번에는 프록시가 x 요청 ID를 받았기 때문에, 이번에는 새 ID를 생성할 필요가 없다는 것을 알게 될 것이고, 체인의 다음 프록시로 이 ID를 보낼 것입니다.

그리고 동일한 요청 ID를 가지고 있다는 것은 이 범위를 함께 모을 수 있다는 것을 의미할 것입니다. 죄송합니다. 이것은 침습적이기 때문에 응용 프로그램 코드를 변경해야 한다는 뜻입니다.

이렇게 하지 않으면 세상이 끝나지 않을 거라는 걸 알 수 있을 거예요.

하지만 그것은 당신의 흔적이 서로 엉켜지지 않을 것이라는 것을 의미할 것이다.

그리고 정말 실망스러운 소식은, 물론, 여러분이 건축에 배치할 모든 컨테이너에서, 다시 한번, 세계에 이 일을 해야 한다는 것입니다.

그리고 만약 여러분이 한 컨테이너에서 이것을 하는 것을 잊는다면, 그것은 단지 그곳을 통과하는 어떤 교통체증도 흔적들을 깨트릴 것이고, 제 말을 믿지 않을 것입니다.

Istio에게 자주 묻는 질문 때문에 왔습니다.

분산 추적에 대해 자주 묻는 질문 중 하나는 분명 제게 자주 묻는 질문입니다.

즉, 왜 티오가 저를 위해 이것을 할 수 없을까요? 응용프로그램 대신 헤더를 전파할 수 없는 이유는 무엇입니까? 이제 그들은 아이스티오 사이드카라고 말하는 것 말고는 더 자세히 대답하지 않습니다.

즉, 권한 위임 프록시는 아웃바운드 요청을 발생시키는 인바운드 요청과 연관시킬 수 있는 암시적 방법이 없습니다.

그러니 생각해보면, 이 요청은 ID 47로 여기에 들어오는 것이 타당할 것입니다.

그런 다음 이 컨테이너가 일부 처리를 수행하고 해당 x 요청 ID 필드가 없는 경우 이 프록시는 이 요청이 수신 요청에 의해 발생했음을 알 수 있는 방법이 없습니다.

그리고 저는 인정해야 합니다. 네, 비록 실망스럽지만, 그것은 실제로 불가능해 보입니다.

자, 만약 아이스티오의 미래 버전에서 누군가가 이 문제를 해결할 방법을 생각해 낸다면 저는 놀라지 않을 것입니다.

그리고 만약 이 문제에 대한 해결책이 있다면, Istio 개발자들에게 연락하세요. 왜냐하면 그들이 당신으로부터 듣고 싶어할 테니까요.

나는 이곳이 확실히 이시오의 가장 약한 지역이라고 생각한다.

하지만 이러한 프록시 구조를 고려할 때, 이것은 해결할 수 없는 문제처럼 보입니다.

어떤 이유로든, 2019년에 녹화할 때는 반드시 컨테이너 논리 안에 수동으로 넣어야 합니다.

요청을 받으면 이 값을 일부 변수 또는 데이터베이스에 저장해야 합니다.

그런 다음 발신 요청을 할 때 보내는 새 요청에 이 헤더를 추가하여 수동으로 요청해야 합니다.

그리고 우리는 이것을 주시할 것입니다.

그리고 만약 미래에 Istio의 미래 버전에서 이것이 더 이상 요구 사항이 되지 않는다면, 저는 모두에게 알리고 이 비디오를 다시 녹음할 것입니다.

하지만 지금으로서는 그럴 필요가 있다.

세상에는 수백만 개의 다른 언어들이 있습니다.

어떤 프로그래밍 언어를 사용하고 계신지 모르겠습니다.

그러나 각 언어마다 이러한 헤더를 전달할 수 있는 다른 방법이 있습니다.

Istio의 참조 설명서를 듣고 있습니다.

작업 링크 아래를 보고 원격 측정 및 분산 추적 링크를 클릭하면 개요가 표시됩니다.

네, 그렇습니다.

개요에서, 그들이 가장 먼저 말하는 것은 미량 컨텍스트 전파입니다.

그게 바로 우리가 여기서 이야기하고 있는 것입니다.

istio는 전체 추적을 묶기 위한 힌트가 필요합니다. 응용 프로그램은 HTTP 헤더를 전파해야 합니다. 이 헤더를 통해 전달해야 하는 헤더의 목록을 제공합니다.

여기 보시는 것은, 샘플 어플리케이션의 코드 섹션입니다. 이것은 Python으로 작성되었습니다.

여러분이 파이썬을 잘 아는지 모르겠지만, 저는 파이썬을 자주 사용하지 않아요.

하지만 여기에서는 이 헤더를 추출하는 코드 블록을 제공했습니다.

좀 더 아래로 내려가 보면, Java를 사용하는 샘플 애플리케이션의 일부가 있습니다.

그들은 여기 몇가지 기술을 사용하고 있습니다. 예, 이건 정말 보기 흉합니다. 왜냐하면 기본적으로, 여러분은 모든 방법을 응용 프로그램 내부의 방법, 운영 또는 기능에서 해야 하기 때문입니다.

여기서 그들이 하고 있는 것은 아마도 이것이 REST endpoint를 구현하는 방법입니다.

GET 요청을 수신합니다.

요청을 받으면 Java는 이를 주석이라고 합니다. 여기서 웹 프레임워크를 원합니다. 여기서 이 줄을 자동으로 잡고 머리글에 포함된 모든 x request ID를 가져와 xrec라는 로컬 변수에 저장한 다음 작업을 계속합니다.기타 추적 필드

그리고 나는 그들이 여기서 무엇을 하고 있는지 모른다.

바로 그거야.

하지만 아마도, 이것은 업스트림 서비스라고 불리는 것 같다.

그리고 그들은 모든 헤더를 매개 변수로 보내는 것을 조심하고 있습니다. 정말 끔찍할지라도 말이죠. 그래서 즐겁지 않습니다.

그리고 나는 당신의 프로그래밍 언어에 대한 구체적인 조언을 줄 수 없다.

하지만 스프링 부츠를 사용한다면, 플리트먼 어플리케이션이 스프링 부츠로 구현되어 있기 때문에 이런 말씀을 드리자면, 저는 이 강좌를 위해 GitHub 저장소에 있습니다. this@github.com forward slash dickbox forward slashistio Fletman이라는 단어를 보실 수 있습니다.

여기 플리트맨의 소스 코드를 가지고 있습니다.

자, 여기 릴리즈 링크를 보시면, 일련의 도커 이미지를 만들고 있습니다. 각 코스의 각 섹션마다 하나씩 말이죠.

이전 동영상에서 작업한 도커 이미지에는 6번 콜론이라는 태그가 붙었습니다. 릴리즈 목록을 보시면 원격측정이라는 릴리즈가 있습니다.

이제 이 릴리즈를 위해 GitHub 태그를 만들었습니다.

GitHub 태그를 도커 이미지 태그와 동일하게 만듭니다.

여기 링크에 따라 섹스에 태그를 붙이시면, 소스 코드를 정확하게 알 수 있도록 제가 하는 겁니다.

이건 마스터도 아니고, 리포지토리의 책임자도 아닙니다.

이것은 이전 비디오에서 방금 모니터링한 시스템에 사용된 소스 코드입니다.

제가 이 전파를 이루기 위해 한 일은 스프링 부츠 속임수라는 것을 보여드리고자 합니다.

제가 이것을 실행하게 되었을 때, 저는 운이 좋게도 이 모든 마이크로서비스에서 Fein이라는 라이브러리를 사용하고 있습니다.

당신이 명성에 익숙한지 모르겠어요.

하지만 만약 그렇다면, 이 도서관은 당신이 휴게소 호출을 할 수 있게 해주는 도서관입니다.

직접 네트워크 요청을 하지 않아도 됩니다.

기본적으로 매우 높은 수준의 URL 호출 방법을 제공합니다.

그리고 저는 정말 운이 좋게도 Fein을 사용했고, 이러한 이유로 명성을 사용하지 않았습니다. 저는 단지 명성을 좋아합니다.

그러나 Fein의 특징 중 하나는 자동 헤더 전파를 할 수 있다는 것이다.

즉, 제 마이크로 서비스 중 하나를 가져간다면, 여기를 보면, Istio Fleetman API 게이트웨이를 볼 수 있고, 소스 폴더와 메인 폴더를 드릴다운하고, Java Comm, 가상 페어 프로그래머, API로 들어가면, 우리는 Java의 폴더 구조를 매우 좋아하게 됩니다. 저는 단지 어디에서든지 찾고 있습니다.청혼

여기 서비스에 대해 생각해 보세요. 위치추적 외부 서비스 도트 자바가 있습니다.

예를 들어, 27호선을 봅시다.

여기, 제가 전화를 걸고 있는 곳은 차량 기록을 알아보는 곳입니다.

그리고 그것은 외부 서비스가 될 것입니다.

이전 데모에서는 이 통화 내역을 확인할 수 있습니다.

그리고 유명한 방법은 원격 위치 마이크로 서비스(micro service call) 도트 자바(dot java)라고 불리는 파일을 만드는 것입니다.

그리고 정말 좋습니다. 우리는 이것을 일반적인 자바 함수에 있는 것처럼 쓸 수 있습니다. 정규적인 자바 방식, 역사를 얻는 방법, 이것은 모두 자바어처럼 보입니다.

그리고 여기 있는 이 주석만으로도 Fane은 자동으로 그것을 네트워크 요청으로 변환시킬 것입니다.

아주 깔끔해요.

아주 좋아요.

하지만 여기서 보여드리려고 하는 것은, 여러분이 눈치채셨는지 모르겠지만, 거기에는 전혀 아무것도 없었습니다.

나는 그 x request 아이디를 말한 적이 없다.

그 이유는 제가 이 구성 폴더를 찾기 위해 몇 단계 올라갔기 때문입니다.

그리고 그 안에는 전파 헤더, 인터셉터 도트 자바라고 불리는 자바 클래스가 있습니다.

여러분 중 많은 분들이 자신의 프로젝트에 이것을 사용하고 싶어할 수도 있다는 것을 알고 있기 때문에, 저는 이 수업에 대해 큰 코멘트를 달았습니다.

하지만 여기서 제 코멘트를 훑어볼 수 있다면, 이것이 바로 인터셉터 인페어라고 불리는 것입니다. 이것은 자동으로 실행될 것입니다. 저는 이것을 프로젝트에 그냥 떨어뜨릴 필요가 없습니다. 그리고 들어오는 REST 요청이 있을 때마다 자동으로 불이 붙습니다.

수신 요청 휴지 요청이 있는 경우 x부터 시작하는 모든 헤더를 제거한 다음 해당 헤더를 저장합니다.

또한 모든 마이크로 서비스에서 이러한 작업을 수행하면 해당 요청을 해당 나가는 휴지 요청에 추가할 수 없습니다. 그러면 분산 추적에 필요한 사용자 지정 헤더를 전파할 수 있는 최종 결과를 얻을 수 있습니다.

수업이 특별히 즐거운 것은 아니지만, 좋은 점은 이것만 있으면 된다는 것입니다.

저는 이 수업을 부를 필요가 없습니다, 프레임워크에 의해 자동으로 호출될 것입니다, 아주 훌륭합니다.

그래서 제가 실제로 할 일은 이 수업을 어떤 종류의 도서관에 넣고, 그 도서관을 제 모든 마이크로 서비스에 걸쳐서 사용하는 것입니다.

이 시스템을 위해, 저는 간단한 작업만 수행했습니다. 그리고 모든 시스템에 이 파일이 있는지 확인하였습니다.

솔직히 말해서 복사해서 붙였는데 이 데모에 효과가 있어요.

예를 들어, 직원 서비스로 전환하고 기본 Java를 소스화하면 구성 폴더가 다시 나타납니다.

전파 헤더 인터셉터 도트 자바가 정확히 같은 클래스입니다.

호출된 적은 없지만 프레임워크는 헤더를 전파하는 데 사용합니다.

스프링 부츠에서 일하지 않으면 말이 안 된다는 것을 깨달았습니다. 그리고 만약 여러분이 고통스럽게 일하지 않는다면, 제가 말할 수 있는 한, 여러분이 어떤 프로그래밍 언어로 되어 있든, 여러분을 위해 이 일을 할 도서관이 있는지 둘러보도록 하세요.