Functions as Service (FaaS) : its monitoring and use as tools

FaaS Functions as a Service: its monitoring and use as tools

FaaS: how to work with them without dying in the attempt

How about starting with an introduction? We will attach links to articles already published – and from third parties – that expand on each concept or topic in order to keep our journey as compact as possible.
For at least five years you’ve been hearing phrases like “the cloud, you have to put everything up on the cloud”, which is a very clever sales strategy: when you say”cloud”, our mind automatically rises, it goes beyond this planet, and we could lose sight of our data (and in our case, our applications as well), so we have to be very careful about the direction of our information.

In Pandora FMS we have our feet well on the ground and our flexibility is enough to be able to see the existing clouds on the horizon. That is why we have talked about the basic concepts of the cloud and here we reaffirm what has been said:

“Always keep in mind the business objective over the considerations and supposed technical advantages. The cloud is just another tool.”

We have even published that we have to look at the cloud with suspicion: there are many questions we must ask ourselves before migrating some of our processes.There are certainly well-documented success stories and we have even landed on Amazon Web Services AWS®. to take advantage of the good things, offering an image of the Open Source version of Pandora FMS (but we clearly show you how to take advantage of our Tentacle protocol and to be able to monitor other virtual machines in order to centralize the information of the logs).

We have not been left behind in monitoring virtual environments like Docker Swarm (which are in the cloud) due to the challenge of their metrics. As you can see, our collective team in this your blog has made an effort to bring you all the news that are assimilated by the incredible flexibility of Pandora FMS.

In this entry we will focus on the same approach as one of our colleagues did, and we will apply it to Functions as a Service, which we abbreviate as FaaS. This comes from the English language,”Function as a Service”, or FaaS and it evokes other important terms: “Software as a Service” or SaaS (e.g. eHorus or even CRM in the cloud) and “Infrastructure as a Service” or “IaaS” (and there are many more to be included under the term YaaaS:”Yet another as a Service”).

What are FaaS?

FaaS are the short programs (functions) that we make with a certain programming language, they are monolithic and we host them with a provider and they can be called by us, by other applications or even events.
Here the clear advantage is that we as programmers can forget about servers, their updates, SSH connections, etc., to such an extent that we might forget that we are on a server and we will devote ourselves to perform the FaaS without major setbacks (Is this the end of the DevOps as we know them?). That is why, in English, these functions are called “serverless“, which we consider to be untrue: the server will always be there. Just because we don’t care where it is and how it is configured, maintained and monitored doesn’t mean that the figure doesn’t exist.
In short, FaaS are programs that are loaded, run and when finished all your data is destroyed and we will only be charged for the running time.

What are the uses of FaaS?

The uses can be practically infinite:

• We could make a FaaS run every hour, read an XML file, extract only the fields we need and store them in a database (even it can tell us if there are new fields in the document, as that is a versatility of XML: to add data without affecting compatibility in reading).
• A FaaS could consult several RSS feeds, link them together and create an HTML document to be saved on a mobile phone for offline consultation.
• Another FaaS may well connect to a database and query the number of units sold of a specific item and/or its existence, availability and price.
• We will also be able to resize images in a massive way; verify the payment and balance in soda dispensing machines; connect our vacuum cleaners to our WIFI network (Internet of things), notifications by Slack or we could consult the price of certain shares in any stock exchange in the world.

How can we monitor FaaS?

Pandora FMS can, indirectly, deal with business processes through Transactional Monitoring, with the results of our FaaS on a database, and with the Pandora FMS agent suitable for that database, we will obtain the same purpose: to take care that our processes, customers and companies are operational and producing. This article is about implementing agents directly on our FaaS, without losing sight of the whole scenario.

Who hosts FaaS?

To date, there are not many companies that sell machine time:

• IBM® with its”OpenWhisk actions®”.
• Microsoft® with its”Azure Functions®”.
• Google® with its”Cloud Functions” (still in beta).
• Amazon® with its “AWS Lambdas®”.

As we mentioned, given our incursion into AWS®, in this article we will focus on AWS Lambdas® (you can see the frequently asked questions in this link) because it is a mature product that many companies already use.

AWS Lambdas®

Amazon® rightly refers to the FaaS as”Lambdas”, because this is the concept that encompasses the minimal and recursive functions of a programming language. However, don’t be fooled’: lambda calculation is complex and we will simplify it as much as possible here.

Characteristics of the AWS Lambdas®

• Each AWS Lambda® function has its limits: 50 megabytes in compressed form, 512 megabytes in its own temporary folder on disk and for each instance, at least 128 megabytes of memory up to 3 gigabytes (CPU power is proportional to the contracted memory), the maximum execution time is 300 seconds.
• We can program for Java, JavaScript (Node.JS), PHP, Ruby, Python and .NET®.
• Important note: successive versions of an FcS will be maintained as long as we want and we can specifically call them one by one (maximum of one thousand at a time).
• Amazon® invoices per 100 millisecond block, however, pricing plans are calculated in seconds and the first million requests are free. These requests (time used) are multiplied by the memory contracted. In practice, in the long run, the 1024 MB plan is cheaper because it takes less time to calculate.

Defining an AWS Lambda®

We must, in JSON or YAML format, make a formal definition to Amazon® of our future FaaS: name, version, dependencies, memory to be used, etc.; we will find all the details here. For example, a function in Node.js to make a HTTPS request in YAML (according to AWS SAM®), would be as follows:

AWSTemplateFormatVersion:'2010-09-09'.
Transform:'AWS::Serverless-2016-10-31'.
Description: Demonstrates using a built-in Node.js module to make an HTTPS request.
Resources:
httpsrequest:
Type:'AWS::Serverless::Function
Properties:
Handler: index.handler
Runtime: nodejs4.3
CodeUri: .
Description: Demonstrates using a built-in Node.js module to make an HTTPS request.
MemorySize: 128
Timeout: 60https://aws.amazon.com/es/java/?nc2=h_l2_d
Policies:https://aws.amazon.com/es/java/?nc2=h_l2_d
- Version: '2018-04-15' -'2018-04-15'.
Statement:
- Effect: Allow
Action:
- ses:SendBounce
Resource:'*''.

Invoking an AWS Lambda®

Once we have our FaaS ready and hosted, we can invoke it via API via token authentication: only if it is positive the identification is called the FaaS and if it is negative it returns a 303 code (this protects our pockets from indiscriminate launch attacks). Many Amazon® products can invoke our FaaS, previously authorized by us, but we are particularly interested in the one we can invoke on demand.

Amazon Cloud Watch®

While our scripts are already able to collect metrics about execution or not when receiving on-demand response (e.g. error 303 for unauthorized and 404 for not found), internally Amazon offers us certain basic metrics through Amazon Cloud Watch®, which are as follows (successful responses that return zero value are not recorded by Amazon Cloud Watch®):

• Invocations
• Errors (4XX response values)
• Dead Letter Error
• Duration (in milliseconds but invoiced in blocks of 100 milliseconds)
• Throttles (significant error 429 number of instances opened simultaneously, many requests at the same time)
• IteratorAge
• ConcurrentExecutions
• UnreservedConcurrentExecutions

If our FcS is written in Python we can also add our own metrics, we can also include successful responses:
import logging
logger = logging.getLogger()
logger.setLevel(logging.INFO)
def my_logging_handler(event, context):
logger.info('got event{}'.format(event))
logger.error('Something's wrong.')
return'Our own metrics.

Instead of”logging.INFO” we can change the type of metric. Another point to note is that any print will also be saved as a metric!

from __future__ import print_function
def lambda_handler(event, context):
print('This will also be saved in Cloud Watch')
return'Our own metrics.

Through the Amazon CloudWacth® console you can view the logs of a specific function by running the following command (see query limits at no additional cost):

serverless logs -f my-function-FcS

AWS CloudWatch® Emulator and its metrics

If we want to practice our own Amazon Lambda® emulator (including metrics) in a local test environment, we can use the Serveless Offline Plugin (for Node.JS only) and view these awslogs for humans (here’s an example of how Amazon Cloud Watch returns a metric. You can see it here in machine language).

Do you want to learn more about Amazon® FaaS monitoring?

Amazon® offers the AWS X-Ray® service, which is free of charge for the first 100,000 scans and the first million scans retrieved; from those values onwards, collection begins. Essentially, it is a debugging platform to which we can program specific commands within our function code, with the certainty that such explicit data will be saved and if necessary retrieved by us for analysis. Here is an example of the libraries we should call in Java:

import com.amazonaws.xray.javax.servlet.AWSXRayServletFilter

Leave your comments and opinions below. We want to know your doubts and we will do our best to answer them as much as possible. Until the next opportunity, we’ll “read” each other!