ja:documentation:pandorafms:monitoring:09_log_monitoring

ログの監視と収集

Versión Enterprise.Log monitoring in Pandora FMS is approached in two different ways:

Enterprise 版Pandora FMS におけるログ監視には、以下の 2つの異なる手法があります。

  1. モジュールベース: 非同期監視としの Pandora でログを表現します。ユーザにより事前設定された条件を満たすデータを検出した場合にアラートを関連付けることができます。 ログのモジュール表現では、以下を行うことができます:
    1. ログの中で正規表現にマッチする数を数えるモジュールの作成
    2. ログメッセージの行および内容を取得
  2. 複合表示ベース: キャプチャしたい複数の発生元のログからすべての情報を 1つのコンソールで表示し、ログが処理されたタイムスタンプを使用して情報を順番に整理できます。

From version 7.0 NG 712, Pandora FMS incorporates Elasticsearch to store log information, which implies a significative performance improvement.

バージョン 7.0NG 712 からは、Pandora FMS に、ログ情報を保存するための Elasticsearch が組み込まれているため、パフォーマンスが大幅に向上しています。

処理は単純です。

  • The logs analyzed by the software agents (eventlog or text files) are forwarded to Pandora Server in RAW form within the XML reporting agent:
  • Pandora FMS data server receives the XML agent, which contains information about both monitoring and logs.
  • When the DataServer processes XML data, it identifies log information, keeping in the primary database the references about the agent that was reported and the source of the log, automatically sending information to ElasticSearch in order to be stored.
  • Pandora FMS stores the data in Elasticsearch indexes generating a daily index for each Pandora FMS instance.
  • Pandora FMS server has a maintenance task that deletes indexes in the interval defined by the system admin (90 days by default).
  • ソフトウエアエージェントで分析されたログ (eventlog またはテキストファイル) は、Pandora サーバへ転送されます。エージェントから送信される XML に (RAW) データとして含まれます。
  • Pandora FMS データサーバは、エージェントから XML を受け取ります。そこには、監視とログの両方の情報が含まれています。
  • データサーバが XML データを処理する時に、ログ情報を識別し、報告されたエージェントに関する情報やログのソースをプライマリデータベースに保存し、ログの保存には情報を自動的に ElasticSearch に送信します。
  • Pandora FMS はデータを Elasticsearch インデックスに保存し、各 Pandora FMS インスタンスの日次インデックスを生成します。
  • Pandora FMS サーバには、システム管理者が定義した間隔(デフォルトでは90日)でインデックスを削除するメンテナンスタスクがあります。

It is recommended to distribute Pandora, FMS Server and Elasticsearch in independent servers.

Pandora FMS サーバと Elasticsearch は別々のサーバに展開することをお勧めします。

  • Rocky Linux 8 or RHEL 8.
  • At least 4 GB of RAM, although 6 GB of RAM are recommended for each Elasticsearch instance.
  • Disable SWAP on the node(s) where Elasticsearch is located.
  • At least 2 CPU cores.
  • At least 20 GB of disk space for the system.
  • At least 50GB of disk space for Elasticsearch data (the amount can be different depending on the amount of data to be stored). Elasticsearch disk usage is very intensive, so the faster the read and write speed, the better the performance of the environment.
  • Connectivity from Pandora FMS server to Elasticsearch API (port 9200/TCP by default).
  • Rocky Linux 8 または RHEL 8。
  • 最低 4GB のメモリ、ただし ElasticSearch インスタンスでは、6GB のメモリを推奨します。
  • Elastic が動作するサーバでの SWAP の無効化。
  • 最低 2 CPUコア。
  • 最低 20GB のシステムディスク空き領域。
  • 最低 50GB の ElasticSearch データディスク空き領域(保存されるデータの量に応じて、異なる場合があります)。 Elasticsearch のディスク使用量は非常に多いため、読み取りと書き込みの速度が速いほど、環境のパフォーマンスが向上します
  • Pandora FMS サーバから、Elasticsearch API (デフォルトポートは 9200/TCP) への接続性。

With a single node environment with these characteristics, up to 1 GB of data can be stored daily and stored for the default time of 8 days.

上記の最低条件のシングルノード環境では、毎日最大 1 GB のデータを保存し、デフォルトで 8日間保存できます。

In the case of requiring greater data resilience and fault tolerance, it will be necessary to configure an Elasticsearch cluster (minimum 3 nodes to guarantee data integrity). When moving to a cluster environment it is also possible to distribute the load among the nodes, doubling (in the case of 3 nodes) the processing capacity of the environment. A load balancing system will be necessary if you want to attack with the different nodes simultaneously.

より高いデータ復元力とフォールトトレランスが必要な場合は、Elasticsearch クラスターを構成する必要があります(データの整合性を保証するために最低 3つのノード)。 クラスタ環境に移行する場合、ノード間で負荷を分散し、環境の処理能力を 2倍(3ノードの場合)にすることもできます。 異なるノードで同時に処理したい場合は負荷分散システムが必要になります

Elasticsearch official documentation:

Elasticsearch の公式ドキュメントは以下にあります。

For Rocky Linux 8 it is recommended to install using the RPM package, it is a single package that contains everything needed to install the Elasticsearch database.

Rocky Linux 8 の場合、RPM パッケージを使用してインストールすることをお勧めします。これは、Elasticsearch データベースのインストールに必要なものすべてを含んだ単一のパッケージです。

For download go to https://www.elastic.co/downloads/elasticsearch and select Linux x86_64 ( AMD® or Intel® 64 bits processors).

ダウンロードには、https://www.elastic.co/downloads/elasticsearch へ行き、Linux x86_64 ( AMD® または Intel® 64 ビットプロセッサ) を選択します。

Once you have downloaded the package, you must upload it to the server where you will install Eleasticsearch, go to that directory and run with sufficient rights:

パッケージをダウンロードしたら、Eleasticsearch をインストールするサーバにアップロードし、そのディレクトリに移動して、必要な権限を持ったユーザで次のように実行します。

dnf install ./downloaded_packet.rpm

You will get an output similar to:

次のような出力が表示されます。

To verify that the service was installed correctly you can run the command:

サービスが正しくインストールされたことを確認するには、次のコマンドを実行します。

systemctl status elasticsearch.service

You will get an output similar to:

次のような出力が表示されます。

Note that the Elasticsearch service is inactive.

Elasticsearch サービスが無効になっていることに注意してください。


You must first edit the configuration file
/etc/elasticsearch/elasticsearch.yml
and then start the Elasticsearch service.


最初に、設定ファイル /etc/elasticsearch/elasticsearch.yml を編集し、Elasticsearch サービスを起動する必要があります。

This file contains the configuration of all the parameters of the Elasticsearch service, see the official documentation for more information:

このファイルには、Elasticsearch サービスのすべてのパラメータ設定が含まれています。詳細については、公式ドキュメントを参照してください。

Next, the minimum configurations required to start the service and its use with Pandora FMS will be described.

次に、サービスを開始するために必要最小限の設定と、Pandora FMS での使用について説明します。

  • Set the port number, data location and location of the event log file:
  • ポート番号、データの場所、イベントログファイルの場所を設定します:
 # ---------------------------------- Network -----------------------------------
 # Set a custom port for HTTP:
 http.port: 9200
 # ----------------------------------- Paths ------------------------------------
 # Path to directory where to store the data (separate multiple locations by a comma):
 path.data: /var/lib/elastic
 # Path to log files:
 path.logs: /var/log/elastic
  • Configure xpack:
  • xpack を設定します:
xpack.security.enabled: false
xpack.security.enrollment.enabled: false

#http.host: [_local_]
#transport.host: [_local_]

It will also be necessary uncomment and define the following lines:

また、以下の行の コメントを外し、次のように定義する必要があります。

cluster.name: pandorafms
node.name: ${HOSTNAME}
network.host: 0.0.0.0

cluster.name

This will be the name of the group or cluster.

これは、グループまたはクラスタの名前です。

node.name

To name the node using the ${HOSTNAME} system variable, it will automatically take the name of the host.

システムの環境変数 ${HOSTNAME} を使っているので、ホスト名が自動的に利用されます。

network.host

For network.host value 0.0.0.0 let Elasticsearch “hear” in all Network Interface Card (NIC), set a specific value for use a specifis NIC.

network.host0.0.0.0 を指定すると Elasticsearch は全ネットワークインタフェース(NIC)で待ち受けます。特定の NIC を指定する場合は、特定の値を指定します。

In case of working with a cluster you need to complete the discovery.seed_hosts (see “Configuring a cluster of Elasticsearch servers” for more information):

クラスターを使用する場合は、discovery.seed_hosts を設定する必要があります(詳細については、 Elasticsearch サーバのクラスターの構成 を参照してください):

discover.seed_hosts : ["ip:port", "ip", "ip"]

Or (format example):

または(フォーマット例):

 discovery.seed_hosts:
  - 192.168.1.10:9300
  - 192.168.1.11
  - seeds.mydomain.com


In the most recent versions of Elasticsearch the memory management of the Java® virtual machine is done automatically and it is recommended to let it be managed this way in production environments, so it is unnecessary to modify the values of the Elasticsearch JVM.


Elasticsearch の最新バージョンでは、Java® 仮想マシンのメモリ管理は自動的に行われるため、本番環境ではこれを利用することをお勧めします。したがって、Elasticsearch の JVM の値を変更する必要はありません

Once finished, it will be necessary to execute:

完了したら、以下を実行します:

systemctl start elasticsearch.service

Wait a few moments while Elasticsearch starts, be patient. The command to query the status is:

Elasticsearch が起動するまでしばらくお待ちください。ステータスを照会するコマンドは次のとおりです。

systemctl status elasticsearch.service

You will see something similar to this:

次のような出力が見られます。

If the service fails to start, check the logs located in /var/log/elastic/ (in this case the file pandorafms.log or the name given to the node).

サービスの開始に失敗した場合は、/var/log/elastic/ にあるログ(この場合はファイル pandorafms.log またはノードに付けられた名前)を確認してください。

To test the installation of Elasticsearch run the following command in a terminal window:

Elasticsearch のインストールをテストするには、ターミナルウィンドウで次のコマンドを実行します。

curl -q http://{IP}:9200/

Replace {IP} with the IP address or URL of the installed Elasticsearch.

{IP} をインストールされている Elasticsearch の IP アドレスまたは URL に置き換えます。

You will receive a response similar to the following:

次のような応答が得られます。

{
  "name" : "3743885b95f9",
  "cluster_name" : "docker-cluster",
  "cluster_uuid" : "7oJV9hXqRwOIZVPBRbWIYw",
  "version" : {
    "number" : "7.6.2",
    "build_flavor" : "default",
    "build_type" : "docker",
    "build_hash" : "ef48eb35cf30adf4db14086e8aabd07ef6fb113f",
    "build_date" : "2020-03-26T06:34:37.794943Z",
    "build_snapshot" : false,
    "lucene_version" : "8.4.0",
    "minimum_wire_compatibility_version" : "6.8.0",
    "minimum_index_compatibility_version" : "6.0.0-beta1"
  },
  "tagline" : "You Know, for Search"
}

It is recommended to visit the Elasticsearch best practices link for production environments:

本番環境に向けては、Elasticsearch のベストプラクティスを参照することをお勧めします。

Elasticsearch クラスタ設定

  • The minimum size of an Elasticsearch cluster is 3 nodes and it must always grow in odd numbers in order to make use of the quorum system and guarantee data integrity.
  • Ensure that you have connectivity between all 3 nodes and that ports 9200 and 9300 are accessible between each and every node.
  • Elasticsearch クラスターの最小サイズは 3ノードであり、quorum システムを利用してデータの整合性を保証するには、常に奇数で増やす必要があります。
  • 3つのノードすべての間で通信が可能であり、各ノード間でポート 9200 および 9300 へアクセスできることを確認してください。

Remember to configure the firewall of each node to allow connection through these port numbers.

これらのポート番号を介した接続を許可するように、各ノードのファイアウォールの設定を忘れないでください。

Stop the Elasticsearch service on each and every node:

全ノードの Elasticsearch サービスを停止します。

systemctl stop elasticsearch.service

Modify the following lines in the configuration file /etc/elasticsearch/elasticsearch.yml :

設定ファイル /etc/elasticsearch/elasticsearch.yml の以下の行を編集します。

#discovery.seed_hosts: ["host1", "host2"]
#cluster.initial_master_nodes: ["host1", "host2"]

Uncommentthe lines and add the IP addresses or URLs of each node:

該当行を コメントアウト し、各ノードの IP アドレスまたは URL を追加します。

discovery.seed_hosts: ["host1", "host2", "host3"]
cluster.initial_master_nodes: ["host1", "host2", "host3"]

Example with IP addresses:

IP アドレスでの例:

discovery.seed_hosts: ["172.42.42.101", "172.42.42.102", "172.42.42.103"]
cluster.initial_master_nodes: ["172.42.42.101", "172.42.42.102", "172.42.42.103"]

Make sure that the line cluster.initial_master_nodes is defined only once in the configuration file, in some cases the same line appears in two different blocks of the same file.

cluster.initial_master_nodes の行は設定ファイル内で 1回のみ定義されていることを確認してください。場合によっては、同じ行が同じファイルの異なる 2つの場所に表示されます。

Before starting the service, because the nodes were started for the first time on their own (standalone), the contents of the data folder (by default /var/lib/elasticsearch/) must be deleted in order to start the cluster for the first time. Do this with the command:

ノードは初回に単独で(スタンドアロンで)開始されたため、サービスを開始する前にデータフォルダーの内容(デフォルトでは /var/lib/elasticsearch/)を削除する必要があります。 次のコマンドを実行します。

rm -rf /var/lib/elasticsearch/*

Now it is time to start the services on each and every node. Start and check that they are running with the commands:

次に、すべてのノードでサービスを開始します。 次のコマンドで開始し、実行されていることを確認します。

systemctl start elasticsearch.service && systemctl status elasticsearch.service

You should get an output similar to:

次のような出力を得られます。

Once the services have been started, you must confirm that the 3 nodes are joined to the cluster correctly, so when executing the following command on any of the nodes, the same response should be given:

サービスが開始されたら、3つのノードがクラスターに正しく参加していることを確認する必要があります。任意のノードで次のコマンドを実行すると、同じ応答が返されます。

curl -XGET http://127.0.0.1:9200/_cat/nodes

Check again the firewall configuration always taking into account that the nodes should communicate through ports 9200 and 9300 and that from the PFMS server and the PFMS Web Console should be able to access port 9200 as well. With these steps you will have already installed and configured the Elasticsearch cluster to be used as Pandora FMS log storage engine.

ノードがポート 9200 および 9300 を介して通信する必要があることに加えて、Pandora FMS サーバおよび Pandora FMS Web コンソールからポート 9200 へアクセスできる必要があることを常に考慮してファイアウォールの設定を再度確認してください。ここまでの設定により、Pandora FMS ログストレージエンジンとして使用される Elasticsearch クラスターの準備が完了です。

Before putting into production an environment, either a single node or a data cluster, it is recommended to apply the corresponding configurations to this node or cluster according to its use. In the case of the indexes generated by Pandora FMS, the most effective way to do it is defining a template to define the configuration of the fields and the stored data.

本番環境に導入する前に、用途に応じて、単一ノードまたはデータクラスターのいずれかの環境に応じて対応する設定をあらかじめ実施することをお勧めします。 Pandora FMS によって生成されるインデックスの場合、それを行う最も簡単な方法は、フィールドと保存するデータの設定を定義するためのテンプレートを定義することです。

テンプレートは、インデックス作成時にのみ適用される設定です。テンプレートを変更しても、既存のインデックスには影響しません。

基本テンプレート を作成するには、フィールドを定義するだけです。

 {
  "index_patterns": ["pandorafms*"],
  "settings": {
    "number_of_shards": 1,
    "auto_expand_replicas" : "0-1",
    "number_of_replicas" : "0"
  },
 "mappings" : {
      "properties" : {
        "agent_id" : {
          "type" : "long",
          "fields" : {
            "keyword" : {
              "type" : "keyword",
              "ignore_above" : 256
            }
          }
        },
        "group_id" : {
          "type" : "long",
          "fields" : {
            "keyword" : {
              "type" : "keyword",
              "ignore_above" : 256
            }
          }
        },
        "group_name" : {
          "type" : "text",
          "fields" : {
            "keyword" : {
              "type" : "keyword",
              "ignore_above" : 256
            }
          }
        },
        "logcontent" : {
          "type" : "text",
          "fields" : {
            "keyword" : {
              "type" : "keyword",
              "ignore_above" : 256
            }
          }
        },
        "source_id" : {
          "type" : "text",
          "fields" : {
            "keyword" : {
              "type" : "keyword",
              "ignore_above" : 256
            }
          }
        },
        "suid" : {
          "type" : "text",
          "fields" : {
            "keyword" : {
              "type" : "keyword",
              "ignore_above" : 256
            }
          }
        },
        "type" : {
          "type" : "text",
          "fields" : {
            "keyword" : {
              "type" : "keyword",
              "ignore_above" : 256
            }
          }
        },
        "utimestamp" : {
          "type" : "long"
        }
      }
    }
  }
 }

Through the Elasticsearch interface in Pandora FMS (Admin toolsElasticsearch Interface) and using the native Elasticsearch command you can upload such template.

Pandora FMS の Elasticsearch インターフェース(管理ツール(Admin tools) Elasticsearch インターフェース(Elasticsearch Interface))を介して、ネイティブの Elasticsearch コマンドを使用し、テンプレートをアップロードできます。

We can perform these operations through the Elastic Search interface in Pandora FMS using the native Elastics Search commands.

これらの操作は、ネイティブの ElasticsSearch コマンドを使用してPandora FMS の ElasticSearch インターフェイスから実行できます。

  • PUT _template/<template_name>: for this example PUT _template/pandorafms .
  • PUT _template/<template_name>: この例では PUT _template/pandorafms

You will also be able to consult the templates through the same Pandora FMS interface:

同じ Pandora FMS インターフェースを介してテンプレートを参照することもできます。

  • GET _template/<template_name>: for this example GET _template/pandorafms .
  • GET _template/<template_name>: この例では GET _template/pandorafms

To define a multinode template you must take into account the following information:

マルチノードテンプレートを定義するには、考慮しなければならないことがいくつかあります。

  • When configuring the template (JSON format), you need to configure as many searches as you have nodes, however to correctly configure the replicas you must subtract 1 from the number of nodes in the environment.
  • テンプレート(JSON)の設定を行うときは、ノードと同じ数の検索を設定する ことを考慮に入れる必要がありますが、正しく設定するには、環境に実際に存在する レプリカの数から 1を引く 必要があります。

For example, in a Pandora FMS environment with Elasticsearch with 3 configured nodes, when you modify the number_of_search and number_of_replicas fields it should look like this:

例えば、3つのノードを設定した Elasticsearch を Pandora FMS 環境で使用する場合、number_of_search および number_of_replicas フィールドを次のように変更します。

{
 "index_patterns": ["pandorafms*"],
 "settings": {
   "number_of_shards": 3,
   "auto_expand_replicas" : "0-1",
   "number_of_replicas" : "2"
 },


This is a very basic definition, in order to correctly define the sizing of the Elasticsearch environment it is advisable to take into account the factors described in this article:


これは非常に基本的な定義です。Elasticsearch 環境のサイズを正しく定義するには、以下で説明されている要素を考慮に入れることをお勧めします。

From the command line you can list the templates of the environment by executing:

コマンドラインから以下を実行して環境のテンプレートを一覧表示できます。

curl -X GET "localhost:9200/_cat/templates/*?v=true&s=name&pretty"

You can also view the details of a template, for example the one we have created for pandorafms by running it:

テンプレートの詳細を表示することもできます。たとえば、以下を実行すると pandorafms 用に作成したテンプレートを表示できます。

curl -X GET "localhost:9200/_template/pandorafms*?pretty"

which will return in JSON format the configuration you have defined.

定義した設定を JSON 形式で返します。

You can perform these operations through the Elasticsearch interface in Pandora FMS using the native Elasticsearch commands.

これらの操作は、ネイティブの Elasticsearch コマンドを使用して、Pandora FMS の Elasticsearch インターフェースから実行できます。

  • PUT _template/<template_name> {json_data}: allows you to enter the data of the template to be created.
  • GET _template/><template_name>: allows you to display the created template.
  • PUT _template/<template_name> {json_data}: 作成するテンプレートのデータを入力できます。
  • GET _template/<template_name>: 作成したテンプレートを表示できます。

Elasticsearch のログローテーション

重要: Elasticsearch のログが肥大化しないように、/etc/logrotate.d でログローテーションのエントリーを作成することをお勧めします。

 cat > /etc/logrotate.d/elastic <<EOF
 /var/log/elastic/elaticsearch.log {
        weekly
        missingok
        size 300000
        rotate 3
        maxage 90
        compress
        notifempty
        copytruncate
 }
 EOF

インデックスの削除

You may check at any time the list of indexes and their size by launching a cURL petition against its ElasticSearch server:

ElasticSearch サーバに対して curl でアクセスすることにより、いつでもインデックスの一覧と大きさを確認することができます。

curl -q http://elastic:9200/_cat/indices?

ここで、elastic はサーバの IP です。

インデックスを削除するには、DELETE コマンドを実行します。

curl -q -XDELETE http://elastic:9200/{index-name}

ここで elastic はサーバの IP で、“{index-name}” は上のコマンドの出力ファイルです。これにより、削除されたインデックスによって使用されていたスペースが解放されます。

Enterprise 版バージョン NG 717 以上

This component allows Pandora FMS to analyze the Syslog of the machine where it is located, analyzing its content and storing the references in the Elasticsearch server.

このコンポーネントにより、Pandora はマシンの Syslog を分析できます。Syslog のコンテンツを分析し、ElasticSearch サーバに格納することができます。

SyslogServer の主な利点としては、ログの統合を補完することにあります。Linux および UNIX 環境の SYSLOG 出力をもとにして、SyslogServer では、1つの共通ポイント(Pandora FMS コンソールのログビューア)で、発信元ごとに個別のログを参照したり、検索したりすることができます。

Syslog のインストールは、クライアントとサーバの両方に次のコマンドで行います。

yum install rsyslog

対象のコンピューターに Syslog をインストールしたら、設定ファイル /etc/rsyslog.conf を編集して TCP および UDP 接続を有効にする必要があることに注意してください。

 (...)
 
 # Provides UDP syslog reception
 $ModLoad imudp
 $UDPServerRun 514
 
 # Provides TCP syslog reception
 $ModLoad imtcp
 $InputTCPServerRun 514
 
 (...)

調整を行ったら、rsyslog サービスを再起動します。

サービスが再起動したら、ポート 514 が開いているか確認します。

netstat -ltnp

rsyslog 設定に関する詳細は、公式サイト を参照してください。

Syslog サーバにログを送信するようにクライアントを設定します。そのためには、/etc/rsyslog.conf にあるクライアント rsyslog 設定ファイルにて、リモートホストの設定をする行を見つけて有効にします。

.* @@remote-host:514

ログ送信により、クライアント名を持つコンテナエージェントが生成されるため、エージェントの重複を回避するために、クライアントのホスト名と一致する “別名” を持つエージェントを作成することをお勧めします。

この機能を有効化するには、pandora_server.conf で以下の設定を有効にするだけです。

 # Enable (1) or disable (0) the Pandora FMS Syslog Server
 #  (PANDORA FMS ENTERPRISE ONLY).
 syslogserver 1
 
 # Full path to syslog's output file (PANDORA FMS ENTERPRISE ONLY).
 syslog_file /var/log/messages
 
 # Number of threads for the Syslog Server
 #  (PANDORA FMS ENTERPRISE ONLY).
 syslog_threads 2
 
 # Maximum number of lines queued by the Syslog Server's 
 #   producer on each run (PANDORA FMS ENTERPRISE ONLY).
 syslog_max 65535

syslogserver

ローカルの SYSLOG 分析エンジンの有効化(1)または無効化(0)を設定します。

syslog_file

SYSLOG ファイルの場所です。

syslog_threads

SyslogServer のデータ処理に使う最大スレッド数です。

syslog_max

SyslogServer が処理する最大ウインドウサイズです。一度の実行で処理する最大の SYSLOG エントリー数です。

It is the maximum processing window for SyslogServer, it will be the maximum number of SYSLOG entries that will be processed in each iteration.

これは SyslogServer の最大処理ウィンドウであり、一度に処理される SYSLOG エントリの最大数になります。

You will need an ElasticSearch server enabled and configured; please review the preceding points for how to work with it.

ElasticSearch サーバを有効化し設定する必要があります。使用方法については、前述の内容を確認してください。

Remember: It is necessary to modify the configuration of your device so that logs are sent to Pandora FMS server.

ログが Pandora FMS サーバに送信されるように、デバイスの設定を変更する必要があります。


Version 712 or earlier. You will then need to upgrade to the current version, see “PFMS Upgrade” for more information.


バージョン 712 またはそれ以前。最新のバージョンにアップグレードする必要があります。詳細については、Pandora FMS アップグレード を参照してください。

ログの新たなストレージシステムを設定後、以前から Pandora に保存されているデータを新たなシステムへマイグレートできます。

新たなシステムへマイグレートするには、/usr/share/pandora_server/util/ 以下にある次のスクリプトを実行します。

 # 7.0NG 712 より前のログデータを、7.0NG 712 以降にマイグレート
 /usr/share/pandora_server/util/pandora_migrate_logs.pl /etc/pandora/pandora_server.conf

To enable the log system display, enable the following configuration (SetupSetupEnterprise):

ログの表示を有効化するには、次の設定を有効化する必要があります。(セットアップ(Setup)セットアップ(Setup)Enterprise)

Then set the log viewer performance in the SetupSetupLog Collector:

セットアップ(Setup)セットアップ(Setup)ログ収集(Log Collector) タブで、ログビューワの動作を設定できます。

この画面では以下の設定ができます。

  • Elasticsearch サーバの IP または FQDN アドレス
  • Elasticsearch サービスのポート
  • 表示されるログの数(Number of logs being shown):コンソール応答の高速化のため、レコードの動的読み込みが追加されています。これを利用するには、ページの一番下へスクロールします。すると、次のレコードが読み込まれます。これらのグループのサイズは、グループあたりのレコード数としてこのフィールドに設定できます。
  • 削除する日数(Days to purge): システムのサイズを保持するために、ログ情報を保存する最大日数を定義できます。それを超えると、Pandora FMS のクリーニング処理により自動的に削除されます。

Enterprise 版バージョン NG 747 以上

デフォルトの設定では、Pandora は 1日あたりのインデックスを生成します。これは、何かを検索する際のフラグメント化の役割を持ちます。検索時に Elastic がフラグメントの場所を認識できるようにします。

この検索をデフォルトで最適化するには、Elastics が検索ごとにインデックスを生成し、Elastics ノードと同じ数の検索を環境内で設定する必要があります

これらの検索とレプリカは、Pandora が自動的に生成するインデックスの作成時に設定されるため、この設定を変更するには、テンプレートを使用する必要があります。

A data snapshot (indexes) is the mechanism that recent versions of Elastichsearch use to back up data. These snapshots can be used to recover data after a hardware failure, to transfer data between nodes, and even to remove rarely used indexes from the node(s) (the latter requires additional configuration).

データスナップショット(インデックス)は、Elastichsearch の最近のバージョンにおいてデータをバックアップするために使用するメカニズムです。 これらのスナップショットを使用して、ハードウェア障害後にデータを回復したり、ノード間でデータを転送したり、ノードからめったに使用されないインデックスを削除したりすることもできます(後者には追加の構成が必要です)。

These snapshots work by backing up data incrementally, i.e. they copy only the new data that has not been backed up while ensuring that the backups already made are reliable and compatible between different versions of Elasticsearch.

これらのスナップショットは、データを段階的にバックアップすることで機能します。つまり、バックアップされていない新しいデータのみをコピーし、作成済みのバックアップの信頼性と Elasticsearch の異なるバージョン間の互換性を確保します。


For Elasticsearch the way to guarantee all these features is through repositories.


Elasticsearch で、これらすべての機能を保証する方法はリポジトリを使用することです。

The repositories can be your own or made by third parties (AWS S3®, Google Cloud Storage®, Microsoft Azure®) and in any case must be physically outside the node or nodes that you use in conjunction with Pandora FMS. You are solely responsible for these snapshots.

リポジトリは独自のものでも、サードパーティ(AWS S3®、Google Cloud Storage®、Microsoft Azure®)で作成することもできます。いずれの場合も、Pandora FMS と組み合わせて使用する 1つまたは複数のノードの外に物理的に配置する必要があります。 これらのスナップショットについては、ユーザ自身の責任の元での管理となります

See the official Elasticsearch documentation for more information:

詳細については、Elasticsearch の公式ドキュメントを参照してください。

A network file system (NFS) or other shared filesystem must be available from the machine(s) that will host the Elasticsearch repository and the node(s) in the environment.

ネットワークファイルシステム(NFS)またはその他の共有ファイルシステムは、環境内で Elasticsearch リポジトリとノードをホストするマシンから利用可能である必要があります。

Pandora FMS independently also uses NFS to share the exchange directory between several servers: refrain from using this NFS to host Elasticsearch repository(s). You are solely responsible for properly configuring each of the components of your system.

複数のサーバ間でのディレクトリの共有: このNFS を使用して Elasticsearch リポジトリを提供することは控えてください。 システムの各コンポーネントを適切に責任はユーザにあります。

Once you have installed and configured the target NFS, proceed to create and mount a directory on the Elastisearch node(s), for example it can be called:

対象の NFS をインストールして設定したら、Elastisearch ノードにディレクトリを作成してマウントします。たとえば、次のように呼び出すことができます。

/mnt/pandorafms/elk_repo

Grant permissions for the user elasticsearch:

ユーザー elasticsearch に権限を付与します。

chown elasticsearch:  /mnt/pandorafms/elk_repo

You must declare this path in the Elasticsearch configuration file as the repository path on the node(s) (all nodes):

Elasticsearch 設定ファイルでこのパスをノード(すべてのノード)のリポジトリパスとして宣言する必要があります。

path:
  repo:
   - /mnt/pandorafms/elk_repo

When you have configured the node(s) you must restart the elasticsearch service (on all nodes):

ノードを設定したら、(すべてのノードで) elasticsearch サービスを再起動する必要があります。

systemctl start elasticsearch.service && systemctl status elasticsearch.service

Apart from the Elasticsearch interface in Pandora FMS you can also use the curl command to get information or communicate orders to the Elastisearch node or nodes. To create the repository execute locally in the node or nodes (all nodes) the following command:

Pandora FMS の Elasticsearch インターフェース とは別に、curl コマンドを使用して、情報を取得したり、Elastisearch ノードに要求を伝達したりすることもできます。 リポジトリを作成するには、1つまたは複数のノード(すべてのノード)でローカルに次のコマンドを実行します。

curl -X PUT "localhost:9200/_snapshot/backup_repo?pretty" -H 'Content-Type: application/json' -d'
{
 "type": "fs",
 "settings": {
   "location": "/mnt/pandorafms/elk_repo/"
 }
}
'

If you use a port other than 9200, replace it with that value.

9200 以外のポートを利用する場合は、その値を置き換えます。

You should get the following message from the node(s):

ノードから次のようなメッセージが得られます。

"acknowledged" : true

This will indicate that the repository has been created. To check the status of the repository:

これは、リポジトリが作成されたことを示します。 リポジトリのステータスを確認するには次のようにします。

curl -X POST "localhost:9200/_snapshot/my_unverified_backup/_verify?pretty"

Replace my_unverified_backup with the name of the repository to verify. If everything went correctly, you will receive a list of the nodes on which the repository is configured.

my_unverified_backup を確認するリポジトリの名前に置き換えます。 すべてが正常に行われた場合、リポジトリが設定されているノードのリストが表示されます。

To take a snapshot manually, use the snapshot creation API. The snapshot name supports the use of date math to give a unique name.

スナップショットを手動で取得するには、スナップショット作成 API を使用します。 スナップショット名は、一意の名前をつけるために、date math の使用をサポートしています。

PUT _snapshot/my_repository/<my_snapshot_{now/d}>

Replace my_repository with the name of your repository and my_snapshot with the name of the snapshot. If you use curl you must use escape characters, so the above command would look like this:

my_repository をリポジトリの名前に置き換え、my_snapshot をスナップショットの名前に置き換えます。 curl を使用する場合は、エスケープ文字を使用する必要があるため、上記のコマンドは次のようになります。

PUT _snapshot/my_repository/%3Cmy_snapshot_%7Bnow%2Fd%7D%3E

Depending on its size, a snapshot may take some time to complete. By default, the snapshot creation API only starts the snapshot process, which runs in the background. To block the client until the snapshot is finished, set the query parameter wait_for_completion to true.

サイズによっては、スナップショットの取得に時間がかかる場合があります。 デフォルトでは、スナップショット作成 API は、バックグラウンドで実行されるスナップショットプロセスのみを実行します。 スナップショットが終了するまでクライアントが待つようにするには、クエリパラメータ wait_for_completion を true に設定します。

PUT _snapshot/my_repository/my_snapshot?wait_for_completion=true

To perform a snapshot named: snapshot_today, you can run it on one of the nodes:

snapshot_today という名前のスナップショットを実行するには、ノードの 1つで以下のように実行します。

curl -X PUT "localhost:9200/_snapshot/backup_repo/snapshot_today?wait_for_completion=true&pretty"

If you use a port other than 9200, replace it with that value.

9200 以外のポートを利用する場合は、該当部分を置き換えます。

With the parameter wait_for_completion=true the call will remain active until the process is finished (it may take some time, depending on the size of the database).

パラメータ wait_for_completion=true を使用すると、プロセスが終了するまで呼び出し処理が待ちのままになります(データベースのサイズによっては時間がかかる場合があります)。

As soon as it finishes, it will return in JSON form the summary information of the process, it will be something similar to this:

完了するとすぐに、処理の概要情報が JSON 形式で返されます。これは次のようになります。

It is also possible to define specific options in the snapshot execution such as the indexes to include or metadata, for more details visit:

含めるインデックスやメタデータなど、スナップショットの実行で特定のオプションを定義することもできます。詳細については、次を参照してください。


Example:


例:

curl -X PUT "localhost:9200/_snapshot/backup_repo/snapshot_2?wait_for_completion=true&pretty" -H 'Content-Type: application/json' -d'
{
 "indices": "pandorafms*",
 "metadata": {
   "taken_by": "PandoraFMS admin user",
   "taken_because": "backup before upgrading"
 }
}
'

スナップショットの一覧

To get a list of all stored snapshots you can run the command:

保存されているすべてのスナップショットの一覧を取得するには、次のコマンドを実行します。

curl -X GET "localhost:9200/_snapshot/backup_repo/*?pretty"

Where backup_repo is the repository id and * represents all. For more information about snapshot search filters in Elasticsearch visit:

ここで、backup_repo はリポジトリ ID であり、* はすべてを表します。 Elasticsearch のスナップショット検索フィルターの詳細については、次の Web サイトをご覧ください。

スナップショットの削除

To delete a snapshot you must obtain its name from the above command and then execute it on one of the nodes:

スナップショットを削除するには、上記のコマンドにてその名前を取得してから、ノードの 1つで実行します。

curl -X DELETE "localhost:9200/_snapshot/backup_repo/snapshot_today?pretty"

To restore an index from a snapshot it must be closed, apart from other technical considerations. Please refer to this link for more information:

スナップショットからインデックスを復元するには、他の技術的な考慮事項とは別に、インデックスを閉じる必要があります。 詳細については、次のリンクを参照してください。

To restore an index, one of two ways must be used:

インデックスを復元するには、次の 2つの方法のいずれかを使用する必要があります。

  1. Delete the original index before restoring.
  2. Rename the restored index.
  1. 復元する前に、元のインデックスを削除
  2. 復元するインデックスの名前を変更

Both cases are presented below using backup_repo for the repository name and snapshot_today for the snapshot name as examples.

両方の場合を、リポジトリ名に backup_repo、スナップショット名に snapshot_today を例として使用して以下に示します。

  • Delete and restore:
  • 削除およびリストア:

The easiest way to avoid conflicts is to delete an existing index or data stream before restoring it.

競合を回避する最も簡単な方法は、既存のインデックスまたはデータストリームを復元する前に削除することです。


To avoid accidental recreation of the index or data stream, it is recommended to temporarily stop all indexing until the restore operation is completed.


インデックスまたはデータストリームが誤って再作成されないように、復元操作が完了するまですべてのインデックスを一時的に停止することをお勧めします。

To delete an index:

インデックスの削除方法:

curl -X DELETE "localhost:9200/my-index?pretty"

To restore an index:

インデックスのリストア方法:

curl -X POST "localhost:9200/_snapshot/backup_repo/snapshot_today/_restore?pretty" -H 'Content-Type: application/json' -d'
{
 "indices": "my-index,logs-my_app-default"
}
'
  • Rename when restoring

    Make sure you have enough storage space for this operation.

In this way you will repeat the information you already have stored and in some scenarios this process can be useful, for example:

  • リストアの際にリネーム

    この操作をする際は十分なストレージスペースがあることを確認してください。

この方法では、すでに保存されている情報と同じものを扱います。一部のシナリオでは、この処理が役立つ場合があります。たとえば、次のような場合です。

  • You need to confirm that a successful data retrieval has been performed. Each of the indexes and its renamed copy should contain the same information and return the same search results.
  • Validate data audits performed by third parties.
  • データ取得が正常に実行されたことを確認する必要がある。 各インデックスとその名前が変更されたコピーで、同じ情報が含まれ、同じ検索結果が返されることを確認する。
  • サードパーティによって実行されたデータ監査を検証する。
curl -X POST "localhost:9200/_snapshot/backup_repo/snapshot_today/_restore?pretty" -H 'Content-Type: application/json' -d'
{
 "indices": "my-index,logs-my_app-default"
  "rename_pattern": "(.+)",
  "rename_replacement": "restored-$1"
}
'

ノードの完全リストア

In the case of wanting to restore an entire node with all its indexes, it is recommended to stop the indexing services before executing the restore, for more information on this topic visit:

すべてのインデックスを含むノード全体を復元する場合は、復元を実行する前にインデックスサービスを停止することをお勧めします。このトピックの詳細については、次を参照してください。

In a log collecting tool, two things are the main concerns: looking for information, filtering by date, data sources and/or keywords, and seeing that information(Log viewer) drawn in occurrences by time unit. In this example, all log messages from all sources in the last hour are looked for. Look at Search, Start date and End date:

ログ収集のツールに関して、私たちは主に 2つのことに興味があります。日時やデータソース、キーワードによるフィルタリングをしての情報の検索と、時間単位ごとに発生する情報の参照(ログビューワ)です。この例では、直近 1時間のすべてのデータソースからのログメッセージを見てみます。Search, Start date および End date を見てください。

拡大するにはクリックしてください 時間経過による発生表示

最も重要で便利なフィールドは、検索 テキストボックスに入力する検索文字列と、使用可能な 3つの 検索モード です。

完全一致 文字検索で、log は完全マッチします。

|拡大するにはクリックしてください

全単語 単一の ログ の行の順序に関係なく、指定された単語(各単語はスペースで区切られることに注意してください)を すべて 含むかを検索します

拡大するにはクリックしてください

任意の単語 順番は関係なく、指定した単語の いくつか が含んでいるかを検索します。

フィルタされたコンテンツのコンテキストを表示するオプションがチェックされている場合、結果は、検索に関連する他のログ行に関する情報を含む状況の概要になります。

Enterprise 版バージョン NG 727 以上

この機能により、ログエントリをグラフに変換し、 データキャプチャテンプレート に従って情報を整理できます。

これらのデータキャプチャテンプレートは基本的に正規表現と識別子であり、データソースを分析してグラフとして表示できます。

高度なオプションへアクセスするには、高度なオプション(Advanced options) をクリックします。表示形式を選択できるフォームが表示されます。

  • ログエントリーの表示 (プレーンテキスト)
  • ロググラフの表示

ロググラフ表示 オプションでは、キャプチャテンプレートを選択できます。

Apache log model テンプレートは、デフォルトで、標準形式の Apache ログ (access_log) をパースし、時間応答比較グラフの取得、訪問サイトと応答コードによるソートができます。

編集ボタンを押すと、選択したキャプチャテンプレートを編集できます。作成ボタンでは、新たなキャプチャテンプレートを追加できます。

このフォームでは、以下を選択できます。

キャプチャ正規表現(Capture regexp)

データをキャプチャするための正規表現です。取得する各フィールドは、カッコでくくります。 (キャプチャする内容) フィールド(Fields)

正規表現を介してキャプチャされる順番です。 結果は、アンダースコアの間に書かれていない名前のキーフィールドの連結によってソートされます。

key, _value_
key,key2,_value_
key1,_value_,key2

注意: value フィールドが指定されていない場合、自動的に一致する正規表現の数になります。

注意 2: 1つだけ value カラムが指定されている場合は、累積値(デフォルトではパフォーマンス)を表すか、チェックボックスをオンにして平均を表すかを選択できます。

以下のフォーマットのログからエントリを取得するとします。

 Sep 19 12:05:01 nova systemd: Starting Session 6132 of user root.
 Sep 19 12:05:01 nova systemd: Starting Session 6131 of user root.

ユーザのログイン数をカウントするには、次のようにします。

正規表現:

Starting Session \d+ of user (.*?)\.

フィールド:

username

このキャプチャテンプレートは、選択した時間間隔におけるユーザのログイン数を返します。

Version 771 or later

バージョン 771 以降

With this option you may save frequently used filtering preferences, thus creating a list of frequently used filters. Once you have configured all filter values, click Save filter, assign a name and click Save. At any other time you may load these preferences by means of the Load filter button, then from the drop down list of saved filters select one of them and click Load filter.

このオプションを使用すると、頻繁に使用するフィルタ設定を保存し、そのフィルタの一覧を作成できます。 すべてのフィルタ値を設定したら、フィルターの保存(Save filter) をクリックし、名前を割り当てて、保存(Save) をクリックします。 いつでも、保存されたフィルタをドロップダウンリストから選択し、フィルタの読み込み(Load filter) ボタンを使用してこれらの設定を読み込むことができます。

NG 770 version or later.

バージョン NG 770 以降

Using the Favorite system, you can save a shortcut to the Log viewer with filtering preferences by clicking on the star icon in the section title.

お気に入り システムを使用すると、タイトルの星アイコンをクリックして、フィルタ設定を含む ログビューア へのショートカットを保存できます。

You will be prompted for a name to save as a favorite the filtering conditions you set.

設定したフィルタリング条件をお気に入りとして保存するための名前を求められます。

Log viewer filter preferences will be saved in their corresponding section in Favorite (Operation menu).

ログビューワ フィルタ設定は、お気に入り(Favorite) (操作(Operation) メニュー) の対応するセクションに保存されます。

ログ収集は、Windows および Unux (LInux®, MacOS X®, Solaris®, HP-UX®, AIX®, BSD® など) エージェント双方で実行されます。Windows エージェントの場合、イベントビューワモジュールで同様のフィルタを用いることにより、Windows イベントビューワから情報を取得することもできます。

Windows と Unix でのログ情報収集の例をみてみます。

バージョン 750 以降、このアクションは、詳細オプションを有効化することにより、エージェントプラグインを介して実行できます。

以下に示すタイプの処理を実行できるようになります。

Logchannel module

 module_begin
 module_name MyEvent
 module_type log
 module_logchannel
 module_source <logChannel>
 module_eventtype <event_type/level>
 module_eventcode <event_id>
 module_pattern <text substring to match>
 module_description <description>
 module_end

Logevent module

 module_begin
 module_name Eventlog_System
 module_type log
 module_logevent
 module_source System
 module_end 

Regexp module

 module_begin
 module_name PandoraAgent_log
 module_type log
 module_regexp C:\archivos de programa\pandora_agent\pandora_agent.log
 module_description This module will return all lines from the specified logfile
 module_pattern .*
 module_end

ログタイプモジュールの詳細説明については、次の章で確認できます。特定のディレクティブ

module_type log 

この種のタグ module_type logを 定義すると、データベースには保存されませんが、ログコレクターに送信されていることを示します。このタイプのデータを持つモジュールは、有効になっている場合はコレクターに送信され、有効になっていない場合は情報が破棄されます。

注意: この書式は、バージョン 5.0 以上で有効です。Enterprise 版をアップデートした状態にしているか確認してください。

エージェントバージョン 5.0 では、次の書式を使います。

module_plugin grep_log_module /var/log/messages Syslog \.\*

ログパースプラグイン(grep_log)と同じように、grep_log_module プラグインは、処理した情報をログファイルのソースとして “syslog” という名前でログ収集に送信します。どういったパターンの行を送信するかまたはしないかは、\.\* といった正規表現を利用します(この例では全て)。

From Pandora FMS version 749 onwards, a box called Log sources status has been added to the Agent View, where the date of the last log update by that agent will appear. By clicking on the Review magnifying glass icon, you will be redirected to the Log Viewer view filtered by that log.

Pandora FMS バージョン 749 以降、ログソース状態 と呼ばれるボックスがエージェント表示に追加され、そのエージェントによる最後のログ更新の日付が表示されます。虫眼鏡のアイコンをクリックすると、そのログにフィルタしたログビューワ表示にリダイレクトされます。

Pandora FMS ドキュメント一覧に戻る

  • ja/documentation/pandorafms/monitoring/09_log_monitoring.txt
  • 最終更新: 2023/05/12 06:45
  • by 127.0.0.1