안녕하세요.

1. 로키 스트림의 생성에 사용되는 과정:
   • 로그 데이터는 라벨로 분류됩니다. 라벨은 로그 데이터를 구분하고 쿼리하기 위한 메타데이터로, 키/값의 쌍으로 이루어져 있습니다. 예를 들어, {component="printer", location="f2c16", level="error"}와 같은 라벨 세트가 로그 메시지에 할당됩니다.
   • 라벨 세트는 해시되어 고유한 '스트림 ID'를 생성합니다. 이 ID는 특정 로그 스트림을 식별하는 데 사용됩니다. 이미지에는 해시된 결과의 예로 3b2cea09797978fc가 있습니다.
2. 청크의 생성과 저장:
   • 동일한 라벨 세트를 가진 추가적인 로그 메시지들은 같은 '청크'에 추가됩니다. 예를 들어, "Printing is not supported by this printer", "Out of paper", "Too much paper"와 같은 다양한 로그 메시지가 모두 같은 라벨을 공유하므로 같은 청크에 저장됩니다.
   • 이러한 청크는 채워진 후에 압축되고 저장됩니다.
3. 청크 조회를 위한 인덱스:
   • 청크를 빠르게 찾기 위해, 별도의 작고 분리된 인덱스가 유지됩니다. 이 인덱스를 통해 청크를 빠르게 조회할 수 있습니다.
4. 라벨 값의 변화와 새로운 청크 생성:
   • 만약 라벨의 키 또는 값이 달라지면, 다른 해시 값을 가지는 새로운 스트림과 새로운 청크가 생성됩니다. 예를 들어, {component="printer", location="f2c16", level="info"} 라벨 세트는 "Consider the environment before printing this log message"라는 로그 메시지와 함께 새로운 청크를 형성합니다.

자 그러면 로키의 Chunk 데이터 형식을 더 알아보자.

이 형식은 로키가 로그 데이터를 저장할 때 사용하는 내부 구조를 나타냅니다.

프롬쿼리를 공부중인데

카운터, 게이지, 히스토그램등 메트릭타입은 이해를 했다. 쿼리를 레이블로 필터링하거나 혹은 정규표현식으로 필터링하는것까지도 이해를했다.

다만 

instant vector 

range vector

rate함수

서브쿼리가 잘 이해가지 않아, 이해하기 위해 끄적인다.

사용 메트릭

promhttp_metric_handler_requests_total{code="200"}

메트릭 설명 : 

프로메테우스 메트릭 수집관련 http 응답코드중 200(정상)반환한 요청의 수

쿼리1. instant Vector

promhttp_metric_handler_requests_total{code="200"}

결과값

결과값 설명 :promhttp_metric_handler_requests_total 결과값

그래프 결과 :

쿼리2. Range Vector

promhttp_metric_handler_requests_total{code="200"}[5m]

결과값: 

결과값 설명:  지난 5분간의 반환값. 갯수는 총 20개다. 현재 프로메테우스에서 메트릭 수집하는게 15초간격으로 하니까 5분이면 20개가 맞다.

그래프결과: 결과값 자체가 타임스탬프별 결과값을 테이블 형식으로 가지고 있기 때문에 그래프 출력 못함. 

쿼리3. rate(promhttp_metric_handler_requests_total{code="200"}[5m])

결과값:

결과값 설명: rate함수(초당 평균 증가율을 계산하는 함수)를 사용하여 5분(300초)동안 초당 평균 요청 증가율을 출력한것.

앞서 5m일때의 값이 약 20개이다. 즉 rate함수가 초당 평균증가율을 계산하는거니까 300초([5m])동안 약 20개 가량이 증가했으니까  20 / 300 하면 대략 0.066666667이 나온다. 

그래프결과: 

06시 9분에 처음 메트릭 수집이 시작됐고 5분뒤인 14분에 약 20개 가량의 결과값이 쌓였다.

그래서 위와같이 약 14분가량에 밸류값이 0.06666667에 가까운것을 알수있다.

레인지 백터로 5m을 줬을 때 최근 5분동안의 결과값을 타임스탬프 형식으로 가져오는것은 맞다. 여기서 오해하면 안되는게 rate 함수를 사용했을 때 최근 5분동안의 증가율만 결과값으로 반환하지만 이를 그래프로 표현했을때는 수집 시점부터의 수집값을 가지고 그래프를 그린다는것

쿼리4-1.

rate(promhttp_metric_handler_requests_total{code="200"}[5m])[10m:1m]

결과값:

쿼리4-2.

rate(promhttp_metric_handler_requests_total{code="200"}[5m])[20m:1m]

결과값:

쿼리4-3.

rate(promhttp_metric_handler_requests_total{code="200"}[5m])[20m:10m]

결과값:

쿼리4-4.

rate(promhttp_metric_handler_requests_total{code="200"}[5m])[180m:10m]

결과값:

마지막으로 서브 쿼리에 대한 설명이다. [180m:10m]180분동안 10분간격으로 데이터를 가져온다는 뜻이다. 

설치

brew install go-task

아주 간단한 사용법

 cat taskfile.yaml
version: '3'

tasks:
  hello:
    cmds:
      - echo 'Hello World from Task!'
    silent: true
 task hello
Hello World from Task!

말그대로 task들을 코드로 관리하는 도구

• 챗지피티 설명Taskfile의 주요 장점은 다음과 같습니다:
  1. 간단하고 명확한 문법: Taskfile은 가독성이 높고 쓰기 쉬운 문법을 제공합니다. 이는 개발자가 작업을 빠르게 정의하고 이해할 수 있게 해줍니다.
  2. 로컬 및 원격 실행 지원: Taskfile은 로컬 개발 환경과 원격 CI/CD 파이프라인에서 동일한 작업을 실행할 수 있게 해줍니다. 이는 개발 및 배포 과정의 일관성을 보장합니다.
  3. 작업 의존성 관리: Taskfile을 사용하면 작업 간의 의존성을 쉽게 정의하고 관리할 수 있습니다. 이는 작업 실행 순서를 자동화하고 복잡한 작업 흐름을 구성하는 데 도움이 됩니다.
  4. 재사용성 및 모듈화: Taskfile을 통해 정의된 작업은 재사용 가능하고 모듈화되어 있어, 다른 프로젝트나 파이프라인에서 쉽게 재사용할 수 있습니다.
  5. 확장성: Taskfile은 단순한 작업 실행부터 복잡한 파이프라인 구성까지 다양한 요구 사항을 수용할 수 있도록 설계되었습니다. 개발자는 필요에 따라 작업을 확장하고 사용자 정의할 수 있습니다.
  6. 통합 용이성: Taskfile은 GitHub Actions, Jenkins, GitLab CI 등 다양한 CI/CD 도구와 쉽게 통합될 수 있습니다. 이를 통해 개발 팀은 파이프라인을 효율적으로 관리하고 자동화할 수 있습니다.
  Taskfile은 Makefile과 비교할 때 더 현대적이고 사용자 친화적인 대안으로, 개발자들이 작업을 더 효율적으로 관리하고 실행할 수 있게 해줍니다. 추가적인 질문이 있거나 더 자세한 정보가 필요하시면 언제든지 문의해 주세요.
• Taskfile은 개발 과정에서 다양한 작업을 관리하기 위한 도구입니다. 이 도구를 사용하면 테스트 실행, 빌딩, 패키징, 배포 등의 작업을 선언적 방식으로 정의하고 자동화할 수 있습니다. Taskfile의 주요 목적은 작업 실행을 단순화하고, 개발자가 로컬 및 CI/CD 파이프라인 환경에서 동일한 작업을 쉽게 실행할 수 있도록 하는 것입니다.

msbuild라던가 gradle의 여러 버전별로 사용해야 할 때 파이프라인에서 각 gradle의 환경변수를 직접 잡아줄 필요 없이 task를 사용하면 손쉽게 버전별 도구를 사용할수있지 않을가 싶다.

version: '3'

tasks:
  gradle6.1:
    cmds:
      - gradle6.1 wrapper --gradle-version=6.1
      - ./gradlew build
    desc: "Build the project with Gradle 6.1"

  gradle7.2:
    cmds:
      - gradle7.2 wrapper --gradle-version=7.2
      - ./gradlew build
    desc: "Build the project with Gradle 7.2"

이외에도 docker compose up , down 조차도 어려워하는 고객들에게 task를 사용하여 명령어를 만들어주고 사용하라고 해도 좋을듯.

가장 베스트는 개발자들이 직접 이 taskfile이라는 도구를 사용하면서 개발(로컬피씨)환경과 빌드서버환경을 통일하면 가장 좋을듯하다.

사용법 : https://www.youtube.com/watch?v=_-bpnCY3-FE