Elastic에서는 오픈 소스와 오픈 표준을 수용합니다. ELK 스택을 통해 Prometheus 메트릭을 가져와 이를 다른 모든 데이터와 시각화하는 방법을 살펴보세요.

<p>이 블로그에서는 다음을 다룹니다.
</p>
<ul>
	<li>오픈 표준이 중요한 이유</li>
	<li>Prometheus 설명 형식</li>
	<li>Elastic에서 observability를&nbsp;고려하는 방식</li>
	<li>Elasticsearch에서 Prometheus 메트릭을 소비하는 세 가지 방식</li>
	<li>Prometheus Redis 내보내기에서 노출되는
메트릭을 수집하고 시각화하는 방식의 예시
	</li>
</ul>
<h2>오픈 표준</h2>
<p>웹페이지 
	<a href="http://opensource.com">opensource.com</a>에는 다음과 같은 제목의 정보 전달형 자료가 있습니다. "<a href="https://opensource.com/resources/what-are-open-standards">오픈 표준이란 무엇인가요?</a>".  이 문서에는
여러 중요한 강조점이 있지만 운영 부서에서 몇 년의 경험을
쌓은 저로서는 다음 사항이 가장 공감되는 내용이었습니다.
</p>
<ol start="1">
	<li>가용성: 오픈 표준은 모두가 읽고 구현할 수 있도록
공개되어 있습니다.
	</li>
	<li>최종 사용자 선택을 최대화</li>
	<li>차별 없음(공급업체 중립성): 오픈 표준과 이를 적용하는
조직에서는 하나의 구현자를 다른 하나에 비해
선호하지 않습니다.
	</li>
	<li>의도적인 기밀 없음: 표준은 상호 운용 가능한 구현에 필요한
어떠한 세부 사항도 숨기지 않아야 합니다.
	</li>
</ol>
<p>이러한 사항이 오픈 표준이 좋은 이유이며
이제는 
	<a href="https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md">
	Prometheus 설명 형식</a>이 <a href="https://openmetrics.io/">
	OpenMetrics</a>의 기반이 되는 이유를 살펴보겠습니다. Richard Hartmann은 그의 <a href="https://promcon.io/2018-munich/slides/openmetrics-transforming-the-prometheus-exposition-format-into-a-global-standard.pdf">
	PromCon 2018</a> 및 KubeCon + <a href="https://www.youtube.com/watch?v=DARVop91kBQ">
	CloudNativeCon</a> North America 2018에서
Prometheus 설명 형식에 의해 영향을 받은 오픈 표준을
생성하는 이유를 이렇게 요약했습니다.
</p>
<ul>
	<li>대부분의 데이터는 독점적이며, 구현이 어렵거나 두 가지
모두에 해당합니다
	</li>
	<li>Prometheus는 사실상 클라우드 네이티브 메트릭 모니터링에서
표준이 되었습니다
	</li>
	<li>설명 데이터의 편의성은 <a href="https://prometheus.io/docs/instrumenting/exporters/">
	호환 가능한 메트릭 엔드포인트</a>의 급격한 성장으로 이어졌습니다</li>
	<li>Prometheus의 설명 형식은 많은 운영 경험에 기반을 둔 것이었으나
몇몇 사람들 사이에서 설계되었습니다
	</li>
	<li>일부 기타 프로젝트와 공급업체는 “경쟁하는” 제품의 무언가를
도입하는 것에 대한 의견이 양분되었습니다
	</li>
</ul>
<h2>Prometheus 설명 형식</h2>
<p>설명 형식에 대한 자세한 정보는 <a href="https://github.com/prometheus/docs/blob/master/content/docs/instrumenting/exposition_formats.md">
	Prometheus Github 보관소</a>에서 읽어보실 수 있습니다. 지금은 예시를 살펴보겠습니다.
 여기 /metrics 엔드포인트로 포트 9121에서 메트릭을 게시하는 
	<a href="https://github.com/oliver006/redis_exporter">
	Oliver006's Redis 내보내기</a>가
있습니다.  저는 지금 여기에 Redis “초당 동시 운영” 메트릭에 대한 정보를
보여드리고 있을 뿐입니다.  판독할 정보는
세 줄 뿐입니다.
</p>
<ol start="1">
	<li>도움말 텍스트</li>
	<li>메트릭 유형(이 경우 게이지)</li>
	<li>측정된 Redis 서버(로컬호스트 포트 6379), 및 현재
판독값(초당 ops 9개)
	</li>
</ol>
<p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltdc2597dd9d329537/5cd475e29033f96a5b031b8b/roscigno-prometheus-exposition-format.png" data-sys-asset-uid="bltdc2597dd9d329537" alt="roscigno-prometheus-exposition-format.png">
</p>
<h2>Elastic의 Observability</h2>
<p>여러분께서 <a href="/kr/blog/observability-with-the-elastic-stack">
	Elastic에서 Observability를&nbsp;어떤 방식으로 고려하는지</a>에 대한 글을 읽어보시길 권장하지만 다음은
제가 게시글에서 가장 좋아하는 구절입니다.
</p>
<blockquote>‘관측 가능한’ 시스템을 설계하고 구축하는 것의 목표는
시스템이 생산 단계에서 실행되는지 확인하고 시스템 관리 운영자가
바람직하지 않은 동작(예: 서비스 중단 시간, 오류, 느린 응답)을
감지할 수 있으며, 효과적인 방식(예: 자세한 이벤트 로그, 세분화된
리소스 사용 정보 및 애플리케이션 추적)으로
근본 원인을 찾아내어 조치 가능한 정보를 획득하는 것입니다.
</blockquote>
<p>이는 제가 진정으로 공감하는 말이며 이를 통해 우리가 제공하는 서비스를
실행, 정비 및 관리하기 위해 모든 로그, 메트릭 및
추적 정보가 필요하다는 점을 알 수 있습니다.  Prometheus는 광범위한
도입 및 활성화된 커뮤니티로 인해 observability의 매우 중요한
일부분이라고 할 수 있습니다.  OpenMetrics 표준은 실제로든 인식한 것이든 장벽을 없애고
상식적인 “born in ops” 메트릭 형식을 도입함으로써
가치가 계속 높아질 일밖에 남지 않았습니다.
</p>
<p>저와 이야기를 나눈 대부분의 사람들은 로깅에 있어 Elastic
Stack 또는 ELK와 굉장히 친숙합니다.  Elastic Stack이 메트릭과 APM에도
훌륭하다는 점을 모르고 계셨다면 
	<a href="/kr/blog/elasticsearch-as-a-time-series-database-for-telemetry-data-at-ns1">
	메트릭</a> 및 <a href="/kr/solutions/apm">
	APM / 분산 추적</a>에 대한 당사 정보를 확인해 보세요.
</p>
<p>메트릭을 내보내기 하는 방식으로서 Elastic Stack와 Prometheus간의
깊은 통합에 관심을 가진 주요 이유는 다음과 같습니다.
</p>
<ul>
	<li>Elasticsearch에서 메트릭과 로그 및 APM을 결합하고
이를 Kibana에서 상호 비교합니다. Elastic Stack에서 로그와 메트릭 결합에 대한 NS1의 
	<a href="/kr/blog/elasticsearch-as-a-time-series-database-for-telemetry-data-at-ns1">
	사용자 이야기</a>를 확인해
보세요.
	</li>
	<li>현재 네이티브 클러스터링을 지원하지 않는 Prometheus 서버에서
수집한 메트릭의 장기 저장을 위해 Elasticsearch를
사용합니다.
	</li>
	<li>지역적으로 분포되어 있는 Prometheus 인스턴스 전반에서
메트릭에 대한 글로벌 뷰를 생성합니다.
	</li>
</ul>
<p>블로그의 나머지 내용에는 당사에서 이러한 통합에 접근하는 방식이
설명되어 있습니다.
</p>
<h3>샘플 내보내기</h3>
<p>제 데모 환경은 Google
Kubernetes Engine(GKE)에서 실행 중이어서 애플리케이션과 Metricbeat,
그리고 Prometheus 내보내기를 모두 Kubernetes에서 실행 중입니다.  이는
Redis 내보내기를 Redis 이미지를 동반한 사이드카로서 Redis
내보내기를 배포하는 Oliver006의 메니페스트 일부입니다.  내보내기는 포트 9121에서
게시되고 있으며 이는 Prometheus Redis 내보내기에 대한 
	<a href="https://github.com/prometheus/prometheus/wiki/Default-port-allocations">
	기본 할당 포트 번호</a>
	입니다.
</p>
<pre class="prettyprint">...
  - name: redis-exporter
    image: oliver006/redis_exporter:latest
    resources:
      requests:
        cpu: 100m
        memory: 100Mi
    ports:
    - containerPort: 9121
...
</pre>
<p><a href="https://github.com/elastic/examples/blob/master/scraping-prometheus-k8s-with-metricbeat/guestbook.yaml">전체 소스는 GitHub에서 확인</a>
</p>
<h3>Metricbeat Prometheus 모듈로 메트릭 스크랩
</h3>
<p><a href="/kr/products/beats/metricbeat">
	Metricbeat</a>는 Elastic의 메트릭에 대한 경량 데이터 전송 프로그램입니다.  Metricbeat과 함께 전송하는
	<a href="/guide/en/beats/metricbeat/7.0/metricbeat-module-prometheus.html">
	Prometheus 모듈</a>은 세 가지 방식으로 메트릭을 수집할 수
있습니다:
</p>
<ol start="1">
	<li>포트 9090에서 Prometheus 서버에 연결하여 Prometheus 페더레이션 API
를 사용해 이미 수집된 메트릭을 수집(Prometheus가 수집하는
메트릭을 얻기 위해)
	</li>
	<li>/metrics 엔드포인트를 사용해 포트 9090에서 Prometheus 서버에
연결(Prometheus 자가 모니터링)
	</li>
	<li>Prometheus 내보내기에 개별적으로 연결하고 설명 형식을
구문 분석
	</li>
</ol>
<p>다른 방식과 비교해 한 가지 접근 방식을 선택하는 이유는 무엇일까요? 이는 Prometheus
서버와의 편안함 정도에 따라 다릅니다.
</p>
<ul>
	<li>메트릭을 스크랩하기 위해 Prometheus 서버를 이미 설정하지
않았고 통합 목적을 위해 이러한 메트릭을 직접 쿼리하고자 하는 경우
옵션 (1) 및 (2)로 시작하실 수 있습니다.
	</li>
	<li>그러나 이미 Prometheus 서버가 준비되어 있지 않거나
내보내기를 여러 도구로 병렬 스크랩하는 것을 개의치 않는 경우
옵션 (3)을 선택하실 수 있습니다.
	</li>
</ul>
<p>참고: 상기 Metricbeat 기능의 일부는 Metricbeat 버전 7.0에서
베타 버전입니다.  따라서 
	<a href="/kr/downloads ">7.0 베타를 다운로드</a>하시거나
	컨테이너 링크를
	<a href="https://www.docker.elastic.co/">
	https://www.docker.elastic.co/</a>에서 복사해 비생산 환경에서 베타를 실행할 것을 권장합니다.
</p>
<h3>Prometheus 페더레이션 API</h3>
<p>일반적으로 페더레이션은 조정 활성화, 데이터세트를 함께 가져오거나 서로 다른 위치에서 사용할 수 있는 데이터의 복사본을 만들 때(재난 복구용) 사용합니다.  Prometheus 서버에서는 <a href="https://prometheus.io/docs/prometheus/latest/federation/"><code>/페더레이션</code> 엔드포인트</a>를 제공하며 Elastic은 위에 설명한 모든 이유를 위해 Prometheus에서 수집한 메트릭을 복사하고자 이 엔드포인트에 연결합니다.
</p>
<pre class="prettyprint">...
  - module: prometheus
    period: 10s
    hosts: ["prometheus-service.monitoring.svc.cluster.local:9090"]
    metrics_path: '/federate'
    query:
      'match[]': '{__name__!=""}'
...
</pre>
<p><a href="https://github.com/elastic/examples/blob/master/scraping-prometheus-k8s-with-metricbeat/metricbeat-kube-state-and-prometheus-server.yaml">GitHub에서 전체 소스 참조</a><a href="https://github.com/elastic/examples/blob/master/scraping-prometheus-k8s-with-metricbeat/metricbeat-kube-state-and-prometheus-server.yaml"></a>
</p>
<p>위 예시에서는 쿼리가 “공백이 아닌 이름으로 된 모든 값”으로 설정되어 있습니다.  모든 것을 수집하는 것이 좋으며 Prometheus 문서에는 더욱 제한적인 일치 조건을 작성할 수 있는 방법이 나와 있습니다.  예시는 또한 Pometheus 서버에 10초마다 연결하며 제 데모 서버는 몇몇 pod와 kube-state-metrics에서만 수집하고 있지만 이 주기를 변경하시는 것이 좋습니다.
</p>
<h3>Prometheus 자가 모니터링</h3>
<p>Prometheus에서는 내보내기와 동일하게 <code>/metrics</code> 엔드포인트를 제공합니다.  이는 Prometheus 서버에 대한 메트릭을 수집할 수 있도록 하기 위함입니다.  이는 다음과 같이 구성됩니다.
</p>
<pre class="prettyprint">...
  - module: prometheus
    period: 10s
    hosts: ["prometheus-service.monitoring.svc.cluster.local:9090"]
    metrics_path: /metrics
...
</pre>
<p><a href="https://github.com/elastic/examples/blob/master/scraping-prometheus-k8s-with-metricbeat/metricbeat-kube-state-and-prometheus-server.yaml">전체 소스는 GitHub에서 확인</a>
</p>
<h3>Prometheus 내보내기 스크랩</h3>
<p>Metricbeat DaemonSet를 배포하기 위한
메니페스트의 YAML의 일부는 Metricbeat에
대해 
	<code>kubernetes.labels.app</code> == <code>redis</code>로 자동 검색할 것을 지시하고 해당 pod의 포트 9121에서
메트릭을 읽습니다.  Redis 내보내기 컨테이너에 대해 설정된 
containerPort는 9121이라는 것을 기억하실 겁니다.
</p>
<pre class="prettyprint">...
- condition.equals:
    kubernetes.annotations.prometheus.io/scrape: "true"
  config:
    - module: prometheus
      period: 10s
      # Redis pods
      hosts: ["${data.host}:9121"]
      metrics_path: /metrics
...
</pre>
<p>Metricbeat가 배포되면 해당 조건인
kubernetes.labels.app == redis을 만족하는 모든 pod에는 적용된 Prometheus 모듈과
포트 9121에서 내보내기 사이드카로부터 수집된 메트릭이
있습니다.
</p>
<p>하지만 메타데이터는 k8s 세계를 돌게 하는 원동력이지 않습니까?  이제
메타데이터와 Beats 자동 검색 기능을 좀 더 실행해보겠습니다.  상기 YAML의
일부에 대한 대체물을 확인해 주십시오.
</p>
<pre class="prettyprint">...
- condition.equals:
    kubernetes.annotations.prometheus.io/scrape: "true"
  config:
    - module: prometheus
      period: 10s
      hosts: ["${data.host}:${data.kubernetes.annotations.prometheus.io/port}"]
      metrics_path: /metrics
...
</pre>
<p><a href="https://github.com/elastic/examples/blob/master/scraping-prometheus-k8s-with-metricbeat/metricbeat-prometheus-auto-discover.yaml">전체 소스는 GitHub에서 확인</a>
</p>
<p>이제 Redis pod에 대한 내보내기를
찾는 대신
	<code>kubernetes.annotations.prometheus.io/scrape</code>의 각주가 참으로 설정된 모든 pod에 대한 내보내기를 찾아 보겠습니다.  이는
또한 Prometheus 자동 검색이 설정된 방식이기도 합니다.  일반적으로 Metricbeat
자동 검색은 elastic.co 네임스페이스의 각주에 따라 구동되지만
지금 Prometheus 내보내기로부터의 판독값을 다루고 있으므로
Prometheus와 연관된 표준 k8s 각주를
적용해야 합니다.  위에서 호스트 목록을 살펴보면:
</p>
<p><code>hosts: ["${data.host}:${data.kubernetes.annotations.prometheus.io/port}"]</code>
</p>
<p>포트 9121는 Redis 내보내기의 포트이기 때문에 이를 더이상
하드코딩하지 않는 것을 보실 수 있습니다.  각주 
	<code>prometheus.io/port</code>가 내보내기에 대한 포트 번호에 설정되어 있습니다.  완전함을 위해 이러한 각주가
설정되어 있는 guestbook.yaml의 일부를
보여드리겠습니다.
</p>
<pre class="prettyprint">...
kind: Deployment
metadata:
  name: redis-master
spec:
  replicas: 1
  template:
    metadata:
      annotations:
        prometheus.io/scrape: "true"
        prometheus.io/port: "9121"
      labels:
        app: redis
...
</pre>
<p><a href="https://github.com/elastic/examples/blob/master/scraping-prometheus-k8s-with-metricbeat/guestbook.yaml">전체 소스는 GitHub에서 확인</a>
</p>
<p>메타데이터는 k8s의 세계를 돌아가게 한다고 말씀드렸습니다. 
이게 아마 70년대 노래이지 않았나 싶네요.
</p>
<h3>인사이트를 얻기 위한 시각화</h3>
<p>데이터를 Elastic Stack으로 가져오는 것은 좋지만 일단 데이터와 상호작용할 수 있어야 합니다.  아래 영상에서는 Prometheus에서 스크랩한(이후 Elastic Stack에 가져온) Redis 메트릭과 Metricbeat으로 직접 kube-state-metrics에서 수집한 Kubernetes 이벤트를 사용해 유용한 시각화 구축에 접근하는 방법을 보실 수 있습니다.
</p>
<p>영상과 함께 따라하며 자세한 안내를 받고자 하시는 경우
먼저 
	<a href="https://github.com/elastic/examples/blob/master/scraping-prometheus-k8s-with-metricbeat/README.md">
	예시 보관소</a>를 참조하십시오.
</p>
<div class="video embed-container" style="height: 319.725px;">
	<img style="width: 100%; margin: auto; display: block;" class="vidyard-player-embed" src="https://play.vidyard.com/kt1jkhu1sptWzV3Y1wrfwE.jpg" data-uuid="kt1jkhu1sptWzV3Y1wrfwE" data-v="4" data-type="inline">
</div>
<h2>Observability로 돌아와서</h2>
<p>마지막 섹션에서는 Olive006의 Redis 내보내기로 노출된 주요 Redis
메트릭에 대한 Kibana 시각화(초당 즉각 ops)를
생성했습니다.  다음 단계는 로그를 수집하고
대시보드를 생성해 애플리케이션 전반에서 로그 및 메트릭을
함께 결합하는 것입니다.
</p>
<p>Kubernetes 환경에서 로그를 수집하는 방법에 대해 
알아보시려면 먼저 
	<a href="https://github.com/elastic/examples/blob/master/MonitoringKubernetes/README.md">
	elastic/examples</a> GitHub 보관소에 있는 지침을 따를 것을 권장합니다.  몇 분만에 Filebeat, Metricbeat
및 Packetbeat에서 데이터를 수집해
Elasticsearch에 게시할 수 있습니다.  서로 다른 Beat로 전송하는 샘플 대시보드가
있으며 여러분이 Prometheus 데이터에 대한 시각화를 자체적으로
자유롭게 생성해 시각화를 함께 혼합하여 작업하는 방식에 맞는
대시보드를 생성할 수 있습니다. 문제를 겪거나 observability에 대한 이야기를 나누고자 할 경우 
	<a href="https://discuss.elastic.co">토론</a> 포럼에 글을 남겨 주세요.
</p>

blog-roscigno-wide.jpg

blog-roscigno-thumb.png

Elasticsearch Observability: Embracing Prometheus and OpenMetrics Standards for Metrics

Elasticsearch Observability: 메트릭에 대한 Prometheus 및 OpenMetrics 표준 수용

<p>Elastic Stack 버전 6.5를 통해 데이터와 상호 작용하는 두 가지 새로운 방법을 출시했습니다. 바로 인프라 및 로그 UI입니다. 둘 다 6.5의 베타 버전이며, 이 부분은 나중에 여러분에게 피드백을 요청할 때 다시 다루도록 하겠습니다. 먼저 이 방법 각각에 대해 이를 개발하게 된 동기, 사용자 경험 및 UI 구성을 살펴보려고 합니다. 로그 UI부터 살펴보겠습니다.</p><h2>로그 UI</h2><h3>동기</h3><p>저는 "그냥 로그만 주세요. 복잡한 기능은 필요 없어요. 알아야 할 모든 것이 로그에 적혀 있습니다. 난 단지 이를 읽고 싶어요."라는 말을 아주 많이 들었습니다. Elastic은 사용자의 의견을 존중합니다. 선택은 사용자에게 달려 있습니다.</p><p>맨 아래에 있는 경험이 가장 최근의 경험인 tail -f의 업그레이드 버전, 테이블, 차트, 태그 클라우드 등을 사용한 시각적 경험 또는 테이블 형식의 보기가 지원됩니다. 사용자는 자신에게 가장 적합한 방식으로 일할 수 있어야 하며, Elastic Stack의 개방성이 이를 지원합니다.</p><table border="0" style="width: 100%;"><tbody><tr><td><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltf9bdf54b4eeab8bc/5c57d6fb85820dce0bcc2bf5/Logs-small.jpg" data-sys-asset-uid="bltf9bdf54b4eeab8bc" alt="Logs-small.jpg" style="background-color: initial;"/> </td><td><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt1af8714b20964974/5c57d6ef16a7de000c2b32a0/visuals-small.jpg" data-sys-asset-uid="blt1af8714b20964974" alt="visuals-small.jpg"/> </td><td><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt7193fa48ab952fe4/5c57d6e94c9f4feb0b4c5843/discover-small.jpg" data-sys-asset-uid="blt7193fa48ab952fe4" alt="discover-small.jpg"/> </td></tr></tbody></table><h3>사용자 경험</h3><p>로그 UI를 사용하는 것은 로그 파일을 추적하는 것과 유사하지만, 모든 시스템의 모든 로그를 하나의 콘솔에서 사용할 수 있다는 점이 다릅니다. 로그가 스트리밍되고 tail -f와 마찬가지로 뷰의 맨 아래 레코드가 가장 최근의 레코드입니다. 기본적으로 로그 UI에는 구성 기준을 충족하는 모든 로그의 모든 레코드가 표시됩니다(자세한 내용은 다음 섹션 참조). 문제를 해결할 때 모든 서비스의 모든 로그가 동시에 필요하지 않다고 판단되면(누군가 읽을 수 있는 것보다 빠른 속도로 스트리밍됨) 상단의 검색 창에 입력하여 상호 작용을 변경하면 됩니다. 예를 들어, Kubernetes 레이블 티어 = "frontend"인 Apache httpd pod에서 404 오류만 보려는 경우 검색 창에 입력을 시작하기만 하면 자동 완성 기능을 통해 올바른 로그를 찾을 수 있습니다.</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt6f7988e6a847040c/5ca7ef626583cf3c4114a271/animated-gif-logs-ui-optimized.gif"/></p><p>이를 터미널을 열고, k8s 제공업체로 인증하고, 원하는 pod를 파악하고, kubectl logs -f … | grep 404를 실행하는 것(아니면 비 컨테이너 환경에서 호스트 이름을 찾아 ssh로 액세스한 후 로그를 추적하는 것 등)과 비교하십시오. Elastic에서는 사용자의 삶을 더 편하게 만들고 사용자가 원하는 방식으로 데이터를 제공하고자 합니다.</p><h3>구성</h3><p>언제나처럼 <a href="/guide/en/kibana/6.x/xpack-logs.html">로그 UI 설명서</a>가 제공되지만 이 블로그에서는 구성 옵션 중 일부를 살펴보려고 합니다. 다음은 기본 구성으로, 이를 config/kibana.yml에 붙여넣은 후 원하는 대로 수정할 수 있습니다.</p><pre class="prettyprint">xpack.infra.sources.default.logAlias: "filebeat-*"<br/>xpack.infra.sources.default.fields.timestamp: "@timestamp"<br/>xpack.infra.sources.default.fields.message: ['message', '@message']<br/></pre><p>구성은 매우 간단합니다. 처음에 로그 UI에 표시되는 줄은 filebeat-* 별칭과 일치하는 모든 인덱스의 메시지 필드입니다. 그러면 모든 Logstash 인덱스를 추가하려면 어떻게 해야 할까요? config/kibana.yml 항목에서 xpack.infra.sources.default.logAlias를 모든 Logstash 인덱스를 추가하도록 수정하고 Kibana를 다시 시작하면 됩니다.</p><pre class="prettyprint">#xpack.infra.sources.default.logAlias: "filebeat-*"<br/>xpack.infra.sources.default.logAlias: "filebeat-*,logstash-*"<br/></pre><p>Kibana를 다시 시작하는 것을 잊지 마세요. 로그 UI를 다시 열고 [Stream Live]를 클릭하면 모든 Logstash 및 Filebeat 로그가 로그 UI로 스트리밍되는 것을 볼 수 있습니다.</p><p><strong>참고</strong>: <a href="/guide/en/elasticsearch/reference/6.5/indices-aliases.html">Elasticsearch 별칭</a>을 사용하려면 xpack.infra.sources.default.logAlias를 별칭 이름으로 설정한 다음 필요에 따라 별칭을 업데이트하기만 하면 됩니다. 다음은 logs의 별칭을 사용하는 예제입니다.</p><p>별칭 생성:</p><pre class="prettyprint">curl -X POST "localhost:9200/_aliases" -H 'Content-Type: application/json' -d'<br/>{<br/>    "actions" : [<br/>        { "add" : { "indices" : ["logstash-*", "filebeat-*"], "alias" : "logs" } }<br/>    ]<br/>}<br/>'<br/></pre><p>config/kibana.yml 업데이트:</p><pre class="prettyprint">#xpack.infra.sources.default.logAlias: "filebeat-*"<br/>xpack.infra.sources.default.logAlias: "logs"<br/></pre><h2>인프라 UI</h2><h3>동기</h3><p>인프라 관리에는 세 가지 기본적인 성숙도 단계가 있습니다.</p><ol><li>무언가에 장애가 발생한 것을 발견하고 모니터링 시스템을 열어 조사합니다.</li><li><span></span>큰 대시보드에 모든 시스템에 대한 주요 지표를 차트로 작성하고, 이를 관찰한 다음, 문제를 파헤칩니다.</li><li>머신 러닝을 통해 운영을 자동화하여 정상적인 동작을 파악하고, 새로운 문제를 감지하고, 운영팀에 알립니다.</li></ol><p>인프라 UI는 운영이 ‘큰 대시보드에 주요 지표를 차트로 작성’하는 단계에 이르도록 설계되었습니다. 우리 모두는 ‘머신 러닝으로 자동화하는 단계’로 가야 합니다. 자세한 내용은 <a href="/kr/products/stack/machine-learning">Elastic 머신 러닝</a>에서 확인할 수 있으며, 이 게시물 끝부분에 있는 비디오를 보면 머신 러닝 작업의 알림에서 시작하여 APM 및 분산 추적, 인프라 UI 및 로그 UI를 통해 이동하는 워크플로우를 확인할 수 있습니다. 모든 로그, 메트릭, APM 및 분산 추적이 모두 Elasticsearch에 있으므로 모든 데이터에서 모든 분석 및 시각화 도구를 사용할 수 있습니다.</p><p>먼저 인프라 UI를 살펴본 후 자세히 알아보겠습니다. 다음은 Kubernetes pod 화면인데 제가 pod를 네임스페이스별로 그룹화했습니다. 저는 인바운드 네트워크 트래픽을 살펴보고 있습니다. Pod 중 하나를 마우스 오른쪽 버튼으로 클릭하면 해당 pod의 로그 또는 해당 pod의 큐레이션된 메트릭 대시보드로 이동할 수 있습니다.</p><h3>사용자 경험</h3><p>호스트, Kubernetes(k8s) pod, Docker 컨테이너라는 세 가지 유형의 디바이스가 현재 지원됩니다. 인프라 UI의 장점은 매우 많은 수의 디바이스에 대한 주요 지표의 상태를 볼 수 있다는 것입니다. 볼륨이 큰 경우, 검색창을 사용하거나 그룹을 클릭하여 관심 있는 하위 세트로 드릴다운할 때까지는 텍스트 없이 색상으로만 구분된 사각형이 표시됩니다. 디바이스의 로그를 시작하거나 메트릭 대시보드를 표시할 수도 있습니다.</p><p>앞서 ‘주요 지표’에 대해 언급했는데요. 현재 목록은 다음과 같으며 모두 Metricbeat에서 제공하는 지표입니다.</p><p style="margin-left: 20px;">호스트: CPU, 메모리, 로드, 인바운드 트래픽, 아웃바운드 트래픽 및 로그 속도<br/>Kubernetes: CPU, 메모리, 인바운드 트래픽, 아웃바운드 트래픽<br/>Docker: CPU, 메모리, 인바운드 트래픽, 아웃바운드 트래픽</p><p>그룹화를 사용하면 디바이스 목록을 확대할 수 있습니다. Kubernetes와 함께 배포된 특정 애플리케이션을 지원하는 경우 네임스페이스 그룹이 적합합니다. 문제가 특정 노드가 오버로드되는 것과 관련이 있다고 생각되면 네임스페이스와 노드 둘 다로 그룹화하여 더 세분화할 수 있습니다. 현재 그룹화 목록은 다음과 같으며 디바이스 유형당 최대 2개까지 사용할 수 있습니다.</p><p style="margin-left: 20px;">호스트: 가용 영역, 머신 유형, 프로젝트 ID, 클라우드 서비스 제공자<br/>Kubernetes: 네임스페이스, 노드<br/>Docker: 호스트, 가용 영역, 머신 유형, 프로젝트 ID, 서비스 제공자</p><p>여러분이 데이터와 상호 작용하려는 방식을 지원하는 그룹이 위의 그룹 중에 없다면 검색 창을 사용하십시오. 입력을 시작하기만 하면 <a href="/guide/en/kibana/6.5/kuery-query.html">Kibana Query Language(KQL)</a> 자동 완성 기능이 여러분을 안내할 것입니다. 위에서 로그 UI의 GIF로 예제를 보여드렸는데요. 제가 kubernetes를 입력하기 시작하면 Kibana는 레이블과 티어를 제시한 다음 Elasticsearch에 색인된 항목을 기반으로 선택 가능한 옵션을 제공했습니다.</p><p>리소스를 그룹화한 후에는 그룹을 클릭하여 드릴다운할 수 있으므로 해당 그룹에 대한 자세한 정보를 볼 수 있습니다. 특정 호스트, pod 또는 컨테이너에 관심이 있는 경우 해당 항목의 로그 또는 메트릭을 드릴다운하십시오. 다음은 호스트 메트릭 뷰의 일부입니다.</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt0db77ee61091f61f/5d2848c18e6f797b0da2f02e/screenshot-metrics-infrastructure-monitoring-feature-page.jpg"/></p><h3>구성</h3><p>인프라 UI의 경우에는 구성이 필요한 부분이 거의 없습니다. Metricbeat를 배포하고 <a href="/guide/en/beats/metricbeat/6.5/metricbeat-module-system.html">시스템 모듈</a>을 활성화하기만 하면 됩니다. 컨테이너를 실행 중이라면 <a href="/guide/en/beats/metricbeat/6.5/metricbeat-module-kubernetes.html">Kubernetes</a>와 <a href="/guide/en/beats/metricbeat/6.5/metricbeat-module-docker.html">Docker 모듈</a>도 활성화하십시오.</p><p>기본 인덱스 패턴(Metricbeat-*)을 수정한 경우가 아니라면 이것으로 끝입니다. 사용자 정의가 필요한 경우 자세한 내용은 <a href="/guide/en/kibana/6.x/xpack-infra.html">인프라 UI 설명서</a>를 참조하십시오. 여기에는 주요 옵션만 적어두었습니다.</p><pre class="prettyprint">xpack.infra.sources.default.metricAlias: "metricbeat-*"<br/>xpack.infra.sources.default.fields.host: "beat.hostname"<br/>xpack.infra.sources.default.fields.container: "docker.container.name"<br/>xpack.infra.sources.default.fields.pod: "kubernetes.pod.name"<br/></pre><h2>의견을 알려주세요</h2><p>이 두 가지 모두 베타 UI로, Elastic에서는 사용자의 피드백을 환영합니다. 그뿐만 아니라 정식 버전으로 출시된 후에도 계속해서 피드백에 귀를 기울일 예정입니다. 데이터와 어떻게 상호작용하길 원하는지 말씀해주세요. 인프라 UI 베타 릴리즈의 그룹화 기능이 팀 구성 방식을 지원하기에 충분한가요? 무엇이 더 나을까요? 메트릭에 적절한 색상을 사용하고 있나요? 로그 UI에서 로그를 필터링하는 다른 방법이 필요하신가요? 인프라 UI에서 메트릭 뷰를 시작하면 관심 있는 메트릭이 표시되나요?</p><p><a href="https://discuss.elastic.co/c/kibana">Kibana 토론 포럼</a>으로 가셔서 좋아하는 것, 싫어하는 것, 필요한 것 등을 알려주세요. 피드백을 환영하는 Elastic 개발자들이 남겨주신 내용을 읽고 답변을 드릴 것입니다. 또한 <a href="https://github.com/elastic/kibana">GitHub</a>에서 케이스를 생성하거나 PR을 제출하거나 이를 계속 확인할 수 있습니다.</p><h2>지금 사용해보세요</h2><p>라이브 <a href="https://demo.elastic.co/">데모 시스템</a>에는 여러분이 검색, 시각화 및 상호 작용할 수 있는 로그와 메트릭이 있습니다. 데모에서 인프라 타일을 클릭하여 인프라 UI를 시작하십시오.</p><p><a href="https://demo.elastic.co"><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltc85a8861b14f7f05/5c57d682a669c2e50b763c45/JumpIn.jpg" data-sys-asset-uid="bltc85a8861b14f7f05" alt="JumpIn.jpg" width="200" height="187" style="width: 200;height: 187;"/></a></p><p>Kubernetes 또는 Docker 뷰로 전환하거나, UI를 사용하여 객체를 그룹화하거나, 검색 창을 사용하여 뷰의 범위를 좁힐 수 있습니다. 호스트, pod 또는 컨테이너를 마우스 왼쪽 버튼으로 클릭하고 해당 객체에 대한 로그 UI를 시작하십시오. demo.elastic.co에 있는 동안 대시보드 및 시각화도 일부 살펴보시기 바랍니다. <a href="https://demo.elastic.co/">랜딩 페이지</a>에서 다른 영역으로 이동할 수 있습니다.</p><h2>데모 시청</h2><p>다음은 이러한 UI(그리고 분석 추적을 지원하는 APM 및 머신 러닝)의 워크플로우를 보여주는 비디오입니다. 읽어주셔서 다시 한번 감사드립니다. 그리고 여러분의 피드백을 기다리겠습니다!</p><div class="video embed-container" style="height: 478px;"><img style="width: 677;margin: auto;display: block;" class="vidyard-player-embed" src="https://play.vidyard.com/78EpMXQeU57jR7HrKsMXqK.jpg" data-uuid="78EpMXQeU57jR7HrKsMXqK" data-v="4" data-type="inline" width="677"/></div>

infrastructure-and-logs-background.jpg

infrastructure-and-logs-thumbnail.jpg

Infrastructure and Logs UI: New ways for Ops to interact with Elasticsearch

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

Elastic Stack으로 Docker 및 Kubernetes 로그 및 메트릭을 모니터링하세요. Beats로 컨테이너 데이터를 수집하고, Elasticserch로 분석하며 Kibana로 시각화하세요.

<p>이 블로그는 컨테이너 환경을 모니터링에 대해 설명하며 <a href="https://cloud.google.com/kubernetes-engine/">Google Kubernetes Engine</a>(GKE), <a href="https://www.ibm.com/cloud/container-service">IBM Cloud Kubernetes Service</a> 및 기타 모든 Kubernetes(k8s) 및&nbsp;Docker 환경을 포함할 수 있습니다. 이 블로그의 목적으로, IBM Cloud Kubernetes Service를 사용하겠습니다.
</p>
<p>Kubernetes 및 Docker 컨테이너 모니터링에 대해 왜 쓰고 있는지 궁금해 하실지도 모르겠습니다. 클라우드 공급자가 인프라를 관리하고 있으니, 나는 내 앱에 대해서만 생각하면 된다, 그렇게 생각하시겠죠? 옳은 생각일 수도 있지만, 저는 개인 추천을 받았어도 Yelp 리뷰를 확인하는 사람입니다. 가지고 있는 정보가 더 많을수록 더 좋은 것이죠. 저는 내 앱에서의 모든 로그와 메트릭, 또 환경을 사용할 수 있기 원하고 이 모두를 검색, 시각화하고 경보를 보낼 수 있기 원합니다. 일반적인 컨테이너 모니터링은 훌륭하지만, Kubernetes 이벤트 및 메타데이터를 사용해서 앱 성능 차트에 스케일링 또는 롤링 업데이트에 대한 알림을 표시하는 멋진 방법을 보여 드리고자 합니다.
</p>
<p>계속하기 전에 몇 가지 용어를 정리해 드리겠습니다.
</p>
<ul>
	<li><strong>로그:</strong> 타임 스탬프 및 메시지입니다. 여기에는 "NGINX started at 13:42(NGINX, 13:42에 시작됨)"와 같은 일반적인 로그 항목이 포함되며 "There was an NGINX container with a Back-off restarting failed container at 16:20 (16:20에 백오프 재시작이 실패한 컨테이너를 가진 NGINX 컨테이너가 있습니다)."와 같은 k8s 이벤트가 포함됩니다.</li>
	<li><strong>메트릭:</strong> 고정된 시간에 수집된 숫자 측정값입니다. 이것은 "전자 상거래 사이트를 통한 판매는 지난 10분 동안 $50,000이었습니다", 또는 "CPU 사용률은 14:00:00에서 14:00:10까지 17%였습니다.”가 될 수 있습니다.</li>
</ul>
<h2>Kubernetes 클러스터에서의 앱 배포</h2>
<p>여기서는 Apache HTTP Server, PHP 및 Redis를 기반으로 해서 이 애플리케이션을 사용하겠습니다.
</p>
<p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltb6c40127948a43cc/5c305565760e7f7a666d690f/k8s-module-1.png" data-sys-asset-uid="bltb6c40127948a43cc" alt="k8s-module-1.png">
</p>
<p>또한 애플리케이션 및 컨테이너 인프라를 모니터링하기 위해 다음 사항이 제공됩니다.&nbsp;
</p>
<ul>
	<li>Elastic Cloud에 호스팅된 Elasticsearch 서비스 배포.</li>
	<li><span></span>Beats는 동일한 Kubernetes 클러스터에서 DaemonSet으로 배포된 로그 및 메트릭을 위한 경량 수집기입니다. 이는 일반적으로 Kubernetes 클러스터에 배포된 fluentd를 대체할 수 있다는 것에 유의하십시오.</li>
</ul>
<h2>로그 및 메트릭</h2>
<p>상기 애플리케이션은 캡처해야 하는 유용한 정보를 지속적으로 생성하는 생태계의 한 부분일 뿐입니다. 다음은 로그 및 메트릭이 수집되는 레벨입니다.
</p>
<ol>
	<li>오케스트레이션(Kubernetes)</li>
	<li><span></span>호스트</li>
	<li>애플리케이션</li>
	<li>컨테이너(Docker)</li>
</ol>
<p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltd3029c1072fc382e/5c57e478bc5d07ed0b48c928/k8s-module-2.png" data-sys-asset-uid="bltd3029c1072fc382e" alt="k8s-module-2.png">
</p>
<p>데이터를 수집하기 위해 <a href="/kr/products/beats">Beats</a>(Filebeat, Metricbeat 및 Packetbeat) 그리고 System, Kubernetes 및 Docker 모듈을 애플리케이션용 모듈(Apache 및 Redis)과 함께 사용합니다. 각 Beat에<a href="https://kubernetes.io/docs/concepts/workloads/controllers/daemonset/">DaemonSet</a>를 배치하고 Kubernetes가 이들을 관리하게 했습니다. 목록이 장황하게 들릴지도 모르지만, 걱정하지 마세요. Beats의 자동 검색 기능으로 간단하게 유지될 수 있습니다. 애플리케이션을 모니터링하기 위한 Beat 배포에 대한 자세한 내용은&nbsp;<a href="/kr/blog/monitoring-an-application-running-in-docker-containers-and-kubernetes-with-the-elastic-stack">이 블로그</a> 및 함께 제공되는 비디오에 있습니다. 사실, 처음부터 보고 싶으시면 Elastic의 <a href="/kr/docker-kubernetes-container-monitoring">컨테이너 모니터링 페이지</a>를 확인하십시오.<span></span>
</p>
<p>색인 생성, 저장, 검색, 분석 및 데이터 시각화를 위해 <a href="/kr/cloud/elasticsearch-service/signup">호스팅된 Elasticsearch</a>를 사용했습니다. Elasticsearch 서비스를 Elastic Cloud에 배포하는 방법은 Elasticsearch 및 Kibana를 여러분 자신이 관리하는 시스템에 배포하는 것과 마찬가지로 <a href="/kr/start">시작 페이지에서 자세히 설명</a>되어 있습니다. 어느 방식을 선택하든, 잘 작동합니다.
</p>
<p>Beats와 모듈에 대해 언급했는데 이에 대해 설명을 좀 더 해 드리겠습니다. Beat는 Elasticsearch 또는 Logstash로 데이터를 보내는 경량 에이전트입니다. Beats는 어떤 경우에는 실제 또는 가상 시스템에서와 같이 데이터가 시작한 곳에 배포되고 어떤 경우에는 소스와 함께 배포됩니다(예 : DaemonSet). 모듈은 공통 로그 형식의 수집, 구문 분석, 색인 및 시각화를 단순화합니다.
</p>
<p>이는 조금 지루하게 들릴 수도 있지만 다음과 같은 방식으로 설명해 보겠습니다. Elastic 모듈은 사전 패키지 처리된 환경입니다. 여러분이 Apache HTTPD Server 관리에 대해서는 아주 잘 알고 있지만 NGINX는 알지 못한다고 가정해 보겠습니다. NGINX를 아는 사람에게 가서 "로그에서 무엇을 찾으십니까? 어떤 메트릭을 관측하고 계십니까? 내 기록 파일에서 grep을 줄 수 있겠습니까?"라고 질문할 수 있습니다. 이러한 질문에 대한 답이 Beat 모듈을 정의하는 것입니다. 바로 Kubernetes, Docker, NGINX, Apache, 운영 체제, 데이터베이스 등과 같이 수 많은 것들을 위한 사전 패키지된 대시보드, 저장된 검색, 구문 분석 및 수집입니다. 제 경험상 이것은 매우 강력한 기능의 집합입니다.
</p>
<p><a href="/guide/en/beats/metricbeat/current/metricbeat-module-kubernetes.html">k8s 모듈</a>은 pod, 노드, 볼륨, ReplicaSets, 배포 등과 관련된 메트릭을 수집합니다. 각 메트릭에는 풍부한 메타데이터 세트가 첨부되어 있어 데이터를 앱에 연결할 수 있습니다. 예를 들어, pod <em>xyz</em>가 메모리 사용 한도에 근접하는지에 대해 관심이 없다고 생각할 수도 있지만, 해당 메트릭이 앱의 프론트엔드와 연결되어 있는 것으로 나타나면 비즈니스에 대한 가치를 알 수 있습니다. 이것은 또한 아래 비디오의 성능 차트를 보강하기 위해 사용할 이벤트를 수집합니다(위의 로그 정의에 Kubernetes 이벤트를 포함시킨 것을 기억하세요).
</p>
<p><a href="/guide/en/beats/metricbeat/current/metricbeat-module-docker.html">Docker 모듈</a>은 컨테이너, 호스트, 메모리, 네트워크, 상태 확인 등에 관련된 메트릭을 수집합니다. Kubernetes 모듈과 마찬가지로 메타데이터는 앱 및 환경의 성능을 이해하는 데 매우 중요합니다.
</p>
<p><a href="/guide/en/beats/filebeat/current/filebeat-modules.html">Filebeat</a> 및 <a href="/guide/en/beats/metricbeat/current/metricbeat-modules.html">Metricbeat</a>에 대한 다른 많은 모듈들이 있습니다. 또한 <a href="/guide/en/beats/packetbeat/current/visualizing-data-packetbeat.html">Packetbeat</a>에는 Cassandra, Flows, HTTP, MySQL, MongoDB 등과 같은 서비스를 위한 많은 대시 보드가 함께 제공됩니다.
</p>
<p>데이터를 실용적인 인텔리전스로 전환하는 것이 얼마나 쉬운지 보십시오. 비디오 기능:
</p>
<ul>
	<li>앱 성능 메트릭으로 Kubernetes 이벤트 시각화
	</li>
	<li>Metricbeat Kubernetes 모듈 이벤트 메트릭 세트 자세히 알아보기
	</li>
	<li>Kubernetes 이벤트 탐색 및 사용자 지정 시각화 구축</li>
</ul>
<div class="video embed-container" style="height: 319.725px;">
	<img style="width: 100%; margin: auto; display: block;" class="vidyard-player-embed" src="https://play.vidyard.com/FMHRF7JA2JhmPqpTNm4edp.jpg" data-uuid="FMHRF7JA2JhmPqpTNm4edp" data-v="4" data-type="inline">
</div>

Mashup-dashboards.jpg

MetricBeatDocker-Dash.png

Monitoring Kubernetes and Docker Containers with Beats: Logs, Metrics, and Metadata

Beats로 Kubernetes와 Docker 컨테이너 모니터링하기: 로그, 메트릭 및 메타데이터

컨테이너화 애플리케이션은 동적이며 Elastic Stack 또한 그렇습니다. Beats는 앱, Docker 및 Kubernetes의 로그와 매트릭스를 자동 탐색, 수집하며 변화에 따라 조정됩니다.

<p>Rolling updates, 효율성, 복원성, 일관성 등을 위해 <a href="/docker-kubernetes-container-monitoring">컨테이너에서 앱을 실행합니다</a>. 모니터링 시스템은 같은 특성을 가져야 하며 적합도는 더 나아야 합니다.&nbsp; 컨테이너화 및 오케스트레이션에 익숙한 경우, <a href="#different">그렇다면 무엇이 다릅니까?</a> 섹션으로 건너 뛰십시오. 거기서 컨테이너화된 애플리케이션 모니터링의 세부 사항에 대해 이야기할 것입니다.
</p><h2>Docker 컨테이너</h2><blockquote>Docker 컨테이너 이미지는 경량이며 독립적이고 그것을 실행하는데 필요한 모든 것, 즉 코드, 런타임, 시스템, 툴, 시스템 라이브러리, 설정을 포함하는 실행 가능한 소프트웨어 패키지입니다. 컨테이너는 예컨대 개발과 대기 환경 간의 차이처럼 그 환경으로부터 소프트웨어를 분리하며 같은 인프라 상에서 다른 소프트웨어를 실행하는 팀 간의 갈등을 줄이는데 유용합니다.
</blockquote><p>출처: <a href="http://www.docker.com/what-container" target="_blank">www.docker.com/what-container</a>
</p><h2>Kubernetes 또는 k8s</h2><blockquote>Kubernetes는 컨테이너화된 애플리케이션의 배치, 확장 및 관리를 자동화하기 위한 오픈소스 시스템입니다.&nbsp; 그것은 용이한 관리와 탐색을 위해 애플리케이션을 구성하는 컨테이너를 논리적 단위로 분류합니다. Kubernetes는 커뮤니티의 동급 최강의 아이디어와 관행과 결합하여 구글에서 프로덕션 워크로드를 실행한 15년의 경험을 바탕으로 구축합니다.&nbsp;
</blockquote><p><a name="different">출처: </a><a href="http://kubernetes.io" target="_blank">kubernetes.io</a>
</p><p>K8s는 <a href="https://en.wikipedia.org/wiki/Numeronym" target="_blank">숫자 기반의 응용어</a> (Numeronym) 입니다.
</p><h2>무엇이 다릅니까?</h2><p>위의 정의가 말하지 않은 점은 컨테이너에서 로그와 매트릭스를 가져와 배치를 모니터링하고 확장하는 것이 조금 다르다는 점이며 이는 더 어려운 것은 아니고 그냥 다를 뿐입니다.&nbsp; 모니터링 시스템은 동적이 되도록 제작되어야 합니다. 배치가 확장되면서 모니터링 시스템은 자동으로 변동 사항을 탐지하고 그에 따라 조정되어야 합니다.&nbsp; 모니터링 시스템 관리에 대한 부담을 관리자에게 지울 수 없습니다.&nbsp; 이 글에서 표면적으로만 다룬 후 향후의 블로그에서 심층적으로 짚어보겠습니다. 그 때 각 Elastic 모듈의 세부 사항을 자세히 다루겠습니다.&nbsp; 하단의 동영상에서 현실적인 예시를 보실 수 있습니다.
</p><h2>모니터링</h2><p>모니터링은 과부하된 용어입니다.&nbsp; 이 논의에서 모니터링은 애플리케이션이나 서비스 및 그것을 좌우하는 환경을 수집, 파싱, 저장, 시각화 및 대행하는 것입니다.&nbsp; Kubernetes 및 Docker에서 Apache와 Redis를 실행하는 경우, 그 때 (모니터링의 정의를 이용해) 다음을 수집해야 합니다:
</p><ul>
	<li>Apache 매트릭스 및 로그
	</li>
	<li>Redis 매트릭스 및 로그
	</li>
	<li>Kubernetes 매트릭스 및 로그
	</li>
	<li>Docker 매트릭스 및 로그
	</li>
	<li>네트워크 매트릭스
	</li>
	<li>반응 시간
	</li>
</ul><p>그 다음 서비스용으로 약간의 시각화를 생성합니다:
</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt973dd15de68e0d89/5c583cc0eab90dd80b53f19c/visualizations.jpg" data-sys-asset-uid="blt973dd15de68e0d89" alt="visualizations.jpg">
</p><p>그리고 마지막으로 상황이 안 좋아질 때 PagerDuty 또는 Slack으로 일부 자동화된 경고를 생성합니다:
</p><p><img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltbcaf2f0014edd6dd/5c583cc5a2b68bd90b9ff0c3/SlackAlert.png" data-sys-asset-uid="bltbcaf2f0014edd6dd" alt="SlackAlert.png">
</p><h2>간단한 것은 간단해야 합니다</h2><p>Elastic Stack (Elasticsearch, Kibana, Beats 및 Logstash)은 상기의 모든 것을 빠르고 쉽게 시행할 수 있는 기능을 제공합니다.&nbsp; Elastic 모듈은 공통 로그 포맷을 위해 수집, 파싱, 색인 템플릿, 시각화 등을 포함합니다. 로그 파일이 운영체제의 기본 위치에 있는 경우 로그 파일이 어디에 있는지 알 필요가 없습니다. 이 동영상에서는 컨테이너 환경에서 가용한 풍부한 메타데이터를 이용해 귀하의 앱과 Docker / Kubernetes를 더욱 쉽게 관리하는 방법을 살펴볼 것입니다.&nbsp; 앞으로 보게 될 동영상의 모든 파일과 README는 <a href="https://github.com/elastic/examples/tree/master/MonitoringKubernetes" target="_blank">GitHub</a> 에 있습니다. Kubernetes 튜토리얼(환상적임)은 <a href="https://kubernetes.io/docs/tutorials/stateless-application/guestbook/" target="_blank">Kubernetes Docs</a> 에 있습니다.&nbsp; 이 예시에서는 IBM 클라우드 컨테이너 서비스의 앱을 배치하고 그 다음 Elastic Beats와 Hosted <a href="https://www.elastic.co/cloud/elasticsearch-service?elektra=home&storm=sub1" target="_blank">Elasticsearch Service</a> 를 이용하여 우리의 앱에 대한 정보를 자동 탐색, 수집, 파싱, 색인, 검색 및 시각화할 것입니다. 동영상에서 다루는 주제입니다:
</p><ul>
	<li>컨테이너 앱 모니터링이 다른 이유
	</li>
	<li>Rolling update 진행 방법
	</li>
	<li>아웃오브더박스 Elastic모듈 대시보드
	</li>
	<li>Docker 메타데이터가 Beats 자동 탐색을 구동하는 방법
	</li>
	<li>Kubernetes 예시 PHP 게스트북 배치
	</li>
	<li>Beats (Elasticsearch로 데이터를 탐색, 파싱, 강화, 전송하는 로그 및 매트릭스 전송자) 배치</li>
</ul><div class="video embed-container" style="height: 319.725px;">
	<img style="width: 100%; margin: auto; display: block;" class="vidyard-player-embed" src="https://play.vidyard.com/tdSAdqPixZbTkfnMt7NZik.jpg" data-uuid="tdSAdqPixZbTkfnMt7NZik" data-v="4" data-type="inline">
</div><p><span style="background-color: initial;">향후의 블로그에서는 배치에 대한 세부 사항, 각 Elastic모듈이 목표에 도달하기 위해 무엇을 제공하며 아웃오브더박스 경험 이상으로 확장하기 위한 방법(경고를 Slack에 전송하는 것 같은)을 다루겠습니다. 동영상을 시청하시는 동안 특정 Docker컨테이너에서 특정 로그를 수집하기 위해 우리가 Beats를 어떻게 구성했는지 궁금하시면 <a href="https://www.elastic.co/guide/en/beats/filebeat/current/configuration-autodiscover.html" target="_blank">autodiscover</a> 에서 읽어보십시오. 시간이 많이 절약될 것입니다.</span>
</p>

Monitoring an application running in Docker containers and Kubernetes with the Elastic Stack

Elastic Stack으로 Docker 컨테이너와 Kubernetes에서 실행되는 애플리케이션 모니터링하기

Start free trial

Blog Footer CTA

Sign up for Elastic Cloud free trial

Customer Success Manager

Dan Roscigno

<p>By submitting you acknowledge that you've read and agree to our <a href="/legal/elastic-cloud-account-terms" target="_self">Terms of Service</a>, and you agree to receive the <a href="/legal/privacy-statement#how-we-use-the-information" target="_self">selected communications</a> at the contact details you provided above. See <a href="/legal/privacy-statement/" target="_self">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.</p>

Communication Preferences - ONLY for /communication-preferences

<p>제출하면 귀하가 <a href="/kr/legal/elastic-cloud-account-terms" target="_self">Elastic 서비스 약관</a>을 읽고 이에 동의하며, 위에 제공된 연락처로 <a href="/kr/legal/privacy-statement#how-we-use-the-information" target="_self">선택한 커뮤니케이션</a>을 수신하는 데 동의한 것으로 간주됩니다. 언제든지 수신을 거부할 수 있으며 자세한 내용은 <a href="/kr/legal/privacy-statement/" target="_self">Elastic 개인정보 취급방침</a>을 참조하시기 바랍니다.</p>

<p>By submitting you acknowledge that you've read and agree to our <a href="/legal/serverless-preview-terms" target="_blank">Terms of Service</a>, and that Elastic may <a href="/legal/privacy-statement#how-we-use-the-information" target="_blank">contact you</a> about our related products and services, using the details you provide above. See <a href="/legal/privacy-statement/" target="_blank">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.</p>

Serverless GDPR Text

<p>제출하면 귀하가 Elastic <a href="/kr/legal/serverless-preview-terms" target="_self">서비스 약관</a>을 읽고 이에 동의하며, 위에 제공된 세부 정보를 사용하여 Elastic이 관련 제품 및 서비스에 대해 귀하에게 <a href="/kr/legal/privacy-statement#how-we-use-the-information" target="_self">연락할 수 있음</a>을 이해한 것으로 간주됩니다. 언제든지 수신을 거부할 수 있으며 자세한 내용은 <a href="/kr/legal/privacy-statement/" target="_self">Elastic 개인정보 취급방침</a>을 참조하시기 바랍니다.</p>

<p>By submitting you agree to <a href="/agreements/global/cloud-services-monthly" rel="nofollow">Elastic Cloud Terms of Service</a>. Your personal data will be processed in accordance with <a href="/legal/privacy-statement">Elastic's Privacy Statement</a>.</p>

Cloud Trial GDPR Text

<p>제출하면 <a href="/kr/agreements/global/cloud-services-monthly" rel="nofollow">Elastic Cloud 서비스 약관</a>에 동의하시게 됩니다. 개인 데이터는 <a href="/kr/legal/privacy-statement">Elastic의 개인정보 취급방침</a>에 따라 처리됩니다.</p>

<p>By submitting you acknowledge that you've read and agree to our <a href="/legal/terms-of-use" target="_blank">Terms of Service</a>, and that Elastic may <a href="/legal/privacy-statement#how-we-use-the-information" target="_blank">contact you</a> about our related products and services, using the details you provide above. See <a href="/legal/privacy-statement/" target="_blank">Elastic’s Privacy Statement</a> for more details or to opt-out at any time.</p>

Newsletter GDPR Text

<p>제출하면 귀하가 Elastic <a href="/kr/legal/terms-of-use" target="_self">서비스 약관</a>을 읽고 이에 동의하며, 위에 제공된 세부 정보를 사용하여 Elastic이 관련 제품 및 서비스에 대해 귀하에게 <a href="/kr/legal/privacy-statement#how-we-use-the-information" target="_self">연락할 수 있음</a>을 이해한 것으로 간주됩니다. 언제든지 수신을 거부할 수 있으며 자세한 내용은 <a href="/kr/legal/privacy-statement/" target="_self">Elastic 개인정보 취급방침</a>을 참조하시기 바랍니다.</p>

Explore similar demos

Overview

Speakers

Close

See more insights

The content on this page is not available in the selected language. As Elastic grows globally, we continue to support content in multiple languages.

The content on this page is not available in the selected language.

이 페이지의 콘텐츠는 선택하신 언어로 제공되지 않습니다. Elastic은 다양한 언어로 콘텐츠를 제공하기 위해 최선을 다하고 있습니다.조금만 더 기다려주세요!

Author

Articles by

Learn more

Watch now (no PT)

Watch now

See all top stories

All (no PT translation)

Contact information

Press Release

Share on Reddit

Share this story

Share by Email

Thank you for your interest!

Contact Info

Follow us on Youtube

Load More

Share on LinkedIn

Follow us on LinkedIn

Search Integrations

All Solutions

Video for

Follow us on Twitter

See when this webinar starts in my time zone

내 표준 시간대로 웨비나 시작 시간 확인하기

Register to Watch

Register now

See All Posts

Can't make it? Register and we'll send you the recording. You'll also receive an email with related content

참여가 어려우신가요? 등록하시면 녹화 자료를 보내드리겠습니다. 이메일로 관련 콘텐츠도 받아보실 수 있습니다.

Small image for

On-demand webinar

Featured webinar

Register to Attend

Share on Facebook

Reset all

Upcoming webinar

View more posts

Print

Hosted by

Sign In to Attend

View next

Follow us on Facebook

Share

Highlights

Read less

You'll also receive an email with related content

이메일을 통해 관련 내용을 보내드리겠습니다.

Thank you for registering. We will send you a confirmation email soon.

등록해 주셔서 감사합니다. 곧 확인 이메일을 보내드리겠습니다.

Author

Articles by Dan Roscigno

Customer Success Manager, Elastic

Elasticsearch Observability: 메트릭에 대한 Prometheus 및 OpenMetrics 표준 수용

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

Beats로 Kubernetes와 Docker 컨테이너 모니터링하기: 로그, 메트릭 및 메타데이터

Elastic Stack으로 Docker 컨테이너와 Kubernetes에서 실행되는 애플리케이션 모니터링하기