こんにちは、社会人2年目の秋葉です！ 最近、本格的にAWS関連の案件にアサインされ、インフラ構築や運用に関わる機会が増えてきました。 これまでの学習や研修とは異なり、実務でAWSに触れる中で、「ドメイン名の管理って意外と奥が深いな…」と感じる場面が多くなってきました。 DNS解決といったら、みなさんご存じ「Route53」ですが、社内のナレッジ（TechHarmony）を調べてみると、Route 53について詳しくまとめられた記事や事例が意外と少なく、体系的に学ぶにはやや苦労する印象を受けました。 そこで本記事では、 これからAWSを扱う方や、Route 53をあまり理解してない方々 に向けて、Route 53の主要機能を紹介していこうと思います！！ この記事をみたらRoute53マスターに近づけること間違いなしです！ Route53とは 突然ですが、インターネットを「大きな街」と考えてみましょう。 行きたいお店があったとき、あなたはどうやってそこにたどり着きますか？ もちろん、目的地をスマホで検索して向かうはずだと思いますが、住所まで丁寧に調べてなどいませんよね…、 インターネットの世界でも同じように、「192.0.2.1」とか「54.213.88.45」みたいな数字の羅列であるIPアドレスなど正直覚えられません…。 そんなときに活躍するのが「 DNS（Domain Name System） 」という仕組みです。 DNSは、インターネットの住所録のようなもので、「example.com」などの覚えやすい名前を、「192.0.2.1」などのIPアドレスに変換してくれる役割を担っています。これによって、私たちは難しい数字を覚えることなく、目的のWebサイトにスムーズにアクセスできています。 そして、このDNSの役割をクラウド上で高い信頼性・スケーラビリティをもって提供してくれるサービスが Amazon Route 53 です。Amazon Route 53は、AWSが提供するマネージドDNSサービスで、以下のような特徴があります。 ドメイン名とIPアドレスの変換（名前解決）を高速かつ安定して提供 自動でのフェイルオーバーやヘルスチェック機能による可用性の向上 AWSの他のサービスとの統合による柔軟なシステム構成 世界中のDNSサーバーネットワークによる高速レスポンス つまり、Route 53を使えば、 柔軟で信頼性の高いDNS環境 を簡単に構築・管理できるというわけです！ これから、Amazon Route 53の基本的な使い方や設定のポイントについて、具体的にご紹介していきます。   ここで 余談 なのですが、「Route 53」という名前は、アメリカの有名な国道「ルート66」にちなんでいるそうです。 「情報のハイウェイを安全に導く道しるべ」という意味合いが込められており、53はDNSで使われるポート番号「53番」に由来しています。   マネージドコンソールで見たRoute53 さっそくAWSマネージドコントロールでRoute53を見てみましょう！ 本記事（基礎編）では赤枠の部分の機能を中心に説明していきます。 以下のようなメニュー構成になっていません。 見慣れない用語など、最初は少しとっつきにくく感じるかもしれませんが、慣れてしまえば直感的です。 ダッシュボード ：サービスの全体状況やゾーン一覧を確認できます。 ホストゾーン ：DNSレコードの設定を行うエリアです。ここでドメインごとにレコードを管理します。 ドメインの登録 ：Route 53で独自ドメインを購入・管理する機能です。 ヘルスチェック ：指定したエンドポイントの状態を監視できます。 プロファイル ：登録した設定値を他VPC内に反映することができます。 ホストゾーンとは ホストゾーン（Hosted Zone）とは、あるドメイン名に対してのDNSレコードを管理するための領域です。 例えるなら「1つのドメインのDNS設定をまとめて管理するフォルダ」と考えるとわかりやすいです！ 例えば、「example.com」 といったドメインを使う場合、そのドメイン用にホストゾーンを作成し、その中に「Aレコード」や「CNAMEレコード」などのDNSレコードを登録していく流れとなります。（※レコードについては後ほど説明） パリックホストゾーンとプライベートホストゾーンの違い 上の画像でもわかるように、ホストゾーンには 「 パブリック 」 と 「 プライベート 」 の2種類があります。 違いは次の通りとなっています。 種類 特徴 主な用途 パブリックホストゾーン インターネット全体からアクセス可能 Webサイトの外部公開など プライベートホストゾーン VPC内部のみで名前解決可能 社内システムや検証環境など パブリックゾーンでは、インターネットに公開するドメイン（例：public.example.com）を管理し、世界中からアクセスされるWebサービスなどに利用します。 一方、プライベートゾーンはVPCと紐づけて使い、特定のネットワーク内だけで有効な名前解決を行います。用途としては、社内システムや検証環境を構築するケースが多いです。 DNSレコード（A / CNAME / MX / TXT）とは DNSレコードとは、「特定のドメインにアクセスしたときに、どのサーバーと通信するか」を決めるための 設定情報 です。 例えば、「example.com といったドメインにアクセスすると、IPアドレスが 192.0.2.1 のサーバーに接続される」といった情報は、Aレコードと呼ばれるDNSレコードによって管理されます。 DNSレコードにはさまざまな種類があり、それぞれ異なる役割を担っています。 今回は多数のレコードのうちで、よく使う４つのDNSレコードを簡単に紹介します！ レコード名 説明 用途 例 A レコード 「ドメイン名」と「IPv4アドレス」を紐付ける。 Webサーバーやメールサーバーなど、IPv4で通信するサービスの宛先指定 名前 → IPv4 CNAME レコード 「あるドメイン名」を「別のドメイン名」に変換する。 サービス名やサブドメインのリダイレクト、可用性向上のためのエイリアス利用など 名前 → 別名 MX レコード メールの配送先を指定する。 メールサーバーの冗長化（複数定義可能）、受信ドメインの設定 メール配送先 TXT レコード テキスト情報をDNSに設定する。 サービス連携のドメイン所有確認、テキスト情報の登録 テキスト情報 ヘルスチェックとは ヘルスチェックとは、特定のエンドポイント（例：WebサーバーやAPIなど）が正常に動作しているかを定期的に確認し、問題が発生した際には自動的に別の健全なエンドポイントへ トラフィックを切り替える ことで、サービスの継続性を保つ仕組みです。   プロファイルとは Route 53のDNS関連設定（プライベートホストゾーン、Resolverの転送ルール、DNSファイアウォールルール）を「プロファイル」というひとまとまりで定義でき、そのプロファイルを、同じリージョン内の 複数のVPCに一括適用で きるようになります。 おわりに ここまで、AWS Route 53の主要な機能について解説してきました。 私自身、実際に業務でRoute 53を使う中で、「DNSの奥深さ」や「どんな場面で何を使うか」を肌で感じることが多く、学び直すたびに新たな発見がありました。 最初は専門用語や仕組みに戸惑うことも多いかと思いますが、本記事が、「Route 53ならこういうことができる！」「この機能はこんな場面で役立つ！」という気づきのきっかけになればとても嬉しく思います。 本記事で紹介したポイントを軸に、ぜひ自身のプロジェクトや業務の中でRoute 53を活用してみてください。 これからAWSを使うみなさんの挑戦や成長の一助になれば幸いです。 ぜひ一緒に、“ Route 53マスター ”を目指して頑張りましょう！

こんにちは、2年目の加藤です！ 私は最近、Microsoft Fabricを使用したデータ加工の技術検証を行っています。Microsoft Fabricは2023年から一般リリースされたということもあり、技術ドキュメントが少なく、戸惑う部分があったので「使ってみた」として記事に残そうと思います。 構成図 Microsoft Fabric レイクハウスでメダリオン アーキテクチャを作成する | mslearn-fabric.ja-jp 今回は、上記のMicrosoft公式が出しているハンズオンを中心にデータ取得・加工を行っていきます。 ハンズオンの構成図としては、下記のようになっています。 メダリオンアーキテクチャとは？ データ分析やデータプラットフォームの設計において使用される一般的なアーキテクチャのフレームワーク。ブロンズ、シルバー、ゴールドのレイヤーが存在する。 ブロンズ ：未加工のデータを格納 シルバー ：クレンジング済み（欠損値補填、重複排除など）データを格納 ゴールド ：BIツールや機械学習で使用しやすい形（ビジネスに特化した形）に整形したデータを格納 しかし、このハンズオンではNotebookを利用しており、データ変換過程が何を行っているのか分かりづらいので、本記事では、Data Factory内のDataflow Gen2というGUIベースでデータ格納を行えるアイテムを使用します。 改めてDataflow Gen2を使用した構成図を下記に示します。 手順 環境準備 1 Microsoft Fabric用アカウントを作成する 現在、誰でも60日間無料でFabricを利用できるので、それを利用してアカウントを作成します。 始める | Microsoft Fabric 2 Fabric内でワークスペースを作成する 画面左側の「ワークスペース」>「新しいワークスペース」を押下します。 ワークスペースの名前を入力し、画面右下の「適用」を押下します。 テストデータを準備する 1 売上csvデータをダウンロードする ハンズオンで案内されているcsvファイルをローカルにダウンロードします。 Microsoft Fabric レイクハウスでメダリオン アーキテクチャを作成する | mslearn-fabric.ja-jp 2 レイクハウスに売上データを格納する Fabricワークスペース上から「新しい項目」を押下し、「レイクハウス」を選択します。 新しいレイクハウスに名前（例 Sales）を入力し、「作成」を押下します。 レイクハウス内の画面左側タブの「Files」>「新しいサブフォルダー」にて、データ格納のためのフォルダ（例：bronze）を作成します。 新しく作成したフォルダーを押下し、画面上部の「データを取得」>「ファイルのアップロード」を押下し、ローカルにダウンロードしたcsvファイルをアップロードします。 アップロードしたファイルが存在することを確認します。 アップロードしたファイルが確認できない場合、フォルダーにカーソルを合わせた際に表示される「 ︙ 」を押下し、「最新の情報に更新」を押下します。 これで、売上データをFabric上に格納することができました。 データを加工する ハンズオンでは、データ加工として下記プロセスを行っています。 売上データのクレンジング及びテーブル化 テーブル化したデータから各種データ（顧客、製品、日付）を抽出 各種データ（顧客、製品、日付）から最終売上テーブルを作成 本記事では、「売上データのクレンジング及びテーブル化」をデータ加工の例として記載します。   1 Dataflow Gen2を作成する 対象のワークスペースで「新しい項目」を押下し、「データフロー（Gen2）」を選択します。 名前（例：Transform data for Silver）を入力し、「作成」を押下します。 2 データを取得する 「データを取得。」を押下します。 レイクハウスを選択し、デフォルト設定のまま「次へ」を押下します。 先ほど作成したレイクハウス内のフォルダの売上データを選択し、「作成」を押下します。 作成していないフォルダが存在する場合があるが、これはFabricが裏側で使用するデータが見えているだけなので無視して良い 3 データを加工する ハンズオン内では具体的に下記のデータ加工を行っています。 列名の変更 データ型の変更 ソースcsvファイル名を格納する列の追加 現在時間を格納する列の追加 2019/8/1より古いデータにフラグを立てる列の追加 列名の変更 プレビュー画面の列名をダブルクリックし、適切な列名をつけます。   データ型の変更 基本的に自動でデータ型を読み込んで変換をしてくれますが、任意で変更したい場合にはプレビュー画面の列名横のアルファベットや数字などのイラストを押下して変更することができます。   ソースcsvファイル名を格納する列の追加 「列を追加します」>「カスタム列」を押下します。 列名（例：FileName）とデータ型に「テキスト」を選択し、カスタム列の式にソースcsvファイル名（例：”2019.csv”）を入力します。   現在時間を格納する列の追加 「列を追加します」>「カスタム列」を押下します。 列名（例：CreatedTS）とデータ型に「日付/時刻」を選択し、カスタム列の式に下記の数式を入力します。 DateTime.LocalNow()   2019/8/1より古いデータにフラグを立てる列の追加 「列を追加します」>「条件列」を押下します。 列名（例：IsFlagged）を入力し、それ以外の条件を下記のように設定します。 列名 演算子 値 出力 Else OrderDate 次の値より前: 2019-08-01 true false データ型が「任意」になっているので、「True/False」に変換します。   以上の操作で、売上データのクレンジングができました。 今回の例では、2019年の売上データしか取り込んでいないのですが、2020年の売上データや2021年の売上データを取り込み、全てのデータを結合させることもできます。 データの結合 2019年と同様の操作を行い、2020年、2021年のデータを用意します。 「ホーム」>「クエリをアペンドする。」を押下します。 「3つ以上のテーブル」を選択し、追加するテーブルを選択します。   加工したデータをテーブルに保存します。 テーブル化したいクエリ内の「︙」の横にある「データ同期先の追加」>「レイクハウス」を押下します。 レイクハウスを選択し、デフォルトの接続設定のまま、「次へ」を押下します。 以前レイクハウスを使用した際の接続情報が残っているため、デフォルトの設定となります。 「新しいテーブル」を選択し、保存したいワークスペース、レイクハウス（例：test_kato/Sales）を選択します。 テーブル名（例：sales_silver）を入力し、「次へ」を押下します。 列マッピングはデフォルトのまま、「設定の保存」を押下します。 以上でテーブルとして保存するための設定ができました。 その後は、「ホーム」>「保存と実行。」を押下します。 実行が終わると、先ほど指定したレイクハウスにテーブルができます。 テーブル化することで、Power BIなどからテーブルを参照し、レポートとして利用することができます。 おわりに 本記事では、データの取得、データの加工をMicrosoft Fabircを使用して行ってみました。Dataflow Gen2を使用することで、データエンジニアではなくても、GUIベースでポチポチとボタンを押すことでデータ加工を行えるので、初心者の方でも取っつきやすいサービスだと感じました。ただ、データ加工をごりごりにやってこられた方にとっては、クエリでデータ加工を行った方が間違いも少なく、圧倒的に早くデータ加工ができるので、Dataflow Gen2だと物足りなさを感じるかもしれません。 Microsoft FabricはPower BIとの親和性が高く、Power BIを使われている企業は多いので、ある一定の需要があると思います。お客様への提案の幅を広げる、技術の幅を広げるという意味でも、一度Microsoft Fabricを触れてみてはいかがでしょうか？

こんにちは、高坂です。 前回の記事 では、PrismaCloudのアラートデータからアラートタイプ毎のアラート件数と重要度を取得してバブルチャートを作成しましたが、今回はそれにアラート解決状況の情報を追加して可視化を試みてみました。 Prisma Cloudではコンソールから取得できるデータがいくつかあり、アラートデータもそのひとつです。 このデータには、アラートの重要度（Severity）だけでなく、そのアラートが現在どのような状態にあるかを示すステータス（例：Open, Resolved, Dismissed）も含まれています。 日々大量に発生するアラートの中から、どの種類のアラートが、どれくらいの量と重要度で発生し、どの程度きちんと対応されているのかを読み取るのは、なかなか大変な作業です。 今回は、アラートのステータス情報に着目し、「数」「重要度」に加えて「解決状況」データを分析することで、クラウド環境のセキュリティ状態を1枚の図で直感的に可視化できないか試してみました。 取得データの紹介 まず、アラートデータはPrisma Cloudコンソールの「アラート画面」の「csvファイルをダウンロード」から取得できます。 csvファイルに記載されているカラムは以下22項目です。 No. カラム 説明 1 Alert ID アラートに割り当てられた一意の識別子 2 Policy Name アラートをトリガーしたポリシーの名前 3 Policy Type ポリシーのタイプ（ CSPMを利用した際に主に利用されるタイプは iam, config, networkなど） 4 Description アラートが何を意味するのか、なぜトリガーされたのかについての詳細な説明 5 Policy Labels ポリシーに関連付けられたカスタムラベルまたはタグ 6 Policy Severity アラートの重大度レベル（Critical, High, Medium, Low, Informationalの5段階） 7 Resource Name アラートに関係するクラウドリソースの名前 8 Cloud Type クラウド環境の種類（例：AWS, Azure, GCP, Alibaba Cloud） 9 Cloud Account Id リソースが存在するクラウドアカウントのID 10 Cloud Account Name クラウドアカウント名 11 Region クラウドリソースが配置されているリージョン 12 Recommendation アラートをトリガーした問題を解決するための推奨されるアクション 13 Alert Status アラートの現在のステータス（例：Open, Dismissed, Resolved） 14 Alert Time アラートが生成されたタイムスタンプ 15 Event Occurred アラートをトリガーしたイベントが実際に発生したタイムスタンプ 16 Dismissed On アラートが無視されたタイムスタンプ 17 Dismissed By アラートをDismissed処理したユーザー 18 Dismissal Reason アラートをDismissedした理由 19 Resolved On アラートが解決済みとしてマークされたタイムスタンプ 20 Resolution Reason アラートを解決した理由 21 Resource ID アラートに関係するクラウドリソースの一意の識別子 22 Account Groups そのクラウドアカウントが属するPrisma Cloudのアカウントグループ 今回はこの中から「Policy Type」、「Policy Severity」、「Cloud Account Id」、「Alert Status」を使用していきます。 可視化の準備：分析シナリオと仮想データの作成 今回は実際のアラート情報ではなく、仮想的なアラートデータを作成し、どのように可視化分析ができるかご紹介します。 可視化分析をするにあたって3つシナリオのクラウドアカウントのアラート状況を想定して用意しました。以下簡単な説明です。 Cloud Account ID シナリオ 111122223333 基本的な設定ミス（config）に関するアラートが圧倒的に多い。次いで、IAMロールの権限設定ミス（iam）が散見が、アラートへの対応が追いついていないような環境。 結果として、アラート総数は多く、解決率が非常に低い状況。 444455556666  基本的な設定ミスはほとんどなく、configやiamのアラートは非常に少ない。 しかし、外部に公開されているサービスのため、不審なアクティビティや攻撃の兆候（anomaly, network）に関するアラートが時折発生する。 これらのアラートは深刻度がhighと高いが、迅速かつ的確に対応している環境。 結果として、アラート総数は少なく、解決率が非常に高い。  777788889999 configやnetworkの重大なアラートは少ない。 しかし、不要な権限を持つIAMロールや長期間利用されていないユーザー（iam）に関するアラートが継続的に発生している。 これらのアラートは即時的なリスクが低いため、対応の優先順位が低く、対応が中途半端になっている環境。 結果として、アラート総数、深刻度、解決率すべてが中程度。   各アカウントの具体的なアラート発生状況は以下の通りです。 左列の「Policy Type」と、上段の「Policy Severity」の組み合わせごとに、発生したアラートの件数を示しています。 また、各セルには総件数、カッコ内に未解決件数の形式で、対応状況の内訳も記載しています。 Cloud Account ID=111122223333 Cloud Account ID=111122223333 informational low medium high critical iam 0(0) 0(0) 105(80) 14(12) 0(0) config 0(0) 212(169) 122(96) 0(0) 0(0) network 10(8) 8(6) 5(4) 2(2) 0(0) anomaly 0(0) 0(0) 23(21) 0(0) 0(0) Cloud Account ID=444455556666 Cloud Account ID=444455556666 informational low medium high critical iam 0(0) 0(0) 6(0) 0(0) 0(0) config 0(0) 0(0) 5(0) 0(0) 0(0) network 0(0) 0(0) 0(0) 19(1) 0(0) anomaly 0(0) 0(0) 0(0) 11(3) 9(0) Cloud Account ID= 777788889999 Cloud Account ID= 777788889999 informational low medium high critical iam 0(0) 57(18) 55(17) 0(0) 0(0) config 0(0) 55(24) 0(0) 0(0) 0(0) network 0(0) 0(0) 25(15) 0(0) 0(0) anomaly 0(0) 0(0) 8(6) 0(0) 0(0)   Pythonによるデータ分析と可視化の実装 今回の可視化分析には、前回同様Pythonを使用しました。 主な利用ライブラリは、データの読み込みや加工を行う pandas と、グラフ描画を担当する matplotlib です。 処理の概要 処理の概要は以下の通りです。 Prisma Cloudからダウンロードしたアラートファイルからアラートデータを読み込む。 アラートの重要度（Severity）を数値に変換し、ステータスから「解決済み」か否かを判定する。 ポリシータイプ（Policy Type）ごとに、「アラート総数」「平均重要度スコア」「解決率」を集計する。 集計結果をもとにバブルチャートを生成する。 生成されるバブルチャートは、以下の要素で構成されます。 横軸:  ポリシータイプ (Policy Type) 縦軸:  そのポリシータイプにおけるアラートの平均的な重要度スコア バブルの大きさ:  そのポリシータイプで発生したアラートの総数 バブルの色:  そのポリシータイプにおけるアラートの解決率 このグラフによって、「どの分野で、どれくらい重要で、どれくらいの量のアラートが、どの程度対応されているのか」を一枚で表現します。 グラフ化の工夫点 今回の可視化で特にこだわったのは、「いかに直感的に状況を理解しやすくするか」という点です。そのために、以下の2つの工夫を実装に盛り込みました。 バブルの色 ：2色使用し、解決率を感覚的に読み取れるようにする まず、アラートの対応状況を視覚的に伝えるため、Alert Statusが「Resolved」または「Dismissed」のものを「解決済み」と定義し、ポリシータイプごとの解決率を、(Resolved数+Resolved数)×100/アラート数として算出しました。 そして、この解決率を赤（解決率0%）から緑（解決率100%）へと変化するカラーマップ（ヒートマップ）でバブルの色に反映させています。 これにより、例えば赤色に近いバブルがあれば「対応が遅れている危険な領域」、緑色に近ければ「きちんと対応されている健全な領域」ということが、一目で判断できるようになります。 バブルの大きさ ：アラート数を「対数スケール」で調整し、差を見やすく 次に、アラートの発生件数にはポリシータイプごとに大きな偏りがあるケースが考えられます。例えば、「configアラートが1000件、anomalyアラートが5件」といった極端な差がある場合、件数をそのままバブルのサイズに反映すると、小さい方のアラートは点のようにしか表示されず、グラフ上でほとんど見えなくなってしまいます。 そこで、アラート件数を対数（log）スケールで補正し、人間の感覚に近い差で表現されるようにサイズを調整しました。 この工夫により、件数が極端に少ないポリシータイプもグラフ上で無視されることなく、その存在と状況（重要度や解決率）をしっかりと把握できるようになります。   結果の表示 前述のPythonコードで処理したバブルチャートを実際に表示すると以下のようになります。 このグラフを見ることで、各クラウドアカウントにおいて、どのようなポリシータイプで、どれぐらいの重要度のアラートがどれだけ発生していて、どれだけ解決できているかを一目でだいたい把握できます。 再渇しますが、生成されるバブルチャートは、以下の要素で構成されます。 横軸:  ポリシータイプ (Policy Type) 縦軸:  そのポリシータイプにおけるアラートの平均的な重要度スコア バブルの大きさ:  そのポリシータイプで発生したアラートの総数 バブルの色:  そのポリシータイプにおけるアラートの解決率 Cloud Account ID：111122223333 anomalyやnetworkのアラート件数は少ない反面、configとiamのアラート件数が多いことがわかります。また、全体的に解決率が低い状況が読み取れます。   Cloud Account ID：444455556666 configやiamのアラート少ない反面、anomalyとnetworkアラート比較的多いことがわかります。 また、特にanomalyとnetworkのアラート重要度の平均が高いが、全体的に解決率は高い状態であることが読み取れます。 Cloud Account ID：777788889999 anomalyに比べて他アラートタイプのアラートが多いことがわかります。解決率は全体的に50%付近であることが読み取れます。   まとめ 今回はPrisma Cloudのアラートデータ（今回は仮想データを使用）をPythonで処理し、ポリシータイプごとの「アラート数」「平均重要度」「解決率」を一枚にまとめたバブルチャートを作成しました。 バブルチャートの「大きさ（数）」「高さ（重要度）」「色（解決率）」という3つの視覚的要素を用いることで、どのポリシータイプにアラートが集中し、その重要度はどれくらいで、さらにどの程度対応が遅れているのかを直感的に捉えることができます。これにより、膨大なアラート情報の中から「本当に注目すべき危険な領域」を特定し、セキュリティ対応の優先順位付けを行う際のひとつの判断材料になるのではないでしょうか。 今回紹介した手法は一例であり、データの性質や分析目的によっては、さらに多様な可視化や分析手法が存在します。今後もPrisma Cloudから取得できるデータのさらなる活用方法について、試行錯誤し結果を発信していければと考えております。 また、当社では、Prisma Cloudを利用して複数クラウド環境の設定状況を自動でチェックし、設定ミスやコンプライアンス違反、異常行動などのリスクを診断するCSPMソリューションを販売しております。ご興味のある方はお気軽にお問い合わせください。リンクはこちら↓ マルチクラウド設定診断サービス with CSPM｜ SCSK株式会社 マルチクラウド環境のセキュリティ設定リスクを手軽に確認可能なスポット診断サービスです。独自の診断レポートが、運用上の設定ミスや設計不備、クラウド環境の仕様変更などで発生し得る問題を可視化し、セキュリティインシデントの早期発見に役立ちます。 www.scsk.jp

こんにちは、SCSKの嶋谷です。 監視ツール(ZabbixやDatadogなど)では、それぞれの管理コンソールから監視対象で発生しているアラートや監視データを閲覧することができます。 Mackerelでもコンソールからアラートや監視データの閲覧が可能で、発生日時やアラート内容などが記載されています。 監視対象で発生している障害を復旧するためには、アラート内容を分析して対応方法を考える必要があります。 近年ではChatGPTやCopilotを利用して、AIに助言をもらうことが多くなっています。 しかし、ChatGPTやCopilotでは一般的な回答しか得られません。Mackerelで検知したアラートに対する助言を得るためには、プロンプトに発生日時やアラート内容を記載する必要があります。Mackerel専用のAIチャットボットを作りたいと思っていたところ、株式会社はてな様がMackerel MCPサーバーの提供を開始されました。 MackerelとAIでシステム専任の担当者を作る ―― Mackerel MCPサーバーで始めるアラート対応【前編】 これによりMackerel専用のチャットボットが作成できると考え、Mackerel MCPサーバーに触れてみたので紹介します。 MCPとは MCP(Model Context Protocol)は、AIモデル（特に大規模言語モデル：LLM）と外部ツールやデータソースを統一された方法で接続するためのオープンソースプロトコルです。2024年11月にAnthropic社が発表しました。 MCPの仕様に準拠して構築されたサーバーをMCPサーバーと呼び、AIからのリクエストを受け取り、外部のツールやデータソースと連携して必要な処理を実行して結果を返すことが可能となります。 これまで外部ツールと接続する場合は、個別にAPIやプログラムを作成する必要がありました。 MCPサーバーを利用すれば、個別に作成する必要が無くなり、同じ方法で多様な外部ツールに接続することが可能になります。 MCPについて ZabbixやDatadogなどもMCPサーバーに対応し始めています。 Mackerel MCPサーバーに触れる ここからMackerelのMCPサーバーのセットアップからチャットボットと対話までの流れを説明していきたいと思います。 構成 Mackerel MCPサーバーの構成図を下記に示します。 今回はユーザ自身のPCで動作するローカルMCPサーバーで環境を構築しました。 PCにClaude Desktopをインストールして、Mackerel MCPサーバーとの接続設定を行うことで簡単に環境を構築することができます。 環境構築手順 ここから実際の環境構築の手順について説明していきます。 Claude Desktopのインストール 下記リンクからユーザPCにClade Desktopをインストールします。 Download Claude インストール後アカウント登録を行います。(Googleアカウントでの登録も可能です。) Claudeにはいくつかのプランがありますが、今回は無料(Free)プランを選択しました。 Node.jsのインストール 下記リンクからユーザPCにNode.jsをインストールします。 Node.js — どこでもJavaScriptを使おう インストール後にバージョン確認と、npxコマンドが実行可能であることを確認します。 Node.jsバージョン確認 % node -v V22.20.0 npxコマンド実行可否確認 % npx -v 10.9.3 上記のような結果となればインストールが完了し、npxコマンドが実行可能であることを確認できます。 npxコマンドはNode.jsのインストールと同時にインストールされ、個別にインストールする必要はありませんでした。 MCPサーバーの設定 Claude DesktopとMackerel MCPサーバーを連携します。 ①Claude Desktopの設定を選択 ②設定画面の「開発者」メニューを選択して、ローカルMCPサーバー内の「設定を編集」を選択 掲載画像はすでに設定後の画面となっているため、表示位置などは初期状態とは異なっています。 「設定の編集」を選択するとClaude Desktopの設定ファイルが保存されているフォルダが自動で開きます。 ③設定ファイルを編集 Claude Desktopの設定ファイルが保存されているフォルダの「claude_desktop_config.json」に設定を記載します。 設定内容は下記のとおりです。 { 　"mcpServers": { 　　"mackerel": { 　　　"command": "npx", 　　　"args": ["-y", "@mackerel/mcp-server"], 　　　"env": { 　　　　"MACKEREL_APIKEY": " ${MACKEREL_APIKEY}" 　　　} 　　} 　} } ④Claude Desktopを再起動 ⑤連携できているかの確認 設定の「開発者」メニューを確認すると、「ローカルMCPサーバー」の項目に「mackerel」が出現し、「running(動作中)」と 表示されます。 Claude DesktopとMackerel MCPサーバーの連携は完了になります。 Claude DesktopでMackerel MCPサーバーを利用 提供機能 Mackerel MCPサーバーは以下13の機能を提供しています。 アラートの取得やホストの取得などさまざまな機能を提供しています。 list_alerts アラートの一覧を取得 get_alert 特定のアラートを取得 get_alert_logs 特定のアラートのログを取得 list_dashboards ダッシュボードの一覧を取得 get_dashboard 特定のダッシュボードを取得 update_dashboard 特定のダッシュボードを更新 list_hosts ホストの一覧を取得 get_host_metrics 特定のホストのメトリックを取得 list_services サービスの一覧を取得 get_service_metrics 特定のサービスのメトリックを取得 list_monitors 監視ルールの一覧を取得 get_monitor 特定の監視ルールを取得 get_trace トレースIDからトレースデータを取得 利用例1：アラートの分析や対応方法の相談 Mackerelで発生しているアラートについて、分析と対応方法をClaudeに相談してみました。 Mackerelで発生している特定のアラートについて、下記のようにプロンプトを送信しました。 アラートID「5AABPvnt85U」で発生している問題を分析して、問題の対処法を考えてください。 アラートIDについてはMackerelのコンソールから確認しています。 ※Freeプランでのメッセージ回数制限回避のため、アラートIDはMackerelコンソールで確認しています。 プロンプトの回答結果を下記に示します。 プロンプトで指定したアラートIDの原因と対処法を出力してくれました。 設定からアラートの相談まで短時間で完了することができ、こんなにも簡単なんだと感銘を受けました。 利用例2：ダッシュボードの更新 ここでは私の気になった「update_dashboard」機能について触れてみたので紹介します。 Mackerelのダッシュボード機能は監視データを一画面に集約することができ、サーバーの状況を把握することが可能な機能です。 グラフや数値などの情報パーツをドラッグ＆ドロップで自由に並べて、自分専用の見やすい画面を作ることが可能です。 今回は、特定ホストのメモリ使用量のグラフ・数値を可視化したダッシュボードを作成しました。 ダッシュボードの作成方法は今回のブログでは省略します。 作成したダッシュボードが下記です。メモリ使用量のグラフ・数値が一目で把握することが可能です。 このダッシュボード更新するために、「検証機ダッシュボードを更新したい」とClaude Desktopに投げました。 回答を以下に示しています。「update_dashboard」機能で実現可能な更新内容が記されています。 今回はダッシュボード名の変更とCPUのグラフを追加してみました。 下記のプロンプトをClaude Desktopに入力して送信しました。 ダッシュボード名をブログ用ダッシュボードに変更して、CPUのグラフウィジェットも追加してください。 Claude Desktopから「更新が完了しました。」と返信が来た後、Mackerelコンソールのダッシュボードを確認しました。 下記のようにダッシュボードが更新されていました。ダッシュボード名が変更され、CPU使用量のグラフが追加されていました。 アラート対応の相談とは少し違いますが、AIと対話するだけで更新できるのはとても便利だと感じました。 まとめ 今回はMackerel MCPサーバーでAIにアラートの対応方法を相談してみました。設定方法としてはとても簡単で詰まることなく設定完了することができました。Mackerelの情報をもとにアラートの対応方法などを考えてくれるのでとても便利だなと思いました。現時点では、データ取得機能が多いですが、今後は「upadte_dashboard」のような更新機能も増加するのではないかと心待ちにしています。 最後まで読んでいただきありがとうございました。

こんにちは。New Relic技術担当の井上です。 この記事では、New Relicを導入する前に、New Relicで収集されるデータの内容と、その構造について解説します。あわせてセキュリティ面にも触れています。New Relicのデータ収集の仕組みを理解する際の参考になれば幸いです。 はじめに New Relicを導入前に「どんなデータが収集されるのか」、「そのデータはどのように扱われるのか」、「セキュリティは安全なのか」といった疑問をもつ方もいると思います。私もその一人です。New Relicがどのようにデータを収集・管理し、安全性を確保しているのかを解説します。   New Relicで扱うデータ システムの状態を表すデータは、オブザーバビリティの分野では「テレメトリデータ」と呼ばれます。New Relicで収集されるテレメトリデータは、次の4種類に分類され、頭文字をとって「MELT」と略されています。 メトリクス(Metrics) アプリケーションやシステムがどんな状態かを定量的に数字で表した ものになります。New Relicでは、このメトリクス情報を使ってシステムがどんな状態かを時系列で調査・分析することができます。 メトリクスには2つのタイプがあります。 集計メトリクス：一定の時間帯で起きたことをまとめた数字 (例：1分間のエラー回数) ステータスメトリクス：ある瞬間の状態を表す数字(例：現在のCPU使用率) メトリクスを収集することで、システムのパフォーマンスやリソースの異常を発見することができるため、重要なデータの一つと言えますね。 イベント(Events) アプリケーションやシステムで何が起きたのかを記録した ものになります。例えば、APIの呼び出しやユーザがログインをしたなど、事象や行為を指します。New Relicではエラーに関わらず発生した出来事をイベントとしてJSON形式で表現したKey-Valueで記録するため、リアルタイムで何が起きたのかを調査・分析することができます。エラーが発生した、デプロイが実行した、ユーザがファイルをダウンロードしたなど、”いつ”、”何が起きたか”を指すイベントになります。 エラーだけが記録されている場合でも、「いつ」、「どんなシステム変更があったか」も一緒に記録されていることで、原因の分析がずっとしやすくなりますね。 ログ(Logs) アプリケーションやシステムが出力するメッセージ になります。New Relicでは、ログ単体で調査というよりも、他のデータと組み合わせることで、原因特定を迅速化することに使われます。例えば以下のような使い方があります。 イベントデータ：あたらしいバージョンがデプロイした ログ　　　　　：デプロイ直後からログにエラーが急増している メトリクス　　：レスポンスタイムが悪化している 上記のデータを組み合わせることで、デプロイした内容に不具合があったことが明確にできますね。 トレース(Traces) アプリケーション内でリクエストがどのように流れたかを記録した ものになります。複数のサービスやツールが連携して1つのサービスを提供する場合、その処理は複数のシステムやアプリケーションを経由します。この一連の流れを「トレース」と呼びます。一つのトレースは全体の処理時間や経路を把握するために、一意のトレースIDが付与されます。また、 トレースは複数のスパンで構成 されます。スパンとは「DB参照」、「API呼び出し」など、トレースを構成する個々の処理単位を指します。これらのスパンにも一意のスパンIDが付与され、それらが組み合わさって、1つのトレースを形成します。   上記の図を例に例えると、ユーザがログイン情報を入力し送信後、認証サーバからレスポンスを返答する一連の流れを指します。スパンは、ログイン情報入力後、 サーバーが処理 → DBで認証 → セッション生成 など、レスポンスを返答するまでの間の個々の処理を指します。 この一連の流れを追跡・記録することで、どこで遅延や問題が発生したかを把握できますね。New Relicはストレージやパフォーマンスへの負荷を避けるために、 代表的なサンプルのみを収集 します。 参考： New Relicデータタイプ：メトリクス、イベント、ログ、トレース（MELT） | New Relic Documentation   集めたデータはどこに集約される？ New Relicへデータを転送(送信)するには、エージェントと呼ばれるプログラムをオンプレミスサーバやクラウド環境などにインストールする必要があります(一部、エージェントをインストールしなくても収集できるデータはあります) 。 収集されたデータはTelemetry Data Platform のNRDB に集約 されますが、転送データはエージェントの設定で制御できますので、すべてのデータが収集されるわけではないです。NRDBはNew Relic社が管理しているバックエンドシステムであり、すべてのテレメトリデータ（メトリクス、イベント、ログ、トレースなど）を保存・検索・分析するためのデータベースになります。数十万アカウントから送られるデータを処理するため、想像を絶するスペックのデータベースが稼働しているのですね。   参考： New Relic データベース (NRDB): 内部の馬力 | New Relic Documentation           New Relic実践入門 第2版 オブザーバビリティの基礎と実現 電子書籍｜翔泳社の本   データの容量の見方 クラウド環境はコストの変動が激しいため、気づかない間にNew Relicへのデータ転送量が増えていた、、ということもあります。New Relicではダッシュボードでデータ量の確認やコストの上限が近づいたらアラートを出すことができます。この記事では、コンソール上でのデータ容量の見方を紹介します。 以下(左下ユーザアイコン>Manage Your Data)の図で以下のことが確認できます。 データ転送量の予測を算出 してくれるので、コスト管理や上限監視に役立ちますね。データ容量の減らし方については、別の記事にてご説明したいと思います。 1.過去30日間のデータ転送量、1日の平均データ転送量 2.Month-to-date：今月これまでに取り込んだデータ量 3.Projected end-of-month：月末時点の予測値 4.アカウントごとのデータ転送量 5.どの機能やリソースでどれくらいの転送量を占めているか (CSVにてダウンロード可能)　等   参考： データ取り込みの理解と管理 |New Relic ドキュメント   データの保管期間 データ保管期間は契約プランよって異なります。New Relicに転送されたデータはデータ保持期間が終了後、データが自動的に削除されます。 転送されたデータを自身で消すことはできません。 削除したい場合は、New Relicに問い合わせする必要があります。データの保管期間は以下(左下ユーザアイコン>Administration>Data Retention)から確認できます。   参考： データ保持の表示と管理 |New Relic ドキュメント         New Relic の個人データの要求 |New Relic ドキュメント   データを扱う上での制約事項 大量にデータを検索したり、アラートが飛んだりした場合、他の顧客のアカウントに影響を与える可能性があります。 膨大な量のデータを処理し続けるには限界があるため、ある一定以上の制限 を設けています。制限に達していないかどうかは、以下の画面(左下ユーザアイコン>Administration>Limits)で確認できます。1分間あたりでAPIのリクエストが数万レベルで実施されることは、ほとんどのシステムでは該当しないかと思います。1アカウントに対する制限なので、全世界のアカウントがアクセスしているとなると、NRDBはどれだけ大きいのでしょうか。。   参考： New Relicのデータ制限を理解する |New Relic ドキュメント           New Relic のデータ使用制限とポリシー |New Relic ドキュメント   データのプライバシー 利用者のデータを収集することになるため、セキュリティについてどうなっているのか、気になりますね。New RelicはGDPR、CCPAなどの国際的なプライバシー法に準拠しています。業界標準のセキュリティ監査を毎年実施し、プライバーシー・バイ・デザインの原則に従い、データは暗号化されて、アクセス管理は厳重となっているため、ユーザが安心して使えるような設計を提供しています。ただし、 データの送信はあくまでもユーザの責任 となりますので、ユーザ側で個人情報や機密情報を含めないようにログに出力しないまたは転送するログを決めるなど、設定とシステム構成が正しく行われていることを確認する必要があります。New Relicのエージェントは導入した環境からアウトバウンド通信のみを行います。エージェントの通信に使用するIPアドレスやポートはNew Relicの公式サイトに公開されていますので、必要なアウトバウンドに制限することもできます。 参考： New Relic によるデータプライバシー |New Relic のドキュメント           セキュリティとプライバシー |New Relic ドキュメント           New Relicネットワークトラフィック | New Relic Documentation           New Relic実践入門 第2版 オブザーバビリティの基礎と実現 電子書籍｜翔泳社の本   さいごに システム全体を可視化するためにすべてのデータを取得することは理想ですが、現実的にシステム負荷増加やデータ量が増えると重要な情報が埋もれてしまい、コストが膨大にもつながります。目的の設定や必要なデータを選んで取ることで、真のオブザーバビリティが発揮する、ということをObservability Conference Tokyo 2025のLizさんの講演を聞いて共感しました。そのためには、エラーのみ収集、遅延が発生したのものだけを記録など、導入して終わりではなく、日々のモニタリングから、”本当に必要な情報は何か”、継続的に収集対象を見直していかなければならないと日々感じています。 SCSKはNew Relicのライセンス販売だけではなく、導入から導入後のサポートまで伴走的に導入支援を実施しています。くわしくは以下をご参照のほどよろしくお願いいたします。

LifeKeeperの『困った』を『できた！』に変える！サポート事例から学ぶトラブルシューティング＆再発防止策 こんにちは、SCSKの前田です。 いつも TechHarmony をご覧いただきありがとうございます。 LifeKeeper の運用は、システムの安定稼働を支える重要な役割を担いますが、時には「なぜか動かない」「エラーが出てフェイルオーバーできない」といった『困った』事態に直面することもありますよね。そんな時、サポートに問い合わせて解決した経験は、多くの方にとって貴重な財産となっているはずです。 本連載企画「LifeKeeper の『困った』を『できた！』に変える！サポート事例から学ぶトラブルシューティング＆再発防止策」では、実際に LifeKeeper のサポートに寄せられた問い合わせ事例を基に、よくあるトラブルの原因、究明プロセス、そして何よりも『再発防止策』に焦点を当てて深掘りしていきます。 はじめに LifeKeeper for Linux を利用した高可用性クラスタにおいて、EC2 リソースの起動やフェイルオーバーはシステムの安定稼働に不可欠な要素です。しかし、予期せぬエラーで EC2 リソースが起動せず、クラスタの自動切り替えが機能しない、手動での起動もできないといった「困った！」状況に直面することは少なくありません。 本連載の第一弾では、この「EC2 リソースが起動しない」という問題に焦点を当てます。特に、AWSとの連携部分における見落としがちな設定や、トラブルシューティングのプロセス、そして何よりも「再発させない」ための具体的な対策と学習ポイントを、実際のサポート事例を交えて解説します。この記事を読み終える頃には、EC2 リソース起動失敗の原因を特定し、自信を持って対処できるようになるでしょう。 今回の「困った！」事例 LifeKeeper の EC2 リソースが起動しないという問題は、一見すると同じ事象に見えても、その裏には様々な原因が潜んでいます。今回は、 LifeKeeper のバージョンアップ後に  EC2 リソースが起動しなくなった という、特に見落としがちな事例を深掘りします。 事象の概要 : 待機系サーバにて LifeKeeper for Linux のバージョンアップ後、 待機系サーバで EC2 リソースの起動（スイッチオーバー時の起動処理）に失敗 する事象が発生しました。LifeKeeper for Linux のバージョンアップ前の 稼働系での EC2 リソース起動（スイッチバック）は成功 しており、特定のバージョンアップが関連している可能性があります。 発生時の状況 : あるお客様環境で、LifeKeeper for Linux のバージョンを v9.5.2 から v9.7.0 へアップデート する作業を実施しました。バージョンアップ後、待機系サーバで EC2 リソースの起動テストを行ったところ、これまで正常に動作していた EC2 リソースが突如起動に失敗。エラーメッセージからは、 AWS メタデータへのアクセスに問題 がある可能性が示唆されました。しかし、LifeKeeper for Linux のバージョンアップしていない稼働系サーバでは同じ EC2 リソースが正常に起動できる状況であり、その場での原因の特定が出来ませんでした。 原因究明のプロセス : サポートチームによる調査の結果、以下の点が判明しました。 LifeKeeper for Linux v9.7.0 へのアップデートと IAM 権限の関係 : お客様に設定していただいていた既存の IAM ロールの権限リストは v9.5.2 のものであり、v9.7.0 へのアップデートに伴い、LifeKeeper for EC2 Recovery Kit が必要とする IAM 権限が変更されている可能性が浮上しました。 サポートチームは、LifeKeeper の公式ドキュメント「Recovery Kit for EC2 の要件」を参照するよう促しました。 v9.7.0 のルートテーブル構成に必要な権限 : ec2:DescribeRouteTables ec2:ReplaceRoute ec2:DescribeNetworkInterfaceAttribute ec2:ModifyNetworkInterfaceAttribute v9.5.2 の権限（比較用） : ec2:DisassociateAddress ec2:DescribeAddresses ec2:AssociateAddress ec2:DescribeRouteTables ec2:ReplaceRoute   この比較から、特に v9.6.0 以降で「送信元/送信先チェック」の対応を行うために、いくつかの権限が追加・変更されていることが確認されました。 アップデート時のドキュメント参照の重要性 : LifeKeeper 製品のバージョンアップ時には、今回のように IAM 権限をはじめとする各 Recovery Kit の「要件」「設定」「考慮事項」が変更されることがあります。 これらの変更情報は、製品の新機能、バグ情報、各 Recovery Kit のドキュメントといった複数の箇所に記載されているため、全体を網羅的に確認することが重要です。今回の事例は、 アップデート作業の際には、 関連する公式ドキュメント群を丹念に確認し、最新の要件を漏れなく把握することの重要性 を改めて示すものでした。これにより、予期せぬトラブルを未然に防ぐことができます。 判明した根本原因 : LifeKeeper for Linux のバージョンアップ（v9.5.2 から v9.7.0）に伴い、EC2 Recovery Kit が必要とする IAM ロールの権限が不足していたことが根本原因でした。特に v9.6.0 で「送信元/送信先チェック」の対応が行われたことにより、必要な権限セットが変更されており、この変更がお客様の既存の IAM ロールに反映されていなかったため、EC2 リソースの起動に失敗していました。 「再発させない！」ための対応策と学び EC2リソースが起動しないという問題は、一度解決しても再発させないための予防策が非常に重要です。 具体的な解決策 : 上記事例の解決策は以下の通りです。 EC2リソースで操作するための IAM 権限の付与 : LifeKeeper for EC2 Recovery Kit v9.7.0 の要件に合致するよう、関連する IAM ロールに不足している EC2 関連の権限（ ec2:DescribeNetworkInterfaceAttribute 、 ec2:ModifyNetworkInterfaceAttribute  など）を追加しました。これにより、EC2 リソースは正常に起動するようになりました。 再発防止策とトラブルシューティングのヒント（チェックリスト形式） : EC2 リソース起動失敗は多様な原因で発生するため、以下のチェックリストを参考に、日々の運用やトラブルシューティングにご活用ください。 IAM ロール・権限に関する確認 :   LifeKeeper  バージョンアップ時の権限要件確認 : LifeKeeper for Linux や各 Recovery Kit をバージョンアップする際は、必ず最新バージョンの公式ドキュメントで「Recovery Kit for EC2 の要件」を確認し、必要な IAM 権限が変更・追加されていないか確認しましたか？   IAM  ロールへの最小権限付与 : LifeKeeper が EC2 リソース操作に利用するIAMロールには、必要な権限が過不足なく付与されていますか？（最小権限の原則を遵守しつつ、不足がないか確認）   一時的な資格情報の有効期限 : 一時的な資格情報を使用している場合、その有効期限は適切に設定されていますか？ AWS CLI と AWS サービスに関する確認 :   AWS CLI  の実行確認 : LifeKeeper が内部で実行する AWS CLI コマンド（ aws ec2 replace-route  など）が、OS で手動実行した際に正常に完了しますか？   AWS  側エラーコードの確認 : AWS CLI の実行が失敗する場合、AWS 側から返されるエラーコード（例: エラー253）の内容を AWS サポートに確認し、AWS 側の設定（ルートテーブル、セキュリティグループなど）に見直すべき点がないか確認しましたか？   AWS  サービスヘルスダッシュボード : 利用している AWS リージョンで、EC2 や IAM、VPC などの関連サービスに障害が発生していないか、AWS サービスヘルスダッシュボードを確認しましたか？ 環境設定と競合に関する確認 :   デバッグログの有効化と取得 : EC2 リソース起動失敗時は、LifeKeeper のデバッグログを有効にして、詳細なエラー情報を収集しましたか？（具体的な設定方法はサポートに確認）   セキュリティ製品との競合 : LifeKeeper および DataKeeper のインストールフォルダ（通常 /opt/LifeKeeper、/usr/local/bin/nbd-client、/usr/local/bin/nbd-server 等）が、ウイルス対策ソフトや証跡管理ソフトの監視対象から除外されていますか？（競合によりリソース起動失敗や誤検知が発生する可能性があります）   環境変数の確認 :  perform_action  コマンドなど、LifeKeeper 関連コマンドを特定のユーザーで実行する場合、そのユーザーの環境変数（特に  http_proxy 、 https_proxy  などのプロキシ設定）が LifeKeeper の GUI 実行時（通常 root）と一致しているか、または EC2 リソースの起動に必要な設定が適切に行われていますか？（例: root ユーザーで  sudo -i  を使用すると環境変数が引き継がれないケースなど） ベストプラクティス : 公式ドキュメントの熟読と定期的な確認 : LifeKeeper のバージョンアップ時だけでなく、定期的に Recovery Kit for EC2 の「要件」「設定」「考慮事項」セクションを公式ドキュメントで確認しましょう。最新の情報に常にキャッチアップすることが、未然のトラブル防止につながります。 jpdocs.us.sios.com/home | SIOS Technology Portal | SIOS Technology 最小権限の原則と定期的な見直し : IAM ロールには、LifeKeeper の運用に必要な最小限の権限のみを付与する「最小権限の原則」を適用し、定期的にその権限セットが最新の要件に合致しているか見直しましょう。 LifeKeeper と外部ツールとの共存設定 : ウイルス対策ソフトや証跡管理ソフトを導入する際は、事前に LifeKeeper のインストールディレクトリを除外設定することを徹底しましょう。これにより、不要な競合による問題を回避できます。 AWS CLI の安定稼働 : LifeKeeper は内部で AWS CLI を利用するため、基盤となる OS 環境で AWS CLI が安定して動作することが重要です。プロキシ設定やネットワーク疎通など、AWS CLI が AWS エンドポイントと正常に通信できることを確認しましょう。 まとめ LifeKeeper の EC2 リソース起動失敗は、 クラウド環境と連携するシステムならではの 複雑さ があります。 しかし、本記事でご紹介したように、バージョンアップに伴う IAM 権限の変更、AWS CLI のエラー、環境変数の設定不備など、その原因は明確に特定できます。 特に重要なのは、 「常に最新のドキュメントを確認する習慣」 と、 「発生したエラーメッセージやデバッグログから原因を特定するプロセス」 です。そして、一度解決した問題は二度と起こさないための 「再発防止策チェックリスト」を活用することで、より堅牢なシステム運用が可能になります。 日々の運用でこれらのポイントを意識し、今回学んだトラブルシューティングと再発防止策を実践することで、EC2 リソースの「困った！」を「できた！」に変え、安定した高可用性クラスタを維持できるようになるでしょう。 次回予告 次回の連載では、「リソース起動・フェイルオーバー失敗の深層」の第二弾として、「IP リソースが切り替わらない！ネットワーク設定の落とし穴と診断術」と題し、LifeKeeper の IP リソースに関するトラブルシューティングと、ネットワーク設定に関するベストプラクティスを深掘りします。どうぞお楽しみに！ 詳しい内容をお知りになりたいかたは、以下のバナーからSCSK LifeKeeper公式サイトまで

こんにちは、SCSKの坂木です。 「標準の監視アイテムだけでは取得できない、独自の情報を収集したい…」 「特定のスクリプトを実行した結果をZabbixで監視したい…」 そんな風に思ったことはありませんか？ そのお悩み、Zabbixエージェントの機能 UserParameter  を使えば解決できます！   この記事では、 UserParameterの基本的な設定方法 を、初心者の方にも分かりやすくステップバイステップで解説していきます。 ※この記事では、監視対象のホストにZabbixエージェントがすでにインストールされ、Zabbixサーバと基本的な通信が確立されていることを前提として解説を進めます。   UserParameterについて UserParameterは、Zabbixエージェントで標準提供されていない、 ユーザー独自のカスタムアイテムキーを定義するための機能 です。 監視対象ホストのエージェント設定ファイルに、任意の「キー名」と、そのキーが呼び出された時に実行される「OSコマンドやスクリプト」を紐付けて定義します。 5 User parameters www.zabbix.com   system.runとの比較 Zabbixでスクリプトの実行結果を監視ができる機能には、UserParameterの他にsystem.runがあります。 どちらも任意のスクリプトを実行できる点では同じですが、下表の相違点があります。 項目 UserParameter system.run 実行スクリプトの定義場所 Zabbixエージェントの設定ファイル ZabbixのWeb画面（アイテムのキー） セキュリティ 設定ファイルで許可されたスクリプト/コマンドしか実行できない 設定によっては任意のスクリプト/コマンドを実行できてしまう 設定のしやすさ 設定ファイルとZabbixインターフェースの両方設定が必要 Zabbixインタフェースの設定のみ（ワイルドカードを用いない場合は設定ファイルも変更が必要）   設定ファイルの編集 UserParameterでは、Zabbixエージェントの設定ファイルにスクリプトの実行コマンドを記載します。 監視対象ホストにSSHなどでログインし、Zabbixエージェントの設定ファイル(zabbix_agentd.conf)を開きます。 # vi /etc/zabbix/zabbix_agentd.conf ファイルを開いて、UserParameterに関する設定項目を探してください。 ### Option: UserParameter # User-defined parameter to monitor. There can be several user-defined parameters. # Format: UserParameter=<key>,<shell command> # See 'zabbix_agentd' directory for examples. # # Mandatory: no # Default: # UserParameter= UserParameterの書式は以下の通りです。この書式に従って設定ファイルに追記していきます。 UserParameter=<key>,<command> 項目 値 key Zabbixインタフェースでアイテムを作成する際に指定する、任意の名前のアイテムキー command 上記のキーが呼び出されたときに、Zabbixエージェントが実行するコマンドやスクリプト   今回は2つのUserParameterを作成します。 こちらのように設定ファイルに記載します。複数のUserParameterを定義したい場合は、 1行に1つずつ 記述していきます。 ### Option: UserParameter # User-defined parameter to monitor. There can be several user-defined parameters. # Format: UserParameter=<key>,<shell command> # See 'zabbix_agentd' directory for examples. # # Mandatory: no # Default: # UserParameter= UserParameter=samplekey01,/etc/zabbix/work/get_security_updates.sh　　　#記載した箇所（Case1） UserParameter=samplekey02[*],/etc/zabbix/work/search_log.sh "$1" "$2"　 #記載した箇所（Case2）   記載したUserParameterは以下の設定としています。 Case1：引数のないスクリプトを実行するパターン 項目 値 key samplekey01 command /etc/zabbix/work/get_security_updates.sh ▼実行スクリプト：適用可能なセキュリティアップデートの件数をカウント # cat /etc/zabbix/work/get_security_updates.sh #!/bin/bash dnf updateinfo list sec -q | wc -l   Case2：引数を使って1つのUserParameter定義を使い回すパターン 項目 値 key samplekey02[*] command /etc/zabbix/work/search_log.sh “$1” “$2” keyの最後に [*]をつけると、このキーがcommand後の””内の引数を受け入れる設定 となります。これにより、Zabbixインタフェースのアイテム設定画面から、監視したい対象のパラメータを自由に渡すことが可能になります。 commandで使われている$1と$2は、Zabbixインタフェースのアイテムのキーにて定義される、引数のプレースホルダーです。 $1にはキーで指定された 1番目の引数 が、$2には、キーで指定された 2番目の引数 が入ります。 ▼実行スクリプト：指定されたログファイル（引数1）から、指定されたキーワード（引数2）が含まれる行数をカウント # cat /etc/zabbix/work/search_log.sh #!/bin/bash if [ ! -f "$1" ]; then echo 0 exit 0 fi grep -c "$2" "$1"   実行ファイルの権限変更 UserParameterは、zabbixユーザ権限で実行 されます。 そのため、スクリプトファイルに対してzabbixユーザが実行できるパーミッションを付与する必要があります。 スクリプトファイルに実行権限を付与します。 # chmod +x /etc/zabbix/work/get_security_updates.sh # chmod +x /etc/zabbix/work/search_log.sh zabbixユーザが実行できるファイルになっていることを確認します。 # ll -rwxr-xr-x. 1 root root 48 Oct 24 01:21 get_security_updates.sh -rwxr-xr-x. 1 root root 242 Oct 28 07:44 search_log.sh 以上で、zabbixエージェント側での設定は完了です。   Zabbixインタフェースでのアイテム設定 続いて、ZabbixサーバのインタフェースからUserParameterのアイテムを作成していきます。 [データ収集] > [ホスト] > (対象ホストの) [アイテム] と進み、[アイテムの作成] をクリックします。 以下の項目を設定します。 Case1：引数のないスクリプトを実行するパターン 項目 値 タイプ Zabbixエージェント キー samplekey01　(zabbix_agentd.confで記載したアイテムキー)   Case2：引数を使って1つのUserParameter定義を使い回すパターン 項目 値 タイプ Zabbixエージェント キー samplekey02[/var/log/work/testlog,zabbix] （引数はキー名に続けて [ ] 内に具体的な値をカンマ区切りで指定する。 $1に”/var/log/work/testlog”を、S2に”zabbix”を渡す）   $1で指定した/var/log/work/testlogは以下の通りです。今回は$2で”zabbix”を指定しているため、”zabbix”の個数である3が出力されます。 # cat /var/log/work/testlog error test test zabbix zabbix zabbix   設定が完了したら、アイテムが正しくデータを取得できているか確認しましょう。 [監視データ] > [最新データ]を開き、設定したアイテムの値が定期的に更新されていることを確認してください。   以上で設定は完了です。   まとめ 本記事では、Zabbixの監視を拡張する UserParameterを使った設定方法 について解説しました。 UserParameterは、Zabbixインタフェースのアイテム設定から引数を変えるだけで、同じ仕組みを横展開できるのも強みです。 この記事を参考に、ぜひUserParameterを試してみてください！   ▼ Zabbixに関するおすすめ記事 【Zabbix】トリガーアクションでスクリプトを実行する方法 本ブログではZabbixのトリガーアクションで障害対応を自動化する方法を解説します。 今回はトリガーアクションの中でもスクリプトの実行方法について説明します。 blog.usize-tech.com 2025.06.10 【Zabbix】system.runでスクリプト実行結果を監視する方法 Zabbixのsystem.run設定方法をステップバイステップで解説。標準アイテムにないカスタム監視を実現するため、zabbix_agentd.confの修正、安全なAllowKeyの使い方、スクリプトの権限設定までを網羅。初心者でも安心のガイドです。 blog.usize-tech.com 2025.11.04

システムを作る中で冗長性を上げるために同構成の仮想マシンを2つ作る、といったことはよくあると思いますが、同じものを何度も手動で作り上げるのは大変です。 また、IaCで構築する際も、同じ内容のものをいくつも書いていると、コードが冗長になったり、パラメータに修正があったときに何か所も変更しなければなりません。 そのため、今回はモジュール化を用いて同構成のリソースを簡単に複製する方法について紹介します。モジュールを使うことで、コードの冗長化を防ぎ、パラメータの修正も1か所するだけで済むようになります。 フォルダ構成 実行するプログラムをmainフォルダに、呼び出し先のプログラムをmoduleフォルダに分け、mainプログラムからmoduleプログラムを呼び出すような構成にします。 こうすることで、実行部分(main)と細かいパラメータの実装部分(module)を分けて管理することができ、コードが見やすく保守性も高まります。 root | |__main | |___main.tf | |__module | |___module.tf | |___module2.tf module まずはmoduleファイルについてです。moduleファイルでは通常通りresourceブロックを作成し、パラメータを埋め込んでいきます。その中でリソースごとに変更したいパラメータ（リソース名など）は変数化しておきます。 resource "azurerm_virtual_machine" "vm" { name = var.vm_name　#リソースごとに名前を変えたいので変数化しておく location = "japan east" vm_size = "Standard_B1ls" .... tags = { Name = var.vm_name } } variable "vm_name"{} #変数定義 moduleファイル内では複数サービスを定義することができ、同時に呼び出すことができます。VMを作成する際はnicが必要になるので、同ファイルに定義する、といったことができます。 #nic resource "azurerm_network_interface" "nic" { name = var.nic_name location = "japan east" ... } #vm resource "azurerm_virtual_machine" "vm" { name = var.vm_name　#リソースごとに名前を変えたいので変数化しておく location = "japan east" vm_size = "Standard_B1ls" .... tags = { Name = var.vm_name } } variable "nic_name"{} #変数定義 variable "vm_name"{} モジュールの呼び出し(main.tf) モジュールを作成できたらあとは呼び出すだけです。ここではソースとなるファイルを指定し、変数化していた部分にパラメータを定義します。 module "vm1"{ source = "../module/module.tf" #ソースファイル呼び出し nic_name = "nic1" #事前定義していた変数に値を入力 vm_name = "vm1" } module "vm2"{ source = "../module/module.tf" nic_name = "nic2" vm_name = "vm2" これで準備は完了です。あとはmainフォルダ内で「terraform apply」を実行すれば同構成のマシンを作成することができます。 おわりに 今回はリソースをモジュール化し、同構成のリソースを複数構築する方法について紹介しました。手動で作成するよりかなり楽ですし、コードも短くきれいになるのでぜひ利用してみてください

当記事は、前回の記事「Ansibleを使用してNW機器設定を自動化する（PaloAlto-サービス編①）」からの改善となります。 設定情報がベタ書きで使い勝手が悪い点　を　設定情報をまとめてINPUT（JSON）できる使い勝手の良い仕組みとしました！！ これにより、Anibleとの連携ができるようになりますので、ご参考になれば幸いです。 ※前回記事： https://blog.usize-tech.com/paloalto-integration-with-ansible1/ 当記事は、 日常の運用業務（NW機器設定）の自動化 により、 運用コストの削減　および　運用品質の向上 　を目標に 「Ansible」 を使用し、様々なNW機器設定を自動化してみようと　試みた記事です。 Ansibleは、OSS版（AWX）＋OSS版（Ansible）を使用しております。   PaloAltoの「Objects-サービス」の登録／変更／削除を実施してみた 事前設定 Templateを作成し、インベントリーと認証情報を設定する。 インベントリー：対象機器（ホスト）の接続先を設定。　※ホストには以下変数で接続先IPを指定 ansible_host: xxx.xxx.xxx.xxx 認証情報：対象機器へのログイン情報（ユーザ名／パスワード）を設定。 ユーザ名は　　変数：ansible_user　　　に保持される パスワードは　変数：ansible_password　に保持される   事前設定２：設定情報をまとめてINPUT（JSON）できるように、「Survey」を活用 テンプレートが読み込むことができる変数（Survey）を設定する。※今回は、各設定のデフォルト値に値を設定する。 実際の値（JSON） ・input_service1:{"name":"test_service001","protocol":"tcp","destination_port":"10","source_port":"110","description":"test_service001","tag":["test"]} ・input_service2:{"name":"test_service001","protocol":"tcp","destination_port":"20","source_port":"120","description":"test_service001","tag":["test"]} ・input_service3:{"name":"test_service001","protocol":"tcp","destination_port":"30","source_port":"130","description":"test_service001","tag":["test"]} ・input_service4:{"name":"test_service001"}   事前設定 Templateを作成し、インベントリーと認証情報を設定する。 インベントリー：対象機器（ホスト）の接続先を設定。　※ホストには以下変数で接続先IPを指定 ansible_host: xxx.xxx.xxx.xxx 認証情報：対象機器へのログイン情報（ユーザ名／パスワード）を設定。 ユーザ名は　　変数：ansible_user　　　に保持される パスワードは　変数：ansible_password　に保持される   Playbook作成（YAML） 使用モジュール paloaltonetworks.panos.panos_service_object 　を使用。 ※参考ページ：https://galaxy.ansible.com/ui/repo/published/paloaltonetworks/panos/content/module/panos_service_object/   接続情報（provider）の設定 providerには、ip_address／username／password　の指定が必要。 vars: provider:   ip_address: '{{ ansible_host }}'　　　←　インベントリーのホストで設定   username: '{{ ansible_user }}'　　　　←　認証情報で設定   password: '{{ ansible_password }}'　　←　認証情報で設定   変数（Survey）の値取得 vars で　各変数（Survey）の値取得。 ※各変数（Survey）の値は、構造化データのように見えて「文字列」なので、ディクショナリ（構造化データ）として正しく扱えるように、from_json フィルターを使用すること！！           vars: wk_input1: '{{ input_service1 | from_json}}' wk_input2: '{{ input_service2 | from_json}}' wk_input3: '{{ input_service3 | from_json}}' wk_input4: '{{ input_service4 | from_json}}'   Objects-サービスの登録　★ 変数（Survey）の値をそのまま使用した場合…エラーとなる 接続情報とサービス情報（ Survey：input_service1 ）を指定して登録（state: ‘present’）を行う。 - name: Add Service1_input_service1 paloaltonetworks.panos.panos_service_object: provider: '{{ provider }}' name: '{{ input_service1.name }}' protocol: '{{ input_service1.protocol }}' destination_port: '{{ input_service1.destination_port }}' source_port: '{{ input_service1.source_port }}' description: '{{ input_service1.description }}' tag: '{{ input_service1.tag }}' state: 'present' register: wk_result 実行結果：構造化データではないので、オブジェクトに項目が無いという エラー となる。　※Ansibleの実行結果を抜粋 "msg": "The task includes an option with an undefined variable. The error was: 'ansible.utils.unsafe_proxy.AnsibleUnsafeText object' has no attribute 'name'. ... Objects-サービスの登録 接続情報とサービス情報（ Survey：input_service1 ）を指定して登録（state: ‘present’）を行う。 - name: Add Service1_wk_input paloaltonetworks.panos.panos_service_object: provider: '{{ provider }}' name: '{{ wk_input1.name }}' protocol: '{{ wk_input1.protocol }}' destination_port: '{{ wk_input1.destination_port }}' source_port: '{{ wk_input1.source_port }}' description: '{{ wk_input1.description }}' tag: '{{ wk_input1.tag }}' state: 'present' register: wk_result 実行結果：対象のサービスが登録された。　※Ansibleの実行結果（diff）を抜粋 "before": "", "after" : "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_service001\">\n\t<protocol>\n\t\t<tcp>\n\t\t\t<source-port>110</source-port>\n\t\t\t<port>10</port>\n\t\t</tcp>\n\t</protocol>\n\t<description>test_service001</description>\n\t<tag>\n\t\t<member>test</member>\n\t</tag>\n</entry>\n"   Objects-サービスの変更　※登録のつづき 接続情報とサービス情報を指定して　登録されたサービスの変更（ state: ‘replaced’ ）を行う。　 ※replacedの場合は、既存設定の置き換えとなる - name: Change Service1 paloaltonetworks.panos.panos_service_object: provider: '{{ provider }}' name: '{{ wk_input2.name }}' protocol: '{{ wk_input2.protocol }}' destination_port: '{{ wk_input2.destination_port }}' source_port: '{{ wk_input2.source_port }}' description: '{{ wk_input2.description }}' # tag: '{{ wk_input2.tag }}' state: 'replaced' register: wk_result 実行結果：登録時のtag指定ありのサービスが、Rreplaedによりtag指定なしのサービスに変更された。　※Ansibleの実行結果（diff）を抜粋 "before": "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_service001\">\n\t<protocol>\n\t\t<tcp>\n\t\t\t<source-port>110</source-port>\n\t\t\t<port>10</port>\n\t\t</tcp>\n\t</protocol>\n\t<description>test_service001</description>\n\t<tag>\n\t\t<member>test</member>\n\t</tag>\n</entry>\n", "after" : "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_service001\">\n\t<protocol>\n\t\t<tcp>\n\t\t\t<source-port>120</source-port>\n\t\t\t<port>20</port>\n\t\t</tcp>\n\t</protocol>\n\t<description>test_service001</description>\n</entry>\n"   接続情報とサービス情報を指定して　登録されたサービスの変更（ state: ‘merged’ ）を行う。　 ※mergedの場合は、既存設定の上書きとなる - name: Change Service2 paloaltonetworks.panos.panos_service_object: provider: '{{ provider }}' name: '{{ wk_input3.name }}' protocol: '{{ wk_input3.protocol }}' destination_port: '{{ wk_input3.destination_port }}' source_port: '{{ wk_input3.source_port }}' # description: '{{ wk_input3.description }}' tag: '{{ wk_input3.tag }}' state: 'merged' register: wk_result 実行結果：上記変更時のtag指定なしのサービスが、mergedによりtag指定ありのサービスに変更された。また、サービス情報にdescriptionを指定しなくても、既存設定が維持されていることを確認。　※Ansibleの実行結果（diff）を抜粋 "before": "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_service001\">\n\t<protocol>\n\t\t<tcp>\n\t\t\t<source-port>120</source-port>\n\t\t\t<port>20</port>\n\t\t</tcp>\n\t</protocol>\n\t<description>test_service001</description>\n</entry>\n", "after" : "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_service001\">\n\t<protocol>\n\t\t<tcp>\n\t\t\t<source-port>130</source-port>\n\t\t\t<port>30</port>\n\t\t</tcp>\n\t</protocol>\n\t<description>test_service001</description>\n\t<tag>\n\t\t<member>test</member>\n\t</tag>\n</entry>\n"   Objects-サービスの情報収集　※変更のつづき 接続情報とサービスを指定して情報収集（state: ‘gathered’）を行う。 - name: Get Service Info paloaltonetworks.panos.panos_service_object: provider: '{{ provider }}' name: '{{ wk_input4.name }}' state: 'gathered' register: wk_result 実行結果：対象サービスの情報が取得できた。　※Ansibleの実行結果（gathered_xml）を抜粋 "gathered_xml": "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_service001\">\n\t<protocol>\n\t\t<tcp>\n\t\t\t<source-port>130</source-port>\n\t\t\t<port>30</port>\n\t\t</tcp>\n\t</protocol>\n\t<description>test_service001</description>\n\t<tag>\n\t\t<member>test</member>\n\t</tag>\n</entry>\n"   Objects-サービスの削除　※変更のつづき 接続情報とサービスを指定して削除（state: ‘absent’）を行う。 - name: Delete Service1 paloaltonetworks.panos.panos_service_object: provider: '{{ provider }}' name: '{{ wk_input4.name }}' state: 'absent' register: wk_result 実行結果：対象のサービスが削除された。　※Ansibleの実行結果（diff）を抜粋 "before": "<?xml version=\"1.0\" encoding=\"utf-8\"?>\n<entry name=\"test_service001\">\n\t<protocol>\n\t\t<tcp>\n\t\t\t<source-port>130</source-port>\n\t\t\t<port>30</port>\n\t\t</tcp>\n\t</protocol>\n\t<description>test_service001</description>\n\t<tag>\n\t\t<member>test</member>\n\t</tag>\n</entry>\n", "after" : "" 最後に 今回、変数（Survey）を活用したことで、Ansibleに INPUT（JSON）を設定 できるようになりました。 設定情報がYAMLにベタ書きではなくなったので、使い勝手は増しましたが、 都度　変数（Survey）のデフォルト値に値を設定しての実行の為、まだまだ　使い勝手が悪い。。。            今後　外部からAnsibleの INPUT（JSON）に値を連携し実行させる仕組みを試みたいと思います。

はじめまして！　SCSKの三浦です。   ServiceNow World Forum25が2025年10月22日・23日に開催されました。 ServiceNowと出会って1か月、早速大イベントに参加してきたのでレポートをお届けします！   イベント概要 ServiceNow World Forum25は、ServiceNowの最新テクノロジーやAIプラットフォームを、パートナー企業や専門家とともに紹介する大規模イベントです。   SCSKもパートナー企業としてブース出展をしました。 こちらにも携わりました。緊張、、、   今回は東京ビッグサイトに場所を移し、2日間で約11,000人を動員しました。 なんとWorld Forumが開催される9都市のうち、 2 日間開催は日本のみ。 この規模感から、日本におけるServiceNowの注目度の高さを実感するとともに、ServiceNow自身も日本市場を重要視していることが伝わってきました。   イベント参加者は、興味のあるセッションを自由に選んで講演を聞いたり、パートナー企業が出展するブースで各社の技術や取り組みについて知ることができます。 私はServiceNowビギナーなので、初心者向けのセッションを中心に選んで参加しました！   いざ、基調講演へ まず、イベント全体のテーマや方向性を示す基調講演に参加しました。 今回の講演で重点的に語られていたのは「 人とAIの協働 」です。企業におけるAI活用の現状や、実際のAIエージェントの活用事例が紹介されました。 特に心に残ったポイントは以下の通りです。 IT部門が変革の起点に AIが身近になった今も、IT部門の事業にはまだ多くの未開拓領域が残されており、企業全体としてもAIを十分に活用しきれていないのが現状です。講演では、IT部門が社内DXの成功事例となるべきというメッセージが強調されました。 未開拓領域に挑む姿勢が、今後の企業変革の鍵になると語られました。 AIは“流行”ではなく“転換点” 講演で印象的だったのは、AIは一時的なブームではなく、働き方を根本から変える転換点だという点です。その価値を最大限に引き出すには、データとワークフローをシームレスに統合することが欠かせないという話が心に残りました。 人とAIの二馬力による未来 講演を通じて印象的だったのは、AIが「デジタル労働力」として人間と協働し、二馬力で価値を生み出すという考え方です。今後、労働人口が減少していく中で、AIを活用して人の力を解放することが不可欠だと語られていました。さらに、時代の流れに先んじてAIの能力を高め、企業や社会全体の生産性を向上させる取り組みが必要だというメッセージが強く印象に残りました。   Day1 セッションレポート 1日目は、KDDIによる「ServiceNowとSMS連携技術」についてのセッションに参加しました。 このセッションでは、ServiceNowとSMSを連携させたサービスが紹介され、SMSの高い利用率と開封率から、通知手段として非常に有効であることが示されました。 さらに、追加の開発やアプリのインストールなしでServiceNow上で利用できる点も大きな利点です。 ServiceNowを触り始めたばかりの私にとって、このセッションは、アイデア次第でさまざまなサービスを生み出せる可能性を感じる貴重な機会でした。ServiceNow開発の幅広さを改めて実感しました。   Day1所感 想像していたイベントの雰囲気とは異なり、基調講演前のDJパフォーマンスや華やかな演出が印象的でした。 また、基調講演やセッションの内容から、ServiceNowがAI活用を前面に押し出していることを強く実感しました。 初学者として、ServiceNowの機能や基礎知識を学べたこと、さらに他社での活用事例を知ることができたのは大きな収穫でした。   初日の最後には、絢香さんによるスペシャルライブが開催されました！ このライブは Presented by SCSK であり、今回のWFTでSCSKの存在感を強く感じる場面でした。 華やかな演出とともに、１日目の締めくくりとなりました。   次回、Day2のレポートに続きます…！

こんにちは、SCSKの坂木です。 「標準の監視アイテムだけでは取得できない、独自の情報を収集したい…」 「特定のスクリプトを実行した結果をZabbixで監視したい…」 そんな風に思ったことはありませんか？ そのお悩み、Zabbixエージェントの強力な機能 system.run を使えば解決できます！ この記事では、 system.runの基本的な設定方法から、セキュリティを考慮した安全な使い方 まで、初心者の方にも分かりやすく ステップバイステップで解説していきます。 この記事では、監視対象のホストにZabbixエージェントがすでにインストールされ、Zabbixサーバと基本的な通信が確立されていることを前提として解説を進めます。 system.runについて system.runは、Zabbixエージェントがインストールされたサーバ上で、任意のスクリプトを実行し、その結果を監視データとして取得できる便利なアイテムキーです。 1 Zabbix エージェント www.zabbix.com system.runは任意のコマンドを実行できるため、設定を誤ると深刻なセキュリティリスク となります。 このため、Zabbix Agentの デフォルト設定では無効化 されています。 安全に利用するためには、実行を許可するスクリプトファイルを明示的に指定するなどの対策が必須です。 次章以降で、具体的な有効化の手順と、セキュリティを担保するための設定方法を解説します。   設定ファイルの修正 デフォルトの状態では、セキュリティ上の理由からsystem.runの利用は全面的に禁止されています。 この章では、安全な形で特定のスクリプト実行のみを許可する設定を行っていきます。 まず、監視対象ホストにSSHなどでログインし、Zabbixエージェントの設定ファイル(zabbix_agentd.conf)を開きます。 # vi /etc/zabbix/zabbix_agentd.conf ファイルを開いて、DenyKeyに関する設定項目を探してください。 こちらは、デフォルトでDenyKey=system.run[*]、つまり『全てのsystem.runコマンドを拒否する』設定となっております。 ### Option: DenyKey # Deny execution of items keys matching pattern. # Multiple keys matching rules may be defined in combination with AllowKey. # Key pattern is wildcard expression, which support "*" character to match any number of any characters in certain position. It might be used in both key name and key arguments. # Parameters are processed one by one according their appearance order. # If no AllowKey or DenyKey rules defined, all keys are allowed. # Unless another system.run[*] rule is specified DenyKey=system.run[*] is added by default. # # Mandatory: no # Default: # DenyKey=system.run[*] 次に、以下のようにAllowKeyでsystem.runの利用を許可します。 []内はsystem.runの実行を許可するファイル名を記載します。 ワイルドカードが利用できる ので、*を用いて特定のディレクトリ配下のファイル全て実行可能といった設定もできます。 （正規表現での指定はできません） 追記した一行は「/etc/zabbix/work/ ディレクトリ配下にある、任意のスクリプトやコマンドの実行だけを許可します」という意味になります。 ### Option: DenyKey # Deny execution of items keys matching pattern. # Multiple keys matching rules may be defined in combination with AllowKey. # Key pattern is wildcard expression, which support "*" character to match any number of any characters in certain position. It might be used in both key name and key arguments. # Parameters are processed one by one according their appearance order. # If no AllowKey or DenyKey rules defined, all keys are allowed. # Unless another system.run[*] rule is specified DenyKey=system.run[*] is added by default. # # Mandatory: no # Default: # DenyKey=system.run[*] AllowKey=system.run[/etc/zabbix/work/*] #追記した箇所 ⚠️ セキュリティに関する重要ポイント []内を*にするとサーバ内の全てのすべてのスクリプトが実行できてしまうため、 必要最低限のファイルのみ許可するように設定してください 。 例えば、以下のような設定は絶対に避けてください。 AllowKey=system.run[*] 設定ファイルの編集が終わったら、保存してファイルを閉じます。 最後に、変更内容を反映させるためにZabbixエージェントを再起動します。 # systemctl restart zabbix-agent   実行ファイルの権限変更 本ブログでは、セキュリティアップデートの件数を取得するget_security_updates.shをsystem.runの実行対象ファイルとします。 また、ファイルを/etc/zabbix/work/配下に配置します。 # cat get_security_updates.sh #!/bin/bash dnf updateinfo list sec -q | wc -l system.runで呼び出されるスクリプトファイルは、zabbixユーザ権限で実行 されます。 そのため、スクリプトファイルに対してzabbixユーザが実行できるパーミッションを付与する必要があります。 スクリプトファイルに実行権限を付与します。 # chmod +x /etc/zabbix/work/get_security_updates.sh zabbixユーザが実行できるファイルになっていることを確認します。 # ll -rwxr-xr-x. 1 root root 48 Oct 24 01:21 get_security_updates.sh 以上で、zabbixエージェント側での設定は完了です。   Zabbixインタフェースでのアイテム設定 続いて、Zabbixサーバのインタフェースからsystem.runのアイテムを作成していきます。 [データ収集] > [ホスト] > (対象ホストの) [アイテム] と進み、[アイテムの作成] をクリックします。 以下の項目を選択します。 項目 値 タイプ Zabbixエージェント(アクティブ) キー system.run[<実行するスクリプトファイルのフルパス>] 設定が完了したら、アイテムが正しくデータを取得できているか確認しましょう。 [監視データ] > [最新データ]を開き、設定したアイテムの値が定期的に更新されていることを確認してください。 以上で設定は完了です。これでsystem.runによるカスタム監視が開始されます。   まとめ 本記事では、Zabbixエージェントのsystem.runを利用してカスタム監視を行う方法を解説しました。 system.runは、任意のコマンドやスクリプトの実行結果を取得できる非常に柔軟な機能ですが、その反面、セキュリティ設定が不可欠です。 設定の要点はこちらになります。 項目 要点 エージェント側 AllowKeyで実行可能なコマンドを厳密に制限する 監視対象ホスト側 スクリプトファイルをzabbixユーザが実行できるパーミッションに設定する Zabbixサーバー側 (UI) system.run[command]キーでアイテムを作成する 特に、 AllowKey=system.run[*]のような広範な許可設定は深刻なセキュリティリスクとなるため、本番環境では絶対に使用しないでください 。 system.runを正しく理解し、安全に活用することで、Zabbixの監視能力は飛躍的に向上します。標準アイテムでは実現できない独自の監視要件に、ぜひ応用してみてください。   ▼ Zabbixに関するおすすめ記事 【Zabbix】トリガーアクションでスクリプトを実行する方法 本ブログではZabbixのトリガーアクションで障害対応を自動化する方法を解説します。 今回はトリガーアクションの中でもスクリプトの実行方法について説明します。 blog.usize-tech.com 2025.06.10  

こんにちは　SCSK 野口です。 今回は「LifeKeeper for Linuxのインストール要件」についてご紹介いたします。 LifeKeeperの要件は具体的に何があるのか、Linuxへインストールするための要件についてまとめみました。 基本要件について システム要件 LifeKeeper for Linuxの安定稼働には、以下のシステム要件を満たす必要があります。(2025年10月時点) ディスク容量は LifeKeeper本体の最小容量であり、OSやアプリケーションデータ、ログ容量は別途必要です。 そのため、余裕を持ったディスク設計が必須です。 これらの要件を確実に満たすことで、LifeKeeperの安定稼働が実現できます。 メモリーの枯渇はスローダウンを引き起こし、LifeKeeperが障害と判断する可能性があるよ！ オペレーティングシステム LifeKeeper for Linux v9 は、以下のオペレーティングシステム（OS）がサポートされています。(2025年10月時点) ※ LifeKeeperのバージョンによって、利用できる OSバージョンが異なるためご注意ください！ (例) LifeKeeper for Linux v9.7.0の場合、 RHEL9 は 9.1 (64ビット) までがサポートされています。 詳細情報についてはこちらのリンクからご確認ください。 「サポート対象のオペレーティングシステム」 カーネル LifeKeeper for Linux v9 は、以下のカーネルがサポートされています。(2025年10月時点) ※ OSのバージョンによって、利用できる カーネルバージョンが異なるためご注意ください！ (例) Red Hat Enterprise Linux 7 for AMD64/EM64Tの RHEL7.1の場合、 ” 3.10.0-229.el7 ” がサポートされています。 詳細情報についてはこちらのリンクからご確認ください。 「Linuxの設定」 カーネル は ハイフンの次までが一致する場合、サポート対象 となるわ！ ストレージ LifeKeeper for Linux v9 は、以下のストレージがサポートされています。(2025年10月時点) ※ 全てのストレージがサポートされているわけではないのでご注意ください！ 詳細情報についてはこちらのリンクからご確認ください。 「サポートストレージ」 ノード設定について ホスト名/名前解決 はじめに、各ノードにホスト名を設定する必要があります。 また、ホスト名を設定後は各ノード間で名前解決ができるようにしてください。 ホスト名を設定する際は、hostnamectl コマンドを使用して設定します。 DNSサーバが利用可能な場合、サーバを使用してホスト名を登録します。 使用可能な DNSサーバがない場合、/etc/hostsを使用してホスト名を解決することをお勧めします。 設定後、お互いがホスト名で疎通できることを確認してね！ SELinux LifeKeeper for Linuxは、SELinuxを有効にする場合は以下の条件があります。 SELinuxモード ■ Enabled (enforcing または permissive) ・SELinuxが有効になっている場合、LifeKeeperは mmap_low_allowed が”on”である必要があります。 ・LifeKeeperインストールスクリプトは、SELinuxの有効を検出すると、この設定を自動的に更新します。 ・クラスター上で実行される全てのアプリケーションが、SELinuxモードをサポートしている必要があります。 ■ Disabled ・LifeKeeper for Linuxのインストールが可能です。 SELinux有効化は、 システム上の全アプリケーションがサポートされていることが必須だよ ！ ファイアーウォール LifeKeeper for Linuxは、以下のポートを開放し、各サーバーで相互に通信できるようにします。 設定してもインストールできない場合、 一時的にファイアーウォールを無効にしてください。 ファイアウォールの設定 ■ クラスタ対象サーバ間の双方向で許可が必要 ・TCP 7365       : コミュニケーションパスの通信で使用 ・TCP 5000       : REST API サーバ通信で使用    （LKWMC 用） ・TCP 10001 ～ : DataKeeperの同期で使用 *¹ ■GUIクライアントとクラスタ対象サーバ間の双方向で許可が必要 ・TCP 81, 82     : GUI サーバ通信で使用            （X forwarding用） ・TCP 5110       : GUI サーバ通信で使用            （LKWMC用） ・TCP 1024 ～   : GUIのためのRMI通信で使用 *² （X forwarding用） ※ クラスタ対象サーバとは LifeKeeperがインストールされるクラスターノードを指します。 *¹ 10001 + <mirror number> + (256 * i) の計算式で算出されるポートとなります。 *² ランダムポートを使用。アクセス制限をかけるのは難しため、必要に応じSSH X forwardingを検討してください。 GUIクライアントおよびクラスタ対象サーバを動作させるシステムで、これらのポートを開放する必要があります。 ファイアウォール設定は、インストールやGUIからの管理、そしてクラスター間の通信で重要となります。 DataKeeperを使用する場合、DataKeeper同期のポートを開放する必要があるわよ！ パッケージの依存関係 LifeKeeper for Linuxのインストールには、OSのアーキテクチャ (x86/x86_64)に一致した以下のパッケージが必要です。 ※ LifeKeeperはログの記録に rsyslogデーモンを使用します。    LifeKeeperをインストールする前に rsyslogを導入し、起動させておく必要があります。 LifeKeeperのインストーラーはyum/zypperを使うため、OSリポジトリーのセットアップを強く推奨します。 LifeKeeperオプションの Application Recovery Kit (ARK)の一部は、サポートパッケージのインストールが必要です。 詳細情報についてはこちらのリンクからご確認ください。 「Linux の依存関係」 OSのインストール設定によって、必要なパッケージの一部や全てが既に導入済みの時があるよ！ まとめ 今回は、LifeKeeper for Linuxのインストール要件について、ご紹介しましたがいかがでしたか。 ・システム要件では、条件を満たしているか、 余裕を持ったディスク設計かを確認する。 ・OSやカーネル、それからストレージでは、LifeKeeper のサポート対象であることを確認する。 ・ノード設定では、ホスト名/名前解決やSELinux、それからファイアウォール設定等を確認する。   詳細情報をご希望の方は、以下のバナーからSCSK Lifekeeper公式サイトまで

本記事では、ServiceNowのフローに追加された新アクション「Wait For Message」の使い方を紹介します。 「Wait For Message」アクションとは 指定したメッセージ文字列をFlowAPIから受け取るまで、フローを一時停止するアクションです。 オプションでタイムアウト値も設定でき、設定した時間を過ぎるとメッセージを受け取っていなくても次の処理に進むことができます。 Yokohamaバージョンで新しく追加された機能のため、まだ使ったことがない方が多いと思いますが、様々なフローに活用できそうなアクションですので本記事で使い方を紹介させていただきます。 使い方 フローの作成 まずは、以下のようなフローを作成していきます。 トリガーには「Incident Created」を指定し、インシデントが起票された時にフローが動作するようにします。 アクションには、「Wait For Message」と「Log」を作成します。 「Wait For Message」のMessageには再開用の文字列”Restart”を設定し、Timeoutには3分を設定します。 バックグラウンドスクリプトの作成 続いて、以下のように再開用の文字列をフローに送るためのバックグラウンドスクリプトを作成します。 ※ sys_idの値はこの後の手順で記載します。 var sys_id = " 後ほど記載 "; var message = "Restart"; sn_fd.FlowAPI.sendMessage(sys_id, message); 実行 フローを実行（テスト） 作成したフローをSaveし、任意のインシデントを選択してテストを実行します。 「Your test has finished running. View the flow execution details.」をクリックして詳細を見ると、「Wait For Message」アクションの部分で処理が一時停止し、その先の「Log」アクションが実行されていないことがわかります。 メッセージの送信 「Open context record」をクリックして開いたページから、sys_idをコピーします。 先ほどのバックグラウンドスクリプトのsys_idの部分にペーストし、「Run Script」をクリックしてスクリプトを実行します。 フローの詳細画面に戻り「Refresh Flow Data（赤枠で囲った矢印）」をクリックすると、「Wait For Message」アクションの処理とその先の「Log」アクションの処理がCompletedになり、完了していることが確認できます。 タイムアウトした場合 続いて、タイムアウトした場合の動作も確認します。 フローの画面に戻り、再度テストを実行します。 「Your test has finished running. View the flow execution details.」をクリックして詳細を見ると、「Wait For Message」アクションの部分で処理が一時停止し、その先の「Log」アクションが実行されていないことがわかります。 このまま3分間放置した後に「Refresh Flow Data（赤枠で囲った矢印）」をクリックすると、以下のようにタイムアウトして「Log」アクションが実行されていることが確認できます。 まとめ 以上が、Yokohamaバージョンから新しく追加された「Wait For Message」アクションの紹介になります。 これまでにも指定した時間待機するアクションはありましたが、メッセージが来るまで待機するアクションが新しく追加されたことでさらに便利になりました。 再開用の文字列とタイムアウト値（オプション）の設定のみで簡単に使用できますので、皆様もぜひご活用ください。

はじめに 今回はPrisma Cloudの次世代バージョンとして2025年2月に発表された、Cortex Cloudについて、AWSに実際に接続してみてアラートを取得してみようと思います。 Prisma CloudとCortex Cloudだと接続方法も変わってきますので接続手順をご紹介します。 AWSに接続 本環境は検証環境のため実際のコンソール画面と記事の内容が異なる可能性がある旨ご了承ください。 「Settings」>「Data Sources」を押下し、以下画像の様に移動します。 右上の「Add Data Source」を押下します。 「Amazon Web Services (AWS)」を選択します。 「Connect Another Instance」を押下します。 以下画像に遷移したら、「Scope」と「Scan Mode」を選択します。 Scopeには以下が選択できます。                 選択項目 説明 Organization 一元管理される AWS アカウント  Organizational Unit AWS アカウントのグループ Account 特定の AWS メンバーアカウント Scan Modeは以下が選択できます 選択項目 説明 メリット/デメリット Cloud Scan セキュリティスキャンをCortexCloudのクラウドアカウントの環境で実行します Cloud Scanが推奨されています メリット： セキュリティスキャンの追加費用は不要 デメリット： セキュリティスキャンされたデータがCortex Cloudのクラウドアカウント環境へ転送されるため、データを自社環境外に持ち出せない要件には不向き Scan with Outpost ユーザーが所有するクラウドアカウントにデプロイされたリソースに対して、セキュリティスキャンが実行されます。 このオプションを選択した場合は、このインスタンスで使用するアウトポストアカウントを選択します メリット： セキュリティスキャンが自クラウド環境で稼働するため、スナップショットデータが自クラウド環境外に転送されることは無い。 デメリット： 自クラウド環境で稼働するスキャンのコンピューティングコストが別途発生する 今回は「Scope」はAccountで「Scan Mode」はCloud Scanを選択しました 選択後右下の「Save」を押下します。 次にAWS でCloud Formationテンプレートを実行します。 2つの設定値があります。              選択項目 説明 Automated Execute in AWSをクリックして AWS CloudFormation に接続し、スタックを作成します。 ※事前にAWSにログインしている必要があります。 Manual Download CloudFormation  をクリックし、指示に従って AWS で CloudFormation テンプレートファイルを手動で実行します。 今回はAutomatedを選択し、自動実行します。 「Execute in AWS」を押下するとAWSに移動し、CloudFormationスタック作成画面に遷移します。 「スタック名」と以外はデフォルトで値が入っています。 値を入力後「スタックを作成」からスタックを作成します。 スタック作成が正常に完了すると以下画像の様に「CREATE_COMPLETE」と出ます。 Cortex Cloudの画面に戻ると以下画像の様に「Instance Created Successfully」と出ていますので、Closeを押して閉じます。 接続されているインスタンス（AWSアカウント）の数が増えていることを確認します。 元々私の環境では「1 Instances Configured」だったので「2 Instances Configured」と表示されたことでアカウントが接続できたことが分かります。 ポリシーの作成 アカウント接続のみではアラートが取得できないのでポリシーを作成していきます。 ポリシーはPrisma Cloudおけるアラートルールと同じです 1. 左ペイン「Posture Management」>「Rules & Policies」 > 「Create Policy」を押下します。 2. Create Policyを押下すると以下画像の様に遷移します。 以下入力をしてから「Next」を押下します。 Policy Name :  任意のポリシー名 Description  ： 任意のポリシーの説明 Labels         ： ラベルを追加したい場合は任意のラベル名を入力 3. アラートを取得する範囲を選択します。 今回はAll Rulesを選択します。選択したら「Next」を押下します。 All Matching Filter Criteria : フィルター条件に一致するアラートを取得します From Rules List                : ルールリストからアラートを取得します All Rules                          : すべてのルールからアラートを取得します 4. アラートを受け取る対象の範囲を選択します。 以下オプションから選択します。今回はAll Cloud Assetsを選択しました。 選択後「Done」を押下し作成します。 From Cloud Accounts: クラウドアカウントを選択しアラートを受け取る範囲を選択します From Asset Groups   : アセットグループ(Prisma Cloudのアカウントグループ)を選択し受け取る範囲を選択します All Cloud Assets        : すべてのクラウドアセットを選択します。 5. ポリシーが追加されていることがわかります。 これでポリシー作成は完了です。 アラート取得できているか確認 接続後正常にアラートが取得できているかを確認します。 「Case & Issues」> 「Issues」に移動します。 フィルターの「Asset Accounts」から先ほど追加したAWSアカウントIDが表示されますので適応します。 適応後以下画像の様にIssuesがでていることが確認できます。 Cortex CloudではアラートがIssuesとなっています。 対象のIssuesを押下するとOverviewが確認できます。 ここには脆弱性に関する詳細な情報などが書かれています。 「Case & Issues」> 「Cases」に移動します。 フィルターの「Asset Accounts」から先ほど追加したAWSアカウントIDが表示されますので適応します。 適応後以下画像の様にCaseが表示されていることが確認できます。 対象のCaseを押下するとIssuesと同じくOverviewなどを確認することができます。 Overviewではアラートが出ているIssuesのAssetsの情報やIssuesの重要度の割合などを表示してくれています。   さいごに 今回はCortex CloudでAWS接続してみました。 CloudFromationスタックを作成するだけで簡単に接続することができるので追加で接続する際にも簡単にできそうです。 当社では、複数クラウド環境の設定状況を自動でチェックし、設定ミスやコンプライアンス違反、異常行動などのリスクを診断するCSPMソリューションを販売しております。 マルチクラウド設定診断サービス with CSPM｜ SCSK株式会社 ご興味のある方は是非、お気軽にお問い合わせください。

こんにちは。New Relic技術担当の井上です。 「システムが遅い」「原因がわからない」「ログはあるけど、何を見ればいいの？」現代の複雑な分散システムにおいて、こうした悩みは日常茶飯事です。そんな中、“オブザーバビリティ”という考え方が注目されています。この記事ではオブザーバビリティとは何か、オブザーバビリティ製品の中で、なぜNew Relicが優れているのかをご紹介をします。 オブザーバビリティとは 「オブザーバビリティ（Observability）」の用語の意味から見ていきます。「観測する（Observe）」と「能力（Ability）」を組み合わせた言葉で、日本語では「可観測性」や「観測する力」と訳されます。 オブザーバビリティとは、システムの中で何が起きているかを外から見て理解するための能力 を指します。アプリケーションやシステムが動く中で生まれる大量の情報から、内部の状態を読み取る技術です。「エラーが起きた」という結果を見るだけでなく、その原因をたどることで、どこで何が問題だったのかを明らかにします。これにより、予期しないトラブルにも素早く対応できるようになります。 参考: オブザーバビリティ・エンジニアリング – O’Reilly Japan         オブザーバビリティとは？監視との違い、必要性について解説 | New Relic   オブザーバビリティの考えがなぜ重要とされているか 最近では、最初からクラウド環境でアプリを動かしたり、ソフトウェアを開発したりする「クラウドネイティブ」な分散型システムが広く使われるようになってきました。この分散型システムには、機能の追加や変更がしやすく、必要に応じてスケールさせたり、止まらずに動かし続けたりできるというメリットがあります。 ただし、複数のコンピューターが連携して動くため、管理すべき対象が増え、運用が複雑になりがちです。しかも、それぞれが異なるインフラ上で動いていることも多く、トラブルが起きたときに原因を特定するのが難しく、時間がかかってしまいます。 オブザーバビリティが実現されると、さまざまなデータソースから集めた情報をリアルタイムで確認できるようになります。 これにより、チームは すばやく問題を見つけて解決できるだけでなく、トラブルの予防や運用の効率化 も可能になります。結果として、ユーザーにとって快適で信頼性の高い体験を提供できるサービスを提供し続け、競争力を高めることができます。 上記の背景から、 システムの状態を俯瞰的に見て理解する「オブザーバビリティ（可観測性）」の重要性が高まっている のです。   参考: オブザーバビリティとは？監視との違い、必要性について解説 | New Relic         2024年オブザーバビリティ予測レポート   オブザーバビリティ市場の動向 Data Observability Market Report2025によると、データオブザーバビリティ市場規模は近年急速に成長しています。2025年には年間平均成長率（CAGR）は16.1％になると予想されます。今後数年間で急速な成長が見込まれており、2024年の25億3,000万ドルから2029年には15.5％のCAGRで52億3,000万ドルに達すると予測されています。地域別では アジア太平洋がもっとも急成長する地域 としてレポートされています。クラウドベースのソリューションの拡大により、データ量の増加がオブザーバビリティ市場の成長を加速している一因であることが考えられます。 オブザーバビリティを実現するために、どのような製品があるのか、製品の機能や市場への対応力、技術革新、戦略などをもとに、オブザーバビリティ関連の企業を評価する「Gartner Magic Quadrant for Observability Platforms」レポートがあります。オブザーバビリティ市場のリーダを牽引しているのはDynatrace、Datadog、Grafana labs、New Relic。その中でも New Relicは13年連続で“リーダー”のポジション に選ばれています。13年連続で選出されていることで、信頼や技術力、市場変化の柔軟な対応力が実証されていることがわかります。 参考: Data Observability Market Report 2025 – Insights And Trends to 2034         2025 Gartner Magic Quadrant for Observability | New Relic New Relicの特徴 New Relicは2008年に創業し、その10年後の2018年に日本法人が設立されています。 国内オブザーバビリティ市場で6年連続売上シェアNo.1 を獲得しており、オブザーバビリティ製品において高い名声を得ています。余談ですが、New Relicという社名は、創業者 Lew Cirne（ルー・サーニー） の名前を並び替えたアナグラムです。 参考: New Relic、国内オブザーバビリティ市場で6年連続売上シェアNo.1を獲得 | New Relic   New Relicの主なサービスはどのようなものがあるのかを見ていきます。New Relic は、システム全体の可観測性（オブザーバビリティ）を実現するために、以下の3つの機能レイヤーで構成されています： 1. データの一元管理機能 New Relic が収集するあらゆるデータを一元管理するプラットフォーム(Telemetry Data Platform)です。アプリケーションやインフラストラクチャのデータを収集、可視化することができます。これにより、開発、運用、サポートなど、異なるチームが同じデータを共有できることで、共通の認識を持って問題解決に取り組めます。 役割 ：あらゆるテレメトリーデータ（ログ、メトリクス、トレースなど）を収集・保存・検索。 ポイント ：データの一元管理と高速なクエリが可能。NRQL による柔軟な分析もサポート。 ダッシュボード画面   ログデータ画面   2. システム全体の可視化機能 APM（アプリケーションパフォーマンス管理）、インフラ、ログ、そしてデジタルカスタマー体験など、ソフトウェア全体の仕組みをまとめて分析する機能(Full-Stack Observability)です。これにより、問題の発見から解決までのスピードが大幅に向上し、トラブルシューティングがこれまでになくスムーズになります。 役割 ：アプリケーション、インフラ、ユーザー体験まで、システム全体を可視化。 ポイント ：APM、インフラ監視、分散トレーシングなどを通じて、問題の特定とパフォーマンス改善を支援 基本機能について以下にまとめました。 基本機能 モニタ内容 New Relic APM アプリケーションパフォーマンス監視 データベース稼働状況、外部サービス呼出/応答状況、例外処理（エラー）状況、スループット、 トランザクションタイム、プロセス毎のCPU/メモリ使用率などの情報を収集可能 New Relic INFRASTRACTURE インフララストラクチャ監視 CPU使用率、メモリ使用率、ディスク使用率、ネットワーク使用率などの情報を収集可能 New Relic BROWSER ブラウザ監視（RUM：リアルユーザモニタリング） ページビュー・ユーザ側の行動状況（読込時間、サイト移動、パフォーマンス）、アプリケーション 速度・パフォーマンス、Javascriptエラー、AJAXリクエストなどの情報を収集可能 New Relic MOBILE モバイル監視 Android/iOS/ハイブリッドモバイルアプリケーションのパフォーマンスとトラブル状況を可視化。 HTTPレスポンス・HTTPエラーコード、セッション状況などの情報を収集可能 New Relic SYNTHETICS 外形監視 特定のWebサイト/アプリケーション/APIエンドポイントへのテストリクエスト送信 による稼働状態・応答時間をモニタリング その他 その他機能 ログ管理、サーバレス機能監視、Kubernetesモニタリング、アラート設定・通知設定、 インベントリ管理・脆弱性情報収集、他 3. 業務活用型AI機能 AIを活用して、インシデントの早期発見・分析・対応を実現します。異常検知や予測に加え、ITSMとの連携や相関分析の仕組みも構築できます。AIによる異常検知や予測により、問題が大きくなる前に対応できるため、ダウンタイムやユーザーへの影響を最小限に抑えられます。 役割 ：AI/ML による異常検知、アラートのノイズ削減、インシデントの自動分析。 ポイント ：運用負荷を軽減し、迅速な意思決定をサポート。 参考: New Relic の主要機能 | New Relic   他社製品との比較 「Gartner Magic Quadrant for Observability Platforms」のレポートでリーダとして選出されている国内主要3製品について機能をまとめました。 項目 New Relic Datadog Dynatrace 他製品とのインテグレーション ○ ○ ○ 監視機能(APM/インフラ/外形監視) ○ ○ ○ ログ管理 ○ 〇 ○ 課金ポリシー ※いずれも＋データ量課金あり ◎ ユーザ数課金 〇 ホスト課金 〇 ホスト課金 無料枠 ◎ ユーザ1名+100GB/月 〇 一定期間のみ 〇 一定期間のみ   1ユーザ+100GB無料が永久に使える ことがかなり魅力的です。まずは試しに入れてみたい、操作してみたいというスモールスタートには最適な製品であることがわかります。また、サポート面においてもNew Relicは日本国内法人を設立し、技術サポートを日本語で問いあわせできるが魅力の一つになります。 参考: New Relic、Datadog、Dynatrace のコスト比較 |ニューレリック         New Relic vs. Datadog Comparison | New Relic         New Relic vs. Dynatrace | New Relic         New Relic の新しい製品体系と価格体系 さいごに オブザーバビリティとは何か？オブザーバビリティ製品において、New Relicがどのような特徴を持っており、他社との差別化を図っているのかを少しでもご理解いただけたら幸いです。 SCSKはNew Relicのライセンス販売だけではなく、導入から導入後のサポートまで伴走的に導入支援を実施しています。くわしくは以下をご参照のほどよろしくお願いいたします。

こんにちは。 Raspberry PiとAWSをつなげて何かできないかと思い、今回はRaspberry Piに気温/気圧/湿度センサーを接続して、取得した情報をAWS IoT Coreに送り、S3バケットに情報を保存するところまでやってみようと思います。 構成イメージ 今回AWS上で構築するリソースとデータの流れは以下のイメージです。 センサー ⇒ Raspberry Pi ⇒ AWS IoT Core ⇒ S3バケットの順でデータが流れる想定です。 Raspberry Pi上でPythonスクリプトを動かして取得データをMQTTでAWS IoT Coreに送り、AWS IoT CoreでメッセージをS3バケットに保存するようにルール設定をしてみようと思います。   用意するもの 今回使うものは以下の通りです。 ・Raspberry Pi 5 ・温湿度・気圧センサーモジュールキット (BME280使用) ・ジャンパーケーブル×5 ・ブレッドボード×1 (・AWSコンソール接続用PC)   Raspberry Pi 事前設定 今回やりたいことを実施するために、いくつかRaspberry Pi上で設定しておく必要があります。 ・I2C通信の有効化 ・必要なライブラリのインストール ・温湿度・気圧センサーモジュールキットとRasberry Piの接続 以上の設定方法を順を追って説明します。 ※今回は取得したデータをRaspberry Piから送り、AWS上へ保存することがメインのため簡単に説明します。 Raspberry Pi設定：I2C有効化 Raspberry Piとセンサーの通信を行うために、Raspberry Pi側でI2C通信を有効化します。 コンソールで以下のコマンドを実行します。 sudo raspi-config GUIが立ち上がったら以下の手順でI2C通信を有効化します。 ①「３．Interface Options」を選択して[ENTER]キーを押下 ②「I5 I2C」を選択し、[ENTER]キーを押下 ③ 確認画面が表示されたら<はい>を選択し、[ENTER]キーを押下 ④ I2Cが有効化されたメッセージが表示されたら[ENTER]キーを押下 ⑤ Raspberry Piを再起動する Raspberry Pi設定：ライブラリのインストール BME280センサーからデータを取得するために、以下のコマンドを実行して必要なライブラリを追加します。 sudo pip3 install smbus2 –break-system-packages sudo pip3 install bme280 –break-system-packages sudo pip3 install paho-mqtt –break-system-packages ※インストールオプションに「–break-system-packages」をつけないと、インストール時にエラーになります。 温湿度・気圧センサーモジュールキットとRasberry Piの接続 センサーをRaspbarry Piにつなぐため、まずはブレッドボードに温湿度・気圧センサーモジュールキットを接続します。 次に回路とRaspbarry Piを接続します。 センサー側 Raspberry Pi側 BME280 VDD 3.3V：1ピン BME280 GND GND：9ピン BME280 SDI GPIO2(SDA)：3ピン BME280 SDO GND：6ピン BME280 SCK GPIO3(SDL)：5ピン ちょっと見づらいですが、実物はこんな感じ↓です。 　 接続が終わったら、以下のコマンドを実行します。 sudo i2cdetedt -y 1 実行結果に「76」という表記があれば、正常に接続できています。   AWS設定 さて、Rasberry Piの下準備が完了したところで、次にAWSの設定を実施していきます。 今回AWS上で設定が必要なのは以下の通りです。 ・S3バケットの作成 ・AWS IoT Coreのポリシー作成 ・Raspberry Piの登録と接続用証明書発行 ・AWS IoT Coreのエンドポイント作成 ・AWS IoT Coreのルール設定 こちらも順を追って説明していきます。 S3バケットの作成 まずは、最終的にデータが保存されるS3バケットを作成します。 ※下図の赤枠部分 AWSコンソールにログインして、Amazon S3を開きます。 [汎用バケット]＞[バケットを作成]からバケットを作成します。 ※今回は特別な設定は実施せず、すべてデフォルトのまま作成します。 AWS IoT Core：ポリシー設定 ここからはAWS IoT Coreの設定を実施します。 ※下図の赤枠部分 まずは、Raspberry PiがIoT Core向けに実施できる操作を制御する「ポリシー」を設定していきます。 ※このあと発行する証明書にポリシーをアタッチすることで、実施できる操作が制御されます。 AWSコンソールでIoT Coreを開いて、[管理]＞[セキュリティ]＞[ポリシー]を開いてください。 ポリシーが表示されたら、画面右上の[ポリシーを作成]からポリシーを作成していきます。 作成画面が表示されたら、ポリシー名と許可するアクションを設定します。 今回は一通りのMQTTアクションを許可するため、以下の許可設定とします。 すべて設定し終えたら、画面右下の[作成]でポリシーを作成します。 ポリシー効果 ポリシーアクション ポリシーリソース Allow iot:Connect * Allow iot:Publish * Allow iot:Receive * Allow iot:Subscribe * 以上でポリシーの作成は完了です。 AWS IoT Core：Raspberry Piの登録と接続用証明書発行 ポリシーの作成が完了したら、Raspberry PiをIoT Coreへ接続するための証明書を発行します。 [管理]＞[すべてのデバイス]＞[モノ]を開き、画面右上の[モノを作成]からデバイスを登録していきます。 作成するものの数は1つを選択し、次へ進みます。 モノのプロパティはデフォルト設定のまま、次へ進みます。 今回は、デバイスシャドウも「シャドウがありません」のままで問題ないです。 デバイス証明書の設定は「新しい証明書を自動生成 (推奨)」を選択したまま、次へ進みます。 ポリシーの選択では、先ほど作成したポリシーにチェックを入れ、「モノの作成」を押下してください。 「モノの作成」を押下すると、証明書ファイルのダウンロード画面が表示されますので、必要な証明書をダウンロードします。 今回利用するのは、以下の3ファイルです。 ・デバイス証明書ファイル (.crt) ・プライベートキーファイル (*****-private.pem.key) ・「Amazon ルートCA 1」のルートCA証明書ファイル 以上で証明書の発行は完了です。 AWS IoT Core：エンドポイント作成 続いて、Raspberry PiがMQTT接続する際の接続先になるエンドポイントを作成していきます。 IoT Coreコンソールの[接続]＞[ドメイン設定]を開き、[ドメイン設定を作成]からエンドポイントを作成します。 作成画面が開いたら、以下の通り設定します。 ※記述の無い箇所はデフォルトのままで結構です。 ・ドメイン設定名：任意の名前 ・ドメインタイプ：AWSマネージドドメイン (カスタムドメインも利用できるようですが、今回はマネージドを利用します。) ・アプリケーションプロトコル：セキュアな Websocket 経由の MQTT ・ドメイン設定のステータス：有効にする 設定し終えたら、[ドメイン設定を作成]を押下します。 ドメイン設定が作成出来たら、作成したドメイン設定の「ドメイン名」を控えておいてください。 (後ほど作成するPythonスクリプトの中に記述します。) 以上でエンドポイントの作成は完了です。 AWS IoT Core：ルール設定 最後に、Raspberry Piから送信されてきたときのルール設定をします。 ルール設定では、ルールの対象とするメッセージをSQL形式で指定出来たり、 そのメッセージに対するアクションを設定することができます。 IoT Coreコンソールの[管理]＞[メッセージのルーティング]＞[ルール]を開き、[ルールを作成]からルールを作成します。 ルールのプロパティ設定画面が表示されたら、任意のルール名を入力して次へ進みます。 次に、SQLステートメントを設定します。ここで設定したSQLに従って、対象とするメッセージを抽出します。 今回は、「topic/」から始まるすべてのメッセージを対象としたいため、以下の通りSQLステートメントを入力し、次へ進みます。 SELECT * FROM ‘topic/#’ 続いて、ルールアクションを設定します。 ルールアクションでは、SQLに従って抽出したメッセージに対して、どのようなアクションを実行するかを設定できます。 今回は冒頭に説明した通り、受け取ったメッセージをS3バケットに出力したいため、以下の通りアクションを追加し、次へ進みます。 ・アクション：S3 bucket ・S3 URI：先ほど作成したS3バケット ・キー：iot/${topic()}/${timestamp()}.json ・IAMロール：アクションに必要なアクセス許可が付与されたロール キーの設定では、メッセージがS3バケットに保存される際のパスとファイル名を指定します。 今回は「iot/トピック名」の下に、「タイムスタンプ.json」というファイル名で、メッセージが保存されるように指定しています。 また、IAMロールについては、今回は「AmazonS3FullAccess」を付与したロールを指定しています。 ※作成されていない場合は、このタイミングで作成してください。 最後に設定確認画面が表示されますので、[作成]を押してルールを作成してください。 以上で、すべてのAWS設定が完了しました。   Pythonスクリプトの作成 ここまで来たら、残すはPythonスクリプトを作成して、Raspberry Pi上で動かすだけです。 Pythonスクリプトのコードを以下に記述します。 こちらのスクリプトでは、AWS IoT CoreのエンドポイントへMQTTクライアント接続し、 センサーで取得した情報を5秒おきにエンドポイント向けにパブリッシュします。 トピック名は「topic/raspi1」としているため、パブリッシュされたメッセージは先ほどのルール設定に引っかかって、 S3バケットに保存されるという算段です。          ※事前にRaspbarry Piにダウンロードした証明書ファイルを保存しておいてください。 ※以下はご自身の設定に合わせて置き換えてください。 ・IoT Coreのエンドポイントドメイン名 ・各種証明書ファイルのパス/ファイル名 import time import json import socket from datetime import datetime import ssl import paho.mqtt.client as mqtt from smbus2 import SMBus import bme280 #AWSエンドポイント情報 aws_endpoint = "********.amazonaws.com" #作成したエンドポイントのドメイン名 aws_port = 8883 #MQTTトピック設定 mqtt_topic = "topic/raspi1" #AWS証明書 ca_path = "*************.pem" #「Amazon ルートCA 1」のルートCA証明書ファイル crt_path = "*************.pem.crt" #デバイス証明書ファイル (.crt) key_path = "*************-private.pem.key" #プライベートキーファイル (*****-private.pem.key) # BME280のI2C定義（I2Cポート1、アドレスはSDOをGNDなら0x76） i2c_port = 1 i2c_address = 0x76 # I2Cバス・BME280初期化 bus = SMBus(i2c_port) bme280.load_calibration_params(bus, i2c_address) # キャリブレーション #MQTTクライアント接続 client = mqtt.Client() client.tls_set(ca_certs=ca_path, certfile=crt_path, keyfile=key_path, tls_version=ssl.PROTOCOL_TLSv1_2) client.connect(aws_endpoint, aws_port, keepalive=60) client.loop_start() time.sleep(1) hostname = socket.gethostname() try: while True: # BME280データ取得 data = bme280.sample(bus, i2c_address) temperature = data.temperature humidity = data.humidity pressure = data.pressure now = datetime.utcnow().isoformat() + "Z" payload = { "datetime": now, "hostname": hostname, "temperature": round(temperature, 2), "humidity": round(humidity, 2), "pressure": round(pressure, 2) } client.publish(mqtt_topic, json.dumps(payload), qos=1) print("published:", payload) time.sleep(5) except KeyboardInterrupt: print("終了します。") finally: client.disconnect() bus.close()   Pythonスクリプトの実行/動作確認 ここまでですべての準備が整いましたので、実際にRaspberry Pi上でPythonスクリプトを動かして動作を確認してみましょう。 Raspbarry Piでコンソールを開いて、以下のコマンドを実行してください。 今回はPythonスクリプトのファイル名を「sensor.py」としています。 python3 sensor.py スクリプトを実行すると、コンソール上で5秒おきにメッセージをパブリッシュした旨の出力がされます。 パブリッシュされたメッセージはIoT Coreで設定したルールの通り、指定のS3バケットへjson形式で保存されます。 ダウンロードしたファイルをメモ帳で開いてみると、気温/気圧/湿度が記述されたメッセージがそのまま保存されていることが 分かります。           以上で、Raspberry PiとAWS IoT Coreを連携し、センサーで取得したデータをS3バケットに保存することができました。   最後に 今回はRaspberry Piに気温/気圧/湿度センサーを接続して、取得した情報をAWS IoT Coreに送り、S3バケットに情報を保存するところまでやってみました。 個人的にはRaspbarry PiもAWS IoT Coreも初めて触る代物だったため、構成はかなり簡単めかな？と思っております。 皆様もぜひとも触ってみてはいかがでしょうか。 また、続きとして、今回S3バケットに保存したデータをQuickSightで可視化してみる記事もございますので、 ぜひともご覧ください。 https://blog.usize-tech.com/visualize-iot-data-raspberrypi-aws/ もっと詳しく調べたら色々できそうだと思ったので、まだまだたくさん触ってみたいと思います。 最後まで読んでいただきありがとうございました。

こんにちは。SCSKの松渕です。 Google Cloudで ファインチューニングが簡単に実装できる と聞いたので、実践してみたいと思います。 はじめに ファインチューニングとは ファインチューニングとは、 事前学習済みの大規模言語モデル（LLM）を、特定のタスクやデータセットに合わせて、追加で学習・調整する ことです。 これは、モデルの基本的な知識や言語能力を活かしつつ、特定の用途（例：社内文書の要約、特定のトーンでの応答、固有の知識の習得）に特化させるために行われます。 なんだか、RAGとの違いがよく分からないですね。ということでRAGとの違い、使い分けを整理します。 RAGとの違い Geminiに整理いただきました。 特徴 RAG (検索拡張生成) ファインチューニング (モデル調整) 目的 最新 ・ 専門 の 外部情報 に基づいて、正確な回答を生成すること。 モデルの 振る舞い （スタイル、トーン、出力形式）や ドメイン知識 を改善すること。 仕組み 質問と関連性の高い外部文書を 検索 し、その文書をプロンプトに 追記 してLLMに入力する。モデル自体は 変化しない 。 カスタムデータ を使ってモデルの 重み（パラメータ）を更新し、モデルを恒久的に変更 する。 必要なデータ 検索対象となる 参照文書 （PDF、社内文書、データベースなど）。 高品質 な 質問と回答のペア や 指示 データ。 コスト/時間 低い 。主に検索システム（ベクトルデータベースなど）の構築・維持費用。 高い 。大量のGPUリソースと時間が必要（特にベースモデルが大きい場合）。 更新頻度 容易 。参照文書を更新するだけで、即座に結果に反映される。 困難 。データが更新されるたびに、トレーニングをやり直す必要がある。 学習限界 モデルが参照文書に ない 情報を 生成 することはできない。 モデルが学習データに 含まれない 知識（新しい事実）を 知る ことはできない。 RAGのほうが向いているケース 情報が頻繁に更新 される 情報の 出典を明確化 したい ※どのドキュメントの何ページ目　まで出典明記したい場合、チャンク化やメタデータ設計を適切に実施する必要あり 事実の 正確性が最重要 （ハルシネーション対策） ファインチューニングのほうが向いているケース 特定の スタイルやトーンの統一 （jsonなどの出力形式の固定なども可能） トークン効率の改善。 モデルの プロンプトサイズを削減 し、コストとレイテンシを改善したい場合 ハイブリッド（RAG + ファインチューニング） 上記参照いただくとわかる通り、RAGとファインチューニングは 二者択一のものではありません 。これら二つを組み合わせることで、 ファインチューニング でモデルに 出力形式とスタイル を学習させ、 RAG でモデルに 最新かつ正確な事実 を提供する、カスタムAIシステムを構築できます。 今回実装する方式について 今回は、Google Cloudで 簡単にファインチューニングできる 教師ありファインチューニング サービス を利用します！ ベースとなるモデルは、 Gemini とGemma、Llamaなどの一部のOSSのモデルでした。 詳細は以下参照ください。 Gemini モデルの教師ありファインチューニングについて(Google Cloud ドキュメント)   事前準備 やりたいことを整理 何より大事ですね。RAGとの使い分けの部分の調査から、 Geminiの応答口調を調整してみよう と思います。 小難しいカタカナ英語ばっかり使う ようにファインチューニングします。 データさえあれば、 「〇〇さんっぽく応答してくるAI」 とかは盛り上がること間違いなし！ データの準備 学習大規模言語モデル（LLM）のファインチューニングには、 対話形式のデータセット を学習用データとして準備する必要があります。 特定のタスク（この場合は要約）をモデルに学習させるための 入力（ユーザーのプロンプト）と、それに対する理想的な出力（モデルの応答）のペア として構成されています。 Google社が提供している 学習データのサンプル が こちら 。JSON Lines形式で記載されています。 私が準備した学習データの一行抜粋します。（私は今回、 Gemini使って400行程度準備 してもらいました） {“contents”: [{“role”: “user”, “parts”: [{“text”: “業務の引き継ぎで失敗しないためには？”}]}, {“role”: “model”, “parts”: [{“text”: “タスクのスコープとネクストアクションをマストで文書化し、クリティカルなプロセスは複数のメンバーでコンセンサスを取るべきです。”}]}]} 実際に言われたら、私なら思わず聞き返してしまうかもしれません。 1行で対話のひとつのターン（発話）を表しています。 "role": "user" ：この発話が ユーザー（入力側） からのものであることを示しています。 "parts": [...] ：発話の 内容（テキストや画像など）を格納 する配列です。 "text": "..." ：ユーザーがモデルに与えた 指示（プロンプト）の本文 です。 この例では、「業務の引き継ぎで失敗しないためには？」という文章です。 "role": "model" ：この発話が モデル（出力側）の理想的な応答 であることを示しています。 "text": "..." ：モデルがこのプロンプトに対して学習すべき 正解の回答 です。 小難しい横文字ばかり使ってますね。 データ準備についての各種注意事項は以下参照ください。 データ数としては、 100 個のサンプルから始めて、必要に応じて数千にスケールする ことをおすすめします。データセットは量よりも質のほうがはるかに重要です。 Gemini モデルの教師ありファインチューニング データを準備する(Google Cloud ドキュメント)   ファインチューニング実施 ファインチューニング開始 「Vertex AI」の「チューニング」画面から 、「チューニング済モデルを作成」を押下 します   作成画面に移ります。 モデル名は適当に入力 します。（キャプチャは入力前ですが） ベースモデルを選択 します。今回はgemini-2.5-flash-lightを選択します。 リージョンを選択 します。 日本のリージョンは選択できません でした。（2025/10現在） EUかアメリカのどこかを選択します。   エポック数、学習率の乗数など細かい設定も可能です。今回はデフォルトのまま進めます。   データセットを選択します。Geminiに作成してもらったデータから 一部（20サンプル）を検証用データセットとして設定 します。   検証をセットすると最後に 検証データを利用した評価まで自動で実施 してくれます。 マネージドのメリットを最大限生かすためにも、検証データセットを用意しましょう。 検証用データと学習データは重複しないよう に準備 します。   学習待ち 「Vertex AI」の「チューニング」画面に作成中のモデルの表示が出てきますので、完了まで待ちます。   今回のケースでは作成にかかった時間は 22分程度 でした。     結果確認とテスト 結果確認 テスト完了したら、結果を確認します。「成功」と表示されているので、大丈夫そうです。 そのほか、各種評価指標もよさげです。 正確性が1に近く、Lossも0に近い 。 ピンク（検証用データの値）と青（学習用データの値）も大きく差はなさそう に見えます。   テスト 「テスト」ボタン が上部にありましたので、押下します。 モデル選択画面が出てきますので、先ほど作成したモデルを選びます。 Google検索へのグラウンディング、RAGへのグラウンディングも可能 です。 今回は使わないのでOFFのまま。   温度（temperature）やTop-Pなどのチューニングも可能。 今回はデフォルトのままで進めます。   適当にプロンプト投げて応答の確認見てみます。左がモデルの応答で、右が私のプロンプトです。 いい感じに煩わしいですね！！大成功です！！   コストの確認 後日、コスト確認しました。合計　 \161- 　でした。（Gemini 2.5 flash lite tuning　の料金） 安っ・・・！！ まとめ 本ブログでは、Google CloudのVertex AIを活用し、 大規模言語モデル（LLM）のファインチューニング を実践しました。基本的な知識から実践的な手順、そして成功の鍵となるRAGとの使い分けまでを解説しました。 本ブログを書く中で、 RAGとファインチューニングの使い分け を整理、理解できた のは大きかったです。 また、ファインチューニングはハードル高い技術だと思ってましたが、ここまで 簡単に実装できる とは驚きが隠せません。 AutoML の時も、 コーディングAIエージェント の時も驚きでしたが、 AI周りの技術は本当に日々進歩してます ね。。 データ準備さえできたら、 「〇〇さんそっくりAI」 はいつか作ろうと思います！！

こんにちは。SCSKの安藤です。 「 Zabbix Conference Japan 2025 」にプラチナスポンサーとして出展します。 本カンファレンスでは、Zabbix社創設者兼CEO Alexei Vladishev による基調講演をはじめ、Zabbixメンバーによる最新機能の紹介、ユーザー企業による事例発表、関連ソリューションの紹介など、Zabbixをより深く理解できる多彩なプログラムをご用意しております。 Zabbixの魅力を再発見する機会として、ぜひご参加ください！ 開催概要 事前ウェビナー   【日時】　　11月4日(火)　10:30-17:00 　　　　　   11月5日(水)　10:30-17:00 【会場】　　オンライン 本編   【日時】　　11月6日(木)　10:00-17:20 　　　　　   11月7日(金)　10:00-17:10 【会場】　　東京ポートシティ竹芝 ポートホール 　　　　　　(オンライン配信およびアーカイブ配信はございません。)   当社講演 事前セミナー 【タイトル】　　～限界シリーズ～　第2弾 Zabbix7.0のパフォーマンス限界調査編（再） 【日時】 11月4日(火)　11:30-11:50 【概要】 Zabbix7.0LTSの新機能である、Pollerプロセスの並列処理実行について、どの程度処理性能向上に寄与しているのか、 実際に試してみました。昨年のZabbixカンファレンスでご好評いただいた講演を再度お届けします。 【登壇者】 上田 太一（ITインフラサービス事業グループ 基盤ソリューション事業本部 テクノロジーサービス部） 本編 【タイトル】　　AIエージェントが変えるZabbix運用の未来 【日時】 11月7日(金)　11:25-11:55 【概要】 日々のZabbix運用において、監視対象の追加、監視設定、マップ作成、障害対応など、さまざまな業務があります。 本プレゼンテーションでは、AIにより、これらの業務が効率化できることをデモを交えて発表致します 【登壇者】 新沼 俊介（ITインフラサービス事業グループ 基盤ソリューション事業本部 テクノロジーサービス部）   詳細・お申込み 以下よりお申込みください。 Zabbix Conference Japan 2025｜EventRegist（イベントレジスト） 「Zabbix Conference Japan 2025」の告知ページです。 eventregist.com   当日は皆さまのご来場を心よりお待ちしております！       SCSK Plus サポート for Zabbix SCSK Plus サポート for Zabbix 世界で最も人気のあるオープンソース統合監視ツール「Zabbix」の導入構築から運用保守までSCSKが強力にサポートします。 www.scsk.jp   ★YouTubeに、SCSK Zabbixチャンネルを開設しました！★ SCSK Zabbixチャンネル SCSK Zabbixチャンネルでは、Zabbixのトレンドや実際の導入事例を動画で解説。明日から使える実践的な操作ナレッジも提供しており、監視業務の効率化に役立つヒントが満載です。 最新のトピックについては、リンクの弊社HPもしくはXアカ... www.youtube.com   ★X（旧Twitter）に、SCSK Zabbixアカウントを開設しました！★ https://x.com/SCSK_Zabbix x.com

こんにちは！Catoクラウド担当、佐藤と申します！ 約1か月前に新人研修が終わり、初期配属でCatoクラウドを担当することになりました。 今回は、CatoクラウドのvSocket構築の手順を解説いたします。 私自身もまだまだ勉強中ですので、そういった目線で感じたことや、つまずいたポイントなどを共有できればと思います！ はじめに 近年、クラウドサービスはますます進化しており、多くの組織でオンプレミスからクラウドへの移行が進んでいます。 その中で、AWSなどのクラウド環境とCatoクラウドを連携させたいと考えている方も多いのではないでしょうか？ この記事では、 AWS環境上にvSocketを構築し、Catoクラウドと接続するまでの手順を紹介します。 手順説明では、実際に私が検証した際の設定を表示して進めていきますので、「簡単に試してみたい！」という方は、画像内で入力されている設定を参考にしていただけると幸いです。（小さくて見えずらいかもですが…） 事前準備 通常、組織のネットワーク環境をCatoクラウドへ接続するためには、Socketと呼ばれる実機アプライアンスが必要です。しかし、パブリッククラウド環境（今回はAWS）とCatoクラウドを接続する場合は、 vSocket(virtual Socket） という仮想アプライアンスをAWS環境上に構築し、Siteと接続することでクラウド環境をCatoネットワークに統合することができます。 AWS上にvSocketを構築するにあたり、以下３つのサブネットが必要です。 MGMTサブネット（public)：vSocketの管理用 WANサブネット(public)：vSocketとCatoクラウドを接続する外部通信用 LANサブネット(private)：vSocketと内部環境を接続する内部通信用 全体の構成を以下に示します。      vSocket構築手順 vSocketの構築手順の解説をしていきます。 以下のステップで設定を進めます。 1. Catoクラウド vSocket Siteの設定 2. AWS設定 　2-1. Elastic IPアドレス取得 　2-2. VPC作成 　2-3. サブネット作成 　2-4. インターネットゲートウェイ設定 　2-5. セキュリティグループ設定 　2-6. インターフェイス設定 　2-7. ルートテーブル設定（MGMT・WAN用） 　2-8. ルートテーブル設定（LAN用） 　2-9. インスタンス起動 3. 接続確認 本記事は2025年10月23日時点での構築手順です。 内容については今後変更の可能性がありますこと、ご了承ください。 図例は一例としてご参考いただけますと幸いです。          Cato社が提供する最新版の構築手順は下記となりますので、ご参照ください。 https://support.catonetworks.com/hc/en-us/articles/4413273479825-Configuring-an-AWS-vSocket-Site 本記事と上記ナレッジベースの内容に差異がある場合、ナレッジベースの内容を優先してください。   1. Catoクラウド　vSocket Siteの設定 Catoクラウドの管理ポータルであるCMA（Cato Management Application)上でvSocketと紐づけるSiteの設定を行います。 1. CMAのメニューから、「 Network>Site 」をクリック 2.「 New 」をクリック   3. Add Siteウィンドウ設定をで各種設定を行い、「 Apply 」をクリックします。 • Site Name : ユニークなサイト名 • Site Type : 適切なものを選択 • Connection Type : vSocket AWSを選択 • Country : 使用する国を選択 • State : 使用する地域を選択 • Time Zone : 使用するタイムゾーンを選択 • License Type/Licence：利用可能なライセンスを選択 • Downstream ： 利用帯域に従って設定 • Upstream ： 利用帯域に従って設定 • Native Range : LANサブネットのIPレンジを設定 （今回は、10.10.3.0/24） • Local IP : 使用するLAN用ENIのIPアドレスを設定 （今回は、10.10.3.10) ※Licenseの選択で「Unassigned」のみの場合は利用可能なライセンスがない状況ですので、ご用意をお願いします。     4. 「 Network>Sites 」からAWS vSocket Siteの設定で作成したサイトをクリックします。 5. 「 Site Configuration>Socket 」をクリックし、シリアル番号(S/N)をコピーして控えておきます。 ※シリアル番号は、AWS上でvSocketを作成する際に使用します。 2. AWS設定 次に、AWS側の設定を行います。 設定手順内で明示している項目以外は、デフォルト値、もしくはご自身の環境に合わせた設定で問題ありません。 2-1. AWS設定-Elastic IPアドレス取得 MGMT用とWAN用のElastic IPアドレスの割り当てを行います。 1.AWS Management Consoleのホーム画面で「 VPC 」をクリックします。 2.左側のメニュー内の「 Elastic IP 」をクリックします。 3.「 Elastic IPアドレスを割り振る 」をクリックします。   4.パブリックIPv4アドレスプールという項目で、「 AmazonのIPv4アドレスプール 」を選択します。 5.「 割り振る 」をクリックします。 6.Elastic IPアドレスの設定画面で、作成したElastic IPアドレスの名前を変更します。 ※Nameにカーソルを合わせると編集アイコンが表示されます。判別しやすい名前への変更を推奨します。 7. １～６と同様の手順で WAN用 のElastic IPの割り当てを行います。   2-2. AWS設定-VPC作成 vpcを新規作成します。 ※既存のVPCがある場合、本項目は省略してください。 1. AWS Management Consoleのホーム画面で「 VPC 」をクリックします。 2. VPC Management Console画面で「 お使いのVPC 」をクリックします。 3.「 VPCを作成 」をクリックします。   4. VPCの設定を入力後、「 VPCを作成 」をクリックします。 • 作成するリソース : 「 VPCのみ 」を選択 • 名前タグ ： VPCの名前を入力 • IPv4 CIDRブロック : 「IPv4 CIDRの手動入力」を選択 • IPv4 CIDR : VPCのIPアドレス範囲を入力 • IPv6 CIDRブロック : 「IPv6 CIDRブロックなし」を選択 • テナンシー : デフォルト値のまま   2-3. AWS設定-サブネット設定 MGMT用のサブネットを作成します。 1. AWS Management Consoleのホーム画面で「 VPC 」をクリックします。 2. VPC Management Console画面で「 サブネット 」をクリックします。 3. 「 サブネットを作成 」をクリックします。 4. サブネットの設定を入力し、「 サブネットを作成 」をクリックします。 • VPC ID : 「2-2」で作成したVPCを選択 • サブネット名 ： 任意の名前を入力 • アベイラビリティゾーン : 適切なものを選択 • IPv４ CIDRブロック : MGMTサブネットのIPアドレス範囲を入力 ※アベイラビリティゾーンはMGMT・WAN・LANの3つのサブネットで同じである必要があります。   5. １～４と同様の手順で WAN用、LAN用サブネット の作成を行います。 ※IPv4 CIDRについて、WAN用はWANサブネットのIPアドレス範囲、LAN用はLANサブネットのIPアドレス範囲を入力してください。   2-4. AWS設定-インターネットゲートウェイ設定 インターネットゲートウェイを設定し、2-2で作成したVPCにアタッチします。 ※インターネットゲートウェイがすでにVPC内に存在する場合には、この手順は飛ばしてください。 1. AWS Management Consoleのホーム画面で「 VPC 」をクリックします。 2. VPC Management Console画面で「 インターネットゲートウェイ 」をクリックします。 3. 「 インターネットゲートウェイの作成 」をクリックします。   4. インターネットゲートウェイの設定後、「 インターネットゲートウェイの作成 」をクリックします。 • 名前タグ : 任意の名前を入力   5. 下図の画面に変わりましたら、「 アクション 」より「 VPCにアタッチ 」をクリックします。   6. アタッチするVPCを選択後、「 インターネットゲートウェイのアタッチ 」をクリックします。 • 使用可能なVPC : 2-2で作成したVPCを選択     2-5. AWSの設定-セキュリティグループの作成 後で作成する各ネットワークインターフェースに適用するセキュリティグループを作成します。 1. AWS Management Consoleのホーム画面で「 VPC 」をクリックします。 2. EC2 Management Console画面で「 セキュリティグループ 」をクリックします。 3. 「 セキュリティグループを作成 」をクリックします。   4. 希望するAWSセキュリティ要件に合わせて、 MGMT・WAN・LAN用のセキュリティグループ をそれぞれ作成します。 • セキュリティグループ名 : MGMT・WAN・LAN用とわかるもの • VPC : 2-2で作成したVPC          • インバウンドルール : MGMT・WAN用： インバウンド通信がないため、ルール不要 LAN用： vSocketと接続したいAWS環境内部のサーバセグメントからの通信を許可 • アウトバウンドルール : デフォルトのすべて許可で問題ありません。 厳しく制限を掛けたい場合は以下を参照してください。 MGMT・WAN用：TCP 443 / UDP 443 / UDP 53 / ICMP すべて宛先Any LAN用：AWS上のご自身のサーバの通信要件にあわせてご検討ください。   2-6. AWS設定-ネットワークインターフェイス設定 ネットワークインターフェイスの作成を行います。 ※MGMT・WAN用とLAN用で少し設定が異なりますのでご注意ください。 1. AWS Management Consoleのホーム画面で「 EC2 」を選択します。 2. EC2 Management Console画面で、「 ネットワークインターフェイス 」をクリックします。 3. 「 ネットワークインターフェイスの作成 」をクリックします。   4. ネットワークインターフェイスの設定を入力し、「 ネットワークインターフェイスを作成 」をクリックします。 • Description : 任意で入力 • サブネット ： MGMTのサブネット を選択 • インターフェイスのタイプ: ENA • プライベートIPｖ4アドレス : 固定の指定があれば「カスタム」、なければ「自動割り当て」を選択 • セキュリティグループ : MGMT用のもの を選択 5. インターフェイス作成後、Name欄が空欄ですので、 MGMT用のインターフェイス であることがわかる任意の名前を設定します。 6. WAN用、LAN用インターフェイス も同様の手順で作成します。   7. ElasticIPアドレス(グローバルIPアドレス)の関連付けを行います。 作成したMGMT用インターフェイスを右クリックし、「 アドレスの関連付け 」を選択します。 8. 先程取得したElasticIPを選択し、「 関連付ける 」をクリックします。 9. 同様に、 WAN用インターフェイス にもElasticIPを関連付けします。（ LAN用は不要 ）   10. 作成した LAN用のインターフェイス を右クリックし「 送信元/送信先チェックを変更 」をクリックします。 11. 「 送信元/送信先チェック 」を外し(無効にし)、保存をクリックします。 ※このチェックが有効だとルーティングできません。   2-7. AWS設定-ルートテーブルの設定(MGMT・WAN用） MGMTおよびWANサブネットで使用するルートテーブルの設定を行います。 ※MGMTとWANサブネットはルートテーブルを共用します。 1. AWS Management Consoleのホーム画面で「 VPC 」をクリックします。 2. VPC Management Console画面で「 ルートテーブル 」をクリックします。 3.「 ルートテーブルを作成 」からルートテーブルを新規作成します。 4. 設定項目を入力し「 ルートテーブルの作成 」をクリックします。 • 名称 : MGMTおよびWAN用とわかる名称 • VPC： 2-2で作成したもの   5. 作成したルートテーブルを右クリックし、「 ルートを編集 」を選択します。 6. 「 ルートを追加 」からルートを追加します。 7.   0.0.0.0/0 を 2-4で作成したインターネットゲートウェイ(IGW)に向けるようルートを追加し保存します。     8. ルートテーブル一覧に戻り、作成したルートテーブルを再度クリックします。 9. 下部にある「 サブネットの関連付け 」タブから、「 サブネットの関連付けを編集 」をクリックします。 10. MGMTとWANの2つのサブネットを選択 し、「 関連付けを保存 」をクリックします。   2-8. AWS設定-ルートテーブルの設定(LAN用） LANサブネットで使用するルートテーブルの設定を行います。 1. 2-7の１～４の手順でLAN用のルートテーブルを作成します。 2. 作成したルートテーブル画面の下部に表示される「 ルート 」タブを表示します。  3. 「 ルートを編集 」からルートを追加します。   4. 0.0.0.0/0 を、先ほど作成したLANインターフェイスのENIに向けるようルートを追加し保存します。 ※この時点ではルートがブラックホールになっていても問題ありません。   2-9. AWS設定‐インスタンスの起動 AMIからインスタンスの起動を行います。 1. AWS Management Consoleのホーム画面で「 EC2 」を選択します。 2. 「 インスタンスを起動 」をクリックします。   vSocketとなるインスタンスの設定を行います。 1. 「 名前 」は任意のものを入力します。 2. 「 インスタンス数 」は1を入力してください。 3. OSイメージの検索欄に「 Cato 」と入力しEnterを押すと、AMIの選択画面に推移します。 4. AMIの選択画面にて「 AWS Marketplace AMI 」を選択します。 5. CatoのAMIが表示されますので、「 選択 」をクリックします。   6. 確認画面が表示されますので、 Cato Networks Virtual Socket であることを確認の上、「 今すぐ購読 」をクリックします。   7. 「 インスタンスタイプ 」はデフォルトで「 c5.xlarge 」が選択されています。 ※Cato社推奨：通常はc5.xlarge、契約帯域が2Gpbs以上の場合はc5n.xlarge 8. 「 キーペア(ログイン) 」より、「 キーペア名 」をクリックします。 9. 既存のキーペアを選択するか、または「 新しいキーペアの作成 」をクリックしてキーペアの作成を行ってください。   10.「 ネットワーク設定 」から「 編集 」をクリックし、設定を行います。 • VPC : vSocketのVPCを選択 • サブネット : MGMT用サブネット を選択 ※他のサブネットを選択すると正しく起動しません • パブリックIP自動割り当て: 「無効化」を選択 • ファイアーウォール : 「既存のセキュリティグループを選択する」 • 共通のセキュリティグループ : 空欄にします 11.「高度なネットワーク設定」をクリックし詳細設定に進みます。 12. ネットワークインターフェイス1の「 ネットワークインターフェイス 」をプルダウンし、 MGMTインターフェイス を選択します。 13.「 ネットワークインターフェイスを追加 」をクリックします。 14.ネットワークインターフェイス2が表示されます。 15.「 ネットワークインターフェイス 」をプルダウンし、 WANインターフェイス を選択します。 ※この指定を誤るとvSocketが接続されません 16.「 サブネット 」の項目で赤文字のエラーが出る場合には、プルダウンし、一番上の「 選択 」を選んでください。 17.さらに「 ネットワークインターフェイスを追加 」をクリックします。 18.ネットワークインターフェイス3が表示されます。 19.「 ネットワークインターフェイス 」をプルダウンし、 LANインターフェイス を選択します。 ※この指定を誤るとvSocketが接続されません 20.「 サブネット 」の項目で赤文字のエラーが出る場合には、プルダウンし、一番上の「 選択 」を選んでください。 以上でネットワークインタフェースの設定は完了です。 ネットワークインターフェース１、２、３がMGMT、WAN、LANの順になっていることを確認し、次の設定に進みます。   21. 「 ストレージを設定 」で、以下のように設定します。 • サイズ : 16GiB • タイプ : gp2 22.「 高度な詳細 」をクリックします。 23.一番下までスクロールし、「 ユーザーデータ 」に１のSite設定で控えた vSocketのシリアル番号(S/N) を入力します。 ※明示している項目以外は、デフォルト値で問題ありません。   24. 設定内容を確認し、「 インスタンスを起動 」をクリックします。   接続確認 vSocketが起動すると、自動でのアップグレードが走り、その後接続状態となります。検証時は、1分ほどで接続が確認できましたが、念のため5～10分程度お待ち下さい。 CMAのSite画面で以下のように「 Connected 」と表示されれば接続成功です。 以上でvSocket構築から接続の確認までが一通り完了しました。 補足として、AWS環境内の内部セグメントに対し、Catoモバイルクライアントから接続を試してみましたので紹介いたします。   補足：AWS内部サーバへの接続確認 今回はvSocketを構築するための最低限の構成（MGMT・WAN・LAN）を作成しましたが、実際にはAWS環境内に既存のサーバセグメントがあると思います。 今回の検証でも 内部サーバーをたて、Catoモバイルクライアントから接続ができるか確認 してみました。 以下追加項目と全体の構成図です。 ＜追加項目＞ サブネット：cato-subnet-test（10.10.4.0/24） EC2インスタンス：cato-vsocket-test （10.10.4.42） ルートテーブル：宛先　0.0.0.0/0　　ターゲット　LAN側ENI ※ルートテーブルのあて先はCatoクラウドを経由したい通信を設定してください。   モバイルクライアントからCatoクラウドに接続した状態で、SSH接続を試したところ、 追加した内部サーバへの接続を確認できました。   注意点 上記の補足確認は、AWSでルーティングを設定するだけではモバイルクライアントの接続が確立されません。 CatoクラウドのSiteに対してもルーティングの設定 が必要です。(私はここの部分がうまくできず、すこし苦戦しました…） 1. CMA上の「 Network 」＞「 Networks 」＞「 New 」から、ルーティングの設定が行えます。 2. 以下の項目を設定し、「 Apply 」をクリックします。 •　Type：Routed •　IP Ranges：内部サーバセグメントのIPアドレス範囲 •　Gateway：LANサブネットの2つ目のIPアドレス（LANサブネットの範囲が10.10.3.0/24の場合、10.10.3.1) ※サブネット内の最初の４つと最後の１つのIPアドレスは以下のようにAWSに予約されています。 サブネット内の2つ目のアドレスがデフォルトゲートウェイに設定されています。 IPアドレス（例） 用途 .0 ネットワークアドレス .1 デフォルトゲートウェイ .2 DNSサーバー .3 予備 .255 ブロードキャストアドレス   おわりに 今回は、AWS環境でのvSocket構築手順について紹介しました。 本記事がこれから構築を始めようと考えている方々の一助になれば幸いです。 今後は、vSocketの冗長化などにもチャレンジしていきたいと考えています！ 最後まで見ていただきありがとうございました！

こんにちは、SCSKの谷です。 オンプレ、AWS、Azure、Google Cloudといったハイブリッドで利用する環境では、監視対象が増えツールも分散しがちです。 Mackerelのインテグレーションを使えば、AWS・Azure・Google Cloudの標準監視サービスからメトリックを取得し、Mackerel上で一元管理できるため、マルチクラウド及びハイブリッド環境の監視を効率化できます。 以前、AWSのインテグレーションを使った監視を試しましたが、今回はGoogle Cloudのインテグレーションを実際に設定してみました。 Mackerel で AWS のサーバーレスサービスを監視してみた – TechHarmony 今回の記事では、Google Cloudインテグレーションの設定方法と実際にMackerelの管理画面でどのように見えるのかをご紹介します。 ぜひ最後までご覧ください！ ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー 当部署では他にも記事を投稿していますので、よかったらご覧ください。 MackerelでSNMP監視を検証してみた – TechHarmony MackerelでAmazon Connectを監視してみた – TechHarmony ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー 監視対象について 今回監視対象としたのは、以下のサービスのリソースになります。 ・Compute Engine　　 仮想マシンを提供するIaaSサービスで、自由度の高いインフラ構築が可能 ・App Engine　　　　  アプリケーションを自動スケーリングするPaaSサービスで、                                   コードをデプロイするだけで運用できる ・Cloud SQL                フルマネージドなリレーショナルデータベースサービスで、                                    MySQLやPostgreSQLなどを簡単に利用可能 上記のサービスを選択した理由としては、2025年10月現在Mackerelでメトリックを収集することが可能なGoogle Cloudのサービスが上記3つのためです。 各サービスのリソースについては監視を実装するためにデプロイしており、最低限のスペックのものを使用しております。 MackerelでのGoogle Cloudインテグレーション設定手順 MackerelでGoogle Cloudのインテグレーションを利用して監視するための手順を説明していきます。 Mackerel上でGoogle Cloudのインテグレーションを設定するためには、事前にGoogle Cloud側で準備が必要となります。 内容としては同じですが、Google Cloud側の事前準備の方法として以下の2パターンがあります。 ・Cloud SDKを用いた連携方法 →Cloudshellを用いた方法。CLIを利用して設定するためGoogle Cloudに慣れている人におすすめです。 ・Google Consoleを用いた連携方法 →上記の通りGoogle Consoleを利用した方法です。GUIであるため分かりやすくGoogle Cloudに慣れていない人にもおすすめです。 私はGoogle Cloudを触るのが今回が初めてだったので、「Google Consoleを用いた連携方法」で事前準備を実施しました。 ここからは、Google Cloudの事前準備の手順の説明後、Mackerel上でのインテグレーション設定の登録方法を説明していきます。 Cloud APIの有効化（Google Cloud） まずはじめにMackerelにデータ連携するために必要なGoogle CloudのCloud APIを有効化します。 （１）Google Consoleへログインし、「APIライブラリ」に移動します。 （２）以下のCloud APIを有効化します（今回はすべて有効化しました） 必須 Cloud Resource Manager API   必須 Cloud Monitoring API   任意 Compute Engine API Compute Engineインスタンスの監視が必要な場合 任意 Cloud SQL Admin API Cloud SQLインスタンスの監視が必要な場合 任意 App Engine Admin API App Engineサービスの監視が必要な場合 サービスアカウント作成（Google Cloud） Mackerelがメトリックを取得するためのサービスアカウントを作成していきます。 （１）「IAMと管理＞サービスアカウント」を選択し、サービスアカウントの管理画面を開きます。 （２）上部にある「サービスアカウントを作成」を選択します。 （３）必要な上を入力し、サービスアカウントを作成します。 ・サービスアカウント名 ・サービスアカウントID ・サービスアカウントの説明（任意） （４）Mackerelがメトリック取得に必要なロールを付与します。 必須 参照者   必須 モニタリング閲覧者   任意 Compute 閲覧者 Compute Engineインスタンスの監視が必要な場合 任意 Cloud SQL 閲覧者 Cloud SQLインスタンスの監視が必要な場合 任意 App Engine 閲覧者 App Engineサービスの監視が必要な場合 （５）完了ボタンを押し、サービスアカウントの設定を完了する。 サービスアカウントキー発行（Google Cloud） MackerelとGoogle Cloud間の認証のためのキーを発行します。 （１）作成したサービスアカウントの管理画面を開きます。 （２）「鍵」のタブを開き、「キーの追加＞新しい鍵の作成」を選択します。 （３）キーのタイプとして「JSON」を選択し、「作成」ボタンをクリックします。 （４）作成後、秘密鍵のJSONファイルがローカルにダウンロードされます。 以上でGoogle Cloud側の設定が完了になります。ここからMackerel上でGoogle Cloudインテグレーションの設定をしていきます。 Google Cloudインテグレーション設定（Mackerel） 続いてMackerelの管理画面上でGoogle Cloudインテグレーション設定を登録していきます。 （１）Mackerelの管理画面に入り、Google Cloud インテグレーションタブを開きます。 （２）「新しいGoogle Cloudインテグレーション設定を登録」ボタンを選択します。 （３）プロジェクトの設定に連携対象のGoogle Cloudのプロジェクトコード及び先ほど作成したJSON形式の秘密鍵の中身をペーストします。 （４）メトリックを収集するサービスを選択し、作成ボタンをクリックします。 ※メトリック選択時に好きなサービス/ロールを紐づけることができます。 連携確認 以上でGoogle Cloudインテグレーションの設定は完了です。 Mackerel上でGoogle Cloudインテグレーションの設定直後の状態を見てみましょう。 ここまでの手順が完了すると、自動でMackerelにGoogle Cloud上のリソース情報が連携され管理画面の「ホスト」のところですぐに確認することができます。 以下の画像は今回Google Cloudで作成したリソースをMackerelの管理画面上のホスト一覧で表示したものです。 クラウドインテグレーションソートをすることにより、対象を絞っております。 今回作成したホストに対応するサービスは以下の通りです。 サービス名 ホスト名 App Engine 20251001t062902.default Compute Engine vm-demo-1 Cloud SQL pg-demo-1 Mackerel上での監視メトリック確認 初めてでしたが、設定作業はつまずくことなく設定することができました。 ここからは、Google Cloudから連携されたデータがMackerel上でどのように見えているかをサービスごとに載せていきます。 Mackerel上でのメトリック確認方法 Mackerelの管理画面から各ホストのメトリックデータのグラフを確認するためには、ホスト一覧から確認したい対象のホスト名をクリックすることで、メトリックデータ一覧の画面に遷移します。 メトリックデータ一覧の画面は以下のようになります。 Google Cloudから取得したホストの概要が載っております。画像では途切れていますが、初期状態ではMackerelの管理画面上で表示可能な全てのグラフが並んでおります。表示するグラフについては管理画面で調整可能です。 Compute Engine Mackerelでは様々なCompute Engineのメトリックを取得することが可能です。 MackerelからCompute Engineのリソースのメトリックを取得するには、「Compute Engine API」のAPIが有効化されている必要があります。 また、連携用のサービスアカウントに対して、「Compute 閲覧者」のロールを付与している必要がございます。 以下は代表的なメトリックになります。 グラフ名 メトリック 説明 CPU instance/cpu/utilization インスタンスのCPU使用率。負荷監視の基本指標。 Disk bytes instance/disk/read_bytes_count instance/disk/write_bytes_count ディスク読み込み量。I/O性能確認に重要。 ディスク書き込み量。ストレージ負荷の把握に利用。 Network bytes instance/network/received_bytes_count instance/network/sent_bytes_count ネットワークで受信したバイト数。トラフィック監視に使用。 ネットワークで送信したバイト数。外部通信の負荷確認に重要。 Firewall dropped packets count firewall/dropped_packets_count ファイアウォールでドロップされたパケット数。セキュリティ監視に重要。 Mackerelの画面で確認したところ合計11個のグラフが表示されていました。 今回はその中のCPUグラフをお見せします。 CPUの使用率を可視化したグラフとなっており単位は「％」です。今回16:25～16:35の時間帯にstressコマンドをVM上で実行し、CPUの使用率を意図的に上げ正しくメトリックが連携されているか確認しました。 App Engine MackerelからApp Engineのメトリックを取得するには、「App Engine Admin API」のAPIが有効化されている必要があります。 また、連携用のサービスアカウントに対して、「App Engine 閲覧者」のロールを付与している必要がございます。 理由が不明のため、偶々なのかもしれませんが、App Engineだけはインテグレーションを設定してからMackerelの管理画面のホスト上に表示されるまで他の2サービスと比べて時間がかかりました。（約20分くらい） 時間がたてば表示されメトリックが連携されていたので、連携されてこない場合でも30分程度待つことをおすすめします！ 以下は代表的なメトリックになります。 グラフ名 メトリック 説明 CPU Usage system/cpu/usage インスタンスのCPU使用量。負荷監視の基本指標。 Memory usage system/memory/usage メモリ使用量。リソース不足やスケーリング判断に重要。 HTTP DoS intercept http/server/dos_intercept_count DoS攻撃を検知・遮断した回数。セキュリティ監視に重要。 HTTP Response count http/server/response_count HTTPレスポンス数。アプリのリクエスト処理量を把握。 Mackerelの画面で確認したところ合計8個のグラフが表示されていました。 今回はこの中のHTTP Response countグラフをお見せします。 こちらのグラフはHTTPレスポンス数を可視化したグラフになります。 初期の状態だとApp Engine宛へのアクセスがなかったため、Google Cloudから取ってくるメトリックが存在せず、グラフが表示されない状態でした。12時頃に繰り返しアクセスすることにより、以下のようにグラフが表示され正しくメトリックが連携できていることを確認できました。 Cloud SQL MackerelからCloud SQLのメトリックを取得するには、「Cloud SQL Admin API」のAPIが有効化されている必要があります。 また、連携用のサービスアカウントに対して、「Cloud SQL 閲覧者」のロールを付与している必要がございます。 以下は代表的なメトリックになります。 使用するDB（MySQLやPostgerSQL）により取得可能なメトリックに違いがあり、 今回はPostgerSQLを使用したので、PostgerSQLのメトリックを記載しております。 グラフ名 メトリック 説明 CPU database/cpu/utilization データベースのCPU使用率。負荷監視の基本指標。 Memory database/memory/usage database/memory/quota  メモリ使用量と割り当て容量。リソース不足の検知に重要。 Connections database/network/connections データベース接続数。接続プールやスロット枯渇の検知に利用。 PostgreSQL transaction database/postgresql/transaction_count  PostgreSQLのトランザクション数。処理負荷の把握に利用。 Mackerelの画面で確認したところ合計10個のグラフが表示されていました。 今回はこの中のPostgreSQL transactionグラフをお見せします。 こちらのグラフはPostgreSQLのトランザクション数を可視化したグラフになります。   まとめ 今回、MackerelのGoogle Cloudインテグレーションを使って監視を設定してみましたが、手順は非常にシンプルで、他クラウドと同様に迷うことなく進められました。初めての方でも問題なく導入できると思いますので、より詳しい内容を知りたい方は、公式のヘルプを確認してみることをお勧めします。 Google Cloudインテグレーション – Mackerel ヘルプ 設定後、App Engineのリソースがホスト一覧に表示されず少し戸惑いましたが、事前に認識しておけば大丈夫です。 他のクラウドサービスと比べると、現状Mackerelで監視できるGoogle Cloudのサービスはまだ3つのみです。Google Cloudの強みは機械学習やAI系のサービスなので、そのようなサービスも監視できるようになればいいなと思います。便利な機能だからこそ、さらに対応サービスが増えることに期待です。今後のはてなさんの動きに注目してください！ 今後もMackerelに関する記事を投稿していきますので、よろしくお願いします！