#1079 OIC Activity Stream Tracing Levels and OCI Logging

This post details how OIC activity stream logs surface in OCI Logging. It also shows exactly what you will see in OCI Logging, depending on the trace level you select, when activating your integration.

The post also covers some of the possibilities you have for interrogating these logs in OCI Logging. 

Finally, we take a look at OCI Dashboards, which allow us to add widgets, based on OCI Service Metrics as well as the OIC activity stream, pushed to OCI. 

You can do a lot with this data in OCI Logging; pushing these logs from OIC, can also be a conduit to OCI Logging analytics. There you can create really powerful, actionable dashboards.

But today, it's back to basics - what do I get in OCI Logging, when I push the activity stream logs from OIC. Not only that, we will also take a look at OCI Dashboards!    

Let's start with a simple example - 

Our integration, shipOrder, has 3 tracking fields - orderNr, customerNr and productNr. Each of these are initially set to values contained in the request payload. The only logic in the integration is assigning the value "MyCustomer" to the customerNr tracking field.

Debug Level Trace

Check out the activity stream log messages in OCI Logging - 

This log entry format is essentially the OCI Logging view of the OIC Activity Stream, essentially a subset of the activity stream, you can download from OIC.

With the level set to Debug, you get the following log entries. Note, they are not in the order you might expect, but we can quickly fix this. 

Essentially, the entries are in descending order, from a time perspective.

So let's begin by setting the sort to datetime asc- 

The first entry contain the wire message (the request json payload).

The second, logs the execution of the  Receive actin, which actually initiates the flow.

Before looking at these in detail, let's first look at the generic structure of the activity stream log surfaced in OCI Logging. 

The datetime field is the execution timestamp for this entry, it is in epoch format. The time field, contains the converted version o this.

 

The log content is divided into 2 main areas - data, which contains the salient info related to the OIC execution step being logged and oracle, which contains tenancy, compartment ocids etc.

If the log entry is for a OIC action, such as Receive (OIC Trigger), you will see 2 fields in data - actionName and actionType. In our case, these have the values, shipOrder(the name given to the trigger) and Receive.  
 

So let's go thru these 1 by one - 

Wire message - 

Note the parentEventId = -1. This indicates a top level integration, i.e. an integration that has not been invoked by another integration.

We see the flow or instance id along with the integration and project ids - integrationFlowIdentifier & projectCode.

Note the opcRequestId - think of this as a guid, that would be passed to any integrations, invoked by this one.

Finally, the message field - this is a generic field, and, in this case, it's value is the request payload.

The second message is for the Receive action, which we've already looked at.

Now come the initial 3 message for the tracking fields -

These have the format -

The next messages relate to the Assign of the value "MyCustomer" to the customerNr tracking field -

Now to the next 3 log entries - 

The first of these is for message received by mapper -

The second - is for the assignment of the new customerNr tracking field value.

The 3rd message - data Mapping completed.

The final 2 log entries are for the response - 

The first one contains the xml representation - 

The second is json - 

Audit Level Trace

With trace level set to Debug we had 13 log messages, with trace level set to Audit, 10 -

The Assign action is not logged, for example. However, I still get the request and response payloads logged.

Ergo, Audit should be sufficient for most cases.

Production Level Trace

10 rows, but no request, response payloads logged -

However, tracking fields are logged - 

If required from a compliance or business perspective, I can use the Logger action to push fields, e.g. request payload fields, to the activity stream log surfaced in OCI Logging.

I mentioned earlier that what we see as activity stream logs in OCI Logging, is but a subset of what we have in OIC itself.

Here is an excerpt of the download of the activity stream log for a "production" trace run of shipOrder -

What else can we do in OCI Logging?

Firstly, how do I enable logging to OCI Logging? Simple, just click the Logs link in the OCI console page for your OIC instance -

I've already enabled such.

Here's another of my OIC instances -

As you can see, I've chosen a different log name.

I delete this log and then enable logging again - 

I could, if I wanted to, enter the log name used by the first instance -

Or else I could give a unique name to this log. Note, you can also specify data retention period via the advanced options -

I run a couple of integrations, so we've something to look at in OCI Logging. I've set the trace level to audit.

Now we're in OCI Logging. A couple of things to note here -

1. the ability to enter custom filters

2. the ability to specify which logs to search. The default is all logs in the compartment, so we will narrow this down.

3. time frame.

Let's begin by specifying our OIC activity stream log - 

I see the order number (310397) I just entered - 

Now, let's look at the custom filters - 

the simplest filter expression is just a string e.g. the order number 310397. I enter this value in the filter field and click return -

  As you can see, it has morphed into the expression - logContent = "*310397*" and naturally returns all log messages that contain that string.

I change the query to sort in asc order - 

and check out the results - 

I can also filter on the log file fields -

for example, give me all the logs for a specific integration - 

The filter also shows you the possible values - as I've only run shipOrder, that's all I see.

You can always click the advanced mode link to see the actual query. After a while you may find yourself using this more often than not.

Also note the ability to save searches -

We can make the search more interesting by filtering on customer - let's run the following first -

Note, you cannot edit saved search queries, so I start over again - 

search "ocid1.compartment.oc1.." |

data.integrationFlowIdentifier='SHIPORDER!01.00.0000' and data.key='customerNr' and

data.value='Commiskey Inc' | sort by datetime asc

 

Net, net, you can make these queries as simple or complex, based on your observability requirements.

I can search for the combination of customer and product -

logContent='*Commiskey Inc*iBike*'

I mentioned earlier that OCI Logging can function as a conduit to other OCI services. for this you use connectors.

I have already created a connector to OCI Logging Analytics. The other possible targets are -

Object Storage could be used to push OIC logs to 3rd party monitoring apps, such as Grafana etc.

Finally, from OCI Logging, we can
directly navigate to OCI Dashboards.

OCI Dashboards

Dashboard usage is very intuitive.

We will build our first dashboard from scratch - 

The following widget sources are relevant from an OIC perspective - 

This simple widget can tell you your top integrations from a billing perspective.

I also added a widget based on the OCI Service Metric - NumberOfInboundRequests

Here I can create a widget, based on my saved search -

From here we can drill into the log using Log Search -

The base query for this doughnut (yes, this is the correct spelling) is - 

 

Summa Summarum

Naturally OIC itself provides a plethora of features in respect of Observability. However, OCI Logging is a great value add to that. It allows folks who only have access at OCI level to monitor what's running on OIC. This may fit in nicely with segregation of responsibilities etc. It also allows us to create dashboards combining data from OCI Service Metrics for OIC as well as data from the activity stream logs, pushed to OCI. 

If I've whetted your appetite for more, then please check out these posts on OCI Logging. 

I've also posted on leveraging OCI Logging Analytics for OIC Observability; those posts are available here.