概要

Zabbixのログ監視は、CloudWatch Logs, Lambda, Chatworkを組み合わせて実現できます。

DatadogとかMackerelに移行を考えているけど、機能として欠けていて、でも業務には組込まれていて、みたいなのをどうにかしました。

注意点

Chatwork APIが、５分間に100回というヤバい仕様なので、これより明らかに頻度の少ないものだけにしましょう。
他は、目立った制約事項はない、、、はず

構成

EC2

CloudWatch Logsエージェントをインストールします。詳細は下記。

CloudWatch Logs の使用開始 - Amazon CloudWatch

CloudWatch Logs

ログが取り込まれていることが確認できれば、ここでやることはもう無いです。

Lmbda

言語はpython。hello-world-python をテンプレに、ちゃちゃっとIAMロールとかも作りましょう。

# coding: UTF-8
from __future__ import print_function

import json
import pycurl
import urllib
import base64
import zlib
import datetime

api_token       = "チャットワークのAPIトークン"
room_id         = "ルームID"
room_message    = "https://api.chatwork.com/v1/rooms/{0}/messages".format(room_id)

def lambda_handler(event, context):
    data = zlib.decompress(base64.b64decode(event['awslogs']['data']), 16+zlib.MAX_WBITS)
    data_json = json.loads(data)
    for log in data_json["logEvents"]:
        log_json = json.loads(json.dumps(log, ensure_ascii=False))
        message = u"[info][title]なんか出たよ！！[/title]" \
            + log_json['message'] \
            + "[/info]"
        option = {'body': message}
        c = pycurl.Curl()
        c.setopt(pycurl.URL, room_message)
        c.setopt(pycurl.HTTPHEADER, ['X-ChatWorkToken:' + api_token])
        c.setopt(pycurl.POST, 1)
        c.setopt(pycurl.POSTFIELDS, urllib.urlencode(option))
        c.perform()

仕上げに、LambdaファンクションのEvent sourcesを追加します。ソースはCloudwatchLogsで、お目当てのロググループ名を指定します。

フィルタパターンを設定すれば、特定のキーワードを含んたものが来た時だけ、ファンクションを起動できます。

フィルタとパターンの構文 - Amazon CloudWatch

ChatWork

通知先ルームを用意するのと、APIトークンを用意する以外、やることは特にないです。

NG集

...というのを一発で組めたわけではなく、紆余曲折あったのですよと。

Fluentd入りのEC2 -> ChatWork

Fluentdで、in_tailと、out_chatworkの組み合わせを、最初に構築しましたが、下記の事情で諦めました。

td-agent、1系をインストール済み。1系では、fluent-plugin-out_chatworkをインストールしてみたものの、なんだか動いてる気配がない
td-agent、そもそもインストール出来ないやつがいた。32bit版AmazonLinux。
- CloudWatchLogsエージェントは、32bit版AmazonLinuxにも、スパッと入った

EC2 -> CloudWatchLogs -> Zapier -> ChatWork

CloudWatchLogsで、メトリックフィルタとアラートを設定
アラート発生をトリガーに、Zapierで、ChatWorkに通知します。

これをボツにしたのは、メトリックフィルタとアラートが「出たよ！」しかわからず、通知も「出たよ！CloudWatchLogsの画面を見に行ってね！」しか出せず、イケてないフローだったためです。

EC2 -> CloudWatchLogs -> Fluentd -> ChatWork

EC2からCloudWatchLogsにログを収集するところまでは、最終形と同じ。

Fluentdに、in_cloudwatchlog、out_chatworkの組み合わせです。

これをボツにしたのは、in_cloudwatchlogは良かったのですが、そもそもCloudWatchLogsのAPIがくっそイケてなくて、更新頻度の低いロググループからだと、同じログを何度でも返してくるため、「ログ監視」みたいなことには全く使えない代物だとわかったためです。