The article Create your first serverless function with Red Hat OpenShift Serverless Functions showed how to get started with a Node.js function application. You saw how to create a simple function application and deploy it to Red Hat OpenShift. It also covered basic usage of the Knative command-line tool kn.
This series of articles offers a deeper dive into Node.js serverless functions on OpenShift. In Part 1, we'll look at how logging works and how to customize what is logged in a Node.js function application.
Note: If you are not familiar with serverless functions in Node.js, we recommend reading Create your first serverless function with Red Hat OpenShift Serverless Functions.
Prerequisites
To follow along with the examples, you'll need to install Docker and the kn command-line interface (CLI).
It is not necessary to have access to a Red Hat OpenShift cluster, but if you would like to test one out for free, check out the Developer Sandbox for Red Hat OpenShift. For more information on setting up your environment for Red Hat OpenShift Serverless Functions, see the OpenShift Serverless Functions Quick Start guide.
Getting started with serverless functions
As a quick refresher, we can use the kn func create command to scaffold out a new Node.js functions application that responds to simple HTTP requests. Along with the package.json and func.yaml files, this application includes a very basic index.js that exports a single function, which is the "function" part of Serverless Functions. We will extend this to show the different logging options available.
For those that would like to follow along, you can find the example in the GitHub repository associated with this article. You can run it locally (assuming you’ve run npm install first) with the npm run local command. This uses faas-js-runtime to run the function application. If everything goes okay, something similar to this should be output to the console:
> faas-js-runtime ./index.js
The server has started. http://localhost:8080
Navigating to the URL should output something similar to this:
{"query":{}}
Adding a query parameter to the URL—for example, http://localhost:8080?name=luke—should produce something like this:
{"query":{"name":"luke"},"name":"luke"}
Looking at the code that gets executed, we can see that it is a pretty simple function:
function invoke(context) {
context.log.info(`Handling HTTP ${context.httpVersion} request`);
if (context.method === 'POST') {
return handlePost(context);
} else if (context.method === 'GET') {
return handleGet(context);
} else {
return { statusCode: 451, statusMessage: 'Unavailable for Legal Reasons' };
}
}
The context object that is passed provides access to the incoming HTTP request information, including the HTTP request method, any query strings or headers sent with the request, the HTTP version, and the request body.
If the method that was requested is a POST, then it calls the handlePost method, and if the requested method was a GET, then the handleGet function is called and returned.
The context object also provides a logging object that can be used to write out output. This logging object is an instance of the Pino logger. You can learn more about Pino and its logging API in the Pino documentation.
You might notice that the preceding function uses the info log level to output what type of request it is currently handling:
context.log.info(`Handling HTTP ${context.httpVersion} request`);
If you were running this locally, you might have also noticed that by default, this log doesn’t get output. That is because, by default, the serverless function's runtime log level is set to warn.
Let’s see how we can change this.
Customizing the log level
The log level can be changed in a few different ways, depending on how you are running the function application.
Running locally
Because we are running things locally using the faas-js-runtime CLI, we can simply use the --logLevel flag. If we wanted to use the info log level, we could run it locally like this:
$ npm run local -- --logLevel=info
Note: The logLevel flag was recently added to the faas-js-runtime in the 0.7.0 release.
Now we should see a little more info when we start up the server:
> faas-js-runtime ./index.js "--logLevel=info"
{"level":30,"time":1622052182698,"pid":21445,"hostname":"lincolnhawk2","msg":"Server listening at http://0.0.0.0:8080"}
The server has started. http://localhost:8080
And if we navigate to the URL, that info log we saw in the preceding code should now also be output to the console:
{"level":30,"time":1622052256868,"pid":21445,"hostname":"lincolnhawk2","reqId":"req-1","req":{"method":"GET","url":"/","hostname":"localhost:8080","remoteAddress":"127.0.0.1","remotePort":35532},"msg":"incoming request"}
{"level":30,"time":1622052256869,"pid":21445,"hostname":"lincolnhawk2","reqId":"req-1","msg":"Handling HTTP 1.1 request"}
{"level":30,"time":1622052256872,"pid":21445,"hostname":"lincolnhawk2","reqId":"req-1","res":{"statusCode":200},"responseTime":4.370276033878326,"msg":"request completed"}
Running in a container
The example can also be run inside a container by using the kn func run command. To set the log level for this workflow, an entry needs to be made inside the func.yaml that was created during the scaffolding.
-- func.yaml snippet
name: logging-with-functions
...
envVars:
For the purposes of this example, we only care about that last parameter, envVars. This is where we can set the log level for our function. We use the environment variable FUNC_LOG_LEVEL. For example, if we wanted to change the log level to info, we just add this:
-- func.yaml snippet
name: logging-with-functions
...
envVars:
FUNC_LOG_LEVEL: info
Now when the function is run with kn func run, the output should be similar to the examples just shown:
> [email protected] start /workspace/.invoker
> node server.js
{"level":30,"time":1622052644164,"pid":20,"hostname":"c38b7f5bcdc8","msg":"Server listening at http://0.0.0.0:8080"}
FaaS framework initialized
Running on an OpenShift cluster
If you have a running OpenShift cluster with the OpenShift Serverless operators installed and set up, you can deploy the function to that cluster by running the following command:
$ kn func deploy
Upon successful deployment, the kn CLI tool will output the URL to access the function application. You can then see the logs by running the oc logs command like this:
$ oc logs -f POD_NAME -c user-container
The output should be similar to what was just shown in the previous section—something like this:
~/logging-with-functions(main*) » oc logs logging--with--functions-00001-deployment-fb8cdc4b9-plw99 -f -c user-container
> [email protected] start /workspace/.invoker
> node server.js
{"level":30,"time":1622565846908,"pid":21,"hostname":"logging--with--functions-00001-deployment-fb8cdc4b9-plw99","msg":"Server listening at http://0.0.0.0:8080"}
FaaS framework initialized
{"level":30,"time":1622565847507,"pid":21,"hostname":"logging--with--functions-00001-deployment-fb8cdc4b9-plw99","reqId":"req-2","req":{"method":"GET","url":"/","hostname":"logging--with--functions-default.apps.ci-ln-nhfrz7t-f76d1.origin-ci-int-gce.dev.openshift.com","remoteAddress":"127.0.0.1","remotePort":39872},"msg":"incoming request"}
{"level":30,"time":1622565847508,"pid":21,"hostname":"logging--with--functions-00001-deployment-fb8cdc4b9-plw99","reqId":"req-2","msg":"Handling HTTP 1.1 request"}
{"level":30,"time":1622565847510,"pid":21,"hostname":"logging--with--functions-00001-deployment-fb8cdc4b9-plw99","reqId":"req-2","res":{"statusCode":200},"responseTime":2.031086999922991,"msg":"request completed"}
Note: The pod name I've specified is specific to my cluster, so it will be different for you. You can get a list of the running pods by running oc get pods.
To update the environment variable, FUNC_LOG_LEVEL, we can again use the oc CLI to edit the running Knative service. Run oc get ksvc to get the name of the service that was created.
$ oc get ksvc
logging--with--functions http://logging--with--functions-default.apps.ci-ln-r48r1qk-d5d6b.origin-ci-int-aws.dev.rhcloud.com logging--with--functions-00001 logging--with--functions-00001 True
This will most likely be the only service returned, so we can just run oc edit ksvc. (If there is more than one, you will need to specify the name of the service to edit, like this: oc edit ksvc/SERVICE_NAME.) Doing so will open up an editor (vi), which allows us to update the FUNC_LOG_LEVEL value. Once the changes are saved, the function will restart with the new log level.
We can view the logs as before with the oc log command. Note that the pod name will be different when the function restarts.
Conclusion to Part 1
As you can see, logging output and changing the levels at which the logger responds inside a Node.js function application is fairly easy. Stay tuned for more articles in this series about OpenShift Serverless Functions using Node.js. While you wait, be sure to check out the latest on Red Hat OpenShift Serverless Functions.
If you want to learn more about what Red Hat is up to on the Node.js front, check out our Node.js topic page.
Last updated: September 19, 2023