엔지니어링

인프라 및 로그 UI: 운영팀이 Elasticsearch와 상호 작용하는 새로운 방법

Elastic Stack 버전 6.5를 통해 데이터와 상호 작용하는 두 가지 새로운 방법을 출시했습니다. 바로 인프라 및 로그 UI입니다. 둘 다 6.5의 베타 버전이며, 이 부분은 나중에 여러분에게 피드백을 요청할 때 다시 다루도록 하겠습니다. 먼저 이 방법 각각에 대해 이를 개발하게 된 동기, 사용자 경험 및 UI 구성을 살펴보려고 합니다. 로그 UI부터 살펴보겠습니다.

로그 UI

동기

저는 "그냥 로그만 주세요. 복잡한 기능은 필요 없어요. 알아야 할 모든 것이 로그에 적혀 있습니다. 난 단지 이를 읽고 싶어요."라는 말을 아주 많이 들었습니다. Elastic은 사용자의 의견을 존중합니다. 선택은 사용자에게 달려 있습니다.

맨 아래에 있는 경험이 가장 최근의 경험인 tail -f의 업그레이드 버전, 테이블, 차트, 태그 클라우드 등을 사용한 시각적 경험 또는 테이블 형식의 보기가 지원됩니다. 사용자는 자신에게 가장 적합한 방식으로 일할 수 있어야 하며, Elastic Stack의 개방성이 이를 지원합니다.

Logs-small.jpg visuals-small.jpg discover-small.jpg

사용자 경험

로그 UI를 사용하는 것은 로그 파일을 추적하는 것과 유사하지만, 모든 시스템의 모든 로그를 하나의 콘솔에서 사용할 수 있다는 점이 다릅니다. 로그가 스트리밍되고 tail -f와 마찬가지로 뷰의 맨 아래 레코드가 가장 최근의 레코드입니다. 기본적으로 로그 UI에는 구성 기준을 충족하는 모든 로그의 모든 레코드가 표시됩니다(자세한 내용은 다음 섹션 참조). 문제를 해결할 때 모든 서비스의 모든 로그가 동시에 필요하지 않다고 판단되면(누군가 읽을 수 있는 것보다 빠른 속도로 스트리밍됨) 상단의 검색 창에 입력하여 상호 작용을 변경하면 됩니다. 예를 들어, Kubernetes 레이블 티어 = "frontend"인 Apache httpd pod에서 404 오류만 보려는 경우 검색 창에 입력을 시작하기만 하면 자동 완성 기능을 통해 올바른 로그를 찾을 수 있습니다.

이를 터미널을 열고, k8s 제공업체로 인증하고, 원하는 pod를 파악하고, kubectl logs -f … | grep 404를 실행하는 것(아니면 비 컨테이너 환경에서 호스트 이름을 찾아 ssh로 액세스한 후 로그를 추적하는 것 등)과 비교하십시오. Elastic에서는 사용자의 삶을 더 편하게 만들고 사용자가 원하는 방식으로 데이터를 제공하고자 합니다.

구성

언제나처럼 로그 UI 설명서가 제공되지만 이 블로그에서는 구성 옵션 중 일부를 살펴보려고 합니다. 다음은 기본 구성으로, 이를 config/kibana.yml에 붙여넣은 후 원하는 대로 수정할 수 있습니다.

xpack.infra.sources.default.logAlias: "filebeat-*"
xpack.infra.sources.default.fields.timestamp: "@timestamp"
xpack.infra.sources.default.fields.message: ['message', '@message']

구성은 매우 간단합니다. 처음에 로그 UI에 표시되는 줄은 filebeat-* 별칭과 일치하는 모든 인덱스의 메시지 필드입니다. 그러면 모든 Logstash 인덱스를 추가하려면 어떻게 해야 할까요? config/kibana.yml 항목에서 xpack.infra.sources.default.logAlias를 모든 Logstash 인덱스를 추가하도록 수정하고 Kibana를 다시 시작하면 됩니다.

#xpack.infra.sources.default.logAlias: "filebeat-*"
xpack.infra.sources.default.logAlias: "filebeat-*,logstash-*"

Kibana를 다시 시작하는 것을 잊지 마세요. 로그 UI를 다시 열고 [Stream Live]를 클릭하면 모든 Logstash 및 Filebeat 로그가 로그 UI로 스트리밍되는 것을 볼 수 있습니다.

참고: Elasticsearch 별칭을 사용하려면 xpack.infra.sources.default.logAlias를 별칭 이름으로 설정한 다음 필요에 따라 별칭을 업데이트하기만 하면 됩니다. 다음은 logs의 별칭을 사용하는 예제입니다.

별칭 생성:

curl -X POST "localhost:9200/_aliases" -H 'Content-Type: application/json' -d'
{
"actions" : [
{ "add" : { "indices" : ["logstash-*", "filebeat-*"], "alias" : "logs" } }
]
}
'

config/kibana.yml 업데이트:

#xpack.infra.sources.default.logAlias: "filebeat-*"
xpack.infra.sources.default.logAlias: "logs"

인프라 UI

동기

인프라 관리에는 세 가지 기본적인 성숙도 단계가 있습니다.

  1. 무언가에 장애가 발생한 것을 발견하고 모니터링 시스템을 열어 조사합니다.
  2. 큰 대시보드에 모든 시스템에 대한 주요 지표를 차트로 작성하고, 이를 관찰한 다음, 문제를 파헤칩니다.
  3. 머신 러닝을 통해 운영을 자동화하여 정상적인 동작을 파악하고, 새로운 문제를 감지하고, 운영팀에 알립니다.

인프라 UI는 운영이 ‘큰 대시보드에 주요 지표를 차트로 작성’하는 단계에 이르도록 설계되었습니다. 우리 모두는 ‘머신 러닝으로 자동화하는 단계’로 가야 합니다. 자세한 내용은 Elastic 머신 러닝에서 확인할 수 있으며, 이 게시물 끝부분에 있는 비디오를 보면 머신 러닝 작업의 알림에서 시작하여 APM 및 분산 추적, 인프라 UI 및 로그 UI를 통해 이동하는 워크플로우를 확인할 수 있습니다. 모든 로그, 메트릭, APM 및 분산 추적이 모두 Elasticsearch에 있으므로 모든 데이터에서 모든 분석 및 시각화 도구를 사용할 수 있습니다.

먼저 인프라 UI를 살펴본 후 자세히 알아보겠습니다. 다음은 Kubernetes pod 화면인데 제가 pod를 네임스페이스별로 그룹화했습니다. 저는 인바운드 네트워크 트래픽을 살펴보고 있습니다. Pod 중 하나를 마우스 오른쪽 버튼으로 클릭하면 해당 pod의 로그 또는 해당 pod의 큐레이션된 메트릭 대시보드로 이동할 수 있습니다.

사용자 경험

호스트, Kubernetes(k8s) pod, Docker 컨테이너라는 세 가지 유형의 디바이스가 현재 지원됩니다. 인프라 UI의 장점은 매우 많은 수의 디바이스에 대한 주요 지표의 상태를 볼 수 있다는 것입니다. 볼륨이 큰 경우, 검색창을 사용하거나 그룹을 클릭하여 관심 있는 하위 세트로 드릴다운할 때까지는 텍스트 없이 색상으로만 구분된 사각형이 표시됩니다. 디바이스의 로그를 시작하거나 메트릭 대시보드를 표시할 수도 있습니다.

앞서 ‘주요 지표’에 대해 언급했는데요. 현재 목록은 다음과 같으며 모두 Metricbeat에서 제공하는 지표입니다.

호스트: CPU, 메모리, 로드, 인바운드 트래픽, 아웃바운드 트래픽 및 로그 속도
Kubernetes: CPU, 메모리, 인바운드 트래픽, 아웃바운드 트래픽
Docker: CPU, 메모리, 인바운드 트래픽, 아웃바운드 트래픽

그룹화를 사용하면 디바이스 목록을 확대할 수 있습니다. Kubernetes와 함께 배포된 특정 애플리케이션을 지원하는 경우 네임스페이스 그룹이 적합합니다. 문제가 특정 노드가 오버로드되는 것과 관련이 있다고 생각되면 네임스페이스와 노드 둘 다로 그룹화하여 더 세분화할 수 있습니다. 현재 그룹화 목록은 다음과 같으며 디바이스 유형당 최대 2개까지 사용할 수 있습니다.

호스트: 가용 영역, 머신 유형, 프로젝트 ID, 클라우드 서비스 제공자
Kubernetes: 네임스페이스, 노드
Docker: 호스트, 가용 영역, 머신 유형, 프로젝트 ID, 서비스 제공자

여러분이 데이터와 상호 작용하려는 방식을 지원하는 그룹이 위의 그룹 중에 없다면 검색 창을 사용하십시오. 입력을 시작하기만 하면 Kibana Query Language(KQL) 자동 완성 기능이 여러분을 안내할 것입니다. 위에서 로그 UI의 GIF로 예제를 보여드렸는데요. 제가 kubernetes를 입력하기 시작하면 Kibana는 레이블과 티어를 제시한 다음 Elasticsearch에 색인된 항목을 기반으로 선택 가능한 옵션을 제공했습니다.

리소스를 그룹화한 후에는 그룹을 클릭하여 드릴다운할 수 있으므로 해당 그룹에 대한 자세한 정보를 볼 수 있습니다. 특정 호스트, pod 또는 컨테이너에 관심이 있는 경우 해당 항목의 로그 또는 메트릭을 드릴다운하십시오. 다음은 호스트 메트릭 뷰의 일부입니다.

구성

인프라 UI의 경우에는 구성이 필요한 부분이 거의 없습니다. Metricbeat를 배포하고 시스템 모듈을 활성화하기만 하면 됩니다. 컨테이너를 실행 중이라면 KubernetesDocker 모듈도 활성화하십시오.

기본 인덱스 패턴(Metricbeat-*)을 수정한 경우가 아니라면 이것으로 끝입니다. 사용자 정의가 필요한 경우 자세한 내용은 인프라 UI 설명서를 참조하십시오. 여기에는 주요 옵션만 적어두었습니다.

xpack.infra.sources.default.metricAlias: "metricbeat-*"
xpack.infra.sources.default.fields.host: "beat.hostname"
xpack.infra.sources.default.fields.container: "docker.container.name"
xpack.infra.sources.default.fields.pod: "kubernetes.pod.name"

의견을 알려주세요

이 두 가지 모두 베타 UI로, Elastic에서는 사용자의 피드백을 환영합니다. 그뿐만 아니라 정식 버전으로 출시된 후에도 계속해서 피드백에 귀를 기울일 예정입니다. 데이터와 어떻게 상호작용하길 원하는지 말씀해주세요. 인프라 UI 베타 릴리즈의 그룹화 기능이 팀 구성 방식을 지원하기에 충분한가요? 무엇이 더 나을까요? 메트릭에 적절한 색상을 사용하고 있나요? 로그 UI에서 로그를 필터링하는 다른 방법이 필요하신가요? 인프라 UI에서 메트릭 뷰를 시작하면 관심 있는 메트릭이 표시되나요?

Kibana 토론 포럼으로 가셔서 좋아하는 것, 싫어하는 것, 필요한 것 등을 알려주세요. 피드백을 환영하는 Elastic 개발자들이 남겨주신 내용을 읽고 답변을 드릴 것입니다. 또한 GitHub에서 케이스를 생성하거나 PR을 제출하거나 이를 계속 확인할 수 있습니다.

지금 사용해보세요

라이브 데모 시스템에는 여러분이 검색, 시각화 및 상호 작용할 수 있는 로그와 메트릭이 있습니다. 데모에서 인프라 타일을 클릭하여 인프라 UI를 시작하십시오.

JumpIn.jpg

Kubernetes 또는 Docker 뷰로 전환하거나, UI를 사용하여 객체를 그룹화하거나, 검색 창을 사용하여 뷰의 범위를 좁힐 수 있습니다. 호스트, pod 또는 컨테이너를 마우스 왼쪽 버튼으로 클릭하고 해당 객체에 대한 로그 UI를 시작하십시오. demo.elastic.co에 있는 동안 대시보드 및 시각화도 일부 살펴보시기 바랍니다. 랜딩 페이지에서 다른 영역으로 이동할 수 있습니다.

데모 시청

다음은 이러한 UI(그리고 분석 추적을 지원하는 APM 및 머신 러닝)의 워크플로우를 보여주는 비디오입니다. 읽어주셔서 다시 한번 감사드립니다. 그리고 여러분의 피드백을 기다리겠습니다!