AWS CDK で cfn-mackerel-macro を使ってみる

Mackerel を AWS CloudFormation を管理できる cfn-mackerel-macro を見つけたので、example.yaml を AWS CDK に変換してみた。

AWS CDK に対応するクラスが存在しないので、CfnResource クラスを使うことになるため、自動補完機能が使えないのが辛い……。なので、Construct Library を作成したほうが良さそうかもしれない。

Mackerel のカスタムメトリックプラグインをサービスメトリックに連携

この記事は Mackerel Advent Calendar 2020 の6日目の記事です。

Mackerel ではカスタムメトリックプラグインを利用することで自分たちに必要なミドルウェアのメトリックを収集できることだと考えています。Mackerel エージェントをインストールした状態ではシステムメトリックのみの取集となるため、必要なミドルウェアのメトリックを取集するためには、カスタムメトリックプラグインを利用することになるのです。カスタムメトリックは下記から探すことができると思います。

有益なカスタムメトリックプラグインがいろいろとあるのですが、ホストに紐づくカスタムメトリックではなく、サービスに紐づくサービスメトリックに連携したい思うことがたまにあります。どのような方法があるののかを考えていたときに、Mackerel の CRE である @a-know さんが mackerel-remora を使うことを思いつきました。

github.com

blog.a-know.me

mackerel-remora ではカスタムメトリックプラグインの出力形式でサービスメトリックに連携してくれる素晴らしいツールです!

今回は mackerel-plugin-nature-remo をサービスメトリックに連携してみることにしました。

連携方法

mackerel-remora では Docker イメージが公開されているので、Docker Compose で起動することにしました。

適当なディレクトリに設定ファイルとプラウグインを下記のように配置します。

├── config.yml
├── docker-compose.yml
└── plugins
    └── mackerel-plugin-nature-remo_linux_amd64
        ├── README.md
        └── mackerel-plugin-nature-remo

config.yml は下記のような内容です。

apikey: {{ Mackrel の API キー }}
plugin:
  servicemetrics:
    home:
      nature-remo:
        command: /app/plugins/mackerel-plugin-nature-remo_linux_amd64/mackerel-plugin-nature-remo -access-token {{ Nature Remo のアクセストークン }}

また、docker-compose.yml は下記のような内容です。

version: '3'
services:
  remora:
    image: aknow/mackerel-remora:latest
    restart: always
    volumes:
      - .:/app
    environment:
      MACKEREL_REMORA_CONFIG: /app/config.yml

そして、Docker コンテナーを起動します。

$ docker-compose up -d

しばらくすると、サービスメトリックに Nature Remo が収集した温度や湿度が連携されるようになります。

f:id:holidayworking:20201202204058p:plain

まとめ

Mackerel のカスタムメトリックプラグインをサービスメトリックに連携するために mackerel-remora を使ってみました。今回は Docker Compose でホストディレクトリをマウントして、設定ファイルとプラグインを読み込みましたが、Docker イメージ内にそれらを含めることで AWS Fargate などでも動かすことができると思います。

Mackerel のロール内異常検知に対する所感

Mackerel のロール内異常検知がやっとリリースされましたね。

mackerel.io

早速設定してみましたが、この機能は難しいと感じました。これまでの監視ルールでは CPU の使用率が70%を超えた場合はワーニング、90%を超えた場合はクリティカルとするという直感的(職人芸?)の設定が出来たと思います。でも、異常検知ではこのようなことが出来ず、センシティビティというものを選択する必要があります。このセンシティビティをどのように設定するべききを考える必要があるのですが、ヘルプページの説明を読んでもよく分からないと感じました。

Sensitivity: sensitiveのほうが小さな変化に反応しやすくなります。大きな変化のみアラートを発報したい場合、insensitiveを設定してください

過去のデータをもとに sensitive を設定した場合はこういったときにアラートが発生、insensitive を設定した場合はこういったときにアラートが発生するというのが、監視ルールを作成するときに把握できればいいと思います。でも、現状はそのようなことが出来ないため、始めは sensitive で監視ルールを作成して、アラートが発生するけど、サービスへの影響が問題ないと判断することが出来れば、normal や insensitive に変更するのがいいかなと思います。

mackerel-plugin-elasticsearch-cluster-stats をつくった

Mackerel アンバサダーに就任したので mackerel-plugin-elasticsearch-cluster-stats をつくった。

github.com

背景

Mackerel の AWS インテグレーションで Amazon Elasticsearch Service を監視しているけど、対応しているメトリックでは fielddata や Query Cache がどれぐらいメモリーを確認することが出来ない状態である。CloudWatch でこれらのメトリックが取得できるようになれば良いのだけど……。

mackerel-plugin-elasticsearch を使う方法も考えたけど、このプラグインは Amazon Elasticsearch Service が対応していない Node Stats でメトリックを取得しているため、このプラグインを使うことを断念した。

Node Stats と同様のメトリックが取得できそうである Cluster Stats は Amazon Elasticsearch Service で対応しているので、Cluster Stats から必要なメトリックを取得するプラグインを作成することにした。

使い方

mkr plugin install でインストールできるようになっているので、このプラグインを実行するサーバーで下記のコマンドを実行する。

$ mkr plugin install mackerel-plugin-elasticsearch-cluster-stats

Mackerel エージェントの設定ファイルに下記を追加する。

[plugin.metrics.elasticsearch-cluster-stats]
command = "/opt/mackerel-agent/plugins/bin/mackerel-plugin-elasticsearch-cluster-stats [-scheme=<'http'|'https'>] [-host=<host>] [-port=<port>] [-metric-key-prefix=<prefix>] [-tempfile=<tempfile>]"

Mackerel エージェントを再起動して、しばらくすると下記のような感じでグラフが作成されるはずである。

f:id:holidayworking:20190221195838p:plain

Mackerel と Capistrano の連携方法

この記事は Mackerel Advent Calendar 2017 の22日目の記事です。

今年の2月頃から仕事で Mackerel を使い出して、下記のプラグインを作成した。

プラグインの作成を振り返ってみても良かったけど、仕事で携わっているサービスは Ruby on Rails で開発しており、デプロイに Capistrano を使っているので、Mackerel と Capistrano の連携方法について書くことにした。

デプロイ対象のホストを Mackerel から取得

Mackerel のヘルプにも連携方法が書かれているが、Capistrano 2.x を前提としているため Capistrano 3.x で同じことをやろうとすると、少し修正が必要である。

まずは Capfilemackerel-client を読み込むようにする。

require "capistrano/setup"

require "capistrano/deploy"

require "capistrano/scm/git"
install_plugin Capistrano::SCM::Git

require "capistrano/rbenv"
require "capistrano/bundler"
require "capistrano/rails/assets"
require "capistrano/rails/migrations"

require 'mackerel/client'

Dir.glob("lib/capistrano/tasks/*.rake").each { |r| import r }

そして、config/deploy/production.rb で Mackerel からデプロイ対象のホストを取得するようにする。

set :mackerel_api_key, ENV.fetch('MACKEREL_API_KEY')

def host_ip_addrs(role)
  client = Mackerel::Client.new(mackerel_api_key: fetch(:mackerel_api_key))

  hosts = client.get_hosts(service: fetch(:application), roles: role).select do |host|
    host.status == 'standby' || host.status == 'working'
  end

  hosts.map do |host|
    interface = host.interfaces.find { |i| i['name'].match(/^eth/) }
    interface['ipAddress'] if interface
  end.compact
end

role :app, host_ip_addrs(:app)
role :web, host_ip_addrs(:app)
role :db,  host_ip_addrs(:app)

これで、ステータスが working または standby になっているホストに対してデプロイが実行されるようになる。

デプロイ時に Mackerel のグラフアノテーションへ投稿

config/deploy/production.rb に下記をすると、グラフアノテーションへ投稿することが出来る。

namespace :deploy do
  task :starting do
    set :deploy_started_at, Time.now.to_i
  end

  task :finished do
    deploy_finished_at = Time.now.to_i
    annotation = {
      title: 'deploy application',
      description: "link: https://github.com/holidayworking/#{fetch(:application)}/commit/#{fetch(:current_revision)}",
      from: fetch(:deploy_started_at),
      to: deploy_finished_at,
      service: fetch(:application)
    }
    client = Mackerel::Client.new(mackerel_api_key: fetch(:mackerel_api_key))
    client.post_graph_annotation(annotation)
  end
end

この状態でデプロイすると、下記のようにグラフアノテーションが投稿される。

f:id:holidayworking:20171220090226p:plain

デプロイしたリビジョンをもとに GitHub のコミットログへのリンクを生成しているので、どの時点で何をデプロイしたかも分かるので便利である。

Mackerel のサービスメトリックで Resque のキュー数を可視化してみる

Resque で非同期処理をすることが多いので、Mackerel のサービスメトリックで Resque のキュー数を可視化してみた。

ソースコード

各キューごとのキュー数と、その合計値をサービスメトリックで登録するようにしている。

使い方

cron で1分毎に実行するようにする。

結果

f:id:holidayworking:20171008103215p:plain

f:id:holidayworking:20171008103223p:plain

Mackerel Drinkup #4 Tokyo で LT をしてきた

Mackerel Drinkup #4 Tokyo で LT をしてきた。

mackerelio.connpass.com

LT の内容は mackerel-plugin-aws-waf の紹介(公式プラグイン集のひとつになりました)。作成経緯や苦労した点について。AWS WAF 自体の説明は大雑把にしかしていないので、この発表資料は参考にしないほうがいいかも……

久しぶりの発表だったので緊張したし、スライドのフォントサイズが小さかったりと個人的に反省点もあったけど、Mackel の開発者が直接フィードバックをもらうことができたので楽しい時間だった。

LT のご褒美に Mackerel グラスをもらったので、大切に使いたいと思う。