CloudFormationでエラーに遭遇する理由

CloudFormation で、構造エラーですっと出たときの原因をいくつか紹介します。

An error occurred (ValidationError) when calling the CreateStack operation: Template format error: unsupported structure.

1. UTF8になっていない

文字コードはUTF8にしましょう。

2. パスの指定方法を間違えている

ローカルファイルパスの指定方法を間違えています。

–template-body file://c:\Users\example\Documents\hoge\hoge.template

「file://」で初めて、パスを指定してあげないとダメです。

3. 日本語を使用している

Descriptionに日本語を使用したくなりますが、日本語は使用できません

4. 純粋に構文ミス

純粋な構文ミスですね。
本当はこのケースを最初に除外すべきなので、一番シンプルなもので動作確認するといいのかもしれません。

5. yaml でも特に関係ない

あまりにもエラーが解消できないと、「yaml」だと何かオプション指定が必要に違いない!と思いたくなりますが、jsonでもyamlでもそれによる追加オプションは無いのです。

「Prometheus入門から運用まで徹底解説」で登壇してきました

July Tech Festa 2017 で、「Prometheus入門から運用まで徹底解説」というタイトルで登壇してきました。

セッションの目的は、すでに別のモニタリングシステムを使ったことがある人が、Prometheusを評価、検証しようとしたときに必要な情報の提供と、初めてだとハマるポイントを予め解説しておくことです。

それによって、最初の評価検証がスムーズに行えることを企図したセッションとなっています。

Prometheusの冗長化について公式のスタンス

Prometheusをどうやって冗長構成を組むか一度は悩むのではないでしょうか。
公式ドキュメントを見ても、冗長構成の組み方には言及がされていないように見えます。

Prometheusの冗長構成については、Githubのissuesで公式見解が語られていますので紹介します。

For HA, simply run the two Prometheus servers independently with the same configuration. They’ll have the same data, modulo sample timings.

潔いスタンスですね。
別々に2つのPrometheusを構築して、同じ構成ファイルで動かしましょう。同じデータになるよとのこと。
クエリ発行先を片方にして、何か問題が発生すればもう片方にスイッチさせる。
DNSのCNAMEを使って切り替えるのが一番楽だろう。
もっと自動化したいのなら、ロードバランサ―かVIPを使いましょう。
その名前をGrafanaで使えばばっちり。

スケールのためだとしても、Prometheusを分けて、監視する対象を分けちゃいましょう。

ちなみに質問者が喰い下がって、「so you could query any server, and get forwarded (http 301 or just proxy request) to a server who has the data.」と要望しました。
それに対する回答が、「This is not a feature we plan to add.」と。

他の質問者が突っ込んでみました。「Example that was mentioned above: when a physical server is downed.」
それに対する回答が、「If you need 100% accuracy in data reporting, Prometheus is not for you 」
100%のデータ保持を担保したいのなら、Prometheusはあなた向きじゃないよだって。

Prometheusのローカルストレージの特性をよく表現した説明が書かれています。
耐久性、レプリケーション、長期のデータ保持は考慮してないよ。
数週間、数カ月、数年問題なく動作するのだとしても、あくまでも上記のことは考慮してない。

Prometheus’s local storage is generally not considered a durable, replicated, or arbitrarily long-term storage – even if it works well for weeks, months, or sometimes even years in practice.

とは言え、希望が無いわけでもありません。

長期保存については対応しようとしてるし、サーバダウンやデータレプリケーションについてはよくしようと思っている。

"Real" long-term storage is still in the works and aims to address individual down servers and replication of data better. It will be decoupled enough from the main Prometheus servers that these won’t have to hard-depend on it though.

altermanagerは?

Prometheusを複数運用していても、Altermanagerは1つにしましょう。
Altermanagerは、手動フェールオーバーでいいんじゃない?

とのこと。。。

ただし、「監視システムを独立して監視することはいつでも重要だよ」で締めくくられています。

redash 2.0 リリース:Athena正式対応!だけど表示されない時の対応

2017/8/8に、redash 2.0 がリリースされました。

今回のリリースで個人的に一番嬉しいのが、「Athena: direct query runner using the instead of JDBC proxy.」です。
今までも、redashでAthena使えはしたのですが、別にプロキシを立てて、
そこ経由でクエリ発行しないといけないという辛いものでした。

今回のメジャーアップデートで、正式対応したので早速アップデートしました。
バージョン1系統からのアップデートは、アップデーターがあるので非常に簡単です。

cd /opt/redash/current
sudo bin/upgrade

これで1〜2分でアップデートされます。

ところが自分の環境では、AthenaがData Sourceで表示されなかったのです。
ついでにBigQueryも使用できなくなってました。

これはRequirementsで要求されているライブラリが不足している、
もしくはバージョンが低いことが原因なのでインストールしてあげると
データソースにAtenaが表示されるようになります。

pip install -r requirements.txt
pip install -r requirements_all_ds.txt

redashをsupervisorctlで起動するときに発生するエラーへの対応

1. Error: .ini file does not include supervisorctl section

/opt/redash/supervisordsupervisorctl start allを実行すると、Error: .ini file does not include supervisorctl sectionとエラーが発生する。

色々紛らわしいのだが、.iniは、supervisord.confと読み替えて差し支えない。
supervisorctlが定義されていないと言われるので、supervisord.confに追記する。今回は空行で追加した。

[supervisorctl]
[supervisord]
nodaemon=false
logfile=/opt/redash/logs/supervisord.log
pidfile=/opt/redash/supervisord/supervisord.pid
directory=/opt/redash/current

2. http://127.0.0.1:19001 refused connection

/opt/redash/supervisordsupervisorctl start allを実行すると、http://127.0.0.1:19001 refused connectionとエラーが発生する。

supervisordが起動していないことが原因。まずは起動してあげる。

# supervisord -c supervisord.conf
# supervisorctl start all

3. FATAL: role “root” does not exist

api_error.logOperationalError: (psycopg2.OperationalError) FATAL: role "root" does not existというエラーが発生している。

postgresqlに、rootロールがないというエラーなので、roleを作成してあげる。

su postgres
psql
postgres=# CREATE ROLE root LOGIN SUPERUSER PASSWORD 'root';
postgres=# \q

4. you have to set the C_FORCE_ROOT environment variable

celery_error.logに次のエラーが発生していた。
If you really want to continue then you have to set the C_FORCE_ROOT
environment variable (but please think about this before you do).

対応するために、/opt/redash/current/redash/worker.pyを編集する。

+++ from celery import Celery,platforms
--- from celery import Celery
+++ platforms.C_FORCE_ROOT = True
celery = Celery('redash',
                broker=settings.CELERY_BROKER,
                include='redash.tasks')