CLS LogListener 파이프라인을 사용한 수집 시 복잡한 로그 구문 분석

복잡한 프로덕션 로그는 한 가지 깨끗한 형식으로 도착하는 경우가 드뭅니다. 단일 라인은 타임스탬프로 시작하여, 구분 기호로 분리된 필드를 이어가고, JSON 객체를 포함하며, 추가적인 래퍼 텍스트로 끝날 수 있습니다. 만약 컬렉터가 하나의 파서만 적용할 수 있다면, 다운스트림 로그 플랫폼은 손실된 구조를 받거나 운영자가 나중에 정리해야 하는 원시 문자열을 받게 됩니다.

원문 기사는 이러한 상황에 대한 해결책으로 Tencent Cloud CLS LogListener의 복합 구문 분석(composite parsing)을 컬렉터 측 파이프라인으로 제시합니다. LogListener는 하나 이상의 프로세서를 순차적으로 실행할 수 있으므로, 로그 라인을 분할하고, 디코딩하며, 필터링하고, 풍부하게 만들고(enriched), CLS에 업로드되기 전에 재조립할 수 있습니다.

복합 구문 분석이 유용한 경우

복합 구문 분석은 세 가지 소스 기반 시나리오를 위해 설계되었습니다:

시나리오	로그 라인에서 발생하는 일	파이프라인의 동작
여러 구문 분석 모드가 필요함	한 부분은 구분 기호로 분리되어 있고, 다른 부분은 JSON 또는 키-값 텍스트임	첫 번째 분할 후 서로 다른 필드에 대해 다양한 프로세서를 적용합니다
...

흐름은 간단합니다: 원본 로그를 세그먼트로 분할하고, 각 세그먼트에 적절한 프로세서를 적용하며, 구조화된 로그 콘텐츠가 되어야 할 필드만 출력합니다.

원문 기사의 프로세서 맵

원문 스크린샷에는 이 워크플로우에서 사용 가능한 프로세서들이 포함되어 있습니다:

기능	프로세서	소스 기반 용도
필드 추출	processor_log_string	다중 문자 라인 구문 분석, 일반적으로 고급 단일 라인 로그용
...

패턴 1: 업로드 전 필드 제거

패턴 1: 업로드 전 필드 제거

만약 원본 로그에 세 개의 키-값 쌍이 포함되어 있지만 key2만 유용하다면, 소스 기사는 processor_drop을 사용하여 key1과 key3를 제거합니다.

입력:

key1:value1
key2:value2
key3:value3

LogListener 설정:

{
  "processors": [
    {
...

출력:

key2:value2

이것은 가장 저렴한 종류의 로그 최적화입니다. 인덱싱하거나 분석할 필요가 없는 필드를 제거하여 페이로드 크기와 저장 비용을 줄일 수 있습니다.

패턴 2: 메타데이터에서 로그 풍부하게 만들기 (enrich logs from metadata)

기사에서는 또한 메타데이터를 이용한 로그 풍부화 사례를 보여줍니다. value1,value2와 같은 로그 본문이 파일 경로에서 수집되며, 컬렉터는 해당 경로에서 소유권 필드를 추출합니다. 소스에 따르면 meta_processor는 LogListener 2.7.4 이상을 요구합니다.

입력:

value1,value2

경로:

/usr/local/loglistener-2.7.4/testdir/test.log

설정 형태:

{
  "processors": [
    {
...

소스에서 보여주는 출력 필드:

msg1:value1
msg2:value2
__TAG__.app: loglistener
...

패턴 3: 자식 프로세서로 중첩된 필드 구문 분석 (parse nested fields with child processors)

사용자 정의 구문 분석 예제는 하나의 쉼표로 구분된 줄로 시작합니다:

1571394459,http://127.0.0.1/my/course/4|10.135.46.111|200,status:DEAD,

파이프라인은 먼저 이 줄을 time, msg1, msg2로 분할합니다. 자식 프로세서들은 이후 유닉스 타임스탬프를 변환하고, msg1을 |로 분할하며, msg2를 키-값 콘텐츠로 구문 분석합니다.

{
  "processors": [
    {
...

출력:

time: 1571394459
submsg1: http://127.0.0.1/my/course/4
submsg2: 10.135.46.111
...

패턴 4: JSON이 포함된 실제 접근 로그 언래핑 (unwrap a real access log with JSON inside)

마지막 소스 예제는 슬래시로 감싸진 로그 줄입니다:

마지막 소스 예제는 슬래시로 감싸진 로그 줄입니다:

2016-01-02 12:59:59/log_start/{"remote_ip":"10.135.46.111","body_sent":23,"responsetime":0.232,"upstreamtime":"0.232","upstreamhost":"unix:/tmp/php-cgi.sock","http_host":"127.0.0.1","method":"POST","url":"/event/dispatch","request":"POST /event/dispatch HTTP/1.1","xff":"-","referer":"http://127.0.0.1/my/course/4","agent":"Mozilla/5.0 (Windows NT 10.0; WOW64; rv:64.0) Gecko/20100101 Firefox/64.0","response_code":"200"}/log_end/

예상 동작:

1. 로그를 /로 분할하여 다섯 개의 세그먼트로 나눕니다.
2. 첫 번째 세그먼트를 time으로 유지합니다.
3. 래퍼 필드(wrapper fields)는 제거합니다.
4. JSON 세그먼트를 확장합니다.

{
  "processors": [
    {
...

최종 구조화된 필드는 time, agent, body_sent, http_host, method, referer, remote_ip, request, response_code, responsetime, upstreamhost, upstreamtime, url, 그리고 xff를 포함합니다.

실용적인 체크리스트

• 단일 파서(parser)가 소스 로그 형식을 표현할 수 없을 때는 복합 파싱(composite parsing)을 사용합니다.
• 첫 번째 분할은 간단하게 유지하고, 특정 필드에 대해 자식 프로세서(child processors)를 적용합니다.
• 검색이나 분석에 필요하지 않은 래퍼 또는 가치 낮은 필드는 업로드 전에 제거합니다.
• 이미지 전용 구성 예제는 선택 가능한 JSON으로 변환하여 향후 사용자가 복사하고 검토할 수 있도록 합니다.
• 파이프라인 순서를 명시적으로 유지합니다. LogListener는 프로세서 구성을 순차적으로 실행합니다.