挨拶 ども！こんにちは「デモ開発」が連続で続いていて、デッドヒートの波に乗っている龍ちゃんです。一件は完了しているので、記事の共有をしておきます。最近はサムネイルの作りに凝っています。： 「生成AI×LINE」で作るチャットゲーム ちょうど開発を進めていく中で、フロントエンドの開発効率を爆上げする方法を見つけたので、リハビリがてらさくっとブログにまとめていきたいと思います。 実際にこちらの内容を 利用したリポジトリはこちら になります。 本日の内容 フロントエンドで完結するモックの作りこみについてになります。APIの実装を待つよりも先にデータ構造からデザインを確認したいときに使うことができます。 フロントエンド開発時のモックについて モックといえば、モック用にアプリケーションを構築する方法もあります。今回は、フロントエンドでAPIのモックを作成する方法について紹介していきます。API通信ライブラリとしてはaxiosを対象としています。 ディレクトリ構成 今回は、API通信部分をapiというファイル内に処理をまとめておきます。各ファイルの構造としては、以下のようなイメージです。 api +---User # API名 +---api.ts # API通信処理 +---constants.ts # 返信用定数 +---type.ts # response request Type定義 apiディレクトリ内にAPIに対応したディレクトリを作成します。各APIディレクトリには、以下の3つのファイルから構成されています。 ファイル名 責務 api.ts REST APIの場合であればまとめておくことができる constant.ts ダミーの返信用定数を保存するファイル typs.ts レスポンス リクエストのタイプ定義 環境変数で、モックと本番環境との切り替え制御を行います。api.ts内で環境変数を呼び出して判定を行い、モックの場合は constat.ts からダミーのレスポンスを呼び出して返信します。 構築方法 まずは、環境編素を用意します。 # モック使用時はtrueとして、モックではない場合false VITE_MOCK="true" constants.ts と type.ts はそれぞれ対応する情報を適宜入れてください。 api.ts では定義した情報を利用して構築します。 import axios from "axios"; import { dummyFetchEnemyResponse, dummyPostBattleResponse } from "./constants"; import { RequestPostBattleType, ResponsePostBattleType } from "./type"; import { axiosClient } from "../axiosClient"; import { sleep } from "@utilities/utilitiesLogic"; export const postBattle = async (data: RequestPostBattleType) => { // 環境変数読み込み const mockFlag = import.meta.env.VITE_MOCK as boolean; // 環境変数によってはダミーを返答する if (mockFlag) { await sleep(2000); return dummyPostBattleResponse; } // API通信の処理 const response = await axios.post<ResponsePostBattleType>("/api/battle", data); return response.data; }; 上記のコードによってモックと本番環境を環境変数によって切り分けを行うことができます。API通信のラグを再現するために特定の秒数待機するプログラムを作成しています。 export const sleep = (ms: number) => new Promise((res) => setTimeout(res, ms)); これによって正常系のローディングを含む処理を再現することができます。 終わり さっくりとまとめ終わりました。こちらを利用することで、フロントエンドから型定義を作成することで「フロント→バック」の順番で作成することができます。 本来であれば、「バック→フロント」の順番でAPIのテストを行って開発するのがきれいです。でも、定義等をノリで作っていく場合はフロントから作り上げていく方が楽なんですよね。 というわけでおすすめしています！ではまた～ ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post フロントエンドで完結する簡易的なAPIモック作成について first appeared on SIOS Tech. Lab .

今回はPushgatewayを利用して、Prometheus serverから直接pullできないメトリクスを収集する方法をご紹介します。 なお、【メトリクス収集・監視】シリーズと題して他にも記事を投稿していきますので、併せてご確認ください。 Prometheus+Grafanaでメトリクスを監視する【メトリクス収集・監視】 Pushgatewayでメトリクスをプッシュする【メトリクス収集・監視】 　★本記事 Alertmanagerでアラートを通知する【メトリクス収集・監視】 Prometheusを冗長化構成（HA構成）にする方法と注意点【メトリクス収集・監視】 Pushgatewayとは ジョブ/バッチ実行など何らかの理由で生存期間の短いサーバーやアプリケーションに対して、プッシュ型のメトリクス収集を提供するコンポーネントです。 前述の生存期間の短いサーバーやアプリケーション自体がこのPushgatewayにメトリクス情報を送ることによりPushgatewayで一時的に保管が行われ、Prometheus serverがその情報の収集を行います。 目的 本記事では、任意の短命なアプリケーションからPushgatewayを介して、Prometheus serverにメトリクスを収集させる方法をご紹介します。 前提 下記の記事を参考に、Prometeus server、監視対象サーバー(Node exporter)、Grafanaが構築されていること。 Prometheus+Grafanaでメトリクスを監視する【メトリクス収集・監視】 環境 今回の構成図・検証環境サーバーは以下の通りです。 短命なアプリケーションの代わりとして、 vm-target1 から curl でメトリクスをプッシュします。 ・構成図 ※黄色背景が新たに構築するサーバー 用途 ホスト名 IPアドレス Grafanaサーバー vm-grafana1 172.24.1.5/24 Prometheusサーバー vm-prom1 172.24.1.9/24 短命アプリ vm-target1 172.24.1.10/24 Pushgateway vm-pushgw 172.24.1.10/24 上記サーバーのOS/SWは以下の通りです。 OS/SW バージョン OS Ubuntu 22.04 LTS Grafana grafana-enterprise 9.5.13 Prometheus 2.53.2 LTS Node exporter 1.8.2 Pushgateway 1.9.0 Pushgatewayの構築・動作確認 それではPushgatewayの構築を行っていきます。 ここでは特段記載のない限り vm-pushgw で操作を行います。 バイナリダウンロード・解凍 まず作業ディレクトリを作成して移動します。 # 作業ディレクトリ作成 sudo mkdir /work ; sudo chown azureuser:azureuser /work ; sudo chmod 777 /work # 移動・確認 cd /work ls -la 実行結果 azureuser@vm-pushgw:~$ sudo mkdir /work ; sudo chown azureuser:azureuser /work ; sudo chmod 777 /work azureuser@vm-pushgw:~$ azureuser@vm-pushgw:~$ cd /work azureuser@vm-pushgw:/work$ ls -la total 8 drwxrwxrwx 2 azureuser azureuser 4096 Sep 19 15:47 . drwxr-xr-x 20 root root 4096 Sep 19 15:47 .. azureuser@vm-pushgw:/work$ 次にPushgatewayのバイナリダウンロード、および、解凍をします。 # バージョン指定 VERSION = 1.9.0 # ダウンロード・確認 curl -sSOL https://github.com/prometheus/pushgateway/releases/download/v ${VERSION} /pushgateway- ${VERSION} .linux-amd64.tar.gz ls -la # 解凍・確認 tar xf pushgateway- ${VERSION} .linux-amd64.tar.gz ls -la # 解凍先ディレクトリへの移動・確認 cd pushgateway- ${VERSION} .linux-amd64/ ls -la 実行結果 azureuser@vm-pushgw:/work$ VERSION = 1.9.0 azureuser@vm-pushgw:/work$ curl -sSOL https://github.com/prometheus/pushgateway/releases/download/v ${VERSION} /pushgateway- ${VERSION} .linux-amd64.tar.gz azureuser@vm-pushgw:/work$ azureuser@vm-pushgw:/work$ ls -la total 10324 drwxrwxrwx 2 azureuser azureuser 4096 Sep 19 15:48 . drwxr-xr-x 20 root root 4096 Sep 19 15:47 .. -rw-rw-r-- 1 azureuser azureuser 10563386 Sep 19 15:48 pushgateway-1.9.0.linux-amd64.tar.gz azureuser@vm-pushgw:/work$ azureuser@vm-pushgw:/work$ tar xf pushgateway- ${VERSION} .linux-amd64.tar.gz azureuser@vm-pushgw:/work$ ls -la total 10328 drwxrwxrwx 3 azureuser azureuser 4096 Sep 19 15:49 . drwxr-xr-x 20 root root 4096 Sep 19 15:47 .. drwxr-xr-x 2 azureuser azureuser 4096 Jun 9 00:05 pushgateway-1.9.0.linux-amd64 -rw-rw-r-- 1 azureuser azureuser 10563386 Sep 19 15:48 pushgateway-1.9.0.linux-amd64.tar.gz azureuser@vm-pushgw:/work$ azureuser@vm-pushgw:/work$ cd pushgateway- ${VERSION} .linux-amd64/ azureuser@vm-pushgw:/work/pushgateway-1.9.0.linux-amd64$ ls -la total 18332 drwxr-xr-x 2 azureuser azureuser 4096 Jun 9 00:05 . drwxrwxrwx 3 azureuser azureuser 4096 Sep 19 15:49 .. -rw-r--r-- 1 azureuser azureuser 11357 Jun 9 00:05 LICENSE -rw-r--r-- 1 azureuser azureuser 487 Jun 9 00:05 NOTICE -rwxr-xr-x 1 azureuser azureuser 18745578 Jun 9 00:04 pushgateway azureuser@vm-pushgw:/work/pushgateway-1.9.0.linux-amd64$ Pushgatewayのインストール 今回はPushgatewayバイナリ実行用のユーザーを作成して実行することにします。 そのため、ユーザー作成と取得したバイナリを適切なディレクトリへ配置します。 まずはユーザー/グループ作成を行います。 # グループ追加 sudo groupadd prometheus # ユーザー追加・ホームディレクトリ確認 sudo useradd prometheus -g prometheus -d /var/lib/prometheus -s /usr/sbin/nologin -m sudo ls -la /var/lib/prometheus/ 実行結果 azureuser@vm-pushgw:/work/pushgateway-1.9.0.linux-amd64$ sudo groupadd prometheus azureuser@vm-pushgw:/work/pushgateway-1.9.0.linux-amd64$ azureuser@vm-pushgw:/work/pushgateway-1.9.0.linux-amd64$ sudo useradd prometheus -g prometheus -d /var/lib/prometheus -s /usr/sbin/nologin -m azureuser@vm-pushgw:/work/pushgateway-1.9.0.linux-amd64$ sudo ls -la /var/lib/prometheus/ total 20 drwxr-x--- 2 prometheus prometheus 4096 Sep 19 15:50 . drwxr-xr-x 41 root root 4096 Sep 19 15:50 .. -rw-r--r-- 1 prometheus prometheus 220 Jan 7 2022 .bash_logout -rw-r--r-- 1 prometheus prometheus 3771 Jan 7 2022 .bashrc -rw-r--r-- 1 prometheus prometheus 807 Jan 7 2022 .profile azureuser@vm-pushgw:/work/pushgateway-1.9.0.linux-amd64$ 次に取得したバイナリファイルを配置していきます。 # 実行バイナリの配置・確認 sudo cp pushgateway /usr/local/bin/ ls -la /usr/local/bin/pushgateway* 実行結果 azureuser@vm-pushgw:/work/pushgateway-1.9.0.linux-amd64$ sudo cp pushgateway /usr/local/bin/ azureuser@vm-pushgw:/work/pushgateway-1.9.0.linux-amd64$ ls -la /usr/local/bin/pushgateway* -rwxr-xr-x 1 root root 18745578 Sep 19 15:51 /usr/local/bin/pushgateway azureuser@vm-pushgw:/work/pushgateway-1.9.0.linux-amd64$ Pushgatewayのサービス化と起動確認 こちらはオプションとなりますが、今回は systemctl コマンドで管理できるよう、Unitファイルを作成してSystemdサービス化を行います。 # Unitファイル作成 cat << "EOF" | sudo tee /etc/systemd/system/prometheus-pushgateway.service [ Unit ] Description = Prometheus PushGateway Documentation = https://github.com/prometheus/pushgateway After = network-online.target [ Service ] User = prometheus WorkingDirectory = /var/lib/prometheus ExecStart = /usr/local/bin/pushgateway ExecStop = /bin/kill -TERM ${MAINPID} ExecReload = /bin/kill -HUP ${MAINPID} [ Install ] WantedBy = multi-user.target EOF 実行結果 azureuser@vm-pushgw:/work/pushgateway-1.9.0.linux-amd64$ cat << "EOF" | sudo tee /etc/systemd/system/prometheus-pushgateway.service [ Unit ] Description = Prometheus PushGateway Documentation = https://github.com/prometheus/pushgateway After = network-online.target [ Service ] User = prometheus WorkingDirectory = /var/lib/prometheus ExecStart = /usr/local/bin/pushgateway ExecStop = /bin/kill -TERM ${MAINPID} ExecReload = /bin/kill -HUP ${MAINPID} [ Install ] WantedBy = multi-user.target EOF [ Unit ] Description = Prometheus PushGateway Documentation = https://github.com/prometheus/pushgateway After = network-online.target [ Service ] User = prometheus WorkingDirectory = /var/lib/prometheus ExecStart = /usr/local/bin/pushgateway ExecStop = /bin/kill -TERM ${MAINPID} ExecReload = /bin/kill -HUP ${MAINPID} [ Install ] WantedBy = multi-user.target azureuser@vm-pushgw:/work/pushgateway-1.9.0.linux-amd64$ それでは正常に起動することを確認するため、サービス起動を行います。 # Unitファイルの反映・ステータス確認 sudo systemctl daemon-reload sudo systemctl status prometheus-pushgateway # サービス起動・ステータス確認 sudo systemctl start prometheus-pushgateway sudo systemctl status prometheus-pushgateway # サービスの自動起動有効化 sudo systemctl enable prometheus-pushgateway 実行結果 azureuser@vm-pushgw:/work/pushgateway-1.9.0.linux-amd64$ sudo systemctl daemon-reload azureuser@vm-pushgw:/work/pushgateway-1.9.0.linux-amd64$ sudo systemctl status prometheus-pushgateway ○ prometheus-pushgateway.service - Prometheus PushGateway Loaded: loaded ( /etc/systemd/system/prometheus-pushgateway.service ; disabled ; vendor preset: enabled ) Active: inactive ( dead ) Docs: https://github.com/prometheus/pushgateway azureuser@vm-pushgw:/work/pushgateway-1.9.0.linux-amd64$ azureuser@vm-pushgw:/work/pushgateway-1.9.0.linux-amd64$ sudo systemctl start prometheus-pushgateway azureuser@vm-pushgw:/work/pushgateway-1.9.0.linux-amd64$ sudo systemctl status prometheus-pushgateway ● prometheus-pushgateway.service - Prometheus PushGateway Loaded: loaded ( /etc/systemd/system/prometheus-pushgateway.service ; disabled ; vendor preset: enabled ) Active: active ( running ) since Thu 2024-09-19 15:53:17 JST ; 3s ago Docs: https://github.com/prometheus/pushgateway Main PID: 23328 ( pushgateway ) Tasks: 6 ( limit: 2263 ) Memory: 4.7M CPU: 6ms CGroup: /system.slice/prometheus-pushgateway.service └─23328 /usr/local/bin/pushgateway Sep 19 15:53:17 vm-pushgw systemd [ 1 ] : Started Prometheus PushGateway. Sep 19 15:53:17 vm-pushgw pushgateway [ 23328 ] : ts = 2024-09-19T06:53:17.910Z caller = main.go:87 level = info msg = "starting pushgateway" version = "(version=1.9.0, branch=HEAD, revision=d1ca1a6a426126a09a21f745e8ffbaba> Sep 19 15:53:17 vm-pushgw pushgateway[23328]: ts=2024-09-19T06:53:17.911Z caller=main.go:88 level=info build_context=" ( go = go1.22.4, platform = linux/amd64, user = root@2167597b1e9c, date = 20240608-15:04:08, tags = un > Sep 19 15:53:17 vm-pushgw pushgateway [ 23328 ] : ts = 2024-09-19T06:53:17.912Z caller = tls_config.go:313 level = info msg = "Listening on" address = [ :: ] :9091 Sep 19 15:53:17 vm-pushgw pushgateway [ 23328 ] : ts = 2024-09-19T06:53:17.912Z caller = tls_config.go:316 level = info msg = "TLS is disabled." http2 = false address = [ :: ] :9091 azureuser@vm-pushgw:/work/pushgateway-1.9.0.linux-amd64$ azureuser@vm-pushgw:/work/pushgateway-1.9.0.linux-amd64$ sudo systemctl enable prometheus-pushgateway Created symlink /etc/systemd/system/multi-user.target.wants/prometheus-pushgateway.service → /etc/systemd/system/prometheus-pushgateway.service. azureuser@vm-pushgw:/work/pushgateway-1.9.0.linux-amd64$ Pushgatewayへメトリクス情報のプッシュ・PushgatewayのWebUI確認 短命なアプリケーションからPushgatewayへメトリクス情報をプッシュする手段として、今回は簡易的に vm-target1 でcurlコマンドを実行して確認します。 vm-target1 でcurlコマンドを実行することでPushgatewayへPOST送信を行い、PushgatewayのWebUIでメトリクス情報を受信したことを確認します。 ここではPushgatewayのWebUI操作を除き、 vm-target1 で操作を行います。 PushgatewayのWebUIの事前確認 下記のURLでアクセスしWebUI画面が表示され、メトリクス情報が何も表示されていないことを確認します。 http://＜vm-pushgwのホスト名/IPアドレス＞:9091/ Pushgatewayへメトリクス情報のプッシュ ここではシンプルなメトリクスと複雑なメトリクスの2パターンのメトリクス情報をプッシュすることにします。 参考： pushgateway v1.9.0#command-line # シンプルなメトリクスのプッシュ echo "some_metric 3.14" | curl --data-binary @- http://vm-pushgw:9091/metrics/job/some_job # 複雑なメトリクスのプッシュ cat << EOF | curl --data-binary @- http://vm-pushgw:9091/metrics/job/some_job/instance/some_instance # TYPE some_metric counter some_metric2 { label = "val1" } 42 # TYPE another_metric gauge # HELP another_metric Just an example. another_metric 2398.283 EOF 実行結果 azureuser@vm-target1:~$ echo "some_metric 3.14" | curl --data-binary @- http://vm-pushgw:9091/metrics/job/some_job azureuser@vm-target1:~$ azureuser@vm-target1:~$ cat << EOF | curl --data-binary @- http://vm-pushgw:9091/metrics/job/some_job/instance/some_instance # TYPE some_metric counter some_metric2 { label = "val1" } 42 # TYPE another_metric gauge # HELP another_metric Just an example. another_metric 2398.283 EOF azureuser@vm-target1:~$ PushgatewayのWebUI確認 先ほどと同じく下記のURLでアクセスし、今度はメトリクス情報が2件表示されていることを確認します。 なお、この時点ではPushgatewayに一時保存されており、Prometheus serverにメトリクス収集されていないことにご留意ください。 http://＜vm-pushgwのホスト名/IPアドレス＞:9091/ Prometheus serverのメトリクス収集先にPushgatewayを追加 それではPushgatewayからメトリクスを収集するため、Prometheus serverに収集先を追加します。 そのため、ここでは vm-prom1 で操作を行います。 prometheus.ymlの変更 scrape_configs ブロックに新たに job_name ブロックを追加し、Pushgatewayである vm-pushgw の情報を下記の通り追記します。 - job_name: pushgw honor_labels: true static_configs: - targets: ['vm-pushgw:9091'] 追記後の内容確認 azureuser@vm-prom1:~$ tail -n 20 /etc/prometheus/prometheus.yml # Here it's Prometheus itself. scrape_configs: # The job name is added as a label `job=` to any timeseries scraped from this config. - job_name: "prometheus" # metrics_path defaults to '/metrics' # scheme defaults to 'http'. static_configs: - targets: [ "localhost:9090" ] - job_name: target01 static_configs: - targets: [ 'vm-target1:9100' ] - job_name: pushgw honor_labels: true static_configs: - targets: [ 'vm-pushgw:9091' ] azureuser@vm-prom1:~$ ユースケースによりますが、ここで注意する点として基本的に honor_labels: true を指定することが挙げられます。 この指定はプッシュ送信したラベルとPushgatewayが付与するラベルとで重複が発生した場合、 プッシュ送信したラベルを優先させる 指定です。 例えばinstanceラベルにはPushgateway自体を表す vm-pushgw:9091 ではなく、プッシュ送信した際に付与した値である some_instance を保持したい場合、 honor_labels: true を指定する必要があります。 Pushgatewayはメトリクス情報を中間で保持するサーバーに過ぎないため、ほとんどの場合、この例のようにはPushgatewayで付与されるラベルより、送信元（今回ではvm-target1からcurlで送信した内容）のラベルを優先することが望ましいでしょう。 参考： pushgateway v1.9.0#about-the-job-and-instance-labels prometheus.ymlの反映 変更内容を反映するためsystemctlでサービスを再起動します。 # サービス再起動・ステータス確認 sudo systemctl restart prometheus sudo systemctl status prometheus 実行結果 azureuser@vm-prom1:~$ sudo systemctl restart prometheus azureuser@vm-prom1:~$ sudo systemctl status prometheus ● prometheus.service - Prometheus Server Loaded: loaded ( /etc/systemd/system/prometheus.service ; enabled ; vendor preset: enabled ) Active: active ( running ) since Thu 2024-09-19 18:18:10 JST ; 3s ago Docs: https://prometheus.io/docs/introduction/overview/ Main PID: 2081 ( prometheus ) Tasks: 5 ( limit: 2260 ) Memory: 43.6M CPU: 150ms CGroup: /system.slice/prometheus.service └─2081 /usr/local/bin/prometheus --config.file = /etc/prometheus/prometheus.yml --web.console.templates = /etc/prometheus/consoles --web.console.libraries = /etc/prometheus/console_libraries Sep 19 18:18:10 vm-prom1 prometheus [ 2081 ] : ts = 2024-09-19T09:18:10.356Z caller = head.go:793 level = info component = tsdb msg = "WAL segment loaded" segment = 5 maxSegment = 6 Sep 19 18:18:10 vm-prom1 prometheus [ 2081 ] : ts = 2024-09-19T09:18:10.357Z caller = head.go:793 level = info component = tsdb msg = "WAL segment loaded" segment = 6 maxSegment = 6 Sep 19 18:18:10 vm-prom1 prometheus [ 2081 ] : ts = 2024-09-19T09:18:10.357Z caller = head.go:830 level = info component = tsdb msg = "WAL replay completed" checkpoint_replay_duration = 4.120173ms wal_replay_duration = 98.78385 > Sep 19 18:18:10 vm-prom1 prometheus [ 2081 ] : ts = 2024-09-19T09:18:10.360Z caller = main.go:1169 level = info fs_type = EXT4_SUPER_MAGIC Sep 19 18:18:10 vm-prom1 prometheus [ 2081 ] : ts = 2024-09-19T09:18:10.360Z caller = main.go:1172 level = info msg = "TSDB started" Sep 19 18:18:10 vm-prom1 prometheus [ 2081 ] : ts = 2024-09-19T09:18:10.360Z caller = main.go:1354 level = info msg = "Loading configuration file" filename = /etc/prometheus/prometheus.yml Sep 19 18:18:10 vm-prom1 prometheus [ 2081 ] : ts = 2024-09-19T09:18:10.366Z caller = main.go:1391 level = info msg = "updated GOGC" old = 100 new = 75 Sep 19 18:18:10 vm-prom1 prometheus [ 2081 ] : ts = 2024-09-19T09:18:10.366Z caller = main.go:1402 level = info msg = "Completed loading of configuration file" filename = /etc/prometheus/prometheus.yml totalDuration = 6.65351 > Sep 19 18:18:10 vm-prom1 prometheus [ 2081 ] : ts = 2024-09-19T09:18:10.367Z caller = main.go:1133 level = info msg = "Server is ready to receive web requests." Sep 19 18:18:10 vm-prom1 prometheus [ 2081 ] : ts = 2024-09-19T09:18:10.367Z caller = manager.go:164 level = info component = "rule manager" msg = "Starting rule manager..." azureuser@vm-prom1:~$ GrafanaでPushgatewayで収集したメトリクスを確認 前回の記事 で作成したデータソースに対し、 some_metric や some_metric2 、 another_metric メトリクスを指定してクエリすると、Pushgateway経由で収集されたメトリクスが表示されることを確認します。 Pushgateway利用時の注意点 最後にPushgateway利用時の注意点を挙げさせて頂きます。 Prometheus公式からアナウンスのある通り、Pushgatewayは限られた場合にのみ利用することが推奨されています。 公式HPから抜粋すると、 Pushgatewayは SPOF(単一障害点)とボトルネックになる可能性 がある NW構成の問題でPrometheus serverからpull出来ない場合、安易にPushgatewayを利用するのではなく、 NW構成または Prometheus serverの配置を見直すべき である 特定のマシン/インスタンスに 意味的に紐づかないバッチ/ジョブの結果を取得するために利用するには有用 である とある通り、非常に限定された状況下でのみ推奨されていることが分かります。 参考： Pushgatewayを使用すべきか？ 上記の通りPushgatewayの利用には注意が必要であるものの、 特定の状況下では有効なため、利用シーンを見極めながらご活用ください。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Pushgatewayでメトリクスをプッシュする【メトリクス収集・監視】 first appeared on SIOS Tech. Lab .

PS/SLの佐々木です。 9/14 – 9/15にNEMTUSさんが山形県で開催していた夏合宿に参加してきました。 NEMTUSさんとはNEM（ネム）」と「Symbol（シンボル）」技術の普及や発展を促進するNPO法人です。 弊社サイオステクノロジーとはOSCというイベントの出店でご一緒させていただくことがあり、NEMTUSさん自身も定期的にイベントを行っているということでしたので、今回イベントに参加させていただくことになりました。 NEMTUSさんHP 合宿について 今回の合宿は山形県のさくらんぼ東根駅が最寄りのあずまやさんという旅館で開催されていました。私自身人生初山形でした。 合宿では複数のコンテンツが用意されていました。 ブロックチェーンを利用したサービスを体験してみる ブロックチェーンにデータを読み書きしてみる 記念トークンの発行 QA ネットワーキング またこれら以外にも会議室を24時間借りていてくださったので合宿参加メンバーで夜までいろいろな話や情報交換といった交流をする時間がほかのイベントのと比べて圧倒的に多いのが合宿の特徴でした。 各コンテンツについて 続いて各コンテンツの中身を簡単に紹介します。 ブロックチェーンを利用したサービスを体験してみる ポイントカードを発行し、ポイントを付与するお店側とポイントを受け取るユーザーの体験をそれぞれしてみるというものでした。 Ethereumと異なる点として送付したポイント(トークン)を発行者が回収する機能があったり、トークンの有効期限を設定することができたりする点に違いがあるのかなと思いました。(Symbolの規格をちゃんと確認したわけではないので正確な情報ではないかもしれません、、) ブロックチェーンにデータを読み書きしてみる こちらは実際にコーディングを行うセッションでした。 SymbolブロックチェーンではEVM系のチェーンとは異なり、nodeが用意しているAPIをSDKを使用して使うことができるものとなっており、スマートコントラクトの開発が不要です。 そのためエンジニアは今まで通りのweb2のアプリケーションの開発に集中することができます。 またnodeも公開されているためEthereumのように自分でnodeを立ててネットワークに参加したり、node as a serviceのようなものを契約する必要がないためかなり手軽に開発を始めることができます。 Symbolではnodeを公開して自分のnodeでステーキングしてもらうとnodeを公開しているユーザーにインセンティブが入る仕組みのようです（Delegate PoS） これはEVMチェーンを使っていた私にはかなり驚きでしたが、開発者目線で開発にかかるコストや準備がかなり低減されるのでいい仕組みだなと思っていました。 node listは こちら から確認できます。 実際にSymbolブロックチェーンとSDKを用いてポイントを発行したり、付与したりするところをコーディングしてみたのですが、以下のような点は非常に良いと思いました。 Transactionの管理 AggregateTransactionを使用して100個のトランザクションを送った場合すべて成功したらcommit, 一つでも失敗したらロールバック Delegate PoS こちらは先ほど軽く触れましたが、開発者が手軽に動作検証をしたい場合には非常に良い仕組みだと思いました。 APIフレンドリーな設計 こちらも先ほど触れましたが、スマートコントラクト不要でブロックチェーン上で開発できる点です。SmartContractは監査をしたり、維持管理にまだ課題が多いですが、それを意識しないのは非常に大きいと思います。 モザイク機能 ERC20のようなトークンをSymbolではモザイクというみたいです。 トークンには様々な属性(有効期限やトークン所有者とトークン移動の権限を分けるなど)が存在しており、これらをスマートコントラクトなしで実現できるのは非常によい開発体験だと思いました。 事前に用意されているAPIしか使用できないという制約が気になってはいましたが、事前にAPIが提供されている範囲内で実装が可能な要件であればかなり高速に開発できるのに加え、なかなか自分で実装すると時間がかかるマルチシグやAggregateTransactionが手軽に利用できるという点はすごく良いと思いました。 またブロックチェーン上で何か処理をするというよりも、ブロックチェーンにデータを保存することで得られる恩恵(改ざん耐性やデータの永続性)のために使用したい場合はより手軽に利用できるSymbolとは相性が良いのかなと思いました。 参加してみて 今回NEMTUSさんの合宿に参加してみて今までキャッチアップできていなかったブロックチェーンのキャッチアップやネットワーキングで技術、市場のディスカッションや情報共有をすることができ非常に有意義で楽しい時間を過ごすことができました。 合宿なので普段のイベントではあまり深い話はできなかったりしますが、時間の制約がほとんどないような状況を作れるのは合宿の良さですね。 またQAセッションでSymbolを使用している事例で気になっているものがあったので質問し、丁寧に回答していただけたり、参加者も地元の方から関西の方まで幅広くいたので、関西の方のイベントの雰囲気やローカルな話などかなり深い話ができたことが非常に良かったと思います。 最後に 今回合宿を企画していくださったNEMTUSの皆様合宿でお会いさせてていただいた方にこの場を借りて感謝申し上げます。 最後に合宿の様子の写真を載せさせていただきます。   ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 1人がこの投稿は役に立ったと言っています。 The post NEMTUS夏合宿に参加してきました first appeared on SIOS Tech. Lab .

今回はPrometheusとGrafanaを使用してメトリクスを監視する方法をご紹介します。 なお、【メトリクス収集・監視】シリーズと題して他にも記事を投稿していきますので、併せてご確認ください。 Prometheus+Grafanaでメトリクスを監視する【メトリクス収集・監視】 　★本記事 Pushgatewayでメトリクスをプッシュする【メトリクス収集・監視】 Alertmanagerでアラートを通知する【メトリクス収集・監視】 Prometheusを冗長化構成（HA構成）にする方法と注意点【メトリクス収集・監視】 目的 本記事では、メトリクス収集・監視の入門編としてPrometheus serverの導入、監視対象サーバー（Node exporter）の導入、そしてそれらのメトリクスをGrafanaで表示するための方法をご紹介します。 環境 今回の構成図・検証環境サーバーは以下の通りです。 ・構成図 用途 ホスト名 IPアドレス Grafanaサーバー vm-grafana1 172.24.1.5/24 Prometheusサーバー vm-prom1 172.24.1.9/24 監視対象サーバー（Node exporter） vm-target1 172.24.1.10/24 上記サーバーのOS/SWは以下の通りです。 OS/SW バージョン OS Ubuntu 22.04 LTS Grafana grafana-enterprise 9.5.13 Prometheus 2.53.2 LTS Node exporter 1.8.2 Prometheusサーバーの構築・動作確認 それではPrometheusサーバーの構築を行っていきます。 ここでは特段記載のない限り vm-prom1 で操作を行います。 バイナリダウンロード・解凍 まず作業ディレクトリを作成して移動します。 # 作業ディレクトリ作成 sudo mkdir /work ; sudo chown azureuser:azureuser /work ; sudo chmod 777 /work # 移動・確認 cd /work ls -la 実行結果 azureuser@vm-prom1:~$ sudo mkdir /work ; sudo chown azureuser:azureuser /work ; sudo chmod 777 /work azureuser@vm-prom1:~$ azureuser@vm-prom1:~$ cd /work azureuser@vm-prom1:/work$ ls -la total 8 drwxrwxrwx 2 azureuser azureuser 4096 Sep 18 15:47 . drwxr-xr-x 20 root root 4096 Sep 18 15:47 .. azureuser@vm-prom1:/work$ 次にPrometheusサーバーのバイナリダウンロード、および、解凍をします。 # バージョン指定 VERSION = 2.53.2 # ダウンロード・確認 curl -sSOL https://github.com/prometheus/prometheus/releases/download/v ${VERSION} /prometheus- ${VERSION} .linux-amd64.tar.gz ls -la # 解凍・確認 tar xf prometheus- ${VERSION} .linux-amd64.tar.gz ls -la # 解凍先ディレクトリへの移動・確認 cd prometheus- ${VERSION} .linux-amd64/ ls -la 実行結果 azureuser@vm-prom1:/work$ VERSION = 2.53.2 azureuser@vm-prom1:/work$ curl -sSOL https://github.com/prometheus/prometheus/releases/download/v ${VERSION} /prometheus- ${VERSION} .linux-amd64.tar.gz azureuser@vm-prom1:/work$ ls -la total 101780 drwxrwxrwx 2 azureuser azureuser 4096 Sep 18 16:06 . drwxr-xr-x 20 root root 4096 Sep 18 15:47 .. -rw-rw-r-- 1 azureuser azureuser 104212702 Sep 18 16:06 prometheus-2.53.2.linux-amd64.tar.gz azureuser@vm-prom1:/work$ azureuser@vm-prom1:/work$ tar xf prometheus- ${VERSION} .linux-amd64.tar.gz azureuser@vm-prom1:/work$ ls -la total 101788 drwxrwxrwx 3 azureuser azureuser 4096 Sep 18 16:07 . drwxr-xr-x 20 root root 4096 Sep 18 15:47 .. drwxr-xr-x 4 azureuser azureuser 4096 Aug 10 00:16 prometheus-2.53.2.linux-amd64 -rw-rw-r-- 1 azureuser azureuser 104212702 Sep 18 16:06 prometheus-2.53.2.linux-amd64.tar.gz azureuser@vm-prom1:/work$ azureuser@vm-prom1:/work$ cd prometheus- ${VERSION} .linux-amd64/ azureuser@vm-prom1:/work/prometheus-2.53.2.linux-amd64$ ls -la total 261348 drwxr-xr-x 4 azureuser azureuser 4096 Aug 10 00:16 . drwxrwxrwx 3 azureuser azureuser 4096 Sep 18 16:07 .. -rw-r--r-- 1 azureuser azureuser 11357 Aug 10 00:13 LICENSE -rw-r--r-- 1 azureuser azureuser 3773 Aug 10 00:13 NOTICE drwxr-xr-x 2 azureuser azureuser 4096 Aug 10 00:13 console_libraries drwxr-xr-x 2 azureuser azureuser 4096 Aug 10 00:13 consoles -rwxr-xr-x 1 azureuser azureuser 137838575 Aug 9 23:56 prometheus -rw-r--r-- 1 azureuser azureuser 934 Aug 10 00:13 prometheus.yml -rwxr-xr-x 1 azureuser azureuser 129735160 Aug 9 23:56 promtool azureuser@vm-prom1:/work/prometheus-2.53.2.linux-amd64$ Prometheus serverのインストール 今回はPrometheusバイナリ実行用のユーザーを作成して実行することにします。 そのため、ユーザー作成と取得したバイナリを適切なディレクトリへ配置します。 まずはユーザー/グループ作成を行います。 # グループ追加 sudo groupadd prometheus # ユーザー追加・ホームディレクトリ確認 sudo useradd prometheus -g prometheus -d /var/lib/prometheus -s /usr/sbin/nologin -m sudo ls -la /var/lib/prometheus/ 実行結果 azureuser@vm-prom1:/work/prometheus-2.53.2.linux-amd64$ sudo groupadd prometheus azureuser@vm-prom1:/work/prometheus-2.53.2.linux-amd64$ azureuser@vm-prom1:/work/prometheus-2.53.2.linux-amd64$ sudo useradd prometheus -g prometheus -d /var/lib/prometheus -s /usr/sbin/nologin -m azureuser@vm-prom1:/work/prometheus-2.53.2.linux-amd64$ sudo ls -la /var/lib/prometheus/ total 20 drwxr-x--- 2 prometheus prometheus 4096 Sep 18 16:11 . drwxr-xr-x 41 root root 4096 Sep 18 16:11 .. -rw-r--r-- 1 prometheus prometheus 220 Jan 7 2022 .bash_logout -rw-r--r-- 1 prometheus prometheus 3771 Jan 7 2022 .bashrc -rw-r--r-- 1 prometheus prometheus 807 Jan 7 2022 .profile azureuser@vm-prom1:/work/prometheus-2.53.2.linux-amd64$ 次に取得したバイナリ/設定ファイルを配置していきます。 # 実行バイナリの配置・確認 sudo cp prometheus promtool /usr/local/bin/ ls -la /usr/local/bin/prom* # 設定ファイル、データ格納先ディレクトリ作成・確認 sudo mkdir -p /etc/prometheus /var/lib/prometheus/data sudo chown prometheus:prometheus /var/lib/prometheus/data sudo ls -la /etc/prometheus /var/lib/prometheus/data # 設定ファイルなどの配置・確認 sudo cp -r prometheus.yml consoles console_libraries /etc/prometheus/ ls -la /etc/prometheus/ 実行結果 azureuser@vm-prom1:/work/prometheus-2.53.2.linux-amd64$ sudo cp prometheus promtool /usr/local/bin/ azureuser@vm-prom1:/work/prometheus-2.53.2.linux-amd64$ ls -la /usr/local/bin/prom* -rwxr-xr-x 1 root root 137838575 Sep 18 16:16 /usr/local/bin/prometheus -rwxr-xr-x 1 root root 129735160 Sep 18 16:16 /usr/local/bin/promtool azureuser@vm-prom1:/work/prometheus-2.53.2.linux-amd64$ azureuser@vm-prom1:/work/prometheus-2.53.2.linux-amd64$ sudo mkdir -p /etc/prometheus /var/lib/prometheus/data azureuser@vm-prom1:/work/prometheus-2.53.2.linux-amd64$ sudo chown prometheus:prometheus /var/lib/prometheus/data azureuser@vm-prom1:/work/prometheus-2.53.2.linux-amd64$ sudo ls -la /etc/prometheus /var/lib/prometheus/data /etc/prometheus: total 8 drwxr-xr-x 2 root root 4096 Sep 18 16:16 . drwxr-xr-x 98 root root 4096 Sep 18 16:16 .. /var/lib/prometheus/data: total 8 drwxr-xr-x 2 prometheus prometheus 4096 Sep 18 16:16 . drwxr-x--- 3 prometheus prometheus 4096 Sep 18 16:16 .. azureuser@vm-prom1:/work/prometheus-2.53.2.linux-amd64$ azureuser@vm-prom1:/work/prometheus-2.53.2.linux-amd64$ sudo cp -r prometheus.yml consoles console_libraries /etc/prometheus/ azureuser@vm-prom1:/work/prometheus-2.53.2.linux-amd64$ ls -la /etc/prometheus/ total 20 drwxr-xr-x 4 root root 4096 Sep 18 16:16 . drwxr-xr-x 98 root root 4096 Sep 18 16:16 .. drwxr-xr-x 2 root root 4096 Sep 18 16:16 console_libraries drwxr-xr-x 2 root root 4096 Sep 18 16:16 consoles -rw-r--r-- 1 root root 934 Sep 18 16:16 prometheus.yml azureuser@vm-prom1:/work/prometheus-2.53.2.linux-amd64$ Prometheus serverのサービス化と起動確認 こちらはオプションとなりますが、今回は systemctl コマンドで管理できるよう、Unitファイルを作成してSystemdサービス化を行います。 # Unitファイル作成 cat << "EOF" | sudo tee /etc/systemd/system/prometheus.service [ Unit ] Description = Prometheus Server Documentation = https://prometheus.io/docs/introduction/overview/ After = network-online.target [ Service ] User = prometheus WorkingDirectory = /var/lib/prometheus ExecStart = /usr/local/bin/prometheus --config.file = /etc/prometheus/prometheus.yml --web.console.templates = /etc/prometheus/consoles --web.console.libraries = /etc/prometheus/console_libraries ExecStop = /bin/kill -TERM ${MAINPID} ExecReload = /bin/kill -HUP ${MAINPID} [ Install ] WantedBy = multi-user.target EOF 実行結果 azureuser@vm-prom1:/work/prometheus-2.53.2.linux-amd64$ cat << "EOF" | sudo tee /etc/systemd/system/prometheus.service [ Unit ] Description = Prometheus Server Documentation = https://prometheus.io/docs/introduction/overview/ After = network-online.target [ Service ] User = prometheus WorkingDirectory = /var/lib/prometheus ExecStart = /usr/local/bin/prometheus --config.file = /etc/prometheus/prometheus.yml --web.console.templates = /etc/prometheus/consoles --web.console.libraries = /etc/prometheus/console_libraries ExecStop = /bin/kill -TERM ${MAINPID} ExecReload = /bin/kill -HUP ${MAINPID} [ Install ] WantedBy = multi-user.target EOF [ Unit ] Description = Prometheus Server Documentation = https://prometheus.io/docs/introduction/overview/ After = network-online.target [ Service ] User = prometheus WorkingDirectory = /var/lib/prometheus ExecStart = /usr/local/bin/prometheus --config.file = /etc/prometheus/prometheus.yml --web.console.templates = /etc/prometheus/consoles --web.console.libraries = /etc/prometheus/console_libraries ExecStop = /bin/kill -TERM ${MAINPID} ExecReload = /bin/kill -HUP ${MAINPID} [ Install ] WantedBy = multi-user.target azureuser@vm-prom1:/work/prometheus-2.53.2.linux-amd64$ それでは正常に起動することを確認するため、サービス起動を行います。 # Unitファイルの反映・ステータス確認 sudo systemctl daemon-reload sudo systemctl status prometheus # サービス起動・ステータス確認 sudo systemctl start prometheus sudo systemctl status prometheus # サービスの自動起動有効化 sudo systemctl enable prometheus 実行結果 azureuser@vm-prom1:/work/prometheus-2.53.2.linux-amd64$ sudo systemctl daemon-reload azureuser@vm-prom1:/work/prometheus-2.53.2.linux-amd64$ sudo systemctl status prometheus ○ prometheus.service - Prometheus Server Loaded: loaded ( /etc/systemd/system/prometheus.service ; disabled ; vendor preset: enabled ) Active: inactive ( dead ) Docs: https://prometheus.io/docs/introduction/overview/ azureuser@vm-prom1:/work/prometheus-2.53.2.linux-amd64$ azureuser@vm-prom1:/work/prometheus-2.53.2.linux-amd64$ sudo systemctl start prometheus azureuser@vm-prom1:/work/prometheus-2.53.2.linux-amd64$ sudo systemctl status prometheus ● prometheus.service - Prometheus Server Loaded: loaded ( /etc/systemd/system/prometheus.service ; disabled ; vendor preset: enabled ) Active: active ( running ) since Wed 2024-09-18 16:22:53 JST ; 4s ago Docs: https://prometheus.io/docs/introduction/overview/ Main PID: 19221 ( prometheus ) Tasks: 6 ( limit: 2263 ) Memory: 17.1M CPU: 44ms CGroup: /system.slice/prometheus.service └─19221 /usr/local/bin/prometheus --config.file = /etc/prometheus/prometheus.yml --web.console.templates = /etc/prometheus/consoles --web.console.libraries = /etc/prometheus/console_libraries Sep 18 16:22:53 vm-prom1 prometheus [ 19221 ] : ts = 2024-09-18T07:22:53.497Z caller = tls_config.go:316 level = info component = web msg = "TLS is disabled." http2 = false address = [ :: ] :9090 Sep 18 16:22:53 vm-prom1 prometheus [ 19221 ] : ts = 2024-09-18T07:22:53.497Z caller = head.go:793 level = info component = tsdb msg = "WAL segment loaded" segment = 0 maxSegment = 0 Sep 18 16:22:53 vm-prom1 prometheus [ 19221 ] : ts = 2024-09-18T07:22:53.497Z caller = head.go:830 level = info component = tsdb msg = "WAL replay completed" checkpoint_replay_duration = 32.001µs wal_replay_duration = 1.479323m > Sep 18 16:22:53 vm-prom1 prometheus [ 19221 ] : ts = 2024-09-18T07:22:53.499Z caller = main.go:1169 level = info fs_type = EXT4_SUPER_MAGIC Sep 18 16:22:53 vm-prom1 prometheus [ 19221 ] : ts = 2024-09-18T07:22:53.499Z caller = main.go:1172 level = info msg = "TSDB started" Sep 18 16:22:53 vm-prom1 prometheus [ 19221 ] : ts = 2024-09-18T07:22:53.499Z caller = main.go:1354 level = info msg = "Loading configuration file" filename = /etc/prometheus/prometheus.yml Sep 18 16:22:53 vm-prom1 prometheus [ 19221 ] : ts = 2024-09-18T07:22:53.511Z caller = main.go:1391 level = info msg = "updated GOGC" old = 100 new = 75 Sep 18 16:22:53 vm-prom1 prometheus [ 19221 ] : ts = 2024-09-18T07:22:53.511Z caller = main.go:1402 level = info msg = "Completed loading of configuration file" filename = /etc/prometheus/prometheus.yml totalDuration = 12.228 > Sep 18 16:22:53 vm-prom1 prometheus [ 19221 ] : ts = 2024-09-18T07:22:53.511Z caller = main.go:1133 level = info msg = "Server is ready to receive web requests." Sep 18 16:22:53 vm-prom1 prometheus [ 19221 ] : ts = 2024-09-18T07:22:53.511Z caller = manager.go:164 level = info component = "rule manager" msg = "Starting rule manager..." azureuser@vm-prom1:/work/prometheus-2.53.2.linux-amd64$ azureuser@vm-prom1:/work/prometheus-2.53.2.linux-amd64$ sudo systemctl enable prometheus Created symlink /etc/systemd/system/multi-user.target.wants/prometheus.service → /etc/systemd/system/prometheus.service. azureuser@vm-prom1:/work/prometheus-2.53.2.linux-amd64$ Prometheus WebUIでの確認 PrometheusにはWebUI画面が用意されているため、ここではPrometheus server自身のメトリクスが収集されており、正常に表示されることを確認します。 prometheus.ymlの確認（自分自身が収集対象であることの確認） まずprometheus.ymlでPrometheus server自身がメトリクス収集対象になっていることを確認します。 azureuser@vm-prom1:/work/prometheus-2.53.2.linux-amd64$ tail -n 11 /etc/prometheus/prometheus.yml # A scrape configuration containing exactly one endpoint to scrape: # Here it's Prometheus itself. scrape_configs: # The job name is added as a label `job=` to any timeseries scraped from this config. - job_name: "prometheus" # metrics_path defaults to '/metrics' # scheme defaults to 'http'. static_configs: - targets: [ "localhost:9090" ] azureuser@vm-prom1:/work/prometheus-2.53.2.linux-amd64$ 上記の通りscrape_configsにジョブ定義があり、targets: [“localhost:9090”]となっていれば自分自身が収集対象となっています。 WebUIでの確認 下記のURLでアクセスしWebUI画面が表示されることを確認します。 http://＜vm-prom1のホスト名/IPアドレス＞:9090/ このWebUI画面ではPromQLでメトリクス情報を検索できるので、試しにprocess_cpu_seconds_totalでCPU使用率がグラフに表示されることを確認します。 なお、Prometheus serverは下記のURLを使用してメトリクスを収集しているため、ブラウザでアクセスすると取得メトリクスが表示されます。 http://＜vm-prom1のホスト名/IPアドレス＞:9090/metrics 監視対象サーバーの追加 このままではPrometheusサーバー自身の監視しか行っていませんので、監視対象サーバーを追加していきます。 具体的には監視対象サーバーに Node exporter を導入して監視します。 ここでは特段記載のない限り vm-target1 で操作を行います。 バイナリダウンロード・解凍 まず作業ディレクトリを作成して移動します。 # 作業ディレクトリ作成 sudo mkdir /work ; sudo chown azureuser:azureuser /work ; sudo chmod 777 /work # 移動・確認 cd /work ls -la azureuser@vm-target1:~$ sudo mkdir /work ; sudo chown azureuser:azureuser /work ; sudo chmod 777 /work azureuser@vm-target1:~$ azureuser@vm-target1:~$ cd /work azureuser@vm-target1:/work$ ls -la total 8 drwxrwxrwx 2 azureuser azureuser 4096 Sep 18 17:21 . drwxr-xr-x 20 root root 4096 Sep 18 17:21 .. azureuser@vm-target1:/work$ 次に Node exporter のバイナリダウンロード、および、解凍をします。 # バージョン指定 VERSION = 1.8.2 # ダウンロード・確認 curl -sSOL https://github.com/prometheus/node_exporter/releases/download/v ${VERSION} /node_exporter- ${VERSION} .linux-amd64.tar.gz ls -la # 解凍・確認 tar xf node_exporter- ${VERSION} .linux-amd64.tar.gz ls -la # 解凍先ディレクトリへの移動・確認 cd node_exporter- ${VERSION} .linux-amd64/ ls -la 実行結果 azureuser@vm-target1:/work$ VERSION = 1.8.2 azureuser@vm-target1:/work$ curl -sSOL https://github.com/prometheus/node_exporter/releases/download/v ${VERSION} /node_exporter- ${VERSION} .linux-amd64.tar.gz azureuser@vm-target1:/work$ azureuser@vm-target1:/work$ ls -la total 10436 drwxrwxrwx 2 azureuser azureuser 4096 Sep 18 17:23 . drwxr-xr-x 20 root root 4096 Sep 18 17:21 .. -rw-rw-r-- 1 azureuser azureuser 10676343 Sep 18 17:23 node_exporter-1.8.2.linux-amd64.tar.gz azureuser@vm-target1:/work$ azureuser@vm-target1:/work$ tar xf node_exporter- ${VERSION} .linux-amd64.tar.gz azureuser@vm-target1:/work$ ls -la total 10440 drwxrwxrwx 3 azureuser azureuser 4096 Sep 18 17:23 . drwxr-xr-x 20 root root 4096 Sep 18 17:21 .. drwxr-xr-x 2 azureuser azureuser 4096 Jul 14 20:58 node_exporter-1.8.2.linux-amd64 -rw-rw-r-- 1 azureuser azureuser 10676343 Sep 18 17:23 node_exporter-1.8.2.linux-amd64.tar.gz azureuser@vm-target1:/work$ azureuser@vm-target1:/work$ cd node_exporter- ${VERSION} .linux-amd64/ azureuser@vm-target1:/work/node_exporter-1.8.2.linux-amd64$ ls -la total 20048 drwxr-xr-x 2 azureuser azureuser 4096 Jul 14 20:58 . drwxrwxrwx 3 azureuser azureuser 4096 Sep 18 17:23 .. -rw-r--r-- 1 azureuser azureuser 11357 Jul 14 20:57 LICENSE -rw-r--r-- 1 azureuser azureuser 463 Jul 14 20:57 NOTICE -rwxr-xr-x 1 azureuser azureuser 20500541 Jul 14 20:54 node_exporter azureuser@vm-target1:/work/node_exporter-1.8.2.linux-amd64$ Node exporterのインストール Prometheus server 同様、バイナリ実行用のユーザーを作成して実行することにします。 そのため、ユーザー作成と取得したバイナリを適切なディレクトリへ配置します。 まずはユーザー/グループ作成を行います。 # グループ追加 sudo groupadd prometheus # ユーザー追加・ホームディレクトリ確認 sudo useradd prometheus -g prometheus -d /var/lib/prometheus -s /usr/sbin/nologin -m sudo ls -la /var/lib/prometheus/ 実行結果 azureuser@vm-target1:/work/node_exporter-1.8.2.linux-amd64$ sudo groupadd prometheus azureuser@vm-target1:/work/node_exporter-1.8.2.linux-amd64$ azureuser@vm-target1:/work/node_exporter-1.8.2.linux-amd64$ sudo useradd prometheus -g prometheus -d /var/lib/prometheus -s /usr/sbin/nologin -m azureuser@vm-target1:/work/node_exporter-1.8.2.linux-amd64$ sudo ls -la /var/lib/prometheus/ total 20 drwxr-x--- 2 prometheus prometheus 4096 Sep 18 17:25 . drwxr-xr-x 41 root root 4096 Sep 18 17:25 .. -rw-r--r-- 1 prometheus prometheus 220 Jan 7 2022 .bash_logout -rw-r--r-- 1 prometheus prometheus 3771 Jan 7 2022 .bashrc -rw-r--r-- 1 prometheus prometheus 807 Jan 7 2022 .profile azureuser@vm-target1:/work/node_exporter-1.8.2.linux-amd64$ 次に取得したバイナリを配置していきます。 # 実行バイナリの配置・確認 sudo cp node_exporter /usr/local/bin/ ls -la /usr/local/bin/node* 実行結果 azureuser@vm-target1:/work/node_exporter-1.8.2.linux-amd64$ sudo cp node_exporter /usr/local/bin/ azureuser@vm-target1:/work/node_exporter-1.8.2.linux-amd64$ ls -la /usr/local/bin/node* -rwxr-xr-x 1 root root 20500541 Sep 18 17:27 /usr/local/bin/node_exporter azureuser@vm-target1:/work/node_exporter-1.8.2.linux-amd64$ Node exporterのサービス化と起動確認 こちらはオプションとなりますが、今回は systemctl コマンドで管理できるよう、Unitファイルを作成してSystemdサービス化を行います。 # Unitファイル作成 cat << "EOF" | sudo tee /etc/systemd/system/prometheus-node-exporter.service [ Unit ] Description = Prometheus Node Exporter Documentation = https://github.com/prometheus/node_exporter After = network-online.target [ Service ] User = prometheus WorkingDirectory = /var/lib/prometheus ExecStart = /usr/local/bin/node_exporter ExecStop = /bin/kill -TERM ${MAINPID} ExecReload = /bin/kill -HUP ${MAINPID} [ Install ] WantedBy = multi-user.target EOF 実行結果 azureuser@vm-target1:/work/node_exporter-1.8.2.linux-amd64$ cat << "EOF" | sudo tee /etc/systemd/system/prometheus-node-exporter.service [ Unit ] Description = Prometheus Node Exporter Documentation = https://github.com/prometheus/node_exporter After = network-online.target [ Service ] User = prometheus WorkingDirectory = /var/lib/prometheus ExecStart = /usr/local/bin/node_exporter ExecStop = /bin/kill -TERM ${MAINPID} ExecReload = /bin/kill -HUP ${MAINPID} [ Install ] WantedBy = multi-user.target EOF [ Unit ] Description = Prometheus Node Exporter Documentation = https://github.com/prometheus/node_exporter After = network-online.target [ Service ] User = prometheus WorkingDirectory = /var/lib/prometheus ExecStart = /usr/local/bin/node_exporter ExecStop = /bin/kill -TERM ${MAINPID} ExecReload = /bin/kill -HUP ${MAINPID} [ Install ] WantedBy = multi-user.target azureuser@vm-target1:/work/node_exporter-1.8.2.linux-amd64$ それでは正常に起動することを確認するため、サービス起動を行います。 # Unitファイルの反映・ステータス確認 sudo systemctl daemon-reload sudo systemctl status prometheus-node-exporter # サービス起動・ステータス確認 sudo systemctl start prometheus-node-exporter sudo systemctl status prometheus-node-exporter # サービスの自動起動有効化 sudo systemctl enable prometheus-node-exporter 実行結果 azureuser@vm-target1:/work/node_exporter-1.8.2.linux-amd64$ sudo systemctl daemon-reload azureuser@vm-target1:/work/node_exporter-1.8.2.linux-amd64$ sudo systemctl status prometheus-node-exporter ○ prometheus-node-exporter.service - Prometheus Node Exporter Loaded: loaded ( /etc/systemd/system/prometheus-node-exporter.service ; disabled ; vendor preset: enabled ) Active: inactive ( dead ) Docs: https://github.com/prometheus/node_exporter azureuser@vm-target1:/work/node_exporter-1.8.2.linux-amd64$ azureuser@vm-target1:/work/node_exporter-1.8.2.linux-amd64$ sudo systemctl start prometheus-node-exporter azureuser@vm-target1:/work/node_exporter-1.8.2.linux-amd64$ sudo systemctl status prometheus-node-exporter ● prometheus-node-exporter.service - Prometheus Node Exporter Loaded: loaded ( /etc/systemd/system/prometheus-node-exporter.service ; disabled ; vendor preset: enabled ) Active: active ( running ) since Wed 2024-09-18 17:29:58 JST ; 3s ago Docs: https://github.com/prometheus/node_exporter Main PID: 20164 ( node_exporter ) Tasks: 3 ( limit: 2263 ) Memory: 4.6M CPU: 6ms CGroup: /system.slice/prometheus-node-exporter.service └─20164 /usr/local/bin/node_exporter Sep 18 17:29:58 vm-target1 node_exporter [ 20164 ] : ts = 2024-09-18T08:29:58.327Z caller = node_exporter.go:118 level = info collector = time Sep 18 17:29:58 vm-target1 node_exporter [ 20164 ] : ts = 2024-09-18T08:29:58.327Z caller = node_exporter.go:118 level = info collector = timex Sep 18 17:29:58 vm-target1 node_exporter [ 20164 ] : ts = 2024-09-18T08:29:58.327Z caller = node_exporter.go:118 level = info collector = udp_queues Sep 18 17:29:58 vm-target1 node_exporter [ 20164 ] : ts = 2024-09-18T08:29:58.328Z caller = node_exporter.go:118 level = info collector = uname Sep 18 17:29:58 vm-target1 node_exporter [ 20164 ] : ts = 2024-09-18T08:29:58.328Z caller = node_exporter.go:118 level = info collector = vmstat Sep 18 17:29:58 vm-target1 node_exporter [ 20164 ] : ts = 2024-09-18T08:29:58.328Z caller = node_exporter.go:118 level = info collector = watchdog Sep 18 17:29:58 vm-target1 node_exporter [ 20164 ] : ts = 2024-09-18T08:29:58.328Z caller = node_exporter.go:118 level = info collector = xfs Sep 18 17:29:58 vm-target1 node_exporter [ 20164 ] : ts = 2024-09-18T08:29:58.328Z caller = node_exporter.go:118 level = info collector = zfs Sep 18 17:29:58 vm-target1 node_exporter [ 20164 ] : ts = 2024-09-18T08:29:58.328Z caller = tls_config.go:313 level = info msg = "Listening on" address = [ :: ] :9100 Sep 18 17:29:58 vm-target1 node_exporter [ 20164 ] : ts = 2024-09-18T08:29:58.328Z caller = tls_config.go:316 level = info msg = "TLS is disabled." http2 = false address = [ :: ] :9100 azureuser@vm-target1:/work/node_exporter-1.8.2.linux-amd64$ azureuser@vm-target1:/work/node_exporter-1.8.2.linux-amd64$ sudo systemctl enable prometheus-node-exporter Created symlink /etc/systemd/system/multi-user.target.wants/prometheus-node-exporter.service → /etc/systemd/system/prometheus-node-exporter.service. azureuser@vm-target1:/work/node_exporter-1.8.2.linux-amd64$ Prometheus serverのメトリクス収集先の追加 監視対象サーバー vm-target1 に Node exporter を導入したため、 Prometheus server のメトリクス収集先に vm-target1 を追加します。 そのため、ここでは vm-prom1 で操作を行います。 prometheus.ymlの変更 scrape_configs ブロックに新たに job_name ブロックを追加し、新たなメトリクス収集先である vm-target1 の情報を下記の通り追記します。 - job_name: target01 static_configs: - targets: ['vm-target1:9100'] 追記後の内容確認 azureuser@vm-prom1:/work$ tail -n 20 /etc/prometheus/prometheus.yml rule_files: # - "first_rules.yml" # - "second_rules.yml" # A scrape configuration containing exactly one endpoint to scrape: # Here it's Prometheus itself. scrape_configs: # The job name is added as a label `job=` to any timeseries scraped from this config. - job_name: "prometheus" # metrics_path defaults to '/metrics' # scheme defaults to 'http'. static_configs: - targets: [ "localhost:9090" ] - job_name: target01 static_configs: - targets: [ 'vm-target1:9100' ] azureuser@vm-prom1:/work$ prometheus.ymlの反映 変更内容を反映するためsystemctlでサービスを再起動します。 # サービス再起動・ステータス確認 sudo systemctl restart prometheus sudo systemctl status prometheus 実行結果 azureuser@vm-prom1:/work$ sudo systemctl restart prometheus azureuser@vm-prom1:/work$ sudo systemctl status prometheus ● prometheus.service - Prometheus Server Loaded: loaded ( /etc/systemd/system/prometheus.service ; enabled ; vendor preset: enabled ) Active: active ( running ) since Wed 2024-09-18 17:44:29 JST ; 5s ago Docs: https://prometheus.io/docs/introduction/overview/ Main PID: 19459 ( prometheus ) Tasks: 5 ( limit: 2263 ) Memory: 27.5M CPU: 70ms CGroup: /system.slice/prometheus.service └─19459 /usr/local/bin/prometheus --config.file = /etc/prometheus/prometheus.yml --web.console.templates = /etc/prometheus/consoles --web.console.libraries = /etc/prometheus/console_libraries Sep 18 17:44:29 vm-prom1 prometheus [ 19459 ] : ts = 2024-09-18T08:44:29.975Z caller = head.go:793 level = info component = tsdb msg = "WAL segment loaded" segment = 0 maxSegment = 1 Sep 18 17:44:29 vm-prom1 prometheus [ 19459 ] : ts = 2024-09-18T08:44:29.976Z caller = head.go:793 level = info component = tsdb msg = "WAL segment loaded" segment = 1 maxSegment = 1 Sep 18 17:44:29 vm-prom1 prometheus [ 19459 ] : ts = 2024-09-18T08:44:29.976Z caller = head.go:830 level = info component = tsdb msg = "WAL replay completed" checkpoint_replay_duration = 47.201µs wal_replay_duration = 29.824796 > Sep 18 17:44:29 vm-prom1 prometheus [ 19459 ] : ts = 2024-09-18T08:44:29.978Z caller = main.go:1169 level = info fs_type = EXT4_SUPER_MAGIC Sep 18 17:44:29 vm-prom1 prometheus [ 19459 ] : ts = 2024-09-18T08:44:29.978Z caller = main.go:1172 level = info msg = "TSDB started" Sep 18 17:44:29 vm-prom1 prometheus [ 19459 ] : ts = 2024-09-18T08:44:29.978Z caller = main.go:1354 level = info msg = "Loading configuration file" filename = /etc/prometheus/prometheus.yml Sep 18 17:44:30 vm-prom1 prometheus [ 19459 ] : ts = 2024-09-18T08:44:30.003Z caller = main.go:1391 level = info msg = "updated GOGC" old = 100 new = 75 Sep 18 17:44:30 vm-prom1 prometheus [ 19459 ] : ts = 2024-09-18T08:44:30.004Z caller = main.go:1402 level = info msg = "Completed loading of configuration file" filename = /etc/prometheus/prometheus.yml totalDuration = 25.263 > Sep 18 17:44:30 vm-prom1 prometheus [ 19459 ] : ts = 2024-09-18T08:44:30.004Z caller = main.go:1133 level = info msg = "Server is ready to receive web requests." Sep 18 17:44:30 vm-prom1 prometheus [ 19459 ] : ts = 2024-09-18T08:44:30.004Z caller = manager.go:164 level = info component = "rule manager" msg = "Starting rule manager..." azureuser@vm-prom1:/work$ Prometheus WebUIでの確認 ここでは新しく追加した Node exporter を導入した vm-target1 のメトリクス収集が行われていることを、 Prometheus server のWebUI画面にて確認します。 WebUIでの確認 下記のURLでアクセスし、PromQLのprocess_cpu_seconds_totalでCPU使用率をグラフに表示します。 http://＜vm-prom1のホスト名/IPアドレス＞:9090/ そうすると、 Node exporter を導入した vm-target1 のメトリクスも収集・表示されていることが分かります。 なお、Prometheus serverと同様に、Node exporterを導入したサーバーでは下記のURLを公開しており、それにPrometheus serverがアクセスしてメトリクスを収集しているため、下記URLをブラウザでアクセスすると取得メトリクスが表示されます。 http://＜vm-target1のホスト名/IPアドレス＞:9100/metrics Grafanaの構築・メトリクス表示 それでは、いよいよGrafanaでメトリクス表示していきます。 Grafanaの構築 Grafanaのインストールについては、簡易ではありますが以前書いたブログをご参照ください。 Grafana利用DBをSQLiteからPostgreSQLに変更する【Grafana運用管理】#Grafanaの構築 Grafanaでメトリクス表示 Prometheusデータソースの作成 下記の通り、Prometheusデータソースの設定を行い、 Save & test で正常に保存されることを確認してください。 Name：任意の名前を付けてください。 HTTP > URL：http://＜vm-prom1のホスト名/IPアドレス＞:9090　　 ダッシュボード作成・メトリクス表示 下記の通り、先ほど作成したデータソースを対象にダッシュボードを作成してメトリクスが表示されることを確認します。（ここでは今までと同じprocess_cpu_seconds_totalを表示します。） 終わりに いまやメトリクス収集・監視といえばPrometheusがデファクトスタンダードと言っても過言ではないですが、 本番運用、特に冗長化やHA構成にする場合は色々と考慮点が必要になってきます。 今後、GrafanaファミリーのMimirと絡めて、その辺りもご紹介できればと思います。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Prometheus+Grafanaでメトリクスを監視する【メトリクス収集・監視】 first appeared on SIOS Tech. Lab .

こんにちは！ 今月も「OSSのサポートエンジニアが気になった！OSSの最新ニュース」をお届けします。 Linux Foundation は、Linuxシステム管理に必要なスキルとプロセスを学習するオンラインコース「Linux System Administration Essentials (LFS207)」の日本語版「Linuxシステム管理基礎 (LFS207-JP)」の提供を開始しました。 Linuxシステム管理トレーニングをリニューアル「Linuxシステム管理基礎」提供開始 https://prtimes.jp/main/html/rd/p/000000296.000042042.html 2024/9/11、Adobe Acrobat Reader における脆弱性に関する情報 (APSB24-70) が公開されました。 攻撃者による悪意のある PDF を開くと、任意のコードが実行される可能性があります。 Adobe AcrobatおよびReaderの脆弱性（APSB24-70）に関する注意喚起 https://www.jpcert.or.jp/at/2024/at240018.html Linux 財団は、分散型エコシステム向けのオープンソースを統括する組織として「リナックス財団分散型信頼（LFDT）」を設立しました。 リナックス、ヘデラと100人以上のメンバーで分散型財団を設立 https://jp.cointelegraph.com/news/linux-foundation-decentralized-trust-hedera-hyperledger ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 【2024年9月】OSSサポートエンジニアが気になった！OSS最新ニュース first appeared on SIOS Tech. Lab .

今回は、 パッケージマネージャ について解説します！ パッケージマネージャとは パッケージマネージャとは、システムにインストールされているソフトウェア (パッケージ) を リポジトリ と呼ばれるオンラインデータベース上で管理するためのツールです。 パッケージマネージャの主な目的はソフトウェアのインストール、アップグレード、削除を行うことですが、中でも パッケージの依存関係を自動的に解決してくれる ところがメリットと言えます。 代表的なパッケージマネージャは、Red Hat 系システムだと yum と dnf 、Debian 系システムだと apt があります。 今号では Red Hat 系の yum 、 dnf についてご紹介します。 yum と dnf の違いは？ Red Hat 系システムでは yum と dnf、2つのコマンドが用意されています。 yum は以前から使用されていたコマンドであり、多くの Linux ユーザにとって馴染み深いコマンドです。それに対して dnf は yum の後継として開発され、様々な改善が取り入れられています。 細かな違いとしては、それぞれ下記の通りとなっています。 yum は Python2 に基づいて、dnf は Python3 に基づいて開発されている yum は定期的に不要なキャッシュを手動でクリアする必要があるが、dnf は自動的にクリアする機能が実装されている dnf は実装の改善により、パフォーマンスが向上している なお、Fedora22 (RHEL8 系) 以降では標準のパッケージマネージャが yum から dnf に変更されています。yum と dnf では、サブコマンドやオプションも同じものが使用可能であるため、yum を使い慣れたユーザでも dnf に移行しやすい設計になっています。 基本の操作方法 (検索、インストール、アップデート、削除) yum、dnf コマンドの基本操作 (パッケージの検索、インストール、アップデート、削除) について、それぞれ説明します。 なお、上にも記載の通りサブコマンドやオプションは同じとなるため、dnf コマンドの実行例のみ掲載しています。 検索 特定のパッケージを検索するには、 dnf search コマンドを実行します。 例えば、git というパッケージを検索する場合は、下記の様なコマンドになります。 # dnf search git … ============================================== Name Exactly Matched: git =============================================== git.x86_64 : Fast Version Control System ============================================= Name & Summary Matched: git ============================================== git-all.noarch : Meta-package to pull in all git tools git-clang-format.i686 : Integration of clang-format for git … (長いため省略) … ================================================== Name Matched: git =================================================== kacst-digital-fonts.noarch : Fonts for arabic from arabeyes project ================================================= Summary Matched: git ================================================= LibRaw.x86_64 : Library for reading RAW files obtained from digital photo cameras LibRaw.i686 : Library for reading RAW files obtained from digital photo cameras … この時、結果には git という文字列を含むパッケージすべてと、要約 (説明文) が表示されます。 yum コマンドの場合は、下記の様になります。 # yum search git インストール パッケージをインストールするには、 dnf install コマンドを実行します。 例えば、git というパッケージをインストールする場合は、下記の様なコマンドになります。 # dnf install git … ======================================================================================================================== Package Architecture Version Repository Size ======================================================================================================================== Installing: git x86_64 2.43.5-1.el8_10 rhel-8-appstream-rhui-rpms 92 k Installing dependencies: emacs-filesystem noarch 1:26.1-11.el8 rhel-8-baseos-rhui-rpms 70 k git-core x86_64 2.43.5-1.el8_10 rhel-8-appstream-rhui-rpms 11 M git-core-doc noarch 2.43.5-1.el8_10 rhel-8-appstream-rhui-rpms 3.1 M perl-Error noarch 1:0.17025-2.el8 rhel-8-appstream-rhui-rpms 46 k perl-Git noarch 2.43.5-1.el8_10 rhel-8-appstream-rhui-rpms 79 k perl-TermReadKey x86_64 2.37-7.el8 rhel-8-appstream-rhui-rpms 40 k Transaction Summary ======================================================================================================================== Install 7 Packages Total download size: 14 M Installed size: 46 M Is this ok [y/N]: この時、指定したパッケージのみではなく git と依存関係があるパッケージも併せてインストールされます。 なお、上記の様にインストールを開始する前に Is this ok [y/N]: の文字列が表示され、インストールを続行するかを聞かれます。 y を押下するとインストール続行、N (もしくは n) を押下するとインストールを中止 します。 yum コマンドの場合は、下記の様になります。 # yum install git アップデート パッケージをアップデートするには、 dnf update コマンドを実行します。 例えば、既にインストール済みの git というパッケージをアップデートする場合は、下記の様なコマンドになります。 # dnf update git … ======================================================================================================================== Package Architecture Version Repository Size ======================================================================================================================== Upgrading: git x86_64 2.43.5-1.el8_10 rhel-8-appstream-rhui-rpms 92 k git-core x86_64 2.43.5-1.el8_10 rhel-8-appstream-rhui-rpms 11 M git-core-doc noarch 2.43.5-1.el8_10 rhel-8-appstream-rhui-rpms 3.1 M perl-Git noarch 2.43.5-1.el8_10 rhel-8-appstream-rhui-rpms 79 k Transaction Summary ======================================================================================================================== Upgrade 4 Packages Total download size: 14 M Is this ok [y/N]: yum コマンドの場合は、下記の様になります。 # yum update git 削除 パッケージをシステム上から削除するには、 dnf remove コマンドを実行します。 例えば、既にインストール済みの git というパッケージを削除する場合は、下記の様なコマンドになります。 # dnf remove git … ======================================================================================================================== Package Architecture Version Repository Size ======================================================================================================================== Removing: git x86_64 2.27.0-1.el8 @rhel-8-appstream-rhui-rpms 368 k Removing unused dependencies: emacs-filesystem noarch 1:26.1-11.el8 @rhel-8-baseos-rhui-rpms 0 git-core x86_64 2.27.0-1.el8 @rhel-8-appstream-rhui-rpms 32 M git-core-doc noarch 2.27.0-1.el8 @rhel-8-appstream-rhui-rpms 12 M perl-Error noarch 1:0.17025-2.el8 @rhel-8-appstream-rhui-rpms 70 k perl-Git noarch 2.27.0-1.el8 @rhel-8-appstream-rhui-rpms 63 k perl-TermReadKey x86_64 2.37-7.el8 @rhel-8-appstream-rhui-rpms 65 k Transaction Summary ======================================================================================================================== Remove 7 Packages Freed space: 45 M Is this ok [y/N]: yum コマンドの場合は、下記の様になります。 # yum remove git yum、dnf コマンドについての補足事項 dnf (yum) install コマンド実行時に対象パッケージが既にインストール済みである場合はアップデートが実行され、反対に dnf (yum) update コマンド実行時に対象パッケージがインストールされていない場合はインストールが実行されます。 パッケージ名の後ろに バージョン指定がない場合は、リポジトリ内での最新バージョンがインストールまたはアップデートされます。 明示的にインストール・アップデート先のバージョンを指定したい場合は パッケージ名の後にバージョンを指定 (例：dnf install git-2.27.0-1.el8 など) します。 -y オプション (例： dnf install -y など) を付けると、 Is this ok [y/N]: が表示されず直ちに処理が開始されます。ただし、 依存関係があるパッケージなどが事前に確認できなかったり、意図しないパッケージのインストール、アップデート、削除が行われる可能性があるので、利用は推奨しません。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 知っておくとちょっと便利！パッケージマネージャについて1 ～Red Hat 系システム編～ first appeared on SIOS Tech. Lab .

始めに ども！今月はデモづくりに追われている龍ちゃんです。先日、学生さん数名とお話する機会があったのですが、自分が学生の時よりもはるかに能動的な学生に圧倒されてしまいました。いや～素晴らしいですね。そんな学生さんのためにも大急ぎでブログを執筆しておきます。 もし、間違いを見つけたらSNSでもメールでも問い合わせください 単純に疑問の場合でも遠慮なく問い合わせしてもらって大丈夫ですよ”(-“”-)” さて、今回は「生成AI×LINE」で遊べるゲームを作ったので、その報告と軽めの説明を垂れ流していこうと思います。 LINE内のブラウザで立ち上げて遊ぶゲームとなっています。アプリのうっすいところから実装で苦労した部分など、実現するにあたっての道のりを記載していこうと思います。 「生成AI×LINE」で作るチャットゲーム アプリの構想は、「持ち運びしやすいデモ」から始まりました。デモを魅せに行くにあたって必要なものとしては、説明資料とQRコードになります。友達に送るのであれば共有もしやすいので、一石二鳥か三鳥ぐらいありそうです。 ゲームコンセプト ゲームのコンセプトとしては、ユーザーが作成したキャラクターと事前に用意したキャラクターでの「プロンプト戦闘」になります。生成AIを根幹に組み込んでいるエンタメアプリケーションとなっています。 対戦キャラクターは事前に生成しておき、ユーザーの入力をトリガーにして「審判プロンプト」によって勝敗が決します。 アーキテクト・使用技術 やはりデプロイしないと共有って難しいですよね。なるべく早くlocalhostから抜け出すと世界が広がります。 アーキテクト 今回作成したアプリケーションの設計はAzure寄せたシンプルな構成になっています。 それぞれのデプロイ先としては以下のような内訳となっています。 名称 リンク フロントエンド Azure Static Web Apps バックエンド Azure Web Apps データベース Firebase Firestore AIサービス Azure OpenAI Service 理想的には、ログも含めてAzure上に寄せたかったのですがデータベース周りは高いのでさくっと使えるFirestoreを使用しています。 認証にはLIFFアプリの認証を使用しています。こちらを利用することで、LINE内のブラウザから立ち上げれば、LINEのアカウント情報での認証が完了した状態でアクセスすることができます。 大変な認証処理をフロントのみで完結することができる！ 「Azure OpenAI Service 」では、GPT-4oとGPT-3.5-Turboのモデルをそれぞれ利用しています。なぜ？二つのモデルを利用しているのかについては「プロンプト」で触れています。 使用技術 フロントエンドとしては、以下のライブラリを使用しています。 ライブラリ名 説明 React もう素のHTMLを書くのなんて信じられない React-Hook-Form フォームを作成のため axios ブラウザからのhttpリクエスト用 SWR データfetch用 再取得やローディング中の表現が楽 @line/liff JSでLIFFアプリを作成するために必要 Tailwind CSSのフレームワーク CSSを各効率が爆上がりします lottie アニメーションを簡単に表示してくれる 主要なものを上げています。開発効率のためにESlintやPrettierなどのコード成型用ライブラリを入れています。開発環境の構築にはViteを使用しています。 バックエンドとしては、フレームワーク：nest.jsを使用して構築しています。追加で入れたライブラリとしては、以下の用の内容になります。 ライブラリ名 説明 firebase-admin firebaseにアクセスしてデータの入出力に使用 openai Azure OpenAI Serviceにアクセスするためのライブラリ 主に外部のサービスにアクセスするのを助けてくれるライブラリを導入しています。nest.jsは環境構築をした際に、開発に必要なコード成型は入っている状態なのですぐ開発を始めることができます。 バックエンドの環境は、データベースにFireStoreを採用するまでの名残でDockerで構築しており、ローカル開発環境はDevContainerを使用して作成しています。 フロントエンドとバックエンドに共通しているのは、どちらもGitHub ActionsでCI/CDを実装している点です。どちらも簡易ですが、mainリポジトリに変更をpushすることで自動でビルドが走り。それぞれの環境にデプロイが処理されます。 プロンプト さて、今回の成果物の根幹にかかわる部分の解説に移っていきます。今回作成したプロンプトとしては、「審判プロンプト」と「JSON整形プロンプト」の2つになります。 審判プロンプト モデルベースとしては、「Gpt-4o」を利用しています。 こちらのプロンプトが目標としているのは、主に以下の2つになります。 ユーザーとAI側のキャラクターの勝敗を判定する 戦闘の記録をダイナミックに脚色する 事前入力としては「AI側のキャラクター情報」を与えます。また、ここでJSON形式のひな形を作成します。返答としては、脚色された情報とJSONのような文字列が返答されます。 JSONの返答例を与えることで、JSON形式の返答率は上がります。ですが、GPT-4oはJSONでの出力を守ってくれないという悪癖があります。なので、ここでは文字列の情報としてJSON情報を受け取ります。 プロンプトの全文です。 あなたは決闘の審判です。二つのキャラクターの戦闘を見守り、勝敗までの流れを判定してください。 AI側がチャンピオン、ユーザー側が挑戦者です。 次の内容は必ず守ってください「チャンピオンのキャラクターが勝利した場合はsystem、挑戦者が勝利した場合はuserと明記してください。」 --- ${enemyPrompt} --- 以下のType出力を守った内容を最後に付録として記載してください。 --- { "combatLogs": { "round":number, "combatLog":string }[] } --- 例は以下のようになります。combatLogは小説家のように過大に脚色して演出してください。決闘の勝者を明確にしてください。 --- { "combatLogs": [ { "round": 1, "combatLog": "訓練場の教官が鉄の剣で攻撃しました" }, { "round": 2, "combatLog": "訓練場の教官が鉄の盾で防御しました" } ] } --- JSON整形プロンプト モデルベースとしては、「GPT-3,5-Turbo」を利用しています。 こちらのプロンプトが目標としているのは、「APIのレスポンスとして返すためのJSON作成」になります。 入力としては、「審判プロンプト」で作成された結果を入力します。また、文章中から勝者を判定してJSONの形式に出力を制限しています。 プロンプトの全文です。 - 出力をJSON形式にしてフォーマットとしては以下のサンプルに従ってください。 - 以下の形式のJSON以外は出力しないでください。 - AI側がチャンピオン、ユーザー側が挑戦者です。 - winnerには挑戦者が買った場合は「user」、チャンピオン側が買った場合は「system」を入力してください。 - winnerには「user」か「system」しか入力しないでください。 { "winner":"user"|"system", "combatLogs": { "round":number, "combatLog":string }[] } なぜ二つのプロンプトを併用しているのか？ これは、文章中にも触れましたが「Gpt-4o」がJSON形式の返答を得意としていないという悪癖のせいです。参考情報としては、こちらを参考にしてもらえればと思います。 2024-08-02 AOAI：Gpt-4oでJSON出力に失敗する対症療法 新規の情報作成ではなく、「入力値から特定のフォーマットに変換する」というシンプルなタスクを「GPT-3.5-Turbo」にお任せすることで「GPT-4o」の不得意な部分をカバーしています。 実装 具体的な実装内容については、ある程度ソースが読める方はそれぞれのリポジトリ進んでいただいて読んでもらえる方が手っ取り早いかもしれません。フロントエンド・バックエンドのそれぞれのリポジトリを置いておきます。 名称 リンク フロントエンド https://github.com/Ryunosuke-Tanaka-sti/2024-line-liff-app-frontend バックエンド https://github.com/Ryunosuke-Tanaka-sti/2024-line-liff-app-backend 仕様書はREADMEに記載しようかと考えています。頑張ってメンテナンスします。 ここでは、実装面に気を付けていたことについて列挙していきます。 LIFFアプリを作成することで気を付ける点 こちらの記事でまとめています。 nest.jsでLIFFアプリのトークンをセキュアに運用する フロント側でユーザー情報を取得することができます。ですが、 バックエンドにその情報をそのまま送付することは禁止されています 。そのため、フロントエンドではアクセストークンをヘッダーに埋め込んで、バックエンド側でそれを検証することでユーザー情報を取得しています。 プロンプトで処理しやすいように分割する こちらは、プロンプトのテクニックのお話になります。今回は「ストーリー作成」と「返答用JSON作成」の2つで分割しました。こちらに関してもテクニックの1つになります。 「審判プロンプト」と「JSON整形プロンプト」で登場するJSONの型は絶妙に違います。これは、「審判プロンプト」内で直接JSONを作成するよりも、生成された文章から勝者を類推するほうが精度が高かったからです。 このようにプロンプトフレンドリーに処理を分割することは結構苦労しました。 フロントを作ってからバックを作る 急に開発の話ですが、本来なら「バックエンドのAPIを作って、テストしてからフロントの画面を作っていく」が正しい順番だと思います。今回は、時間がなかった＋開発者独りだったのでフロントを書きながら表示に必要な情報の構築を合わせてしていました。 詳しくは、別記事で書きますが環境変数で「MOCK」というフラグを立てた時は、定数を返答するようにコードを作成することで開発工程を3つほどスキップすることができました。 おわり ども！お疲れ様です。久しぶりの執筆と開発で結構疲れがありますが、ここ数週間は充実した日々でしたね。やはり定期的に新しいものを作る必要があります。 この記事でカバーできていない部分などは全然質問に答えますので気軽に問い合わせしてください。執筆者情報のところにXのリンクが張ってあります。 次作るデモはロボット動かします！お楽しみに～ ではまた！ なぜプラットフォームにLINEを使用しているのか？ しれっとLINEを使う方向で話を進めていますが、このアプリがLINEを使用して進めているかについて触れていこうと思います。LINEを採用している理由としては、以下の三つの理由があります。 直感的操作がレベチ！ LINE内で遷移することなく認証ができる 持ち運べるデモって便利なんです 直感的操作がレベチ！ 広く使われているアプリでもあるので、皆さん特段説明する必要なく操作をすることができるかと思います。（使ってるユーザーはね！）スムーズにデモに入ることができます。これは、強みです。 LINE内で遷移することなく認証ができる ゲームを作る上で、スコアは重要な指標になると思ってます。こちらを実装するためには、必ず個人を特定（ユーザー登録）する必要があります。よく使う認証はGoogle認証なんですけど、デモのためにGoogleでのログインってハードルが高くないですか？ということもあって特に遷移することなく、認証を作ることができるというのも強みです。 持ち運べるデモって便利なんです！ いろんな理由を並べたんですけども、デモを持っていくにあたって一番うれしいのがここです。デモを披露するにあたって必要なのが、友達登録用のQRだけなので説明する資料とQRを持っていけば、あとは身一つでデモを魅せることができます。まぁ認証が必要なければ、サイトでも同じことができるんですけどね。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post LINE×生成AI：チャットバトルゲームを作る！ first appeared on SIOS Tech. Lab .

日本工学院八王子専門学校 ITスペシャリスト科 AI・システム専攻 3年生。 高山尚也と申します。 私は普段、PCゲーム(最近のおすすめはRustedMossとZedzone)で遊んだり、 Javaを使ってMinecraftのMod制作などをしています。 サイオステクノロジー株式会社では社員の技術力向上を大事にしており、その一環として情報発信などのアウトプットを推進しているそうです。 そのため、今回はサイオスへインターンに行ってみたということで、その内容について紹介していきます。 サイオスをインターン先に選んだ理由について きっかけは学校でインターン先を推薦されたことです。 そこで募集内容を確認したところ、以下のような内容でした。 アプリを企画から開発までフルスタックに制作する 何名かのインターン生とともにチームを組む 期間は３週間で、週5日 ほぼリモート作業(出社は週1) これが私には魅力的でした。 私はこれまでインターンに1回行っており、そちらでは主に業務体験を行い、すでに用意されたアプリに対して作業を行っていました。 一方のサイオスでは1からアプリを制作するということで、今までにない経験ができると考えました。 というわけで募集に応募し、インターンに参加させていただきました。 実際にインターンに行ってみて、良かったなと思ったことは以下の通りです。 アウトプット講座など、社員の皆様の貴重なお話を聞けたこと Azureを使ってWebアプリを作成し、様々な学びが得られたこと ひとつひとつ見ていきましょう！ インターンで印象に残った話 インターン中はアウトプット講座やMTGへの参加、懇談会などで、社員の皆様からお話を聞く機会が多くありました。 その中で特に印象に残ったアウトプット講座について、ピックアップして語っていきたいと思います。 こちらはサイオス社員のMicrosoft MVPである武井さんに開いていただいた講座です。 Microsoft MVP(Most Valuable Professional)とは何かというと、Microsoftの製品について深い知識を持ち、そしてその知識を広める活動をする人を表彰する制度のことです。 つまりMicrosoftの製品に詳しく、さらにそれを広めている方ということですね。 こちらの講座では、アウトプットの重要性を説くような内容でした。 そのポイントとして、以下の点が挙げられます。 アウトプットはそれを読む人だけでなく、書いている自分にも役に立つ 書いた内容を忘れてしまったとき、自分にとってそれらが最良の辞書になる 人に教えることは記憶の定着に強く効果がある 以上のように、アウトプットにはとても良い効果があります。 学習する際、得てしてインプットが多くなってしまいやすいですが、実際にはインプットとアウトプットの割合は3:7で行った方が良いそうです。 これらを過去の自分に照らしてみると、学んだのに忘れてしまったり、学んだつもりでもしっかりと理解していないことがあるなと考えました。 今後は何かしらに書いてみることや、ブログなんかを始めてみようかな？と、そのように思えるような講座でした。 Azureを使ったWebアプリ制作 Webアプリ制作では私含め2名でチームを組み、「ITインターンウィザード」というアプリを制作しました。 ITインターンウィザードはChatBot形式のWebアプリケーションで、目的はITインターンに関する悩みを解決することです。 余談ですが、名前に付いている”ウィザード”という単語には、2つの意味が込められています。 一つはゲームなどでよく登場する”魔法使い”という意味の英単語です。 もう一つはソフトウェアのインストール時などによく実行される、対話型のコンピュータプログラムのことです。(インターネット接続ウィザードなど) また、このChatBotのことを魔法使いと見立てている、という見方もできますね。 話が逸れましたが、本題に戻りましょう。 こちらのアプリはAzureのクラウド上にデプロイされており、Azureの以下のサービスを利用しました。 App Service Functions Azure OpenAI AI Search RAGという技術を仕様しており、情報ソース(今回は 魔法のスプレッドシート2024 を利用させていただきました)から情報を検索し、それをもとに回答することで正確性や有用性を高めています。 Azureは少ししか触ったことがなく、RAGに関しても初めて知りましたが、サンプル作成から段階を踏んで学習を行いました。 開発の流れとしては資料などをもとに制作を始め、詰まった部分は社員の方に相談し、レビューなどもしていただきながら制作を進めました。 アプリを1から作るにあたり、企画書や要件定義書、テスト仕様書なども制作しました。 それぞれの書類の目的を意識し、そのための書き方を学ぶことができました。 またチーム開発ですので、タスク管理やスケジュール管理なども学ぶことができました。 自分ひとりではないため、ほかの人から見て自分の作業がどの程度進んでいるかが分かるようになど、気を付けるべき点が多くありました。 また、制作スケジュールは余裕を持たせておりましたが、実際は半日程度遅れが出ることもあり、作業量の予測の難しさを実感しました。 こうして振り返ってみると、大変多くの学びがありましたね。 総括 まとめです。以上のように、サイオスへインターンに行ってみて、大変多くの学びを得ることができました。 またほぼリモートである点も良かったです。移動時間がないため疲労が少なく、インターンに集中することができました。 実際に働くなら出社した方が集中できると考えていましたが、今回の体験でフルリモートもありだなと思うようになりました。 ここでは書いておりませんが、懇談会では就職についてのアドバイスなどを受けるなど、社員の方々には大変良くしていただきました。 これらの体験は、今後間違いなく就職などで役立つだろうと感じています。 最後に、このブログ記事を書いていく中で、今回のインターンで得た学びを再確認することができました。 まさにアウトプットの効果ですね。学んだことのアウトプットを習慣として取り入れていきたいと思います。 以上でブログ記事を終わります。 お読みいただきありがとうございました。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post サイオスへインターンに行ってみた first appeared on SIOS Tech. Lab .

はじめまして、日本工学院八王子専門学校ITスペシャリスト科の長島翔梧です。今回はサイオステクノロジー株式会社さんの夏のインターンシップに行ってきて、学んだことや起きたことなどを記事にしようと思います。 主にやったことは、 AzureのOpenAI APIを呼び出してみよう RAGを構築してみよう 上二つをもとにオリジナルアプリを作ってみよう その他(実業務体験や懇談会etc…) です。これらについて取り上げようと思います。 1.AzureのOpenAI APIを呼び出してみよう AzureのOpenAI APIをNode.jsから呼び出すWebアプリを試作してみました。Azureは去年AWSの授業で「なんか時間余ったし、ちょっと触ってみるかー」みたいなノリでしかやってなかったので、正直ちゃんとできるか不安ではありました。 Expressでサーバーを立ち上げ、Node.jsからAzureリソースを呼び出すという仕組みです。以下の記事を参考にして作成しました ・Azureリソースの作成 Chapter 04とChapter 06 URL ・Azure OpenAIライブラリの利用 URL 試作するOpenAIの呼び出しWebアプリは以下の画像のような感じです。         同じくインターン生の高山君に少しアドバイスをもらいながら何とか完成。どのようにAzureリソースを呼び出すかはここで理解しました。 最後に、完成したアプリをAzure App Serviceにデプロイさせました。デプロイの仕方は以下のサイトを参考にしてます。 ・VSCodeでAzure Web Appの作成とデプロイをする URL このとき、.gitignoreファイルや.envファイルの使い方について学んだのが印象的です。こういったことは、授業では習わなかったので、とても大事なことを知れたと思います。 2.RAGを組み込んでみよう 次はRAGを組み込んでアプリを拡張していきます。 そもそもRAGとは？ Retrieval-Augmented Generation (RAG) は、 大規模言語モデル(LLM)によるテキスト生成に、外部情報の検索を組み合わせることで、回答精度を向上させる技術のことです。 このRAGを使って今度は以下の画像のようなシステムを試作しました。 ユーザーがWebアプリに質問を入力 ↓ Azure Functionsが受け取る ↓ Azure AI Searchで質問に近しい回答部分を算出 ↓ Azure AI Searchに送った質問と算出された近しい回答部分をAzure Functionsが受け取る ↓ 次にAzure OpenAI APIで回答を生成 ↓ 結果をWebアプリに送信する といった流れになっています。 以下の記事を参考にしました。 ・RAGハンズオンセミナー資料 – README.mdのAzrueリソースの作成 URL ・ Azure Functions ローカル開発 URL ・Azure Functions のデプロイ URL ・関数アプリの作成 URL なんかうまくデプロイできていなかったり、Azureリソースの設定やソースコードを間違えたりでなんやかんや苦戦しましたが、こちらも何とか完成させることができました。 が、 「 じゃぁこれからオリジナルアプリを作っていくぞー！」ってところで、大問題が発生しました… 3.上二つをもとにオリジナルアプリを作ってみよう RAGとAzureリソースの呼び出しの仕方を学んだところでいよいよオリジナルアプリを作る段階になりました。作るアプリは「ITインターンウィザード」。IT系インターンシップをチャットボット形式で検索できるWebアプリケーションです。これをいざ二人で作ろうと思った矢先、とんでもないことが起きました。 なんと私、 コロナにかかりました… 家族がコロナになってしまい、そのまま流れるように感染しました。(インターン期間中にコロナになるとか勘弁して欲しい……弟許すまじ) 9/3(火)の朝からあまり体調が良くなく、「熱はないし、喉痛いだけだからまぁ大丈夫っしょ」とか思って調子乗っていたら、午後になるにつれて体中が熱くなり段々フラフラするようになって、ついには38度オーバーの熱をたたき出していました。これは流石に午後のインターンはキツイなと思い、午後からお休み…。ただ、なぜか翌日は37.4度と意外にも熱は低く、「今日病院で検査して薬もらえば明日から復帰できそう！」とちょっと一人で舞い上がっていました。がしかし、そんな都合のいい話ではありませんでした。 翌日、38.9度。。。 「オワタ」。。。。 普通にしんどかったです。まさかここまで綺麗に熱がぶり返すとは思いませんでした。しかも38、39度オーバーの熱は土曜日まで続き、結局この週は月曜日と火曜の午前しか参加することが出来ず、インターンのほぼ1/3を寝たきりで過ごす羽目になりました。 そして、ようやく熱が下がり、後遺症だけが残ったまま最終週を迎え、インターンに復帰したころには、なんとバックエンド側が殆ど出来上がっていたではありませんか(；　；) 仕方がないとはいえ、せっかくのインターンが……と、かなりショックを受けました。 僕がやったことは、残っていたUIの作成でした。CSSでデザインしたくらいです。ちょうど学校の個人制作課題でたくさんCSSを触っていた時期でしたので、かなり楽勝でした。めっちゃ簡単でした。少しだけ、スクリプトを書いたぐらいでなにも苦戦することはありませんでした。 コロナで欠席続きで迷惑もかけちゃって…本当に申し訳なくてしょうがなかったです…。 救いだったのは、サイオスの皆様と一緒にインターンをしていた高山君がとても優しくしてくれたことです。感謝しかありません。 ってなわけで、オリジナルアプリをほとんど作ったのは高山君なので、オリジナルアプリについて知りたい方は高山君の記事を見ることを推奨します。おそらく書いてくれるんじゃないかなって勝手に思ってます。 4.その他(実業務体験や懇談会etc…) アプリ制作以外にもたくさんのことを学ばせてもらい、体験させてもらいました。 主にやったこととしては チームミーティングの参加 月次報告会の参加 SL合同朝会の参加 若手社員さんとの懇談会 MVP武井さん講座 実業務体験 です。 が、実業務体験は、コロナになってしまってできなかったので割愛させていただきます。なにしたのかさっぱりわかりません。 SL合同朝会は、メンバーの皆さんと集まり、テーマに沿った軽い雑談などをしコミュニケーションをとりました。リモートワークならではの取り組みでしたね。 チームミーティングや月次報告会では、メンバーそれぞれが担当している仕事の進捗具合を共有されてました。いつもサイオスの社員さんはどのように情報共有しているのかを見ることができました。 次に懇談会ですね。こちらは新卒1、2年目の社員さんとの懇談会でした。主に就活について教えていただきました。僕自身もこの夏休みが終わったら就職活動を始めようと思っていたのですが、何から始めるべきか、どう始めたらいいのか、など就活を始めるうえで自分の中で若干敷居が高いような気がして始めるのに少し不安を抱いていましたが、お話を聞いたことによりそれが少し緩和されてやりやすくなりました。 MVPの武井さんのお話もかなり興味深かったです。アウトプットのすゝめがテーマの講座でした。 自分が作ってみたこと、やってみたことをどんなやり方で、どんな感じでやってみて、どうだったか、どう失敗したかを記事などに書いてみることが大事だと教わりました。そうすることで、新たな視点の意見や、知らなかった技術や知識を得る機会が格段に増えると。 ちょうど今自分も学校の個人制作で作ったデスクトップアプリがあるので、苦戦したこと、今後の改善点などを記事にしてみようと思いました。 5.終わり 以上がこのインターンに行ってやったこと、学んだことでございました。コロナになって貴重な体験を逃したりいろいろ迷惑かけたりしちゃいましたが、なかなかあまり無い経験をさせてもらったと思っています。サイオステクノロジー株式会社の皆さん、3週間どうもお世話になりましたm(_ _ )m ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 2024年度 サイオステクノロジー株式会社インターンまとめ by長島翔梧 first appeared on SIOS Tech. Lab .

こんにちは PS/SLの佐々木です。 今年もWebxに参加してきました。 私が聞いたセッションや議論した内容で興味深かったものをいくつか紹介します。 webxとは webxとは国内最大級のweb3カンファレンスです。 日本語英語問わず、様々なバクボーンを持ったスピーカーがスピーチやパネルディスカッションを行ったり、ネットワーキングエリアで交流したり、スポンサーブースで製品紹介をしていたりするイベントです。 web3はまだまだ発展途上な技術でありこれから、有用なユースケースの創出やブロックチェーンエコシステムのさらなる開発などマスアダプションに向けてまだまだ課題がある現状です。 そしてwebxではそれらの課題に対する取り組みの成果発表や新しい製品の発表、政治・政策的な取り組みやVCの方たちの注目している投資先など様々な視点からweb3に関する見え方の話が聞ける非常に興味深いイベントになっていましたのでいくつか私の印象に残った話をいくつか紹介します。 日本政府の政策について 日本のweb3政策では平議員がweb3PTの座長をしており、ホワイトペーパーも出されておいり日本のweb3政策の旗振りをしてくださっている印象を私は持っており、今回のwebxでも複数のセッションで登壇されていました。 日本のweb3に関する取り組みの大きなポイント一つ目は税制です。 今までは法人税が期末時価評価課税という制度がとられていましたが、これが対象から除外されました。 そして次の問題としてあるのが課税区分が雑所得になるという点です。 こちらはまだ改正されていませんが、キャピタルゲインと同じ扱いになるとより暗号資産を保有しやすくなります。これの背景としてあるのはビットコインETFの出現が関係しているようです。 新規でweb3のビジネスを行いたい場合にはいくつか問い合わせ対象があるようです。 経産省 内閣官房　新しい資本主義事務局 金融庁 イノベーション推進室　Fintechサポートデスク web3マスアダプションに向けて必要なこと マスアダプションに向けての議論は様々なカンファレンスで最も議論されている内容だと思います。 今年はマスアダプションに向けて以下のような内容が語られていました。 責任の所在 分散システムなので事実上の管理者は存在しない そのため何かトラブルが起こった際の責任の所在が不明になってしまう 例えばウォレットの秘密鍵を紛失した場合など 本人確認の方法 ゼロ知識証明 技術として非常に難しい 現在は生体認証を用いて検証をするのが主流？ スケーラビリティ かなりパフォーマンスが出るチェーンは出現してきている しかしまだブロックチェーンを使用していることをユーザーが意識するレベルにある AIとの共存 今まではプラットフォーマーに管理されていたデータがブロックチェーン上に保存されていくことが期待される これにより、AIがどのようなデータを学習しているのか検証が可能になりより安全なAIの利用が可能 突然AIが使用できなくなったりするリスクも減る しかし個人情報保護などの課題も多い 私の聞いたセッションでは上記のような内容が主に話されている印象でした。 去年まではインターオペーラビリティ（チェーン間のデータの相互運用）やスケーラビリティの問題が主に語られている印象でしたが、今年度は社会実装に向けての議論が多かった印象です。 日本で期待されているユースケース 日本が持っているIPを活用したサービスであったりブランドのリブランディングが挙げられていました。 IP活用 日本はアニメやキャラクターをはじめとする様々な世界的なIPが存在する。 これらのアニメキャラをメタバース空間で使用してみる実験や二次創作作品の権利をNFTで管理していくことで原作者、二次創作者どちらにもメリットのある仕組みを生み出して行けたりする。 また最近は個人がTwitterを使用してIPを生み出すような事例があり、ブロックチェーンを使うことで個人が企業に対して権利を主張できたりする可能性があり、権利保護の分野での活用が期待されています。 リブランディング 日本酒や梅酒は世界基準で見たときにかなり安価である問題がある。 これをブロックチェーンを使って製造過程のトレース情報や製造、品質情報をブロックチェーンで管理していくことで、製品の価値基準を世界標準に引き上げることでリブランディングを図る施策がある。 企業ブース 企業ブースでは様々なデモや技術者の方のお話を聞けたりディスカッションを行うことができ非常に有意義な時間でした。 私は3時間ぐらいかけてほとんどのブースを回ったのですが、DID/VCのデモを拝見することができたり、Ripple社のXRPの技術動向や使用するユースケースを聞けたり、Dappsを作成する際の共通の課題感を技術者同士で共感しあえ、各企業がどのような取り組みを行っているのかといった情報を交換できたりと非常に有意義な時間になりました。 企業様のブースを見て回っているとWalletを提供している企業さんと取引所を提供している企業さんが非常に多く、いったいどれを使えばいいやらといつも思っています（笑） 全体を通して 今年のwebxもすごい盛り上がりでweb3系のイベントは本当に派手でお祭りのようなイベントが多いなと思いいつも楽しませてもらっています。 個人的には技術的な話しはもちろんですが、普段意識的にキャッチアップできない業界の話や海外と日本のトレンドの違いを聞けるのが非常にありがたく参加しています。 web3は半分以上英語のセッションなので話を翻訳しながらメモを取るのは非常に難しいので、英語はもっと勉強しないとなぁといつも思わされますね。。。 また今回は私の大好物であるレッドブルが無限に配られていてたくさん飲めました。うれしい。 あと最後にオードリータンさんと安野貴博さんの講演を聞けたのがとてもうれしかったです。 イベントの様子     ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post webx2024 イベントレポート first appeared on SIOS Tech. Lab .

こんにちは、サイオステクノロジーの織田です。 ９月末に開催されるOSC広島での展示に向けてAIエージェントの開発に携わらせていただいています。現在は、AI周りのキャッチアップとしてAzure OpenAI Serviceの使い方を学習しています。キャッチアップの過程でAzure OpenAI Serviceで利用できるモデルの種類やその違いで躓いたので共有したいと思います。 はじめに 今回はキャッチアップの一環として、Azure OpenAI ServiceとLangChainを活用したRAGの実装を行いました。参考にしたサイトは コチラ です。このサイトでは、某人気漫画のWikipedia上のテキストを取り込むことでRAGを実装する手順を紹介しています。 不具合の内容 サイトで紹介されている通りに作業を進めていくと、ベクターデータベースの作成で不具合が発生しました。エラーの内容は下の画像の通り404エラーが発生しています。デプロイメントが存在しないということらしいです。（ちゃんとGPTをデプロイしたはずなのに…） ベクターデータベース作成時のエラー とりあえず Azure OpenAI Studioにモデルがあることを確認しにいきました。下の画像の通りモデルが存在しています。 Azure OpenAI Studioで作成したモデル一覧 モデルが存在するということは、環境変数に間違った値を指定したかと思い一応確認。しかし、Azureで確認した情報と差異は見つかりませんでした。 環境変数一覧 不具合の原因 「モデルを作成したのになぜ404エラーが出るのか…」と悶々としながら色々と調べていると コチラ のサイトを見つけました。 「Azure OpenAI Serviceで提供してるモデルにはGPT、ChatGPT、埋め込みがあります」 あれ？そういえば、環境変数の中に”text-embedding-3-small”なるものがあったような…とりあえず Azure OpenAI Studioでモデル一覧を確認。 Azure OpenAI Serviceで提供してるモデル一覧 あった！！不具合の原因は埋め込みモデルを作っていないことだったのです。（まさかGPTとは別に作るものだったとは…）その足でベクターデータベースを作成。 埋め込みモデル作成後にエラー解消 無事に実行されました 最後に 今回は、Azure OpenAI Serviceで利用できるモデルについてでした。GPT以外にも複数のモデルが利用可能になっており、必要な場合はGPTとは別に作成する必要があります。もし私と同じようなエラーが発生し解決できずに困っている方がいれば、参考にしていただけると幸いです。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Azure OpenAI Serviceで利用できるモデルについて first appeared on SIOS Tech. Lab .

こんにちは、サイオステクノロジーの佐藤 陽です。 今回はBicepで複数のサブネットをデプロイしたときに発生した、エラーの解消方法をご紹介します。 Bicep入門したての自分用のメモとなってますが、誰かのお役に立てれば幸いです。 はじめに みなさんBicep使ってますか？ Azureに特化したIaCツールであり、書きやすさ・読みやすさに定評があります。 最近自分もこのBicepに入門して色々書いてるのですが、TerraformやARM Templateに比べると非常に書きやすくて気に入ってます。 このBicepですが、Azure FunctionsやCosmosDBなんかのリソースはもちろん、VNetなどネットワークリソースのデプロイも可能です。 そんな中、複数のサブネットをデプロイするときに少しハマってしまったので、個人的な備忘録として記録に残したいと思います。 結論 先に結論書いてしまうと 発生したエラー AnotherOperationInProgress: Another operation on this or dependent resource is in progress. To retrieve status of the operation use uri: https://management.azure.com/subscriptions/~~~~ 解決策 VNetとSubnetNetを別々のリソースとして定義するのではなく SubNetをVNetの子リソースとして定義するよう実装する。 MSの ドキュメント にも「子リソースとして定義することが最適である」との記載がありました。 解決までの道のり 現状 まず今回想定している環境として、以下のレンジでVNetを作成します。 10.0.0.0/16 このVNetに対して、以下の3つのSubnetを作成します。 10.0.0.0/24 10.0.1.0/24 10.0.2.0/24 これを実現するために、最初に書いていたBicepのコードはこちらです。 main.bicep targetScope = 'subscription' param environmentName string param location string var tags = {   // Tag all resources with the environment name.   'azd-env-name': environmentName } resource rg 'Microsoft.Resources/resourceGroups@2021-04-01' = {   name: 'rg-sios'   location: location   tags: tags } module vnet './core/networking/vnet.bicep' = {   name: 'vnet'   scope: rg   params: {     name: 'vnet-sios'     addressPrefix: '10.0.0.0/16'     location: location   } } module subnet1 './core/networking/subnet.bicep' = {   name: 'subnet1'   scope: rg   params: {     name: 'subnet1'     addressPrefix: '10.0.0.0/24'     existingVirtualNetworkName: vnet.outputs.name   } } module subent2 './core/networking/subnet.bicep' = {   name: 'subnet2'   scope: rg   params: {     name: 'subnet2'     addressPrefix: '10.0.1.0/24'     existingVirtualNetworkName: vnet.outputs.name   } } module subnet3 './core/networking/subnet.bicep' = {   name: 'subnet3'   scope: rg   params: {     name: 'subnet3'     addressPrefix: '10.0.2.0/24'     existingVirtualNetworkName: vnet.outputs.name     } } ./core/networking/vnet.bicep param location string = resourceGroup().location param name string // 作成するvnetのアドレス空間 param addressPrefix string param subnets array = [] resource vnet 'Microsoft.Network/virtualNetworks@2021-02-01' = {   name: name   location: location   properties: {     addressSpace: {       addressPrefixes: [addressPrefix]     }     subnets: subnets   } } output name string = vnet.name output id string = vnet.id ./core/networking/subnet.bicep param name string param addressPrefix string param existingVirtualNetworkName string param delegations array = [] // 既に存在する仮想ネットワークを参照 resource existingVirtualNetwork 'Microsoft.Network/virtualNetworks@2023-04-01' existing = {   scope: resourceGroup()   name: existingVirtualNetworkName } resource subnet 'Microsoft.Network/virtualNetworks/subnets@2023-04-01' = {   parent: existingVirtualNetwork   name: name   properties: {     addressPrefix: addressPrefix   } } output id string = subnet.id output name string = subnet.name 最初にVNetのリソースを定義し、そのあとparentのパラメータを通してSubnetを追加するような方法となります。 このBicepファイルを用いてを実行すると、以下のようなエラーが発生しました。 AnotherOperationInProgress: Another operation on this or dependent resource is in progress. To retrieve status of the operation use uri: https://management.azure.com/subscriptions/~~~~   Subnetを作成する際、同じVNetに同時にアクセスしてしまうため、処理がバッティングしていることを表しています。 このあたりBicepではいい感じにやってくれないようです。 ちなみに stackoverflow にも同じような境遇の人がいました。 修正案 以下のように、VNet構築時に子リソースとしてSubnetを書くことで解消しました。 module vnet './core/networking/vnet.bicep' = {   name: 'vnet'   scope: rg   params: {     name: 'vnet-sios'     addressPrefix: '10.0.0.0/16'     location: location     subnets: [         {           name: 'subnet1'           properties: {             addressPrefix: '10.0.0.0/24'           }         }         {           name: 'subnet2'           properties: {             addressPrefix: '10.0.1.0/24'           }         }         {           name: 'subnet3'           properties: {             addressPrefix: '10.0.2.0/24'           }         }       ]   } } この実装方法に関しては、 MSのドキュメント でも推奨されており、 以下のように書かれていました。 仮想ネットワーク定義内でサブネットを定義するのが最適です。 子リソースを使用してサブネットを定義すると、Bicep ファイルが初めてデプロイされた場合、仮想ネットワークがデプロイされます。 その後、仮想ネットワークのデプロイが完了すると、各サブネットがデプロイされます。 この順序付けは、Azure Resource Manager が個々のリソースを個別にデプロイするために起こります。 同じ Bicep ファイルを再デプロイすると、同じデプロイの順序付けが起こります。 ただし、subnets プロパティが実質的に空なので、仮想ネットワークは、サブネットの構成なしにデプロイされます。 その後、仮想ネットワークが再構成された後、サブネット リソースが再デプロイされ、各サブネットが再確立されます。 状況によっては、この動作により、デプロイ中に仮想ネットワーク内のリソースの接続が失われることがあります。 その他の状況によっては、Azure により仮想ネットワークの変更が妨げられ、デプロイが失敗することがあります。 また他にも、Subnetのリソース定義部分でdependsOnのパラメータを利用することで解決できそうでした。 ただ、「dependsOnは必要な時だけ使うべき」といった内容の 記載 も見られたので、今回は採用を見送りました。  サブネットへの参照 一件落着かと思いましたが 次にハマったのが、作成したSubnetを参照する方法です。 プライベートエンドポイントの設定を行う場合など、他のリソースを作成するときにこのSubnetのIdが必要になるケースが多くあるかと思います。 独立したリソースとしてSubnetを定義している場合は簡単にアクセスできますが、VNetの子リソースとして定義されているため、ややアクセスし辛いです。 VNetが持つ subnets というarrayのパラメータはすぐに取得できるのですが、そこから取得したいSubnetだけを抽出するのは冗長な実装になりそうです。 しかも配列に入れられる順番も毎回異なる可能性があるとのことで、array番号で決め打ちというのも難しそうです。 そして、この解決方法に関しても MSドキュメント に紹介されてました。 ドキュメントさまさまです。 ドキュメントから引っこ抜くと、以下のような形での実装すればOKみたいです。 param location string = resourceGroup().location var virtualNetworkName = 'my-vnet' var subnet1Name = 'Subnet-1' var subnet2Name = 'Subnet-2' resource virtualNetwork 'Microsoft.Network/virtualNetworks@2023-11-01' = {   name: virtualNetworkName   location: location   properties: {     addressSpace: {       addressPrefixes: [         '10.0.0.0/16'       ]     }     subnets: [       {         name: subnet1Name         properties: {           addressPrefix: '10.0.0.0/24'         }       }       {         name: subnet2Name         properties: {           addressPrefix: '10.0.1.0/24'         }       }     ]   }   resource subnet1 'subnets' existing = {     name: subnet1Name   }   resource subnet2 'subnets' existing = {     name: subnet2Name   } } output subnet1ResourceId string = virtualNetwork::subnet1.id output subnet2ResourceId string = virtualNetwork::subnet2.id   ただこのコードだと moduleを利用していない ハードコーディング色が強い など、いまいち柔軟性に欠ける実装に感じました。 そこで、このコードを参考に、subnet.bicepを以下のように書き直しました。 ./core/networking/subnet.bicep param name string param existingVirtualNetworkName string // 既に存在する仮想ネットワークを参照 resource existingVirtualNetwork 'Microsoft.Network/virtualNetworks@2023-11-01' existing = {   name: existingVirtualNetworkName   //名前が一致するSubnetだけを抽出   resource subnet 'subnets@2023-11-01' existing = {     name: name   } } output id string = existingVirtualNetwork::subnet.id output name string = existingVirtualNetwork::subnet.name このリソースに対し、既存のVNetとSubnetの名称を与えることで 既に存在しているSubnetリソースにアクセスすることが可能となり、SubnetのリソースIDを取得することが可能となります。 main.bicepとしては以下のような形になります。 (実際は、subnet名などを変数で定義しておいてあげるとよいかと思います。) module vnet './core/networking/vnet.bicep' = {   name: 'vnet'   scope: rg   params: {     name: 'vnet-sios'     addressPrefix: '10.0.0.0/16'     location: location     subnets: [         {           name: 'subnet1'           properties: {             addressPrefix: '10.0.0.0/24'           }         }         {           name: 'subnet2'           properties: {             addressPrefix: '10.0.1.0/24'           }         }         {           name: 'subnet3'           properties: {             addressPrefix: '10.0.2.0/24'           }         }       ]   } } module existingSubnet1 './core/networking/subnet.bicep' = {   name:'existingSubnet1'   scope:rg   params:{     name:'subnet1'     existingVirtualNetworkName: vnet.outputs.name   } } //例えばKeyVault用にPrivateEndpointの設定を行う module keyVaultPrivateEndpoint './core/networking/private-endpoint.bicep' = {   name: 'key-vault-private-endpoint'   scope: rg   params: {     name: keyVault.outputs.name     location: location     subnetId: existingSubnet1.outputs.id  //ここでSubnetのIdを参照     privateLinkServiceId: keyVault.outputs.id     privateLinkServiceGroupIds: ['vault']     dnsZoneName: 'vaultcore.azure.net'     linkVnetId: vnet.outputs.id   } } まとめ 今回はBicepを使って複数Subnetを構築する際のポイントをご紹介しました。 他にもこんな簡単な方法あるよ！といった方はぜひコメントで教えてください。 まだまだBicep入門したてなので、色々勉強していきたいと思います。 ではまた！ 参考文献 2023-11-01 API バージョンを使って Bicep で Azure VNet のサブネットを自由にデプロイする Azure Bicep の配列にハマる(n回目) Bicep を使って仮想ネットワーク リソースを作成する ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 【Azure】Bicepで複数サブネットをデプロイする時のポイントを紹介！ first appeared on SIOS Tech. Lab .

Azure OpenAI ServiceによるRAGハンズオン開催のお知らせ 〜独自データを用いた生成AIの利活用を学ぶ〜【初級編】第2回 この度、「 Azure OpenAI ServiceによるRAG実装ガイド 」 をダウンロードしていただいた方限定に、 RAGのハンズオンを無料開催いたします。前回好評につき、2回目の開催です。 本ガイドの目的は、これからRAGを始める人に参考にしていただくため、「シンプル」「強力」「すぐ動く」をモットーにしたRAGアプリケーションを実装するためのガイドです。本ガイドではRAGのアーキテクチャのみならず「実際に動くコード」もご用意致しました。読者の皆様には、コードを動かしながらRAGをより深くご理解頂けることを一番の目的としております。 ハンズオンのお申込みは先着順となっておりますので、 ご興味がある方はお早めにお申し込みください。 【無償】初級テクニカルトレーニング Azure OpenAI ServiceによるRAGハンズオン 〜独自データを用いた生成AIの利活用を学ぶ〜【初級編】 ＜概要＞ Azure OpenAI Serviceの概要説明 RAGの概要説明 RAGの構築 ＜日時＞ 2024年9月20日（金）13:00～17:00（受付12: 30～） ＜場所＞ 〒106-0047 東京都港区南麻布2-12-3　サイオスビル3F ＜得られるスキル＞ Azure OpenAI Serviceの基礎 Azure OpenAI Serviceがどのようなサービスであり、 どのように利用するのかを学ぶことができます。これにより、 クラウドベースのAIサービスの活用方法を理解し、 自身のプロジェクトに適用するための基礎を築くことができます。 RAGの仕組み RAG（Retriever-Augmented Generation）の基本的な仕組みを理解し、 独自データを活用した生成AIの基礎理論を学ぶことができます。 RAG構築方法 実際にRAGを構築するための基本的な手順を学びます。 ハンズオンを通じて、 独自データの準備から外部データベースへの登録、 そして生成AIを用いた回答生成までの流れを体験し、 実践的なスキルを身につけることができます。 ＜費用＞ 無料 ＜定員＞ 24名（先着順） ＜対象者＞ Azure OpenAI ServiceによるRAG実装ガイドをダウンロードされた方 エンドユーザ企業の方 ＜準備いただくもの＞ お名刺 無線LANを利用できるPC(Windows、 MacどちらでもOK) GitHubのアカウント(GitHub Codespacesの180CPU時間の無料枠利用のためFr eeでOK) Azureのサブスクリプション Azureのサブスクリプションで利用可能なAzure Open AI Service( 承認には時間を要するため以下のURLより早めにご申請ください 。ご用意が難しい場合は別途ご相談ください。) https://aka.ms/oai/access ＜注意事項＞ 本ハンズオンでは、 受講者ご自身のAzureサブスクリプションを使用していただく ことが前提となります。そのため、 サブスクリプションにかかる費用は受講者様のご負担となります。 ハンズオン中に発生するAzure利用料金は、通常、 数百円程度、1000円未満と見込んでおります。 Azure OpenAI ServiceによるRAG実装ガイドをダウンロードしていない 方がお申込みをした場合、キャンセルとさせていただきますので、 あらかじめご了承ください。   【有償】支援サービス 上級テクニカルトレーニング Azureの最先端技術を駆使したRAGハンズオンです。 このハンズオンでは、最新の検索手法である「 セマンティックハイブリッド検索」、Azure Static Web Apps、Azure Functionsによるフルサーバーレス構成など、 最新技術を用いたRAGの構築方法をお伝えします。 業務委託・技術支援 当社では、AIだけでなく、 クラウドネイティブなアプリケーション開発、 既存システムのクラウド移行・モダナイゼーション、 システムの基盤構築など、 クラウドを中心としたシステム開発あるいは技術支援なども行って おります。システムでの困り事がありましたら、 ぜひご相談ください。 チャットボット作成 (RAGツール開発) RAG(Retrieval-Augmented Generation)を中心に、 話題の生成AIを活用した業務の効率化、 DX化をお手伝いいたします。社内ノウハウの見える化、 カスタマーサポートの省力化、 チャットボットアプリケーションの導入など、 社内資源の有効活用をお考えの場合は、ぜひご相談ください。 AI関連アプリ開発 既存のアプリ・システムを、もっと便利に・ 楽にできないかお考えですか？RAGやLangChain などにより生成AIを活用すれば、 今まで以上により業務効率を上げるのに効率的なアプリの開発を行 うことができます。 まずはコンサルティングという形からご相談いただくことも可能で す。AIで迷われたら、ぜひご相談ください。 Azure CSP販売・技術支援 Azureのライセンス販売を通じてお客様のビジネスをご支援し ています。 Azureライセンスの提供からAI技術のコンサルティングまで 全て当社にお任せください。​​​​ ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 【9/20無料開催】Azure OpenAI ServiceによるRAGハンズオン 〜独自データを用いた生成AIの利活用を学ぶ〜初級編（第2回） first appeared on SIOS Tech. Lab .

サイオステクノロジーの藤原です。 今回はApache Syncopeを構築してみました。手順は公式ドキュメント（https://syncope.apache.org/docs/）を参考に進めます。 前提条件 AlmaLinux 9.4 Java 17 Apache Syncope 3.0.7 Javaインストール # dnf -y install java-17-openjdk # java -version openjdk version "17.0.11" 2024-04-16 LTS OpenJDK Runtime Environment (Red_Hat-17.0.11.0.9-3) (build 17.0.11+9-LTS) OpenJDK 64-Bit Server VM (Red_Hat-17.0.11.0.9-3) (build 17.0.11+9-LTS, mixed mode, sharing) Apache Syncopeインストール ダウンロード ここ（https://syncope.apache.org/downloads）からZIPをダウンロードします。Signaturesのsha512の値を控えておきます # curl -LkvOf https://dlcdn.apache.org/syncope/3.0.7/syncope-standalone-3.0.7-distribution.zip フィンガープリントの確認 # sha512sum syncope-standalone-3.0.7-distribution.zip acb26d01d244e7bd33339f64c9811286e9178e5cd3b7e472fbeabf8be83bb8e77ccc8849f3e587ebacfec34887fd6ce73aa3333231952a60f316e4b71f624f8b  syncope-standalone-3.0.7-distribution.zip   先ほど控えたSignaturesのsha512の値とフィンガープリントが一致していることを確認します。 インストール 配置 ダウンロードしたパッケージを解凍して配置します。 # unzip syncope-standalone-3.0.7-distribution.zip # mv syncope-standalone-3.0.7 /opt/apache-syncope syncopeユーザを作成 # useradd syncope 権限を付与 # chown -R syncope. /opt/apache-syncope systemdで起動するように設定を追加 # vim /usr/lib/systemd/system/syncope.service [Unit] Description=Apache Syncope Service [Service] Type=forking User=syncope Group=syncope ExecStart=/opt/apache-syncope/apache-tomcat-9.0.89/bin/startup.sh ExecStop=/opt/apache-syncope/apache-tomcat-9.0.89/bin/shutdown.sh WorkingDirectory=/opt/apache-syncope/apache-tomcat-9.0.89/bin [Install] WantedBy=multi-user.target   サービス起動 SELinuxの無効化 # setenforce 0 systemd設定のリロード # systemctl daemon-reload サービス起動 # systemctl start syncope ログイン サービスはポート9080で起動します。 今回はポートフォワードでローカルポート8080からSyncopeサーバのポート9080にアクセスしています。 http://localhost:8080/syncope-console   ユーザー名：admin パスワード：password 構築からログインまで完了です。 初期設定ではDBのH2 Databaseがインメモリで起動するように設定されており、再起動するたび初期化されてしまいます。 DBにはこちら（https://syncope.apache.org/docs/getting-started.html#internal-storage）のものが使用可能なようなのでPostgreSQLにしたいなと思うのですが、現時点では設定方法が分かりません。。。       ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Apache Syncopeを構築してみた first appeared on SIOS Tech. Lab .

サイオステクノロジーの藤原です。 今回はmidPointをDistribution Packageから構築してみました。手順は（ https://docs.evolveum.com/midpoint/install/bare-installation/distribution/ ）を参考に進めます。 構築から初回ログインまでの流れについて説明していきます。 前提条件 AlmaLinux 9.4 Java 21 midPoint 4.8.3 Javaインストール # dnf -y install java-21-openjdk # java -version openjdk version "21.0.4" 2024-07-16 LTS OpenJDK Runtime Environment (Red_Hat-21.0.4.0.7-1) (build 21.0.4+7-LTS) OpenJDK 64-Bit Server VM (Red_Hat-21.0.4.0.7-1) (build 21.0.4+7-LTS, mixed mode, sharing) midPointインストール ダウンロード # curl -OL https://evolveum.com/downloads/midpoint/4.8.3/midpoint-4.8.3-dist.tar.gz 解凍 # tar zxvf midpoint-4.8.3-dist.tar.gz 配置 # mv midpoint-4.8.3 /opt/midpoint-4.8.3 # ln /opt/midpoint-4.8.3 /opt/midpoint midpointユーザ作成 # useradd -r -d /opt/midpoint/var -s /sbin/nologin -c "Midpoint daemon" midpoint 権限変更 # chown -R midpoint. /opt/midpoint-4.8.3 systemd設定 今回はこちら（ https://docs.evolveum.com/midpoint/install/bare-installation/systemd/ ）を参考にsystemdで起動するように設定してみました。 # vim /etc/systemd/system/midpoint.service [Unit] Description=MidPoint Standalone Service ###Requires=postgresql.service ###After=postgresql.service [Service] User=midpoint WorkingDirectory=/opt/midpoint ExecStart=/usr/bin/java -Xmx2048m -Dmidpoint.home=/opt/midpoint/var -jar /opt/midpoint/lib/midpoint.jar SuccessExitStatus=143 ###TimeoutStopSec=120s [Install] WantedBy=multi-user.target サービスの起動と自動起動設定 # systemctl daemon-reload # systemctl enable midpoint # systemctl start midpoint # systemctl status midpoint 初回ログイン administratorのパスワード確認 初回起動時のログにadministratorのパスワードが記載されているので確認します。 # grep "Administrator initial password" /opt/midpoint/var/log/midpoint.log 2024-08-27 05:00:20,660 [] [main] WARN (com.evolveum.midpoint.init.DataImport): Administrator initial password (except double quotes): "hogehoge" ログインする ポート8080でサービスが起動するので、midPointにログインします。 今回はポートフォワードでローカルポート28080からmidPointサーバのポート8080にアクセスしています。 https://localhost:28080/midpoint/ ユーザー名：administrator パスワード：hogehoge ホーム画面が表示されたら初回ログインまで完了です。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post midPointを構築してみた（From Distribution Package） first appeared on SIOS Tech. Lab .

サイオステクノロジーの藤原です。 前回はmidPointを構築しました（https://tech-lab.sios.jp/?p=42755）。 今回はmidPointでCSVからアカウントを作成したいと思います。   CSVの用意 源泉となるCSVを作成します。CSVはmidPointが載っているサーバ上に配置します。 ファイルにはmidPointが書き込みできる権限を与えます。 # vim /opt/midpoint/var/csv/csvresource.csv ユーザID 姓（漢字） 名（漢字） メールアドレス sios-test1 最雄 太郎 sios-test1@siostest02.com sios-test2 最雄 次郎 sios-test2@siostest02.com sios-test3 最雄 三郎 sios-test3@siostest02.com   リソースの作成 midPointと接続されるシステムはリソースとして定義されます。CSVのリソースを作成していきます。 ホーム画面から左ペインの「リソース」＞「新規リソース」を選択します 「スクラッチ」を選択します 「CsvConnector」を選択します 基本情報を入力し、「次へ：設定→」へ進みます 最初に配置したCSVのファイルパスを指定し、「次へ：ディスカバリー→」へ進みます CSVファイルに書き込み権限がない場合、ここでエラーになります。   各項目を入力し、「次へ：スキーマ→」へ進みます デフォルトでAccountObjectClassにチェックが入っているので、そのまま「リソースの作成」を選択します リソースが作成できたので、「ウィザードを終了」からリソース一覧に戻ります 「CSVリソースblog用」が作成されました リソース・オブジェクトが認識されていることを確認します CSVに記載されたアカウントが認識されています リソースの設定 midPointは基本的にリソースを作成しただけでは何も処理が発生しません。midPoint側にCSVのリソース・オブジェクトに対応するユーザーが存在しない場合に、ユーザーを作成するように設定します。 オブジェクトタイプの追加 先ほど作成したリソースを選択し、「スキーマ処理」を開きます 基本情報を入力し、「次へ：リソース・データ→」へ進みます 種類はアカウントを選択します。CSVリソースに記載されているのはアカウントであるためです。 リソース・データを入力し、「次へ：MidPointデータ→」へ進みます ここはデフォルトのまま進めます。 MidPointデータを入力し、「設定を保存」を選択します タイプはユーザー、アーキタイプはPersonを選択します オブジェクトタイプが作成されます オブジェクトタイプの設定 作成したオブジェクトタイプにマッピングと同期の設定を行います マッピングを設定します。「インバウンドの追加」を選択します CSVリソースのアカウントの属性と、midPoint側のアカウントの属性との紐づけを行います。 今回は以下のように属性をマッピングしました 次に同期の設定を行います リソース側のアカウントとmidPoint側のアカウントを比較した時に、どのように処理を行うか定義します。 今回はリソース側のアカウントに対応するアカウントがmidPoint側に存在しない場合に、ユーザーを新規作成するような設定を行いました。   アカウント作成 リソースのライフサイクル状態をActiveにして、変更が反映されるようにします リソース・オブジェクトから対象アカウントを選択し、右側のアイコンから「インポート」をクリックしてアカウントをインポートします 状況がLINKEDになっていれば、midPoint側にユーザーとアカウントが新規作成され、CSV側のアカウントと紐づいた状態になっています。 左ペインのユーザー＞すべてのユーザーを開きます 先程インポートしたアカウントからユーザーが作成されたことが確認できます。         ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post midPointでCSVからアカウントを作成する first appeared on SIOS Tech. Lab .

はじめに こんにちは！今月から生成AI活用事業がメイン業務になったなーがです。前回から少し時間が空いてしまいましたが、今回はAzure OpenAI Serviceの機能の一つであるOn Your Dataについて書こうと思います。 Azure OpenAI On Your Dataとは？ Azure OpenAI On Your DataはAzure OpenAI Serviceの機能の一つで、簡単にRAGが構築できるサービスです。RAGって何？という方は、弊社ブログで解説していますので以下の記事をご覧ください。 RAG構築のためのAzure OpenAI Serviceリファレンスアーキテクチャ詳解 Azure OpenAI ServiceによるRAG実装ガイドを公開しました 【7/24無料開催】Azure OpenAI ServiceによるRAGハンズオン 〜独自データを用いた生成AIの利活用を学ぶ〜初級編 こちらは9月にも開催予定です！ 【徹底解説】Document Intelligenceを利用してRAGを構築する【セマンティックチャンキング】 【初心者向け】RAG評価フレームワーク Ragasを必要最低限で使ってみる 【AOAI】RAGパイプラインの構築から評価フェーズまでの実装を一挙解説！【Ragas】 RAGを自前で構築するには以下の4つのリソースが必要となり、Azureを使用する場合はそれぞれ以下のようになります。 インデクサー：自前で作成 オーケストレーター：自前で作成 検索エンジン：Azure AI Search 生成AI：Azure OpenAI Service 弊社ブログでも「 RAG構築のためのAzure OpenAI Serviceリファレンスアーキテクチャ詳解 」として解説を行っていますが、あまりリソースを作ったことがない場合やコードはよく分からないからGUIでポチポチやって出来ないかな？と思われている方もいると思います。Azure OpenAI On Your Dataを使うと、以下のように自前で作成が必要だったインデクサーとオーケストレーターをAzure側でいい感じにやってくれます。 インデクサー： Azure OpenAI Service オーケストレーター： Azure OpenAI Service 検索エンジン：Azure AI Search 生成AI：Azure OpenAI Service 使い方 まず、作成が必要なリソースは以下になります。各リソースの作成方法に関しては長くなるのでここでは割愛します。 Azure OpenAI Service モデルのデプロイ Azure AI Search Azure ストレージアカウント Azure OpenAI Studioのプレイグラウンドを開くと、「セットアップ」の中に「データを追加する」があると思うので、クリックします。 ※新UIでやっています。旧UIの場合は「設定」の中に「データを追加する」があります。 「データソースの追加」をクリックします。 ローカルのファイルをアップロードするため、「データソースを選択する」で「Upload files (preview)」を選択して「次へ」をクリックします。 「サブスクリプション」、「Azureストレージアカウント」、「AI Search」を選択し、「インデックス名（今回はdocsとしました）」を入力します。 ※「Azureストレージアカウント」の「リソースの共有 (CORS)」が設定されていない場合は、下記のようにエラーが発生します。「CORSをオンにする」をクリックすることで、「リソースの共有 (CORS)」が設定されます。 ドラッグアンドドロップまたはファイルを参照して選択したファイル名が表示されたら「ファイルのアップロード」をクリックします。 「ファイルは正常にアップロードされました。」と表示されたら「次へ」をクリックします。 「検索の種類（今回はセマンティックにしました）」、「チャンクサイズ（今回はアップロードするファイルが小さいので256としました」を選択して「次へ」をクリックします。 「Azure リソース認証の種類」で「APIキー」を選択して「次へ」をクリックします。 「保存して閉じる」をクリックします。 インデクシングが開始されます。 しばらくすると、データソース作成が完了します。 AI Seachの「インデックス」を確認すると、アップロードしたファイルがインデックスとして登録されていることが分かります。 それではプロンプトで「テスト就業規則.pdf」に記載されている始業時間を質問をしてみます。望んだとおりの回答を得ることが出来ました。 回答に参照があるので開いてみると、参照元の情報（今回だとテスト就業規則.pdf）が表示されています。 データの削除 「データソースの削除」から「続行」をクリックすることでアップロードしたデータソースを削除できます。（※AI Searchのインデックスは削除されません） さいごに 今回はAzure OpenAI Serviceの機能の一つであるOn Your Dataについて書きました。生成AI活用事業に取り組み始めて1か月が経ち、少しずつ生成AIやRAGについての知識が付いてきたと思います。今後も業務で学んだことをブログにしていきたいと思います。 ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post Azure OpenAI Service の On Your Dataを使ってみた first appeared on SIOS Tech. Lab .

こんにちは！ 今月も「OSSのサポートエンジニアが気になった！OSSの最新ニュース」をお届けします。 2024/7/31、株式会社グローバルインフォメーションは、市場調査レポート「Linuxソフトウェア市場：タイプ別、用途別：世界の機会分析と産業予測、2024年～2032年」の販売を開始しました。 Linuxソフトウェア市場：タイプ別、用途別：世界の機会分析と産業予測、2024年～2032年 https://newscast.jp/news/4939282 2024/8/7、Linux Foundation Research が「Open Source License Compliance」の日本語版「オープンソース ライセンス コンプライアンス」を公開しました。 オープンソース ライセンス　コンプライアンス https://www.linuxfoundation.jp/publications/2024/08/open-source-license-compliance-jp/ 2024/8 の Windows セキュリティ更新プログラムが Windows / Linux のデュアルブート環境に影響があり、Linux 環境が起動しなくなる事象が発生する可能性があると発表しました。 August 2024 security update might impact Linux boot in dual-boot setup devices https://learn.microsoft.com/en-us/windows/release-health/status-windows-11-22h2#3377msgdesc ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 【2024年8月】OSSサポートエンジニアが気になった！OSS最新ニュース first appeared on SIOS Tech. Lab .

今号では、Linux における 標準入力 、 標準出力 、 標準エラー出力 について解説します！ 標準入力・標準出力・標準エラー出力とは 標準入力 とは、プログラムが使うデータを受け取るための読み込み元を意味します。 主な標準入力として、 キーボード などがあります。 標準出力 とは、プログラムが使うデータの出力先を示します。 それに対して 標準エラー出力 とは、プログラムが使うデータのうち、エラーの出力先を意味します。 主な標準出力・標準エラー出力として、 コンソール、ディスプレイ などがあります。 また、コマンド操作における標準入力・標準出力・標準エラー出力では、 パイプライン 、 リダイレクト という仕組みを使用することができます。 パイプライン パイプラインとは、コマンドの出力を別のコマンドの入力として扱う仕組みです。 &#8220;|&#8221; で表現します。 例えば、text.txt というファイルの内容から grep コマンドで特定の文字列を抽出する場合、下記の様なコマンドを実行します。 # cat text.txt | grep aaa aaa 前提として、text.txt の内容は下記の通りです。 # cat text.txt aaa bbb ccc ddd eee この時、cat text.txt にて出力された内容が &#8220;|&#8221; (パイプライン) を通じて grep コマンドに渡され、grep コマンドはその 標準入力からデータを受け取っています 。 リダイレクト リダイレクトとは、コマンドの出力先を別の出力先 (ファイルなど) に変更することができる仕組みです。 &#8220;>&#8221; や &#8220;<" で表現します。 標準出力のリダイレクト 例えば、ls コマンドでカレントディレクトリのファイル一覧を表示させた場合、結果をコンソールではなくファイルに出力する場合、下記の様なコマンドを実行します。 # ls > /tmp/file.txt # file.txt の内容は下記の通りとなります。 # cat /tmp/file.txt file1 file2 file3 標準エラー出力のリダイレクト 上記で解説した標準出力 &#8220;>&#8221; の場合、 エラーとなる実行結果、つまり標準エラー出力 はリダイレクトしません。 例えば、先ほどと同様に ls コマンドの実行結果を標準エラー出力のリダイレクト &#8220;2>&#8221; を使用してファイルに出力してみますが、出力先ファイルには何も記録されません。 代わりに、デフォルトの標準出力であるコンソールに実行結果が表示されています。 # ls 2> /tmp/file.txt file1 file2 file3 # cat /tmp/file.txt # では、ls コマンドで存在しないファイルを指定して実行した場合はどうでしょうか。 この場合、コンソールには何も表示されず実行結果が file2.txt にリダイレクトされたことが分かります。 # ls file4 2> /tmp/file2.txt # cat /tmp/file2.txt ls: file4 にアクセスできません: そのようなファイルやディレクトリはありません 標準出力、標準エラー出力両方のリダイレクト 上記で解説した標準出力、標準エラー出力を両方同時にリダイレクトさせることもできます。 先ほどの 2通りの ls コマンドを下記の様にそれぞれ実行すると、いずれの場合も実行結果が各ファイルへ書き込まれた事が分かります。 # ls > /tmp/file.txt 2>&1 # ls file4 > /tmp/file2.txt 2>&1 # cat /tmp/file.txt file1 file2 file3 # cat /tmp/file2.txt ls: file4 にアクセスできません: そのようなファイルやディレクトリはありません 標準入力のリダイレクト パイプラインの章で解説した grep コマンドの実行例ですが、標準入力のリダイレクトを使用しても同じことができます。 # grep aaa ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post 知っておくとちょっと便利！標準入力・標準出力・標準エラー出力について first appeared on SIOS Tech. Lab .

はじめに 皆さんこんにちは。 エンジニアの細川です！ 今月のSIOS Technologyのアドベントカレンダー、テーマは「生成AI」ということで、生成AIを活用した次世代エディターのCursorについて紹介します！無料で試せるので気になる方はぜひこの記事を読んで試してみてください！ Cursorとは？ Cursorは生成AIによるサポートが組み込まれたエディターになります。 VSCodeをフォークしているので、使い勝手などは基本的にVSCodeと変わらず、多くの拡張機能にも対応しています。 コーディングの際に、サジェストしてくれたり、chatで相談できたりするような使い勝手としてはGithub Copilotがデフォルトで入っているエディターというような印象です。 例えばコーディングしていると以下のように、サジェストをしてくれます。 &nbsp; また、chatでコードについての質問などを自然言語で投げることができます。 以下はある関数のテストコードを書いてもらっている例です。 &nbsp; &nbsp; 利用料金 料金プランは無料プラン、Proプラン、Businessプランの3つです。 個人的に無料で始められるのが、かなり推しポイントです！ Cursor導入手順 まずは こちら のページからCursorをダウンロードします。 ダウンロードしたファイルを開いて、Cursorをインストールしてください。 ダイアログ中の language 欄には「日本語」を入力します。 他はお好きなように設定してください！ VSCodeで導入済みの拡張機能をワンクリックで導入してくれるので非常に便利です！ おすすめ設定 続いて、日本語化の設定と、VSCodeのようにサイドバー表示にする設定のやり方を紹介します。 日本語化 まず日本語化です。 以下の「 Japanese Language Pack for Visual Studio Code 」の拡張機能が入っていない方は導入してください。 その後、「Ctrl + Shift + P」でコマンドパレットを開き、検索欄に「Language」と入力します。 検索結果の中から、以下のConfigure Display Languageの項目をクリックして、日本語を選択してください。 Cursorを再起動すれば、日本語になっていると思います。 サイドバー表示 続いてサイドバー表示の設定方法についてです。Cursorはデフォルトでは以下のようにツールバーが上部に表示されているのですが、こちらも設定で左サイドに表示させることができます。 まずは、以下のようにファイル→ユーザー設定→ 設定をクリックして、設定画面を開きます。 そして設定画面で検索欄に「activity」と入力して、以下のWorkbench &gt; Activity Bar: Orientationをクリックし、「vertical」を選択してください。 選択後再起動すると、VSCodeのように、左側にツールバーを表示させることができます。 権利系について ビジネス面で利用するうえで気になるのが権利系ではないでしょうか？ 少し公式ページをあさってみたところ、 こちら の箇所に生成物の権利等はすべて利用者が所有するという記載がありました。生成物については権利上は問題なさそうです。 また、chatやソースコードなどの情報がモデルの学習に使われるのではないか？という懸念もあると思いますが、そちらはプライバシーモードを使うことで解決できます。 無料プランでもプライバシーモードを利用できるので、業務利用をする場合はプライバシーモードで利用すると良いかと思います。 Github Copilotとの違い 僕は業務でGithub Copilotを利用しているのですが、 Github Copilot と今回紹介したCursorとの違いについて紹介したいと思います。 Github Copilotは既にご存知の方も多いと思いますが、VSCodeなどの拡張機能で、導入するとCursorと同じようにコードをサジェストしてくれたり、chatでやり取りを行うことができます。両方使ってみた感想としても、どちらも非常に使い勝手が良くかなり似ている印象がありました。 違いを挙げるとすれば以下の3つかと思います。 無料プランの有無 利用できるモデルの違い 有料プランの価格の違い 無料プランの有無 まず、無料プランの有無ですが、Cursorには無料のプランがあるのに対し、Github Copilotには永続的な無料プランはありません。30日限定で無料で使うことはできますが、それ以降は基本的に最低のプランでも毎月10$かかってしまいます。 利用できるモデルの違い Github Copilotでは裏側で利用されるモデルをユーザー側で指定することはできません。現在はGPT4oが使われています。それに対して、Cursorではユーザーが使うモデルを自由に設定することができます。GPT4などはもちろんのこと、自身で契約しているAPIキーを入力することで、AzureのOpenAIやGeminiなど様々なモデルを利用することができます。自身で好きなモデルを利用できることはかなり良いんじゃないかと思います。 有料プランの価格の違い 最後は有料プランの価格の違いです。 Github Copilotは1番安い個人プランの場合月額10$となっています。 それに対して、Cursorは有料プランの場合安いプランでも月額20$とGithub Copilotと比べると高めの設定となっています。もちろん無料プランでも永続的に利用することができますが、本格的に利用する場合は有料プランを契約するかと思いますので、その際は価格も念頭に置いて吟味してみてください！ まとめ Cursorはデフォルトでコードサジェストやチャットなどのサポート機能が搭載されたエディター 無料で利用できる！ VSCodeと似ており、移行も簡単 プライバシーモードを利用することで業務利用も可能そう Github Copilotとも近い使い心地。有料プラン契約の場合は要吟味 おわりに 今回は少し前に注目されていたCursorを紹介させていただきました。 永続的に無料で使えるというのはやっぱりうれしいですね。 個人開発ではぜひ積極的に利用していきたいと思います！ 他にも生成AI関連の記事がたくさん出ると思うのでぜひ そちら もチェックしてみてください！ 参考にさせていただいた記事 https://roboin.io/article/2024/08/02/github-copilot-chat-now-powered-by-gpt-4o/ https://qiita.com/k1mu0419/items/2d903660d1f571abb8f2 https://note.com/harunorika/n/na8b374cd774e &nbsp; ご覧いただきありがとうございます！ この投稿はお役に立ちましたか？ 役に立った 役に立たなかった 0人がこの投稿は役に立ったと言っています。 The post AIエディターCursor使ってみた！ first appeared on SIOS Tech. Lab .