Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Quell-Deklarationen

In Amazon Kinesis Agent für Microsoft WindowsQuell-DeklarationenGeben Sie an, wo und welche Protokoll-, Ereignis- und Metrikdaten gesammelt werden sollen. Außerdem geben sie optional Informationen für die Analyse dieser Daten an, sodass sie umgewandelt werden können. Die folgenden Abschnitte beschreiben Konfigurationen für die integrierten Quell-Typen, die in Kinesis Agent für Windows verfügbar sind. Da Kinesis Agent für Windows erweiterbar ist, können Sie benutzerdefinierte Quelltypen hinzufügen. Jeder Quelltyp erfordert in der Regel bestimmte Schlüssel-Wert-Paare in den Konfigurationsobjekten, die für diesen Quelltyp relevant sind.

Alle Quell-Deklarationen müssen mindestens die folgenden Schlüssel-Wert-Paare enthalten:

Beispiele für vollständige Konfigurationsdateien, die verschiedene Arten von Quell-Deklarationen verwenden, finden Sie unter Streamen aus verschiedenen Quellen an Kinesis Data Streams.

DirectorySource-Konfiguration

Overview

Der DirectorySource-Quelltyp sammelt Protokolle aus Dateien, die im angegebenen Verzeichnis gespeichert sind. Da es Protokolldateien in vielen verschiedenen Formate gibt, können Sie mit der DirectorySource-Deklaration das Format der Daten in der Protokolldatei angeben. Anschließend können Sie den Inhalt des Protokolls in ein Standardformat, z. B. JSON oder XML, transformieren, bevor Sie ihn an verschiedene AWS-Services streamen.

Es folgt ein Beispiel für eine DirectorySource-Deklaration:

{
	   "Id": "myLog",
	   "SourceType": "DirectorySource",
	   "Directory": "C:\\Program Data\\MyCompany\\MyService\\logs",
	   "FileNameFilter": "*.log",
	   "IncludeSubdirectories": true,
	   "IncludeDirectoryFilter": "cpu\\cpu-1;cpu\\cpu-2;load;memory",
	   "RecordParser": "Timestamp",
	   "TimestampFormat": "yyyy-MM-dd HH:mm:ss.ffff",
	   "Pattern": "\\d{4}-\\d{2}-\\d(2}",
	   "ExtractionPattern": "",
	   "TimeZoneKind": "UTC",
	   "SkipLines": 0,
	   "Encoding": "utf-16",
	   "ExtractionRegexOptions": "Multiline"
}

Alle DirectorySource-Deklarationen können die folgenden Schlüssel-Wert-Paare angeben:

Regex-Datensatz-Parser

Sie können unstrukturierte Textprotokolle mit dem Regex-Datensatz-Parser zusammen mit den TimestampFormat–, Pattern- und ExtractionPattern-Schlüssel-Wert-Paaren analysieren. Angenommen, Ihre Protokolldatei sieht folgendermaßen aus:

[FATAL][2017/05/03 21:31:00.534][0x00003ca8][0000059c][][ActivationSubSystem][GetActivationForSystemID][0] 'ActivationException.File: EQCASLicensingSubSystem.cpp'
[FATAL][2017/05/03 21:31:00.535][0x00003ca8][0000059c][][ActivationSubSystem][GetActivationForSystemID][0] 'ActivationException.Line: 3999'   
  

Sie können in diesem Fall den folgenden regulären Ausdruck für das Pattern-Schlüssel-Wert-Paar angeben, um die Protokolldatei leichter in einzelne Protokolldatensätze aufzuteilen:

^\[\w+\]\[(?<TimeStamp>\d{4}/\d{2}/\d{2} \d{2}:\d{2}:\d{2}\.\d{3})\]   
  

Dieser reguläre Ausdruck weist folgende Sequenz auf:

Sie können das folgende Format für das TimestampFormat-Schlüssel-Wert-Paar angeben, um den Zeitstempel in Textform in ein Datum und eine Uhrzeit umzuwandeln:

yyyy/MM/dd HH:mm:ss.fff

Sie können den folgenden regulären Ausdruck zum Extrahieren der Felder des Protokolldatensatzes über das ExtractionPattern-Schlüssel-Wert-Paar extrahieren.

^\[(?<Severity>\w+)\]\[(?<TimeStamp>\d{4}/\d{2}/\d{2} \d{2}:\d{2}:\d{2}\.\d{3})\]\[[^]]*\]\[[^]]*\]\[[^]]*\]\[(?<SubSystem>\w+)\]\[(?<Module>\w+)\]\[[^]]*\] '(?<Message>.*)'$

Dieser reguläre Ausdruck weist die folgenden Gruppen in der Sequenz auf:

Die folgende Quell-Deklaration kombiniert diese regulären Ausdrücke und das Format für Datum und Uhrzeit in den vollständigen Anleitungen für Kinesis Agent für Windows zum Analysieren dieser Art von Protokolldatei.

{
    "Id": "PrintLog",
    "SourceType": "DirectorySource",
    "Directory": "C:\\temp\\PrintLogTest",
    "FileNameFilter": "*.log",
    "RecordParser": "Regex",
    "TimestampFormat": "yyyy/MM/dd HH:mm:ss.fff",
    "Pattern": "^\\[\\w+\\]\\[(?<TimeStamp>\\d{4}/\\d{2}/\\d{2} \\d{2}:\\d{2}:\\d{2}\\.\\d{3})\\]",
    "ExtractionPattern": "^\\[(?<Severity>\\w+)\\]\\[(?<TimeStamp>\\d{4}/\\d{2}/\\d{2} \\d{2}:\\d{2}:\\d{2}\\.\\d{3})\\]\\[[^]]*\\]\\[[^]]*\\]\\[[^]]*\\]\\[(?<SubSystem>\\w+)\\]\\[(?<Module>\\w+)\\]\\[[^]]*\\] '(?<Message>.*)'$",
    "TimeZoneKind": "UTC"
}

Weitere Informationen zu regulären Ausdrücken finden Sie unter Regular Expression Language - Quick Reference in der Microsoft .NET-Dokumentation.

Delimited-Datensatz-Parser

Sie können mit dem Delimited-Datensatz-Parser halbstrukturierte Protokoll- und Datendateien analysieren, bei denen die einzelnen Datenspalten in den einzelnen Datenzeile durch eine konsistente Zeichenfolge voneinander getrennt sind. Beispiel: In CSV-Dateien sind die einzelnen Spaltendaten durch ein Semikolon und bei TSV-Dateien durch ein Tabulatorzeichen voneinander getrennt.

Angenommen, Sie möchten eine Microsoft Protokolldatei im NPS-Datenbankformat analysieren, die von einem Netzwerkrichtlinienserver erstellt wurde. Eine solche Datei könnte in diesem Fall folgendermaßen aussehen:

"NPS-MASTER","IAS",03/22/2018,23:07:55,1,"user1","Domain1\user1",,,,,,,,0,"192.168.86.137","Nate - Test 1",,,,,,,1,,0,"311 1 192.168.0.213 03/15/2018 08:14:29 1",,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,"Use Windows authentication for all users",1,,,,
"NPS-MASTER","IAS",03/22/2018,23:07:55,3,,"Domain1\user1",,,,,,,,0,"192.168.86.137","Nate - Test 1",,,,,,,1,,16,"311 1 192.168.0.213 03/15/2018 08:14:29 1",,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,,"Use Windows authentication for all users",1,,,,

Das folgende Beispiel einer appsettings.json-Konfigurationsdatei enthält eine DirectorySource-Deklaration, die diesen Text mittels eines Delimited-Datensatz-Parsers als Objektdarstellung analysiert. Anschließend streamt sie die Daten im JSON-Format an Kinesis Data Firehose:

{
    "Sources": [
        {
            "Id": "NPS",
            "SourceType": "DirectorySource",
            "Directory": "C:\\temp\\NPS",
            "FileNameFilter": "*.log",
            "RecordParser": "Delimited",
            "Delimiter": ",",
            "Headers": "ComputerName,ServiceName,Record-Date,Record-Time,Packet-Type,User-Name,Fully-Qualified-Distinguished-Name,Called-Station-ID,Calling-Station-ID,Callback-Number,Framed-IP-Address,NAS-Identifier,NAS-IP-Address,NAS-Port,Client-Vendor,Client-IP-Address,Client-Friendly-Name,Event-Timestamp,Port-Limit,NAS-Port-Type,Connect-Info,Framed-Protocol,Service-Type,Authentication-Type,Policy-Name,Reason-Code,Class,Session-Timeout,Idle-Timeout,Termination-Action,EAP-Friendly-Name,Acct-Status-Type,Acct-Delay-Time,Acct-Input-Octets,Acct-Output-Octets,Acct-Session-Id,Acct-Authentic,Acct-Session-Time,Acct-Input-Packets,Acct-Output-Packets,Acct-Terminate-Cause,Acct-Multi-Ssn-ID,Acct-Link-Count,Acct-Interim-Interval,Tunnel-Type,Tunnel-Medium-Type,Tunnel-Client-Endpt,Tunnel-Server-Endpt,Acct-Tunnel-Conn,Tunnel-Pvt-Group-ID,Tunnel-Assignment-ID,Tunnel-Preference,MS-Acct-Auth-Type,MS-Acct-EAP-Type,MS-RAS-Version,MS-RAS-Vendor,MS-CHAP-Error,MS-CHAP-Domain,MS-MPPE-Encryption-Types,MS-MPPE-Encryption-Policy,Proxy-Policy-Name,Provider-Type,Provider-Name,Remote-Server-Address,MS-RAS-Client-Name,MS-RAS-Client-Version",
            "TimestampField": "{Record-Date} {Record-Time}",
            "TimestampFormat": "MM/dd/yyyy HH:mm:ss"
        }
    ],
    "Sinks": [
        {
            "Id": "npslogtest",
            "SinkType": "KinesisFirehose",
            "Region": "us-west-2",
            "StreamName": "npslogtest",
            "Format": "json"
        }
    ],
    "Pipes": [
        {
            "Id": "W3SVCLog1ToKinesisStream",
            "SourceRef": "NPS",
            "SinkRef": "npslogtest"
        }
    ]
}

An Kinesis Data Firehose gestreamt Daten im JSON-Format sehen wie folgt aus:

{
    "ComputerName": "NPS-MASTER",
    "ServiceName": "IAS",
    "Record-Date": "03/22/2018",
    "Record-Time": "23:07:55",
    "Packet-Type": "1",
    "User-Name": "user1",
    "Fully-Qualified-Distinguished-Name": "Domain1\\user1",
    "Called-Station-ID": "",
    "Calling-Station-ID": "",
    "Callback-Number": "",
    "Framed-IP-Address": "",
    "NAS-Identifier": "",
    "NAS-IP-Address": "",
    "NAS-Port": "",
    "Client-Vendor": "0",
    "Client-IP-Address": "192.168.86.137",
    "Client-Friendly-Name": "Nate - Test 1",
    "Event-Timestamp": "",
    "Port-Limit": "",
    "NAS-Port-Type": "",
    "Connect-Info": "",
    "Framed-Protocol": "",
    "Service-Type": "",
    "Authentication-Type": "1",
    "Policy-Name": "",
    "Reason-Code": "0",
    "Class": "311 1 192.168.0.213 03/15/2018 08:14:29 1",
    "Session-Timeout": "",
    "Idle-Timeout": "",
    "Termination-Action": "",
    "EAP-Friendly-Name": "",
    "Acct-Status-Type": "",
    "Acct-Delay-Time": "",
    "Acct-Input-Octets": "",
    "Acct-Output-Octets": "",
    "Acct-Session-Id": "",
    "Acct-Authentic": "",
    "Acct-Session-Time": "",
    "Acct-Input-Packets": "",
    "Acct-Output-Packets": "",
    "Acct-Terminate-Cause": "",
    "Acct-Multi-Ssn-ID": "",
    "Acct-Link-Count": "",
    "Acct-Interim-Interval": "",
    "Tunnel-Type": "",
    "Tunnel-Medium-Type": "",
    "Tunnel-Client-Endpt": "",
    "Tunnel-Server-Endpt": "",
    "Acct-Tunnel-Conn": "",
    "Tunnel-Pvt-Group-ID": "",
    "Tunnel-Assignment-ID": "",
    "Tunnel-Preference": "",
    "MS-Acct-Auth-Type": "",
    "MS-Acct-EAP-Type": "",
    "MS-RAS-Version": "",
    "MS-RAS-Vendor": "",
    "MS-CHAP-Error": "",
    "MS-CHAP-Domain": "",
    "MS-MPPE-Encryption-Types": "",
    "MS-MPPE-Encryption-Policy": "",
    "Proxy-Policy-Name": "Use Windows authentication for all users",
    "Provider-Type": "1",
    "Provider-Name": "",
    "Remote-Server-Address": "",
    "MS-RAS-Client-Name": "",
    "MS-RAS-Client-Version": ""
}   

SysLog-Datensatz-Parser

Für den SysLog-Datensatz-Parser enthält die analysierte Ausgabe aus der Quelle die folgenden Informationen:

Im Folgenden finden Sie ein Beispiel von in das JSON-Format umgewandelten SysLog-Daten:

{
    "SysLogTimeStamp": "Jun 18 01:34:56",
    "Hostname": "myhost1.example.mydomain.com",
    "Program": "mymailservice:",
    "Message": "Info: ICID 123456789 close",
    "TimeStamp": "2017-06-18T01:34.56.000"
}

Summary

Im Folgenden finden Sie eine Zusammenfassung der verfügbaren Schlüssel-Wert-Paare für die DirectorySource-Quelle und die RecordParser, die sich auf diese Schlüssel-Wert-Paare beziehen.

ExchangeLogSource-Konfiguration

Der ExchangeLogSource-Typ wird verwendet, um Protokolle von Microsoft Exchange zu sammeln. Exchange erstellt Protokolle in mehrere verschiedene Protokollformaten. Dieser Quelltyp analysiert alle von ihnen. Es ist zwar auch möglich, sie unter Verwendung des Typs DirectorySource mit dem Datensatz-Parser Regex zu analysieren, aber wesentlich einfacher, ExchangeLogSource zu verwenden. Dies liegt daran, dass Sie für die Protokolldateiformate keine regulären Ausdrücke entwerfen und bereitstellen müssen. Es folgt ein Beispiel für eine ExchangeLogSource-Deklaration:

{
   "Id": "MyExchangeLog",
   "SourceType": "ExchangeLogSource",
   "Directory": "C:\\temp\\ExchangeLogTest",
   "FileNameFilter": "*.log"
}

Alle Exchange-Deklarationen können die folgenden Schlüssel-Wert-Paare angeben:

W3SVCLogSource-Konfiguration

Der Typ W3SVCLogSource wird verwendet, um Protokolle von Internet Information Services (IIS) für Windows zu sammeln.

Es folgt ein Beispiel für eine W3SVCLogSource-Deklaration:

{
   "Id": "MyW3SVCLog",
   "SourceType": "W3SVCLogSource",
   "Directory": "C:\\inetpub\\logs\\LogFiles\\W3SVC1",
   "FileNameFilter": "*.log"
}

Alle W3SVCLogSource-Deklarationen können die folgenden Schlüssel-Wert-Paare angeben:

UlsSource-Configuration

Der UlsSource-Typ wird verwendet, um Protokolle von Microsoft SharePoint zu sammeln. Es folgt ein Beispiel für eine UlsSource-Deklaration:

{
    "Id": "UlsSource",
    "SourceType": "UlsSource",
    "Directory": "C:\\temp\\uls",
    "FileNameFilter": "*.log"
}

Alle UlsSource-Deklarationen können die folgenden Schlüssel-Wert-Paare angeben:

WindowsEventLogSource-Konfiguration

Der Typ WindowsEventLogSource wird verwendet, um Ereignisse vom Windows-Ereignisprotokoll-Service zu sammeln. Es folgt ein Beispiel für eine WindowsEventLogSource-Deklaration:

{
    "Id": "mySecurityLog",
    "SourceType": "WindowsEventLogSource",
    "LogName": "Security"
}

Alle WindowsEventLogSource-Deklarationen können die folgenden Schlüssel-Wert-Paare angeben:

Die analysierte Ausgabe von WindowsEventLogSource enthält die folgenden Informationen:

Es folgt ein Beispiel eines in das JSON-Format umgewandelten Ereignisses:

{[ 
    "EventId": 7036, 
    "Description": "The Amazon SSM Agent service entered the stopped state.", 
    "LevelDisplayName": "Informational", 
    "LogName": "System", 
    "MachineName": "mymachine.mycompany.com", 
    "ProviderName": "Service Control Manager", 
    "TimeCreated": "2017-10-04T16:42:53.8921205Z", 
    "Index": 462335, 
    "UserName": null, 
    "Keywords": "Classic", 
    "EventData": [ 
    "Amazon SSM Agent", 
    "stopped", 
    "rPctBAMZFhYubF8zVLcrBd3bTTcNzHvY5Jc2Br0aMrxxx==" 
]}

WindowSeventLogPollingSource-Konfiguration

WindowsEventLogPollingSourceverwendet einen abfragebasierten Mechanismus, um alle neuen Ereignisse aus dem Ereignisprotokoll zu sammeln, die den konfigurierten Parametern entsprechen. Das Abrufintervall wird dynamisch zwischen 100 ms und 5000 ms aktualisiert, je nachdem, wie viele Ereignisse während der letzten Umfrage gesammelt wurden. Es folgt ein Beispiel für eine WindowsEventLogPollingSource-Deklaration:

{
    "Id": "MySecurityLog",
    "SourceType": "WindowsEventLogPollingSource",
    "LogName": "Security",
    "IncludeEventData": "true",
    "Query": "",
    "CustomFilters": "ExcludeOwnSecurityEvents"
}

Alle WindowsEventLogPollingSource-Deklarationen können die folgenden Schlüssel-Wert-Paare angeben:

WindowsETWEventSource-Konfiguration

Der WindowsETWEventSource-Typ wird verwendet, um Ereignisablaufverfolgungen für Anwendungen und Services mithilfe der Funktion Event Tracing for Windows (ETW) zu sammeln. Weitere Informationen finden Sie unter Event Tracing in der Windows-Dokumentation.

Es folgt ein Beispiel für eine WindowsETWEventSource-Deklaration:

{
    "Id": "ClrETWEventSource",
    "SourceType": "WindowsETWEventSource",
    "ProviderName": "Microsoft-Windows-DotNETRuntime",
    "TraceLevel": "Verbose",
    "MatchAnyKeyword": 32768
}

Alle WindowsETWEventSource-Deklarationen können die folgenden Schlüssel-Wert-Paare angeben:

Die Ausgabe von WindowsETWEventSource enthält die folgenden Informationen für jedes Ereignis:

Es folgt ein Beispiel eines in das JSON-Format umgewandelten Ereignisses:

{ 
     "EventName": "Exception/Start", 
     "ProviderName": "Microsoft-Windows-DotNETRuntime", 
     "FormattedMessage": "ExceptionType=System.Exception;\r\nExceptionMessage=Intentionally unhandled exception.;\r\nExceptionEIP=0x2ab0499;\r\nExceptionHRESULT=-2,146,233,088;\r\nExceptionFlags=CLSCompliant;\r\nClrInstanceID=9 ",
     "ProcessID": 3328, 
     "ExecutingThreadID": 6172, 
     "MachineName": "MyHost.MyCompany.com", 
     "Payload": 
      { 
        "ExceptionType": "System.Exception", 
        "ExceptionMessage": "Intentionally unhandled exception.", 
        "ExceptionEIP": 44762265, 
        "ExceptionHRESULT": -2146233088, 
        "ExceptionFlags": 16, 
        "ClrInstanceID": 9 
      } 
}

WindowsPerformanceCounterSource-Konfiguration

Der WindowsPerformanceCounterSource-Typ erfasst die Leistungsindikator-Metriken von Windows. Es folgt ein Beispiel für eine WindowsPerformanceCounterSource-Deklaration:

{
	"Id": "MyPerformanceCounter",
	"SourceType": "WindowsPerformanceCounterSource",
	"Categories": [{
			"Category": "Server",
			"Counters": ["Files Open", "Logon Total", "Logon/sec", "Pool Nonpaged Bytes"]
		},
		{
			"Category": "System",
			"Counters": ["Processes", "Processor Queue Length", "System Up Time"]
		},
		{
			"Category": "LogicalDisk",
			"Instances": "*",
			"Counters": [
				"% Free Space", "Avg. Disk Queue Length",
				{
					"Counter": "Disk Reads/sec",
					"Unit": "Count/Second"
				},
				"Disk Writes/sec"
			]
		},
		{
			"Category": "Network Adapter",
			"Instances": "^Local Area Connection\* \d$",
			"Counters": ["Bytes Received/sec", "Bytes Sent/sec"]
		}
	]
}

Alle WindowsPerformanceCounterSource-Deklarationen können die folgenden Schlüssel-Wert-Paare angeben:

WindowsPerformanceCounterSourceKann nur mit einer Pipe verwendet werden, die eine Amazon CloudWatch ch-Senke angibt. Verwenden Sie eine separate Senke, wenn integrierte -Metriken von Kinesis Agent für Windows auch zu CloudWatch gestreamt werden. Überprüfen Sie nach dem Start des -Service das Kinesis Agent für Windows-Protokoll, welche Einheiten für Leistungsindikatoren abgeleitet wurden, wenn keine Einheiten in denWindowsPerformanceCounterSource-Deklarationen. Bestimmen Sie mithilfe von PowerShell die gültigen Namen für Kategorien, Instances und Leistungsindikatoren.

Um Informationen zu allen Kategorien, einschließlich mit Leistungsindikatorsätzen verknüpften Leistungsindikatoren, anzuzeigen, führen Sie diesen Befehl in einem PowerShell-Fenster aus:

    Get-Counter -ListSet * | Sort-Object
   

Um zu bestimmen, welche Instances für jeden der Leistungsindikatoren im Leistungsindikatorsatz verfügbar sind, führen Sie in einem PowerShell-Fenster einen Befehl wie den folgenden aus:

    Get-Counter -Counter "\Process(*)\% Processor Time"
   

Der Wert des Counter-Parameters sollte einer der Pfade aus einem untergeordneten PathsWithInstances-Elements sein, das durch den vorherigen Get-Counter -ListSet-Befehlsaufruf aufgeführt wurde.

Integrierte Quelle von Kinesis Agent für Windows -Metriken: Quelle

Zusätzlich zu gewöhnlichen Metrikquellen wie demWindowsPerformanceCounterSourceTyp (sieheWindowsPerformanceCounterSource-Konfiguration), kann der -Senkentyp von CloudWatch Metriken von einer besonderen Quelle erhalten, die Metriken zu Kinesis Agent für Windows selbst erfasst. Kinesis Agent für Windows-Metriken sind auch im BereichKinesisTap-Kategorie von Windows-Leistungsindikatoren.

DieMetricsFilterDas -Schlüssel-Wert-Paar für die CloudWatch enken-Deklarationen gibt an, welche Metriken von der integrierten -Kinesis Agent für Windows-Metrikenquelle an CloudWatch gestreamt werden. Der Wert ist eine Zeichenfolge mit einem oder mehreren Filterausdrücken, die durch Semikolons getrennt sind, z. B.:

"MetricsFilter": "FilterExpression1;FilterExpression2"

Eine Metrik, die mit einem oder mehreren Filterausdrücken übereinstimmt, wird zu CloudWatch gestreamt.

Einzel-Instance-Metriken sind global und nicht an eine bestimmte Quelle oder Senke gebunden. Mehrfach-Instance-Metriken sind dimensional basierend auf der Id der Quell- oder Senken-Deklaration. Jeder Quell- oder Senkentyp kann über einen anderen Satz von Metriken verfügen.

Eine Liste integrierter -Metriknamen von Kinesis Agent für Windows finden Sie unterListe der Kinesis Agent für Windows-Metriken.

Bei Einzel-Instance-Metriken ist der Filterausdruck der Name der Metrik, z. B.:

"MetricsFilter": "SourcesFailedToStart;SinksFailedToStart"
      

Bei Mehrfach-Instance-Metriken ist der Filterausdruck der Name der Metrik, ein Punkt (.) und dann die Id der Quell- oder Senken-Deklaration, von der die Metrik generiert wurde. Angenommen, die Id einer Senken-Deklaration lautet MyFirehose:

"MetricsFilter": "KinesisFirehoseRecordsFailedNonrecoverable.MyFirehose"      
      

Sie können in diesem Fall spezielle Platzhaltermuster verwenden, die zwischen Einzel-Instance- und Mehrfach-Instance-Metriken unterscheiden.

Das folgende Beispiel entspricht allen Einzel-Instance-Metriken:

"MetricsFilter": "*"

Da ein Sternchen keinem Punkt entspricht, werden nur Einzel-Instance-Metriken eingeschlossen.

Das folgende Beispiel entspricht allen Mehrfach-Instance-Metriken:

"MetricsFilter": "*.*"

Das folgende Beispiel entspricht allen Metriken (Einzel- und Mehrfach-Instance):

"MetricsFilter": "*;*.*"

Das folgende Beispiel fasst alle Mehrfach-Instance-Metriken für alle Quellen und Senken zusammen:

"MetricsFilter": "*._Total"

Im folgenden Beispiel werden alle Kinesis Data Firehose -Metriken für alle Kinesis Data Firehose Senken aggregiert:

"MetricsFilter": "*Firehose*._Total"

Das folgende Beispiel entspricht allen Einzel- und Mehrfach-Instance-Fehlermetriken:

"MetricsFilter": "*Failed*;*Error*.*;*Failed*.*"

Das folgende Beispiel entspricht allen nicht wiederherstellbaren Fehlermetriken, die für alle Quellen und Senken aggregiert werden:

"MetricsFilter": "*Nonrecoverable*._Total"

Informationen dazu, wie eine Pipe angegeben wird, die die integrierte -Metrikquelle von Kinesis Agent für Windows verwendet, finden Sie unterKonfigurieren von Kinesis Agent für Windows-Metrik-Pipes.

Liste der Kinesis Agent für Windows-Metriken

Im Folgenden finden Sie eine Liste der Einzel-Instance- und Mehrfach-Instance-Metriken, die für Kinesis Agent für Windows verfügbar sind.

Einzel-Instance-Metriken

Die folgenden Einzel-Instance-Metriken sind verfügbar:

Mehrfach-Instance-Metriken

Die folgenden Mehrfach-Instance-Metriken sind verfügbar:

DirectorySource-Metriken

WindowsEventLogSource-Metriken

KinesisFirehose-Senken-Metriken

KinesisStream-Metrics

CloudWatchLog-Metriken

CloudWatch-Metriken

Lesezeichen-Konfiguration

Standardmäßig sendet Kinesis Agent für Windows Protokolldatensätze an Senken, die nach dem Starten des Agenten erstellt werden. Manchmal ist es sinnvoll, frühere Protokolldatensätze zu senden, z. B. Protokolldatensätze, die in dem Zeitraum erstellt werden, wenn Kinesis Agent für Windows während einer automatischen Aktualisierung gestoppt wird. Die Lesezeichen-Funktion verfolgt, welche Datensätze zu Senken gesendet wurden. Wenn Kinesis Agent für Windows im Lesezeichenmodus gestartet wird, sendet er alle Protokolldatensätze, die erstellt wurden, nachdem Kinesis Agent für Windows gestoppt wurde, zusammen mit allen anschließend erstellten Protokolldatensätzen. Zur Steuerung dieses Verhaltens können dateibasierte Quell-Deklarationen optional die folgenden Schlüssel-Wert-Paare enthalten:

Wenn Kinesis Agent für Windows für eine lange Zeit angehalten wurde, müssen diese Lesezeichen möglicherweise gelöscht werden, da die mit einem Lesezeichen versehenen Protokolldatensätze und Ereignisse möglicherweise nicht mehr vorhanden sind. Lesezeichendateien für eine bestimmte Quell-ID befinden sich in %PROGRAMDATA%\Amazon\AWSKinesisTap\source id.bm.

Lesezeichen funktionieren nicht bei Dateien, die umbenannt oder abgeschnitten wurden. ETW-Ereignisse und Leistungsindikatoren können aufgrund ihrer Beschaffenheit nicht mit einem Lesezeichen versehen werden.