로그의 출처는 어디입니까? 빔 로그 다이빙

로그로 문제를 해결하고 추측하는 매혹적인 세계에 계속 몰입합니다. 안에 이전 기사 우리는 기본 용어의 의미에 동의하고 Veeam의 전체 구조를 단일 애플리케이션으로 한 눈에 살펴보았습니다. 이 작업은 로그 파일이 어떻게 형성되는지, 어떤 종류의 정보가 로그 파일에 표시되는지, 왜 그렇게 보이는지 파악하는 것입니다.

이 "로그"가 무엇이라고 생각하십니까? 대부분에 따르면 모든 응용 프로그램의 로그에는 대부분의 시간이 뒷마당 어딘가에서 식생하지만 적시에 빛나는 갑옷을 입고 갑자기 나타나 모든 사람을 구하는 일종의 전능 한 개체의 역할이 할당되어야합니다. 즉, 각 구성 요소의 사소한 오류에서 개별 데이터베이스 트랜잭션에 이르기까지 모든 것을 포함해야 합니다. 그리고 오류가 발생한 후 즉시 수정 방법을 기록했습니다. 그리고 이 모든 것이 몇 메가바이트에 맞아야 합니다. 그냥 텍스트입니다! 텍스트 파일은 수십 기가바이트를 차지할 수 없습니다. 어디선가 들었거든요!

그래서 로그

실제로 로그는 진단 정보의 아카이브일 뿐입니다. 거기에 무엇을 저장할지, 저장을 위한 정보를 어디서 얻을지, 얼마나 상세해야 하는지는 개발자 스스로 결정해야 합니다. 누군가는 ON/OFF 수준의 기록을 남기며 미니멀리즘의 길을 걷고, 누군가는 닿을 수 있는 모든 것을 부지런히 긁어모은다. 소위 로깅 수준을 선택할 수 있는 중간 옵션도 있지만 저장하려는 세부 정보와 추가 디스크 공간을 직접 지정하면 =) VBR에는 XNUMX개의 수준이 있습니다. 그리고 저를 믿으세요. 디스크의 여유 공간이 있는 가장 상세한 로깅으로 어떤 일이 발생하는지 보고 싶지 않을 것입니다.

괜찮은. 우리는 우리가 무엇을 저장하고 싶은지 대략적으로 이해했지만 합법적인 질문이 생깁니다. 이 정보를 어디서 얻을 수 있습니까? 물론 우리는 내부 프로세스에 의해 스스로를 기록하는 이벤트의 일부를 구성합니다. 그러나 외부 환경과의 상호 작용이 있을 때 무엇을 해야 할까요? Veeam은 목발과 자전거의 지옥에 빠지지 않기 위해 이미 발명된 발명품을 발명하지 않는 경향이 있습니다. 미리 만들어진 API, 내장 함수, 라이브러리 등이 있을 때마다 우리는 장치를 울타리하기 전에 미리 만들어진 옵션을 우선적으로 사용할 것입니다. 후자로도 충분하지만. 따라서 로그를 분석할 때 가장 많은 오류가 타사 API, 시스템 호출 및 기타 라이브러리의 메시지에 있다는 점을 이해하는 것이 중요합니다. 이 경우 VBR의 역할은 이러한 오류를 있는 그대로 로그 파일에 전달하는 것입니다. 그리고 사용자의 주된 임무는 어떤 라인이 누구에게서 왔는지, 그리고 이 "누가"가 무엇을 담당하는지 이해하는 법을 배우는 것입니다. 따라서 VBR 로그의 오류 코드가 MSDN 페이지로 이동하는 경우 괜찮고 올바른 것입니다.

이전에 합의한 대로 Veeam은 소위 SQL 기반 애플리케이션입니다. 이것은 모든 설정, 모든 정보 및 일반적으로 정상적인 기능에만 필요한 모든 것, 즉 모든 것이 데이터베이스에 저장됨을 의미합니다. 따라서 간단한 사실은 로그에 없는 것이 데이터베이스에 있을 가능성이 높다는 것입니다. 그러나 이것은 만병통치약도 아닙니다. 어떤 것은 Veeam 구성 요소의 로컬 로그나 데이터베이스에 없습니다. 따라서 호스트 로그, 로컬 시스템의 로그 및 백업 및 복원 프로세스와 관련된 모든 로그를 연구하는 방법을 배워야 합니다. 또한 필요한 정보가 전혀 제공되지 않는 경우도 발생합니다. 그 방법입니다. 

그러한 API의 몇 가지 예

이 목록은 예외적으로 완전한 것을 목표로 하지 않으므로 그 목록에서 궁극적인 진실을 찾을 필요가 없습니다. 그 목적은 당사 제품에 사용되는 가장 일반적인 타사 API 및 기술을 보여주는 것뿐입니다.

함께 시작하겠습니다. VM웨어. 

목록의 첫 번째는 vSphere API. 인증, 계층 읽기, 스냅샷 생성 및 삭제, 머신에 대한 정보 요청 등에 사용됩니다. 솔루션의 기능은 매우 광범위하므로 버전에 대한 VMware vSphere API 참조를 권장할 수 있습니다. 5.5 и 6.0. 최신 버전의 경우 모든 것이 검색됩니다.

빅스 API. 별도의 하이퍼 바이저의 흑 마법 오류 목록. 네트워크를 통해 파일에 연결하지 않고 호스트의 파일 작업을 위한 VMware API. 더 나은 통신 채널이 없는 시스템에 파일을 넣어야 할 때 최후의 수단으로 사용할 수 있는 옵션입니다. 파일이 크고 호스트가로드되면 고통스럽고 고통 스럽습니다. 그러나 여기에서는 56,6Kb/s도 0Kb/s보다 낫다는 규칙이 적용됩니다. Hyper-V에서는 이를 PowerShell Direct라고 합니다. 그러나 그것은 이전에 불과했습니다.

vSphere 웹 서비스 API vSphere 6.0부터(대략 이 API가 버전 5.5에서 처음 도입된 이후) 게스트 머신과 함께 작동하는 데 사용되며 거의 모든 곳에서 VIX를 대체했습니다. 실제로 이것은 vSphere를 관리하기 위한 또 다른 API입니다. 관심있으신 분들은 공부해보시길 추천드립니다 위대한 수동. 

VDDK (가상 디스크 개발 키트). 이 부분에서 논의된 라이브러리 기사. 가상 디스크를 읽는 데 사용됩니다. 옛날 옛적에 VIX의 일부였지만 시간이 지나면서 별도의 제품으로 옮겨졌습니다. 그러나 상속인으로서 VIX와 동일한 오류 코드를 사용합니다. 그러나 어떤 이유로 SDK 자체에는 이러한 오류에 대한 설명이 없습니다. 따라서 다른 코드의 VDDK 오류는 이진 코드에서 십진 코드로의 변환일 뿐이라는 것이 경험적으로 밝혀졌습니다. 두 부분으로 구성됩니다. 첫 번째 부분은 컨텍스트에 대한 문서화되지 않은 정보이고 두 번째 부분은 전통적인 VIX/VDDK 오류입니다. 예를 들어 다음과 같은 경우:

VDDK error: 21036749815809.Unknown error

그런 다음 대담하게 이것을 132200000001진수로 변환하고 132200을 얻습니다. 정보가 없는 1의 시작 부분을 버리고 나머지는 오류 코드(VDDK XNUMX: 알 수 없는 오류)가 됩니다. 가장 빈번한 VDDK 오류에 대해서는 최근에 별도의 기사.

이제 살펴보자 창.

여기에서 우리에게 가장 필요하고 중요한 모든 것은 표준에서 찾을 수 있습니다. 이벤트 뷰어. 그러나 한 가지 문제가 있습니다. 오랜 전통에 따르면 Windows는 오류의 전체 텍스트를 기록하지 않고 번호만 기록합니다. 예를 들어 오류 5는 "액세스 거부", 1722는 "RPC 서버를 사용할 수 없음", 10060은 "연결 시간 초과"입니다. 물론 가장 유명한 것을 기억하면 좋지만 지금까지 보지 못한 것은 어떻습니까? 

그리고 인생이 전혀 꿀처럼 보이지 않도록 오류도 접두사 0x8007과 함께 0진수 형식으로 저장됩니다. 예를 들어 8007000x14e는 실제로 XNUMX, 메모리 부족입니다. 왜 그리고 누구를 위해 이런 일이 일어났는지는 어둠에 가려진 수수께끼입니다. 그러나 전체 오류 목록은 SMS 없이 무료로 다운로드할 수 있습니다. 데브센터.

그건 그렇고, 때로는 0x8007뿐만 아니라 다른 접두사가 있습니다. 이러한 슬픈 상황에서 HRESULT("결과 핸들")를 이해하려면 문서 개발자를 위해. 일상 생활에서는 이렇게 하라고 조언하지 않지만 갑자기 벽을 눌렀거나 궁금하다면 이제 무엇을 해야할지 알 것입니다.

그러나 Microsoft의 동지들은 우리를 조금 불쌍히 여기고 세상에 유틸리티를 보여주었습니다. 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 파일로 작업할 때 가능한 모든 방법으로 사용됩니다. 파일 생성, 삭제, 쓰기를 위해 열기, 속성 작업 등.

위에 언급했듯이 파워쉘 다이렉트 Hyper-V 세계에서 VIX API의 아날로그로. 불행히도 그다지 유연하지 않습니다. 기능에 대한 많은 제한이 있으며 모든 게스트가 아닌 호스트의 모든 버전에서 작동하지 않습니다.

RPC (원격 프로시저 호출) WIndows를 사용해 본 사람 중 RPC 관련 오류를 본 적이 없는 사람은 단 한 명도 없다고 생각합니다. 일반적인 오해에도 불구하고 이것은 단일 프로토콜이 아니라 여러 매개변수를 충족하는 클라이언트-서버 프로토콜입니다. 그러나 로그에 RPC 오류가 있는 경우 90%는 DCOM(Distributed Component Object Model)의 일부인 Microsoft RPC 오류일 것입니다. 인터넷에서 이 주제에 대한 엄청난 양의 문서를 찾을 수 있지만 대부분의 문서는 상당히 구식입니다. 하지만 주제를 공부하고 싶은 열망이 있다면 기사를 추천 할 수 있습니다 RPC란 무엇입니까?, 방법 RPC 웍스 긴 목록 RPC 오류.

로그에 있는 RPC 오류의 주요 원인은 VBR 구성 요소(예: 서버 > 프록시) 간의 통신 시도 실패이며 대부분 통신 문제로 인해 발생합니다.

모든 상단 중 상단 상단은 RPC 서버를 사용할 수 없습니다(1722) 오류입니다. 간단히 말해서 클라이언트는 서버와의 연결을 설정할 수 없습니다. 방법과 이유 - 단일 답변은 없지만 일반적으로 인증 또는 포트 135에 대한 네트워크 액세스 문제입니다. 후자는 동적 포트 할당이 있는 인프라에 일반적입니다. 이 주제에는 심지어 별도의 HF. 그리고 마이크로소프트는 방대한 가이드 실패의 원인을 찾기 위해.

두 번째로 많이 발생하는 오류: 끝점 매퍼에서 사용할 수 있는 끝점이 더 이상 없습니다(1753). 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를 포함한 파일 시스템 드라이버의 계층 구조를 사용하여 볼에 씁니다. 따라서 이러한 드라이버도 오류를 생성합니다.

없이는 할 수 없어 윈속 API. 네트워크를 통해 무언가를 수행해야 하는 경우 VBR은 일반적으로 Winsock으로 알려진 Windows 소켓 API를 통해 작동합니다. 따라서 로그에 많은 IP:Port가 표시되면 이것이 바로 그것입니다. 공식 문서에는 가능한 좋은 목록이 있습니다. 오류.

위에 언급했듯이 WMI (Windows Management Instrumentation)은 Windows 세계의 모든 것과 모든 사람을 관리하기 위한 일종의 전능한 API입니다. 예를 들어 Hyper-V로 작업할 때 호스트에 대한 거의 모든 요청이 이를 통과합니다. 한마디로, 그것은 절대적으로 대체 불가능하고 그 능력이 매우 강력합니다. 내장된 WBEMtest.exe 도구는 어디서 무엇이 고장났는지 찾는데 많은 도움이 됩니다.

그리고 목록의 마지막이지만 결코 중요하지 않은 것은 아닙니다. VSS (볼륨 섀도 스토리지). 주제는 그것에 대해 쓰여진 많은 문서만큼이나 무궁무진하고 신비합니다. 섀도 복사본은 본질적으로 특수한 유형의 스냅샷으로 가장 간단하게 이해됩니다. 그 덕분에 VMware와 Hyper-V의 거의 모든 것에서 애플리케이션 일관성을 갖춘 백업을 만들 수 있습니다. VSS에 대한 약간의 압박으로 별도의 기사를 만들 계획이 있지만 지금은 읽을 수 있습니다. 이 설명. 조심하세요. 순식간에 VSS를 이해하려고 하면 뇌 손상을 입을 수 있습니다.

이것에 대해 아마도 멈출 수 있습니다. 가장 기본적인 사항을 설명하는 작업이 완료된 것으로 간주하므로 다음 장에서 이미 로그를 살펴 보겠습니다. 그러나 질문이 있으시면 의견에 자유롭게 질문하십시오.

출처 : habr.com