Streaming logs to external systems

Introduction
Copied!

The workflow logs described in the previous page in this section are a powerful tool to enable seeing the context of current & past runs for a given workflow. This can be vital in providing key insights into the health of given workflows.

It is also possible to enable the streaming of workflow logs information to an external endpoint. This means you could use a system such as Datadog, Sentry, Redshift, New Relic or Kibana in order to conduct further analysis and display statistics in a meaningful dashboard, as is offered by these services.

This opens up all sorts of possibilities in terms of what you can do with filtering and visualizing your logs, to help identify patterns of success and failure, time taken and processing efficiency, across workflows and individual connectors (both third-party service and core/helpers), as illustrated by the following example dashboard:

The following shows an example of a graphic dashboard you could render with filters of log data:

And the following shows an example Datadog dashboard with a basic list of events and specific columns:

And an individual event:

Log event types
Copied!

There are three main log event types in Tray:

Data payloads are subject to change with subsequent releases

The 'Execution' event type
Copied!

An Execution event gives the details on the status of a workflow run. A key piece of info here being eventType which can be: created | started | retrying | failed | created_failed | manually_retried | successful | terminated

Execution payload format
Copied!

The execution log payload format is:

šŸ“‹
1
{
2
"header": {
3
"payloadSize": 773,
4
"version": 1
5
},
6
"logType": "execution_event",
7
"eventType": "<created | started | retrying | failed | created_failed | manually_retried | successful | terminated>",
8
"created": "<iso timestamp>",
9
"executionCreated": "<iso timestamp>",
10
"executionId": "<uuid>",
11
"workflowId": "<uuid>",
12
"organizationId": "<uuid>",
13
// fields present in case of error
14
"errorMessage": "<string | undefined>",
15
"errorStepName": "<string | undefined>",
16
"errorStepTitle": "<string | undefined>",
17
"errorId": "<uuid | undefined>",
18
"errorType": "<internal | input | connector | external>"
19
}

Execution example payload
Copied!

And the following screenshot shows an example execution log payload:

The Execution event for Embedded also includes solutionId, solutionInstanceId and sourceWorkflowId fields. Refer this page here.

The 'Step' event type
Copied!

A Step event gives details about the status of a specific step in a workflow. A key piece of info here being stepState which can be running | failure | success

It can be of logType 'input' or 'output' (as explained in the Intro to Logs and Debugging)

Step payload format
Copied!

The standard step payload format is:

šŸ“‹
1
{
2
"header": {
3
"payloadSize": 773,
4
"version": 1
5
},
6
"logType": "<step_input | step_output>",
7
"created": "<iso timestamp>",
8
"executionCreated": "<iso timestamp>",
9
"executionId": "<uuid>",
10
"workflowId": "<uuid>",
11
"organizationId": "<uuid>",
12
"stepName": "<string>",
13
"stepState": "<running | failure | success>",
14
"connectorName": "<string>",
15
"connectorVersion": "<string>",
16
"operation": "<string>",
17
"executionStepUuid": "<uuid>",
18
"correlationId": "<uuid>",
19
// if enabled
20
"data": "<object>",
21
// fields present in case of error
22
"errorMessage": "<string | undefined>",
23
"errorId": "<uuid | undefined>",
24
"errorType": "<internal | input | connector | external>"
25
}

Step payload example
Copied!

And the following screenshot shows an example step log step_input payload:

And a step_output payload:

Enhanced error alerting payloads
Copied!

Note that it is possible to turn on enhanced payloads for your error handling workflows.

This will mean that payloads coming through to your workflows using the Alerting Trigger will contain more detailed information on workflow errors, as they will have parsed the information directly from the third-party service which returned the error.

Please see our Error Handling documentation for full details.

The 'Audit' event type
Copied!

Audit events inside of Tray.io are a powerful tool to be able to see the user and system generated actions performed on Workflows, Users and Authentications. Context given from these events can be vital to providing key insights into the usage of the Tray platform and also to provide a historical trail of user or system actioned events that took place in the Tray platform.

This allows customers to run their own real time analysis using the tooling of their choice and also have a copy of the logs for batch analysis later and also monitor the usage of the platform for auditing purposes.

Audit payload format
Copied!

Each audit event has slightly different details, but the following is a sample format.

šŸ“‹
1
{
2
"eventType": "string",
3
"details": {"stepName": "string", "workflowId": "<uuid>"},
4
"organizationId": "<uuid>",
5
"timestamp": "<iso datetime>",
6
"impersonatedBy": {"userId": "string", "email": "string"},
7
"calledBy": {"userId": "string", "email": "string"}
8
}

Audit payload example
Copied!

And the following screenshot shows an example audit log payload:

Please see the appendix below for a table which gives a list of all the Audit events available.

There are several Embedded-specificĀ AuditĀ events. Refer this page here.

Saving filters in your dashboard
Copied!

The external service you are streaming your logs to will likely have the ability to filter data according to your needs.

There are obviously huge possibilities in terms of what filtering can be done. But some ways in which you might wish to filter are:

  • By connectorName so you can have a dashboard which shows all information on how Salesforce connectors are running across all your workflows

  • By stepState = retrying to get a view on all step events which are currently retrying

  • By eventType = failed to monitor failing workflows

Setting up logs streaming
Copied!

To begin the setup process please either:

- Contact your account manager

Or

- Click on 'Submit a ticket' in the 'Getting Help' section of the builder:

When creating a ticket you will be presented with the Log Streaming form:

The following table lists the basic required information we need to begin the setup process

Requirement Description Example
Secure Endpoint (https) URL that we'll be streaming the given log information to (This might not be required - i.e. when an API key is needed instead) https://customer.logservice.endpoint/
API key Some services will require an API key
Organization or Email(s) to be enabled on The Username(s) or Organization/Domain to enable log streaming on Email(s): support@acme.com Organization: "acme.com"
Content-Type of Requests "applicaton/json" or "application/ndjson" application/json
Log Type "Execution", "step logs" , or "everything" Step Logs

Once set up you can then validate that your service is receiving the correct log types.

For whitelisting purposes Tray.io will be sending logs from the following IPs

  • 52.8.7.130

  • 18.144.153.142

Example setup - Datadog
Copied!

In order to set up Datadog for logs streaming you will need to go to the 'Integrations' section of your dashboard to retrieve both your API key and Application Key which you have configured for use with Tray.io:

Then simply provide us with your Organization/Email, Content type and Logs Type info as above

Questions & Feedback
Copied!

In order to improve this feature, we'd like to hear from your experience in using Logs Streaming. To do so, navigate to the "Product Feedback" section of your Tray.io dashboard and mention 'Logs Streaming' in your message.

Appendix - Table of Audit log event types
Copied!

There are several Embedded-specificĀ AuditĀ events. Refer this page here.

Category Name
Authentication AuthenticationCreated
Authentication AuthenticationUpdated
Authentication AuthenticationDeleted
Authentication AuthenticationRefreshFailed
Authentication AuthenticationRefreshSuccessful
Authentication AuthenticationCreationFailed
Authentication AuthenticationSharingChanged
Authentication AuthenticationUsed
Authentication/Workflow ServiceChanged
Authentication/Workflow ServiceCreated
Organization OrganizationUserInvited
Organization OrganizationDetailsUpdated
Organization OrganizationSettingsUpdated
User UserInternalRoleChanged
User 2FALoginFailed
User 2FADisabled
User 2FAEnabled
User UserLoginSucceeded
User UserLoginFailed
User UserDeleted
User UserOrganizationRoleChanged
Workflow WorkflowUpdated
Workflow WorkflowCreated
Workflow WorkflowDeleted
Workflow WorkflowViewed
Workflow WorkflowTagsUpdated
Workflow WorkflowDisabled
Workflow WorkflowStepTitleUpdated
Workflow WorkflowStepSettingsUpdated
Workflow WorkflowStepOperationUpdated
Workflow WorkflowStepAuthenticationSet
Workflow WorkflowAlertingWorkflowSet
Workflow WorkflowStepMoved
Workflow WorkflowStepDescriptionRemoved
Workflow WorkflowDescriptionRemoved
Workflow WorkflowStepDeleted
Workflow WorkflowVersionRolledBack
Workflow WorkflowEnabled
Workflow WorkflowStepCreated
Workflow WorkflowStepAuthenticationRemoved
Workflow WorkflowStepDescriptionSet
Workflow WorkflowCloned
Workflow WorkflowDescriptionSet
Workflow WorkflowAlertingWorkflowRemoved
Workflow WorkflowNameUpdated
Workflow WorkflowDebugLogViewed
Workflow WorkflowDetachedFromProject