helen's blog

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

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

AWS

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をアップデートすると設定値が反映されなくなる

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 Couchbase Monitoring

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

概要

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はマスターしたぞ！たぶん！

なぜか公式ドキュメントのどのコマンドでもDatadog Agentが再起動できない

Datadog

全部試してだめだったときにとても困っちゃったよね

# こういうとき
$ sudo service status datadog-agent
status: 認識されていないサービスです。

Datadog Agent の公式ドキュメント

docs.datadoghq.com

やってたこと

Amazon Linuxを使用しているので下記でインストールします

DD_API_KEY=<YOUR_API_KEY> bash -c "$(curl -L https://raw.githubusercontent.com/DataDog/datadog-agent/master/cmd/agent/install_script.sh)"

これはDatadogにログインして表示されるコマンドです
https://app.datadoghq.com/account/settings#agent/aws

これでインストールするとなぜか公式ドキュメントのどのコマンドでも再起動できない
どうしたものか・・と思ってルートディレクトリを見ると
ddagent-install.log というファイルが存在することに気づきました

そのファイルをぼんやり眺めると・・

Your Agent is running and functioning properly. It will continue to run in the
background and submit metrics to Datadog.

If you ever want to stop the Agent, run:

    sudo stop datadog-agent

And to run it again run:

    sudo start datadog-agent

見たことないコマンドだ・・・と思って実行すると停止と起動ができます

$ which datadog-agent
/usr/bin/datadog-agent

こういうことのようだ

ちなみに

$ ls /usr/bin/dd-agent
/usr/bin/dd-agent

こういうのもいたけど

$ dd-agent status
The deprecated binary 'dd-agent' is no longer provided. 
Please use the 'datadog-agent' binary instead.

でもこういうふうに怒られる

コマンドの順序を入れ替えて datadog-agent start とかするとコンソールを奪われる😇

よく見るとおもしろいね

Amazon Auroraでレプリケーションのために出力していたbinlogを止めるには

AWS Aurora

AuroraをオンプレミスのMySQLとレプリケーションしていたけど
それが不要になってお片付けをしていたら
想定外のところで詰まってしまいサポートに問い合わせました

Auroraとのレプリケーション方法

binlogを出力する

公式に手順があります

docs.aws.amazon.com

クラスタのパラメータグループで binlog_format を ROW, STATEMENT, MIXEDのどれかにします
設定の反映にはAuroraクラスタの再起動が必要です

レプリケーションの撤去

binlogを停止する

先の手順にあるように、クラスタのパラメータグループで binlog_format を OFF にします
同様に反映にはAuroraクラスタの再起動が必要です

レプリケーション自体は STOP SLAVE; で止まるのですが、
binlogを出力しているとAuroraの性能に影響がでてしまうため
必要なくなったのであれば止めておくべきです

うまくいかなかった

わたしのところでは、今回、binlog_formatをMIXEDにしていました
クラスタのパラメータグループを編集し、
再起動など諸々を実施してもOFFになりませんでした

# なぜか STATEMENT になる
# もちろん再起動前はMIXEDでした
mysql> SHOW VARIABLES LIKE 'binlog_format';
+---------------+-----------+
| Variable_name | Value     |
+---------------+-----------+
| binlog_format | STATEMENT |
+---------------+-----------+
1 row in set (0.00 sec)

# 停止しているかのようなメッセージは出る
mysql> show binary logs;
ERROR 1381 (HY000): You are not using binary logging

サポートさんに問い合わせるまでに実施したこと

どれも状況は変わりませんでした

問い合わせた結果

  • binlog_format にOFFを設定すると log-bin は無効になる
  • ただし、 binlog_format の設定値によらず無効になっている
  • SHOW VARIABLES LIKE 'log_bin' が OFF になっていれば良い

とてもややこしいけれど、
binlog_formatを変更するとlog_binも変更され、
２つのパラメータで管理されているそうです

つまり

binlog_format は OFF になっていないけどbinlogは停止できていた！

mysql> SHOW VARIABLES LIKE 'log_bin'\G
*************************** 1. row ***************************
Variable_name: log_bin
        Value: OFF
1 row in set (0.00 sec)

サポートさんに確認してよかった〜

log_bin がOFFになっているのを見ても
binlog_format が OFF にならないんですけど！？ って問い合わせしちゃいそう😅

おまけ

今回、レプリケーションのためのbinlog停止とともに、
Auroraインスタンスのスケールダウンとファミリー変更を行いました

事前に binlog_format を OFF にしておけば
改めて再起動は不要になる（スケールダウン作業中に適応される）のは学びでした

再起動の瞬断とはいえ、サービスのダウンする瞬間を減らせてよかった😊