Elastic Stack 7.2에서는 Observability가 훨씬 쉬워집니다. APM 에이전트별 메트릭, 새로운 인프라 Metrics Explorer 등과 같은 개선 사항에 대해 알아보세요.

운영자가 애플리케이션과 서비스의 가용성과 양호한 상태, 빠른 속도를 유지하도록 하기 위해 제공되는 도구를 개선하려는 우리의 끝없는 열의를 사용자와 함께 나누게 되어 정말 기쁩니다. 이러한 목적을 “Observability”&nbsp;라고 부르시든 아니든 계속 읽어보세요!

Elastic APM은 요청이 많았던 .NET 에이전트를 베타로 릴리즈함으로써 .NET에 대한 지원을 추가합니다. 인프라 모니터링 측면에서는, Metrics Explorer를 추가했습니다. 이것은 Kibana의 Infrastructure 앱에서 제공되는 새로운 조회 기능으로, 임시로 인프라 메트릭과 상호 작용하는 방식을 개선하기 위해 설계되었습니다. 마지막으로, 7.2에서는 CoreDNS와 CRI-O 같은 클라우드 네이티브 기술을 위한 몇 가지 새로운 데이터 통합을 출시함으로써 Kubernetes 모니터링 도구를 계속해서 넓혀가고 있습니다.

기다리기 싫으시면, 버전 7.2가 <a href="/kr/cloud/elasticsearch-service">Elasticsearch Service</a>에서 지금 제공되고 있으니 확인해 보세요. 이 새로운 기능들은 호스트형 Elasticsearch 제품인 Elasticsearch Service 에서&nbsp;이용하실 수 있습니다. 또는 <a href="/kr/downloads">Elastic Stack 최신 버전을 다운로드</a>하여 실행하셔도 됩니다.

<h2>Observability에 대한 Elastic의 접근 방법</h2>
“Observability”이라는 용어는 시스템, 서비스, 애플리케이션의 상태에 대한 통합적인 가시성을 강조하는 철학을 말해줍니다. 업계에서는 비교적 새로운 용어이지만, 수많은 사용자와 팀들이 운영상의 필요를 위해 Elastic Stack을 찾게 되는 주요 이유를 효과적으로 포착하고 있습니다. 모든 것이 인덱스로 저장되는&nbsp;Elasticsearch의 유연한 성격 덕분에, 사용자는 일반적으로 별개의 데이터 소스였던 로그, 메트릭, 추적, 가동 시간 메트릭 등을 단일한 운영 저장소로 성공적으로 한데 모을 수 있습니다.


	<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt6082737bba8cc593/5d0416aa0b20e952523c959c/elastic-observability-devops.png" data-sys-asset-uid="blt6082737bba8cc593" alt="사용자의 모든 인프라 로그, 메트릭, 가동 시간 데이터, APM 추적을 Elastic Stack으로 모두 통합" data-image="wvo4blfyqzu1" style="display: block; margin: auto;">

우리는 Observability 영역에서 이중 전략을 채택했습니다. Observability의 각 ‘기둥’에 대해 계속해서 동급 최강의 환경을 제공하면서 동시에 사용자가 좀더 자연스럽고 유동적으로 이러한 데이터 스트림들을 한데 모으는 방법을 지원하는 것입니다. 모든 Observability 데이터는 Elastic Common Schema(ECS)를 고수하며, 모든 Kibana 애플리케이션은 통합되어 클릭 한 번으로 탐색과 데이터 상관 관계 워크플로우를 제공합니다.

<img data-image="vav8bcqlcf3y" src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt368c68953bf815de/5d0a9a65877575d0584775e5/elastic-observability-containers.gif" data-sys-asset-uid="blt368c68953bf815de" alt=" Elastic Stack 내에서 실행되는 Observability 작업" "="">

독보적인 안전화 제조업체인 Red Wing Shoes는 Elastic Cloud의 호스트형 <a href="/kr/products/elasticsearch/service">Elasticsearch Service</a>를 이용해 공장 작업 현장의 제조 공정, 전자 상거래 웹사이트의 상태, 전 세계 600여 개 소매 매장의 운영을 통합적으로 살펴볼 수 있게 되었습니다. 운영을 담당하는 팀은 사업 성장을 목적으로 하는 새 애플리케이션과 서비스 배포도 주도하고 있습니다. Marc Kermisch 부사장 겸 최고정보책임자는 “ IT 운영을 효율적으로 만드는 데 중점을 두고 있기 때문에 유대가 긴밀한 팀을 통해 이 작업을 할 수 있다”며, “모든 관련 운영 데이터를 단일 데이터 저장소와 UI 인터페이스에서 볼 수 있어서 조치가 가능한 데이터를 기반으로 훨씬 효과적으로 문제를 심사하고 해결할 수 있습니다. Elastic Cloud에서 우리 대신 스택을 전체적으로 관리해준다는 사실은 우리의 관리 오버헤드가 낮다는 뜻입니다. Elastic Stack에 대한 모든 배포, 확장, 업그레이드가 버튼 클릭 한 번으로 가능합니다.”라고 말했습니다.

<a href="/kr/blog/observability-with-the-elastic-stack">Elastic Stack을 이용한 Observability</a> 블로그에서 이 중요한 추세와 관련해 우리가 진행하고 있는 작업에 대해 더 자세히 읽어보세요.

7.2에서는 다음과 같은 제품 개선으로 Observability 계획을 계속해서 더 넓고 깊게 확장시키고 있습니다.

<h2>Elastic APM의&nbsp;.NET&nbsp;지원, 단일 페이지 애플리케이션, 에이전트별 메트릭 추가</h2>
.NET을 위한 Elastic APM 에이전트를 <a href="/kr/blog/elastic-apm-dot-net-agent-preview-released">프리뷰</a>에서 베타 버전으로 전환시키게 된다는 기쁜 소식을 알려드립니다. .NET 에이전트는 ASP.NET Core 2.x+ 및 Entity Framework Core 2.x+를 위한 자동 <a href="/guide/en/apm/agent/dotnet/current/index.html">계측</a>을 추가하며, 아울러 사용자가 다른 프레임워크를 사용하고 있는 모든 .NET 애플리케이션을 수동으로 계측할 수 있는 <a href="/guide/en/apm/agent/dotnet/current/public-api.html">퍼블릭 에이전트 API</a>도 제공합니다.

.NET 지원은 Elastic APM에 대해 가장 요청이 많았던 기능 중 하나였으며, 지원되는 언어들을 종합적으로 완성하게 되어 무척 기대가 됩니다. 언어 지원에서 우선 순위를 정할 수 있도록 <a href="https://docs.google.com/forms/d/e/1FAIpQLSfBjUbv9qjcwNFSXpjJT_PmGJn0kpuF1IdZDtnBl0MLNRbYbQ/viewform">설문조사</a>를 작성해주시고, 미리 보기 버전에 대해 피드백을 제공해주신 우리 커뮤니티의 모든 회원들께 감사드립니다.

Elastic APM의 RUM(Real User Monitoring) 에이전트는 단일 페이지 애플리케이션(SPA)을 위한 지원을 확대하여 사용자가 페이지 로드 트랜잭션에 더하여 경로 변경 트랜잭션을 캡처할 수 있게 해줍니다. SPA는 사용자가 페이지를 탐색할 때 데이터 요소를 동적으로 렌더링 함으로써 더 간소화된 사용자 환경과 더 빠른 로드 타임 등 다중&nbsp;페이지 애플리케이션(MPA)보다 장점이 더 많습니다. 전송의 동적인 성격은 내부 애플리케이션 경로 변경 분석과 같은 최종 사용자 환경을 측정하는 데 있어 훨씬 더 미묘한 접근 방식을 필요로 합니다.

끝으로, APM 에이전트는 APM 추적 데이터와 관련 있는 전반적인 리소스 활용과 같은 일반 핵심 성능 지표뿐 아니라 이제 언어별 메트릭도 수집합니다. 예를 들어, Java 에이전트는 이제 Java 힙 메모리 및 스레드 수와 같은 JVM 메트릭을 수집합니다. 이것은 또한 APM 앱에서 자동으로 표시됩니다. 이러한 에이전트별 메트릭의 추가는 개발자가 추가 에이전트를 설치할 필요 없이 애플리케이션의 동작에 대한 추가적인 컨텍스트를 제공함으로써 훨씬 더 풍부한 모니터링 환경을 만들어줍니다.

<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt5151674c453e2ec8/5d01990fc06daee314d200a4/elastic-observability-metrics.jpg" data-sys-asset-uid="blt5151674c453e2ec8" alt="언어별 메트릭" "="">

<a href="/kr/blog/elastic-apm-7-2-0-released">Elastic APM 릴리즈 블로그</a>에서 APM의 더 많은 장점에 대해 읽어보세요.

<h2>Metrics Explorer를 통한 인프라 메트릭 탐색 개선</h2>
메트릭에 대한 지원 확장은 지난 몇 년 동안 Elastic Stack 엔지니어링 팀이 끊임없이 집중해 온 작업이었습니다. 숫자 데이터에 최적화된 Bkd 트리 같은 새로운 데이터 형식을 통한 저장 공간 효율성 개선, 새로운 Metricbeat 모듈을 통한 메트릭 데이터 세트 통합 확장, Time Series Visual Builder 같은 전용 Kiaban 앱으로 시계열 시각화 역량 개선 등은 이 영역에 대한 우리의 지속적인 노력을 보여주는 몇 가지 예일 뿐입니다.

우리 사용자들은 무척 행복해했습니다. 7.2에서는 Elastic Infrastructure 앱에 Metrics Explorer을 도입함으로써 임시 메트릭 탐색을 더욱 개선해나가고 있습니다. 이 사용자 인터페이스는 사용자가 가장 중요한 인프라 메트릭을 탐색하고 일반 태그와 차트 그룹화를 이용해 이 메트릭과 상호작용할 수 있게 해줍니다. 각 Metrics Explorer 차트를 Time Series Visual Builder에서 열어 추가적으로 조사를 할 수 있으며, 모든 Elasticsearch 집계의 강력한 성능을 클릭 한 번으로 간편한 메트릭 탐색과 결합시킵니다. 이 모든 탐색은 태그,&nbsp;카디널리티의 크기에도&nbsp;불구하고 순식간에 이루어집니다.

<img data-image="ah8ondecltp5" src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltaa9753682c89f6e9/5d0a9a485fe8e2af5a55ae2e/elastic-observability-metrics-explorer.gif" data-sys-asset-uid="bltaa9753682c89f6e9" alt="Kibana 7.2의 Metrics Explorer" "="">

Metrics Explorer는 현재 베타 버전입니다. <a href="https://discuss.elastic.co/c/infrastructure">포럼(Discuss)</a>에 피드백을 남겨주시기 바랍니다!&nbsp;<a href="/kr/blog/elastic-infrastructure-7-2-0-released">Elastic Infrastructure 릴리즈 블로그</a>에서 다른 개선 사항에 대해 읽어보세요.

<h2>Elastic에서 Kubernetes Observability 강화</h2>
Kubernetes 생태계는 수많은 회사의 오픈 소스 혁신에 힘입어 급속히 진화하고 있습니다. 새 프로젝트들이 매달 CNCF 생태계에 추가되며, 놀라운 속도로 졸업 단계(Graduated)에 이릅니다.

Elastic은 이러한 동적 기술 스택을 모니터링하기 위한 필요성을 포함해 Kubernetes에서 마이그레이션하는 팀을 지원하기 위해 노력하고 있습니다. 예를 들어, Filebeat와 Metricbeat의 자동 검색 같은 기능과 <a href="/kr/blog/elasticsearch-observability-embracing-prometheus-and-openmetrics-standards-for-metrics">Prometheus</a> 같은 클라우드 네이티브 기술을 위한 모듈은 Kubernetes 인프라와 거기서 실행되는 서비스 양쪽 모두를 모니터링하는 턴키 방식을 제공합니다.

7.2는 클라우드 네이티브 기술을 위한 몇 가지 새로운 통합의 출시와 함께 이러한 노력을 기반으로 구축됩니다. Filebeat와 Metricbeat는 최근에 CNCF에서 졸업 단계가 된 Kubernetes용 기본 클러스터 DNS인 CoreDNS에 대한 지원을 도입합니다. 아울러 커뮤니티 회원들과의 긴밀한 협력을 통해 오픈 소스 클라우드 네이티브 메시징 시스템인 <a href="/kr/blog/monitoring-nats-messaging-system-with-elastic-beats">NATS 메시징 시스템에 대한 지원</a>도 확장하고 있습니다.

끝으로, Filebeat 7.2는 Kubernetes용 오픈 컨테이너 런타임 계획인 CRI-O에 대한 지원을 추가합니다. RedHat이 개발한 이 경량의 대체 Docker는 인기있는 Openshift 배포에서 이미 기본 컨테이너 런타임입니다. CRI-O 모듈은 모니터링 요건을 희생하지 않고 Kubernetes 사용자가 CRI-O를 컨테이너 런타임으로 전환하게 해줍니다.

<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltb62e24736c6384d5/5d019984ea19705f1784b04f/elastic-observability-kubernetes.jpg" data-sys-asset-uid="bltb62e24736c6384d5" alt="Elastic Stack을 이용한 Kubernetes Observability" "="">

<a href="/kr/blog/elastic-infrastructure-7-2-0-released">Elastic Infrastructure</a> 및 <a href="/kr/blog/elastic-logs-7-2-0-released">Elastic Logs</a> 릴리즈 블로그에서 Kubernetes 데이터 통합의 장점에 대해 더 자세히 읽어보세요.

<h2>잠깐만요...아직 더 있습니다!</h2>
활성 및 가용성&nbsp;모니터링에 대한 턴키 환경을 제공하기 위해 최근에 도입된 Elastic Uptime에는 이제 클릭 한 번으로 Elastic Logs, Infrastructure, APM 앱과의 통합이 포함됩니다. 이 통합은 활성 모니터링을 훨씬 더 쉽게 사용자의 로그 분석 및 Observability 워크플로우로 통합할 수 있게 해줍니다. <a href="/kr/blog/elastic-uptime-monitoring-7-2-0-released">Elastic Uptime 릴리즈 블로그</a>에서 이 내용과 기타 개선 사항에 대해 더 자세히 읽어보세요.

로그 데이터를 이용한 작업을 간소화하기 위해 6.5에서 도입된 Elastic Logs는 명시적인 열 통합을 통해 구조화 로그 및 이벤트에 대한 지원을 추가했습니다. 또한 “필드&nbsp;필터링” 기능을 도입하여, 많은 로깅 사용자가 조사에서 신뢰하는 중요한 “근접&nbsp;로그 조회” 워크플로우가 가능하게 해줍니다. <a href="/kr/blog/elastic-logs-7-2-0-released">Elastic Logs 릴리즈 블로그</a>에서 이 내용과 다른 새 기능에 대해 더 자세히 읽어보세요.

<h2>직접 체험해 보세요</h2>
최신 기능을 사용해 보는 가장 쉬운 방법은 Elastic Cloud에서 <a href="/kr/cloud/elasticsearch-service">Elasticsearch Service</a>&nbsp;클러스터를 실행하는 것입니다. 릴리즈 당일에 Elastic Cloud의 Elasticsearch Service에서 Elastic Stack의 최신 버전이 제공되도록 하고 있습니다. 원하시면, 계속 사용하세요. 우리가 실행, 확장 및 축소, 클러스터 업그레이드를 모두 관리해 드립니다. 직접 실행하는 편을 선호하시면, 바이너리 다운로드, Docker 컨테이너 실행, Kubernetes에서 Elastic Stack 배포 등과 같은 <a href="/kr/downloads">자체 관리&nbsp;옵션</a>에 대해 알아보실 수 있습니다.

blog-generic-teal-banner.png

elastic-observability-7-2-0-thumb.jpg

Observability updates: .NET in APM, Kubernetes monitoring, Metrics Explorer

Elastic Stack 7.2 Observability 업데이트: .NET APM, Kubernetes 모니터링, Metrics Explorer

스키마에 미리 별도의 작업을 하면 검색과 분석이 한결 빨라집니다. 재료 손질과 준비에 시간을 좀더 들이면 음식 맛이 훨씬 좋아지는 것과 비슷합니다.

schema-banner.jpg

schema-read-write-thumb.jpg

Schema on write vs. schema on read

쓰기 스키마(Schema on write)와 읽기 스키마(Schema on read) 비교

로그, 메트릭, 추적을 서로 관련시켜야 합니까? 문제 없습니다. Elastic Stack을 사용하여 가관측성의 3가지 기둥 관리가 얼마나 간단하게 이뤄질 수 있는지 알아보십시오.

Elastic에서 가관측성을 담당하는제품 책임자로서 저는 '가관측성'이라는 용어를 사용할 때 몇 가지 다른 반응을 접합니다. 오늘날까지 가장 일반적인 반응은 다음과 같습니다. "’가관측성’이 뭔가요?" 하지만 이런 말을 듣는 경우도 늘었습니다. "최근에 '가관측성 이니셔티브'를 시작했지만, 여전히 정확히 어떻게 해야 하는지 고민하고 있습니다." 그리고 마침내, 다행히도 함께 일할 수 있었던 몇몇 단체들은 이미 '가관측성'을 제품과 서비스를 디자인하는 방식의 필수적인 부분으로 여깁니다.

이 용어가 여전히 인기를 끌고 있다는 점을 감안할 때, Elastic 뷰의 '가관측성'에서, 아이디어를 선도하는 여러 고객으로부터 무엇을 배웠는지, 그리고 운영 사용 사례에 대한 스택을 진화시키면서 제품 관점에서 이를 어떻게 생각하는지를 이해하게 설명하는 것이 유용할 것이라고 생각했습니다.

<h2>'가관측성'이란 무엇입니까?</h2>
분명, '가관측성'이라는 단어를 우리가 만들어낸 것은 아닙니다. 우리는 주로 SRE(Site Reliability Engineering) 커뮤니티 내의 여러 사용자로부터 이에 대해 알게 되었습니다. 이 용어의 여러 출처는 <a href="https://blog.twitter.com/engineering/en_us/a/2013/observability-at-twitter.html">Twitter</a>와 같은 실리콘 밸리 대기업에서 SRE 조직으로 거슬러 올라갑니다. 그리고 큰 영향을 미치는 <a href="https://landing.google.com/sre/books/">Google SRE Book</a>에서는 이 용어를 언급하지는 않지만, 오늘날 '가관측성'과 관련된 많은 원칙을 제시하고 있습니다.

'가관측성'은 업체가 상자에 담아 제공하는 것이 아니라, 사용자가 구축하는 시스템의 속성이며, 사용성, 고가용성 및 안정성과 유사합니다. '관측 가능한' 시스템을 설계하고 구축하는 목적은 운영자가 운영 환경에서 실행할 때 바람직하지 않은 동작(예: 서비스 중단, 오류, 느린 응답)을 탐지하고 근본 원인을 효과적으로 파악할 수 있도록 하는 것입니다(예: 상세 이벤트 로그, 세분화된 리소스 사용 정보 및 애플리케이션 추적). 조직이 이러한 명백한 목표를 달성하지 못하게 하는 일반적인 문제에는 충분한 정보를 수집하지 않는 것, 너무 많은 정보를 수집하지만 실행 가능하도록 하지 않는 것, 이 정보에 대한 액세스를 세분화하는 것이 포함됩니다.

첫 번째 측면인 바람직하지 않은 동작 감지는 대개 <a href="https://landing.google.com/sre/sre-book/chapters/service-level-objectives/">SLI(Service Level Indicators) 및 SLO(Objectives) 설정으로 시작합니다.</a> 이것은 생산 시스템이 가관측성을 고려하는 조직에서 평가되는 성공의 내부 척도입니다. 이러한 목적을 이행해야 하는 계약상의 의무가 있는 경우, SLI/SLO는 SLA(서비스 수준 계약)로도 해석될 수 있습니다. SLI의 가장 일반적인 예는 시스템 가동 시간이며, 이 경우 SLO를 99.9999%로 설정할 수 있습니다. 시스템 가동 시간은 외부 고객에게 가장 많이 노출되는 SLA이기도 합니다. 그러나 SLI/SLO는 내부적으로 훨씬 더 세분화될 수 있으며, 이러한 가장 중요한 생산 시스템 동작에 대한 모니터링 및 알림은 가관측성 이니셔티브라면 기본입니다. 이러한 가관측성의 측면은 ‘모니터링’이라는 용어로도 알려져 있습니다.

두 번째 측면은 운영자에게 생산 문제를 신속하고 효율적으로 디버그할 수 있는 세분화된 정보를 제공하는 것입니다. 이 영역에서는 많은 움직임과 혁신을 볼 수 있습니다. ‘가관측성의 3가지 기둥’ 즉, 메트릭, 로그 및 애플리케이션 추적에 대해 꽤 많은 논의가 이루어지고 있습니다. 또한 패치워크 도구를 사용하여 이러한 모든 세분화된 데이터를 수집하는 것이 꼭 실행 가능하지는 않으며 많은 경우 비용 효율적이지도 않다는 점도 알려져 있습니다.&nbsp;

<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltf85be52d51892228/5c98d45f8e3cc6505f19f678/three-pillars-of-observability-logs-metrics-tracs-apm.png" data-sys-asset-uid="bltf85be52d51892228" alt="three-pillars-of-observability-logs-metrics-tracs-apm.png" "="" width="446" height="194" style="width: 446px; height: 194px; display: block; margin: auto;">

<h2>가관측성의 '기둥'</h2>
이러한 데이터 수집 측면을 좀 더 자세히 살펴보겠습니다. 오늘날 일반적으로 발생하는 현상으로는 메트릭을 하나의 시스템(보통 리소스 모니터링을 위한 시계열 데이터베이스 또는 SaaS 서비스)으로 수집하고, 로그를 두 번째 시스템(예상되듯이, 대화에 ELK 스택이 많음)으로 수집하며, 세 번째 도구를 사용하여 애플리케이션에서 요청 수준 추적을 제공하는 것입니다. 알림이 발생할 때 서비스 수준의 위반이 나타나면, 운영자는 자신의 시스템으로 달려 들어가 할 수 있는 최선의 ‘회전 의자 통합’(swivel chair integration)을 수행합니다. 즉, 하나의 브라우저 창에서 메트릭을 검토하고, 이를 다른 창에서 수동으로 로그에 연결시키고, 세 번째 창에서(해당하는 경우) 그 흔적을 추적합니다.

이러한 접근법에는 몇 가지 단점이 있습니다. 첫째, 서로 다른 데이터 소스를 수동으로 연결시키는 것은 모두 동일한 사례를 통해 서비스 저하 또는 운영 중단 시 귀중한 시간을 낭비하게 합니다. 둘째, 3개의 서로 다른 운영 데이터 저장소를 유지 관리하는 데 드는 운영 비용이 상당한 부담이 됩니다. 라이선스 비용, 각각의 운영 도구를 담당하는 별도의 관리자 인원, 각 데이터 저장소의 일관되지 않은 머신 러닝 기능, 경고를 위해 서로 다른 의미 체계를 고려해야 하는 ‘헤드스페이스’ 등이 이에 해당됩니다. 제가 이야기를 나눈 모든 기업이 이러한 문제로 어려움을 겪고 있습니다.

이 모든 정보를 단일 운영 저장소에 저장하고 직관적인 사용자 인터페이스에서 이러한 데이터를 자동으로 상호 연관시킬 수 있는 기능을 갖추는 것이 얼마나 중요한지에 대한 인식이 높아지고 있습니다. 우리가 이야기를 나눈 사용자들은 애플리케이션에서 내보낸 로그 줄, 계측 도구에서 생성된 추적 데이터, 시계열 메트릭으로 표시된 리소스 사용률 등 지원하고 있는 서비스와 관련된 데이터의 모든 요소를 운영자가 통합된 방식으로 볼 수 있기를 원합니다. 우리에게 쏟아지는 요청 사항은 검색 및 필터링부터 집계, 시각화에 이르기까지 소스와 관계없이 이러한 데이터에 대한 일관된 임의 액세스를 강조하고 있습니다. 메트릭으로 시작하여 컨텍스트를 전환하지 않고 클릭 몇 번으로 로그 및 추적으로 드릴다운할 수 있다면 조사를 가속화할 수 있습니다. 마찬가지로, 정형 로그에서 숫자 값을 추출하는 것은 메트릭과 놀라운 정도로 비슷하며, 이 둘을 나란히 시각화하는 것은 운영 측면에서 엄청난 가치를 제공합니다.

앞서 언급한 바와 같이 단순한 데이터 수집은 디스크에 너무 많은 정보가 쌓이는 결과를 가져오며 문제 발생 시 실행 가능한 인텔리전스는 정작 부족한 상황이 됩니다. 운영 데이터를 수집하는 시스템이 시계열 패턴에서 ‘관심 있는’ 이벤트, 추적 및 이상 징후를 자동 탐지하는 기능을 제공할 것이라는 기대가 점점 더 커지고 있습니다. 이는 문제를 조사하는 운영자가 근본 원인을 신속하게 파악하는 데 도움이 됩니다. 이러한 이상 징후 탐색 기능을 ‘가관측성의 4번째 기둥’이라고 부르기도 합니다. 가동 시간 데이터, 리소스 사용률 및 로깅 패턴에서 이상 징후를 탐지하고 가장 관련성이 높은 추적을 탐지하는 기능이 가관측성 팀에서 제시하는 새로운 요구 사항입니다.

<h2>가관측성...그리고 ELK Stack?</h2>
그렇다면 가관측성은 Elastic Stack(또는 운영 분야에서 부르는 애칭인 <a href="/kr/elk-stack">ELK Stack</a>)과 어떤 관계가 있을까요?

ELS Stack은 운영 시스템의 로그를 중앙 집중화하는 실질적인 방법으로 널리 알려져 있습니다. 이는 Elasticsearch가 자유 텍스트 검색을 위해 텍스트 기반 로그를 저장하기에 좋은 시스템이라는 가정을 기반으로 합니다. 그리고 실제로, 간단하게 ‘오류’라는 단어로 텍스트 기반 로그를 검색하거나 잘 알려진 태그 세트를 기반으로 로그를 필터링할 수 있다는 것은 매우 강력한 기능이며 대부분 사용자가 처음 시작할 때 사용하는 기능이기도 합니다.

그러나 대부분의 ELS Stack 사용자가 알고 있듯이 데이터 저장소로서의 Elasticsearch는 효율적인 전체 텍스트 검색 및 간단한 필터링 기능을 위한 역색인 그 이상의 기능을 제공합니다. 또한, Elasticsearch에는 고밀도 숫자 시계열을 저장 및 운영하는 데 최적화된 열 기반 저장소가 포함되어 있습니다. 이 열 기반 저장소는 구문 분석된 로그에서 추출된 정형 데이터(스트링과 숫자 모두)를 저장하는 데 사용됩니다. 사실, 우리가 숫자의 효율적인 저장 및 검색을 위해 Elasticsearch를 최적화하도록 동기를 부여한 것이 로그를 메트릭으로 변환하는 사용 사례입니다.

시간이 지나면서 사용자들은 <a href="/kr/solutions/metrics">숫자 시계열</a>을 기존 시계열 데이터베이스 대신 Elasticsearch에 직접 저장하기 시작했습니다. 이러한 요구에 부응하여 Elastic에서는 최근에 데이터 저장소와 UI에서 메트릭 자동 수집, 자동 롤업 개념, 기타 메트릭별 기능을 제공하는 <a href="/guide/en/beats/metricbeat/6.6/metricbeat-modules.html">Metricbeat</a>를 출시했습니다. 그 결과, 로그용으로 ELS Stack을 도입한 사용자 중에서 리소스 사용률과 같은 메트릭 데이터를 Elastic Stack에 저장하는 <a href="/kr/webinars/ns1-leveraging-elasticsearch-as-a-time-series-database">사용자가 점점 더 증가</a>하고 있습니다. 위에 이미 언급한 운영 비용 절감 외에도, Elasticsearch가 숫자 집계가 가능한 필드의 카디널리티에 제약(기존 시계열 데이터베이스를 논의할 때 흔히 제기되는 불만)을 많이 두지 않는다는 것이 사용이 증가한 매력적인 이유의 하나입니다.

메트릭과 마찬가지로, <a href="/kr/products/beats/heartbeat">가동 시간 데이터</a>는 로그와 더불어 매우 중요한 데이터 유형으로, 활성 모니터에서 SLO/SLI 경고의 중요한 소스를 나타냅니다. 가동 시간 데이터는 종종 사용자가 그 영향을 느끼기 전에 서비스, API 및 웹 사이트의 성능 저하에 대한 정보를 제공할 수 있습니다. 그뿐만 아니라 가동 시간 데이터는 스토리지 요구 사항 측면에서 용량이 미미하기 때문에 아주 약간의 비용 추가로 상당한 가치를 확보할 수 있습니다.

또한, Elastic은 작년에 <a href="/kr/solutions/apm">Elastic APM</a>을 출시하여 스택에 애플리케이션 추적 및 분산 추적 기능을 추가했습니다. 여러 오픈 소스 프로젝트와 주요 APN 공급업체에서 이미 Elasticsearch를 사용하여 추적 데이터를 저장 및 검색하고 있었기 때문에 이는 우리에게 당연한 결과였습니다. APN 추적 데이터를 로그 및 메트릭과 별도로 유지하여 운영 데이터 사일로를 지속시키는 것이 기존 APM 도구의 현재 상태입니다. Elastic APM은 지원되는 언어 및 프레임워크에서 추적 데이터를 수집하고 OpenTracing을 지원하는 일련의 에이전트를 제공하며, 이러한 추적 데이터를 자동으로 메트릭 및 로그와 상호 연관시킵니다.

<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/blt248065423cca3f6c/5c98d436fc9053fa5ecd78e3/Screen_Shot_2019-02-28_at_6.58.21_AM.png" data-sys-asset-uid="blt248065423cca3f6c" alt="Screen Shot 2019-02-28 at 6.58.21 AM.png">

<img src="https://images.contentstack.io/v3/assets/bltefdd0b53724fa2ce/bltc5c9236cde8b37b8/5c98d43b146c873d59750036/Screen_Shot_2019-02-28_at_6.47.51_AM.png" data-sys-asset-uid="bltc5c9236cde8b37b8" alt="Screen Shot 2019-02-28 at 6.47.51 AM.png">

이러한 모든 데이터 입력 전체에서 공통 스레드는 각각이 Elasticsearch의 또 다른 인덱스라는 것입니다. 이러한 데이터에서 실행되는 집계, Kibana에서 이를 시각화하는 방법, 경고와 머신 러닝이 각 데이터 소스에 적용되는 방법에는 어떠한 제약도 없습니다. 실제 작동하는 모습을 보려면 <a href="https://www.youtube.com/watch?v=d6h5gpACD4o&feature=youtu.be">이 동영상을 확인하십시오</a>.

<div style="height: 478px; margin-bottom: 20px;">
	<iframe width="100%" height="478" src="//www.youtube.com/embed/d6h5gpACD4o?rel=0" class="video-iframe" frameborder="0" allowfullscreen="">
	</iframe>
</div>
<h2>관측 가능한 Kubernetes 및 Elastic Stack</h2>
가관측성 개념이 매우 활발하게 논의되는 커뮤니티 중 하나가 컨테이너 오케스트레이션을 위해 Kubernetes를 도입한 사용자 그룹입니다. <a href="https://www.cncf.io/">CNCF(Cloud Native Computing Foundation)</a>에 의해 대중화된 용어인 ‘클라우드 네이티브’ 사용자는 고유한 문제에 직면해 있습니다. 즉, 모놀리식 앱을 ‘마이크로서비스’로 분리하는 추세와 더불어 Kubernetes 기반 컨테이너 오케스트레이션 플랫폼에 구축되거나 마이그레이션된 애플리케이션 및 서비스의 대규모 중앙 집중화에 직면해 있습니다. 지금까지 이러한 인프라에서 실행되는 애플리케이션에 대해 필요한 가시성을 제공해주던 도구와 방법이 더는 그 성능을 발휘하지 못합니다.

Kubernetes 가관측성은 그 자체로 별도의 게시물에서 다뤄야 하므로 지금은 <a href="/kr/webinars/observable-kubernetes-with-the-elastic-stack">관측 가능한 Kubernetes 웨비나</a>와 <a href="/kr/blog/distributed-tracing-opentracing-and-elastic-apm">Elastic APM을 사용한 분산 추적 블로그 게시물</a>에서추가 정보를 확인하십시오.

<h2>이제 그다음은?</h2>
이런 게시물에서는 독자에게 살펴볼 수 있는 리소스를 몇 가지 남겨두는 것이 적절할 것 같네요.

가관측성 모범 사레에 대해 자세히 알아보려면 위에 언급한 <a href="https://landing.google.com/sre/books/">Google SRE Book</a>으로 시작하는 것이 좋습니다. 중요한 앱을 프로덕션에서 원활하게 운영하는 것이 생존을 좌우하는 기업의 블로그 게시물 또한 시사하는 바가 큽니다. 예를 들어 <a href="https://engineering.salesforce.com/what-is-observability-d175eb6cd2e4">Salesforce</a> Engineering의 이 최근 게시물은 가관측성 상태를 반복적으로 개선하는 데 도움이 되는 실용적이고 실질적인 안내서라고 생각합니다.

가관측성 이니셔티브를 위해 Elastic Stack 기능을 사용해 보려면 <a href="https://cloud.elastic.co/">Elastic Cloud</a> 샌드박스(궁극적으로 자가 관리형을 배포하는 경우에도 매우 훌륭한 샌드박스)의 <a href="/kr/cloud/elasticsearch-service">Elasticsearch Service</a>에서 최신 버전의 스택을 구동하거나, Elastic Stack 구성 요소를 로컬에 <a href="/kr/downloads">다운로드</a>하여 <a href="/kr/start">설치</a>하십시오. 일반적인 가관측성 워크플로우에 맞춰 특별히 구축된 Kibana의 새로운 로그, 인프라 모니터링, APM 및 가동 시간(6.7에서 제공 예정) UI를 확인하시기 바랍니다. 그리고 질문이 있으시면 언제든 <a href="https://discuss.elastic.co/">토론 포럼</a>에 글을 남겨주십시오. 저희가 도와드리겠습니다!

observablt-banner.jpg

three-pillars-of-observability-logs-metrics-tracs-apm-banner.jpg

Observability with the Elastic Stack

Elastic Stack을 통한 가관측성

Kibana는 Elasticsearch에 저장된 데이터를 검색하고 시각화할 수 있는 강력한 방법을 제공합니다. 시각화를 위해, Kibana는 Elasticsearch 매핑에서 정의된 필드를 찾아 차트를 작성하는 사용자에게 옵션으로 제시합니다. 그러나 중요한 값을 스키마에서 별도 필드로 정의하는 것을 잊으면 어떻게 될까요? 아니면 두 필드를 결합하여 하나로 처리하고 싶다면 어떨까요? 여기서 Kibana 스크립트 필드가 중요한 역할을 하기 시작합니다. 스크립트 필드는 실제로 Kibana 4의 초기부터 존재했습니다. 스크립트 필드가 도입되었을 때, 스크립트 필드를 정의하는 유일한 방법은 숫자 값만을 다루는 Elasticsearch의 스크립팅 언어인 <a href="https://www.elastic.co/guide/en/elasticsearch/reference/5.0/modules-scripting-expression.html" target="_self">Lucene Expressions</a>&nbsp;에 의존했습니다. 따라서 스크립트 필드의 기능은 사용 사례의 하위 집합으로 제한되었습니다. 5.0에서는, Elasticsearch에 다양한 데이터 유형에서 작동할 수 있는 안전하고 강력한 스크립트 언어인 <a href="https://www.elastic.co/guide/en/elasticsearch/reference/5.0/modules-scripting-painless.html" target="_self">Painless</a>를 도입했으며, 그 결과 Kibana 5.0의 스크립트 필드가 훨씬 더 강력해졌습니다. 이 블로그의 나머지 부분에서는, 일반적인 사용 사례를 위한 스크립트 필드를 만드는 방법에 대해 설명합니다. <a href="https://www.elastic.co/guide/en/kibana/5.0/tutorial-load-dataset.html" target="_self">Kibana 시작하기 튜토리얼</a>&nbsp;의 데이터 세트를 기반으로 설명해 드리고, 무료로 스핀업하실 수 있는 <a href="https://cloud.elastic.co/" target="_self">Elastic Cloud</a>에서 실행되는 Elasticsearch와 Kibana 인스턴스를 사용해 보겠습니다. 다음 동영상에서는 Elastic Cloud에서 개인 Elasticsearch와 Kibana&nbsp;인스턴스를 스핀업하고 샘플&nbsp;데이터 세트&nbsp;를 로드하는 방법에 대해 설명합니다.&nbsp; <div class="video embed-container" style="height: 319.725px;"><img class="vidyard-player-embed" src="https://play.vidyard.com/6gWkzXXhT69tUa7uRtvJ96.jpg" data-uuid="6gWkzXXhT69tUa7uRtvJ96" data-v="4" data-type="inline" width="677"/></div><h2>스크립트 필드의 작동 방식</h2>Elasticsearch를 통해 모든 요청에 대한 스크립트 필드를 지정할 수 있습니다. Kibana는 관리 섹션에서 스크립트 필드를 한 번 정의할 수 있도록 함으로써 이를 개선하며, 따라서 향후에 UI의 여러 위치에서 이를 사용할 수 있습니다. Kibana는 스크립트 필드를 다른 구성과 함께 .kibana 인덱스에 저장하지만, 이 구성은 Kibana별이며 Kibana 스크립트 필드는 Elasticsearch의 API 사용자에게 노출되지 않습니다. Kibana에서 스크립트 필드를 정의하려면, 스크립트 언어를 선택하게 되며, Elasticsearch 노드에 설치된 동적 스크립트가 활성화된 모든 언어 중에서 선택할 수 있습니다. 기본값은 5.0에서는 "표현식" 및 "Painless"이고 2.x에서는 "표현식"입니다. 다른 스크립팅 언어를 설치하고 이 언어에 대해 동적 스크립팅을 활성화할 수는 있지만, 충분히 <a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-scripting-security.html" target="_self">샌드박스화</a>&nbsp;할 수 없고 사용이 중단되었기 때문에 권장되지 않습니다. 스크립트 필드는 한 번에 하나의 Elasticsearch 문서에서 작동하지만, 해당 문서의 여러 필드를 참조할 수 있습니다. 따라서 스크립트 필드를 사용하여 단일 문서 내에서 필드를 결합하거나 변환하는 것은 적절하지만, 여러 문서를 기반으로 한 계산(예: 시계열 수학)은 수행하지 않도록 합니다. Painless 및 Lucene 표현식 양쪽 모두 <a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/doc-values.html" target="_self">doc_values</a>에 저장된 필드에서 작동합니다.&nbsp;따라서 스트링 데이터의 경우, 데이터 유형 키워드에 저장할 스트링이 있어야 합니다. Painless 기반의 스크립트 필드도 _source에서 직접 작동할 수 없습니다. 스크립트 필드가 "관리"에서 정의되면, 사용자는 Kibana의 다른 필드와 동일한 방식으로 필드와 상호 작용할 수 있습니다. 스크립트 필드는 검색(Discover) 필드 목록에 자동으로 표시되며 시각화 생성 목적으로 시각화(Visualize)에서 제공됩니다. Kibana는 평가를 위해 쿼리 시 스크립트 필드 정의를 Elasticsearch에 전달합니다. 결과 데이터 세트는 Elasticsearch에서 반환되는 다른 결과와 결합되어 사용자에게 표 또는 차트로 표시됩니다. 이 블로그 작성 시점을 기준으로, 스크립트 필드로 작업할 때 몇 가지 알려진 제한 사항이 있습니다. Kibana 비주얼 빌더에서 사용할 수 있는 대부분의 Elasticsearch 집계를 스크립트 필드에 적용할 수 있습니다. 단, 가장 눈에 띄는 예외는 <a href="https://www.elastic.co/guide/en/elasticsearch/reference/current/search-aggregations-bucket-significantterms-aggregation.html" target="_self">중요 용어 집계</a>입니다. 아래와 같이, 잘 정의된 값을 반환하는 적절한 스크립트를 작성하려면 주의해야 하지만 검색, 시각화 및 대시보드의 필터 표시줄을 통해 스크립트 필드를 필터링할 수도 있습니다. 스크립트 필드를 사용할 때는 아래의 "모범 사례" 섹션을 참조하여 환경을 불안정하게 만들지 않도록 하는 것도 중요합니다. 다음 동영상에서는 Kibana를 사용하여 스크립트 필드를 만드는 방법을&nbsp;보여 드립니다. <div class="video embed-container" style="height: 319.725px;"><img class="vidyard-player-embed" src="https://play.vidyard.com/SKHYsZcKZHq9u7GTNGWPaL.jpg" data-uuid="SKHYsZcKZHq9u7GTNGWPaL" data-v="4" data-type="inline" width="677"/></div><h2>스크립트 필드 예제</h2>이 섹션에서는 일반적인 시나리오에서 Kibana의 Lucene 표현식 및 Painless 스크립트 필드의 몇 가지 예제를 보여 드립니다. 위에서 언급한 바와 같이, 이러한 예제는 <a href="https://www.elastic.co/guide/en/kibana/5.0/tutorial-load-dataset.html" target="_self">Kibana 시작하기 튜토리얼</a>&nbsp;의 데이터 세트를 바탕으로 개발되었으며 이전 버전의 특정 유형의 스크립트 필드 필터링 및 정렬과 관련된 몇 가지 알려진 문제가 있으므로 Elasticsearch 및 Kibana 5.1.1을 사용하고 있다고 가정합니다. Elasticsearch 5.0에서는 Lucene 표현식 및 Painless를 기본적으로 사용할 수 있으므로 스크립트 필드는 대부분 즉시 사용할 수 있습니다. 필드의 정규식 기반 구문 분석이 필요한 스크립트만 예외입니다. 이 경우, elasticsearch.yml에서 다음 설정을 설정하여 Painless: script.painless.regex.enabled: true에 대한 정규식 일치를 켜야 합니다<h3>단일 필드에 대해 계산 수행</h3><ul><li>예제: 바이트에서 킬로바이트 계산</li><li>언어:&nbsp;표현식</li><li>반환 유형:&nbsp;숫자</li></ul><pre class="prettyprint"> doc['bytes'].value / 1024 </pre>참고: Kibana 스크립트 필드는 한 번에 하나의 문서에서만 작동하므로 스크립트 필드에서 시계열 수학을 수행할 수 없습니다. <h3>날짜를 숫자로 반환</h3><ul><li>예제:&nbsp;날짜를 시간으로 구문 분석</li><li>언어: 표현식</li><li>반환 유형:&nbsp;숫자</li></ul>Lucene 표현식은 즉시 사용할 수 있는 전체 호스트의 <a href="https://www.elastic.co/guide/en/elasticsearch/reference/5.0/modules-scripting-expression.html#_date_field_api" target="_self">날짜 조작 함수</a>&nbsp;를 제공합니다. 그러나 Lucene 표현식은 숫자 값만 반환하므로, 스트링 기반 요일을 반환하려면 Painless를 사용해야 합니다(아래). <pre class="prettyprint"> doc['@timestamp'].date.hourOfDay </pre>참고: 위 스크립트는 1-24를 반환합니다 <pre class="prettyprint">doc['@timestamp'].date.dayOfWeek </pre>참고: 위 스크립트는 1-7을 반환합니다 <h3>두 스트링 값 결합</h3><ul><li>예제:&nbsp;소스와 대상 또는 이름과 성을 결합</li><li>언어:&nbsp;painless</li><li>반환 유형:&nbsp;스트링</li></ul><pre class="prettyprint"> doc['geo.dest.keyword'].value + ':' + doc['geo.src.keyword'].value </pre> 참고: 스크립트 필드는 doc_values의 필드에서 작동해야 하므로 위 스트링의 .keyword 버전을 사용하고 있습니다. <h3>논리 도입</h3><ul><li>예제: 바이트 수가 10000을 초과하는 문서에 대한 "빅 다운로드" 레이블 반환</li><li>언어: painless</li><li>반환 유형: 스트링</li></ul><pre class="prettyprint"> if (doc['bytes'].value > 10000) { return "big download"; } return ""; </pre>참고: 논리를 도입할 때는, 모든 실행 경로에 잘 정의된 반환 문과 잘 정의된 반환 값(null이 아님)이 있어야 합니다. 예를 들어, 위의 스크립트 필드는 마지막에&nbsp;반환 문이 없는&nbsp; Kibana 필터에서 사용되거나 문이 null을 반환하는 경우 컴파일 오류와 함께 실패합니다. 또한 Kibana 스크립트 필드 내에서는 논리를 함수로 분할할 수 없습니다.&nbsp; <h3 dir="ltr">하위 스트링 반환 </h3><ul><li>예제: URL의 마지막 슬래시 뒤에 오는 부분 반환</li><li>언어: painless</li><li>반환 유형: 스트링</li></ul><pre class="prettyprint"> def path = doc['url.keyword'].value; if (path != null) { int lastSlashIndex = path.lastIndexOf('/'); if (lastSlashIndex > 0) { return path.substring(lastSlashIndex+1); } } return ""; </pre>참고: indexOf() 작업은 리소스 집약적이지 않고 오류 발생 가능성이 낮으므로 가능한 한 정규식을 사용하여 하위 스트링을 추출하지 마세요.&nbsp; <h3 dir="ltr">정규식을 사용하여 스트링 일치 및 일치 작업 수행 </h3><ul><li>예제: 하위 스트링 "error"가 "referer" 필드에 있으면 "error" 스트링을 반환하고, 그렇지 않으면 "no error" 스트링을 반환합니다.</li><li>언어: painless</li><li>반환 유형: 스트링</li></ul><pre class="prettyprint">if (doc['referer.keyword'].value =~ /kr/error/) { return "error" } else { return "no error" } </pre>참고: 단순화된 정규식 구문은 정규식 일치를 기반으로 하는 조건에 유용합니다.&nbsp; <h3 dir="ltr">스트링 일치 및 일치하는 스트링 반환 </h3><ul><li>예제: "host" 필드의 마지막 점 뒤에 오는 스트링인 도메인 반환</li><li>언어: painless</li><li>반환 유형: 스트링</li></ul><pre class="prettyprint">def m = /^.*\.([a-z]+)$/.matcher(doc['host.keyword'].value); if ( m.matches() ) { return m.group(1) } else { return "no match" } </pre>참고: regex matcher() 함수를 통해 개체를 정의하면 정규식과 일치하는 문자 그룹을 추출하여 반환할 수 있습니다.&nbsp; <h3 dir="ltr">숫자 일치 및 일치하는 숫자 반환 </h3><ul><li>예제: IP 주소의 첫 번째 옥텟을 반환하고(스트링으로 저장) 이를 숫자로 처리</li><li>언어: painless</li><li>반환 유형: 숫자</li></ul><pre class="prettyprint"> def m = /^([0-9]+)\..*$/.matcher(doc['clientip.keyword'].value); if ( m.matches() ) { return Integer.parseInt(m.group(1)) } else { return 0 } </pre>참고: 스크립트에서 올바른 데이터 유형을 반환하는 것이 중요합니다. 정규식 일치는 숫자가 일치하더라도 스트링을 반환하므로, 반환 시 이를 정수로 명시적으로 변환해야 합니다.&nbsp; <h3 dir="ltr">날짜를 스트링으로 반환 </h3><ul><li>예제: 날짜를 요일 스트링으로 구문 분석</li><li>언어: painless</li><li>반환 유형: 스트링</li></ul><pre class="prettyprint">LocalDateTime.ofInstant(Instant.ofEpochMilli(doc['@timestamp'].value), ZoneId.of('Z')).getDayOfWeek().getDisplayName(TextStyle.FULL, Locale.getDefault()) </pre>참고: Painless는 Java의 모든 네이티브 유형을 지원하므로, <a href="https://docs.oracle.com/javase/8/docs/api/java/time/LocalDateTime.html#getDayOfWeek--" target="_self">LocalDateTime()</a>과 같은 해당 유형의 네이티브 함수에 대한 액세스를 제공합니다. 따라서 더 복잡한 날짜 계산을 수행하는 데 유용합니다. <h2 dir="ltr">모범 사례 </h2>보시는 것과 같이, Painless 스크립트 언어는 Kibana 스크립트 필드를 통해 Elasticsearch에 저장된 임의 필드에서 유용한 정보를 추출하는 강력한 방법을 제공합니다. 하지만, 큰 힘에는 큰 책임이 따릅니다.&nbsp; 아래에서는 Kibana 스크립트 필드 사용과 관련된 몇 가지 모범 사례를 개략적으로 설명합니다. <ul><li>스크립트 필드를 실험하려면 항상 개발 환경을 사용하세요. 스크립트 필드는 Kibana의 관리 섹션에 저장한 후 즉시 활성화되므로(예: 모든 사용자의 해당 인덱스 패턴에 대한 검색 화면에 표시됨), 프로덕션에서 직접 스크립트 필드를 개발해서는 안 됩니다. 먼저 개발 환경에서 구문을 시도하고, 스크립트 필드가 스테이징의 실제 데이터 세트 및 데이터 볼륨에 미치는 영향을 평가한 후 프로덕션으로 승격하는 것이 좋습니다.&nbsp;</li><li>스크립트 필드가 사용자에게 가치를 제공한다는 확신을 갖게 되면, 새 데이터 색인 시에 필드를 추출하도록 수집을 수정합니다. 이렇게 하면 쿼리 시에 Elasticsearch 처리가 절약되고 Kibana 사용자를 위한 응답 시간이 단축됩니다. Elasticsearch에서 <a href="https://www.elastic.co/guide/en/elasticsearch/reference/5.0/docs-reindex.html" target="_self">_reindex</a> API를 사용하여 기존 데이터를 다시 색인할 수도 있습니다.</li></ul>

blog-banner-generic-elastic.png

Using Painless in Kibana scripted fields

Kibana 스크립트 필드에서 Painless 사용

Start free trial

Blog Footer CTA

Sign up for Elastic Cloud free trial

headshot-tanya-bragin-300x300.jpg

VP Product Management, Observability

Tanya Bragin

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.

Communication Preferences - ONLY for /communication-preferences

제출하면 귀하가 <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>을 참조하시기 바랍니다.

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.

Serverless GDPR Text

제출하면 귀하가 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>을 참조하시기 바랍니다.

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>.

Cloud Trial GDPR Text

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

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.

Newsletter GDPR Text

제출하면 귀하가 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>을 참조하시기 바랍니다.

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 Tanya Bragin

VP Product Management, Observability, Elastic

Elastic Stack 7.2 Observability 업데이트: .NET APM, Kubernetes 모니터링, Metrics Explorer

쓰기 스키마(Schema on write)와 읽기 스키마(Schema on read) 비교

Elastic Stack을 통한 가관측성

Kibana 스크립트 필드에서 Painless 사용