서비스 추적, OpenTracing 및 Jaeger

우리는 프로젝트에서 마이크로서비스 아키텍처를 사용합니다. 성능 병목 현상이 발생하면 로그를 모니터링하고 구문 분석하는 데 많은 시간이 소요됩니다. 개별 작업의 타이밍을 로그 파일에 기록할 때 일반적으로 이러한 작업이 호출된 원인을 이해하고 작업 순서를 추적하거나 다른 서비스에서 다른 작업에 대한 한 작업의 시간 이동을 추적하기가 어렵습니다.

수작업을 최소화하기 위해 추적 도구 중 하나를 사용하기로 결정했습니다. 추적을 사용할 수 있는 방법과 이유 및 추적 방법에 대해 이 문서에서 설명합니다.

추적으로 해결할 수 있는 문제

1. 단일 서비스 내에서 그리고 모든 참여 서비스 사이의 전체 실행 트리에서 성능 병목 현상을 찾으십시오. 예를 들어:
   • 예를 들어 지오코딩 또는 데이터베이스에 대한 서비스 간 짧은 연속 호출이 많습니다.
   • 네트워크 전송 또는 디스크 읽기와 같은 긴 I/O 대기.
   • 긴 데이터 구문 분석.
   • CPU가 필요한 긴 작업.
   • 최종 결과를 얻는 데 필요하지 않으며 제거하거나 지연할 수 있는 코드 섹션입니다.
2. 어떤 순서로 무엇이 호출되고 작업이 수행될 때 어떤 일이 발생하는지 명확하게 이해합니다.
   
   예를 들어 Request가 WS 서비스에 왔다 -> WS 서비스가 R 서비스를 통해 데이터를 추가했다 -> 그 후 V 서비스에 요청을 보냈다 -> V 서비스가 R 서비스에서 많은 데이터를 로드했다 -> P 서비스로 갔다 -> P 서비스가 다시 R 서비스로 갔다 -> V 서비스가 그 결과를 무시하고 J 서비스로 갔다 -> 그 다음에만 WS 서비스에 응답을 반환하면서 백그라운드에서 다른 것을 계속 계산하는 것을 볼 수 있다.
   전체 프로세스에 대한 이러한 추적이나 자세한 문서가 없으면 코드를 처음 볼 때 무슨 일이 일어나고 있는지 이해하기가 매우 어렵고 코드가 여러 서비스에 흩어져 있고 많은 빈과 인터페이스 뒤에 숨겨져 있습니다.
3. 후속 지연 분석을 위한 실행 트리에 대한 정보 수집. 실행의 각 단계에서 이 단계에서 사용할 수 있는 추적에 정보를 추가한 다음 유사한 시나리오로 이어진 입력 데이터를 파악할 수 있습니다. 예를 들어:
   • 사용자 아이디
   • 권리
   • 선택한 방법의 유형
   • 로그 또는 실행 오류
4. 추적을 지표의 하위 집합으로 전환하고 이미 지표 형태로 추가 분석합니다.

어떤 추적을 기록할 수 있습니다. 기간

추적에는 범위의 개념이 있으며 이는 콘솔에 대한 하나의 로그와 유사합니다. 스파에는 다음이 있습니다.

• 이름, 일반적으로 실행된 메서드의 이름
• 스팬이 생성된 서비스의 이름
• 자신의 고유 ID
• 로그인된 키/값 형식의 일종의 메타 정보입니다. 예를 들어 메서드 매개변수 또는 메서드가 오류로 종료되었는지 여부
• 이 기간의 시작 및 종료 시간
• 상위 스팬 ID

각 범위는 실행이 완료되는 즉시 나중에 검토할 수 있도록 범위 수집기로 전송되어 데이터베이스에 저장됩니다. 앞으로는 상위 ID로 연결하여 모든 스팬의 트리를 구축할 수 있습니다. 예를 들어, 분석할 때 일정 시간 이상 소요된 일부 서비스의 모든 범위를 찾을 수 있습니다. 또한 특정 범위로 이동하면 이 범위 위와 아래의 전체 트리를 볼 수 있습니다.

Opentrace, Jagger 및 이를 프로젝트에 구현한 방법

공통된 기준이 있습니다 오픈트레이스, 어떤 언어로든 특정 구현을 추적하지 않고 수집해야 하는 방법과 대상을 설명합니다. 예를 들어 Java에서 추적에 대한 모든 작업은 일반적인 Opentrace API를 통해 수행되며 예를 들어 Jaeger 또는 아무것도 수행하지 않는 빈 기본 구현을 숨길 수 있습니다.
우리는 사용하고 있습니다 사냥꾼 Opentrace의 구현으로. 여러 구성 요소로 구성됩니다.

• Jaeger-agent는 일반적으로 각 시스템에 설치되는 로컬 에이전트이며 서비스는 로컬 기본 포트에 로그인됩니다. 에이전트가 없으면 일반적으로 이 시스템의 모든 서비스 추적이 비활성화됩니다.
• Jaeger-collector - 모든 에이전트가 수집된 추적을 보내고 선택한 데이터베이스에 저장합니다.
• 데이터베이스는 그들이 선호하는 cassandra이지만 우리는 elasticsearch를 사용합니다. 몇 가지 다른 데이터베이스에 대한 구현과 디스크에 아무것도 저장하지 않는 메모리 내 구현이 있습니다.
• Jaeger-query는 데이터베이스로 이동하여 분석을 위해 이미 수집된 트레이스를 반환하는 서비스입니다.
• Jaeger-ui는 추적을 검색하고 보기 위한 웹 인터페이스이며 jaeger-query로 이동합니다.

별도의 구성 요소는 특정 언어에 대한 opentrace jaeger 구현이라고 할 수 있으며 이를 통해 스팬이 jaeger-agent로 전송됩니다.
Java에서 Jagger 연결 io.opentracing.Tracer 인터페이스 구현으로 귀결되며, 이후 이를 통한 모든 추적이 실제 에이전트로 이동합니다.

또한 스프링 구성 요소의 경우 연결할 수 있습니다. 오픈 트레이싱-스프링-클라우드-스타터 Jaeger의 구현 오픈 트레이싱-스프링-jaeger-클라우드-스타터 컨트롤러에 대한 http 요청, jdbc를 통한 데이터베이스에 대한 요청 등과 같이 이러한 구성 요소를 통과하는 모든 항목에 대한 추적을 자동으로 구성합니다.

Java에서 추적 로그인

최상위 레벨 어딘가에 첫 번째 Span이 생성되어야 합니다. 이것은 예를 들어 요청이 수신될 때 스프링 컨트롤러에 의해 자동으로 수행되거나 요청이 없는 경우 수동으로 수행될 수 있습니다. 이후 아래 Scope를 통해 전송됩니다. 아래 방법 중 하나가 Span을 추가하려는 경우 Scope에서 현재 activeSpan을 가져와서 새 Span을 생성하고 부모가 결과 activeSpan이라고 말하고 새 Span을 활성화합니다. 외부 서비스를 호출하면 현재 활성 스팬이 전달되고 해당 서비스는 이 스팬을 참조하여 새 스팬을 생성합니다.
모든 작업은 Tracer 인스턴스를 거치며 DI 메커니즘을 통해 가져오거나 DI 메커니즘이 작동하지 않는 경우 GlobalTracer.get()을 전역 변수로 가져올 수 있습니다. 기본적으로 트레이서가 초기화되지 않은 경우 NoopTracer는 아무 작업도 수행하지 않는 것을 반환합니다.
또한 ScopeManager를 통해 트레이서로부터 현재 스코프를 획득하고, 현재 스코프에서 새 스팬을 바인딩하여 새 스코프를 생성한 후 생성된 스코프를 닫고 생성된 스팬을 닫고 이전 스코프를 활성 상태로 되돌립니다. 스코프는 스레드에 묶여 있으므로 멀티 스레드 프로그래밍 시 활성 스팬을 다른 스레드로 전송하여 이 스팬을 참조하여 다른 스레드의 스코프를 추가로 활성화하는 것을 잊지 말아야 합니다.

io.opentracing.Tracer tracer = ...; // GlobalTracer.get()

void DoSmth () {
   try (Scope scope = tracer.buildSpan("DoSmth").startActive(true)) {
      ...
   }
}
void DoOther () {
    Span span = tracer.buildSpan("someWork").start();
    try (Scope scope = tracer.scopeManager().activate(span, false)) {
        // Do things.
    } catch(Exception ex) {
        Tags.ERROR.set(span, true);
        span.log(Map.of(Fields.EVENT, "error", Fields.ERROR_OBJECT, ex, Fields.MESSAGE, ex.getMessage()));
    } finally {
        span.finish();
    }
}

void DoAsync () {
    try (Scope scope = tracer.buildSpan("ServiceHandlerSpan").startActive(false)) {
        ...
        final Span span = scope.span();
        doAsyncWork(() -> {
            // STEP 2 ABOVE: reactivate the Span in the callback, passing true to
            // startActive() if/when the Span must be finished.
            try (Scope scope = tracer.scopeManager().activate(span, false)) {
                ...
            }
        });
    }
}

다중 스레드 프로그래밍의 경우 비동기 작업이 시작될 때 자동으로 현재 범위를 스레드로 전달하는 TracedExecutorService 및 유사한 래퍼도 있습니다.

private ExecutorService executor = new TracedExecutorService(
    Executors.newFixedThreadPool(10), GlobalTracer.get()
);

외부 http 요청의 경우 HttpClient 추적

HttpClient httpClient = new TracingHttpClientBuilder().build();

우리가 직면한 문제

• 서비스 또는 구성 요소에서 추적 프로그램을 사용하지 않으면 Bean 및 DI가 항상 작동하지 않는 경우 자동 유선 Tracer가 작동하지 않을 수 있으며 GlobalTracer.get()을 사용해야 합니다.
• 주석은 구성 요소 또는 서비스가 아니거나 동일한 클래스의 인접 메서드에서 메서드를 호출하는 경우 작동하지 않습니다. @Traced가 작동하지 않으면 무엇이 작동하는지 확인하고 수동 추적 생성을 사용해야 합니다. Java 주석을 위한 추가 컴파일러를 연결할 수도 있습니다. 그러면 모든 곳에서 작동합니다.
• 이전 스프링 및 스프링 부트에서 DI의 버그로 인해 opentraing 스프링 클라우드 자동 구성이 작동하지 않는 경우 스프링 구성 요소의 추적이 자동으로 작동하도록 하려면 다음과 같이 유추하여 수행할 수 있습니다. github.com/opentracing-contrib/java-spring-jaeger/blob/master/opentracing-spring-jaeger-starter/src/main/java/io/opentracing/contrib/java/spring/jaeger/starter/JaegerAutoConfiguration.java
• 자원 시도는 Groovy에서 작동하지 않으므로 try finally를 사용해야 합니다.
• 각 서비스에는 추적이 기록될 자체 spring.application.name이 있어야 합니다. 함께 방해하지 않도록 판매 및 테스트에 대한 별도의 이름은 무엇입니까?
• GlobalTracer와 tomcat을 사용하는 경우 이 tomcat에서 실행되는 모든 서비스에는 하나의 GlobalTracer가 있으므로 모두 동일한 서비스 이름을 갖게 됩니다.
• 메서드에 추적을 추가할 때 루프에서 여러 번 호출되지 않도록 해야 합니다. 총 작업 시간을 보장하는 모든 통화에 대해 하나의 공통 추적을 추가해야 합니다. 그렇지 않으면 초과 부하가 생성됩니다.
• 예거의 한 번은 너무 많은 추적을 너무 많이 요청했고 응답을 기다리지 않았기 때문에 다시 수행했습니다. 결과적으로 jaeger-query는 메모리를 많이 잡아먹고 탄성을 늦추기 시작했습니다. jaeger-query를 다시 시작하여 도움을 받음

트레이스 샘플링, 저장 및 보기

세 가지 유형이 있습니다 샘플링 트레이스:

1. 모든 추적을 보내고 저장하는 Const.
2. 주어진 확률로 트레이스를 필터링하는 확률적입니다.
3. 초당 추적 수를 제한하는 속도 제한. jaeger-agent 또는 수집기의 클라이언트에서 이러한 설정을 구성할 수 있습니다. 이제 요청이 많지 않기 때문에 평가자 스택에서 const 1을 사용하지만 시간이 오래 걸립니다. 앞으로 이것이 시스템에 과도한 부하를 줄 경우 이를 제한할 수 있습니다.

cassandra를 사용하는 경우 기본적으로 XNUMX일 동안만 추적을 저장합니다. 우리는 사용하고 있습니다 탄성 검색 추적은 항상 저장되며 삭제되지 않습니다. 매일 별도의 인덱스가 생성됩니다(예: jaeger-service-2019-03-04). 앞으로는 이전 추적의 자동 정리를 구성해야 합니다.

추적을 보려면 다음이 필요합니다.

• 추적을 필터링할 서비스를 선택합니다(예: tomcat에서 실행 중이고 자체 이름을 가질 수 없는 서비스의 경우 tomcat7-default).
• 그런 다음 긴 실행만 수행하려면 작업, 시간 간격 및 최소 작업 시간(예: 10초)을 선택합니다.
  
• 흔적 중 하나로 이동하여 속도가 느려지는 것을 확인하십시오.
  

또한 어떤 request id를 알고 있다면 이 id가 trace span에 기록되어 있다면 태그 검색을 통해 이 id로 trace를 찾을 수 있습니다.

Документация

• 오픈 트레이싱 문서 opentracing.io/docs/overview/what-is-tracing
• 예거 문서 www.jaegertracing.io/docs/1.10
• 예거 자바 연결 github.com/jaegertracing/jaeger-client-java
• 스프링 오픈 추적 연결
  github.com/jaegertracing/jaeger-client-java
  github.com/opentracing-contrib/java-spring-cloud

조항

• habr.com/ru/company/carprice/blog/340946 실제 PHP 및 Golang 프로젝트의 Jaeger Opentracing 및 마이크로서비스
• www.uber.com/distributed-tracing Uber Engineering의 진화하는 분산 추적
• opentracing.io/guides/java
• Medium.com/jaegertracing/running-jaeger-agent-on-bare-metal-d1fc47d31fab 베어 메탈에서 Jaeger Agent 실행

비디오

• www.youtube.com/watch?v=qg0ENOdP1Lo Jaeger와 Prometheus를 사용하여 번개처럼 빠른 사용자 쿼리를 제공하는 방법 — Bryan Boreham
• www.youtube.com/watch?v=WRntQsUajow 소개: Jaeger - Yuri Shkuro, Uber & Pavol Loffay, Red Hat
• www.youtube.com/watch?v=fsHb0qK37bc Serghei Iakovlev, "큰 승리의 작은 이야기: OpenTracing, AWS 및 Jaeger"

출처 : habr.com