Jira での監査ログの連携
Jira Data Center は、データベースとログ ファイルに監査ログを書き込みます。これにより、監査ログを長期保存用のデータベースから定期的にエクスポートする手間は不要になります。なお、このファイルの主な目的は、Jira Data Center をサードパーティ製のログ記録プラットフォームと簡単に連携することです。
イベントの対象範囲とログの保存期間
監査ログ設定メニューは、データベースとログ ファイル内の監査ログの範囲を管理します。ただし、このメニューはログ ファイルの保持期間を管理しません。
- ノードの時刻が深夜 12:00 を迎えた場合、または
- 監査ログ ファイルが 100 MB に達した場合
ノードでログ ファイルの保存件数が上限に達すると、最も古いものが削除されます。既定では、ログ ファイル数の上限は 100 件です (現在の監査ログ ファイル + アーカイブ 99 件)。各アプリケーション ノードで、これらのログ ファイルに対して十分なディスク空き容量を割り当てていることを確認してください。既定設定の 100 件のファイルでは、10 GB を割り当てる必要があります。
ログ ファイルの詳細
Jira Data Center は、監査ログをホーム ディレクトリにリアルタイムで書き込みます。これらのログは監査ログ ファイルに書き込まれます。クラスタ化された Jira Data Center デプロイでは、各アプリケーション ノードのログ ファイルがそれぞれのローカル ホーム ディレクトリに作成されます。
場所
監査ログ ファイルをサードパーティ製のログ記録プラットフォームと連携するには、ファイルの正確な場所を把握しておく必要があります。これはホーム ディレクトリの設定方法によって異なる場合があります。ローカル ホーム ディレクトリの詳細についてはこちらをクリックしてください。
クラスタ化された Jira Data Center デプロイでは、通常、監査ログ ファイルのディレクトリはすべてのノードで同じです。
ファイル名
監査ログのファイル名には次のような命名規則が使用されます。
YYYYMMDD-XXXXX.audit.logXXXXX の部分は 00000 から始まる 5 桁の数字で、同じ日 (YYYMMDD) にアーカイブされた監査ログ ファイルの何番目にあたるかを示します。たとえば、本日 (2020 年 1 月 1 日) にアーカイブされたログ ファイルが 5 件ある場合、次のようになります。
- 最も古いアーカイブ ログ ファイルは
20200101.00000.audit.log - 現在の監査ログ ファイルは
20200101.00005.audit.log
形式
それぞれの監査ログは JSON エントリの形式で監査ログ ファイルに書き込まれます。ファイルの各行が 1 つのイベントを表します。必要に応じて正規表現を使用して簡単な検索を行うことができます。
ログ記録エージェントとの連携
大多数のエンタープライズ環境では、サードパーティ製のログ記録プラットフォームを使用して、すべてのホストのログを集計、保存、管理しています。AWS CloudWatch や Splunk などのログ記録プラットフォームはエージェントを使用して、環境内の各ホストのログを収集します。これらのエージェントは各ホストにインストールされ、ローカル ログを収集して、集計、分析、監査、および保存を一元的に行う場所に送信します。
ご利用のログ記録プラットフォームがこのようにエージェントを使用する場合、各ノードにエージェントを構成して監査ログ ファイルを直接監視できます。ほとんどの大手プラットフォームのログ記録エージェント (AWS CloudWatch、Splunk、ELK、Sumo Logic など) には監査ログ ファイルとの互換性があります。
Amazon CloudWatch エージェント
アトラシアンでは、AWS でのデプロイを簡単にするため、Jira Data Center 用のクイックスタートを提供しています。このクイック スタートを使用すると、Jira Data Center と、Jira Data Center を監視する Amazon CloudWatch インスタンスとともにデプロイできます。
Amazon CloudWatch をセットアップするには、Enable CloudWatch Integration パラメーターのデフォルト設定 (つまり Metrics and Logs) を使用します。クイック スタートは次に Amazon CloudWatch エージェントを構成して、各ノードの監査ログ ファイルからログを収集します。エージェントはこれらのログを jira-software-<aws-stack-name>-audit という名前の独立したログ グループに送信します。
また、クイック スタートは、既定のダッシュボードをセットアップして、各監査ログ ファイルからのログを含む収集されたデータを読み取りやすい形式で表示します。関連情報については、「ログ グループとログ ストリームを操作する」をご参照ください。
Splunk Universal Forwarder
Splunk Enterprise または Splunk Cloud では Splunk Universal Forwarder をログ記録エージェントとして使用できます。これを行うには、各アプリケーション ノードに Universal Forwarder ををインストールする必要があります。
また、各ノードの監査ログ ディレクトリをいずれかのフォワーダーの入力として定義する必要もあります。これにより、フォワーダーは監査ログ ディレクトリからのすべてのログを、設定済みのレシーバーに送信するように設定されます。フォワーダーの入力を定義する 1 つの方法は、Splunk の CLI を使用することです。Linux システムの場合、各アプリケーション ノードで次のコマンドを使用します。
./splunk add monitor <local home directory>/log/audit/ |
各ノードで Splunk Universal Forwarder を構成する方法の詳細については、以下のリンクをご参照ください。
Splunk でのソース・タイプの設定
ソース タイプは、Splunk インデクサーがデータを解析する方法を定義します。 これには、データをイベントに分離する方法、イベントを解析する方法、イベントからタイムスタンプを抽出する方法が含まれます。
Splunk で監査ログを正しく解釈するには、インデクサーに アトラシアン監査ログ用の新しいソース タイプを追加し、設定したフォワーダーに送信データにそのソース タイプでタグを付けるように指示する必要があります。
次のプロパティを持つ atlassian-audit という名前のソース タイプを作成する必要があります。
|
その方法の詳細については、「 Splunk でソース タイプを作成する方法」を参照してください。
ソース タイプを作成したら、送信データに新しいソース タイプのラベルを付けるようにフォワーダーを設定する必要があります。 これを行うには、inputs.conf ファイルで設定したモニターに sourcetype プロパティを追加します。 例えば：
|
詳細については、次のリンクを参照してください。
Filebeat (ELK Stack 用)
ELK Stack 内で Filebeat プラグインを使用して、各ノードの監査ログ ファイルからログを収集できます。現在の監査ログ ファイルにログが書き込まれるたびに、Filebeat がそのログを Elasticsearch または Logstash に転送します。
これをセットアップするには、まず、各アプリケーション ノードに Filebeat をインストールします。次に、監査ログ ファイル ディレクトリを Filebeat の入力として設定します。これを実行するには、そのディレクトリを各ノードの filebeat.yml 構成ファイルの filebeat.inputs セクションに path として追加します。たとえば、次のようになります。
|
Sumo Logic の Installed Collector
Sumo Logic インスタンスをお持ちの場合、Installed Collector を使用して、各ノードの監査ログ ファイルのログを収集できます。これを実行するには、まず、各ノードに Collector をインストールします。次に、<local home directory>/log/audit/* を Local File ソースとして各ノードのコレクタに追加します。