本文為英文版的機器翻譯版本,如內容有任何歧義或不一致之處,概以英文版為準。
針對微軟視窗的 Amazon Kinesis 代理程式疑難排解
使用下列說明來診斷及修正使用適用於微軟視窗的 Amazon Kinesis 代理程式時的問題。
桌面平台或伺服器沒有任何資料串流至預期的 AWS 服務
Symptoms
當您檢查各種設為從 Windows 專用 Kinesis 代理接收資料串流的 AWS 服務所託管的日誌、事件和指標時,Windows 專用 Kinesis 代理程式並未串流任何資料。
Causes
此問題有數個可能的原因:
-
來源、接收或管道設定不正確。
-
Windows Kinesis 代理程式的身份驗證設定不正確。
-
Windows Kinesis 代理程式的授權設定不正確。
-
DirectorySource
宣告中所提供的規則表達式有錯誤。 -
針對
DirectorySource
宣告指定了不存在的目錄。 -
提供給 AWS 服務的是無效值,因此拒絕了 Windows Kinesis 代理程式的請求。
-
接收正在參考在指定或隱含 AWS 區域中不存在的資源。
-
為
WindowsEventLogSource
宣告指定的查詢無效。 -
為來源
InitialPosition
鍵/值對指定的值無效。 -
appsettings.json
組態檔案不符合該檔案的 JSON 結構描述。 -
資料正在串流至與在 AWS 管理主控台中選取的區域不同的區域。
-
Windows 適用的 Kinesis 代理程式並未正確安裝或並未在執行中。
Resolutions
若要解決沒有串流資料的問題,請執行下列步驟:
請檢查 Kinesis 代理程式的
%PROGRAMDATA%\Amazon\AWSKinesisTap\logs
目錄中。搜尋字串ERROR
。若來源或接收並未載入,請執行以下作業:
檢查錯誤訊息,並尋找來源或接收的
Id
。檢查對應至
%PROGRAMFILES%\Amazon\AWSKinesisTap\appsettings.json
組態檔案中Id
的來源或接收宣告,查看是否有任何與所找到錯誤訊息相關的錯誤。如需詳細資訊,請參閱 設定適用於微軟視窗的 Amazon Kinesis。-
修正與錯誤相關的任何組態檔案問題。
停止並啟動
AWSKinesisTap
服務。然後檢查最近的日誌檔案,驗證已解決組態問題。
-
若錯誤訊息指出並未找到管道的
SourceRef
或SinkRef
,請執行以下作業:記下管道的
Id
。檢查
%PROGRAMFILES%\Amazon\AWSKinesisTap\appsettings.json
組態檔案中對應至所記下Id
的管道宣告。確認SourceRef
和SinkRef
鍵/值對的值已正確拼為您意圖參考的來源和接收宣告Id
。修正任何錯誤或拼字錯誤。若組態檔案中沒有來源或接收宣告,請新增宣告。如需詳細資訊,請參閱 設定適用於微軟視窗的 Amazon Kinesis。停止並啟動
AWSKinesisTap
服務。然後檢查最近的日誌檔案,驗證已解決組態問題。
-
若錯誤訊息指出特定 IAM 使用者或角色並未獲得授權執行特定操作,請執行以下作業:
-
若錯誤訊息指出在剖析包含於
%PROGRAMFILES%\Amazon\AWSKinesisTap\appsettings.json
組態檔案中的規則表達式時發生引數錯誤,請執行以下作業:檢查組態檔案中的規則表達式。
-
驗證規則表達式的語法。您可以使用數個網站驗證規則表達式,或是使用下列命令列來檢查
DirectorySource
來源宣告的規則表達式:cd /D %PROGRAMFILES%\Amazon\AWSKinesisTap ktdiag.exe /r
sourceId
將
sourceId
替換成具有不正確規則表達式DirectorySource
來源宣告的Id
鍵/值對值。 -
對組態檔案中的規則表達式進行任何必要的修正,使其有效。
-
停止並啟動
AWSKinesisTap
服務。然後檢查最近的日誌檔案,驗證已解決組態問題。
-
若錯誤訊息指出在剖析並未包含於
%PROGRAMFILES%\Amazon\AWSKinesisTap\appsettings.json
組態檔案中的規則表達式時發生引數錯誤,並且該錯誤與特定接收有關,請執行以下作業:找出組態檔案中的接收宣告。
-
驗證明確與 AWS 服務相關的鍵/值對使用符合該服務驗證規則的名稱。例如,CloudWatch Logs 群組名稱必須只能包含由規則表達式指定的一組字元。
[\.\-_/#A-Za-z0-9]+
。 -
修正接收宣告鍵/值對中的任何無效名稱,然後確認那些資源已適當在 AWS 中設定。
-
停止並啟動
AWSKinesisTap
服務。然後檢查最近的日誌檔案,驗證已解決組態問題。
-
若錯誤訊息指出來源或接收因 null 或遺失參數而無法載入,請執行以下作業:
-
記下來源或接收的
Id
。 -
在
%PROGRAMFILES%\Amazon\AWSKinesisTap\appsettings.json
組態檔案中找出符合所記下Id
的來源或接收宣告。 -
檢閱在來源或接收宣告中提供的鍵/值對,並與相關接收類型 設定適用於微軟視窗的 Amazon Kinesis 文件中的來源或接收類型需求進行比較。將任何遺失的必要鍵/值對新增至來源或接收宣告。
-
停止並啟動
AWSKinesisTap
服務。然後檢查最近的日誌檔案,驗證已解決組態問題。
-
-
若錯誤訊息指出目錄名稱無效,請執行以下作業:
-
在
%PROGRAMFILES%\Amazon\AWSKinesisTap\appsettings.json
組態檔案中找出無效的目錄名稱。 -
驗證此目錄存在並包含應串流的日誌檔案。
-
修正組態檔案中所指定目錄名稱內的任何錯字或錯誤。
-
停止並啟動
AWSKinesisTap
服務。然後檢查最近的日誌檔案,驗證已解決組態問題。
-
-
若錯誤訊息指出資源不存在:
-
找出
%PROGRAMFILES%\Amazon\AWSKinesisTap\appsettings.json
組態檔案中接收宣告內不存在資源的資源參考。 -
使用 AWS 管理主控台在接收宣告內應使用的正確 AWS 區域中找出資源。將它與組態檔案中指定的內容進行比較。
-
變更組態檔案中的接收宣告,使其擁有正確的資源名稱和正確的區域。
-
停止並啟動
AWSKinesisTap
服務。然後檢查最近的日誌檔案,驗證已解決組態問題。
-
-
若錯誤訊息指出針對特定
WindowsEventLogSource
的查詢無效,請執行以下作業:-
在
%PROGRAMFILES%\Amazon\AWSKinesisTap\appsettings.json
組態檔案中,找出與錯誤訊息具有相同Id
的WindowsEventLogSource
宣告。 -
驗證來源宣告中
Query
鍵/值對的值符合 Event queries and Event XML。 對查詢進行任何變更,使其合規。
-
停止並啟動
AWSKinesisTap
服務。然後檢查最近的日誌檔案,驗證已解決組態問題。
-
-
若錯誤訊息指出其中具有無效的初始位置,請執行以下作業:
-
在
%PROGRAMFILES%\Amazon\AWSKinesisTap\appsettings.json
組態檔案中,找出與錯誤訊息具備相同Id
的來源宣告。 -
變更來源宣告中
InitialPosition
鍵/值對的值,使其符合所允許的值,如書籤組態中所述。 -
停止並啟動
AWSKinesisTap
服務。然後檢查最近的日誌檔案,驗證已解決組態問題。
-
-
確認
%PROGRAMFILES%\Amazon\AWSKinesisTap\appsettings.json
組態檔案與 JSON 結構描述相符。-
在命令提示視窗中,呼叫下列各行:
cd /D %PROGRAMFILES%\Amazon\AWSKinesisTap %PROGRAMFILES%\Amazon\AWSKinesisTap\ktdiag.exe /c
-
修正針對
%PROGRAMFILES%\Amazon\AWSKinesisTap\appsettings.json
組態檔案偵測到的任何問題。 -
停止並啟動
AWSKinesisTap
服務。然後檢查最近的日誌檔案,驗證已解決組態問題。
-
-
變更記錄日誌層級,嘗試取得更詳細的記錄日誌資訊。
-
使用以下內容替換
%PROGRAMFILES%\Amazon\AWSKinesisTap\nlog.xml
組態檔案:<?xml version="1.0" encoding="utf-8" ?> <nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.nlog-project.org/schemas/NLog.xsd NLog.xsd" autoReload="true" throwExceptions="false" internalLogLevel="Off" internalLogFile="c:\temp\nlog-internal.log" > <!-- See https://github.com/nlog/nlog/wiki/Configuration-file for information on customizing logging rules and outputs. --> <targets> <!-- add your targets here See https://github.com/nlog/NLog/wiki/Targets for possible targets. See https://github.com/nlog/NLog/wiki/Layout-Renderers for the possible layout renderers. --> <target name="logfile" xsi:type="File" layout="${longdate} ${logger} ${uppercase:${level}} ${message}" fileName="${specialfolder:folder=CommonApplicationData}/Amazon/KinesisTap/logs/KinesisTap.log" maxArchiveFiles="90" archiveFileName="${specialfolder:folder=CommonApplicationData}/Amazon/KinesisTap/logs/Archive-{################}.log" archiveNumbering="Date" archiveDateFormat="yyyy-MM-dd" archiveEvery="Day" /> </targets> <rules> <logger name="*" minlevel="Debug" writeTo="logfile" /> </rules> </nlog>
-
停止並啟動
AWSKinesisTap
服務。然後檢查最新的日誌檔案,查看日誌中是否有額外的訊息可協助診斷及解決問題。
-
-
驗證您在 AWS 管理主控台中正確區域內查看資源。
-
驗證 Windows 代理程式的 Kinesis 代理程式已安裝並在執行中。
-
在 Windows 中,選擇 Start (啟動),然後導覽至 Control Panel (控制台)、Administrative Tools (系統管理工具)、Services (服務)。
-
尋找 AWSKinesisTap 服務。
-
若沒有看到 AWSKinesis 服務,請使用Amazon Kinesis 代理程式入門。
-
若能看到服務,請判斷服務是否正在執行中。若不在執行中,請開啟服務的內容 (以滑鼠右鍵按一下) 選單,然後選擇 Start (啟動)。
-
檢查
%PROGRAMDATA%\Amazon\AWSKinesisTap\logs
目錄中最新的日誌檔案,驗證服務已啟動。
-
適用對象
此資訊適用於 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.115 版及更新版本的 Kinesis 代理
預期資料有時候會遺失
Symptoms
大多數的時候都能成功串流資料的 Kinesis 代理程式,但有時候會遺失某些資料。
Causes
此問題有數個可能的原因:
-
並未使用書籤功能。
-
根據這些服務目前的組態,超過 AWS 服務的資料傳輸速率限制。
-
AWS 服務的 API 呼叫費率限制,根據目前的
appsettings.json
組態檔案和 AWS 帳戶限制。
Resolutions
若要解決遺失資料的問題,請執行下列步驟:
-
考慮使用書籤組態中說明的書籤功能。它可協助確保所有資料最終都會傳送,即使 Windows 適用 Kinesis 代理程式停止並啟動時也一樣。
-
針對 Windows 的內建指標使用 Kinesis 代理程式,探索問題:
-
啟用 Windows 指標的 Kinesis 代理程式串流,如設定 Windows 度量管道的 Kinesis 代理程式。
-
若一或多個接收有大量不可復原的錯誤,請判斷每秒傳送多少位元組或記錄。然後判斷其是否仍在串流資料區域及帳戶中,針對那些 AWS 服務所設定的限制範圍內。
-
若超過限制,請減少傳送的資料量或速率、請求提高限制,或是增加分片 (若適用的話)。
-
在進行調整之後,繼續監控 Windows 專用的 Kinesis 代理程式,確保情況已解決。
-
如需 Kinesis Data Streams 限制的詳細資訊,請參閱Kinesis Data Streams 限制中的Kinesis Data Streams 開發人員指南。如需 Kinesis 資料 Firehose 限制的詳細資訊,請參閱Amazon Kinesis Data Firehose 限制。
適用對象
此資訊適用於 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.115 版及更新版本的 Kinesis 代理
資料以不正確的格式抵達
Symptoms
資料以不正確的格式抵達 AWS 服務。
Causes
此問題有數個可能的原因:
-
appsettings.json
組態檔案中接收宣告Format
鍵/值對的值不正確。 -
DirectorySource
宣告中RecordParser
鍵/值對的值不正確。 -
DirectorySource
宣告中使用Regex
記錄剖析器的規則表達式不正確。
Resolutions
若要解決不正確格式化的問題,請執行下列步驟:
-
檢閱
%PROGRAMFILES%\Amazon\AWSKinesisTap\appsettings.json
組態檔案中的接收宣告。 -
確認已為每個接收宣告指定
Format
鍵/值對正確的值。如需詳細資訊,請參閱 目的地宣告。 -
若具有
DirectorySource
宣告的來源已使用管道與針對Format
鍵/值對指定xml
或json
值的接收連線,請確認那些資源已為RecordParser
鍵/值對指定下列其中一個值:-
SingleLineJson
-
Regex
-
SysLog
-
Delimited
其他記錄剖析器都是僅限文字類型,無法與需要 XML 或 JSON 格式化的接收搭配並正常運作。
-
-
若日誌記錄無法由
DirectorySource
來源類型正確地進行剖析,請在命令提示視窗中呼叫下列各行,驗證在DirectorySource
宣告中指定的時間戳記和規則表達式鍵/值對:cd /D %PROGRAMFILES%\Amazon\AWSKinesisTap ktdiag.exe /r
sourceID
將
sourceID
替換成並未正常運作DirectorySource
來源宣告Id
鍵/值對的值。修正任何由ktdiag.exe
報告的問題。
適用對象
此資訊適用於 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.115 版及更新版本的 Kinesis 代理
效能問題
Symptoms
在安裝並啟動 Windows 版 Kinesis 代理程式後,應用程式和服務的延遲增加。
Causes
此問題有數個可能的原因:
-
Windows 適用 Kinesis 代理程式執行的機器沒有足夠的容量串流所需的資料量。
-
不必要的資料正在串流至一或多個 AWS 服務。
-
Windows 適用 Kinesis 代理程式正在將資料串流至並未針對高資料傳輸速率進行設定的 AWS 服務。
-
Windows Kinesis 代理程式正在 API 呼叫速率限制過低的帳戶中,呼叫 AWS 服務的操作。
Resolutions
若要解決效能問題,請執行下列步驟:
-
使用 Windows 資源監控應用程式,檢查記憶體、CPU、磁碟和網路用量。若您需要使用 Windows 專用 Kinesis Agent 串流大量資料,取決於組態,您可能需要在某些區域內佈建容量較高的機器。
-
您可能可以使用篩選,減少記錄資料的數量:
-
請參閱 WindowsEventLogSource 組態中的
Query
鍵/值對。 -
請參閱設定管道中的管道篩選。
-
請參閱中的 Amazon CloudWatch 指標篩選CloudWatch Logs 目的地組態。
-
-
使用 Windows 效能監控應用程式,檢視 Windows 指標的 Kinesis 代理程式,或將那些指標串流至 CloudWatch (請參閱Windows 內建指標來源適用的 Kinesis 代理程式。在 Windows 效能監控應用程式中,您可以為 Windows 接收和來源的 Kinesis 代理程式新增計數器。他們會列在 AWSKinesisTap Sinks (AWSKinesisTap 接收) 和 AWSKinesisTap Sources (AWSKinesisTap 來源) 下方。
例如,若要診斷 Kinesis Data Firehose 效能問題,請新增Kinesis Firehose效能計數器。
若有大量的可還原的錯誤,請檢查最新 Kinesis 代理程式,查看
%PROGRAMDATA%\Amazon\AWSKInesisTap\logs
目錄中。若KinesisStream
或KinesisFirehose
接收發生調節,請執行以下作業:-
若因為串流資料的速度過快導致發生調節,請考慮提高 Kinesis 資料串流的碎片數。如需詳細資訊,請參閱「」重新分片、擴展和平行處理中的Kinesis Data Streams 開發人員指南。
-
考慮提高 Kinesis Data Streams 的 API 呼叫限制,或增加接收的緩衝區大小 (若 API 呼叫遭到調節)。如需詳細資訊,請參閱「」Kinesis Data Streams 限制中的Kinesis Data Streams 開發人員指南。
-
若資料串流的速度過快,請考慮請求提高 Kinesis Data Firehose 交付串流的速率限制。或者,若 API 呼叫遭到調節,請請求提高 API 呼叫限制 (請參閱 Amazon Kinesis Data Firehose 限制) 或增加接收的緩衝區大小。
-
在增加 Kinesis Data Streams 的碎片數,或增加 KKinesis Data Firehose 串流的速率限制後,請修訂 Windows 專用的 Kinesis 代理程式。
appsettings.json
組態檔案,增加接收的每秒記錄數或每秒位元組數。否則,Windows 版 Kinesis 代理程式將無法利用增加的限制。
-
適用對象
此資訊適用於 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.115 版及更新版本的 Kinesis 代理
磁碟空間不足
Symptoms
適用於 Windows 的 Kinesis 代理程式正在一或多個磁碟機的磁碟空間非常少的機器上執行。
Causes
此問題有數個可能的原因:
-
Windows 記錄日誌組態檔案的 Kinesis 代理程式不正確。
-
適用於 Windows 持久性佇列的 Kinesis 代理程式設定不正確。
某些其他的應用程式或服務正在使用磁碟空間。
Resolutions
若要解決磁碟空間問題,請執行下列步驟:
-
若包含 Windows 日誌檔案 Kinesis 代理程式磁碟上的磁碟空間過低,請檢查日誌檔案目錄 (通常是
%PROGRAMDATA%\Amazon\AWSKinesisTap\logs
。確認保留的日誌檔案數量合理,且日誌檔案的大小也合理。您可以藉由編輯 Windows Kinesis 記錄檔的位置、保留期和詳細程度,控制 Windows 記錄檔的位置、保留期和詳細程度。%PROGRAMFILES%\Amazon\AWSKinesisTap\Nlog.xml
組態檔案。 -
當啟用接收排入佇列功能時,請檢查使用該功能的接收宣告。確認
QueuePath
鍵/值對參考具有足夠空間,可包含使用QueueMaxBatches
鍵/值對所指定批次數量上限的磁碟機。若無法執行該作業,請減少QueueMaxBatches
鍵/值對的值,使資料能輕易容納在指定磁碟機的剩餘磁碟空間內。 -
使用 Windows 檔案總管,找出使用磁碟空間的檔案,並傳輸或刪除多餘的檔案。變更使用大量磁碟空間的應用程式或服務組態。
適用對象
此資訊適用於 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.115 版及更新版本的 Kinesis 代理
故障診斷工具
除了驗證組態檔案,您也能使用ktdiag.exe
工具,該工具可提供數種其他的功能,用於診斷及解決設定和使用針對 Windows 的 Kinesis 代理程式時的問題。ktdiag.exe
工具位於 %PROGRAMFILES%\Amazon\AWSKinesisTap
目錄中。
-
若您認為包含特定檔案模式的日誌檔案正在寫入目錄,但並未由適用於 Windows 的 Kinesis 代理程式處理,請使用
/w
參數,以確認偵測到這些變更。例如,假設您預期具有*.log
檔案名稱模式的日誌檔案正在寫入c:\foo
目錄。您可以在執行ktdiag.exe
工具時使用/w
開關,指定該目錄及檔案模式:cd /D %PROGRAMFILES%\Amazon\AWSKinesisTap ktdiag /w c:\foo *.log
若正在寫入日誌檔案,您可以看到與以下內容相似的輸出:
Type any key to exit this program... File: c:\foo\log1.log ChangeType: Created File: c:\foo\log1.log ChangeType: Deleted File: c:\foo\log1.log ChangeType: Created File: c:\foo\log1.log ChangeType: Changed File: c:\foo\log1.log ChangeType: Changed File: c:\foo\log1.log ChangeType: Changed File: c:\foo\log1.log ChangeType: Changed
若沒有發生這類輸出,表示寫入日誌時發生應用程式或服務問題,或者發生安全組態問題 (而非 Windows 版 Kinesis Agent)。若發生這類輸出,但 Windows 版 Kinesis 代理程式仍未明顯地處理日誌,請參閱。桌面平台或伺服器沒有任何資料串流至預期的 AWS 服務。
-
有時候,日誌只會偶爾寫入,但驗證 Windows 版 Kinesis 代理程式是否正常運作很有用。請使用
/log4net
開關來模擬使用Log4net
程式庫寫入日誌的應用程式;例如:cd /D %PROGRAMFILES%\Amazon\AWSKinesisTap KTDiag.exe /log4net c:\foo\log2.log
這會將
Log4net
樣式的日誌檔案寫入c:\foo\log2.log
日誌檔案,並持續新增新的日誌項目,直到按下任意鍵為止。您可以在檔案名稱後方選擇性地指定使用額外的開關,設定數種選項:- 鎖定:
-lm
、-li
或-le
-
您可以指定下列其中一項鎖定開關,控制鎖定日誌檔案的方式:
-lm
-
會在日誌檔案上使用最低數量的鎖定,提供日誌檔案最大程度的存取。
-li
-
只有相同程序內的執行緒可同時存取日誌。
-le
-
一次只能有一個執行緒存取日誌。此為預設值。
-tn:
毫秒
-
指定寫入日誌項目間的
毫秒
數。預設為 1000 毫秒 (1 秒)。 -sm:
位元組
-
指定每個日誌項目的
位元組
數。預設為 1000 位元組。 -bk:
number
-
指定一次要寫入的日誌項目
數量
。預設為 1。
- 鎖定:
-
有時候模擬寫入 Windows 事件日誌的應用程式會很有用。使用
/e
開關來將日誌項目寫入 Windows 事件日誌;例如:cd /D %PROGRAMFILES%\Amazon\AWSKinesisTap KTDiag.exe /e Application
這會將日誌項目寫入 Windows 應用程式事件日誌,直到按下任意鍵為止。您可以選擇性地在日誌的名稱後方指定下列額外選項:
-tn:
毫秒
-
指定寫入日誌項目間的
毫秒
數。預設為 1000 毫秒 (1 秒)。 -sm:
位元組
-
指定每個日誌項目的
位元組
數。預設為 1000 位元組。 -bk:
number
-
指定一次要寫入的日誌項目
數量
。預設為 1。