vague memory

うろ覚えを無くしていこうともがき苦しむ人の備忘録

AWS CodeBuild 処理時間の確認方法

CodeBuildの処理時間を一覧出力したかったのでメモ。

CodeBuild上だと各実行毎の値しか表示できず、過去の実行分と比較したい場合に不便です。
CloudWatch も定期的に実行しているBuildであれば問題ないですが、期間が空いてしまうと見難いです。



CodeBuild

CodeBuild コンソール上で確認できます。

  • Build Project全体
    • f:id:htnosm:20220103042158p:plain
  • Phase毎
    • f:id:htnosm:20220103042203p:plain

CloudWatch

各Durationメトリクスが用意されています。

{
    "metrics": [
        [ "AWS/CodeBuild", "SubmittedDuration", "ProjectName", "xxxxx" ],
        [ ".", "QueuedDuration", ".", "." ],
        [ ".", "ProvisioningDuration", ".", "." ],
        [ ".", "DownloadSourceDuration", ".", "." ],
        [ ".", "InstallDuration", ".", "." ],
        [ ".", "PreBuildDuration", ".", "." ],
        [ ".", "BuildDuration", ".", "." ],
        [ ".", "PostBuildDuration", ".", "." ],
        [ ".", "UploadArtifactsDuration", ".", "." ],
        [ ".", "FinalizingDuration", ".", "." ],
        [ ".", "Duration", ".", ".", { "yAxis": "right" } ]
    ],
    "view": "timeSeries",
    "stacked": false,
    "region": "ap-northeast-1",
    "stat": "Maximum",
    "period": 60,
    "yAxis": {
        "left": {
            "min": 0
        },
        "right": {
            "min": 0
        }
    },
    "title": "CodeBuild Durations"
}

f:id:htnosm:20220103042210p:plain

AWS CLI

batch-get-builds と tsv 形式での出力のため jq を併用します。

List output of AWS CodeBuild duration times.

こんな感じのデータ出力になります。

f:id:htnosm:20220103042213p:plain

適宜グラフ化などを行います。

f:id:htnosm:20220103042217p:plain

Google Analytics の Slack 通知

Google Analytics のデータをSlack通知したいなと思い立ったのでメモ。(リンク集です)

要件

Google Analytics は高機能なサービスなので色々できるわけですが、 使いこなせていない感満載の私の今回の要望は以下です。

  • 極力面倒な設定をしたくない
    • 別サービスへのアカウント登録なども極力避けたい
  • ユーザ数などの簡易レポート(グラフ)で良い
  • 定期的に通知したい

UA と GA4

尚、当方 UA と GA4 を併用しており、今回は UA からの Slack 通知に落ち着いたので GA4 についてはあまり調べてません。 GA4 と UA の違いについての公式ドキュメントはこの辺りでしょうか。

右往左往

Google Analytics

標準で対応しているものかと思ったのですが、対応していないようでした。
カスタムアラートの機能でメール通知が可能なので、それをSlackへ送る形は取れますが、 レポート自体は pdf で添付されるようなので、 Slack上でメールをクリック、pdf をダウンロードの手間を惜しみ今回は見送ります。

Slack

次に引っ掛かったのは Slack 公式の情報です。 画像リンクが切れてしまっており古い情報のようでした。

Arc Analytics

アカウント登録が必要で、Free プランではカスタマイズがほぼできないようなので今回は見送ります。

Statsbot | Slack App ディレクトリ

"Google Analytics Slack" などで検索すると上位の記事で良く紹介されているサービスでした。 一見良さそうだったのですが、サービスサイトを見てみると悲しい文字が表示されました。

f:id:htnosm:20211218113400p:plain

既に新規受付は終了しているようです。 Slack App Directory でも検索結果に出てこない様になっています。

曰く、別のサービス(Narrative BI for Google Analytics など)を使ってくださいとのことです。 通知以外の機能も充実しているようですが、過剰なので今回は見送ります。

最終的に

既に Google Workspace のアカウントを利用していたので、
Google Analytics(UA) -> SpreadSheet -> Apps Script -> Slack
の形にしました。

この方式も既に事例は多々公開されており、ほぼほぼ引用となるので、参考URLと躓いたポイントだけ記載します。


Google Apps Script を少し改良して複数グラフを通知できるようにして使っています。

f:id:htnosm:20211218113404p:plain

AWS RDS Auto Scaling の Capacity 制御

ドキュメントは以下です。

実際の挙動がどうなるのかを確認しました。

最小容量と最大容量

アプリケーションの Auto Scaling が管理する Aurora レプリカの最大数を指定できます。この値は 0–15 に設定される必要があります。

アプリケーションの Auto Scaling が管理する ということなので、 既設のDBインスタンスの台数には影響しません。

DBインスタンスを3台保有するDBクラスタが存在し、 そのDBクラスタにAuto scaling policy を設定する場合

DB Cluster: db-cluster-01
DB Instance:
    db-instance-01 (Writer)
    db-instance-02 (Reader)
    db-instance-03 (Reader)
Auto scaling policy:
    Minimum capacity: 0
    Maximum capacity: 15

Auto scaling によるスケールアウトが発生し、 n台追加された場合、既存の db-instance-01〜03 + n台 となります。 追加されるDBインスタンスは prefix application-autoscaling- で作成されます。

application-autoscaling なのですが、 マネジメントコンソールの AWS Auto Scaling には表示されません。

f:id:htnosm:20211210090954p:plain

RDS の DB Cluster Logs & events タブで確認可能です。

f:id:htnosm:20211210090958p:plain

CLI では application-autoscaling では出力されます。

aws application-autoscaling describe-scaling-policies --service-namespace rds

トリガー

DB Cluster へ Auto scaling policy を追加すると、 CloudWatch Alarm に prefix TargetTracking-cluster:〜 の2つが追加されます。

f:id:htnosm:20211210091002p:plain

  • TargetTracking-cluster:{DBClusterIdentifier}-AlarmHigh-〜
    • {TargetValue} for 3 datapoints within 3 minutes
  • TargetTracking-cluster:{DBClusterIdentifier}-AlarmLow-〜
    • ({TargetValue} x 90%?) for 15 datapoints within 15 minutes

このAlarmの Description には DO NOT EDIT OR DELETE. との記載があります。 文字通り変更削除は非推奨なのでしょうが、Alarm を直接変更する事は自体はできます。
注意点として、 RDS 側の設定で Auto scaling policy を変更した場合、Alarm は更新されるのではなく、新規作成(旧Alarmは削除)されます。

メトリクスは対象のDBClusterの Role: READER 、Average です。

"metrics": [
    [ "AWS/RDS", "CPUUtilization", "Role", "READER", "DBClusterIdentifier", "db-cluster-01" ]
],

スケールアウトアクティビティ

新しい Aurora レプリカの昇格階層は、最も低い優先順位 (デフォルトでは 15) に設定されています。

TargetTracking-〜-AlarmHigh-〜 の State が In alarm である場合に、Aurora レプリカ(Reader)数を増やします。 (※ State が In alarm の状態が継続していると、クールダウン期間後に再発動します)
メトリクス状態により複数台同時に起動する事があります。
db-instance-01〜03 + n台 の設定が15を超過している場合でも、起動できるのは最大で15台までです。特にWarning、Error出力はありませんでした。

スケールインアクティビティ

Aurora Auto Scaling では、自身が作成した Aurora レプリカのみ削除されます。

TargetTracking-〜-AlarmLow-〜 の State が In alarm である場合に、Aurora レプリカ(Reader)数を減らします。 (※ State が In alarm の状態が継続していると、クールダウン期間後に再発動します)
複数台同時の削除は行われず、1台ずつ削除されます。

f:id:htnosm:20211210091006p:plain

また、あまり実施しないとは思いますが、手動で application-autoscaling- のDBインスタンスを削除しても特にエラーなどは発生しませんでした。

Datadog Log Management estimated usage dashboard

タイトルそのまま Datadog Logs の使用量把握のためのダッシュボードです。 公式ドキュメント上にあります。

Datadog では Integration 設定に併せて自動でダッシュボードが追加されますが、そこに加えてくれても良いのではと思います。

Link

Usage

ダッシュボードを新規作成

f:id:htnosm:20211205180832p:plain

新形式を選択

f:id:htnosm:20211205180234p:plain

歯車ボタンから Import を選択

f:id:htnosm:20211205180239p:plain

JSONアップロード

Link から JSON ファイルを取得してアップロードするか、JSONの内容をコピー&ペーストします。

f:id:htnosm:20211205180243p:plain

f:id:htnosm:20211205180248p:plain

f:id:htnosm:20211205180252p:plain

Datadog Forwarder(AWS) についてのメモ

Datadog Logs へ AWS のログを送る仕組みについて、古い知識のままだったので調べ直したメモ。



AWS から Datadog Logs への送信

AWS の各種ログを送信する方法として2パターン用意されています。 ここで言うログは EC2やECS 内のログではなく、 CloudWatch Log または S3 バケットに保存しているログを指しています。

現在公式ページに記載されているのは、Kinesis Firehose destination)、Forwarder Lambda function となり、 いずれも CloudFormation が用意されています。

f:id:htnosm:20211205173203p:plain

Kinesis Firehose destination

CloudWatch logs -> Firehose -> Datadog の流れです。 大量送信する場合はこちらが推奨とのこと。

CloudFormation のテンプレートは公式ドキュメントから参照できます。 少し古いのかそのまま利用すると IAM Role のポリシーが一部エラーとなります。

CloudWatchLogsPolicy の Action に kinesis:〜 が指定されていますが、 kinesis:PutRecordBatch は存在しません。 また、iam:PassRole も不要です。

{
    "Statement":[
      {
        "Effect":"Allow",
        "Action":["firehose:*"],
        "Resource":["arn:aws:firehose:region:123456789012:*"]
      }
    ]
}

source タグ

定義箇所を見つけられませんでしたが、ある程度自動振り分けしてくれるようです。 Lambda Function の LogGroup (/aws/lambda/...) を対象とすると source:lambda となりました。

Forwarder Lambda function

S3 から Datadog Logs へ送信するパターンです。

CloudFormation のテンプレートは公式ドキュメントから参照できます。 また、AWS Integration 設定の CloudFormation にも含まれています。(Setup : Automatic - CloudFormation で作成される ForwarderStack)

トリガー

トリガーは自動設定も可能です。 AWS Integration 用の IAM Role に必要権限を追加し、Datadog 側 "Amazon Web Services Integration" -> "Collect Logs" で Forwarder の Lambda Function を登録、チェックボックスを設定することで自動的に収集が走ります。 (非常に便利な機能ではありますが、意図せず大量にログが送信される事が懸念です。)

手動の場合は、転送したい対象に各々設定します。

  • CloudWatch Log
    • Log Group に Forwarder Lambda へ向けた Subscription Filter を設定
  • S3
    • S3 バケットに Forwarder Lambda へ向けた Event notification を設定

転送の除外

特定のログを Datadog 側に送信したくない場合の除外設定を行う箇所は以下になります。 Forwarder Lambda 側に条件指定する場合、必要に応じて追加の Forwarder Lambda を作成するなど考慮が必要になるかもしれません。

source タグ

Lambda Function 内処理で振り分けされます。 前はLambdaコンソールから直接参照できましたが、最新版では主処理がLayerに移動したようでした。 Layerは CloudFormation 実行時に GitHub から取得しています。

source タグについて

Datadog Logs へログを送信すると事前定義されたPipelineにより自動的にパースしてくれます。 この際の判定に source タグが利用されます。

f:id:htnosm:20211205173207p:plain

source タグとパースに利用される事前定義されたPiplelineは以下から参照できます。

f:id:htnosm:20211205173211p:plain

source タグ付与条件に合致しなかった場合(S3 バケットに出力している CloudFront アクセスログが、 source:s3 となってしまった場合など)、Pipelineを複製(Clone)して任意のログにPipelineを適用する事も可能です。

tfnotify で Terraform の実行結果を Slack 通知

Terraform の実行結果を Slack へ通知したくなり、 tfnotify を使わせてもらいました。

tfnotify は GitHubへの通知がメインのようで、 Slack への通知は README の通りだと微妙な通知になったので試した結果を残しておきます。



環境

Terraform, Slack のバージョンにより挙動は変わると思います。 試行した環境は以下のとおりです。

  • Terraform: v1.0.x
  • tfnotify: v0.7.0
  • Slack: 2021/09時点

Slack設定

Token と Channel ID が必要になります。

  • Slack API: Applications
    • "Create New App"
    • "From scratch"
      • "App Name"
        • tfnotify など、Slack通知時のユーザ名
      • "Pick a workspace to develop your app in:"
  • 作成した App の詳細ページ (作成時に遷移)
    • "OAuth & Permissions"
      • "Bot Token Scopes"
        • chat:write, chat:write.public
      • "OAuth Tokens for Your Workspace"
        • "Install to Workspace"
        • Workspaceへの追加許可ページに遷移
          • "Allow"
        • "Bot User OAuth Token" に Token が発行される
  • Slack クライアント または Web
    • "Apps" -> "Add apps"
      • 作成した App を選択
    • 通知したいチャンネルを選択
    • "Integrations" -> "Add apps"
      • 追加した App を選択 f:id:htnosm:20211001092710p:plain

チャンネルID

チャンネルの URL に記載されています。 Slack クライアントの場合、左ペインの対象チャンネルを右クリック -> "Copy link" から取得できます。

# 例 ( XXXXXXXXXXX の部分がチャンネルID)
https://example.slack.com/archives/XXXXXXXXXXX

基本形

  • README 記載の .tfnotify.yaml
---
ci: codebuild
notifier:
  slack:
    token: $SLACK_TOKEN
    channel: $SLACK_CHANNEL_ID
    bot: $SLACK_BOT_NAME
terraform:
  plan:
    template: |
      {{ .Message }}
      {{if .Result}}
      ```
      {{ .Result }}
      ```
      {{end}}
      ```
      {{ .Body }}
      ```

実行

  • README 記載のコマンド
terraform plan | tfnotify plan

実行結果

文字化けしてます。

f:id:htnosm:20211001092435p:plain

文字化け(HTMLエスケープ)の解消

tfnotify 内で HTML エスケープを行っており、それがそのまま変換されず出力されています。
README 内の GitHub の箇所に use_raw_output オプションの記載があります。
これを適用することで解消できそうでしたが、対応しているのは GitHub のみでした。
そのため Slack用の PR を挙げました。

PR がマージされることを願いつつ、インストールします。

git clone https://github.com/htnosm/tfnotify.git
cd tfnotify && go build
  • .tfnotify.yaml にオプション追加
# ...
terraform:
  use_raw_output: true
  plan:
# ...

実行

  • README 記載のコマンド
terraform plan | tfnotify plan

実行結果

文字化けが解消できます。

f:id:htnosm:20211001092439p:plain

apply

In the case of apply, you need to do apply.

とありますので、applyを指定、設定も planとは別に apply の定義を追加します。

  • .tfnotify.yaml に apply 追加
# ...
terraform:
  use_raw_output: true
  plan:
# ...
  apply:
    template: |
      {{ .Message }}
      {{if .Result}}
      ```
      {{ .Result }}
      ```
      {{end}}
      ```
      {{ .Body }}
      ```

実行

  • applyコマンド
terraform apply | tfnotify apply

実行結果

f:id:htnosm:20211001092444p:plain

エラー通知

Terraform でエラーが発生した場合に通知ができませんでした。 tfnotify が以下を出力します。

cannot parse apply result

仕様としては、 Error: の文字列で検索しているため通知自体は可能です。( https://github.com/mercari/tfnotify/blob/master/terraform/parser.go#L65 )

条件とそれぞれ対処は以下になります。

  • 標準出力が対象
    • エラー出力を標準出力に含める
  • 行の先頭が Error:
    • no-color オプションを付与する

実行

  • applyコマンド
terraform apply -no-color 2>&1 | tfnotify apply

実行結果

エラー内容が通知され、色も赤になっており良い感じです。

f:id:htnosm:20211001092449p:plain

Refreshing state の除外

管理対象のリソース数が増えてくると、Refreshing state... の行で埋め尽くされます。
複数行パターンでなく、特定の行を除外したいだけであれば tfnotify に渡す前に除外すれば良いです。

  • コマンド例
terraform plan -no-color 2>&1 | grep -v -e ' Refreshing state\.\.\. ' | tfnotify plan

実行時オプション

グローバルオプションのメモです。 各コマンドのヘルプは tfnotify xxx --help で出力

GLOBAL OPTIONS:
   --ci value        name of CI to run tfnotify
   --config value    config path
   --notifier value  notification destination
   --help, -h        show help
   --version, -v     print the version
  • ci, notifier
    • 実行時に定義済み ci, notifier の選択
  • config
    • 定義ファイル(.tfnotify.yaml) の指定
  • version
    • 利用できない (unset となっている)
  • help
    • tfnotify xxx --help で各コマンドのヘルプ出力

まとめ

  • use_raw_output オプションが有効な通知先は限定されている
    • 現時点では GitHub のみ
  • エラー通知は以下が必要
    • tfnotifyへエラー出力も含めて渡す
    • Terraform に -no-color オプションを付与して実行する
  • slack.bot を設定しても置き換わらない(?)
    • 設定を入れても Slack App Name のままでした
  • 定義ファイルは config オプションで実行時指定ができる

AWS HTTP Header の追加・変更方法

AWS上のWebサーバ構成でHTTP Headerの追加・変更についてのメモ。
Target(Origin) に追加・変更したヘッダを渡したい場合に焦点を当てています。

f:id:htnosm:20210925052744p:plain

WAFv2

CloudFront

Lambda@Edge

rewrite-host-header-index.js

CloudFront Functions

Response Headers Policy (2021/11/02 追加)

ELB(ALB)