Logstash 튜토리얼: Logstash를 사용하여 이메일 알림 간소화

게시 됨: 2022-03-11

오류 및 예외를 보고하는 주요 메커니즘으로 이메일을 사용하는 앱은 처음에는 항상 좋은 생각처럼 보입니다. Java 개발자로서 우리는 "이봐, 뭔가 잘못되면 즉시 알겠다!"라고 생각합니다.

그러나 어느 시점에서 오류 이메일이 점점 멀어지고 있으며 이메일 받은 편지함을 정리해야 한다는 것을 깨닫게 될 것입니다. 404(대부분의 경우)를 무시할 수 있으며 새로운 가입 알림을 받는 것이 좋을 수 있지만 하루가 끝나면 너무 바쁘거나 시간이 많이 걸릴 수 있습니다.

조만간 "실행 가능한" 이메일과 무의미한 알림을 구별하는 것이 어려워집니다. 메일에 규칙과 필터를 설정할 수 있지만 이마저도 관리하기 어려워질 수 있습니다.

이 Java 튜토리얼은 Logstash를 사용하여 제어권을 되찾고 이메일 받은 편지함을 정리하고 오류 이메일을 다시 관리할 수 있게 만드는 가능성을 살펴보겠습니다.

Logstash 설정 및 입력

Logstash 튜토리얼의 첫 번째 단계는 시스템에서 수신하는 모든 이메일이 하나의 폴더로 이동하도록 하는 것입니다. 모든 정렬 및 관리를 받은 편지함에서 옮기고 있으므로 더 이상 하나의 큰 폴더인 것은 중요하지 않습니다. 계속 진행하여 이미 설정한 모든 폴더와 필터를 제거하고 하나의 폴더와 하나의 필터로 줄이십시오.

모든 이메일을 "[email protected]"에서 "MyAwesomeAppEmails" 폴더로 이동합니다. 이러한 이메일에 대해 별도의 사서함이 있으면 훨씬 더 쉽습니다.

이제 Logstash를 설정하여 해당 폴더를 폴링하고 IMAP 플러그인을 사용하여 메일을 구문 분석할 수 있습니다. 버전 1.4.2는 받은 편지함에서 이메일 가져오기만 지원하지만 버전 1.5에는 특정 폴더를 폴링할 수 있도록 비교적 간단한 수정 사항이 적용되었습니다. 별도의 사서함이 없는 경우 계속하기 전에 Logstash 인스턴스의 IMAP 플러그인에 패치를 적용하십시오.

 # /etc/logstash/conf.d/01-imap-input.conf input { imap { host => "imap.yourmailserver.com" user => "username" password => "password" secure => true fetch_count => 15 folder => "MyAwesomeAppEmails" # This line will only work if you apply the above mentioned patch } }

그러면 새 이메일을 확인하고 Logstash 이벤트로 구문 분석하기 시작합니다.

로그스태시 필터

많은 유용한 데이터가 이메일에서 다른 이벤트 속성으로 구문 분석됩니다. 이메일 타임스탬프는 이벤트의 "@timestamp"로 사용됩니다. 더 나아가 헤더만으로 오류가 발생한 호스트를 식별하는 것과 같은 작업을 수행할 수 있습니다.

 filter { mutate { replace => [ "received", "%{[received][-1]}" ] } grok { match => [ "received", "from %{HOSTNAME:hostname} \(%{HOSTNAME:full_hostname} \[%{IP:ip}\]\)" ] } mutate { remove_field => [ "received" ] } }

그러나 이것은 오류 이메일을 길들이기에 충분하지 않습니다. 좀 더 구체적으로 설명하는 다음 세 단계가 필요합니다.

오류 유형
오류의 심각도
이메일에 포함된 모든 오류 세부정보

오류 이름(예: "Widget Failed")과 "ERROR: Widget Failed in /var/www/myapp/foobar"와 같이 이메일 제목에 오류 "ERROR"의 심각도를 넣었다고 가정해 보겠습니다. .php 20”.

이것을 사용하여 이벤트의 여러 속성을 설정합니다.

 filter { grok { match => [ "subject", "%{WORD:severity}: %{DATA:type} in %{PATH:path} %{POSINT:line}" ] } }

Logstash는 로그 및 기타 다양한 위치에서 볼 수 있을 것으로 예상되는 미리 정의된 여러 패턴과 함께 제공됩니다. 이를 사용하여 Grok 패턴을 구축하고 읽기 쉽게 만드십시오. "WORD"(단일 단어), "DATA"(non-greedy catchall), "PATH"(Unix 또는 Windows 파일 경로) 및 "POSINT"(양의 정수)를 사용했습니다. Grok 디버거를 사용하여 Grok 패턴을 디버깅할 수도 있습니다. 패턴과 일치하지 않는 메시지에는 "_grokparsefailure" 태그가 지정됩니다.

이는 유형, 심각도, 소스 파일 및 오류 행(기본적으로 이벤트의 모든 관련 메타 데이터)을 처리합니다. 이제 세부 사항으로 넘어갑니다.

미세 조정 Logstash

이전에 이메일에 멋진 머리글이나 바닥글 서명을 추가했을 수 있습니다. 오류 스택 추적에 대한 나머지 이메일을 구문 분석할 수 있도록 메시지와 후행 공백을 제거해 보겠습니다.

 filter { mutate { # gsub takes 3 elements per substitution: field, regular expression and substitution gsub => [ "message", "Your Dev Team", "", "message", "More error details:", "" ] } mutate { strip => "message" } # Split the message into an array of lines, each containing a line of the stacktrace mutate { split => [ "message", "\n" ] } }

"gsub" 변형은 표준 Ruby Regexp 개체를 사용하므로 모든 옵션과 기능을 logstash에서도 사용할 수 있습니다.

Elasticsearch 및 Amazon SNS를 통한 출력

Logstash Elasticsearch 출력을 사용하여 Elasticsearch 인스턴스에 이것을 적용하여 수집 중인 데이터를 쉽게 검색하고 수량화할 수 있습니다.

 output { if "_grokparsefailure" not in [tags] { elasticsearch { } } }

"_grokparsefailure" 태그를 확인하여 제대로 Grok하지 않은 모든 메시지를 제외합니다. 제목이 지정된 제목과 일치하는 이메일만 오류 이메일로 해석되어야 한다고 가정합니다. 그렇지 않으면 간단하고 간단합니다.

Logstash는 많은 출력을 제공하므로 Amazon의 SNS(Simple Notification Service)를 사용하여 중대한 오류를 알리기 위해 SNS 출력을 사용하여 이를 더욱 강화해 보겠습니다. "알림" 유형의 모든 오류는 알림을 생성해야 한다고 가정합니다. EC2 인스턴스에 있지 않은 경우 AWS 키와 암호를 지정해야 합니다.

 output { if "notifiable" in [tags] { sns { region => "us-east-1" arn => "arn:aws:sns:us-east-1:1234567890123456:mytopic" access_key_id => "AWS ACCESS_KEY" # Only specify these if you're not on an EC2 instance secret_access_key => "AWS ACCESS SECRET" # Only specify these if you're not on an EC2 instance } } }

오류에 "알림 가능"으로 태그를 지정하는 것은 귀하에게 달려 있습니다. 오류의 심각도 또는 오류 유형을 확인하여 이를 수행할 수 있습니다.

이제 실제로 중요한 이메일을 다시 읽을 수 있으며 중요한 오류 이메일을 놓치지 않을 것입니다. 또한 오류가 발생하는 빈도와 마지막으로 발생한 시간을 볼 수 있으므로 수정할 오류에 대한 정보에 입각한 결정을 내릴 수 있습니다. 이 Logstash 자습서에 설명된 Elasticsearch의 놀라운 검색 기능 덕분에 특정 오류를 검색하는 것도 더 쉽고 빠릅니다.