Troubleshooting

How to do troubleshooting on Kuiper

Table of Contents

• 1. Kuiper.log
• 2. Troubleshooting Failed Parser
• 3. Troubleshooting Failed Records

---

Kuiper.log

All the logs for Kuiper stored in the file Kuiper.log

/kuiper/files/logs/Kuiper.log

The structure of the log as following.

date,<log-level>,<script-name>.<function-name>[Lin.<function-line>],<component-name>,<message>,<details>

Log	Description
<date>	the date-time in millisecond for the record
<log-level>	INFO, WARNING, ERROR, etc.
<script-name>.<function-name>[Lin.<function-line>]	Just for development usually if you need to modify the platform source code.
<component-name>	this is usually indicate the component name of the logs, for example admin, api, case, elasticsearch, mongo_parsers, parsers, Rhaegal
<message>	Message of the log
<details>	If there is a details like full artifact record, or error message

---

Troubleshooting Failed Parser

If you find the following issue in the files page

this means the parser faced issue and not executed properly. To do more troubleshooting and ensure the parser working properly, jump inside the docker container and run the parser script manually

sudo docker-compose exec celery /bin/bash
cd /app/app/parsers/<parser-folder>/
python <interface-name>.py

But to generate output, you need to call the interface function from the script main function, add the following to the parser interface script

if __name__ == "__main__":
    res = auto_interface("/app/files/files/<case-name>/<case-name>_<machine-name>/<path-to-artifact>" , "<parser-name>")
    print res

Then do the troubleshooting.

NOTE:

• auto_interface might be different depends on the parser itself
• you can get the <path-to-artifact> from the files status from the machine files interface from Kuiper

---

Troubleshooting Failed Records

If you see the following in the machine files status page, that means the parser worked fine, but the generated record were not able to be pushed to the database (Elasticsearch)

To check the reason error, check the artifact file from Kuiper.log log file.

grep "<path-to-artifact>" ./Kuiper.log

Then check the reason message from Elasticsearch component

"2022-10-17 15:21:20.261386","[ERROR]","elkdb.py.bulk_to_elasticsearch_fix_errors[Lin.597]","elasticsearch","Indx[test4], machine [test4_S2], data_type[MuiCache], rec_id[d29e0589-e828-41dd-a588-1cc5c32ef5b0] : No fix found for failed record [d29e0589-e828-41dd-a588-1cc5c32ef5b0] data","{'data_path': u'/app/files/files/test4/test4_S2/2022-10-17T15:15:54-S2.zip/PhysicalDrive1_0/usrclass/Users/smuha/AppData/Local/Microsoft/Windows/UsrClass.dat', 'machine': u'test4_S2', 'data_source': u'MuiCache', 'Data': {u'@timestamp': '2022-10-15T10:47:56.040248', u'sid': 'MuiCache', u'Key_Timestamp': '2022-10-15T10:47:56.040248', u'name': 'C:\\Program Files\\Microsoft Office\\root\\Office16\\EXCEL.EXE.ApplicationCompany'}, 'data_type': u'MuiCache'}"

NOTE: some times the reason will not display in the same record, which depends on the type of error, however, if the reason not exists, search by the record ID (e.i. d29e0589-e828-41dd-a588-1cc5c32ef5b0).

grep "d29e0589-e828-41dd-a588-1cc5c32ef5b0" ./Kuiper.log

You should find all records related to the record ID, including Elasticsearch reason message

"2022-10-17 15:21:19.907411","[WARNING]","elkdb.py.bulk_to_elasticsearch[Lin.400]","elasticsearch","Index [test4]: Failed pushing record: ","{u'index': {u'status': 429, u'_type': u'_doc', u'_id': u'd29e0589-e828-41dd-a588-1cc5c32ef5b0', u'error': {u'reason': u'index [test4] blocked by: [TOO_MANY_REQUESTS/12/disk usage exceeded flood-stage watermark, index has read-only-allow-delete block];', u'type': u'cluster_block_exception'}, u'_index': u'test4'}}"