zuntan02のはてなブログ

備忘録的なものです。時々職場の技術者ブログにも転記してますが、メインはこちらで。

zabbixのアラートをslackに飛ばせなかった→自分自身にhttp(s)アクセス許可したら解決したメモ

【問題解決サマリ】

bageljp/zabbix-slack
https://github.com/bageljp/zabbix-slack/blob/master/slack.sh
を使ってzabbixのアラートをslackに飛ばそうとしたところ、shは叩かれているがタイムアウトした。
自分自身にhttp(s)アクセス許可したら解決した

【問題詳細】

Zabbixがalertを飛ばすタイミングで以下のようにプロセス自体はできているが、最終的にメッセージが飛んでいない状態だった

zabbix    8952  0.0  0.0 115224  3092 ?        S    17:18   0:00 /bin/bash -x /usr/lib/zabbix/alertscripts/slack.sh #alerttest ** alerttest_NG: Too many processes running on...

zabbixserverが自分自身にhttpsリクエストできないのが問題だった。
AWS EC2インスタンスで動作させていたため、セキュリティグループで自身のIPからの接続を許可したところ問題なくslackへのalertが届いた

【インストールメモ】

【参考手順】

https://qiita.com/wapa5pow/items/2327561493015a833c97
https://github.com/bageljp/zabbix-slack
https://qiita.com/tdkaoru/items/7ad9e28cf592f10849df

# アラートスクリプトの置き場所を確認する

grep AlertScripts /etc/zabbix/zabbix_server.conf
→AlertScriptsPath=/usr/lib/zabbix/alertscripts

# インストール

cd /usr/local/share/zabbix/alertscripts
wget https://raw.githubusercontent.com/bageljp/zabbix-slack/master/slack.sh
chmod a+x slack.sh

# slackのwebhookURLを用意
slackのアカウント、チャンネルをご用意いただいた上で
https://my.slack.com/services/new/incoming-webhook
でwebhookURLを取得しておきます。

# slack.shを編集

slack_url='https://hooks.slack.com/services/XXX/XXXX/XXXXX'
zabbix_baseurl="http://zabbix.example.com"
zabbix_username="yourzabbixusername"
zabbix_password="zabbixpassword"

# Zabbixがスクリプトを利用してアラートを通知するように設定する
(以下省略、上記参考手順をご確認下さい)

【AWS】請求額をプロジェクトごとに確認したい(CUR)

【経緯】

これまでプロジェクトごとの請求額を請求明細レポート (DBR)により受けていたが、「AWS Cost & Usage Reports の使用を強くお勧めします」とのことであるためこちらに変更した。

【手順】

1)ユーザ定義タグをリソースに関連付ける

既にいくつかのリソースタグがEC2インスタンスなどに設定されている前提

2)AWS 生成コスト配分タグを有効化

[請求ダッシュボード]-[Cost Management]-[コスト配分タグ]

  • AWS 生成コスト配分タグを[有効化]
  • ユーザー定義のコスト配分タグで配分したいタグを指定して[有効化]

→ステータスがActiveになればOK
f:id:zuntan02:20190417140647p:plain

3)コスト配分レポートを配置するためにS3バケットを用意

EC2ダッシュボード-[S3]-[バケットを作成する]、あとは初期値のまま作成
バケットポリシーについては後ほど設定します

4)AWS のコストと使用状況レポートで[レポートの作成]

[請求ダッシュボード]-[Cost Management]-[Cost & Usage Reports]-[レポートの作成]
・レポート名
・[S3 バケット] で、先に作成したS3バケットを指定。ポリシーが適用されるので権限に問題ない事を確認。
上記以外基本的にはデフォルトでそのまま進める。
f:id:zuntan02:20190417140541p:plain
f:id:zuntan02:20190417140631p:plain

5)請求レポート確認

24時間時間経過後S3バケットを確認

以上

【AWS】カード支払いが拒否されて支払いできなかった

【問題】

20個位あるAWSアカウントのクレジットカードを一気に別カードに乗り換えたところ、9日になってカード会社から不正利用が疑われるとの連絡があった。支払いをしてもらってよいとの連絡をしたが、AWSのマネージドコンソールから[マイ請求ダッシュボード]-[お支払い履歴]を見ると、請求失敗となっていた。

【解決】

カード会社にはこの手の請求について支払いしてよい旨連絡をおこなっており、放置しておけば次回の請求(請求対象月の翌月の8日、12日、16日、20日、28日頃)で請求が成功すると思われるが、念のため手動でお支払い履歴より再決済を実施した。

【再決済成功時のメール】

Title:Thank you for your payment

Dear Amazon Web Services Customer,
We have successfully charged the amount of XXX,XXX JPY you attempted to pay on Apr 9, 20XX.

Below are the details:

AWS Account Number: XXXXXXXXXXXX

Successful charges

Billing Date   Description                   Amount
04/03/20XX   Amazon Web Services charges   XXX,XXX JPY
                                           --------------
Total                                      XXX,XXX JPY
(以下略)

翌朝くらいにこんなメールが来ていれば再決済成功。

【参考】

https://aws.amazon.com/jp/aws-jp-faq/

Q. クレジットカードの支払(決済)に失敗した場合、どうしたら良いですか?

まずはお支払い方法にご登録いただいているクレジットカード情報に誤りがないか、あるいは有効期限内かどうかをご確認ください。 クレジットカード決済が通らなかった原因が不明な場合は、お手数ですがご利用のクレジットカード会社へ直接ご連絡ください。
クレジットカードの失敗につきまして、クレジットカード会社と解決いただけましたら、お支払履歴から再決済を実施してください。(AWSサポートセンター「アカウントおよび請求サポート」窓口でも、再決済を承っております。)

※ 月額利用料の決済が通らない場合、請求対象月の翌月に何度か(8日、12日、16日、20日、28日頃)自動再決済が行われます。
リザーブインスタンスの前払い金など一部お客様にて再決済を実施いただけないものもあります。ご自身で再決済いただけない場合には、サポートセンターよりAWSサポートセンター「アカウントおよび請求サポート」へご連絡ください。

やれやれだ。

【qmail】AmazonLinux+qmail+vpopmail+qmailadmin+autorespondで、autorespondの日本語文字化け対策

【問題】

AmazonLinux+qmail+vpopmail+qmailadmin+autorespondで作られているメールサーバで、autorespondが返す本文/自動返信に引用されるメール本文が文字化けする。
メッセージをqmailadminで作成した場合に起こるが、これはqmailadmineucベースであるため。

【解決サマリ】

1)本文の文字化け

qmailadminで生成された
/home/vpopmail/domains/hoge.com/user/vacation/message
(EUC-JP (LF))をメール標準(※)の文字コードISO-2022-JP」に変換することで解決。
※メールの文字コードは歴史的経緯よりISO-2022-JPがデフォルトとされている
【参照】https://ja.wikipedia.org/wiki/ISO-2022-JP

2)引用文の文字化け

文字化け対策は不可能と思われたため、.qmailで記載されているautorespondのコマンド引数について、オプション(末尾に 0)をつけて送信元のメールを引用させないことで回避した。

【環境】

OS:Amazon Linux AMI
LANG:en_US.UTF-8

qmail:qmail-1.03
qmailadmin:qmailadmin-1.2.16
autorespond:autorespond-2.0.5
vpopmail:popmail-5.4.33

【詳細】

1)不在通知設定

qmailadminで不在通知設定を有効とし、不在通知の本文として以下の内容を作成。

お問い合わせいただきありがとうございます。
確認次第、担当の者より回答をさせていただきます。

※本メールは送信専用です。返信にはご回答できません。
2)文字コード変換

メールサーバにSSHログインし、上記返信ドキュメントが
/home/vpopmail/domains/hoge.com/user/vacation/message
として配置されているので、不要なタイトル、送信元などを削除して本文のみとしたのち、nkf(※)を使用して文字コードISO-2022-JPに変換

nkf -j --overwrite /home/vpopmail/domains/hoge.com/user/vacation/message

# 上記処理で権限が変わってしまうので以下の対応も行う

chown vpopmail:vchkpw /home/vpopmail/domains/hoge.com/user/vacation/message

nkfがインストールされていない場合は以下の手順でインストール

wget http://mirror.centos.org/centos/6/os/x86_64/Packages/nkf-2.0.8b-6.2.el6.x86_64.rpm
yum localinstall nkf-2.0.8b-6.2.el6.x86_64.rpm

【参照】
文字コード変換コマンドの nkfの使い方と実例をまとめました。 - それマグで!

3)autorespondの本文添付をOFFにする

不在通知設定ONの際にqmailadminにより生成されている.qmail(/home/vpopmail/domains/hoge.com/user/直下)の末尾に「0」を追記
ついでに返信回数上限を3→30位にあげとく

/home/vpopmail/domains/hoge.com/user/Maildir/
| /usr/bin/autorespond 86400 30 /home/vpopmail/domains/hoge.com/user/vacation/message /home/vpopmail/domains/hoge.com/user/vacation 0


以上で、(とりあえず)自動応答時の文字化けはなくなったかと思います。

【autorespondのオプション】

# autorespond -h

autorespond: usage: time num message dir [ flag arsender ]

time - amount of time to consider a message (in seconds)
num - maximum number of messages to allow within time seconds
message - the filename of the message to send
dir - the directory to hold the log of messages

optional parameters:

flag - handling of original message:

0 - append nothing
1 - append quoted original message without attachments <default>

arsender - from address in generated message, or:

+ = blank from envelope !
$ = To: address will be used

ニンテンドースイッチのジョイコンのスティック交換メモ

【問題】

ゲーム中にスティックが一方向に入り続ける状態になった。

【確認】

[HOMEメニュー]-[設定]-[コントローラーとセンサー]-[スティックの補正]
で左右のコントローラのスティックを確認してみたところ、右側のコントローラのスティックが下に入り続けている模様

【交換】

■交換部品の注文

今回は
Switch NS Joy-con対応 Joy-Con for Switch コントロール 右/左 センサーアナログジョイスティック 交換用 2個 キャップ付き
を注文した。2日後に到着(ヘタに安いやつを注文すると届くまでに数週間とかかかってしまうらしいので……)。

■分解と交換

★注意★
分解には任天堂の機器ではおなじみのY字ドライバーが必要です。持ってなければ
このへんを買っておけばベター。

1)コントローラの外装はY字ドライバでネジを外して、背面を開けます。
2)バッテリーは両面テープで止まってるのでぺりっと剥がしておきます(ケーブルを抜く必要はないです)
3)バッテリーの乗っていた台のネジ(上下3個)を、+の精密ドライバで外して台を横によけると、問題のスティックが見えてきます
4)スティックを止めているネジ(2個)を+の精密ドライバで外す
5)スティックのフレキシブルケーブルが刺さっているコネクタの、ケーブル挿入口の反対側に灰色の押さえがあるので、これを上に持ち上げでケーブルをそっと抜く
6)スティックを新しいものに交換、フレキシブルケーブルを差し込んで、先ほど持ち上げた押さえを戻してケーブルをロックする
7)バッテリーの台を戻し、バッテリーも元の位置に戻して、ケーブル類を元の位置に戻して、外装も元に戻します。
8)再度[スティックの補正]で、スティックが正常に動作することを確認します

以上。
作業時間5~10分くらい。

【AWS】請求額をプロジェクトごとに確認したい(DBR:レガシー)

:**【参照】
AWSでプロジェクトごとに請求額を見る - Qiita
コスト配分タグの使用 - AWS 請求情報とコスト管理
AWS 生成コスト配分タグのアクティブ化 - AWS 請求情報とコスト管理

【手順】

1)ユーザ定義タグをリソースに関連付ける

今回は既に以下のリソースタグが設定されている前提

  • Environment
  • Project
2)コスト配分レポートを配置するためにS3バケットを用意

EC2ダッシュボード-[S3]-[バケットを作成する]、あとは初期値のまま作成
バケットポリシーについては後ほど設定します

3)S3バケットポリシーの設定と請求レポート有効化

[請求ダッシュボード]-[設定]-[請求明細レポート (レガシー)]
→[レガシー化した請求明細レポート機能を使って、AWS の料金に関する継続的なレポートを受け取る。]をチェックし、[S3 バケットに保存]に、上記で用意したバケット名を入れ、[検証]
→エラーになったらメッセージのリンクにあるサンプルポリシーを[アクセス権限]の[バケットポリシー]にコピペでOK

4)請求レポート確認

月が替わったら2)で作成したS3バケットに保存されている請求レポートを確認しましょう。
xxxxxxxxxxxx-aws-cost-allocation-YYYY-MM.csv

こちらの末尾に「user:Project」列があれば、こちらで絞り込むことが可能です。

以上

php-opcacheの効果が絶大だったメモ

【概要】

Wordpress(nginx+php-fpm)で、アクセス集中時にCPU負荷がボトルネックとなっていたためphp-OPcacheを導入したところ劇的に改善したのでメモ

OPCacheについては以下を参照
OPcacheを利用してPHPを高速にしよう | WEB ARCH LABO
OPcache導入してみた!(速さ検証もあるよ!) - Qiita
PHPのキャッシュ機構のおさらいと、opcacheの設定とかキャッシュクリアとか - waste of time

上記からのぼんやりした認識

  • コンパイルされたバイナリコードをメモリに置いておくので、同じようなリクエストが大量に来る場合に効果があると思われる。
  • 実行結果をキャッシュするわけではないので処理には影響でない。

【環境】

OS:Amazon Linux
EC2インスタンスタイプ:m4.xlarge(4Core/16GiB)
Webサーバ:nginx/1.8.1
PHP:PHP 5.6.38

【やったこと】

■パッケージのインストールと初期設定

# インストール

yum install php-opchache

# パラメータ値を変更
php.netの示す推奨値を利用した)
※推奨設定値:http://php.net/manual/ja/opcache.installation.php
 オプションの詳細:http://php.net/manual/ja/opcache.configuration.php

cat /etc/php.d/10-opcache.ini | egrep -v '^(#|$|;)'

zend_extension=opcache.so
opcache.enable=1
opcache.enable_cli=1
opcache.memory_consumption=128
opcache.interned_strings_buffer=8
opcache.max_accelerated_files=4000
opcache.revalidate_freq=60
opcache.fast_shutdown=1
opcache.blacklist_filename=/etc/php-5.6.d/opcache*.blacklist


# サービス再起動して反映

service php-fpm restart
service nginx restart

# 組み込み状態確認

php -v
PHP 5.6.38 (cli) (built: Oct 16 2018 23:34:40)
Copyright (c) 1997-2016 The PHP Group
Zend Engine v2.6.0, Copyright (c) 1998-2016 Zend Technologies
    with Zend OPcache v7.0.6-dev, Copyright (c) 1999-2016, by Zend Technologies

php -i | grep opcache
(省略)
負荷確認

f:id:zuntan02:20190109122212p:plain
目に見えてレスポンスが軽くなった。
php-fpmのプロセス数も減少している。
空きメモリの減少も見られない(opcache.memory_consumptionの値が上限と思われる)

もっと早くやっとけばよかった。。。