Audit log integrations
Bitbucket Data Center writes audit logs to the database and a log file. By itself, the log file saves you the effort of periodically exporting your audit logs from the database for long-term storage. However, the main purpose of the file is to easily integrate Bitbucket to a third-party logging platform.
Selecting which events to log and adjusting data retention
The Audit log settings menu controls the coverage of audit logs in both database and log file.
- ノードの時刻が深夜 12:00 を迎えた場合、または
- 監査ログ ファイルが 100 MB に達した場合
ノードでログ ファイルの保存件数が上限に達すると、最も古いものが削除されます。既定では、ログ ファイル数の上限は 100 件です (現在の監査ログ ファイル + アーカイブ 99 件)。各アプリケーション ノードで、これらのログ ファイルに対して十分なディスク空き容量を割り当てていることを確認してください。既定設定の 100 件のファイルでは、10 GB を割り当てる必要があります。
To customize the log rotation rules (and, ultimately, the retention rules), use the following bitbucket.properties file parameters:
com.atlassian.audit.file.max.file.sizecontrols the maximum size (in MB) for the current audit log file before it is archived.com.atlassian.audit.file.max.file.countcontrols the maximum number of audit log files (counting the current audit log file and all archived log files).
Both default to 100. If you adjust either of these values, make sure you allocate the right amount of space on each application node. For example, if you set com.atlassian.audit.file.max.file.count=150, you should allocate at least 15GB just for log files on each application node.
For more information on using the bitbucket.properties file, click here.
ログ ファイルの詳細
On clustered Bitbucket Data Center deployments, each application node will produce its own log file in its local home directory.
場所
監査ログ ファイルをサードパーティ製のログ記録プラットフォームと連携するには、ファイルの正確な場所を把握しておく必要があります。これはホーム ディレクトリの設定方法によって異なる場合があります。ローカル ホーム ディレクトリの詳細についてはこちらをクリックしてください。
On a clustered Bitbucket Data Center deployment, the audit log file's directory should be the same on all nodes.
ファイル名
監査ログのファイル名には次のような命名規則が使用されます。
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 エージェント
We provide Quick Starts for Bitbucket Data Center for easy deployments on AWS. This Quick Start lets you deploy Bitbucket Data Center along with an Amazon CloudWatch instance to monitor it.
To set up Amazon CloudWatch, use the Enable CloudWatch Integration parameter's default setting (namely, Metrics and Logs). The Quick Start will then configure the Amazon CloudWatch Agent to collect the logs from each node's audit log files. The agent will send these logs to a separate log group named bitbucket-<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 ソースとして各ノードのコレクタに追加します。
Deprecated audit log file format
Previous Bitbucket releases also generated an audit log file, but this file used a different format. This format is now deprecated. If you require logs generated in this format, you can configure Bitbucket to generate the legacy format alongside the current one. However, we recommend that you use the current audit log file. The legacy format was removed in Bitbucket 8.0.
The legacy audit log file will have the same set of defaults and settings as Bitbucket releases before 7.0, such as:
The file will rotate at 25 MB.
There will be a 100-file limit to the number of legacy audit log files that Bitbucket keeps. When the limit is reached, the oldest file is deleted each day.
To enable the legacy audit log file, set audit.legacy.log=true in the bitbucket.properties file. For more information on using this file, click here.