10장. 로그 스토리지
10.1. 로그 스토리지 정보
로그를 저장하기 위해 클러스터에서 내부 Loki 또는 Elasticsearch 로그 저장소를 사용하거나 ClusterLogForwarder 사용자 정의 리소스(CR) 를 사용하여 로그를 외부 저장소로 전달할 수 있습니다.
10.1.1. 로그 스토리지 유형
Loki는 수평으로 확장 가능한 고가용성 다중 테넌트 로그 집계 시스템으로, 로깅을 위한 로그 저장소로 Elasticsearch의 대안으로 제공됩니다.
Elasticsearch는 들어오는 로그 레코드를 수집 중에 완전히 인덱싱합니다. Loki는 수집 중에 몇 가지 고정된 레이블만 인덱싱하고 로그를 저장한 후 더 복잡한 구문 분석을 수행합니다. 즉 Loki는 로그를 더 빠르게 수집할 수 있습니다.
10.1.1.1. Elasticsearch 로그 저장소 정보
로깅 Elasticsearch 인스턴스는 약 7일 동안 단기 스토리지용으로 최적화 및 테스트되었습니다. 로그를 장기간 유지하려면 데이터를 타사 스토리지 시스템으로 이동하는 것이 좋습니다.
Elasticsearch는 Fluentd의 로그 데이터를 데이터 저장소 또는 인덱스로 구성한 다음 각 인덱스를 shards라고 하는 조각 여러 개로 다시 세분화합니다. 그리고 이 조각을 Elasticsearch 클러스터의 Elasticsearch 노드 세트에 분산 배치합니다. 복제본이라는 이름의 shard 사본을 작성하도록 Elasticsearch를 구성할 수 있습니다. Elasticsearch는 이 역시 Elasticsearch 노드에 분산 배치합니다. ClusterLogging 사용자 정의 리소스(CR)를 사용하면 shard의 복제 방식을 지정하여 데이터 중복성과 장애에 대한 회복 탄력성을 제공할 수 있습니다. ClusterLogging CR의 보존 정책을 사용하여 다양한 로그 유형의 보존 기간을 지정할 수도 있습니다.
인덱스 템플릿의 기본 shard 수는 Elasticsearch 데이터 노드 수와 같습니다.
Red Hat OpenShift Logging Operator 및 그에 동반되는 OpenShift Elasticsearch Operator는 각 Elasticsearch 노드가 자체 스토리지 볼륨이 있는 고유한 배포를 사용하여 배포되도록 합니다. 필요에 따라 ClusterLogging 사용자 정의 리소스(CR)를 사용하여 Elasticsearch 노드 수를 늘릴 수 있습니다. 스토리지 구성과 관련된 고려 사항은 Elasticsearch 설명서를 참조하십시오.
고가용성 Elasticsearch 환경에는 각각 서로 다른 호스트에 있는 최소 3개의 Elasticsearch 노드가 필요합니다.
Elasticsearch 인덱스에 적용된 RBAC(역할 기반 액세스 제어)를 사용하면 개발자에 대한 로그 액세스를 제어할 수 있습니다. 관리자는 모든 로그에 액세스할 수 있으며 개발자는 프로젝트의 로그에만 액세스할 수 있습니다.
10.1.2. 로그 저장소 쿼리
LogQL 로그 쿼리 언어를 사용하여 Loki를 쿼리 할 수 있습니다.
