ログはどこから来たのでしょうか? Veeam ログ ダイビング

私たちは、ログによるトラブルシューティングという、推測の魅惑的な世界に浸り続けます。 の 前の記事 私たちは基本的な用語の意味に同意し、Veeam の全体的な構造を XNUMX つのアプリケーションとして片目で観察しました。 このタスクのタスクは、ログ ファイルがどのように形成されるか、ログ ファイルにどのような種類の情報が表示されるか、およびログ ファイルがそのように見える理由を理解することです。

この「ログ」とは何だと思いますか? ほとんどの人によると、アプリケーションのログには、ほとんどの場合、裏庭のどこかに繁茂しているが、適切な瞬間に、輝く鎧を着てどこからともなく現れて全員を救う、ある種の全能の存在の役割が割り当てられるべきです。 つまり、各コンポーネントのわずかなエラーから個々のデータベース トランザクションに至るまで、すべてが含まれている必要があります。 そして、エラーの後、それを修正する他の方法がすぐに書かれるようにしました。 これらすべては数メガバイトに収まるはずですが、それ以上は収まりません。 それはただのテキストです！ テキスト ファイルは数十ギガバイトも必要ない、どこかで聞いた話です。

それで、ログは

現実の世界では、ログは単なる診断情報のアーカイブです。 そして、そこに何を保存するか、保存する情報をどこから取得するか、そしてそれがどの程度詳細であるべきかは、開発者自身が決定することになります。 オン/オフのレベルを記録してミニマリズムの道を歩む人もいれば、手の届くものすべてを熱心にかき集める人もいます。 いわゆるログ レベルを選択する機能を備えた中間オプションもありますが、保存したい詳細情報と追加のディスク領域を自分で指定する場合 =) ちなみに、VBR にはそのようなレベルが XNUMX つあります。 そして、信じてください、ディスク上の空き領域で最も詳細なログを記録した場合に何が起こるかを見たくないでしょう。

大丈夫。 何を保存したいのかはおおよそ理解できましたが、当然の疑問が生じます。この情報はどこから入手すればよいのでしょうか? もちろん、私たちは内部プロセスによって自分自身を記録するためのイベントの一部を形成します。 しかし、外部環境との相互作用がある場合はどうすればよいでしょうか? 松葉杖と自転車の地獄に陥らないように、Veeam はすでに発明された発明を発明しない傾向があります。 既製の API、組み込み関数、ライブラリなどが存在する場合は、仕掛けのフェンスを開始する前に既製のオプションを優先します。 後者でも十分ですが。 したがって、ログを分析するときは、エラーの大部分がサードパーティ API、システム コール、およびその他のライブラリからのメッセージにあることを理解することが重要です。 この場合、VBR の役割は、これらのエラーをそのままの状態でログ ファイルに転送することになります。 そして、ユーザーの主なタスクは、どの回線が誰からのもので、この「誰」が何を担当しているかを理解することを学ぶことです。 したがって、VBR ログのエラー コードによって MSDN ページが表示されたとしても、それは問題ありません。

先ほど同意したように、Veeam はいわゆる SQL ベースのアプリケーションです。 これは、すべての設定、すべての情報、そして通常の機能にのみ必要なものすべてがデータベースに保存されることを意味します。 したがって、単純な真実は、ログにないものはデータベースにある可能性が最も高いということです。 しかし、これも特効薬ではありません。Veeam コンポーネントのローカル ログやデータベースに存在しないものもあります。 したがって、ホストのログ、ローカル マシンのログ、およびバックアップと復元のプロセスに関係するすべてのログを調査する方法を学ぶ必要があります。 また、必要な情報がどこにも見つからないこともあります。 それがその方法です。 

このような API の例

このリストは例外的に完全であることを目指しているわけではないため、このリストから究極の真実を探す必要はありません。 その目的は、当社の製品で使用されている最も一般的なサードパーティ API とテクノロジーを示すことだけです。

で始めましょう ヴイエムウェア. 

リストの最初に挙げられるのは、 vSphere API。 認証、階層の読み取り、スナップショットの作成と削除、マシンに関する情報の要求などに使用されます。 ソリューションの機能は非常に幅広いため、バージョンについては VMware vSphere API リファレンスをお勧めします。 5.5 и 6.0。 最新バージョンについては、すべて Google で検索するだけです。

VIX API。 ハイパーバイザーの黒魔術。これには別の機能があります。 エラーリスト。 ネットワーク経由でホスト上のファイルに接続せずにファイルを操作するための VMware API。 これより適切な通信チャネルがないマシンにファイルを配置する必要がある場合の最後の手段。 ファイルが大きく、ホストに負荷がかかると、大変なことになります。 ただし、ここでは、56,6 Kb/s であっても 0 Kb/s よりも優れているというルールが機能します。 Hyper-V では、これは PowerShell Direct と呼ばれます。 でもそれは前だけだった

vSpehere Web サービス API vSphere 6.0 以降 (この API がバージョン 5.5 で初めて導入されて以来)、vSphere XNUMX はゲスト マシンの操作に使用され、ほぼどこでも VIX に取って代わりました。 実際、これは vSphere を管理するための別の API です。 興味のある方は勉強することをお勧めします 素晴らしい マニュアル。 

VDDK (仮想ディスク開発キット)。 この記事で部分的に説明したライブラリ статье。 仮想ディスクの読み取りに使用されます。 かつては VIX の一部でしたが、時間の経過とともに別の商品に移行されました。 ただし、後継者として、VIX と同じエラー コードを使用します。 しかし、何らかの理由で、SDK 自体にはこれらのエラーに関する説明がありません。 したがって、他のコードによる VDDK エラーは、バイナリ コードから XNUMX 進コードへの変換にすぎないことが経験的に判明しました。 これは XNUMX つの部分で構成されています。前半はコンテキストに関する文書化されていない情報であり、後半は従来の VIX / VDDK エラーです。 たとえば、次のようになります。

VDDK error: 21036749815809.Unknown error

次に、これを大胆に 132200000001 進数に変換し、132200 を取得します。情報のない 1 の始まりを単純に破棄し、残りがエラー コード (VDDK XNUMX: 不明なエラー) になります。 最も頻繁に発生する VDDK エラーについては、つい最近、別のエラーが発生しました。 記事.

それでは見てみましょう ウィンドウズ.

ここでは、私たちにとって最も必要で重要なものはすべて標準規格の中にあります。 イベントビューア。 ただし、問題が 5 つあります。長い伝統に従って、Windows はエラーの全文を記録せず、その番号のみを記録します。 たとえば、エラー 1722 は「アクセスが拒否されました」、10060 は「RPC サーバーが利用できません」、XNUMX は「接続がタイムアウトしました」です。 もちろん、最も有名なものを覚えていれば素晴らしいのですが、これまで見たことのないものはどうでしょうか? 

そして、人生が蜂蜜のように思われないように、エラーもプレフィックス 0x8007 を付けて 0 進数形式で保存されます。 たとえば、8007000x14e は実際には XNUMX、メモリ不足です。 なぜ、誰のためにこのようなことが行われたのかは謎に包まれています。 ただし、エラーの完全なリストは、SMS なしで無料でダウンロードできます。 開発センター.

ちなみに、0x8007 だけでなく、他のプレフィックスが存在する場合もあります。 このような悲しい状況では、HRESULT (「結果ハンドル」) を理解するには、さらに深く掘り下げる必要があります。 ドキュメンテーション 開発者向け。 普段の生活では、これを行うことはお勧めしませんが、突然壁に押し付けられた場合、または単に興味がある場合は、どうすればよいかわかります。

しかし、マイクロソフトの同志たちは私たちを少し憐れんで、世界にその有用性を示してくれました。 ERR。 これは、Google を使用せずにエラー コードを人間に翻訳できるコンソールの小さな幸福です。 それはこのように動作します。

C:UsersrootDesktop>err.exe 0x54f
# for hex 0x54f / decimal 1359
  ERROR_INTERNAL_ERROR                                           winerror.h
# An internal error occurred.
# as an HRESULT: Severity: SUCCESS (0), FACILITY_NULL (0x0), Code 0x54f
# for hex 0x54f / decimal 1359
  ERROR_INTERNAL_ERROR                                           winerror.h
# An internal error occurred.
# 2 matches found for "0x54f"

当然の疑問が生じます。なぜすぐに復号化をログに書き込まず、これらの謎のコードを残しておくのでしょうか。 答えはサードパーティのアプリケーションにあります。 WinAPI 呼び出しを自分でプルする場合、その応答を解読するのは難しくありません。これには特別な WinAPI 呼び出しさえ存在します。 しかし、すでに述べたように、応答としてのみ私たちに届くものはすべてログに記録されます。 そしてここで、それを解読するには、この意識の流れを常に監視し、そこから Windows エラーのある部分を取り出し、それらを解読して貼り付け直す必要があります。 正直に言うと、最もエキサイティングなアクティビティではありません。

Windows ファイル管理 API ファイルを操作するときにあらゆる方法で使用されます。 ファイルの作成、削除、書き込みのために開く、属性の操作など。

上記の通り PowerShell ダイレクト Hyper-V の世界における VIX API の類似物として。 残念ながら、それほど柔軟性がありません。機能に多くの制限があり、ホストのすべてのバージョンやすべてのゲストで動作するとは限りません。

RPC (リモート プロシージャ コール) WIndows を使ったことがある人で、RPC 関連のエラーを見たことがない人はいないと思います。 よく誤解されていますが、これは単一のプロトコルではなく、多くのパラメータを満たすクライアント/サーバー プロトコルです。 ただし、ログに RPC エラーがある場合、90% の確率で、DCOM (分散コンポーネント オブジェクト モデル) の一部である Microsoft RPC からのエラーです。 このトピックに関する膨大な量のドキュメントはネット上で見つけることができますが、その大部分はかなり古いものです。 ただし、このトピックについて学びたいという強い欲求がある場合は、記事をお勧めします。 RPCとは何ですか?, 認定条件 RPCワークス そして長いリスト RPC エラー.

ログに記録される RPC エラーの主な原因は、VBR コンポーネント間 (サーバー > プロキシなど) の通信試行の失敗であり、ほとんどの場合は通信の問題が原因です。

すべてのトップのうちのトップは、「RPC サーバーが利用できません (1722)」というエラーです。 簡単に言えば、クライアントはサーバーとの接続を確立できませんでした。 どのように、そしてなぜ - 単一の答えはありませんが、通常、認証またはポート 135 へのネットワーク アクセスに問題があります。後者は、動的ポート割り当てを備えたインフラストラクチャで一般的です。 このトピックに関しては、次のようなものもあります。 別のHF。 そしてマイクロソフトは ボリュームのあるガイド 失敗の原因を見つけるために。

1753 番目に多いエラー: エンドポイント マッパーから利用できるエンドポイントはもうありません (XNUMX)。 RPC クライアントまたはサーバーは、それ自体にポートを割り当てることができませんでした。 通常、サーバー (この場合はゲスト マシン) が、終了した狭い範囲からポートを動的に割り当てるように構成されている場合に発生します。 また、クライアント側 (この場合は VBR サーバー) からログインした場合、これは VeeamVssAgent が起動しなかったか、RPC インターフェイスとして登録されなかったことを意味します。 この話題にもあります 別のHF.

さて、上位 3 つの RPC エラーを完了するには、RPC 関数呼び出しが失敗した (1726) ことを思い出してください。 接続は確立されているが、RPC 要求が処理されていない場合に表示されます。 たとえば、私たちは VSS の状況に関する情報を要求します (突然今、そこに影の地雷が作られており、私たちは登ろうとしています)。そして、私たちに応じて沈黙して無視します。

WindowsテープバックアップAPI テープ ライブラリまたはドライブを操作するために必要です。 冒頭で述べたように、私たちは独自のドライバーを作成し、各デバイスのサポートに苦労することを嬉しく思っていません。 したがって、vim には独自のドライバーがありません。 すべては標準 API を通じて行われ、そのサポートはハードウェア ベンダー自身によって実装されます。 はるかに論理的ですよね?

SMB / CIFS 誰もが、CIFS (Common Internet File System) が SMB (Server Message Block) のプライベート バージョンであることを覚えているわけではありませんが、習慣でこれらを並べて書きます。 したがって、これらの概念を一般化することに何も問題はありません。 Samba はすでに LinuxUnix 実装であり、独自の特徴がありますが、余談になります。 ここで重要なことは、Veeam が UNC パス (サーバー ディレクトリ) に何かを書き込むように要求すると、サーバーは mup や mrxsmb などのファイル システム ドライバーの階層を使用してボールに書き込むことです。 したがって、これらのドライバーでもエラーが発生します。

それなしではやっていけない Winsock API。 ネットワーク経由で何かを行う必要がある場合、VBR は Windows Socket API (一般に Winsock として知られています) を通じて機能します。 したがって、ログに大量の IP:Port が表示されれば、これがそれです。 公式ドキュメントには、可能性のあるリストが記載されています エラー.

上記の通り WMI (Windows Management Instrumentation) は、Windows 世界のあらゆるものとすべての人を管理するための一種の万能 API です。 たとえば、Hyper-V を使用する場合、ホストへのほぼすべてのリクエストは Hyper-V を通過します。 一言で言えば、それは絶対にかけがえのないものであり、その能力は非常に強力です。 どこで何が壊れているのかを見つけるには、組み込みの WBEMtest.exe ツールが非常に役立ちます。

そしてリストの最後ですが、決して重要性が低いわけではありません - VSSの (ボリューム シャドウ ストレージ)。 このテーマは、これまでに多くの文書が書かれてきたのと同じくらい、尽きることがなく、謎に満ちています。 シャドウ コピーは、本質的には特殊なタイプのスナップショットとして最も簡単に理解されます。 彼のおかげで、VMware でアプリケーション整合性のあるバックアップを作成でき、Hyper-V ではほぼすべてのバックアップを作成できます。 VSS については別の記事を作成する予定ですが、今のところは読んでみてください。 この説明。 だって、気をつけてね。 VSS をすぐに理解しようとすると、脳損傷につながる可能性があります。

これについては、もしかしたらやめてもいいかもしれません。 最も基本的なことを説明するタスクは完了したと考えているので、次の章ですでにログを見ていきます。 ただし、ご質問がある場合は、コメント欄でお気軽にお問い合わせください。

出所： habr.com