웹사이트 검색

일반적인 ELK 스택 문제를 해결하는 방법


소개

이 튜토리얼은 ELK Stack(Elasticsearch, Logstash, Kibana) 문제 해결 가이드입니다. Ubuntu 14.04 자습서에 Elasticsearch, Logstash 및 Kibana(ELK 스택)를 설치하는 방법을 따랐다고 가정하지만 다른 일반 ELK 설정 문제를 해결하는 데 유용할 수 있습니다.

이 자습서는 ELK 스택의 다양한 구성 요소가 제대로 작동하는지 확인하는 데 도움이 되는 단계와 함께 일련의 일반적인 문제와 이러한 문제에 대한 잠재적 솔루션으로 구성되어 있습니다. 따라서 발생한 문제와 관련된 섹션으로 자유롭게 이동할 수 있습니다.

문제: Kibana 기본 인덱스 패턴 없음 경고

웹 브라우저를 통해 Kibana에 액세스할 때 다음 경고가 있는 페이지가 표시될 수 있습니다.

Kibana warning:
Warning No default index pattern. You must select or create one to continue. ... Unable to fetch mapping. Do you have indices matching the pattern?

다음은 경고의 스크린샷입니다.

"매핑을 가져올 수 없음\은 Elasticsearch에 기본 logstash-* 패턴과 일치하는 항목이 포함되어 있지 않음을 나타냅니다. 일반적으로 이는 Logstash의 통신 문제로 인해 로그가 Elasticsearch에 저장되지 않음을 의미합니다. Elasticsearch로, 그리고/또는 로그 수집기(예: Filebeat)에서 Logstash로 다시 말해, 어떤 이유로 로그가 Filebeat에서 Logstash로, Elasticsearch로 체인을 통과하지 못합니다.

Logstash와 Elasticsearch 간의 통신 문제를 해결하려면 Filebeat 문제 해결 섹션을 실행하십시오.

기본이 아닌 인덱스 패턴을 사용하도록 Logstash를 구성한 경우 텍스트 상자에 적절한 인덱스 패턴을 지정하여 문제를 해결할 수 있습니다.

문제: Kibana가 Elasticsearch에 연결할 수 없음

웹 브라우저를 통해 Kibana에 액세스할 때 다음 오류가 있는 페이지가 나타날 수 있습니다.

Kibana error:
Fatal Error Kibana: Unable to connect to Elasticsearch Error: Unable to connect to Elasticsearch Error: Bad Gateway ...

다음은 오류의 스크린샷입니다.

이는 Kibana가 Elasticsearch에 연결할 수 없음을 의미합니다. Elasticsearch가 실행되고 있지 않거나 Kibana가 잘못된 호스트 및 포트에서 Elasticsearch를 찾도록 구성되었을 수 있습니다.

이 문제를 해결하려면 Elasticsearch 문제 해결 섹션에 따라 Elasticsearch가 실행 중인지 확인하십시오. 그런 다음 Elasticsearch가 실행 중인 호스트 및 포트에 연결하도록 Kibana가 구성되었는지 확인합니다.

예를 들어 Elasticsearch가 포트 9200localhost에서 실행 중인 경우 Kibana가 적절하게 구성되었는지 확인하세요.

Kibana 구성 파일을 엽니다.

  1. sudo vi /opt/kibana/config/kibana.yml

그런 다음 elasticsearch_url이 제대로 설정되었는지 확인하세요.

/opt/kibana/config/kibana.yml excerpt:
# The Elasticsearch instance to use for all your queries. elasticsearch_url: "http://localhost:9200"

저장 및 종료.

이제 Kibana 서비스를 다시 시작하여 변경 사항을 적용하십시오.

  1. sudo service kibana restart

Kibana가 다시 시작된 후 웹 브라우저에서 Kibana를 열고 오류가 해결되었는지 확인합니다.

문제: Kibana에 액세스할 수 없음

ELK 스택의 Nginx 구성 요소는 Kibana에 대한 리버스 프록시 역할을 합니다. Nginx가 제대로 실행되지 않거나 구성되지 않은 경우 Kibana 인터페이스에 액세스할 수 없습니다. 그러나 나머지 ELK 구성 요소는 Nginx에 의존하지 않으므로 잘 작동할 수 있습니다.

원인: Nginx가 실행되고 있지 않습니다.

Nginx가 실행되고 있지 않고 웹 브라우저에서 ELK 스택에 액세스하려고 하면 다음과 유사한 오류가 표시될 수 있습니다.

Nginx Error:
This webpage is not available ERR_CONNECTION_REFUSED

이것은 일반적으로 Nginx가 실행되고 있지 않음을 나타냅니다.

다음 명령을 사용하여 Nginx 서비스의 상태를 확인할 수 있습니다.

  1. sudo service nginx status

서비스가 실행 중이 아니거나 인식되지 않는다고 보고되면 ELK 스택 자습서의 Nginx 설치 섹션의 지침에 따라 문제를 해결하십시오. 서비스가 실행 중이라고 보고되면 동일한 지침에 따라 Nginx를 재구성해야 합니다.

원인: Nginx가 실행 중이지만 Kibana에 연결할 수 없음

Kibana에 액세스할 수 없고 502 잘못된 게이트웨이 오류가 발생하면 Nginx가 실행 중이지만 Kibana에 연결할 수 없습니다.

이 문제를 해결하기 위한 첫 번째 단계는 다음 명령으로 Kibana가 실행 중인지 확인하는 것입니다.

  1. sudo service kibana status

Kibana가 실행 중이 아니거나 인식되지 않는 경우 ELK 스택 자습서의 Kibana 설치 섹션의 지침을 따르십시오.

그래도 문제가 해결되지 않으면 Nginx 구성에 문제가 있을 수 있습니다. ELK 스택 자습서의 Install Nginx 섹션에서 구성 부분을 검토해야 합니다. Nginx 오류 로그에서 단서를 확인할 수 있습니다.

  1. sudo tail /var/log/nginx/error.log

이것은 Nginx가 Kibana에 연결할 수 없는 이유를 정확히 알려줄 것입니다.

원인: 사용자를 인증할 수 없음

기본 인증이 활성화되어 있고 인증 단계를 통과하는 데 문제가 있는 경우 Nginx 오류 로그를 살펴보고 문제의 세부 사항을 확인해야 합니다.

최근 Nginx 오류를 보려면 다음 명령을 사용하십시오.

  1. sudo tail /var/log/nginx/error.log

사용자를 찾을 수 없음 오류가 표시되면 사용자가 htpasswd 파일에 존재하지 않는 것입니다. 이러한 유형의 오류는 다음 로그 항목으로 표시됩니다.

Nginx error logs (user was not found):
2015/10/26 12:11:57 [error] 3933#0: *242 user "NonExistentUser" was not found in "/etc/nginx/htpasswd.users", client: 108.60.145.130, server: example.com, request: "GET / HTTP/1.1", host: "45.55.252.231"

암호 불일치 오류가 표시되면 사용자가 존재하지만 잘못된 암호를 제공한 것입니다. 이러한 유형의 오류는 다음 로그 항목으로 표시됩니다.

Nginx error logs (user password mismatch):
2015/10/26 12:12:56 [error] 3933#0: *242 user "kibanaadmin": password mismatch, client: 108.60.145.130, server: example.com, request: "GET / HTTP/1.1", host: "45.55.252.231"

이 두 가지 오류에 대한 해결 방법은 적절한 로그인 정보를 제공하거나 존재할 것으로 예상되는 사용자 로그인으로 기존 htpasswd 파일을 수정하는 것입니다. 예를 들어 htpasswd.users 파일에서 kibanaadmin이라는 사용자를 생성하거나 덮어쓰려면 다음 명령을 사용합니다.

  1. sudo htpasswd /etc/nginx/htpasswd.users kibanaadmin

그런 다음 원하는 암호를 입력하고 확인하십시오.

No such file or directory 오류가 표시되면 Nginx 구성에 지정된 htpasswd 파일이 존재하지 않는 것입니다. 이러한 유형의 오류는 다음 로그 항목으로 표시됩니다.

Nginx error logs (htpasswd file does not exist):
2015/10/26 12:17:38 [error] 3933#0: *266 open() "/etc/nginx/htpasswd.users" failed (2: No such file or directory), client: 108.60.145.130, server: example.com, request: "GET / HTTP/1.1", host: "45.55.252.231"

여기서 새 /etc/nginx/htpasswd.users 파일을 생성하고 다음 명령을 사용하여 사용자(이 예에서는 kibanaadmin)를 추가해야 합니다.

sudo htpasswd -c /etc/nginx/htpasswd.users kibanaadmin

새 암호를 입력하고 확인하십시오.

이제 방금 생성한 사용자로 인증을 시도합니다.

Logstash: 실행 중인지 확인하는 방법

Logstash가 실행되고 있지 않으면 Filebeat와 같은 로그 전달자로부터 로그를 수신 및 구문 분석하고 처리된 로그를 Elasticsearch에 저장할 수 없습니다. 이 섹션에서는 Logstash가 정상적으로 작동하는지 확인하는 방법을 보여줍니다.

서비스가 실행 중인지 확인

가장 기본적인 확인 사항은 Logstash 상태입니다.

  1. sudo service logstash status

Logstash가 실행 중인 경우 다음 출력이 표시됩니다.

Logstash status (OK):
logstash is running

그렇지 않고 서비스가 실행되고 있지 않으면 다음 메시지가 표시됩니다.

Logstash status (Bad):
logstash is not running

Logstash가 실행되고 있지 않으면 다음 명령으로 시작해 보십시오.

  1. sudo service logstash start

그런 다음 몇 초 후에 상태를 다시 확인하십시오. Logstash는 Java 애플리케이션이며 모든 시작 시도 후 몇 초 동안 "실행 중\으로 보고하므로 "실행 중 아님\ 상태를 확인하기 전에 몇 초 동안 기다리는 것이 중요합니다. "실행 중이 아님\으로 보고되면 구성이 잘못되었을 수 있습니다. 다음 두 섹션에서는 일반적인 Logstash 문제 해결에 대해 설명합니다.

문제: Logstash가 실행되지 않음

Logstash가 실행되지 않는 경우 몇 가지 잠재적인 원인이 있습니다. 이 섹션에서는 Logstash가 실행되지 않는 다양한 일반적인 경우를 다루고 가능한 솔루션을 제안합니다.

원인: 구성에 구문 오류가 포함되어 있습니다.

Logstash가 /etc/logstash/conf.d 디렉터리에 있는 구성 파일에 오류가 있으면 서비스를 제대로 시작할 수 없습니다. 가장 좋은 방법은 실패 이유에 대한 단서를 Logstash 로그에서 확인하는 것입니다.

서비스를 시작하려고 시도하는 동안 Logstash 로그를 볼 수 있도록 서버에 대한 두 개의 터미널 세션을 엽니다.

첫 번째 터미널 세션에서 로그를 살펴보겠습니다.

  1. tail -f /var/log/logstash/logstash.log

그러면 마지막 몇 개의 로그 항목과 향후 로그 항목이 표시됩니다.

두 번째 터미널 세션에서 Logstash 서비스를 시작해 보십시오.

  1. sudo service logstash start

Logstash가 시작될 때 생성된 로그를 보려면 첫 번째 터미널 세션으로 다시 전환하십시오.

오류 메시지가 포함된 로그 항목이 표시되면 메시지를 읽고 무엇이 잘못되었는지 파악하십시오. 다음은 Logstash 구성에 구문 오류(일치하지 않는 중괄호)가 있는 경우 볼 수 있는 오류 로그의 예입니다.

Logstash logs (Syntax error):
... {:timestamp=>"2015-10-28T11:51:09.205000-0400", :message=>"Error: Expected one of #, => at line 12, column 6 (byte 209) after input {\n lumberjack {\n port => 5043\n type => \"logs\"\n ssl_certificate => \"/etc/pki/tls/certs/logstash-forwarder.crt\"\n ssl_key => \"/etc/pki/tls/private/logstash-forwarder.key\"\n \n}\n\n\nfilter {\n if "} {:timestamp=>"2015-10-28T11:51:09.228000-0400", :message=>"You may be interested in the '--configtest' flag which you can\nuse to validate logstash's configuration before you choose\nto restart a running system."}

구성 유효성 검사에 관심이 있다는 마지막 메시지는 구성에 구문 오류가 있음을 나타냅니다. 이전 메시지는 이 경우 구성의 input 섹션에 누락된 닫는 중괄호가 있다는 보다 구체적인 오류 메시지를 제공합니다. 이 문제를 해결하려면 Logstash 구성의 잘못된 부분을 편집하십시오.

  1. sudo vi /etc/logstash/conf.d/01-lumberjack-input.conf

잘못된 항목이 있는 줄을 찾아서 수정한 다음 저장하고 종료합니다.

이제 두 번째 터미널에서 Logstash 서비스를 시작합니다.

  1. sudo service logstash start

문제가 해결된 경우 새 로그 항목이 없어야 합니다(Logstash는 성공적인 시작을 기록하지 않음). 몇 초 후에 Logstash 서비스의 상태를 확인합니다.

  1. sudo service logstash status

실행 중이면 문제가 해결된 것입니다.

우리의 예와 다른 구성 문제가 있을 수 있습니다. 몇 가지 다른 일반적인 Logstash 구성 문제를 다룰 것입니다. 항상 그렇듯이 오류의 의미를 파악할 수 있으면 직접 수정해 보세요.

원인: SSL 파일이 존재하지 않음

Logstash가 실행되지 않는 또 다른 일반적인 원인은 SSL 인증서 및 키 파일에 문제가 있기 때문입니다. 예를 들어, Logstash 구성이 지정한 위치에 존재하지 않으면 로그에 다음과 같은 오류가 표시됩니다.

Logstash logs (SSL key file does not exist):
{:timestamp=>"2017-12-01T16:51:31.656000+0000", :message=>"Invalid setting for beats input plugin:\n\n input {\n beats {\n # This setting must be a path\n # File does not exist or cannot be opened /etc/pki/tls/certs/logstash-forwarder.crt\n ssl_certificate => \"/etc/pki/tls/certs/logstash-forwarder.crt\"\n ...\n }\n }", :level=>:error} {:timestamp=>"2017-12-01T16:51:31.671000+0000", :message=>"Invalid setting for beats input plugin:\n\n input {\n beats {\n # This setting must be a path\n # File does not exist or cannot be opened /etc/pki/tls/private/logstash-forwarder.key\n ssl_key => \"/etc/pki/tls/private/logstash-forwarder.key\"\n ...\n }\n }", :level=>:error} {:timestamp=>"2017-12-01T16:51:31.685000+0000", :message=>"Error: Something is wrong with your configuration.", :level=>:error}

이 특정 문제를 해결하려면 SSL 키 파일(잊은 경우 생성)이 있고 적절한 위치(/etc/pki/tls/private/logstash)에 있는지 확인해야 합니다. -forwarder.key, 예에서). 키 파일이 이미 있는 경우 적절한 위치로 이동하고 Logstash 구성이 이를 가리키는지 확인하십시오.

이제 Logstash 서비스를 시작합니다.

  1. sudo service logstash start

문제가 해결되었으면 새 로그 항목이 없어야 합니다. 몇 초 후에 Logstash 서비스의 상태를 확인합니다.

  1. sudo service logstash status

실행 중이면 문제가 해결된 것입니다.

문제: Logstash가 실행 중이지만 Elasticsearch에 로그가 저장되지 않음

Logstash가 실행 중이지만 Elasticsearch에 로그를 저장하지 않는 경우 Elasticsearch에 연결할 수 없기 때문입니다. 일반적으로 이는 Elasticsearch가 실행되지 않기 때문입니다. 이 경우 Logstash 로그에 다음과 같은 오류 메시지가 표시됩니다.

Logstash logs (Elasticsearch isn't running):
{:timestamp=>"2017-12-01T16:53:29.571000+0000", :message=>"Connection refused (Connection refused)", :class=>"Manticore::SocketException", :backtrace=>[ruby-backtrace-info-here], :level=>:error}

이 경우 Elasticsearch 문제 해결 단계에 따라 Elasticsearch가 실행 중인지 확인하십시오.

다음과 같은 오류가 표시될 수도 있습니다.

Logstash logs (Logstash is configured to send its output to the wrong host):
{:timestamp=>"2017-12-01T16:56:26.274000+0000", :message=>"Attempted to send a bulk request to Elasticsearch configured at '[\"http://localhost:9200/\"]', but Elasticsearch appears to be unreachable or down!", :error_message=>"Connection refused (Connection refused)", :class=>"Manticore::SocketException", :client_config=>{:hosts=>["http://localhost:9200/"], :ssl=>nil, :transport_options=>{:socket_timeout=>0, :request_timeout=>0, :proxy=>nil, :ssl=>{}}, :transport_class=>Elasticsearch::Transport::Transport::HTTP::Manticore, :logger=>nil, :tracer=>nil, :reload_connections=>false, :retry_on_failure=>false, :reload_on_failure=>false, :randomize_hosts=>false}, :level=>:error} {:timestamp=>"2017-12-01T16:57:49.090000+0000", :message=>"SIGTERM received. Shutting down the pipeline.", :level=>:warn}

이것은 Logstash 구성의 output 섹션이 잘못된 호스트를 가리킬 수 있음을 나타냅니다. 이 문제를 해결하려면 Elasticsearch가 실행 중인지 확인하고 Logstash 구성을 확인하십시오.

  1. sudo vi /etc/logstash/conf.d/30-elasticsearch-output.conf

hosts => [\localhost:9200\] 줄이 Elasticsearch를 실행 중인 호스트를 가리키는지 확인합니다.

Logstash output configuration excerpt
output { elasticsearch { hosts => ["localhost:9200"] sniffing => true . . .

저장 및 종료. 이 예에서는 Elasticsearch가 localhost에서 실행 중이라고 가정합니다.

Logstash 서비스를 다시 시작하십시오.

  1. sudo service logstash restart

그런 다음 오류가 있는지 Logstash 로그를 확인하십시오.

Filebeat: 실행 중인지 확인하는 방법

Filebeat는 클라이언트 시스템에서 실행되며 ELK 서버에 로그를 전달합니다. Filebeat가 실행되고 있지 않으면 다양한 로그를 Logstash로 보낼 수 없습니다. 결과적으로 로그는 Elasticsearch에 저장되지 않고 Kibana에 표시되지 않습니다. 이 섹션에서는 Filebeat가 정상적으로 작동하는지 확인하는 방법을 보여줍니다.

로그가 성공적으로 배송되고 있는지 확인

Filebeat가 Logstash에 로그를 제대로 전달하는지 확인하는 가장 쉬운 방법은 syslog 로그에서 Filebeat 오류를 확인하는 것입니다.

  1. sudo tail /var/log/syslog | grep filebeat

모든 것이 제대로 설정된 경우 Filebeat 프로세스를 중지하거나 시작할 때 일부 로그 항목만 표시되어야 합니다.

로그 항목이 표시되지 않으면 Filebeat가 실행 중인지 확인해야 합니다.

서비스가 실행 중인지 확인

확인해야 할 가장 기본적인 사항은 Filebeat의 상태입니다.

  1. sudo service filebeat status

Filebeat가 실행 중인 경우 다음 출력이 표시됩니다.

Output
* filebeat is running

그렇지 않고 서비스가 실행되고 있지 않으면 다음 메시지가 표시됩니다.

Output
* filebeat is not running

Filebeat가 실행되고 있지 않으면 다음 명령으로 시작해 보십시오.

  1. sudo service filebeat start

그런 다음 상태를 다시 확인하십시오. 그래도 문제가 해결되지 않으면 다음 섹션이 Filebeat 문제를 해결하는 데 도움이 됩니다. 일반적인 Filebeat 문제와 해결 방법을 다룹니다.

문제: Filebeat가 실행되지 않음

Filebeat가 클라이언트 시스템에서 실행되고 있지 않은 경우 몇 가지 잠재적인 원인이 있습니다. 이 섹션에서는 Filebeat가 실행되지 않는 다양한 일반적인 경우를 다루고 가능한 솔루션을 제안합니다.

원인: 구성에 구문 오류가 포함되어 있습니다.

Filebeat가 /etc/filebeat/filebeat.yml에 있는 구성 파일에 오류가 있으면 서비스를 제대로 시작할 수 없습니다. 다음과 같은 오류와 함께 즉시 종료됩니다.

Output
Loading config file error: YAML config parsing failed on /etc/filebeat/filebeat.yml: yaml: line 13: could not find expected ':'. Exiting.

이 경우 구성 파일에 오타가 있습니다. 이 문제를 해결하려면 Filebeat 구성의 잘못된 부분을 편집하십시오. 지침은 ELK 스택 자습서의 Filebeat 설정(클라이언트 서버 추가)의 Filebeat 구성 하위 섹션을 따르십시오.

Filebeat 구성을 편집한 후 서비스를 다시 시작하십시오.

  1. sudo service filebeat start

오류 출력이 표시되지 않으면 문제가 해결된 것입니다.

원인: SSL 인증서가 없거나 유효하지 않습니다.

Filebeat와 Logstash 간의 통신에는 인증 및 암호화를 위한 SSL 인증서가 필요합니다. Filebeat가 제대로 시작되지 않으면 syslog에서 다음과 유사한 오류를 확인해야 합니다.

Output
Error Initialising publisher: open /etc/pki/tls/certs/logstash-forwarder.crt: no such file or directory

이는 logstash-forwarder.crt 파일이 적절한 위치에 없음을 나타냅니다. 이 문제를 해결하려면 ELK 스택 자습서의 Filebeat 설정(클라이언트 서버 추가) 섹션의 해당 하위 섹션에 따라 ELK 서버에서 클라이언트 시스템으로 SSL 인증서를 복사하십시오.

적절한 SSL 인증서 파일을 적절한 위치에 배치한 후 Filebeat를 다시 시작해 보십시오.

SSL 인증서가 유효하지 않은 경우 로그는 다음과 같아야 합니다.

syslog (Certificate is invalid):
transport.go:125: SSL client failed to connect with: x509: certificate signed by unknown authority (possibly because of "crypto/rsa: verification error" while trying to verify candidate authority certificate "elk.example.com")

오류 메시지는 인증서가 존재하지만 유효하지 않음을 나타냅니다. 이 경우 Filebeat 설정(클라이언트 서버 추가))을 따라야 합니다.

인증서가 유효하고 올바른 위치에 있는지 확인한 후 Logstash(ELK 서버에서)를 다시 시작하여 강제로 새 SSL 키를 사용하도록 해야 합니다.

  1. sudo service logstash restart

그런 다음 클라이언트 시스템에서 Filebeat를 시작합니다.

  1. sudo service filebeat start

로그를 다시 확인하여 문제가 해결되었는지 확인하십시오.

문제: Filebeat가 Logstash에 연결할 수 없음

Filebeat(클라이언트 서버)가 Logstash(ELK 서버)에 연결할 수 없는 경우 다음과 같은 오류 로그 항목이 표시됩니다.

syslog (Connection refused):
transport.go:125: SSL client failed to connect with: dial tcp 203.0.113.4:5044: getsockopt: connection refused

Logstash에 연결할 수 없는 일반적인 이유는 다음과 같습니다.

  • Logstash가 실행되고 있지 않습니다(ELK 서버에서).
  • 두 서버의 방화벽이 포트 5043의 연결을 차단하고 있습니다.
  • Filebeat가 적절한 IP 주소, 호스트 이름 또는 포트로 구성되지 않았습니다.

이 문제를 해결하려면 먼저 이 가이드의 Logstash 문제 해결 섹션에 따라 Logstash가 ELK 서버에서 실행 중인지 확인하십시오. 둘째, 방화벽이 네트워크 트래픽을 차단하고 있지 않은지 확인하십시오. 셋째, Filebeat가 올바른 IP 주소(또는 호스트 이름)와 ELK 서버의 포트로 구성되어 있는지 확인합니다.

Filebeat 구성은 다음 명령으로 편집할 수 있습니다.

  1. sudo vi /etc/filebeat/filebeat.yml

Logstash 연결 정보가 올바른지 확인한 후 Filebeat를 다시 시작해 보십시오.

sudo service filebeat restart

Filebeat 로그를 다시 확인하여 문제가 해결되었는지 확인하십시오.

일반적인 Filebeat 지침은 ELK 스택 자습서의 Filebeat 설정(클라이언트 서버 추가)의 Filebeat 구성 하위 섹션을 따르십시오.

Elasticsearch: 실행 중인지 확인하는 방법

Elasticsearch가 실행되고 있지 않으면 ELK 스택이 작동하지 않습니다. Logstash는 Elasticsearch에 새 로그를 추가할 수 없으며 Kibana는 보고를 위해 Elasticsearch에서 로그를 검색할 수 없습니다. 이 섹션에서는 Elasticsearch가 정상적으로 작동하는지 확인하는 방법을 보여줍니다.

서비스가 실행 중인지 확인

확인해야 할 가장 기본적인 사항은 Elasticsearch 서비스의 상태입니다.

  1. sudo service elasticsearch status

Elasticsearch가 실행 중인 경우 다음 출력이 표시됩니다.

Elasticsearch status (OK):
* elasticsearch is running

그렇지 않고 서비스가 실행되고 있지 않으면 다음 메시지가 표시됩니다.

Elasticsearch status (Bad):
* elasticsearch is not running

이 경우 Elasticsearch 문제 해결을 다루는 다음 몇 가지 섹션을 따라야 합니다.

HTTP 요청에 응답하는지 확인

기본적으로 Elasticsearch는 포트 9200에서 HTTP 요청에 응답합니다(새 http.port 값을 지정하여 구성 파일에서 사용자 지정할 수 있음). curl을 사용하여 요청을 보내고 Elasticsearch에서 유용한 정보를 검색할 수 있습니다.

다음 명령과 함께 curl을 사용하여 HTTP GET 요청을 보냅니다(Elasticsearch가 localhost에서 도달할 수 있다고 가정).

  1. curl localhost:9200

Elasticsearch가 실행 중인 경우 다음과 같은 응답이 표시됩니다.

Output
{ "name" : "Hildegarde", "cluster_name" : "elasticsearch", "cluster_uuid" : "E8q9kr-0RxycYhSLNx8xeA", "version" : { "number" : "2.4.6", "build_hash" : "5376dca9f70f3abef96a77f4bb22720ace8240fd", "build_timestamp" : "2017-07-18T12:17:44Z", "build_snapshot" : false, "lucene_version" : "5.5.4" }, "tagline" : "You Know, for Search" }

다음 명령을 사용하여 Elasticsearch 클러스터의 상태를 확인할 수도 있습니다.

curl localhost:9200/_cluster/health?pretty

출력은 다음과 같아야 합니다.

Output
{ "cluster_name" : "elasticsearch", "status" : "yellow", "timed_out" : false, "number_of_nodes" : 1, "number_of_data_nodes" : 1, "active_primary_shards" : 6, "active_shards" : 6, "relocating_shards" : 0, "initializing_shards" : 0, "unassigned_shards" : 6, "delayed_unassigned_shards" : 0, "number_of_pending_tasks" : 0, "number_of_in_flight_fetch" : 0, "task_max_waiting_in_queue_millis" : 0, "active_shards_percent_as_number" : 50.0 }

Elasticsearch 클러스터가 단일 노드로 구성된 경우 클러스터는 아마도 노란색 상태일 것입니다. 이는 단일 노드 클러스터의 경우 정상입니다. Elasticsearch 클러스터에 노드를 하나 이상 추가하여 녹색 상태로 업그레이드할 수 있습니다.

문제: Elasticsearch가 실행되지 않음

Elasticsearch가 실행되지 않는 경우 여러 가지 잠재적인 원인이 있습니다. 이 섹션에서는 Elasticsearch가 실행되지 않는 다양한 일반적인 경우를 다루고 잠재적 솔루션을 제안합니다.

원인: 시작되지 않음

Elasticsearch가 실행되고 있지 않다면 처음부터 시작되지 않았을 수 있습니다. Elasticsearch는 설치 후 자동으로 시작되지 않습니다. 이에 대한 해결책은 처음에 수동으로 시작하는 것입니다.

  1. sudo service elasticsearch start

이것은 Elasticsearch가 시작되고 있음을 보고해야 합니다. 10초 정도 기다린 후 Elasticsearch 상태를 다시 확인합니다.

원인: Elasticsearch 서비스가 활성화되지 않았고 서버가 재부팅되었습니다.

Elasticsearch가 제대로 작동했지만 더 이상 작동하지 않는 경우 제대로 활성화되지 않았을 수 있습니다. 기본적으로 Elasticsearch 서비스는 부팅 시 시작하도록 활성화되어 있지 않으므로 부팅 시 Elasticsearch가 자동으로 시작되도록 명시적으로 활성화해야 합니다.

  1. sudo update-rc.d elasticsearch defaults 95 10

Elasticsearch는 이제 부팅 시 자동으로 시작됩니다. 서버를 재부팅하여 작동하는지 테스트하십시오.

원인: Elasticsearch가 잘못 구성됨

Elasticsearch가 /etc/elasticsearch/elasticsearch.yml에 있는 구성 파일에 오류가 있으면 서비스를 제대로 시작할 수 없습니다. 가장 좋은 방법은 실패 이유에 대한 단서를 위해 Elasticsearch 오류 로그를 확인하는 것입니다.

서비스를 시작하는 동안 Elasticsearch 로그를 볼 수 있도록 서버에 대한 두 개의 터미널 세션을 엽니다.

첫 번째 터미널 세션에서 로그를 살펴보겠습니다.

  1. tail -f /var/log/elasticsearch/elasticsearch.log

그러면 마지막 몇 개의 로그 항목과 향후 로그 항목이 표시됩니다.

두 번째 터미널 세션에서 Elasticsearch 서비스를 시작해 보십시오.

  1. sudo service elasticsearch start

Elasticsearch가 시작될 때 생성된 로그를 보려면 첫 번째 터미널 세션으로 다시 전환하십시오.

오류 또는 예외(예: ERROR, 예외 또는 오류)를 나타내는 로그 항목이 표시되면 원인을 나타내는 행을 찾으십시오. 오류. 다음은 Elasticsearch network.host가 확인할 수 없는 호스트 이름 또는 IP 주소로 설정된 경우 표시되는 오류 로그의 예입니다.

Elasticsearch logs (Bad):
... [2015-10-27 15:24:43,495][INFO ][node ] [Shadrac] starting ... [2015-10-27 15:24:43,626][ERROR][bootstrap ] [Shadrac] Exception org.elasticsearch.transport.BindTransportException: Failed to resolve host [null] at org.elasticsearch.transport.netty.NettyTransport.bindServerBootstrap(NettyTransport.java:402) at org.elasticsearch.transport.netty.NettyTransport.doStart(NettyTransport.java:283) at org.elasticsearch.common.component.AbstractLifecycleComponent.start(AbstractLifecycleComponent.java:85) at org.elasticsearch.transport.TransportService.doStart(TransportService.java:153) at org.elasticsearch.common.component.AbstractLifecycleComponent.start(AbstractLifecycleComponent.java:85) at org.elasticsearch.node.internal.InternalNode.start(InternalNode.java:257) at org.elasticsearch.bootstrap.Bootstrap.start(Bootstrap.java:160) at org.elasticsearch.bootstrap.Bootstrap.main(Bootstrap.java:248) at org.elasticsearch.bootstrap.Elasticsearch.main(Elasticsearch.java:32) Caused by: java.net.UnknownHostException: incorrect_hostname: unknown error ...

예제 로그의 마지막 줄은 UnknownHostException: incorrect_hostname 오류가 발생했음을 나타냅니다. 이 특정 예는 network.hostincorrect_hostname으로 설정되어 아무것도 확인하지 않음을 나타냅니다. 단일 노드 Elasticsearch 설정에서는 localhost 또는 127.0.0.1로 설정해야 합니다.

이 문제를 해결하려면 Elasticsearch 구성 파일을 편집하십시오.

  1. sudo vi /etc/elasticsearch/elasticsearch.yml

잘못된 항목이 있는 행을 찾아서 수정하십시오. 예제의 경우 network.host: wrong_hostname을 지정하는 줄을 찾아 다음과 같이 변경해야 합니다.

...
network.host: localhost
...

저장 및 종료.

이제 두 번째 터미널에서 Elasticsearch 서비스를 시작합니다.

  1. sudo service elasticsearch start

문제가 해결되면 Elasticsearch가 시작되었음을 나타내는 오류 없는 로그가 표시되어야 합니다. 다음과 같이 보일 수 있습니다.

Elasticsearch logs (Good):
... [2015-10-27 15:29:21,980][INFO ][node ] [Garrison Kane] initializing ... [2015-10-27 15:29:22,084][INFO ][plugins ] [Garrison Kane] loaded [], sites [] [2015-10-27 15:29:22,124][INFO ][env ] [Garrison Kane] using [1] data paths, mounts [[/ (/dev/vda1)]], net usable_space [52.1gb], net total_space [58.9gb], types [ext4] [2015-10-27 15:29:24,532][INFO ][node ] [Garrison Kane] initialized [2015-10-27 15:29:24,533][INFO ][node ] [Garrison Kane] starting ... [2015-10-27 15:29:24,646][INFO ][transport ] [Garrison Kane] bound_address {inet[/127.0.0.1:9300]}, publish_address {inet[localhost/127.0.0.1:9300]} [2015-10-27 15:29:24,682][INFO ][discovery ] [Garrison Kane] elasticsearch/WJvkRFnbQ5mLTgOatk0afQ [2015-10-27 15:29:28,460][INFO ][cluster.service ] [Garrison Kane] new_master [Garrison Kane][WJvkRFnbQ5mLTgOatk0afQ][elk-run][inet[localhost/127.0.0.1:9300]], reason: zen-disco-join (elected_as_master) [2015-10-27 15:29:28,561][INFO ][http ] [Garrison Kane] bound_address {inet[/127.0.0.1:9200]}, publish_address {inet[localhost/127.0.0.1:9200]} [2015-10-27 15:29:28,562][INFO ][node ] [Garrison Kane] started ...

이제 Elasticsearch 상태를 확인하면 정상적으로 실행되고 있음을 확인할 수 있습니다.

우리의 예와 다른 구성 문제가 있을 수 있습니다. 오류의 의미를 파악할 수 있으면 직접 수정해 보세요. 이것이 실패하면 서버에 특정한 정보(예: IP 주소 또는 자동으로 생성된 Elasticsearch 노드 이름)가 포함되지 않은 개별 오류 줄을 인터넷에서 검색해 보십시오.

결론

이 문제 해결 가이드가 ELK 스택 설정과 관련된 문제를 해결하는 데 도움이 되었기를 바랍니다. 질문이나 제안 사항이 있으면 아래 의견에 남겨주세요!