Hi @johna, welcome to the community!
Quite a bit to unpack here
-
Are logs roll your own or are there some templates/examples that we can leverage to get started?
Yes, by default only the last 100 log files (each file containing 16 MB of data) are kept. You can adjustN8N_LOG_FILE_MAXSIZE
andN8N_LOG_FILE_MAXCOUNT
to configure this behaviour. -
Are there any examples of logs and code that generates logs?
No, but you could simply spin up a test instance using docker by running something likedocker run -it --rm --name n8nlogging -e N8N_LOG_LEVEL=debug -p 5678:5678 n8nio/n8n:0.178.2
and take a look at the real-world output. Here is the debug output from me playing around with a simple webhook workflow just now:
2022-05-27T09:52:06.465Z | debug | Received webhoook "GET" for path "30c1ba65-af24-42d4-aae9-35fae3631cf3" {"file":"ActiveWorkflowRunner.js","function":"executeWebhook"}
2022-05-27T09:52:06.495Z | verbose | Started execution of workflow "Example" from webhook with execution ID 3 {"executionId":"3","file":"WebhookHelpers.js","function":"executeWebhook"}
2022-05-27T09:52:08.191Z | debug | Received child process message of type start for execution ID 3. {"executionId":"3","file":"WorkflowRunner.js"}
2022-05-27T09:52:08.216Z | verbose | Initializing n8n sub-process {"pid":41,"workflowId":1,"file":"WorkflowRunnerProcess.js","function":"runWorkflow"}
2022-05-27T09:52:08.283Z | verbose | Workflow execution started {"workflowId":1,"file":"WorkflowExecute.js","function":"processRunExecutionData"}
2022-05-27T09:52:08.288Z | debug | Received child process message of type processHook for execution ID 3. {"executionId":"3","file":"WorkflowRunner.js"}
2022-05-27T09:52:08.288Z | debug | Executing hook (hookFunctionsPush) {"executionId":"3","workflowId":1,"file":"WorkflowExecuteAdditionalData.js","function":"workflowExecuteBefore"}
2022-05-27T09:52:08.288Z | debug | Start processing node "Webhook" {"node":"Webhook","workflowId":1,"file":"WorkflowExecute.js"}
2022-05-27T09:52:08.289Z | debug | Received child process message of type processHook for execution ID 3. {"executionId":"3","file":"WorkflowRunner.js"}
2022-05-27T09:52:08.289Z | debug | Running node "Webhook" started {"node":"Webhook","workflowId":1,"file":"WorkflowExecute.js"}
2022-05-27T09:52:08.291Z | debug | Running node "Webhook" finished successfully {"node":"Webhook","workflowId":1,"file":"WorkflowExecute.js"}
2022-05-27T09:52:08.292Z | debug | Received child process message of type processHook for execution ID 3. {"executionId":"3","file":"WorkflowRunner.js"}
2022-05-27T09:52:08.293Z | debug | Start processing node "HTTP Request" {"node":"HTTP Request","workflowId":1,"file":"WorkflowExecute.js"}
2022-05-27T09:52:08.294Z | debug | Received child process message of type processHook for execution ID 3. {"executionId":"3","file":"WorkflowRunner.js"}
2022-05-27T09:52:08.294Z | debug | Running node "HTTP Request" started {"node":"HTTP Request","workflowId":1,"file":"WorkflowExecute.js"}
2022-05-27T09:52:08.298Z | debug | Proxying request to axios {"file":"NodeExecuteFunctions.js","function":"proxyRequestToAxios"}
2022-05-27T09:52:08.428Z | debug | Running node "HTTP Request" finished successfully {"node":"HTTP Request","workflowId":1,"file":"WorkflowExecute.js"}
2022-05-27T09:52:08.429Z | debug | Start processing node "Item Lists" {"node":"Item Lists","workflowId":1,"file":"WorkflowExecute.js"}
2022-05-27T09:52:08.429Z | debug | Received child process message of type processHook for execution ID 3. {"executionId":"3","file":"WorkflowRunner.js"}
2022-05-27T09:52:08.429Z | debug | Running node "Item Lists" started {"node":"Item Lists","workflowId":1,"file":"WorkflowExecute.js"}
2022-05-27T09:52:08.430Z | debug | Received child process message of type processHook for execution ID 3. {"executionId":"3","file":"WorkflowRunner.js"}
2022-05-27T09:52:08.432Z | debug | Running node "Item Lists" finished successfully {"node":"Item Lists","workflowId":1,"file":"WorkflowExecute.js"}
2022-05-27T09:52:08.433Z | debug | Received child process message of type processHook for execution ID 3. {"executionId":"3","file":"WorkflowRunner.js"}
2022-05-27T09:52:08.433Z | verbose | Workflow execution finished successfully {"workflowId":1,"file":"WorkflowExecute.js","function":"processSuccessExecution"}
2022-05-27T09:52:08.434Z | debug | Received child process message of type processHook for execution ID 3. {"executionId":"3","file":"WorkflowRunner.js"}
2022-05-27T09:52:08.434Z | debug | Executing hook (hookFunctionsSave) {"executionId":"3","workflowId":1,"file":"WorkflowExecuteAdditionalData.js","function":"workflowExecuteAfter"}
2022-05-27T09:52:08.435Z | debug | Save execution data to database for execution ID 3 {"executionId":"3","workflowId":1,"finished":true,"stoppedAt":"2022-05-27T09:52:08.433Z","file":"WorkflowExecuteAdditionalData.js","function":"workflowExecuteAfter"}
2022-05-27T09:52:08.437Z | debug | Received child process message of type end for execution ID 3. {"executionId":"3","file":"WorkflowRunner.js"}
2022-05-27T09:52:08.450Z | debug | Executing hook (hookFunctionsPush) {"executionId":"3","workflowId":1,"file":"WorkflowExecuteAdditionalData.js","function":"workflowExecuteAfter"}
-
Can workflow template definition JSON be accessed programmatically? It looks like there’s a way to do this through the CLI:
Yes, that would be one possible way. We are also working on an official REST API through which this will be possible (and you can also use the UI API for this as shown here, though this is undocumented + unsupported). -
Is there a way to log the workflow definition JSON when a workflow kicks off?
The workflow definition isn’t part of the logs, but it’s stored with the execution data (in theworkflowData
field of theexecution_entity
table, the full table structure is documented here) if you choose to save such data. -
Is there a way to programmatically access human readable names for node types? For example, if I have a node of type n8n-nodes-base.httpRequest, can I programmatically get the human readable name of HTTP Request?
There’s no in-platform way to resolve the human-readable name I am aware of unfortunately. The given name of a node would be part of the aforementioned workflow JSON though. -
Is there a way to programmatically access user data?
Are you referring to the user credentials stored in n8n? These could be read via the CLI (a command liken8n export:credentials --all --decrypted
would do the job). If you’re looking for n8n users, these would be stored in theusers
table of your n8n database.