#監視

新しい InterSystems IRIS® Cloud SQL と InterSystems IRIS® Cloud IntegratedML® クラウド製品のユーザーであり、デプロイメントのメトリクスにアクセスして独自の可観測性プラットフォームに送信しようと考えている方のために、メトリクスを Google Cloud Platform Monitoring（旧称 StackDriver）に送信して手っ取り早く行う方法をご紹介します。

CI/CD シリーズの新しい章へようこそ。ここでは、InterSystems テクノロジーと GitLab を使用したソフトウェア開発の様々な可能なアプローチを取り上げています。 今回も相互運用性について説明を続けますが、特に相互運用性デプロイの監視に焦点を当てます。 まだアラートをすべての相互運用性プロダクションにセットアップしていない場合は、それをセットアップしてエラーとプロダクションの状態についての一般的なアラートを取得できるようにしてください。

非活動タイムアウトは、すべての相互運用性ビジネスホストに共通する設定です。 ビジネスホストは、「Inactivity Timeout（非活動タイムアウト）」フィールドに指定された秒数以内にメッセージを受信しない場合に非アクティブステータスになります。 プロダクションの監視サービスはプロダクション内のビジネスサービスとビジネスオペレーションのステータスを定期的に確認し、非活動タイムアウト期間内にアクティビティがない場合にその項目を「非アクティブ」にマークします。 デフォルト値は 0（ゼロ）です。 この設定が 0 である場合、ビジネスホストはアイドル状態がどれほど続いても Inactive にマークされることはありません。

これはアラートを生成し、構成されたアラートと合わせてプロダクションの問題に関するリアルタイム通知を可能にするため、非常に便利な設定です。 ビジネスホストがアイドル状態である場合、プロダクション、統合、またはネットワーク接続に調べる価値のある問題がある可能性があります。 ただし、ビジネスホストには一定時間の非活動タイムアウトを 1 つしか設定できないため、夜間、週末、休日などのトラフィックの少ない既知の期間中に不要なアラートを生成する可能性があります。 この記事では、動的な非活動タイムアウトを実装するためのいくつかのアプローチを説明します。 機能する例（現在ある顧客サイトの本番環境で実行しているもの）を紹介していはいますが、この記事は独自の動的な非活動タイムアウトの実装を構築するためのガイドラインを紹介することを目的としているため、ここに提案するソリューションを唯一の代替手法と見なさないようにしてください。

今回は、「孤立メッセージ」について説明します。

孤立メッセージとは何ですか？

すべてのメッセージボディは、メタデータを保持するメッセージヘッダと関連付けらます。ヘッダーには、ソース構成名称、ターゲット構成名称、作成時刻、処理時刻、関連するメッセージボディ参照、セッション情報、メッセージボディのクラス名称、メッセージステータスなどの情報が格納されます。 メッセージボディに対応するヘッダーレコードが存在しない場合、そのメッセージボディは孤立メッセージボディと呼ばれます。ここでは、孤立メッセージボディの原因となる可能性があるものについて説明します。

ヘッダーのみを削除する場合

削除タスクの設定において、BodiesToo メッセージヘッダとともにメッセージボディも削除するかどうかを指定するものです。この設定をOFFにすると、削除タスクはメッセージヘッダーのみを削除し、メッセージボディは残します。これらのメッセージボディは、参照されたヘッダが削除されることから、孤立したレコードとなります。 メッセージヘッダの削除したが、メッセージボディは残している場合、マネジメントポータルでは孤立メッ セージボディを削除する方法はありません。この場合、プログラムによってメッセージボディを削除する必要があります。

削除タスクについては、ドキュメントをご参照ください。

http://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=EGMG_purge#EGMG_purge_basic

これは InterSystems FAQ サイトの記事です。

システムモニタの中の「アプリケーションモニタ」を利用することで、ユーザが定義した特定の監視対象に対してチェックを行い特定の条件に合致した場合に通知を行ったり、メッセージログ（コンソールログ）に情報を出力したり、ユーザが定義するアクションを指定できます。

＜メモ＞
アプリケーションモニタはインストールにより準備されますが、ユーザが付属のアプリケーション・モニタ・クラスを有効化するまで動作しないモニタです。
付属のアプリケーションモニタには、監査のカウントやイベント詳細を収集するもの、ディスクの容量を監視するものなどが含まれます。

詳細は、以下ドキュメントをご参照ください。
【IRIS】アプリケーション・モニタのメトリック
アプリケーション・モニタのメトリック

作成手順は以下の通りです。

1. %SYSネームスペースにアプリケーションモニタ用クラスを作成する
2. 作成した1のクラスを、システムモニタのアプリケーションモニタ有効化メニューで有効化する
3. 収集のインターバルを設定する（秒単位）
4. システムモニタを再起動する

以下例で追加するユーザ定義のアプリケーションモニタクラスは、監査ログに「ログイン失敗」のイベントが記録された場合に、メッセージログ（コンソールログ）にイベント詳細を出力する流れを記述しています。

サポートではこのような質問をたまに受けることがあります。何かが、または誰かが、想定以上のライセンスを使用しており、それを調べなければなりません。 

調べるタイミングは2回あります。 1 つは、アプリケーションが動作しないか、ターミナル経由で接続しようとすると次のような「愛くるしい」メッセージが表示され、ライセンスが使い果たされていることに気づいたときです。

<LICENSE LIMIT EXCEEDED> メッセージ: 

2 つ目のタイミングは、アプリケーションを使用できなかったことがあったという苦情をエンドユーザーから受けたときですが、問題が発生しているのを確認するには遅すぎます。 こういった場合には通例、messages.log に「License Limit exceeded xxxx times」というメッセージが確認されます。

適時に問題をキャッチする

最初のタイミングの場合は、問題が発生している状態を確認できるため、それをキャッチする方法がいくつか考えられます。 

• システム管理ポータルにログインできるのであれば、［ライセンス］セクションに移動して、何が何を使用しているのかを調べることができます。 
• -B パラメーターを使用してターミナル経由で接続します（ライセンスがすべて使用中であるため、通常の方法では接続できません）。

皆さん、こんにちは。

IRIS 履歴モニタープロジェクトが更新されました。ZPM とビルトインの REST API /api/monitor/metrics を使用します。

皆さん、こんにちは！

職場で持ち上がった単純なリクエストで始めた個人プロジェクトを紹介したいと思います。 

使用している Caché ライセンス数を調べることはできますか？ 

コミュニティに掲載されている他の記事を読んでみたところ、David Loveluck が投稿したぴったりの記事が見つかりました。 

APM - Using the Caché History Monitor（APM - Caché 履歴モニターを使用する）

そこで、David の記事を参考に、Caché 履歴モニターを使って、リクエストされた情報を表示して見ました。 

「どのテクノロジーを使用するのか」という疑問に対し 

私は CSP に決定しました。単純で強力なテクノロジーであるため、私が担当するお客様は Caché が単なる MUMPS/ターミナルではないことに気づくでしょう。

ライセンス、データベース増加状況、CSP セッションの履歴を表示するページを作成した後、「システムダッシュボードとプロセス」ページのデザインを新装することにしました。

私の Caché インスタンスではすべてうまく機能します。

でも、IRIS はどうでしょうか？

この度、インターシステムズはSystem Alerting & Monitoring (SAM) バージョン 1.1 をリリースしました。

SAMとは?

SAMはIRIS標準の 監視 API や ログ・モニタ をGrafana や Prometheus といった使い慣れた業界標準のツールと融合し、IRISの基本的な監視とアラートのソリューションです。

SAMの詳細については System Alerting and Monitoring ガイド をご参照ください。

SAM 1.1 の新機能は?

大きなデータセットを扱う際、Grafana ダッシュボードのグラフのパフォーマンスが向上しています。  SAM 1.0 からアップグレードする場合、データにインデックスが追加されるため、十分なディスクスペースを確保することをお勧めします。

アップグレード時の詳細については、 リリースノート を参照してください。
 

SAM トップページ

SAM インスタンスの詳細ページ

皆さん、こんにちは。私の最新のプロジェクトの1つをご紹介します。 Grafana用データソースプラグインです。これは、InterSystems IRISに直接接続して（将来的に）あらゆるデータを収集できるプラグインです。 

この記事では、syslogテーブルについて説明したいと思います。  syslogとは何か、どのように確認するのか、実際のエントリはどのようなものか、そしてなぜそれが重要であるのかについて説明します。  syslogテーブルには、重要な診断情報が含まれることがあります。  システムに何らかの問題が生じている場合に、このテーブルの確認方法とどのような情報が含まれているのかを理解しておくことが重要です。

注記（2019年6月）: 多くの変更がありました。最新の情報についてはこちらをご覧ください。 注記（2018年9月）: この記事が最初に投稿されて以来、多くの変更がありました。Dockerコンテナバージョンを使用することをお勧めします。コンテナとして実行するためのプロジェクトと説明は、以前と同じGitHubの公開場所に残っていますので、ダウンロードして実行し、必要に応じて変更してください。

お客様と共にパフォーマンスレビュー、キャパシティ計画、およびトラブルシューティングに取り組む際、pButtonsから、Cachéとオペレーティングシステムのメトリクスを解凍してレビューすることがよくあります。 しばらく前、HTMLファイルを参照して、グラフ化するセクションを切り取ってExcelに貼り付ける代わりに、UNIXシェル、Perl、およAWKスクリプトで書かれたpButtonsメトリクスのアンパックユーティリティを使用する記事を投稿しました。 これは、時間を節約できる便利な手法ではありますが、内容が全部網羅されているわけではありません。 また、メトリクスを素早く確認して、レポートに含められるように、メトリクスを自動的にグラフ化するスクリプトも使用しています。

これは InterSystems FAQ サイトの記事です。

InterSystems製品のシステムモニタが色々なリソースの使用状況を監視しています。

そしてその使用状況に応じてアラートやワーニング情報をコンソールログ（message.log/cconsole.log）に出力します。

アラート情報が表示するCPUのリソースについては、以下のものが定義されています。

中間データベースを使用して、Grafana と IRIS（または Cache/Ensemble）を使用する方法を説明した非常に有益な記事がコミュニティにいくつか掲載されています。

しかし私は、IRIS 構造に直接アクセスしたいと考えていました。 特にこのリンクで説明しているように、SQL でアクセス可能なCaché履歴モニターのデータにアクセスしたかったのです。

https://community.intersystems.com/post/apm-using-cach%C3%A9-history-monitor

また、データをいじりたくもありませんでした。

必要とするデータを返すクラスクエリはすでにあったので、それらを、JSON を返す REST クラスに埋め込むだけで良かったからです。 クラス Grafana.MonitorData はまだ含めていません。それでなければならないという理由があるわけではなかったためですが、要望があれば、含めることは可能です。

難しい点は 2 つだけでした。 1 つは、各ポイントで、現地時間と UTC 時間を確実に調整することでした。 もう 1 つは、Grafana は「.25」のようにゼロを省略した小数点数値を好まないため、JavaScript エラー「t.dataList.map is not a function 」が発生していたことです。

Prometheus は時系列データの収集に適した監視システムです。

このシステムのインストールと初期構成は比較的簡単です。 このシステムにはデータ視覚化用の PromDash と呼ばれる画像サブシステムが組み込まれていますが、開発者は Grafana と呼ばれる無料のサードパーティ製品を使用することを推奨しています。 Prometheus は多くの要素（ハードウェア、コンテナ、さまざまな DBMS の構成要素）を監視できますが、この記事では Caché インスタンス（正確に言えば Ensemble インスタンスですが、メトリックは Caché からのものになります）の監視に注目したいと思います。 ご興味があれば、このまま読み進めてください。

非常に単純なケースでは、Prometheus と Caché は単一のマシン（Fedora Workstation 24 x86_64）上に存在します。 Caché のバージョンは以下のとおりです。

%SYS>write $zv
Cache for UNIX (Red Hat Enterprise Linux for x86-64) 2016.

こんにちは！ この記事は「Prometheus で InterSystems Caché を監視する」の続きになります。 ここでは ^mgstat ツールの動作結果を視覚化する方法を見ていきます。 このツールを使用すると、Caché のパフォーマンス統計、具体的なグローバルとルーチンの呼び出し数（ローカルおよびECP 経由）、書き込みデーモンのキュー長、ディスクに保存されるブロックと読み取られるブロックの数、ECP トラフィックの量などを取得できます。 ^mgstat は（対話的に、またはジョブによって）単独で起動したり、別のパフォーマンス測定ツールである ^pButtons と並行して起動したりできます。

ここでは 2 つのパートに分けて説明したいと思います。最初のパートでは ^mgstat によって収集された統計を図示し、2 番目のパートではこの統計を正確に収集する方法を集中して取り上げます。 手短に言えば、ここでは $zu関数 を使用しています。 ただし、SYS.Stats パッケージのクラス経由で収集できる大部分のパラメーターに対応したオブジェクトインターフェースがあります。 ^mgstat に表示されるのは、収集できるパラメーターのほんの一部です。 その後、Grafana ダッシュボードですべてのパラメーターを表示してみましょう。

Caché 2017以降のSQLエンジンには新しい統計一式が含まれています。 これらの統計は、クエリの実行回数とその実行所要時間を記録します。

これは、多くのSQLステートメントを含むアプリケーションのパフォーマンスを監視する人や最適化を試みる人にとっては宝物のような機能ですが、一部の人々が望むほどデータにアクセスするのは簡単ではありません。

この記事と関連するサンプルコードでは、このような情報の使用方法と、日次統計の概要を定期的に抽出してアプリケーションのSQLパフォーマンス履歴記録を保持する方法について説明します。
※詳細については、下記ドキュメントページもご参考になさってください。

https://docs.intersystems.com/iris20201/csp/docbook/DocBook.UI.Page.cls?KEY=GSQLOPT_sqlstmts

記録内容

SQLステートメントが実行されるたびに、所要時間が記録されます。 この処理は非常に軽量であり、オフにすることはできません。 コストを最小限に抑えるため、統計はメモリに保持されてから定期的にディスクに書き込まれます。 このデータには当日にクエリが実行された回数と、その平均所要時間と合計所要時間が含まれます。

データはすぐにはディスクに書き込まれません。

皆さん、こんにちは。

InterSystems System Alerting and Monitoring (SAM)をご存知でしょうか。InterSystems IRIS 2020.1以降に対応し、IRISやそのアプリケーションの監視を行うソリューションです。といってもシステム監視を行うPrometheus、アラートを管理するAlertManager、ダッシュボードとしてグラフ等を表示させるGrafanaなどを組み合わせたものですが、IRISの利用者に合わせて設定しやすくなっています。

なお、これらのコンポーネントはDockerコンテナを使用しますので、Docker(19.3.098以降)ならびにDocker compose(1.25以降)をインストールいただく必要があります。

IRISの監視APIについてはこちらをご覧ください。

インストール手順

1. アプリケーションのインストール

アプリケーション自体はDockerコンテナにて提供されますので、DockerComposeのファイルやシェルスクリプトを以下のGitHubリポジトリからダウンロードします。
https://github.com/intersystems-community/sam

以下のgzipファイルをダウンロードし、展開します。
sam-1.0.0.XXX-unix.tar.gz

$ tar zpxvf sam-1.0.0.115-unix.tar.gz

本記事について

InterSystems IRISをモニタリングする方法はいくつかあります。

• SNMP
• システムモニターとemail通知機能
• 管理ポータルのシステムダッシュボード
• Prometheus+Grafanaを使用
• InterSystems SAM (System Alerting and Monitoring)

本記事では上記に加えてAWSにIRISをデプロイする場合に自然な選択子となりうる方法として、CloudWatchを使用する方法をご紹介します。

AWSネイティブの各種サービスとIRISを連携させる方法の典型のご紹介を兼ねています。

内容は、Open Exchangeで公開されています。日本語のREADMEがありますのでそちらをご覧ください。
README.MDからの引用

InterSystems IRISの各種メトリクスとログをAWS CloudWatchに簡単に公開することができます。
これらメトリクスとログがあれば、IRISのデータをダッシュボードやアラートなどに統合することができます。

Prometheus+Grafana,SAM,CloudWatchについては、共通点があります。いずれもIRIS 2019.4から利用可能となった監視APIを使用している点です。下記のREST要求を出すだけで、任意のIRISホストの各種メトリクスの取得が出来ます。

IRIS 2019.4以降の製品には、Prometheus形式でIRISのメトリックを公開する/api/monitorサービス機能が実装されています。 IRISのメトリックを監視・警告ソリューションの一部として使用したい人にとっては大きなニュースです。 このAPIは、IRISの次期バージョンでリリースされる予定の新しいIRIS System Alerting and Monitoring (SAM) ソリューションのコンポーネントです。 

ただし、IRISインスタンスを監視するためにSAMがこのAPIの計画と実証実験を開始するのを待つ必要はありません。 今後の投稿では利用可能なメトリックとその意味についてさらに掘り下げ、対話型ダッシュボードの例を示します。 しかし、まずは背景の説明といくつかの質問と回答から始めましょう。 

IRIS（およびCaché）は常に自分自身とその実行プラットフォームに関する数十のメトリックを収集しています。 これらのメトリックを収集し、CachéとIRISを監視する方法は常に複数存在します 。 また、IRISとCachéの組み込みソリューションを使用しているインストール環境はほとんどないことが分かっています。 例えば、History Monitorはパフォーマンスとシステムの使用状況に関するメトリックの履歴データベースとして長い間利用されてきました。

前回の記事では、pButtonsを使って履歴パフォーマンスメトリックを収集する方法を説明しました。 すべてのデータプラットフォームインスタンス（Ensemble、Cachéなど）にはpButtonsがインストールされていることがわかっているため、私はpButtonsを使用する傾向にありますが、 Cachéパフォーマンスメトリックをリアルタイムで収集、処理、表示する方法はほかにもあり、単純な監視や、それよりもさらに重要な、より高度な運用分析とキャパシティプランニングに使用することができます。 データ収集の最も一般的な方法の1つは、SNMP（簡易ネットワーク管理プロトコル）を使用することです。 

SNMPは、Cachéが管理・監視情報をさまざまな管理ツールに提供するための標準的な方法です。 Cachéのオンラインドキュメンテーションには、CachéとSNMP間のインターフェースに関する詳細が説明されています。 SNMPはCachéと「単純に連携」するはずですが、構成にはいくつかの技と罠があります。 私自身、はじめに何度も過ちを繰り返し、InterSystemsの同僚から助けを得ながらCachéをオペレーティングシステムのSNMPマスターエージェントにやっと接続できた経験から、皆さんが同じような困難を避けられるようにこの記事を書くことにしました。

次の手順で、/api/monitor サービスから利用可能なメトリックのサンプル一覧を表示することができます。 

前回の投稿では、IRISのメトリックをPrometheus形式で公開するサービスの概要を説明しました。 この投稿では、コンテナにIRISプレビューリリース2019.4 をセットアップして実行し、メトリックを一覧表示する方法をお伝えします。 

この投稿は、Dockerがインストールされた環境があることを前提としています。 そうでない場合は、今すぐお使いのプラットフォームにインストールしてください :) 

ステップ 1. dockerでIRISプレビューをダウンロードして実行する 

「プレビューの配布」のダウンロード手順に従い、プレビューライセンスキーとIRISのDockerイメージをダウンロードします。 この例では、InterSystems IRIS for Health 2019.4を選択しています。 

「機能紹介：Dockerコンテナ内のInterSystems製品について」の指示に従ってください。 すでにコンテナに精通している場合は、「InterSystems IRISのDockerイメージをダウンロードする」というタイトルのセクションに進んでください。 

次のターミナル出力は、私がDockerイメージの読み込みに使用している手順を示しています。