目次
こんにちは、terraformおじさんです。
ニンニク入れますか？それとも人生やめますか？
今回は第二回 技術書同人誌博覧会(以下、技書博)とStackdriverについて書いていこうと思います。
■ はじめに
既にご存知の方もいらっしゃるかと思いますが、2019年12月14日に第二回 技書博が開催されます。
技書博とは？
技術書同人誌博覧会（技書博）は、エンジニア（おもにITエンジニア）が自身の知見を「本」という形で共有するために開催される、技術書オンリーイベント（同人誌頒布即売会）です。
いわゆる自費出版の形で出版社などを通さずに技術書を頒布・交流する場でしょうか(ちょっと説明に自信がないです)。 弊社は第一回に引き続き、スポンサーとして協賛しており、ご縁でパンフレットにStackdriverについての記事を書かせていただきました。 本postではパンフレットの記事で書ききれなかった部分に焦点をあてていこうかと思います。
■ 記事の概要
terraformおじさん改めStackdriverおじさんとして、Stackdriverを触ったことがない人が導入を進められることを目指しました。 何故Stackdriverを選択したかというと、ネタが思い浮かばなかった導入のために軽く触ってみたものの、いまいちとっかかりにくいという声を聞くことがあったためです。
記事では、下記のアーキテクチャに基づいてnginxのログを監視し、発報するまでの流れを解説しました。
■ 追補解説 StackdriverのAlert
本postではmonitoring → Slack通知の部分をより掘り下げて解説します。
前提の設定
解説にあたり、インスタンス及びStackdriver Loggingで下記設定が前提となります。
- CentOS 7上にnginxの公式リポジトリからnginxをインストールされている
- Stackdriver Logging agent(google-fluentd)が対象インスタンスにインストールされている
- プラグイン
google-fluentd-catch-all-config-structuredがインストールされている - Stackdriver Loggingのログベースの指標に、
nginx_errorの名称で指標が作成されている - 指標
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に下記のようなアラートが出力されます。
慣れていればそうでもないですがぱっと見エラー内容がわかりにくいと言った声がありました。
そこで、policiesのdocumentに ドキュメント テンプレートの変数 を使って、通知内容に手を入れていきましょう。
■ 通知内容に手を入れる
まずはGoogleのドキュメントを読みつつ、Documentationの設定を行っていきます。
今回は下記のような表示を目指していきます。
hostname で status_code 502 を含むlogが出力されました。
それでは早速、Documentationに変数を書き込んでAlertを出力してみましょう。
${metadata.system_labels.name} で status_code ${metric.label.code} を含むlogが出力されました。
status_code は表示されたものの、hostnameはnullになってしまっています。
■ 脱線: 日本語ドキュメントと英語ドキュメント
さて、そもそも ${metadata.system_labels.name} と何？と疑問に思われる方がいるかと思いますが、実は英語のドキュメントの注釈にしか書かれていない変数です。日本語のドキュメントは英語のドキュメントを追従できていないケースがあり、情報量に差があるケースが稀に良くあります。
例えばドキュメント テンプレートの変数のページだと下記表のように差分があります。
日本語
英語
そのような場合、URLの末尾に ?hl=言語 を追加することでページの言語を指定することができます。
- 日本語ページ
https://cloud.google.com/monitoring/alerts/doc-variables?hl=ja - 英語ページ
https://cloud.google.com/monitoring/alerts/doc-variables?hl=en
明示的に言語を指定できるため、例えば社内でドキュメントページの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になる
次いで、再度アラートの発報を行います。
知ってた。
codeもGroup Byしましょう。
そして再度アラートの発報を行います。
紆余曲折がありましたが、無事Documentationに意図したメッセージを表示することができました。 他にも様々な変数がありますので、有効活用し通知の幅を広げていただければ幸いです。
■ おわりに
誌面の都合で深堀りできなかった部分について、駆け足ながら解説しました。
私の記事に限らず技術書の同人誌に興味がある方は、もしお時間があればぜひ技書博にお立ち寄りいただけますと嬉しいです。
私も足を運び、色々な方々や本との出会いを楽しみにしたいと思います。
株式会社grasys(グラシス)は、技術が好きで一緒に夢中になれる仲間を募集しています。
grasysは、大規模・高負荷・高集積・高密度なシステムを多く扱っているITインフラの会社です。Google Cloud (GCP)、Amazon Web Services (AWS)、Microsoft Azureの最先端技術を活用してクラウドインフラやデータ分析基盤など、ITシステムの重要な基盤を設計・構築し、改善を続けながら運用しています。
お客様の課題解決をしながら技術を広げたい方、攻めのインフラ技術を習得したい方、とことん技術を追求したい方にとって素晴らしい環境が、grasysにはあります。
お気軽にご連絡ください。
