Mackerel を AWS CloudFormation を管理できる cfn-mackerel-macro を見つけたので、example.yaml を AWS CDK に変換してみた。
AWS CDK に対応するクラスが存在しないので、CfnResource クラスを使うことになるため、自動補完機能が使えないのが辛い……。なので、Construct Library を作成したほうが良さそうかもしれない。
Mackerel を AWS CloudFormation を管理できる cfn-mackerel-macro を見つけたので、example.yaml を AWS CDK に変換してみた。
AWS CDK に対応するクラスが存在しないので、CfnResource クラスを使うことになるため、自動補完機能が使えないのが辛い……。なので、Construct Library を作成したほうが良さそうかもしれない。
この記事は Mackerel Advent Calendar 2020 の6日目の記事です。
Mackerel ではカスタムメトリックプラグインを利用することで自分たちに必要なミドルウェアのメトリックを収集できることだと考えています。Mackerel エージェントをインストールした状態ではシステムメトリックのみの取集となるため、必要なミドルウェアのメトリックを取集するためには、カスタムメトリックプラグインを利用することになるのです。カスタムメトリックは下記から探すことができると思います。
有益なカスタムメトリックプラグインがいろいろとあるのですが、ホストに紐づくカスタムメトリックではなく、サービスに紐づくサービスメトリックに連携したい思うことがたまにあります。どのような方法があるののかを考えていたときに、Mackerel の CRE である @a-know さんが mackerel-remora を使うことを思いつきました。
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 が収集した温度や湿度が連携されるようになります。
Mackerel のカスタムメトリックプラグインをサービスメトリックに連携するために mackerel-remora を使ってみました。今回は Docker Compose でホストディレクトリをマウントして、設定ファイルとプラグインを読み込みましたが、Docker イメージ内にそれらを含めることで AWS Fargate などでも動かすことができると思います。
Mackerel のロール内異常検知がやっとリリースされましたね。
早速設定してみましたが、この機能は難しいと感じました。これまでの監視ルールでは CPU の使用率が70%を超えた場合はワーニング、90%を超えた場合はクリティカルとするという直感的(職人芸?)の設定が出来たと思います。でも、異常検知ではこのようなことが出来ず、センシティビティというものを選択する必要があります。このセンシティビティをどのように設定するべききを考える必要があるのですが、ヘルプページの説明を読んでもよく分からないと感じました。
Sensitivity: sensitiveのほうが小さな変化に反応しやすくなります。大きな変化のみアラートを発報したい場合、insensitiveを設定してください
過去のデータをもとに sensitive を設定した場合はこういったときにアラートが発生、insensitive を設定した場合はこういったときにアラートが発生するというのが、監視ルールを作成するときに把握できればいいと思います。でも、現状はそのようなことが出来ないため、始めは sensitive で監視ルールを作成して、アラートが発生するけど、サービスへの影響が問題ないと判断することが出来れば、normal や insensitive に変更するのがいいかなと思います。
Mackerel アンバサダーに就任したので mackerel-plugin-elasticsearch-cluster-stats をつくった。
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 エージェントを再起動して、しばらくすると下記のような感じでグラフが作成されるはずである。
この記事は Mackerel Advent Calendar 2017 の22日目の記事です。
今年の2月頃から仕事で Mackerel を使い出して、下記のプラグインを作成した。
プラグインの作成を振り返ってみても良かったけど、仕事で携わっているサービスは Ruby on Rails で開発しており、デプロイに Capistrano を使っているので、Mackerel と Capistrano の連携方法について書くことにした。
Mackerel のヘルプにも連携方法が書かれているが、Capistrano 2.x を前提としているため Capistrano 3.x で同じことをやろうとすると、少し修正が必要である。
まずは Capfile
で mackerel-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 になっているホストに対してデプロイが実行されるようになる。
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
この状態でデプロイすると、下記のようにグラフアノテーションが投稿される。
デプロイしたリビジョンをもとに GitHub のコミットログへのリンクを生成しているので、どの時点で何をデプロイしたかも分かるので便利である。
Resque で非同期処理をすることが多いので、Mackerel のサービスメトリックで Resque のキュー数を可視化してみた。
各キューごとのキュー数と、その合計値をサービスメトリックで登録するようにしている。
cron で1分毎に実行するようにする。
Mackerel Drinkup #4 Tokyo で LT をしてきた。
LT の内容は mackerel-plugin-aws-waf の紹介(公式プラグイン集のひとつになりました)。作成経緯や苦労した点について。AWS WAF 自体の説明は大雑把にしかしていないので、この発表資料は参考にしないほうがいいかも……
久しぶりの発表だったので緊張したし、スライドのフォントサイズが小さかったりと個人的に反省点もあったけど、Mackel の開発者が直接フィードバックをもらうことができたので楽しい時間だった。
LT のご褒美に Mackerel グラスをもらったので、大切に使いたいと思う。