リリースノート

v.209リリースノート

機能のハイライト

  • LMログにログ分析機能を追加しました
  • LogicMonitor ユーザー アカウント変更通知の強化
  • 2要素認証のオプションとして認証アプリを有効にする

更新の監視

  • 改良された Juniper Mist NetScan および Cisco Meraki NetScan LogicModules
  • Nutanix AOS 6.8 OS が正式にサポートされました
  • LM Exchange に新しいローカル モジュール タブが追加されました
  • Cato SD-WAN GraphQL APIベースのCatoソケットの監視に新しい監視を追加しました
  • Cisco_Catalyst_SDWANモジュールを更新しました

コレクターの設定

セキュリティのアップグレード

Windows コレクターの最小権限

Windows コレクターは、管理者以外の資格情報を使用して実行できるようになりました。これにより、セキュリティ標準が向上し、インストール環境内での不正アクセスや誤用のリスクが軽減されます。

警告: このセキュリティ強化の結果、すべての Windows コレクターを非管理者として実行するように移行する必要があります。

この移行を完了するには、プロンプトベースのウィザードを使用できます。

強化されたセキュリティを活用するには、EA Collector 35.400以降がインストールされている必要があります。詳細については、 EA Collector35.400リリースノート.

詳細については、製品ドキュメントの次の項目を参照してください。

LogicMonitorのセキュリティ要件の詳細については、 重要なセキュリティに関するお知らせ LM コミュニティで。

セキュリティのアップグレード

Linux コレクターの最小権限

Linux コレクターは、非ルート認証情報を使用して実行できるようになりました。これにより、セキュリティ標準が向上し、インストール環境内での不正アクセスや誤用のリスクが軽減されます。

警告: このセキュリティ強化の結果、すべての Linux コレクターを非ルート ユーザーとして実行するように移行する必要があります。

この移行を完了するには、プロンプトベースのウィザードまたはサイレント移行プロセスのいずれかを使用できます。

強化されたセキュリティを活用するには、Collector GD 36.000以降がインストールされている必要があります。詳細については、 GD Collector36.000リリースノート.

詳細については、製品ドキュメントの次の項目を参照してください。

LogicMonitorのセキュリティ要件の詳細については、 重要なセキュリティに関するお知らせ LM コミュニティで。

LMログ

強化

LMログにログ分析機能を追加しました

LogicMonitor は、LM Logs の新機能であるログ分析を導入しました。これは、階層化されたインテリジェンスを使用してログ データを視覚的に要約し、問題の調査とトラブルシューティングに役立つ詳細な分析情報を提供します。複数の基準とディメンションを組み合わせて各ログ メッセージの感情スコアを作成し、最も重要で影響力のあるログをこれまでよりも速く表示します。また、特定のキーワードやフレーズをフィルター処理して、必要なログに焦点を絞るのにも役立ちます。

モジュール

強化

改良された Versa SD-WAN NetScan

Versa SD-WAN向けの更新された拡張スクリプトNetScanでは、資産情報を提供しないデバイスが除外され、 versa.organization 設定されていない場合はフォルダー構造に含まれます。

詳細については、を参照してください。 Versa SD-WAN モニタリング 製品ドキュメントに記載されています。

強化

改良されたJuniper Mist NetScan

JuniperMist LogicModules 向けの改良された拡張スクリプト NetScan では、検出されたリソースのサイト名が含まれていない CSV ファイルのデバッグ サポートが追加されました。

詳細については、を参照してください。 ジュニパーミストモニタリング 製品ドキュメントより。

強化

改良された Cisco Meraki NetScan

Cisco Meraki LogicModules 向けの改良された拡張スクリプト NetScan では、MX IP アドレス検出用のより優れたデフォルトと null チェックが追加されました。

詳細については、を参照してください。 Cisco Meraki モニタリング 製品ドキュメントに記載されています。

強化

Nutanix AOS 6.8 OS が正式にサポートされました

LogicMonitor は、Nutanix Acropolis オペレーティング システムの最新リリースである Nutanix AOS 6.8 を正式にサポートします。LogicMonitor は、Nutanix AOS 6.8 で導入された Nutanix の更新された SNMP データ プロファイルと参照構造をサポートするようになりました。

詳細については、を参照してください。 Nutanixハイパーコンバージドインフラストラクチャ 製品ドキュメントより。

強化

LM Exchange に新しいローカル モジュール タブが追加されました

Exchangeでモジュールを選択すると、そのExchangeモジュールからインポートまたは複製されたすべてのモジュールを、マイモジュールツールボックスから表示できるようになりました。 ローカルモジュール タブで詳細パネルを表示します。このビューには、各モジュールの名前、説明、バージョン、ステータス、最終更新日が表示されます。モジュールを選択すると、ツールボックスでそのモジュールに直接移動します。

詳細については、を参照してください。 モジュールの概要 製品ドキュメントに記載されています。

推奨されない

Apache Groovy 4 によるすべての LogicMonitor 提供の LogicModule のサポート

将来のリリースでは、LogicMonitor コレクターは Apache Groovy 2 をサポートしなくなります。LogicMonitor が提供するすべての公式モジュールは、Apache Groovy 4 と互換性を持つようになります。この移行をサポートするために、LogicMonitor は、Groovy 4 と互換性を持つ公式 LogicModules のアップデートをリリースする予定です。

この移行の結果、次のことを行う必要があります。

  • カスタマイズされたモジュールまたはコミュニティが提供するモジュールを検証して互換性を確保します
    カスタマイズしたモジュールの検証の詳細については、次を参照してください。 カスタム モジュール Groovy 移行の検証 製品ドキュメントに記載されています。
  • 互換性の変更がリリースされた LogicMonitor 提供のモジュールのモジュール更新をインストールします。リリースされた更新モジュールは、LogicModules リリース セクションにリストされます。
    詳細については、を参照してください。 モジュール管理 製品ドキュメントに記載されています。

LogicMonitor EA Collector 34.500 以降は、Groovy 2 および Groovy 4 と互換性があります。EA Collector リリースの詳細については、「 EAコレクター34.500 リリースノート。

既知の問題

Apache Groovy 4 を使用してモジュールを実行する場合、GroovyScriptHelper を使用して LogicMonitor スニペットをスクリプトに組み込むと、次の例外がスローされる可能性があります。

exception:groovy.lang.MissingPropertyException: No such property:

この問題を軽減するには、次のようにクラスのインポート方法を調整します。

if(GroovySystem.version.startsWith("2.")) {
    modLoader = com.logicmonitor.common.sse.utils.GroovyScriptHelper.getInstance()._getScript("Snippets", Snippets.getLoader())
} else {{{}}
    modLoader = com.santaba.agent.groovy.utils.GroovyScriptHelper.getInstance("v4").getScript("Snippets", Snippets.getLoader())
} 

たとえば、以下は Groovy 2 で GroovyScriptHelper がどのように使用されるかを示しています。

import com.logicmonitor.common.sse.utils.GroovyScriptHelper as GSH
import com.logicmonitor.mod.Snippets 
 
modLoader = GSH.getInstance()._getScript("Snippets", Snippets.getLoader()).withBinding(getBinding()) 
 
lmDebug = modLoader.load("lm.debug", "0", true) 
lmDebug.default_context = "Test:SettingContext"

以下に示すように、Groovy 4 で GroovyScriptHelper を使用するようにスクリプトを変更できます。

import com.logicmonitor.mod.Snippets 
 
if(GroovySystem.version.startsWith("2.")) {    
modLoader = com.logicmonitor.common.sse.utils.GroovyScriptHelper.getInstance()._getScript("Snippets", Snippets.getLoader())
} else {   
modLoader = com.santaba.agent.groovy.utils.GroovyScriptHelper.getInstance("v4").getScript("Snippets", Snippets.getLoader())
} 
 
lmDebug = modLoader.load("lm.debug", "0", true) 
lmDebug.default_context = "Test:SettingContext"

重要: LogicMonitor は、LogicMonitor が提供するモジュールのこの問題を軽減するために、公式 LogicModules のアップデートをリリースしています。カスタマイズされたモジュールまたはコミュニティが提供するモジュールを利用している場合は、有効なパラメータをすべてのデータ構造に渡すようにモジュールを更新する必要があります。

既知の問題

スクリプト内のレガシー クラスで Apache Groovy 4 を使用してモジュールを実行すると、次の例外がスローされる可能性があります。

java.lang.RuntimeException: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed

この問題を軽減するには、JPMS 準拠のパッケージ名に移行します。この変更を行っても、Groovy 2 との下位互換性は失われません。

たとえば、次のスクリプトはレガシー クラスを使用します。

import groovy.util.XmlSlurper
import groovy.util.XmlParser
def xmlSlurper = new XmlSlurper()
def xmlParser = new XmlParser()

Groovy 4 では、従来のクラスを JPMS 準拠のパッケージ名に置き換えて、次のように例外を解決できます。

import groovy.xml.XmlSlurper
import groovy.xml.XmlParser
def xmlSlurper = new XmlSlurper() 
def xmlParser = new XmlParser()

重要: LogicMonitor は、LogicMonitor が提供する公式モジュールのこの問題を軽減するために、LogicModules のアップデートをリリースしています。カスタマイズされたモジュールまたはコミュニティが提供するモジュールを利用している場合は、有効なパラメータをすべてのデータ構造に渡すようにモジュールを更新する必要があります。

既知の問題

Apache Groovy 4を使用してモジュールを実行し、 日付フォーマット()、次の例外がスローされます。

java.lang.RuntimeException: org.codehaus.groovy.control.MultipleCompilationErrorsException: startup failed: 

重要: LogicMonitor は、LogicMonitor が提供する公式モジュールのこの問題を軽減するために、LogicModules のアップデートをリリースしています。カスタマイズされたモジュールまたはコミュニティが提供するモジュールを利用している場合は、有効なパラメータをすべてのデータ構造に渡すようにモジュールを更新する必要があります。

既知の問題

Apache Groovy 4を使用してモジュールを実行し、 日付フォーマット()、次の例外がスローされます。

exception:groovy.lang.MissingMethodException: No signature of method: java.util.Date.format() is applicable for argument types: (String) values: [yyyy-MM-dd'T'HH:mm:ss z]

注意: この問題は、LogicMonitor Collector バージョン 35.400 以降で修正されています。 Apache Groovy 4 を使用してモジュールを実行するときにこの問題を軽減するには、LogicMonitor Collector バージョン 35.400 以降にアップグレードしてください。

資料

強化

追加できます インスタンスをインスタンス グループに移動するときに、インスタンス グループを簡単に作成できます。

セキュリティの設定

強化

電話番号フィールドは2要素認証では必須ではありません

ユーザーに対して 2 要素認証を有効にすると、電話番号の入力は必須ではなくなります。

詳細については、を参照してください。 ユーザー。

強化

LogicMonitor ユーザー アカウント変更通知の強化

名、姓、パスワード、2FA の有効化/無効化、電話番号、API トークン、電子メールの変更時、またはユーザー ステータスが手動で停止に変更されたときに送信される LogicMonitor ユーザー アカウント通知メールには、アクションを実行したユーザーに関する情報が含まれるようになりました。これには次の情報が含まれます。

  • IPアドレス
  • 日付時刻
  • ロジックモニターのロゴ
  • 完全な透明性を確保するために、著作権情報とプライバシーポリシーのリンクを掲載しています。
強化

2要素認証のオプションとして認証アプリを有効にする

この機能を使用すると、ローカルユーザーは、アカウントのセキュリティをさらに強化するために、認証アプリベースの検証を追加できます。ユーザーは、Okta、Google Authenticator、Authyなど、RFC標準に準拠した任意の認証アプリを追加できます。また、2FAが有効になっているユーザーのリストを以下で表示できます。 設定 > ユーザーアクセス > ユーザーと役割 > ユーザー.

2FAアプリを有効にするには、 プロフィール > 2FAアプリを設定する.

詳細については、を参照してください。 2要素認証アプリアクセス.

ユーザーアクセス

セキュリティのアップグレード

すべてのユーザーに2要素認証が必要

環境でシングル サインオン (SSO) を活用していない場合、LogicMonitor ポータルにアクセスできるすべてのユーザーは、ポータルにアクセスするために 2 要素認証 (2FA) を使用する必要があります。XNUMXFA を活用すると、アカウントを保護するためのセキュリティ対策が強化されます。

ご使用の環境で 2FA を使用するには、LogicMonitor アカウントで 2FA をグローバルに有効にし、Authy などのサードパーティ アプリケーションを使用して 2FA アカウント アクセスを設定する必要があります。

2FAを有効にするには、 設定 > セキュリティの設定、そして有効にする すべての役割とユーザーにXNUMX要素認証を要求する.

LogicMonitorアカウントで2FAをグローバルに有効にする方法の詳細については、以下を参照してください。 セキュリティの設定 製品ドキュメントに記載されています。

サードパーティアプリケーションで2FAを設定する方法の詳細については、以下を参照してください。 二要素認証アカウントアクセス 製品ドキュメントに記載されています。

LogicMonitorのセキュリティ要件の詳細については、 重要なセキュリティに関するお知らせ LM コミュニティで。

コンテナ監視リリース

コンテナモニタリング8.1.0は09年2024月XNUMX日にリリースされました。コンテナモニタリングの新機能、機能強化、修正された問題と既知の問題、アップグレード手順の詳細については、以下を参照してください。 コンテナ監視 8.1.0 リリースノート。

LogicModuleリリース

新規および更新された LogicModule は、LogicMonitor ポータルで直接利用できます。 Exchange から新しいモジュールをインストールしたり、My Module Toolbox で既存のモジュールを更新したりできます。詳細については、「」を参照してください。 モジュールのインストールモジュール管理 製品ドキュメントに記載されています。

このセクションでは、このリリースで新しく追加された、このリリースで更新された、または将来のリリースで削除される LogicModule を一覧表示します。LogicModule 機能に関連する変更は、「一般的な更新」セクションに一覧表示されます。

新しいLogicModules

LogicModule名Details
4 つのデータソース:
  – Cato_SDWAN_API
  – Cato_SDWAN_ヘルス
  – Cato_SDWAN_インターフェース
  – Cato_SDWAN_トンネル
2 プロパティソース:
  – カテゴリーを追加_Cato_SDWAN
  – 追加ERI_Cato_SDWAN
Cato SD-WAN の新しい監視、Cato ソケットの GraphQL API ベースの監視。

更新されたLogicModules

LogicModule名Details
2 プロパティソース:
  – addCategory_Juniper_Mist_Device
  – addERI_Juniper_Mist_Device
Juniper_Mist_API データソースの要件について記載するために技術ノートを更新しました。
1 プロパティソース:
  – addCategory_Juniper_Mist_Device
1 トポロジソース:
  – Juniper_Mist_Topology
トポロジ オブザーバーの最初のサイト デバイスではなく最初の組織サイト デバイスを選択するように変更し、最初の Mist 組織サイトが監視ユース ケースに追加されていない場合にトポロジ ソースに適用するカスタム プロパティ mist.topology.observer を許可します。
2 つのデータソース:
  – ジュニパー_ミスト_SDWAN_エッジ_ヘルス
  – ジュニパー_ミスト_SDWAN_エッジ_パフォーマンス
Mist SDWAN デバイスを system.hostname IP アドレスで識別できるように変更しました。
1 つのデータソース:
  – CommVault_Windows_サービス
表示名ではなく名前に基づいてインスタンスをチェックするようにフィルターを更新しました。
1 プロパティソース:
  – デバイス基本情報
Cisco Firepower デバイスの処理が追加されました。
1 プロパティソース:
  – addCategory_Juniper_Mist_Device
AP の system.categories から「NoPing」を削除しました。注意: system.categories は PropertySources によって削除されないため、このプロパティは既存のデバイスから手動で削除する必要があります。
1 プロパティソース:
  – ConfigCheck_5_Telnet
2 構成ソース:
  – Telnet_Interactive_Dynamic
  – Telnet_Interactive_Standard
変更された Telnet 共通設定により、IAC 要求データが認証行と混在する状況がサポートされるようになりました。
更新中
1 つのデータソース:
  – HP_MSA_グローバルステータス
ステータスデータポイントのテキストマッチを変更し、出力で「: OK」ではなく「OK」を探すようにしました。
1 つのデータソース:
  – CommVault_管理コンソール
ユーザー名にバックスラッシュのチェックを追加しました。
1 プロパティソース:
  – Config_Arista_Generic
Common Configs では、Arista EOS でのページ分割を回避しようとするようになりました。
1 つのデータソース:
  – Cisco_Meraki_API
セキュリティ アプライアンスが監視されていない場合に、ネットワークごとの不要な API 呼び出しを排除するための検証を追加しました。
1 ログソース:
  – Cisco Catalyst SDWAN アラーム
ログの重大度をログ レベル フィールドにマッピングするように更新されました。
1 つのデータソース:
  – Win2k12_HyperV_ハイパーバイザー統計
メモリ統計が PSCustomObject として表されるときにカウントを正確に決定する機能を追加しました。
更新中
1 つのデータソース:
  – LogicMonitor_ConfigSource_Metrics
3 プロパティソース:
  – ConfigCheck_1_SFTP
  – ConfigCheck_2_SCP
  – ConfigCheck_3_Exec
6 構成ソース:
  – SCP_ダイナミック
  – SCP_標準
  – SFTP_ダイナミック
  – SFTP_標準
  – SSH_Exec_Dynamic
変更された SFTP、SCP、および EXEC 共通設定では、同じ認証、ログ記録、および一般的な処理が使用されるようになりました。
更新中
8 つのデータソース:
  – Cisco_Catalyst_SDWAN_API
  – Cisco_Catalyst_SDWAN_コントロール接続
  – Cisco_Catalyst_SDWAN_ControllerHealth
  – Cisco_Catalyst_SDWAN_コントローラインターフェイス
  – Cisco_Catalyst_SDWAN_DeviceHealth
  – Cisco_Catalyst_SDWAN_ネットワークインターフェイス
  – Cisco_Catalyst_SDWAN_パフォーマンス
  – Cisco_Catalyst_SDWAN_トンネル
1 プロパティソース:
  – addCategory_Cisco_Catalyst_SDWAN
単一のネットワーク インターフェイスのみが報告される問題を解決しました。プロパティ「cisco.sdwan.interfaces.all」を true に設定することで、すべてのネットワーク インターフェイスを表示するオプションのサポートが追加されました。インスタンスがダウンした場合にアラートをアクティブに保つために、状態に関係なくコントローラ インターフェイスとネットワーク インターフェイスが検出されるようになりました。その他の一般的な改善点。

お願い: API モジュールが更新されると、パッケージ内のすべてのモジュールを更新する必要があります。そうしないと、コレクションが壊れます。