DATADOG APM - LOG 트레이스 연결
DATADOG 메뉴얼도 그렇고 티켓 끊어서 물어 봐도 그렇고
하라는대로 다 했는데 APM 과 LOG 가 연동이 되지 않아서 나중에 손보자 하고 내버려둔지 꽤 오래 지나서 다시 연동을 위해 개발쪽을 확인해보니 트레이서 인젝션 설정이 애초에 안되있었고..
TraceId 와 SpanId 가 찍히고 있는데도 연동은 또 안되서 이번엔 또 무엇인가.. 분명 다 찎히는데 왜 !!!라고 하는중 파서에 문제가 있었다는걸 부사수가 발견 하여 수정한김에 올려보는 글
사실 DATADOG (이하 DD)의 가장 큰 불만중 하나는 매뉴얼이 불친절하다 인데 사실 또 다른데 매뉴얼이라고 그렇게 엄청나게 친절한건 아니라서 뭐,
(보안쪽 코드 시큐리티의 취약점 스캔 목록 제거좀 하게 해줘요 제발 ㅠㅠ)
일단 환경은 .NET Core 사용중이고 윈도우 EC2로 IIS 를 통해 서비스하고 있다.
당연하게도 DD 에이전트는 당연히 설치 되어 있어야 하고 .NET 트레이서 설치뢰 APM 이 동작하고 있어야 한다.
자동인젝션을 위해서 DD 에서 지원해주는 로그 모듈이 있는데
Serilog (v1.4+)
log4net
NLog
Microsoft.Extensions.Logging (added in v1.28.6)
이렇게 4가지를 지원하며 그외 로그 모듈의 경우는 수동으로 트레이스 ID 를 넣어 줄수 있다.
회사의 경우 Serilog 와 NLog 를 사용하고 있는데 Serilog 를 사용하는 프로덕트를 우선 작업 했다.(개발자 협조가 더 빨랐다)
로그에 트레이스ID 를 인젝션하기위해 DD_LOGS_INJECTION=true 환경변수가 설정되어있어야 한다.
처음 데이타독을 세팅하기 시작 했을때 변수로 설정되어 있어야 한다 라고만 설명이 되어있어서 도데체 어디의 어떤 변수에 넣으라는 말인가 너무 한참을 빙빙 돌았었는데 결국 스냥 시스템 환경 변수였다. (허무)
https://docs.datadoghq.com/ko/tracing/other_telemetry/connect_logs_and_traces/dotnet/?tab=serilog#getting-started
데이타독의 매뉴얼 문서이다.
dd_env , service, version, trace_id, span_id 가 핵심 변수고
using Datadog.Trace;
using Serilog.Context;
// there must be spans started and active before this block.
using (LogContext.PushProperty("dd_env", CorrelationIdentifier.Env))
using (LogContext.PushProperty("dd_service", CorrelationIdentifier.Service))
using (LogContext.PushProperty("dd_version", CorrelationIdentifier.Version))
using (LogContext.PushProperty("dd_trace_id", CorrelationIdentifier.TraceId.ToString()))
using (LogContext.PushProperty("dd_span_id", CorrelationIdentifier.SpanId.ToString()))
{
// Log something
}위와같이 로그찍기전 위 블럭이 들어가면 트레이서가 자동으로 트레이스ID 와 스팬ID 를 가져와서 로그에 주입하게 된다.
로그를 남기기 시작했다면 이제 로그 전송을 위해 c:\programData\Datadog\conf.d\csharp.d\config.yaml 을 수정(활성)해야 한다.
더 많은 옵션은 DD 문서를 참고 (또는 샘플 yaml 화일을 참고)하면 되고 이정도 설정이면 동작은 충분하다.
*.json 을 해두면 해당 폴더안의 모든 로그화일을 전송하게 되는데 중복은 알아서 정리되는건지 전송되지 않는것인지 까지는 모르겠지만 에이전트를 재시작해서 재전송이 되더라도 동일한 로그가 보이지는 않는다. 하지만 로그화일 갯수가 많아지면 전송오류도 있고 경고도 나오니 가급적 로테이션되는 현재 로그만 전송하는게 좋을 듯 하다.
설정완료후 에이전트를 재시작 하고 (윈도우의 경우 호스트 PC 에서 에이전트 실행하면 웹 인터페이스로 볼수 있다) 재시작된 뒤 status 를 보면 로그 에이전트가 활성화 되어있고 전송된 로그 목록을 볼수 있다.
Checks 부분에서 각 모듈(?)이 정상적으로 설정이 되었는지 확인 할 수 있다.
로그 -> 익스플로러 로 가보면 로그가 들어오고 있을것이다.
Trace 0 흠..
분명 로그엔 TraceID 도 있고. .SpanID 도 있고... 그렇게 환경변수 APM 설정 애플리케이션 소스에 에이전트 재설치도 해보고 트레이서 재설치도 해보고 결국 해결하지 못하고 있었고 티켓을 끊어서 지원을 받은것도 결국 설정부분만 계속 탐구 했었는데
원인은 전혀 예상 못했던 곳에 있었으니..
파이프라인이었다. 파서 생각을 못하고 있었는데 파서의 상위 모든 규칙에 맞지 않는 로그도 결국 일반 로그로써 전송되고 검색되니까 당연히 제대로 전송되고있다 라고만 인식해서 규칙을 볼 생각 자체를 못하고 있었던 것이었다.
그록 파서의 기본 규칙의 수정하기를 누르면 (마우스 오버시 오른쪽에 아이콘 나타남)
파싱 규칙과 규칙에 규칙에 맞는지 샘플을 넣어볼수 있는 창이 있다.
여기서 매치가 되어야 C# 로그로써 인식되는 부분이었으나
[INFO] 부분이 뒤에 있었고 dd.env dd.service dd.version dd.trace_id dd.span_id 의 형식이 잘못되어있었다. (env, service, version 은 없었고 traceId SpanID 로 지정되어있었던 부분.
appsetting 을 수정하여 형식을 맞춰주니
Log 에서 APM 트레이서와 연동 이제 RUM - APM - LOG 의 연동이 완료되어서 RUM 에서 APM 을통해 로그까지 한번에 탐색할수 있게 되었다.
알고보면 사소한 부분이지만 DD 의 기술 지원에서도 파서같은건 아예 기본중의 기본이라 생각해서 언급조차 안했는지 모르겠으나 뭐 원래 띄어쓰기 한칸 때문에 뭔가 안되는게 이동네니까... 라며..
댓글
댓글 쓰기