第二回 技術書博覧会とStackdriver

こんにちは、terraformおじさんです。
ニンニク入れますか?それとも人生やめますか?

今回は第二回 技術書同人誌博覧会(以下、技書博)とStackdriverについて書いていこうと思います。


■ はじめに

既にご存知の方もいらっしゃるかと思いますが、2019年12月14日に第二回 技書博が開催されます。

https://gishohaku.dev/

技書博とは?
技術書同人誌博覧会(技書博)は、エンジニア(おもにITエンジニア)が自身の知見を「本」という形で共有するために開催される、技術書オンリーイベント(同人誌頒布即売会)です。

いわゆる自費出版の形で出版社などを通さずに技術書を頒布・交流する場でしょうか(ちょっと説明に自信がないです)。 弊社は第一回に引き続き、スポンサーとして協賛しており、ご縁でパンフレットにStackdriverについての記事を書かせていただきました。 本postではパンフレットの記事で書ききれなかった部分に焦点をあてていこうかと思います。

■ 記事の概要

terraformおじさん改めStackdriverおじさんとして、Stackdriverを触ったことがない人が導入を進められることを目指しました。 何故Stackdriverを選択したかというと、ネタが思い浮かばなかった導入のために軽く触ってみたものの、いまいちとっかかりにくいという声を聞くことがあったためです。
記事では、下記のアーキテクチャに基づいてnginxのログを監視し、発報するまでの流れを解説しました。

architecture

■ 追補解説 StackdriverのAlert

本postではmonitoring → Slack通知の部分をより掘り下げて解説します。

architecture
前提の設定

解説にあたり、インスタンス及びStackdriver Loggingで下記設定が前提となります。

  1. CentOS 7上にnginxの公式リポジトリからnginxをインストールされている
  2. Stackdriver Logging agent(google-fluentd)が対象インスタンスにインストールされている
  3. プラグイン google-fluentd-catch-all-config-structured がインストールされている
  4. Stackdriver Loggingのログベースの指標に、 nginx_error の名称で指標が作成されている
  5. 指標 nginx_error には表のアイテムが登録されている

前提 4. 指標

resource.type="gce_instance" AND
logName="projects/<project_id> /logs/nginx-access" AND
jsonPayload.code!="200" OR
jsonPayload.code!="301"

前提 5. アイテム

名前 ラベルのデータ型 フィールド名 抽出の正規表現
code 整数 jsonPayload.code (空欄)

■ 通知を作成する

前提条件の準備が整いましたら、Stackdriver Monitoringのメニューより Alerting → Create a Policy を選択し通知を設定していきましょう。
まずはConditionは以下のように設定し、任意のSlack通知を設定した上で保存します。

  • Target
Resource type Metric Filter Group By Aggrigator
GCE VM Instance logging/user/nginx_error none
  • Configuration
Condition triggers if Condition Threshold For
Any time series violates is above 0 1 minute

次に、nginxが設定しているサーバで任意のエラーを発生させ、アラートを出力します。
正しく設定されていれば、Slackに下記のようなアラートが出力されます。

architecture

慣れていればそうでもないですがぱっと見エラー内容がわかりにくいと言った声がありました。

そこで、policiesのdocumentに ドキュメント テンプレートの変数 を使って、通知内容に手を入れていきましょう。

■ 通知内容に手を入れる

まずはGoogleのドキュメントを読みつつ、Documentationの設定を行っていきます。

ドキュメント テンプレートの変数

今回は下記のような表示を目指していきます。

hostname で status_code 502 を含むlogが出力されました。

それでは早速、Documentationに変数を書き込んでAlertを出力してみましょう。

${metadata.system_labels.name} で status_code ${metric.label.code} を含むlogが出力されました。
architecture

status_code は表示されたものの、hostnameはnullになってしまっています。

■ 脱線: 日本語ドキュメントと英語ドキュメント

さて、そもそも ${metadata.system_labels.name} と何?と疑問に思われる方がいるかと思いますが、実は英語のドキュメントの注釈にしか書かれていない変数です。日本語のドキュメントは英語のドキュメントを追従できていないケースがあり、情報量に差があるケースが稀に良くあります。

例えばドキュメント テンプレートの変数のページだと下記表のように差分があります。

日本語 英語
architecture
architecture

そのような場合、URLの末尾に ?hl=言語 を追加することでページの言語を指定することができます。

明示的に言語を指定できるため、例えば社内でドキュメントページのURLを共有する場合など、ブラウザやアカウントの設定によって情報にばらつきが出るのを防ぐことができるので便利です。

■ 改めてhostnameも出力する

それでは、英語ページを見つつdocumentsで (null) が出た問題を解消していきましょう。

Values for some variables (for example resource.project, metric.label.[KEY], resource.label.[KEY], and metadata.user_label.[KEY]) are derived from time series. The values can be null if no values are returned from the time series query. One thing that can cause variables to have null values is if your alerting policy uses a cross-series aggregation (for example, calculating the SUM across each of the time-series that match the filter). When using a cross-series aggregation, any variables not used in grouping are dropped and will have null values if referenced in variable substitution.

ドキュメントに従い、TargetのGroup Byで name (hostname) を指定し、保存しましょう。

Group By対象にnameを指定する 表示がsystem_labels.nameになる
architecture
architecture

次いで、再度アラートの発報を行います。

architecture

知ってた。

codeもGroup Byしましょう。

architecture

そして再度アラートの発報を行います。

architecture

紆余曲折がありましたが、無事Documentationに意図したメッセージを表示することができました。 他にも様々な変数がありますので、有効活用し通知の幅を広げていただければ幸いです。

■ おわりに

誌面の都合で深堀りできなかった部分について、駆け足ながら解説しました。
私の記事に限らず技術書の同人誌に興味がある方は、もしお時間があればぜひ技書博にお立ち寄りいただけますと嬉しいです。
私も足を運び、色々な方々や本との出会いを楽しみにしたいと思います。