JJON's StorY

1. 프로메테우스 실행

> setproxy wget https://github.com/prometheus/prometheus/releases/download/v2.2.1/prometheus-2.2.1.linux-amd64.tar.gz

> tar -xzf prometheus-2.2.1.linux-amd64.tar.gz

> cd prometheus-2.2.1.linux-amd64/

> vi prometheus.yml

prometheus.yml 파일에 scrape_configs 항목 추가

global:
scrape_interval: 10s
scrape_configs:
- job_name: 'prometheus'
static_configs:
- targets: ['localhost:9090']

> ./ prometheus

웹 브라우저에서 http://prometheus-main.ay1.krane.9rum.cc:9090 로 접속하면 다음과 같은 화면을 볼 수 있다.

2. 노드 익스포터 실행

> setproxy wget https://github.com/prometheus/node_exporter/releases/download/v1.0.1/node_exporter-1.0.1.linux-amd64.tar.gz

> tar -xzf node_exporter-1.0.1.linux-amd64.tar.gz

> cd node_exporter-1.0.1.linux-amd64/

> ./node_exporter

웹 브라우저에서 http://prometheus-main.ay1.krane.9rum.cc:9100 로 접속하면 다음과 같은 화면을 볼 수 있다.

프로메테우스가 노드 익스포터를 모니터링 하려면 prometheus.yml 파일에 scrape_configs 항목을 추가 해야 한다.

> cd prometheus-2.2.1.linux-amd64/

> vi prometheus.yml

- job_name: 'node'
static_configs:
- targets: ['localhost:9100']

 프로메테우스를 재시작 하고 target 페이지를 보면 다음과 같이 up 상태인 대상 2개를 확인 할 수 있다.

MySQL 8.0 지원 스토리지 엔진

• InnoDB: MySQL 8.0의 기본 스토리지 엔진입니다. InnoDB사용자 데이터를 보호하기위한 커밋, 롤백 및 크래시 복구 기능이있는 MySQL 용 트랜잭션 안전 (ACID 호환) 스토리지 엔진입니다. InnoDB행 수준 잠금 및 Oracle 스타일의 일관된 비 잠금 읽기는 다중 사용자 동시성과 성능을 향상시킵니다. InnoDB사용자 데이터를 클러스터형 인덱스에 저장하여 기본 키를 기반으로하는 일반적인 쿼리에 대한 I / O를 줄입니다. 데이터 무결성을 유지하기 위해 FOREIGN KEY 참조 무결성 제약 조건도 지원합니다.
• MyISAM:이 테이블은 설치 공간이 작습니다. 테이블 수준 잠금 은 읽기 / 쓰기 워크로드의 성능을 제한하므로 웹 및 데이터웨어 하우징 구성의 읽기 전용 또는 대부분의 읽기 워크로드에서 자주 사용됩니다.
• Memory: 중요하지 않은 데이터의 빠른 조회가 필요한 환경에서 빠른 액세스를 위해 모든 데이터를 RAM에 저장합니다. 이 엔진은 HEAP 엔진으로 알려졌습니다. InnoDB버퍼 풀 메모리 영역은 대부분 또는 모든 데이터를 메모리에 보관하는 범용적인 방법을 제공하고  NDBCLUSTER는 방대한 분산 데이터 세트에 대한 빠른 키-값 조회를 제공합니다.
• CSV: 테이블은 실제로 쉼표로 구분 된 값이있는 텍스트 파일입니다. CSV 테이블을 사용하면 CSV 형식으로 데이터를 가져 오거나 덤프하여 동일한 형식을 읽고 쓰는 스크립트 및 응용 프로그램과 데이터를 교환 할 수 있습니다. CSV 테이블은 index가 생성되지 않기 때문에 일반적으로 InnoDB정상 작업 중에 데이터를 테이블에 보관 하고 가져 오기 또는 내보내기 단계 중에 만 CSV 테이블을 사용합니다.
• Archive: 인덱스 화되지 않은 압축 테이블은 참조되지 않는 많은 양의 기록을 보관 또는 보안 감사 정보를 저장하고 검색하기위한 것입니다.
• Blackhole: Blackhole 스토리지 엔진은 Unix /dev/null장치 와 마찬가지로 데이터를 허용하지만 저장하지 않습니다 . 쿼리는 항상 빈 집합을 반환합니다. 이러한 테이블은 DML 문이 복제본 서버로 전송되지만 원본 서버가 자체 데이터 복사본을 유지하지 않는 복제 구성에서 사용할 수 있습니다.
• NDB(NDBCLUSTER) :이 클러스터 된 데이터베이스 엔진은 가능한 최고 수준의 가용성이 필요한 애플리케이션에 특히 적합합니다.
• Merge: MySQL DBA 또는 개발자가 일련의 동일한 MyISAM테이블 을 논리적으로 그룹화하고 하나의 개체로 참조 할 수 있습니다. 데이터웨어 하우징과 같은 VLDB 환경에 적합합니다.
• Federated: 별도의 MySQL 서버를 연결하여 여러 물리적 서버에서 하나의 논리적 데이터베이스를 생성하는 기능을 제공합니다. 분산 또는 데이터 마트 환경에 매우 적합합니다.
• Example:이 엔진은 새 스토리지 엔진 작성을 시작하는 방법을 보여주는 MySQL 소스 코드의 예입니다. 스토리지 엔진은 아무 작업도 수행하지 않는 " stub" 입니다. 이 엔진으로 테이블을 생성 할 수 있지만 테이블에 데이터를 저장하거나 검색 할 수 없습니다.

전체 서버 또는 스키마에 대해 동일한 스토리지 엔진을 사용하도록 제한되지 않습니다. 모든 테이블에 대해 스토리지 엔진을 지정할 수 있습니다. 예를 들어, 애플리케이션은 데이터를 스프레드 시트로 내보내기위한 InnoDB하나의 CSV테이블과 MEMORY임시 작업 공간을위한 몇 개의 테이블이 있는 대부분의 테이블을 사용할 수 있습니다 .

스토리지 엔진 선택

MySQL과 함께 제공되는 다양한 스토리지 엔진은 다양한 사용 사례를 염두에두고 설계되었습니다. 다음 표는 MySQL과 함께 제공되는 일부 스토리지 엔진에 대한 개요를 제공하며 표 다음에 나오는 설명을 명확히합니다.

참고:
1. 스토리지 엔진이 아닌 서버에서 구현됩니다.
2. 압축 된 MyISAM 테이블은 압축 된 행 형식을 사용할 때만 지원됩니다. MyISAM에서 압축 된 행 형식을 사용하는 테이블은 읽기 전용입니다.
3. 암호화 기능을 통해 서버에서 구현됩니다.
4. 암호화 기능을 통해 서버에서 구현됩니다. MySQL 5.7 이상에서는 미사용 데이터 테이블 스페이스 암호화가 지원됩니다.
5. 외래 키에 대한 지원은 MySQL Cluster NDB 7.3 이상에서 사용할 수 있습니다.
6. FULLTEXT 인덱스에 대한 InnoDB 지원은 MySQL 5.6 이상에서 사용할 수 있습니다.
7. 지리 공간 인덱싱에 대한 InnoDB 지원은 MySQL 5.7 이상에서 사용할 수 있습니다.
8. InnoDB는 Adaptive Hash Index 기능을 위해 내부적으로 해시 인덱스를 사용합니다.

용어사전 :

chunk : 데이터가 저장되는 단위

tombstone : chunk 파일에서 데이터를 즉시 삭제하는 대신 삭제를 기록

WAL : 서버 재 시작이나 crash로 부터 보호를 위한 log

symbol : 시리즈의 레이블 쌍에서 발생한 중복 제거 된 문자열

1. Index Disk Format

다음 각 블록 디렉토리에 있는 index 파일의 형식을 설명합니다

인덱스가 작성 될 때, 위의 줄이 그어진 메인 섹션 사이에 임의의 수의 패딩 바이트가 추가 될 수 있습니다. 파일을 순차적으로 스캔 할 때 섹션의 지정된 길이 뒤에 오는 0 바이트는 건너 뛰어야합니다.

아래에 설명 된 대부분의 섹션은 len필드로 시작 합니다. 항상 후행 CRC32 체크섬 바로 앞의 바이트 수를 지정합니다. 체크섬은 항상 해당 len바이트에 대해 계산 됩니다.

1.1. Symbol Table

Symbol 테이블은 저장된 시리즈의 레이블 쌍에서 발생한 중복 제거 된 문자열의 정렬 된 목록을 보유합니다. 후속 섹션에서 참조 할 수 있으며 총 인덱스 크기를 크게 줄일 수 있습니다.

이 섹션에는 문자열 항목의 시퀀스가 포함되며 각 항목에는 원시 바이트의 문자열 길이가 접두사로 붙습니다. 모든 문자열은 utf-8로 인코딩됩니다. 문자열은 순차 인덱싱으로 참조됩니다. 문자열은 사전 순으로 오름차순으로 정렬됩니다.

1.2. Series

이 섹션에는 시리즈의 레이블 세트와 블록 내의 청크가 포함 된 시리즈의 시퀀스가 포함됩니다. 시리즈는 레이블 세트를 기준으로 사전 순으로 정렬됩니다.
각 시리즈 섹션은 16 바이트로 정렬됩니다. 시리즈의 ID는 offset/16 정의됩니다. 시리즈의 ID는 다른 곳에 참조되어 사용됩니다. 따라서 정렬 된 시리즈 ID 목록은 사전 순으로 정렬 된 시리즈 레이블 세트 목록을 의미합니다.

모든 시리즈 항목은 먼저 레이블 수를 보유하고 레이블 이름과 값을 포함하는 기호 테이블 참조의 튜플이 뒤 따릅니다. 레이블 쌍은 사전 순으로 정렬됩니다.
레이블 뒤에는 인덱싱 된 청크 수가 인코딩되고 그 뒤에 청크 최소 ( mint) 및 최대 ( maxt) 타임 스탬프와 chunk 파일에서의 해당 위치에 대한 참조가 포함 된 메타 데이터 항목 시퀀스가 이어집니다. mint는 첫 번째 샘플의 시간과 maxt는 chunk의 마지막 샘플의 시간입니다. 인덱스에 시간 범위 데이터를 보유하면 쿼리 된 시간 범위와 관련이 없는 chunk를 직접 액세스하지 않고도 삭제할 수 있습니다.

첫 chunk의 mint 저장되고, 델타로 maxt 저장되고, 후속 chunk 대해 이전 시간에 대한 델타로 mint와 maxt는 인코딩된다. 유사하게, 첫 번째 청크의 참조가 저장되고 다음 참조는 이전 참조에 대한 델타로 저장됩니다.

1.3. Label Index

레이블 인덱스 섹션은 하나 이상의 레이블 이름에 대한 기존 (결합 된) 값을 인덱싱합니다. #names 필드는 색인화 된 라벨 이름의 수를 결정하고,그 뒤에 #entries 필드의 총 항목 수가 표시됩니다. 본문은 기호 테이블 참조의 #entries / #names 튜플을 보유하며, 각 튜플은 #names 길이입니다. value 튜플은 사전 순으로 오름차순으로 정렬됩니다. 이는 더 이상 사용되지 않습니다.

예를 들어, 4 개의 다른 값을 가진 단일 라벨 이름은 다음과 같이 인코딩됩니다.

레이블 인덱스 섹션의 순서는 주어진 레이블 이름에 대한 각 레이블 인덱스 섹션의 시작을 가리키는 레이블 오프셋 항목을 포함 하는 레이블 오프셋 테이블에 의해 마무리됩니다 .

1.4. Postings

게시 섹션은 목록과 연관된 지정된 레이블 쌍을 포함하는 시리즈 참조의 단조 증가 목록을 저장합니다.

게시 섹션의 순서 는 지정된 레이블 쌍에 대한 각 게시 섹션의 시작을 가리키는 게시 오프셋 항목을 포함 하는 게시 오프셋 테이블에 의해 마무리됩니다 .

1.5. Label Offset Table

레이블 오프셋 테이블은 일련의 레이블 오프셋 항목을 저장합니다. 모든 레이블 오프셋 항목에는 레이블 색인 섹션의 값에 대한 레이블 이름과 오프셋이 있습니다. 레이블 인덱스 섹션을 추적하는 데 사용됩니다. 이것은 더 이상 사용되지 않습니다.

1.6. Postings Offset Table

posting 오프셋 테이블은 라벨 이름과 값별로 정렬 된 일련의 posting 오프셋 항목을 저장합니다. 모든 posting 오프셋 항목에는 레이블 이름 / 값 쌍과 posting 섹션의 시리즈 목록에 대한 오프셋이 있습니다. posting 섹션을 추적하는 데 사용됩니다. 인덱스 파일이 로드 될 때 부분적으로 메모리로 읽혀집니다.

1.7. TOC

전체 색인에 대한 진입 점 역할을하며 파일의 다양한 섹션을 가리 킵니다. 참조가 0이면 해당 섹션이 존재하지 않으며 조회시 빈 결과가 반환되어야 함을 나타냅니다.

2. Chunks Disk Format

chunks/ 디렉토리에 생성되는 chunk 파일의 형식을 설명합니다. 세그먼트 파일 당 최대 크기는 512MiB입니다.

파일의 chunk는 in-file offset(lower 4 bytes) 및 세그먼트 시퀀스 번호 (upper 4 bytes)로 구성된 uint64에 의해 인덱스에서 참조됩니다.

Chunk

3. Head Chunks on Disk Format

chunks_head/ 데이터 디렉터리 내의 디렉터리에 생성되는 chunk 파일의 형식을 설명합니다 .

파일의 chunk는 in-file offset(lower 4 bytes) 및 세그먼트 시퀀스 번호 (upper 4 bytes)로 구성된 uint64에 의해 인덱스에서 참조됩니다.

Chunk

온 디스크 블록의 chunk와 달리 여기에 chunk가 속한 시리즈 참조와 chunk의 최소/최대 값을 추가로 저장합니다. 이는 chunk와 관련된 인덱스가 없기 때문에 chunk를 재생하는 동안 이러한 메타 정보가 사용됩니다.

4. Tombstones Disk Format

다음은 블록의 최상위 디렉토리에있는 tombstones 파일의 형식을 설명합니다.

마지막 8 바이트는 Stones 섹션의 시작 오프셋을 지정합니다. 스톤 섹션은 빠른 스캔을 위해 4의 배수로 0을 붙입게 됩니다.

Tombstone

5. WAL Disk Format

미리 쓰기 로그는 번호가 매겨지고 순차적 인 세그먼트에서 작동합니다. 예를 들면 000000, 000001, 000002등, 그리고 기본적으로 128MB 제한된다. 세그먼트는 32KB 페이지에 기록됩니다. 가장 최근 세그먼트의 마지막 페이지만 부분적 일 수 있습니다. WAL 레코드는 현재 페이지의 나머지 공간을 초과 할 경우 하위 레코드로 분할되는 불투명 한 바이트 조각입니다. 레코드는 세그먼트 경계로 분할되지 않습니다. 단일 레코드가 기본 세그먼트 크기를 초과하면 더 큰 크기의 세그먼트가 생성됩니다. 페이지 인코딩은 LevelDB's/RocksDB's write ahead log에서 차용됩니다 .

레코드 조각이 다음과 같이 인코딩됩니다.

플래그의 상태는 다음과 같습니다.

0: 페이지는 비어 있습니다.
1: 단일 조각으로 인코딩 된 전체 레코드
2: 레코드의 첫 번째 조각
3: 레코드의 중간 부분
4: 레코드의 마지막 조각

5.1. Series records

시리즈 레코드는 시리즈와 고유 ID를 식별하는 레이블을 인코딩합니다.

5.2. Sample records

샘플 레코드는 샘플을 트리플 목록으로 인코딩합니다 (series_id, timestamp, value). 시리즈 참조 및 타임 스탬프는 첫 번째 샘플의 델타로 인코딩됩니다. 첫 번째 행에는 시작 ID와 시작 타임 스탬프가 저장됩니다. 첫 번째 샘플 레코드는 두 번째 행에서 시작됩니다.

5.3. Tombstone records

tombstone 레코드는 삭제 표시를 트리플 목록으로 인코딩 (series_id, min_time, max_time) 하고 시리즈 샘플이 삭제되는 간격을 지정합니다.

고급 사용자를 위해 데이터베이스 관리 기능을 하는 API입니다.
이 API는이 --web.enable-admin-api 설정되어 있지 않으면 사용할 수 없습니다.

1. snapshot

snapshot은 현재 모든 데이터의 snapshot을 TSDB의 데이터 디렉터리 아래 snapshots/<datetime>-<rand> 에 만들고 응답으로 디렉터리를 반환합니다.
헤드 블록에만 있고 아직 디스크에 압축되지 않은 스냅 샷 데이터를 선택적으로 건너 뜁니다.

URL 쿼리 매개 변수 :

skip_head=<bool> : 헤드 블록에 있는 데이터를 건너 뜁니다. (옵션)

$ curl -XPOST http://localhost:9090/api/v1/admin/tsdb/snapshot
{
  "status": "success",
  "data": {
    "name": "20201014T211224Z-2be650b6d019eb54"
  }
}

이제 스냅 샷이 <data-dir>/snapshots/20201014T211224Z-2be650b6d019eb54 생성 되었습니다.

2. series 삭제

delete_series는 시간 범위에서 선택한 series에 대한 데이터를 삭제합니다.
실제 데이터는 여전히 디스크에 존재하며 향후 압축시 정리되거나 tombstones endpoint를 명시적으로 정리할 수 있습니다.

성공하면 204가 반환된다.

URL 쿼리 매개 변수 :
match[]=<series_selector> : 삭제할 series를 선택하는 반복 라벨 매치 인수다. 하나 이상의 match[] 인수를 제공해야 합니다.
start=<rfc3339 | unix_timestamp> : 시작 타임 스탬프를. 선택 사항이며 가능한 최소 시간이 기본값 입니다.
end=<rfc3339 | unix_timestamp> : 종료 타임 스탬프. 선택 사항이며 기본값은 가능한 최대 시간 입니다.
시작 및 종료 시간을 모두 언급하지 않으면 데이터베이스에서 일치하는 시리즈의 모든 데이터가 지워 집니다.

$ curl -X POST -g 'http://localhost:9090/api/v1/admin/tsdb/delete_series?match[]=up&match[]=process_start_time_seconds{job="prometheus"}'


$ curl -X POST -g 'http://localhost:9090/api/v1/admin/tsdb/delete_series?match[]={__name__="up"}&start="2020-10-14T11:00:00Z"&end="2020-10-14T11:02:00Z"'

3. clean tombstones

clean_tombstones는 디스크에서 삭제 된 데이터를 제거하고 기존 삭제 표시를 정리합니다.
시리즈를 삭제 한 후 공간을 확보하기 위해 사용할 수 있습니다.

성공하면 204가 반환 됩니다.

매개 변수 나 본문이 필요하지 않습니다.

$ curl -XPOST http://localhost:9090/api/v1/admin/tsdb/clean_tombstones

4. TSDB 통계

Prometheus TSDB에 대한 다양한 카디널리티 통계를 반환 합니다.

 - headStats : TSDB의 헤드 블록에 대한 데이터.
 - numSeries : 시리즈 수.
 - chunkCount : 청크 수.
 - minTime : 현재 최소 타임 스탬프 (밀리 초).
 - maxTime : 현재 최대 타임 스탬프 (밀리 초).
 - seriesCountByMetricName : 메트릭 이름 및 시리즈 수 목록.
 - labelValueCountByLabelName : 레이블 이름 및 값 개수 목록.
 - memoryInBytesByLabelName : 레이블 이름과 사용 된 메모리의 목록 (바이트 단위). 메모리 사용량은 지정된 레이블 이름에 대한 모든 값의 길이를 더하여 계산 됩니다.
 - seriesCountByLabelValuePair : 레이블 값 쌍 목록과 해당 시리즈 수를 제공.

$ curl http://localhost:9090/api/v1/status/tsdb
{
  "status": "success",
  "data": {
    "headStats": {
      "numSeries": 508,
      "chunkCount": 937,
      "minTime": 1591516800000,
      "maxTime": 1598896800143,
    },
    "seriesCountByMetricName": [
      {
        "name": "net_conntrack_dialer_conn_failed_total",
        "value": 20
      },
      {
        "name": "prometheus_http_request_duration_seconds_bucket",
        "value": 20
      }
    ],
    "labelValueCountByLabelName": [
      {
        "name": "__name__",
        "value": 211
      },
      {
        "name": "event",
        "value": 3
      }
    ],
    "memoryInBytesByLabelName": [
      {
        "name": "__name__",
        "value": 8266
      },
      {
        "name": "instance",
        "value": 28
      }
    ],
    "seriesCountByLabelValuePair": [
      {
        "name": "job=prometheus",
        "value": 425
      },
      {
        "name": "instance=localhost:9090",
        "value": 425
      }
    ]
  }
}