サクサク読めて、アプリ限定の機能も多数!
トップへ戻る
iPhone 16
htnosm.hatenablog.com
年の瀬の awsume-console-plugin との出会いです。 馴れ初め 結論 検証 スイッチロール マルチアカウントでの認証 パターン1: Sign-in ユーザにスイッチ許可 マネジメントコンソール上での Switch role 後の Switch role パターン2: Roleにスイッチ許可 パターン3: ロールの連鎖 Awsume Console Plugin インストール Sign-in URLの発行 例:パターン2 の Role(a) 例:パターン3 の Role(a) Sign-in 前には Sign out が必要 馴れ初め 🤷:多段スイッチロールだとマネジメントコンソール使えなくなりますね 👼:awsume でできるんじゃない 🤷:マネジメントコンソールの仕様上できないっぽいですけど ... 🤷:できた 結論 AWSume のプラグイン awsume-c
いずれも提供されてからしばらく経ちますが、組み合わせてみるとややこしいことになったので整理してみます。 IAM 認証を使用した Amazon RDS および Aurora PostgreSQL データベースアクセスの保護 | Amazon Web Services ブログ Amazon RDS Proxy を使用したアプリケーションの可用性の向上 | Amazon Web Services ブログ RDS Proxy の利用用途は Lambda を想定しているようで、Lambdaに機能として持っていますし、情報も多いです。(本稿でLambda部分は触れてません) AWS LambdaでAmazon RDS Proxyを使用する | Amazon Web Services ブログ 目次 目次 認証パターン 設定パターン (※)設定について (※1) (※2) ユーザ単位での併用パターン 認証
macOS からWindows を経由して SSH する機会があったため、調査した内容を残しておきます。 Web上で色々情報が見つかったのですが、現在では古い情報も混ざっているため自分用に整理した内容です。 要件 結果 Linuxでのncコマンド Macでのncコマンド 調査 HTTP Proxy 経由のSSH netcat(nc)色々 Ncat(Nmap付属) OpenBSD netcat Amazon Linux の例 Ubuntu の例 Netcat Darwin Port GNU netcat 要件 macOS -> win_proxy(Windows) -> web(Linux) 上記のように直接接続が許可されていない、win_proxy(WindowsのProxyサーバ)の背後のweb(Linuxサーバ)に対し、 macOSからSSH接続を行います。 HTTP tunnel -
AWSの監視をCloudWatch以外(SaaS等)で行っている場合に、AWS API のコール数が気になります。 CloudTrail で証跡を保存、解析すれば詳細に分析できると思いますが、諸事情によりその手法が使えなかったので調べてみました。 AWSサービス CloudTrail Event Trail(証跡) Amazon Macie 主要なSaaSのAPI実行間隔 Datadog Mackerel New Relic 可視化してみる 留意点 没案 AWSサービス 関連するAWSサービスの概要です。 CloudTrail Event APIの実行履歴は CloudTrail Event で表示・取得できます。 How CloudTrail Works - AWS CloudTrail CloudTrail Workflow - AWS CloudTrail CloudTrail は、
Datadog Logs のアップデートがありました。 大きく以下3つの機能が追加されています。 Introducing Logging without Limits Limitless Logs ログ取り込みとインデキシング(フィルタリング)の分離 Archive Logs ストレージ転送 Live Tail リアルタイムログストリーム 既に公式ドキュメントも公開されていますが、ポイントを整理します。 Limitless Logs Archive Logs Configure S3 Bucket Define Archive フォーマット Live Tail Limitless Logs Logging without Limits 送信元でのフィルタを行わず、 Datadog 管理画面上でフィルタが可能です。 フィルタにより除外されたログは、Datadog Logs 課金対象からも除外
結構前からアナウンスはされているのですが、すぐ忘れるので残しておきます。 Datadog だけでは無いですが、Slack側仕様変更により、Slack上の個別ユーザへメンションする際の指定の仕方が変わります。 A lingering farewell to the username | Slack The undocumented approach to mentioning users via the API — <@username> — will no longer function after September 12, 2018. Please reference with the user ID format (<@U123>) instead 既に始まっていて、使えなくなっている状況もあるようです。 Slack APIでユーザー宛のメンションができなくなったので対策した - Q
Datadog Monitor の定義を Terraform で管理できます。 Provider: Datadog が、Datadog側がJSONで定義されており少々書き難いのと、 Monitor毎に同じ記載を繰り返す部分(通知本文や通知先)をテンプレート化できないものかと思い、考えてみた結果をメモ。 Terraform の Template Provider で実現します。 バージョンによっては動作しないですし、もっと良い方法・書き方が有りそうではあります。 目次 目次 要件 環境 ファイル構成 datadog_key.auto.tfvars datadog_monitor.auto.tfvars datadog_monitor.tf datadog_monitor_template.tf templates/ message.tmpl notify.tmpl 作成例 作成結果 要件 複
Nagios を利用して時刻同期の監視を行う場合にプラグインが複数有り、ヘルプのみだと腑に落ちなかったので簡単にまとめます。 公式プラグイン集をベースに確認します。 Nagios Plugins | The home of the official Nagios® Plugins 目次 目次 Nagios ntp plugins check_ntp_peer chrony 未サポート check_ntp_time (check_ntp) 参考URL Nagios ntp plugins 公式プラグインとして用意されているのは以下です。 check_ntp check_ntp_peer check_ntp_time check_ntp は現在は非推奨となっており、 check_ntp_peer または check_ntp_time を利用します。 check_ntp_peer = ntpサー
Datadog logs(パブリックベータ) を試してみる の続きで、 Datadog でのログ管理機能(パブリックベータ版)での検証履歴です。 htnosm.hatenablog.com 今回はログを送信する側での除外、置換、複数行を確認します。 公式 Log Management 目次 目次 ログ収集設定 基本的な設定値 インテグレーションのログ収集設定 未サポートのログ収集設定 Advanced log collection functions (収集ルール) exclude_at_match 送受信例 include_at_match mask_sequences 送受信例 multi_line 送受信例 ログ収集設定 基本的な設定値 # 必須 - type: 入力タイプ (tcp/udp/file) # 入力タイプにより port/path のいずれか #port: tcp/ud
先日 CloudWatch Agent が発表されました。 新発表 – Amazon CloudWatch AgentとAWS Systems Managerとの連携 – 統一されたメトリクスとログの収集をLinuxとWindowsに | Amazon Web Services ブログ SSM Agent 導入が前提、となるとマネジメントコンソールすら使う必要が無いだろうということで、AWS CLI (aws ssm) での導入方法です。 公式導入手順 Collect Metrics from Amazon EC2 Instances and On-Premises Servers with the CloudWatch Agent - Amazon CloudWatch Metrics Collected by the CloudWatch Agent SSM Agent CloudWa
Datadog でのログ管理機能(パブリックベータ版)が発表されました。 Introducing logs in Datadog Datadog Agent もメジャーバージョンアップとなり、色々と変わるようなので正式リリース前に触れてみます。 ベータではありますが、現行環境へすんなり導入できるかという観点で試します。 (利用するには Datadog 側へ申請し、 Activate されていることが前提になります。) 既存環境へのインストール 環境 Agent Ver 6 へのアップグレード Amazon Linux / CentOS6 / CentOS7 Ubuntu 14 / Ubuntu 16 5.x -> 6.x での変更点 起動/停止/再起動 info (Agent 詳細情報出力) 設定ファイル ログ収集有効化 設定ファイル修正 新規ファイルで作成する場合 対象ログの確認 収集し
Datadog のコマンドラインツール dog (dogshell) を使ってみようと思いましたが、あまり情報が無かったのでまとめてみます。 Datadog公式のツールで、ライブラリをインストールすることにより使用できるようになります。 DataDog/datadogpy: The Datadog Python library 目次 インストール 設定ファイル(.dogrc)の作成 オプション optional arguments: 出力オプション デフォルト(指定無し) raw pretty 番外(複数指定) Modes: インストール README を参考にインストールを行います。 今回は素に近い CentOS7 で試してます。必要パッケージは環境により変わると思います。 # cat /etc/redhat-release CentOS Linux release 7.1.1503 (
Amazon DynamoDB Auto Scaling の発表 AWSマネジメントコンソールで新規テーブルを作成すると、デフォルトで Auto Scaling が有効な状態で作成されるようになっているそうです。(変わっていないAWSアカウントもありましたので、既存環境はIAM Role等々を用意しないと切り替わらないのかもしれません。) デフォルトで Auto Scaling 有効 デフォルトで Auto Scaling 無効(既存) 以下、既存テーブルへ適用しようとした際に調査した内容です。 DynamoDB Auto Scaling 設定値 DynamoDB Auto Scaling 有効化で作成されるリソース IAM Role DynamoDBAutoscalePolicy Trust Relationship Application Auto Scaling ScalableTa
AWSのモニタリングサービスCloudWatchからメトリクス(データ)を取得します。 自動でデータ収集、グラフ表示できる便利なサービスですが、値の一覧を見る画面は用意されていません。 グラフ上でカーソルを当てるとその部分の数値は表示できます。 グラフではなく値の一覧が見たいという要望があったので、AWS CLIを使用して取得してみます。 get-metric-statistics データは aws cloudwatch get-metric-statistics で取得します。構文は以下の通りです。 get-metric-statistics --namespace <value> --metric-name <value> [--dimensions <value>] --start-time <value> --end-time <value> --period <value> --
Datadog Monitor 通知先の振り分け設定パターンです。 前提 基本形 アラートレベルで振分 タグの値で振分 タグで指定 前提 通知先のインテグレーション設定を済ませておきます。 今回は Slack インテグレーションで試してます。 ちなみに今回は通知先しか設定していませんが、同様に通知する本文も振り分け先により変更できます。 基本形 Monitor設定画面の Notify your team から定義済みの通知設定を選択することで、本文(Say what’s happening) に自動的に入力されます。 複数設定も可能です。 メールアドレス通知については定義済み通知先の他に、直接指定も可能です。 Monitor(監視)機能の設定ガイド (例えばuser@example.comなら@user@example.comと記述)。 アラートレベルで振分 テンプレート変数を利用し、Al
Terraform Datadog Provider で利用できるリソースの内、Downtime,Monitor,User がインポートに対応しています。 Downtime,MonitorはそれぞれのID、UserはDatadogアカウントのメールアドレスを指定することでインポートが可能です。 # Downtime terraform import datadog_downtime."リソース名" "ダウンタイムID" # Monitor terraform import datadog_monitor."リソース名" "モニターID" # User terraform import datadog_user."リソース名" "ユーザメールアドレス" 使用する ID などはそれぞれ以下のページで確認できます。 Downtime https://app.datadoghq.com/monit
Datadog公式のツール dog 使用方法まとめ monitor 編です。 目次 monitor Modes post positional arguments: optional arguments: 実行例 オプション無し metric alert service check event alert name オプション message オプション options オプション ファイル形式 update 実行例 show 実行例 show_all 実行例 delete 実行例 mute_all | unmute_all 実行例 mute_all unmute_all 通知 mute | unmute optional arguments: 実行例 mute|unmute scope オプション mute→unmuteでscopeを変える事は不可 end オプション(mute) all
Mackerel のアップデートで Webhook の API Gateway 対応が発表されました。 mackerel-agent経由でのメタデータ登録に対応しました ほか - Mackerel ブログ #mackerelio Webhook のリクエスト先に API Gateway のエンドポイントを指定できるようになりました 通知先として選択できる Webhook の対応証明書が拡張され、Webhookの対応先が増えました。 これにより多くの要望を頂いておりました Amazon API Gateway にも対応しました。 AWS Lambda を Amazon API Gateway 経由で呼び出すことも可能です。 アップデート前は通知先に直接 API Gateway の指定は行えていなかったようです。(アップデート前に検証はしてませんでした) 個人的に色々 Webhook からの
前回 Datadog から SNS 経由で Lambda Function を起動を行いました。 Datadog MonitorからSNS経由でLambda起動 - vague memory 別の方法を探してみた所、Webhook Integration が使えそうだったので試してみました。 Datadog-Webhooks Integration 1) API Gateway と Lambda Function を作成 API Gateway を trigger として Lambda Function を作成します。APIへは AccessKey認証 とします。 今回使用した Lambda Function は、受け取った内容をそのまま Slack へポストするだけの物です。 2) CloudFront Distribution 作成 API Gateway の Endpoint をその
CloudWatch Logsを使用したログ監視です。 CloudWatch Logs のメトリックフィルタから Alarm を作成し、SNS メッセージをSlackへ投稿する Blueprint が提供されていますが、 通知されるメッセージだけでは Alarm が発生した事がわかるのみなので、ログ本文を通知したいと思いました。 参考:New – Slack Integration Blueprints for AWS Lambda 通知先(Slack)以外はAWSで完結可能な方法という所で、Lambda(Python)を使用した2パターンを試します。 (1) SNSを経由してSlack通知 (2) Stream to AWS Lambda でSlack通知 図内黒矢印は Blueprint を使用した場合 メトリクスに過去発生頻度を残したいというのであれば(1)、 通知先固定でエラー発生
Nagios で通知(Notifications)の有効/無効切替を curl で実行します。 _NAGIOS="nagios.example.com" _NAGIOS_USER="nagiosadmin" _NAGIOS_PASS="nagiosadmin" _HOST="localhost" ## 無効化 # Disable notifications for this host curl -s -S http://${_NAGIOS}/nagios/cgi-bin/cmd.cgi -u ${_NAGIOS_USER}:${_NAGIOS_PASS} -d "cmd_mod=2&cmd_typ=25&host=${_HOST}" \ | grep 'Message' # Disable notifications for all services on this host curl -
mkr v0.11.1 で dashboardsサブコマンドが追加されています。 連続リリース100週目!ダッシュボード生成ツールをリリースしました・ユーザーグループ発足 - Mackerel ブログ #mackerelio 公式に詳細説明があります。 CLIツール mkr を使う - Mackerel ヘルプ が、どういう風に見えるのかは載っていないので、説明にある内容でのダッシュボード表示を試してみます。 dashboards mkr v0.11.1 以上で dashboards コマンドを使用できます。 $ mkr help | grep -A 1 -e VERSION -e dashboards VERSION: 0.11.3 -- dashboards help, h Shows a list of commands or help for one command dashboa
追記 よく質問されるので追記。 DatadogにはAWSで発生したイベントを拾ってくれる機能がありますが、RDSのイベントは含まれていません。 投稿時点の話で、現在はRDSイベントもDatadog上で取得できます。 RDSのイベント通知機能としてEvent Subscriptionがあり、イベント発生時に任意のメールアドレスに通知ができます。 メールのアラート受信は埋もれやすいので、DatadogとSlackへ通知します。 基本的にはメール送信による投稿が可能なサービスへの連携が可能と思います。 目次 RDSイベント通知 Datadogへ通知 Slackへ通知 RDSイベント通知 設定すると以下の様なFailover等のイベント発生時に設定したメールアドレス宛に通知してくれます。 RDSイベント通知設定 AWSマネジメントコンソールのRDSダッシュボードから EventSubscripti
AWS EC2 インスタンスには、 Status Checked Failed 発生時に自動的に復旧を試みる機能があります。 設定自体は正しく行えているように見えるのに、いざ異常発生時に復旧に失敗するケースに当たりました。 Action failed. Encountered error calling EC2 recover. (401: AWS was not able to validate the provided access credentials) 復旧に失敗した RecoveryAlarm は IAM Role を使用して CloudFormation で作成していましたが、作成(設定)自体は正常に行えていました。 結論としてはドキュメントに記載があるのですが、IAM Role で復旧アラームを作成している場合、復旧アクションは動作しません。 Troubleshoot In
Mackerel の将来予測機能を試してみます。 機能としては式による監視で特定の関数(線形回帰)を使って実現するようです。 将来予測機能による監視・グラフ範囲をURLに反映されるように ほか - Mackerel ブログ #mackerelio 式による監視を行う - Mackerel ヘルプ 将来予測機能 式による監視の仕様 公式サイトの記載より 監視間隔は5分ごと 設定可能な式は、グラフの系列が1本になるものだけ 式が複雑過ぎる等で値が取れない場合はステータス Unknown としてアラートが発生 監視項目上限数20 Free プランでは使用不可 線形回帰関数 使用できる関数は カスタマイズしたグラフを表示する - Mackerel ヘルプ で確認できます。 linearRegression(metrics, duration) 現在時刻から duration 前 までのメトリック値
Mackerel で mkr と WebAPI を使用して poweroff にしたホストを退役します。 今回の判定条件は n日前のメトリクスが無いホストとします。(poweroff 直後のホストは非対象としています) ApiKey/URL/Metricsを設定 検索対象のメトリクスは loadavg5 等必ず存在する物を指定します。 export MACKEREL_APIKEY='XXXXXXXXXX' _MACKEREL_URL="https://mackerel.io/api/v0" _METRICS="loadavg5" # 処理実行当日を含む日数 _KEEP_DAY=1 日数(epoch秒)生成 _KEEP_TO=$(date --date ''${_KEEP_DAY}' days ago' +'%Y-%m-%d 15:00:00') _KEEP_TO=$(TZ=UTC date
Jenkinsを使っていて、複数環境を使い分ける必要が出てきた場合に、 見た目が全部一緒で判り難いので環境別に表示を変えたいと思いました。 Jenkinsの標準機能では存在せず、Simple Theme Plugin を使用するのが定石のようなので、こちらを使用します。 Simple Theme Plugin - Jenkins - Jenkins Wiki 変更点 ヘッダーの色と Jenkins の文字部分を変更します。ついでにジェンキンスおじさまにはご退場いただきます。 おじさまとJenkinsロゴはトップページへのリンクが付与されていますが、無くなっても支障が無いので文字列に置き換えます。 環境 Jenkins Ver: 2.7.1 css と js の格納 ${JENKINS_HOME}/userContent に css と js を格納します。 theme.css backgr
DatadogのMonitorでの通知設定で復旧(Recovery)通知を行わない方法です。 template variables 内に通知先を設定する 通知先を含めて {{#is_alert}}{{/is_alert}} もしくは {{^is_recovery}}{{/is_recovery}} 内に記載 します。 言われてみればなるほどなのですが、しばらくこの発想に至らず、復旧通知は必須なのかと誤解していました。 以下誤解していた理由(言い訳)です。 例文を見ただけではわからなかった 初期表示状態の例文を見て、 {{#is_alert}}|{{#is_recovery}}を使って、異常時と復旧時の通知メッセージを変える物と認識しました。 (そのような使い方ももちろん可能です) 通知先指定時に末尾に設定される このような感じで(3)のアラート文面を書いた後に(4)の通知先を設定すると、ア
前回 AWS Lambda で CloudWatch Logs のログ本文をSlack通知(1) の続きです。 SNSを介さず、Lambdaから直接Slackへ投稿する方法です。 (2) Stream to AWS Lambda でSlack通知 CloudWatch Logs -> Lambda -> Slack CloudWatch Logs のサブスクリプションを使用 参考 サブスクリプションを使用したログデータのリアルタイム処理 cloudwatchlogs -> lambda -> SNSを試してみた - Qiita 各種設定 Blueprints冒頭に記載されている Slack Integration や KMS の設定については割愛します。 Lambda Function 作成 [Services] -> [Lambda] -> [Create a Lambda Functi
次のページ
このページを最初にブックマークしてみませんか?
『vague memory』の新着エントリーを見る
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く