Mackerel 에 fluentd 에서 메트릭을 보내는 플러그인 fluent-plugin-mackerel 의 사용법의 예를 소개합니다.

기능

기능으로는 크게 나누어 다음 두 가지가 있습니다.

mackerel에 메트릭 보내기 (out_mackerel)

태그와 레코드에 mackerel hostid 추가 (out_mackerel_hostid_tag ​​)

전자는 호스트 별 및 서비스 메트릭 전송 모두를 지원합니다. 호스트별 메트릭을 보내는 경우에는 hostid 또는 hostid_path 에서 어떤 호스트의 메트릭을 지정해야 합니다. hostid 에는 직접 hostid 혹은 ${tag_parts[n]} 의 형식 (n은 임의의 정수)을 지정할 수 있어 hostid_path 는 hostid 가 포함되고 있는 파일의 패스를 지정합니다. (yum으로 설치하면/var/lib/mackerel-agent/id에 저장됩니다)

후자는 여러 호스트의 메트릭을 어딘가 특정 fluentd에서 집계하여 보내고 싶을 때 mackerel의 hostid를 태그 나 레코드에 추가하는 데 사용됩니다. 수신자는 hostid 의 지정에 ${tag_parts[n]} 을 지정하면 좋을 것입니다.

기본적으로 1분에 한 번 지표를 전송합니다. flush_interval 로 송신 빈도는 제어할 수 있습니다만, 1분 이하로 설정할 수는 없습니다.

설정 예

웹 서버의 상태 코드별 집계 전송

nginx 및 apache 로그를 datacounter 플러그인을 통해 보내면 다음과 같은 그래프가 생성됩니다.



설정은 다음과 같습니다.

<source>
  type tail
  format ltsv
  time_format %d/%b/%Y:%H:%M:%S %z
  path /var/log/nginx/access.log
  pos_file /var/log/td-agent/nginx.log.pos
  tag raw.nginx
</source>

<match raw.nginx>
  type datacounter
  count_interval 1m
  count_key status
  input_tag_remove_prefix access
  tag nginx.status
  outcast_unmatched yes
  # patternX: X(1-20)
  pattern1 2xx ^2\d\d$
  pattern2 3xx ^3\d\d$
  pattern3 4xx ^4\d\d$
  pattern4 5xx ^5\d\d$
</match>

<match nginx.status>
  type mackerel
  api_key <あなたの API キー>
  hostid_path /var/lib/mackerel-agent/id
  metrics_name http_status.${out_key}
  out_keys nginx_2xx_count,nginx_3xx_count,nginx_4xx_count,nginx_5xx_count
</match>

Cloudwatch RDS 지표 등록

cloudwatch 플러그인 에서 얻은 RDS CPUUtilization 메트릭을 서비스 메트릭으로 등록하는 예입니다.



설정은 다음과 같습니다.

<source>
  type cloudwatch
  tag  raw.cloudwatch.rds_cpu
  cw_endpoint <あなたの RDS のリージョンの Cloudwatch のエンドポイント>
  period 60
  interval 60

  namespace AWS/RDS
  metric_name CPUUtilization
  dimensions_name DBInstanceIdentifier
  dimensions_value <あなたの RDS インスタンスの ID>
</source>

<match raw.cloudwatch.rds_cpu>
  type mackerel
  api_key <あなたの API キー>
  service <あなたのサービス>
  metrics_name ${[1]}.${out_key}
  out_keys CPUUtilization
</match>

요약

fluentd 의 로그를 그대로 흘리기 보다는, 상기의 datacounter 플러그인 이나 numericcounter 플러그인 , grepcounter 플러그인 를 이용해, 감시하고 싶은 항목을 수치화해 포스트 한다고 하는 사용법이 생각됩니다. 위에서는 웹 서버의 로그였습니다만, DB의 슬로우 쿼리의 건수나 시간, 앱 로그의 ERROR나 WARN의 수등, 로그의 감시로의 사용지점은 여러가지 있다고 생각합니다.

또한 AWS 서비스는 특정 호스트에 연결되지 않지만 서비스 메트릭으로 등록하여 개별 호스트의 메트릭과 마찬가지로 Mackerel에 플롯할 수 있습니다. Cloudwatch에서는 저장할 수 없는 장기간의 추세를 파악하고 싶은 경우에는 유효한 수단 중 하나라고 생각합니다. 위에서는 앞의 nginx 와 대비하기 위해 RDS 의 메트릭스로 했습니다만, ELB 등도 서비스 메트릭스로서 등록해도 좋은 자원의 하나라고 생각합니다.

또한, Mackerel은 그래프의 UI도 사용하기 쉽게 만들어져 있기 때문에, 장애 발생시 호스트의 상황과 마찬가지로 AWS 리소스도 같은 화면인 어느 정도 추적하도록 해두면 상황 파악이 용이해질지도 모릅니다. 그렇습니다.