ログ管理・ログ監視製品の採用ポイント
機能とライセンス費用における

嵌りやすいポイントと解決方法を一挙ご紹介

1

課題

2

採用
ポイント

P : 03

3
POINT
POINT
POINT
POINT

P : 03

4
POINT
POINT

5

収集

P : 04 - 06

対象ログの種類と作り込み
複数行ログ対応
アプリケーションのログ
クラウドログサービス対応

蓄積

P : 07 - 08

蓄積するログ情報と検索容易性
サイジングとクラウドストレージ活用

監視

POINT
POINT
POINT

P : 09 - 11

ログ件数とバースト抑制
メッセージフィルタ
自動化連携

02

6
POINT

7

ライセンス
費用

P :12

費用のスケールファクタ

まとめ

P :13

課題

1

2

採用ポイントITシステムの運用において、発生するログを管理することは非常に重要である。

ログは、収集→蓄積→監視の流れで運用自動化・効率化に繋げる。単に収集できる、蓄積｢ログが重要な障害を示す場合」「ログの件数が異常を表す場合」「ログを蓄積して分析する事でできる、監視できるといっても、ログ管理の分野では細かな機能性がユーザビリティにも大き

統計的に新たな傾向を把握できる場合」「ログを異常検知や将来予測に用い、その結果をく影響がでるので、もう一歩踏み込んだ実現性の確認を行うべきである。

元に運用自動化・効率化に活用する場合」などにおいて、ログの管理は必須となり、その種類とサイズは膨大になる。しかし、ログ管理・ログ監視製品は様々である。ログ管理の専用製品や、監視製品にログ管理が含まれるもの、エンジニアしか扱えない知識が求められる製品や、自動化に伴い製品連携が必須なもの、などがある。

こういった事により、プロジェクトの現場では次の課題が出てくる

前 述 の 課 題 に 陥らな いた めにも 、この 各 機 能とライセンス 費 用 について、採 用 時 に 確 認 すべきポイントを示す。そして、Hinemosがこれらのポイントを全てクリアしていることを合わせて紹介する。

課題 1

製品導入の敷居が高い

3

ログのサイズがどの程度大きくなるか、といったサイジングが困難で、適正なHWや製品のライセンス
を選べない

課題 2

監視ツール、ログ管理ツールと似通ったものが導入される

4

収集

蓄積

監視

ライセンス
費用

類似の機能を持つ製品が導入され、使い分けが曖昧だったり、両方の製品の使い方を覚える必要があったり等 の 現 場 の 負 担 が 増える 。自 動 化ツール も別となると製 品 連 携 だ け で、多 大 な 設 計と構築、運用の工数がかかる

課題 3

導入しても使われない

5

海外製品の場合、SEが扱うことを想定したツールの可能性がある。この場合、開発時点では導入は進むが、運用開始後にオペレーターが扱えずに、塩漬けのままになるケースがある

03

6

3

収集

作り込み

多くの製品では、紹介したログの多くに"対応"している事をうたっているが、ここで重要となるのは"作り込みの有無"になる。海外の製品やシステムエンジニア(SE)向けの製品の場合、"ユーザの作り込み"としてスクリプト等の開発を伴って"対応"をうたうケースがある。この場合、運 用フェーズに入るとSEではなくオペレータ主導の作業となるため、ログの追加や問題発生時の対応に再び開発をと に か くロ グ を 収 集 す る こと が 先 決 。
どの 様 な ロ グ に 対して 、どの 様 な 機 能 が 必 要 な の かを 紹 介 する 。

POINT

伴ったり、対応できず使用を止める"塩漬け"にするといった事に陥る。
ログ管理の基本機能の部分

ユーザの開発部分（作り込み部分）

作り込みの部分を前提に〇〇ログに対応、としている製品もある
開発中
運用開始後

対象ログの種類と作り込み

エンジニアが対応するので問題にならない
オペレータでは手に負えなくなる

対 象ログの 収 集を、作り込 み なしで簡 単に 実 現できることが 重 要であるが、カタログ
スペックだけでは単にログの種 類一覧だけが表記されているケースが多い。

Hinemos

対象ログの種類

Hinemosはオペレータ向けの製品である。収集と監視を統一的なインタフェースで提供し、非常にサービスのログ、OSのシステムログ（Windowsイベントとsyslog）や、NW機器、ストレージ装置、

ファイルパスやWindowsイベントの対象を指定するといった事だけで事足りる。Webサービスの応答

様々な種類のログもGUI操作だけで収集する。GUI操作も簡単で、対象の種類をクリックして、ログ

対象ログの種類は、一番最初に確認するポイントになる。アプリケーションのログやミドルウェアや(HTTPレスポンス)等の監視結果もそのままログとして蓄積が可能であり、また収集対象が異なっても

その他プラットフォーム全般のログは当然対象になる。形式はテキストファイルやバイナリファイル、

基本的な画面構成は同じであるため、非常に簡単に製品を習熟できる。

専用の管 理ツールに蓄 積されているもの、クラウドのログサービスに蓄 積されているものに分 類される。広義のログとしては、送 信されてくるsnmptrapやsyslogパケットや、パケットキャプチャも対象に含む場合がある。
ログの種類

ログの形式

PING監視プロセス監視特殊なログ

アプリケーション

テキストファイル

s n m ptra p

ミドルウェア

バイナリファイル

s y slo g パケットサービス

専用の管 理ツール

パケットキャプチャ

OS

ログサービス

Hinemosが収集できるログ

リソース監視サービス・ポート監視

Windowsイベント監視

Hinemosエージェント監視HTTP監視NW機器

HTTPシナリオ監視ストレージ装置

SNMP監視プラットフォーム全 般

04

SNMPTRAP監視

SQL監視

JMX監視

ログファイル監視

Hinemosのログファイル監視の設定
ログの種類別の固有の設定

システムログ監視
相関係数監視収集値統合監視

バイナリファイル監視
パケットキャプチャ
カスタム監視カスタムトラップ監視

チェックを入れると収集・蓄積

POINT

複数行ログ対応

POINT

ファイルに出力されるログは 、Linuxのs ys logの様に"最 大1024 by teの1行ログ"といったシンプルなものだけではない。その代表的なものは、Oracleのログやjavaアプリ
ケーション のロ グになり、それらは 複 数 行 からなるロ グになる 。複 数 行ロ グは 、より詳 細な情 報を得られる反面、収 集や監視を行う立場としては、どこからどこまでが"1つのロ グの 固まり" か を把 握 する 必 要 がある 。一 部 の 製 品では 、複 数 行ロ グも1行単 位でしか収 集・監視が出来ない仕様の場合もある。

クラウドログサービス対応

クラウドのログサービスとは、Amazon CloudWatch LogsやA zure Monitor Logsを指す。クラウド上のシステムのログ管理には、これらのサービスは必須となる。何故なら、
単にEC 2の上にア プリケーションを配 置してログ ファイル を収 集するのとは 異 なり、
クラウド利用のメリットであるPaaSを活用した場合、PaaSのログは直接的にログ管理製 品が 収 集できないからである。そのため、クラウドのログサービスにログを投 入する設定にした後、このログを活用するにはログ管 理 製品側からクラウドのログサービスに連携する必要がある。

代表的な1行ログ
Linuxシステムログ

クラウドのログサービス

Jun 29 17:38:11 Tiger shutdown[30243]: shutting down for system halt

代表的な複数行ログ
Javaスタックトレース

Oracleアラートログ

java.lang.NumberFormatException: For input string: "1.1"

Sat Feb 07 12:35:53 2015

at java.lang.NumberFormatException.forInputString(Unknown Source)

create tablespace TEST_SPACE dataﬁle size 5m autoextend on

at java.lang.Integer.parseInt(Unknown Source)

Completed: create tablespace TEST_SPACE dataﬁle size 5m autoextend on

at java.lang.Integer.<init>(Unknown Source)

Sat Feb 07 12:38:40 2015

at ExceptionPrintDemo.formatInt(ExceptionPrintDemo.java:7)

alter database dataﬁleat ExceptionPrintDemo.main(ExceptionPrintDemo.java:14)'/u01/app/oracle/oradata/CDB122/0/dataﬁle/o1_mf_test_spa_bfc20s53_.dbf'

クラウドログサービス

代表的なPaaS
通常のログ管理製品

ログサービスには
連携できる

直接ログを
収 集できない

resize 8m

Hinemos
Hinemosでは、Amazon CloudWatch LogsやAzure Monitor Logsのログを収集・監視することが可 能 である。ログ ファイルや W i n d o w sイベントを指 定するか のように 、これらのログ を簡 易に

Hinemos扱えるため、クラウドにおけるログもHinemosで統括的に扱うことができる。

Hinemosでは複数行ログに対応している。ユーザが"先頭パターン"、"終端パターン"、"改行コード"

Hinemosのクラウドログサービス対応を指定することで様々な製品の複数行からなるログにも簡単に対応できる。

ログサービス

これにより、意味のある単位でログを収集し、監視や分析にそのまま活用する事ができる。
Hinemosの複数行ログ対応

シームレスな監視

OSやミドルウェアのログと同様にPaaSのログも同一インターフェースで設定

Amazon CloudWatch Logs
フィルタ条件を集約

Azure Monitor Logs

05

業務カレンダの適用

メッセージバースト対応
通知・アクションの集約

必要に応じた収集・蓄積

最終的な蓄積先をHinemosとするようにログの収集も可能

POINT

アプリケーションのログ

Hinemos

多くのプ ロ ジェクトで は 、ア プ リケ ー ション 開 発 者 以 外 が 運 用 設 計 を 行 ってい る 。
具体 的 には 、アプリケーション開 発 中は 開 発 のみに注 力して、運 用については別工程
や別チームが考える事として分割する。この場合では、既に出来上がってしまったアプリ
ケーションに 対して運 用を考えるため 、本 質 的 な 監 視を導 入しようともしても情 報 が足りず、アプリケーションの改修を伴わないと実現できないケースが多い。

これに対して、Hinemos は新たなアプリケーション運用の手法として、Software Deﬁned Monitoringand Logging（SDML）機能を提供している。SDML ロギングモジュールをアプリケーションに組み込むことで、制御ログを介しアプリケーションのログと監視を制御する。
SDML機能アプリケーション監視の課題 ❶アプリ開発後に運用設計

アプリケーション開発中は開発のみに注力して、運用については別工程や別チームが考える事として分割されている④アクションの自動実行

アプリ開発者以外が運用設計を

SDML
コントローラ

既に出来上がってしまったアプリに対して運用を考えるため、本質的な監視を導入しようともしても改修を伴い実現できないケースが多い

また、クラウド化・コンテナ化・アジャイル開発といった要素により開発からリリースまでのサイクルが 非 常に 短く、イテレ ー ティブ（ 反 復 的）な 開 発 の 流 れになってきている。
つまり、アプリケーション開 発 から運 用 開 始までの 期 間 が 短くなり、基 本 的な 監 視を導入しだけで、本質的な監視が 行えていないケースが発生する。

クラウド化・コンテナ化・アジャイル開発といった要素により開発からリリースまでのサイクルが非常に短くイテレーティブ（反復的）な開発の流れに

Java等のアプリケーション②監視すべきログメッセージを出力

SDML
ログリーダ

③制御ログを読み込みモニタリングとロギングを実行

SDML
ロギング

①モニタリングとロギングを制御するコードを出力

これによって、アプリケーションの起動に伴い必要なログを自動で収集したり、監視を自動実行する事が可能になる。

アプリケーション監視の課題 ❷短いシステム開発のサイクル④監視の自動実行

監視対象も、プロセスのエラーログだけではなく、プロセスの死活状態や内部状態も含まれる。
これにより、
アプリケーション監視の設計が不要になり、またアプリケーションの改修を伴わずに運用者が把握すべき情報を自動的に監視が可能になる。

アプリ監視設計の期間がない

アプリ開発や試験から運用開始までに監視設計の期間が短くなり、基本的な監視を導入ししだけで本質的な監視が行えていないケースが多い

自動監視

こういったケースでは、重要な異常を見落とす可能性がある。それは、運 用設 計の役 割
分担や短期開発の優先が、運用の安定稼働を阻害する事を指す。

監視なし

監視実行

監視なし

アプリケーション

アプリケーション

アプリケーション起動❶ プロセスの死活状態

アプリケーション異常終了を検知する

アプリケーション
起動

06

自動的な監視実行

アプリケーション

異常停止

アプリケーション起動時に監視を自動で開始し、アプリケーション正常終了時に監視を停止する

停止
様々な異常検知❷ プロセスの内部状態

プロセスの内部状態を定期的にウォッチし異常の予兆を検知する

アプリケーション

起動・Javaヒープ残量・デッドロック発 生有無
・GC発 生頻 度❸ プロセスのエラーログ
プロセスの出力するログを監視し
エラーメッセージを検知する

アプリケーション
起動

ログ

4

蓄積

Hinemos
H i n e m o s で は ロ グ 収 集 時 に 指 定 箇 所 にタグ付 けをしてメタ 情 報として合 わ せ て 蓄 積 するロ グ
フォーマット機能を備えている。例えば、Apacheのアクセスログの場合、ステータスコードの部分にstatus _codeとタグ付けすることで、検索時に"status _code=200"として簡単に検索する事がロ グ を 収 集 す ると 、次 に 必 要 な の は 蓄 積 す る こと 。
どの ような 形 で 、 どこに 蓄 積 する 必 要 が あ るか を
紹 介 する 。

POINTできる。各製品のログのログフォーマットは各製品にて仕様が明確に決まっているため、エンジニア
が設 計しておくことで、オペレータが非常に簡易に検索活用が出来るようになる。
タグ付けと検索利用

検索条件

蓄積するログ情報と検索容易性

status_code=200

ログを蓄積する際には、生ログ（加工されていないログ）をそのまま蓄積する事が重要である。しかし、生ログだけの蓄 積ではログの検 索が非常に難しくなる。蓄 積したログを 簡 単 に 検 索 し た い ケ ース は 多 く存 在 するが 、一 部 の 製 品で は 生 ロ グ だ け を 蓄 積
し 、1つの検 索窓があるだけのものがある。シンプルな中間 一 致の場合では問題にならないが、ログの特定の部分を指定しての検索の場合に、非常に高度な検索条件をユーザが 検 討して指 定する必 要がある。製 品によっては 、製 品依 存 の言 語でこの 検 索 条 件 を指定するといった事になる。

Apacheアクセスログ
127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326

先頭は送信元IP

難しいログ検索言語[]内は日付情報

キー

src_ipaddress
date

methodApacheアクセスログ

status_code

127.0.0.1 - frank [10/Oct/2000:13:55:36 -0700] "GET /apache_pb.gif HTTP/1.0" 200 2326

生ログ

Apacheアクセスログから、

HTTPステータスコード=200のログだけを検索するには？

検索条件

前後にスペースを入れればヒットするだろうか？

“_ 200_”

予期しない行のヒットを除外するため別の条件も入れるか？

“.*GET.*_ 200_“
生ログのみ

07

メタ情報

send_byte

規則性からタグ抽出値

127.0.0.1
10/Oct/2000:13:55:36 -0700
GET
200
2326

POINT

サイジングとクラウドストレージ活用

Hinemos

ログ管 理の 一 番 の最初の難 関はサイジングにある。収 集したいログの 一覧を作 成し、ログの出力量を見 積り、ログの流 量と蓄 積に必 要なディスク容量を決 定する。しかし、
収 集したいログの出力量は 設 計 時 では 適 切に見 積もることができず、また収 集したい
ログは運用フェーズに入った後に増えていくものである。よって、過大なサイジングにより非常に大きなストレージ装置を用意する事になり、ハードウェアコストがかかるが実際の 利 用 率 は 低 かったり、逆 にストレ ー ジ サイズ を押さえてしまった事 で、集 める べき
ログを取 捨選 択して削っていくという無 駄な運 用コストが発 生する可能性がある。ログの圧縮は改善の1要素ではあるが、根本解決にはならない。

Hinemos では、収集・蓄積したログを ﬂuentd 経由で AWS、A zure、Google Cloud などクラウドのサービスにログを連携する事が可能である。

Hinemos は、これまでの説明の通り、ログ以外にも様々な情報を蓄積し、その蓄積データの管理と監視・自動化への活用を行う。

Hinemosの収集・蓄積

ログのサイジングの難しさ

困難なログサイジング

設計が進んでいない段階で見切り発車でのHW調達
安全を見て余裕のある
ディスク容量のHW購入

パフォーマンス

プラットフォームログ

システム構成

アプリ情報

リソース値

システムログ

プロセス

アプリログ

ログ件数

センターデータ

OS

リソース

応答時間

無理のある運用余裕のある運用だが、HW維持費も高くつく

検索

ログの種類の確定

ログ出力量の確定

ギリギリ収まるディスク容量のHW購入

余裕が無いため蓄積対象を都度選定・削除

search

蓄積データの管理

パッケージ

プロセス

監視・自動化への活用

外部連携

監視

CloudWatch Logs

自動化

BigQuery

Elasticsearch

Azure Storage

この問題は結局のところ、ログ管理製品だけで解決できない。一 般的な解法はクラウドを活用したログの退 避にある。クラウドのログサービスやストレージは 、物 理 的なスト
レージを購入するより安価で利用でき、インバウンドのNW通信には課金されないというメリットがあり、古いログの退 避 先にすることはクラウド黎明 期からの 代 表的なユースケースである。これにより、スモールスタートでログ収 集と蓄積を開始でき、対象の増減にも柔軟に対応できる。これには他にもメリットがあり、クラウド上には機械学習などのサービスもあるため、大量に蓄積したログをそのまま活用する場合にも都合が良い。
ITシステム

NWパケットHinemos の動作するサーバのローカルディスクにユーザの指定する保 存 期間分を蓄積して、性能グラフ表示やログの検索・分析などが簡易に行えると共に、蓄積した情報をログ転送の機能を使用することで クラウドサービスに 簡 単 に 連 携 する。ログ を 連 携 するインタフェースとして一 般 的 なﬂuentd を採用しているため、クラウドサービス以外にも様々な製品と連携が可能である。
ログ転送と外部サービス活用

クラウドストレージ活用
クラウド上のログサービス・ストレージ

ログのバックアップ・退避

クラウド上の
AI/MLサービスの活用

既存の
SWH/データ分析基盤など

08

この機能を使ったクラウドストレージ活用により、
スモールスタートかつ適正・安価なログ運用が可能になる。

監視

5

Hinemos
Hinemosでは、ログの件数による監視と、バースト時の通知抑制の機能を持つ。ログ件数監視により、

指 定の 条 件 を 満 たすロ グが単 位 時 間 に一 定 件 数 出 力されるとアラートを上 げることが できる 。
指 定 条 件 に は 、ロ グ フォ ー マ ット に よる タ グ を 利 用 で き る た め 、例 え ば 送 信 元 I P アドレス

収 集 と蓄 積 をする目 的 は 、 運 用 の 自 動 化 ・ 効 率 化
で あ り 、監 視 は そ の 入 口 に なる 。
ロ グの 監 視 か ら自 動 化 へ の 連 携 に つ いて 、求 めら れ る 機 能 を 紹 介 する 。

POINT

ログ件数とバースト抑制(src_ipaddress)を限定した件数のカウントが可能である。これにより、普段と異なるログ出力状 態を直ちに 検 知ことが できる。また、バースト発 生 時 に、初 回 通 知 や二 回目以 降 のアラートの 発砲を制限する事ができる。これにより、全て同一事象を示す通知により運用監視端末やメールが埋め尽くされことを防ぐことが出来る。

ログ件数監視ログの監 視 は 、ログメッセージに 対 するパターンマッチが 代 表 的な手法であるが、それ だけでは異常を検 知することができない場合もある。例えば、同じ内容のログが連続で出力されるケースや、
単位時間当たりのログ件数が急激に増えるケースである。

バースト抑制ディスク異常などでは、I/O ERRORのログがwriteの単位で発 生するため非常に多くの同じログが出力される。また、Apacheのアクセスログにおいて特定IPアドレスからのリクエストが急増して、これが異常を示すような場合もある。
こういった際に、ログ件 数による挙動の変 化を捉えたいと共に、ログバースト時にユーザへの通 知( アラート)を抑制できないと、同 一事象を示す通 知がユーザに大量に到着し、他の重要なイベントを見逃してしまう二次被害が発 生する。
異常時に発生するログ

IN F O s ervic e s t art
E R R O R dis kio / h o g e
E R R O R dis kio / h o g e
E R R O R dis kio / h o g e
E R R O R dis kio / h o g e
E R R O R dis kio / h o g e

２件目以降はほぼ同じ内容例）ディスクI/O ERROR

例）送信元IPによるログ件数
src _ip a d dre s s =19 8 .51.10 0 .2 01
src _ip a d dre s s =19 8 .51.10 0 .1
src _ip a d dre s s =19 8 .51.10 0 .101

09

メッセージフィルタ

POINT

Hinemos

実際にはログだけではなく、様々な監視結果と合わせて異常を判断すべきである。例えば、
NWセグメントを中継するスイッチに障害が発生すると、このスイッチ経由でアクセスする
アプリケーション や サービスが 全て通 信エラーでログを大 量に出力する。そのため、スイッチの障害に影響を受ける様々なアプリケーションやサービスの異常だけで運用端末の情報が埋め尽くされてしまう。

本 質的なイベントの 特 定には複 数のログや監 視 結 果との関 係 性 から、判 断する必 要が出てくる。
この関係性は、対象システムやアプリケーションの構成により様々であり、そのために柔軟に関係性を定義し、イベントを特定（フィルタリング）する事が求められる。
Hinemosでは、メッセージフィルタ機能により、本質的なイベントを抽出が 可能になる。
メッセージフィルタによる本質的なイベントの特定スイッチの故障

監 視サーバから見ると
Switch S 2より先のサーバも応 答がないので異常と扱う事になる

Router

Switch S1

ServerA

管理対象システム「危険」の通知Switch S2

Switch S2障害

Server B不明

スイッチの故障

NIC 故 障なのでOS上から監 視に必 要な 情 報を取 得できず
全て異常と扱う事になる

プロセス
監視

HTTP
監視

SQL
監視

msg

大量発生

msg

msg

msg

msg

msg

msg

本質的なイベント
フィルタ

msg

自動化

msg

メッセージフィルタ

syslogメッセージフィルタの特徴❶ ルールエンジンを採用

ルールエンジンとは、与えられたルールに従って判断を行う機能「危険」の通知

SNMP
監視
NICの故障時は全て監視不能msg

msg

このメッ セー ジ フィル タの 特 徴 は 大 きく３つ あ る 。１つ 目 の 特 徴 は 、ル ール エ ン ジ ン を 採 用 、している事である。ルールエンジンとは、与えられたルールに従って判断を行う機能であり、ルールの 定 義 により様 々なフィル タリン グが 可 能 になる 。２つ目の 特 徴 は 、W h e n / T h e n のル ール を記述、する事である。ルールを記述するとは難しそうに聞こえるが、When（～の時）/Then（～する）というシンプルな形になる。ルールの数は複 数あっても構 わなく、ルールを記 載するとメッセージ
フィルタが 適 切 に判 断 する。３つ目の 特 徴 は 、イベント間 の 関 係 性も条 件 化 、できる事 である。
これは複合イベント処 理（CEP）と呼 ばれるもので、あるサーバからの応 答がないというイベントが発生した際に、スイッチも障害のイベントが発生していたら、というイベント間の関係性をルールの条 件（When）に記載できる事を指す。
このメッセージフィルタ機能を使 用する事で、本質的ではない不 要なメッセージを排除し、運 用者が 効率的に目的の運 用業務を果たしたり、ユーザの判断を介在せず運 用自動 化に繋げる事が 可能になる。

例えば、あるサーバに対してPING監視からプロセス監視までの多種多様な監視を行っていた
際にNICに障害が発生すると、PINGの応答だけでなく、サーバのOSから何も情報を取得できないため、行っていた全ての監視でエラーが発生し、同様に運用端末の情報が埋め尽くされてしまう。

SNMP
監視

msg

msg

アラート

Server C不明

Hinemosからみて到達不能
ServerB ServerC

PING監視

msg

ルール適用

PING

SNMP

プロセス

メッセージ

ポート

ポート

SQL

msg

msg

ルール適用

msg

msg

判断結果

❷ When/Thenのルールを記述

When/Thenからなるルールを記載すると、メッセージフィルタが適切に判断
ルール1

When
Switch S1が警告

msg

Then
警告を危険に変更

msg
・〇〇の場合、△△する

ルールエンジンルール

メッセージフィルタ機能では、
Droolsを採用

10

ルール3

ルール6

ルール7

ルール4

機能の提供する

ルールエンジン

スイッチX
の障害

ルール5

メッセージフィルタ・□□の場合、▽▽する

この様な形で、真の障害に付随するエラーで運用端末の情報が埋め尽くされると、同時に発生していた重要なログメッセージを見逃す可能性もある。そのためには本質的なイベントに注力して監視できる事が重要になる。

ルール2❸ イベント間の関係性も条件化

複合イベント処理（CEP）によりイベント
間の関係性をWhenの条件に記載

各種機能

ルールの文法は、DRL (DROOLSRULE LANGUAGE) ルール言語に従う

サーバA
の障害

時間

5分以内にスイッチの障害があったか？

Droolsが提供するCEP機能をそのまま使用POINT

自動化連携

Hinemos

運用自動化・効率化には、ジョブ管理やワークフロー管理の機能が必要になる。ログ管理・
ログ 監 視の製 品に、異常を検 知した際に簡易なコマンドを実 行する機 能は備えているものは多いが、これでは不十 分である。例えば障害復旧を行うような処 理を自動 化した
際には 、その 処 理 が 正常に稼 働したか の判 定や複 雑な条 件分 岐、サーバを跨った処 理の 制 御 が 必 要になる。また、専用のジョブ 管 理・ワークフロー 管 理 の 製 品を導入した
場合、ログ管理・ログ監視の製品との連携を作り込み、そして２種類の製品を使いこなす
運用コストがかかる。

Hinemosでは、大きな機能分類として「収集・蓄積」「監視・性能」「自動化」の３大機能と、それらを支える「共通基 本」機能をワンパッケージで提供している。もちろん、これらの機能間は製品として相互に連携している。

Hinemosがワンパッケージで提供する機能

収集・蓄積

自動化連携の課題備えている自動化機能は貧弱

参照
共用利用

連携部分は作り込みが発生

ログ管理・ログ監視製品

リポジトリ

自動化製品

相互連携

監視・性能
参照
共用利用

共通基本

アカウント

相互連携

通知

自動化
参照
共用利用

カレンダ

そのため、Hinemosはログの収集や監視から直ちに自動化機能、つまり、ジョブ管理・ワークフロー
管理の機能に連携する事が出来る。連携方法も簡単であり、監視結果が「危険」の場合に指定の障害

複数の製品の習熟が必要

復旧ジョブを起動する事を、GUIから選択するだけで実現できる。もちろん、このジョブは複数のサーバに跨る複雑なものであってもよく、途中にユーザが対話的に判断を入れる事も可能、そして、起動したジョブの状態遷移もビジュアライズされている。

Hinemosのジョブ管理

よって、Hinemosではワンパッケージで提供されているため、自動化連携を行う際にセットアップが不要であり、統一的なインタフェースで操作ができ、そして何が製品の問題が発生した際も製品間の11切り分けが不要なワンストップ保守というメリットがある。

ライセンス費用

6

Hinemos
Hinemosは 基 本 的に、ログ流 量や監視 対 象台 数、コア 数によりライセンス費 用はスケールせず、
あくまでマネージャ機能のインストール単位で費 用が決まる。

どん な に 高 機 能 な 製 品であってもプ ロ ジェクトとして
採 算 が 合 わないと意 味 がない
そ も そ も 費 用 は 見 積 れ る も の な の だ ろう か

費用のスケールファクタ

費用

POINT

Hinemosのサブスクリプション費用

Hinemosは一定・安価
ログ流量・監視対象数・CPUコア数

ログ 管 理 製 品は 、基 本 的 にログ 流 量 でライセンス費 用がスケールする。サイジングが難しいにも関わらず、製品選定と購入時のフェーズで既にログ流量の見積が必要となってしまう。また、開発や運用フェーズで扱いたいログが増えた場合に、追加の費用を支払う
かログ流用を上限に調整する必要が出てくる。

これにより、ポイントで説明した各 観 点において、非常にメリットがある。
費用のスケールファクタが少ないメリット

ログ 監 視 製 品は 、基 本 的に監 視 対 象台 数 でライセンス費 用がスケールする。仮 想 化やクラウド利 用 が 当たり前の 時 代 に 、サーバー のスケールアウトがログ 監 視 製 品 のライ
センス費用により制限される。

製品選定時

設計・構築時ログ管理機能の利用時自動 化を担うジョブ管 理 製品は 、基 本 的にはサーバ 数やCPUコア 数でライセンス費 用がスケールする。サーバ 数 が 少なくても高スペックのサーバを使 用すると高価 になり、またリソースのスケールアップがライセンス費用に制限される。
費用のスケールファクタ

ログ管理製品

ログ監視製品

自動化機能の利用時

ジョブ管理製品

監視対象数

拠点単位にHinemosマネージャを配置する台数、等の簡易な見積もりで済む
費用変動がないので運用対象の増減、環境変更が簡易に行える
ログ流量の厳密な見積もりは不要

管理対象に導入するエージェント数を削減する必要が無い

自動化製品の追加不要、ハイパフォーマンスなサーバを導入しても安価に済む

クラウドの 様 な 柔 軟 に 環 境 変 化 するシステムにお いてで も 、ログ 管 理・ログ 監 視 機 能を 適 切 な
費 用で提供する製品、それがHinemosである。

費用

費用

費用
ログ流量

ログ監視機能の利用時

Hinemosのメリット

CPUコア数12

まとめ

ログ 管 理 ・ ログ 監 視の 選 定ポイントを 、収 集 → 蓄 積 → 監 視の 機 能 流 れで 紹 介した 。
その中で 、採 用 時に確 認すべきポイントを示し 、H i n e m o s が それら全てクリアし 、
安 価 で 効 率 的なログ 管 理 ・ ログ 監 視を実 現することを紹 介した 。

L i n u x 、W i n d o w s 、各種 U N I X 環 境 から 、仮 想 化 ・ クラウド環 境 に幅 広く対応 する H i n e m o s を
ログ 管 理 ・ ログ 監 視における重 要 なソリューションとして是 非 活 用 頂きたい 。

7

お問い合わせHinemosポータルサイト

https://www.hinemos.info
問い合わせフォーム

https://www.hinemos.info/estimate＊「Hinemos」は日本国内における NTT データ先端技術株式会社の登録商標です。
＊その他の商品名、会社名、団体名は、各社の商標または登録商標です。

2021.12 版
Copyright © 2021 NTT DATA INTELLILINK Corporation