helen's blog

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

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

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

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

# こういうとき
$ 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を止めるには

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も変更され、
2つのパラメータで管理されているそうです

つまり

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 にしておけば
改めて再起動は不要になる(スケールダウン作業中に適応される)のは学びでした

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

Mackerelコンテナエージェントをちょっとだけ触りました

mackerel.io

待望の機能がリリースされてたのでちょっとだけ試します

用意したもの

  • Mackerel (しかもアンバサダーだよ!!!🌸😏🌸)
  • AWS Fargate 一式
    • なにかの検証で作って放置してたのを使いまわします
  • https://hub.docker.com/r/kennethreitz/httpbin/
    • お手軽に status 200 を用意するのによく使わせてもらっているやつ

手順

mackerel.io

サイドカーでコンテナエージェントを起動するだけなのでめっちゃ簡単
APIキーはパラメータストアとかで入れたほうが良さそう

起動する

AWS

f:id:heleeen:20190219005842p:plain

起動してるタスクが1つ

Mackerel

f:id:heleeen:20190219010227p:plain

タスクIDをホスト名としてタスク単位で登録される
設定項目にも見当たらないから手で入れるしかないのかな・・?

Fargate instance info

テーブルの一番右に気になるものがありました

Cluster	arn:aws:ecs:ap-northeast-1:ACCOUNT_ID:cluster/test
Task	32b720e1-b1f2-47e7-9b72-f8ae8ab30cee
Task Family	test
Task Version	6
Task ARN	arn:aws:ecs:ap-northeast-1:ACCOUNT_ID:task/32b720e1-b1f2-47e7-9b72-f8ae8ab30cee

Containers
Name: httpbin
Docker Name: ecs-test-6-httpbin-809d8593fab9ddd29101
Docker ID: 8aab519510a34f27de12b330861c615b60277b2ae26f0f73c7cd36da249acce7

Name: ~internal~ecs~pause # なんだこれ
Docker Name: ecs-test-6-internalecspause-d8c98efc81faf4d5a501
Docker ID: cfe07bc7071f847d01c7997016c6103af2e825303aeefb7cfac976faffbf3963

Name: mackerel-container-agent
Docker Name: ecs-test-6-mackerel-container-agent-bcdab3c995fffaecc401
Docker ID: 2246210032f1f619fb81d418df2bcd38c84d01134660a8200787213d4cf3f254

Known status	RUNNING
Desired status	RUNNING

httpbin が検証用につかっているstatus 200を返してくれるコンテナ、
mackerel-container-agent がコンテナエージェント、
~internal~ecs~pause は特に何か操作したものではありません

~internal~ecs~pause とは

aws.amazon.com

ネットワークスタックとアプリケーションコンテナのコマンドが競合しないように
まずECSエージェントがコンテナ開始前にpauseコンテナをタスクごとに作成する
次にCNIプラグインを実行してpauseコンテナの名前空間を用意し、
タスク定義内のコンテナを起動してpauseコンテナのネットワークスタックを共有する
タスク定義内のすべてのコンテナがENIによるIPアドレスを指定でき、
localhostで通信することができることを表す

なるほど?

グラフ

CPU

一番Poorなスペックでこれ
コンテナエージェントが全然CPU消費してない👀

f:id:heleeen:20190219025559p:plain

Memory

メモリも同様
だけどpauseコンテナが地味に存在感を出していて侮れないなぁ

f:id:heleeen:20190219025730p:plain

Mackerelコンテナエージェントの
設定ファイルがWeb経由やS3配置で取れるのがおもしろくて
apikeyがなければGitHubに設定ファイル入れてRawで取得して使えそう🤔