mackerel으로 인프라를 감시해보자 – 3(로그와 데이터베이스 감시하기)

지난번 글에서 서버의 감시를 설정해보았습니다.
이번에는 서버의 로그 감시와 설정 파일 작업 그리고 인테그레이션을 통한 데이터베이스 감시 등을 알아보겠습니다.

해보기

시연 환경

AWS EC2와 RDS를 감시해보도록 하겠습니다.
EC2의 OS는 Ubuntu 20.04.2.0 LTS를 사용하도록 하겠습니다.
EC2를 작성하는 방법은 본 글에서 설명하지 않습니다.

시연 내용

서버의 설정 파일에 대하여 알아봅니다.
이후 설정 파일을 이용하여 로그 감시를 해보도록 하겠습니다.
마지막으로 AWS 인테그레이션을 통하여 RDS의 감시를 설정해보겠습니다.

매커렐의 설정 파일

매커렐의 설정 파일은 리눅스라면 /etc/mackerel-agent/mackerel-agent.conf 에 있습니다.
윈도우의 경우 C:\Program Files (x86){또는Program Files}\Mackerel\mackerel-agent 에 있습니다.
사용할 수 있는 옵션들이 주석으로 처리되어 있으며 이를 수정하여 다양한 감시를 설정할 수 있습니다.
상세한 사양은 공식 문서를 참고해주세요.

디스크 무시하기

설정 파일 조작의 연습으로 loop 디스크 무시를 설정해보겠습니다.
(우분투 이외의 OS라면 다른 디스크의 무시 혹은 다른 설정을 해보시길 바랍니다.)
AWS의 우분투 이미지를 사용할 경우 SSM-Agent가 자동으로 설치됩니다. 이때 자동으로 snap 패키지를 사용하여 설치됩니다.
문제는 snap 데몬이 시작될 때 loop 디스크를 read only로 마운트하기 때문에 매커렐에서는 이 디스크를 읽고 사용량을 100%로 인식합니다.
그래서 디스크의 사용량(filesystems)의 경보가 발생하게 됩니다.
이를 해결하기 위해 설정 파일의 ignore를 설정해보겠습니다.

ignore 옵션의 기본값은 다음과 같습니다.

# [filesystems]
# ignore = "/dev/ram.*"

loop 디스크를 무시하기 위해서 다음과 같이 바꾼 후 저장합니다.

[filesystems]
ignore = "/dev/loop.*"

만약 리눅스가 아닌 윈도우 OS에서 다수의 디스크를 무시하기 위해선 다음과 같이 설정합니다.

[filesystems]
ignore = "(E|D|F):"

설정을 적용하여 에이전트를 재기동하기 전에 제대로 적용되는지 확인해보겠습니다.
우선 설정 파일의 구문에 문제가 없는지 확인해보기 위해서 configtest명령어를 사용합니다.

$ mackerel-agent configtest
----
/etc/mackerel-agent/mackerel-agent.conf Syntax OK

현재 설정으로 지표를 수집하면 어떻게 나오는지 확인하기 위해선 다음 커맨드를 입력합니다.

$ mackerel-agent once
----
{"host":...}

문제없이 출력되었다면 매커렐을 재기동합니다.

$ sudo systemctl restart mackrel-agent

이후 대시보드를 확인해보면 loop 디스크의 사용량 경보가 해결되어 있는 것을 확인할 수 있습니다.

이런 방식으로 설정 파일에서 필요한 옵션을 수정하여 대시보드에서의 설정보다 더 상세한 감시가 가능합니다.
ignore의 경우에는 별다른 패키지의 설치가 없어도 가능했지만 이름에 "plugin"이 붙어있는 설정은 추가 패키지의 설치가 필요합니다.
로그 감시를 설정해보며 이에 대하여 알아보겠습니다.

로그 감시하기

로그 감시도 마찬가지로 설정 파일을 통하여 조작할 수 있습니다.
저는 고객님의 환경에서 어플리케이션의 로그를 감시하고 경보가 울리도록 설정하기 위하여 사용했었습니다.
이번 글에서는 error 라는 영어 문자열을 감시하지만 영어 이외의 문자열을 감시하기 위해선 설정 파일의 인코딩을 utf-8로 변경하여야 합니다.

사용하기 위해서 우선 추가 패키지를 설치할 필요가 있습니다.
각 옵션의 적용에 어떠한 패키지가 있는지는 공식 문서를 확인해주세요.
로그 감시의 문서는 설명서을 참조해주세요.

우선 각 OS에 맞는 방법을 문서에서 확인하여 플러그인을 설치합니다.

# ubuntu의 경우
sudo apt-get install mackerel-check-plugins

어떠한 파일을 감시하며 해당 파일에 "error"라는 문자열이 기재되면 경보가 울리도록 간단한 설정을 해보겠습니다.
기본적으로 필요한 설정 내용은 다음과 같습니다.

# check-log, --file, --pattern 은 필수
[ plugin.checks.{설정의 이름} ]
command = ["check-log" , "--file" , "{로그 파일의 패스}" , "--pattern" , "{감시할 내용}"]

command의 다른 옵션은 위의 설명서를 참고해주세요.
command 이외에 checks 플러그인의 추가 옵션은 이 쪽 설명서를 참고해주세요.
이를 적용하여 다음과 같은 내용을 설정 파일에 추가하였습니다.

[ plugin.checks.test_error ]
command = ["check-log" , "--file" , "/var/log/test.log" , "--pattern" , "error", "--warning-over", "2", "--critical-over" , "4"]
check_interval =  5

설정 내용을 설명하자면 다음과 같습니다.

• 대시 보드에 표시되는 이름은 test_error 입니다
• /var/log/test.log 파일에 error 라는 문자열을 감시합니다
• 2번을 초과하면 warning, 4번을 초과하면 critical로 경보를 발생시킵니다
• check_interval를 설정하여 5분에 한번 씩 감시합니다

이 후 파일을 저장하고 구문 검사에 문제가 없다면 에이전트를 재기동합니다.
그러면 대시보드에 다음과 같이 해당 서버에 감시 항목이 추가된 것을 확인할 수 있습니다.
매트릭스는 따로 표시되지 않습니다.

제대로 감시가 되고 있는지 로그 파일에 직접 NG를 3번 기입하여 경보가 발생하는지 확인해보니 아래와 같이 제대로 동작하였습니다.

이상으로 서버의 감시 설정은 마치겠습니다. 이어서 RDS의 감시를 설정하겠습니다.

클라우드 서비스의 리소스 감시하기

AWS, GCP, Azure 등의 클라우드 서비스의 리소스를 감시하기 위해선 인테그레이션(통합)이 필요합니다.
이 기능은 Trial 플랜과 Standard 플랜에서만 제공됩니다.

이번엔 AWS의 인테그레이션을 통하여 RDS를 감시해보겠습니다.
공식 문서는 여기를 참고해주세요.
현재 지원하는 AWS의 서비스는 다음과 같습니다.

EC2・ELB (CLB)・ALB・NLB・RDS・ElastiCache・Redshift・Lambda・SQS・DynamoDB・CloudFront・API Gateway・Kinesis Data Streams・S3・Elasticsearch Service・ECS・SES・Step Functions・EFS・Kinesis Data Firehose・Batch・WAF・Billing・Route 53・Connect

인테그레이션을 설정하는 방법으로는 다음 2가지가 있습니다.

• Mackerel 시스템의 AWS 계정에서만 액세스할 수 있도록 IAM 역할을 구성하고 AssumeRole로 인증
• 액세스 키 ID 및 보안 액세스 키 구성

추천 방법은 IAM 역할을 사용하는 것이므로 이번 글에서는 역할로 인테그레이션을 설정하겠습니다.
작업의 흐름은 다음과 같습니다.

1. IAM 역할 생성
2. ARN 등록 및 사용 서비스 설정하기, 호스트 확인
3. 태그 작업

IAM 역할 생성

사이드바의 오거니제이션을 클릭한 후 AWS Integration 탭을 클릭합니다. 그리고 Set up AWS Integration을 클릭합니다.

나온 화면의 External ID은 복사해둡니다.
IAM 역할의 ARN 이 필요하기 때문에 AWS의 IAM 콘솔에서 다음과 같이 역할을 생성합니다.

계정 ID는 고정이며 외부 ID에 방금 복사한 External ID를 붙여넣습니다.

다음으로 권한을 설정합니다.
설명서를 참조하여 필요한 권한만을 검색하여 추가합니다. 저는 EC2(AmazonEC2ReadOnlyAccess)와 RDS(AmazonRDSReadOnlyAccess)의 권한을 추가하겠습니다.
또한 태그로 감시할 서비스를 지정하기 위해 다음의 권한을 인라인 정책으로 추가해주었습니다.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Action": [
                "elasticache:ListTagsForResource",
                "sqs:ListQueueTags",
                "states:ListTagsForResource"
            ],
            "Effect": "Allow",
            "Resource": "*"
        }
    ]
}

역할을 생성한 후 ARN을 복사합니다.

ARN 등록 및 사용 서비스 설정하기

다시 AWS 인테그레이션 화면으로 가서 Role ARN 에 복사한 ARN을 붙여 넣습니다.
그리고 감시할 리전과 서비스를 지정합니다.
서비스를 지정하며 사용할 지표를 설정할 수 있습니다.
각 호스트의 설정된 지표를 5분마다 Cloudwatch의 API 호출이 발생하므로 너무 많은 지표를 호출한다면 요금에 변동이 생길 수 있습니다.
저는 모든 지표가 기록되어 있지 않기도 하고 API 호출로 생기는 요금에 큰 변동이 없어서 따로 지정하지 않았습니다. 자세한 요금은 공식 문서의 API 요금을 참조해주세요.
대략 다음과 같이 설정하여 인테그레이션을 생성합니다.

이 후 호스트 목록을 확인하면 다음과 같이 모든 EC2와 RDS가 호스트로 추가 된 것을 확인할 수 있습니다.

아직 RDS의 모니터와 롤은 추가되지 않았으므로 RDS를 대상으로 저번 글 서비스 등록하기부터 작업해줍니다.

태그 작업

호스트 목록을 확인해보니 사용하지 않을 EC2도 추가되어있습니다.
인테그레이션을 설정할 때 태그를 설정하지 않았기 때문에 모든 EC2와 RDS가 호스트로 등록되었기 때문입니다.
매커렐에서는 감시 대상을 간단하게 태그로 특정할 수 있습니다.

우선 감시할 EC2와 RDS에 특정가능한 태그를 추가합니다.
태그 이름과 값은 자유입니다.

다음으로 오거니제이션의 AWS Integration에서 해당 인테그레이션을 수정합니다.

그리고 이미지와 같이 태그를 지정하면 대상 호스트의 숫자가 줄어드는 것을 확인할 수 있습니다.

업데이트 후 어느정도 시간이 지나고 호스트 목록을 확인하시면 태그를 지정한 호스트만 등록이 되어 있는 것을 확인하실 수 있습니다.

마치며

옵션을 설명하며 글을 적다보니 글이 3개로 나뉘고 말았네요..
여기까지 사용하신다면 매커렐의 대부분의 기능을 사용하실 수 있습니다.
이외에 서버 미들웨어의 지표를 감시한다거나 컨테이너를 감시하는 등 다양한 기능을 매커렐에서 제공하고 있습니다.
관심이 있으신 분은 공식 문서를 참고해주세요.

긴 글 읽어 주셔서 감사합니다.
오탈자 및 내용의 피드백은 must01940지메일로 보내주시면 감사드립니다.

관련 글

• mackerel으로 인프라를 감시해보자 – 1(기본 설정하기)
• mackerel으로 인프라를 감시해보자 – 2(서버 감시하기)
• mackerel으로 인프라를 감시해보자 – 3(로그와 데이터베이스 감시하기)
• mackerel으로 인프라를 감시해보자 – 4(그 외의 모니터링과 팁)