Log Files
TigerGraph Database captures key information on activities occurring across its different components through log functions that output to log files. These log files are not only helpful in troubleshooting but also serve as an auditory resource. This document gives a high-level overview of TigerGraph's logging structure and lists some common information one might need to monitor their database services and where to obtain them in the logs.

Overall Logging Structure

Logs in TigerGraph are stored at <tigergraph_root_dir>/log/. TigerGraph's logs are divided into different folders by the different internal components and each folder corresponds to a different component. Log formats also vary across the different components. In folders where logs are checked often, such as restpp, gsql, and admin, there are three symbolic links that help you quickly get to the most recent log file of that category:
  • log.INFO
    • Contains regular output and errors
  • log.ERROR
    • Contains errors only
  • <component_name>.out
    • Contains all output from the component process
  • log.WARNING or log.DEBUG
    • log.WARNING contains warnings
    • In thegsql folder, log.DEBUG contains very specific information you only need when certain errors happen
Knowing where certain activities are recorded allows one to use tools such as the Linux grep command to easily obtain critical information from your database.

Log locations on a cluster

In a TigerGraph cluster, each node will only keep logs of activities that took place on the node itself. For example, the GSQL logs on the m1 node will only record events for m1 and are not replicated across the cluster.
For GSQL specifically, the cluster will elect a leader to which all GSQL requests will be forwarded. To check which node is the leader, start by checking the GSQL logs of the m1 node. Check the most recent lines of log.INFO and look for lines containing information about leader switch. For example, the logs below recorded a GSQL leader switch from m2 to m1:
1
[email protected] 13:56:52.214 (GsqlHAHandler.java:231) GSQL leader switches from 'm2' to 'm1' ...
2
[email protected] 13:56:52.215 (GsqlHAHandler.java:246) GSQL HA leader switches to 'm1', abort and clear all sessions now.
3
If you want to lower the chance of leader switch by increasing timeout, please use 'gadmin config' to increase 'Controller.LeaderElectionHeartBeatMaxMiss' and/or 'Controller.LeaderElectionHeartBeatIntervalMS'.
4
[email protected] 13:56:52.219 (SessionManager.java:197) Abort and clear all sessions...
5
[email protected] 13:56:52.220 (SessionManager.java:204) All sessions aborted.
6
[email protected] 13:56:52.224 (GsqlHAHandler.java:283) switched to new leader m1
Copied!

Monitor request history

All requests made to TigerGraph's REST endpoints are recorded by the RESTPP logs and Nginx logs. Information available in the logs includes:
  • Timestamp of the request
  • API request parameters
  • Request Status
  • User information (when RESTPP authentication is turned on)
RESTPP is responsible for many tasks in the TigerGraph internal architecture and records many internal API calls, which can be hard to distinguish from manual requests. When RESTPP authentication is on, the RESTPP log will record the user information and mark a call if it is made by an internal API. Therefore, you can use the command below to filter for manual requests:
1
# In the restpp log directory
2
$ grep -i "requestinfo" log.INFO | grep -v "__INTERNAL_API__"
3
4
# All requests exluding the ones made by internal API
5
I0315 21:11:59.666318 14535 handler.cpp:351] RequestInfo|,1.RESTPP_1_1.1615842719666.N,NNN,0,0,0|user:tigergraph|api:v2|function:NoSchema|graph_name:social|libudf:
6
I0315 21:41:36.462616 14541 handler.cpp:351] RequestInfo|,196622.RESTPP_1_1.1615844496462.N,NNN,0,0,0|user:tigergraph|api:v2|function:NoSchema|graph_name:social|libudf:
Copied!
RequestInfo contains the ID of the request, which you can use to look up more information on the request :
Request ID
Here is an example of using a request ID to look up a request in the restpp log:
1
$ grep "1615842719666" log.INFO
2
3
# Returns all information about the specific request
4
# RawRequest log is captured at the entry point of a query
5
I0315 21:11:59.666026 14535 handler.cpp:285] RawRequest|,1.RESTPP_1_1.1615842719666.N,NNN,0,0,0|GET|/echo?parameter1=parameter_value|async = 0|payload_data.size() = 0|api = v2
6
# RequestInfo log is captured after the request has been parsed,
7
# and contains information such as username and the function or UDF to run
8
I0315 21:11:59.666318 14535 handler.cpp:351] RequestInfo|,1.RESTPP_1_1.1615842719666.N,NNN,0,0,0|user:tigergraph|api:v2|function:NoSchema|graph_name:social|libudf:
9
# ReturnResult is captured when the request has been processed
10
I0315 21:11:59.666509 14535 requestrecord.cpp:325] ReturnResult|0|0ms|RESTPP|1.RESTPP_1_1.1615842719666.N|user:tigergraph|/echo|graph_id=1&graph_name=social&parameter1=parameter_value|39
Copied!

Monitor user management tasks

User management activities, such as logins, role and privilege changes are recorded in the GSQL logs in the folder gsql.
To view recent activities, use the symlink log.INFO. There is a lot of information in the logs - to filter for information that you need, you can use Linux commands such as grep and tail For example, to view recent changes in roles, you can run the following command in the gsql log directory:
1
$ grep -i "role" log.INFO
2
3
# Returns all lines containing the word "role"
4
# username source IP
5
[email protected] 22:41:16.167 tigergraph|127.0.0.1:45854|00000000077 (BaseHandler.java:133) Received|POST|/gsql/roles?action=grant&role=globaldesigner&name=lennessy|0
6
[email protected] 22:41:16.863 tigergraph|127.0.0.1:45854|00000000077 (BaseHandler.java:167) Successful|POST|/gsql/roles?action=grant&role=globaldesigner&name=lennessy|application/json; charset=UTF-8|696ms
Copied!
To view login activities, search log.INFO for "login" instead.
1
$ grep -i "login" log.INFO
2
3
# Returns all lines containing the world "login"
4
[email protected] 21:08:42.047 tigergraph|127.0.0.1:53960|00000000001 (BaseHandler.java:133) Received|POST|/gsql/login|28
5
[email protected] 21:08:42.061 tigergraph|127.0.0.1:53960|00000000001 (LoginHandler.java:52) The gsql client is started on the server, and the working directory
6
is /home/tigergraph/tigergraph/log/restpp
7
[email protected] 21:08:42.072 tigergraph|127.0.0.1:53960|00000000001 (LoginHandler.java:80) Successful|Login|tigergraph
8
[email protected] 21:08:42.080 tigergraph|127.0.0.1:53960|00000000001 (BaseHandler.java:167) Successful|POST|/gsql/login|application/json; charset=UTF-8|35ms
Copied!
Last modified 16d ago