helen's blog

ずっとおもしろいことしてたいな。

Mackerelを起点にAmazon EventBridgeを経由してホストを削除する

MackerelのAmazon EventBridge対応が出ました

mackerel.io

AWS Black Belt でも紹介されてて、EventBridgeまわりがわかりやすく説明されています

koudenpa.hatenablog.com

物理で光るのはテンションあがってとても良い!


わたしもこれでなにかおもしろいことしたいな〜って思ってたけどネタが思いついてなくて、
そんなときにチームの人がふと
"MackerelでホストステータスをPower Offにしたらホスト退役するとか、できるか知らんけどw"
って言ってて、その考え方が自分になくておもしろいなと思って作ってみました

普段AWSでホストが起動すると、
MackerelエージェントやAWSインテグレーションでMackerelに連携されて、
ホスト退役すると自動でMackerelから消えて... とAWS起点で考えてたのですが
Mackerelを起点にホストを管理するというのが逆転的でこれいいじゃんって思いました

つくる

mackerel.io

公式ドキュメントとして手順が丁寧に書いてあるのでそのままぽちぽち設定します

よくわからなかったのがドキュメントではあまり触れられていない Event matching pattern のところで、
ちゃんと選択してSaveしてもなぜかAllで保存されちゃいました

f:id:heleeen:20200127032644p:plain

これはAWSでの設定なのですが、なんでこうなるんだろう🤔
Allでもサービス指定しても(Allで保存されるけど)問題なく動きます

ぽちぽちってするだけでMackerelのイベントとAWSのリソースが連携できるのはめっちゃ楽でいいですね

できた

github.com

とっっっても突貫でつくりました

MackerelでECS FargateのタスクのホストステータスをPower Offにすると
Mackerel -> EventBridge -> Lambda -> ECS とリクエストし、
そのタスクがストップされます

Max, Desired CountやAuto Scalingを変更するわけではないので、
たとえばDesired Countが2になっていて、1つをPower Offにすると、
一時的に1タスクになり、そのうち2つ目が起動してきます

ほんとうはこれは3つ目を立ててからStopするほうが親切ではあるのですが
勢いだけで作ってしまったのでタスクは即Stopしにいってしまいます😅

EventBridgeのTargetの設定画面の

f:id:heleeen:20200127030547p:plain

これをぽちぽちするよりLambda書いたほうが簡単そうって感じたのでLambdaにしました
ブラウザ得意になりたい

なんでFargateなのかというと、そこに動いているクラスターがあったからで、
そこに対する理由や考察は全く無いです

作ってみて

今回、MackerelでFargateで稼働しているタスクの様子を見て
違和感のあるやつはPower Offすると入れ替わるっていうシナリオを考えたのですが、
実際Fargateでそんなことあるのか?🤔 という感じです

Mackerelのグラフがきれいなので、
そのグラフからそのままアクション取れたらスムーズでいいな〜

でもこのHostなんか調子悪そうだから入れ替えたいねっていう話だと
今更だけどECSよりEC2のほうが向いていそう

あとMackerelが本来用意しているホストステータスのPower off機能に別の機能を付け加えてしまったので、
本来の用途で使おうと思ったときにびっくりしてしまうかもね

思想も実装もガバガバなくらい動く楽しさ重視で作ってみたからしょうがないね!

Mackerelのどんなイベントが起こったら何をするかという定形のアクションがあったとき、
それをコード化できるっていう部分がとても好き

SlackでMackerelのアラートの様子を見る

これは Mackerel Advent Calendar 2019 - Qiita20日目の記事です
アドベントカレンダーに登録したら部屋がきれいになった話にならなくてよかったです

こんなことありませんか?

日中ふと見かけたアラート、作業をして発生させたアラート...
あいつらちゃんと片付けたっけ?って気持ちになって寝付けなくなったりしませんか?

f:id:heleeen:20191216184934p:plain

ちなみにわたしはアラートではあまりないですけど、
乾燥機つけたっけ・・・というのはよく気になって起きて確認しに行ってます

そういえばAWSでこんなリリースがありました

aws.amazon.com

AWS ChatbotがSlackから実行できるようになりました!
SlackからLambdaが起動できるので、
いろんなことができるようになって夢が広がりますね

SlackからMackerelのアラートを見れるようにしよう!

アラートが上がったタイミングではなく、
任意のタイミングでSlackで見れたら便利かもという気持ちになって作りました

サービス名を指定して、
Slack -> Chatbot -> Lambda -> Mackerel とリクエストして、
結果をSlackにPostします

この解説こそ図示するべきかと考えたのですが、
AWS Chatbotのアイコンは配布されていませんでした
まだベータ版ってこともあるのかな

作り方

まずAWS Chatbotの設定をしていきます

f:id:heleeen:20191219001733p:plain

他の選択肢としてはAmazon Chimeがあります

f:id:heleeen:20191219002640p:plain

Slackに飛ばされるので設定します

f:id:heleeen:20191219010334p:plain

あとはLambdaの中身を実装してデプロイし、Slackから実行するだけです

できた

サービス名を指定して、
そのサービスでOpenなアラートを見れるようにしました
https://github.com/heleeen/alert_checker

f:id:heleeen:20191219132729p:plain

アラートがないときはこんな感じです
平和なときはお寿司を食べようっていう気持ちです

f:id:heleeen:20191219132056p:plain

頑張ったところはSlackにPostするためのJson作りです

できあがるまでの頑張り

サービスはアラートから取得できない

アラートのレスポンスにサービスは含まれていないので、
アラートからモニターIDを取りそれでモニターを引き... みたいなことをしています
ただ、式監視だけはモニターにもロールの設定がなく
サービスの特定ができなかったのでアラートがあっても取得できません...
式にサービス名があるかどうかを grep するくらいしか思いつきませんでした...(やってないですが...)

AWSコンソールでは実行できるのになぜかSlackから実行できない
@aws lambda invoke --payload {"service": "serviceName"} --function-name alert_checker --region ap-northeast-1

というように実行するのですが、
このPayload部分が厄介で、Macの場合、
Slackにコピペで貼り付けたり入力しようとすると
ダブルクオテーションが変換されてしまいエラーしました

f:id:heleeen:20191219011413p:plain

これはシステム環境設定で回避できますが、
他でもダブルクオテーションの向きが修正されなくなるので悩ましいですね

IAMロールの編集はIAMのコンソールから

何気なく↓を実行しようとしたところ、ReadOnlyが必要でした

@aws lambda list-functions ...

ただ、ChatbotのコンソールからIAMロールを編集できません
IAMのコンソールに移動するか、新しく作る必要があります

IAMにしゅっとつけられる体験を最初にしてしまっていたので、
ああ...IAMのコンソール出てくるんだ... という気持ちになりました

コマンドが長い

セヤネン
お布団から寝ぼけたまま打つのはきついので
Slackのほうのbotとかにいい感じにさせたほうがよさそう

Alexa, XXXのアラートを確認して!っていうのも考えたのですが、
楽しそうだけどデバッグ大変そうで諦めました...
楽しそうではあるんだけど...

なぜかLambdaコンソールでの実行は成功するのにSlackからだと返事がない

なんでだろうね

困って↓を入れました

sleep 10

https://github.com/heleeen/alert_checker/blob/master/function/lib/slack.rb#L17

クッ....なぜだ.....


APIやGemが公開されているとこういう連携が楽でいじりがいがあって楽しくていいですね
もっといじりたい

あと乾燥機つけたかどうかもSlackでわかる日がきて欲しい

Amazon QuickSightはUnsubscribeしても用意したリソースは削除されない

Amazon QuickSight というマネージドBIツールがあります

さまざまなデータソースをBIでき、
AuroraもVPC内の通信で完結させてBIすることができます

インターネットを経由させなければいけない過去は終わりました
めっちゃ便利でいいですね

aws.amazon.com

ただ、この設定をして、
QuickSightのVPC接続設定を削除せずにUnsubscribeしても、
接続設定と接続に使用したSecurity Groupなどは自動では削除されません
(当然といえば当然か・・)

その結果、

You are not allowed to manage 'ela-attach' attachments.

というエラーでVPCやENIを削除できない事態になってしまいました

再度SubscribeしてVPC接続設定を削除すると、ENIが削除できるようになりました

Unsubscribeしたからいいかと思っていたのですが、
削除できない!というエラーしか出ないのでしばらく悩まされました😇

Varnishをアップデートすると設定値が反映されなくなる

という問い合わせを受けて調べた

環境

  • CentOS 7
  • Varnish
    • 6.0.1 から6.0.3にバージョンをあげようとしている

事前確認

$ varnishd -V
varnishd (varnish-6.0.1 revision 8d54bec5330c29304979ebf2c425ae14ab80493c)
Copyright (c) 2006 Verdens Gang AS
Copyright (c) 2006-2015 Varnish Software AS

バージョン上げ

下記で実施

Install Howto

1. Install GetPageSpeed repository:
# yum install https://extras.getpagespeed.com/release-el7-latest.rpm

2. Install varnish rpm package:
# yum install --enablerepo=getpagespeed-extras-varnish60 varnish

centos.pkgs.org

こうなる

$ varnishd -V
varnishd (varnish-6.0.3 revision 7d1ded3aa033a018317dbafc61587026ea2ef8a3)
Copyright (c) 2006 Verdens Gang AS
Copyright (c) 2006-2019 Varnish Software AS

このあとに再起動するとなぜか /etc/varnish/varnish.params が反映されなくなる

book.varnish-software.com

↑ だとバージョンは古いけど、
CentOSなら /etc/varnish/varnish.params が読まれるみたいなのになぁ

原因

/lib/systemd/system/varnish.service の ExecStart が変わってる!!

before
[Unit]
Description=Varnish Cache, a high-performance HTTP accelerator
After=network.target

[Service]
# If you want to make changes to this file, please copy it to
# /etc/systemd/system/varnish.service and make your changes there.
# This will override the file kept at /lib/systemd/system/varnish.service
#
# Environment variables may be found in /etc/varnish/varnish.params
#

# Maximum number of open files (for ulimit -n)
LimitNOFILE=131072

# Locked shared memory (for ulimit -l)
# Default log size is 82MB + header
LimitMEMLOCK=85983232

# On systemd >= 228 enable this to avoid "fork failed" on reload.
#TasksMax=infinity

# Maximum size of the corefile.
LimitCORE=infinity

EnvironmentFile=/etc/varnish/varnish.params

Type=forking
PIDFile=/var/run/varnish.pid
PrivateTmp=true
ExecStart=/usr/sbin/varnishd \
	-P /var/run/varnish.pid \
	-f $VARNISH_VCL_CONF \
	-a ${VARNISH_LISTEN_ADDRESS}:${VARNISH_LISTEN_PORT} \
	-T ${VARNISH_ADMIN_LISTEN_ADDRESS}:${VARNISH_ADMIN_LISTEN_PORT} \
	-S $VARNISH_SECRET_FILE \
	-s $VARNISH_STORAGE \
	$DAEMON_OPTS

ExecReload=/usr/sbin/varnish_reload_vcl

[Install]
WantedBy=multi-user.target
after
[Unit]
Description=Varnish Cache, a high-performance HTTP accelerator
After=network-online.target

[Service]
Type=forking
KillMode=process

# Maximum number of open files (for ulimit -n)
LimitNOFILE=131072

# Locked shared memory - should suffice to lock the shared memory log
# (varnishd -l argument)
# Default log size is 80MB vsl + 1M vsm + header -> 82MB
# unit is bytes
LimitMEMLOCK=85983232

# Enable this to avoid "fork failed" on reload.
TasksMax=infinity

# Maximum size of the corefile.
LimitCORE=infinity

ExecStart=/usr/sbin/varnishd -a :6081 -f /etc/varnish/default.vcl -s malloc,256m
ExecReload=/usr/sbin/varnishreload

[Install]
WantedBy=multi-user.target

Release Noteには何もなかった
なんだったんだろう

原因がわかるとなんだそれだけかってなるね

DatadogでCouchbaseの死活監視を構築する

超ピンポイントなネタだけどわたしには難易度が高かった..

概要

DatadogでのService CheckにAlertを設定するまでがなかなか独特で
今後も使うのに忘れちゃいそうと思ったのでメモします

詳細

環境

  • AWS
  • CouchbaseをEC2へインストールしクラスタ構成にする
  • Datadong Agent(v6.10.2)を同様にインストールしてモニタリング

Couchbaseとは

  • ドキュメント型NoSQL
  • JSONが扱える
  • Enterprise版はAMIが提供されている

docs.couchbase.com

わたしのところではPackerでコミュニティ版をインストールしたAMIを作成して運用しています

やりたかったこと

  • CouchbaseをインストールしたEC2ホストの監視
  • Target GroupのHealthyHostの数ではなく、ホストでCouchbaseが元気にしているかを見たい

AWSでは不定期にEC2インスタンスがメンテナンスされます
それによってインスタンス入れ替えが発生し、
Couchbaseクラスタからノードが切り離されたままになる事態が発生しました
(本番環境での事件でなくてとてもよかった!!!)

この時、Couchbaseインストール済みのAMIだったので
再起動後にもHealthHostにはカウントされていたのですが、
構築済みだったクラスタからは外れてしまい
クラスタとしてはノードがダウンした状態になっていました

これがHealth HostではなくCouchbase Hostとしての監視をしていれば検知できたのでは?と考えました

Datadogでどのように監視できるのか?

そのホストのCouchbase ServerにDatadog Agentが接続できるかで判定します
該当するメトリクスは couchbase.can_connect です
couchbase.by_node.health_status でもノードがダウンしたときに取れそうなのですが、
すべてのノードでエージェントが可動していると
自分以外のノードも監視対象になっていてノード数 * ノード数の監視になりそうだったので
今回は couchbase.can_connect で監視することにしました

docs.datadoghq.com

他のメトリクスに比べてService Checkは設定が難しかった..

1つ目のハマりポイント: couchbase.can_connect をコンソール上で見つけられない

Metrics Explorerで見れるだろうと思ったら見つけられず...

メトリクスの検索画面

メトリクスとしては検索できず、Monitors -> Check summary内にある

service checkの有りか

Service Checkなので見方としてもメトリクスではなく監視扱いなのかな?

docs.datadoghq.com

2つ目のハマりポイント: couchbase.can_connect のアラートが設定できない

Datadog AgentでCouchbaseの監視設定をすると、
自動的にCouchbase Integrationがオンになります

なので New Monitor -> Integration で
couchbase.can_connect に対して監視を設定しようと思ったのですが、
対象の値を見つけられませんでした

アラート設定画面

Service Checkに対して監視設定を入れるには
実はIntegration Statusタブに切り替える必要がありました

Service Checkの探し方

たしかにドキュメントを見るとReturn Criticalになっていて、
他と設定が違いそうな雰囲気にも見える

- couchbase.can_connect:
Returns Critical if the Agent cannot connect to Couchbase to collect metrics.

なかなか道のりは長かったけど、Supportの方にとても親切に対応してもらえてとても助かった
これでService Checkはマスターしたぞ!たぶん!