 I want to share with you how to enable serverless metrics in Apache OpenWISC on Kubernetes with Prometheus. And for my BM, my name is Guo Yingchun. So a bit of self-introduction first. I've been working in IBM for more than 10 years. I'm an open source developer. So I've been working in open source community for quite a long time, starting from OpenOffice to OpenStack. Then in 2016, my focus was shifted to serverless. I started with Apache OpenWISC. And now I also work on Kubernetes. And I'm also a contributor to Kubernetes. So this is an outline for my presentation. First, I would like to talk about how we monitor in OpenWISC. I will start with Apache OpenWISC overview. And I will display the metrics defined and collected in the comment also, how these metrics displayed in Prometheus. And I will finish with the demo. So beginning to start with, how many of you have heard of a serverless? Quite a few, good. As the cloud computing structure involves, users' focus will have been narrowed down. At the beginning, we need to pay attention to the whole physical machine, then virtual machine, then the focus is on containers. Now, the focus is on functions for end users. They'll need to pay more attention. We don't need on the underlying infrastructure. They can focus more on business logic. And for cloud vendors, they get higher computing speed and better resource utilization. So I think that in the future, we'll pay more attention to more segments. What about serverless? What about its advantages? In serverless, the functions is daily, event trigger, and it is auto-scaled and even scaled to zero. That means you won't occupy any resource unless you call it. In other words, it is short-lived. These help us to reduce cost because now the cost is generated by your usage. So without usage, there will be any charge. And also, developers can pay more attention to their business logic. They don't need to worry about underlying infrastructure that help them to focus on the market. If there's any change, they can update their app easily or they can put their idea into reality easily. So how do you make your own serverless platform? Kubernetes is a well-known platform to all of you, I guess. And in terms of kind of orchestration, it can be, it's fair to say that it is the unicorn or monopoly in this serverless orchestration. Then you can find an open serverless project and deploy it into Kubernetes. There are quite a few projects open source serverless projects that can be deployed in Kubernetes. For example, OpenWISC, Knative, and Kubernetes. So this helped manufacturers to lower their cost in terms of deployment on Kubernetes. So Apache OpenWISC was initiated by IBM. It is now an incubator in the Apache community. The aim is to build an open source, event-triggered, function-less service platform. So I think the OpenWISC is quite a well-established project in the community because it has the Apache Software Foundation and it is proven on the IBM Cloud. So it is a quite a mature project. In the OpenWISC, it encouraged event-driven programming. The event-trigger action, there is an input that it will activate the action, which is coding. And the coding supports the common languages like Java, Python. The Apache OpenWISC can be deployed on any Docker supported platform. So Apache OpenWISC can be applied in Kubernetes as well. We have a project through the helm. Then you can deploy the Apache OpenWISC on Kubernetes. This is a structure for the development deployment. So you can see the common modules of OpenWISC. On the left is the user rent. We can skip that followed by the ngix. ngix is an API gateway. It will transfer the request into controller. The controller will send a request through load balance to Kafka. And the Kafka will send it to Invoker. The Invoker will call the container and put it in the code and execute it. Between controller and Invoker, Kafka helps with the communication between the two. And all the data is saved in the CoachDB. And on the top, you see a ZooKeeper. It is installed together with Kafka. So based on this structure, there are two common modules in OpenWISC. One is controller, the other is Kafka. And other than that, the Kafka and database, these are also important modules. So this is a typical user case in serverless. In itself, it's a microservice platform. The code can run on this platform. This code runs in stateless status. Therefore, serverless itself is a microservice platform. You can implement fine-grained microservice APIs on it. It is also suitable for the large number of events or the events or the functions can be put on this serverless platform. And it also helps to develop DevOps. Your code upgrades can be used on this platform as well. So metrics is very important on serverless. Not only for serverless. For serverless, that means developers are far away from infrastructure. Maybe the developers are not experienced IT workers. For example, a painter wants to write a code to process his or her image. So for these amateur developers, they know something about Python or some basic languages. And they want to know after the program is put on the cloud how the program can run on the cloud. They have no idea. Therefore, monitoring is very important, especially for serverless. Therefore, for metrics or telemetry, that's the only way for such developers to understand what happens on the server. The metric is really important because it's useful to understand the system health condition. And it is necessary to enable monitoring and the boolean. So metrics is really important. So how do we define the metrics in the open-waste? Open-waste distinguish between system and the user metrics. System metrics typically contain information about system performance in the system metrics. It will collide via the open-source project called common. And all these system metrics will usually be used by providers and operators. Another metric is the user metrics. It contains information about action performance in the open-waste. We will use it as an event and send it to the Kafka. So in the Kafka, you'll receive a lot of the message. And all these messages are the information of the action performance. And it is consumed by the open-waste users. And it can be used for boolean or audit purposes. But we know it's boolean to the users directly in IBM functions. And you can use it via the user interface. And all these info can also be used for the audit and boolean at the same time as well. And later, I will focus on the system metrics. For the user metrics, it is a realization in the open-waste is different. So I think that's another topic. So let's focus on the system metrics. Why did we choose the common to be the open-source monitoring framework? Open-waste is written by Scala. And Scala is based on Java. And it also uses another Java base. It's called AKK, which is the distributed communication software. And in the open-waste, when I choose that, what can I use to collect metrics and to record metrics? At the time, we chose the common. Because we thought that the common is a really outstanding metric collection base on the JVM. And currently, it has already been able to support the Scala and AKK. So that's why we chose the common. There are some features of the common. For example, it has a really powerful matrix. It can be distributed tricks. It can be able to use for distributed tracing and contacts propagation APIs in a single library. And also provide different metric recording instruments in its core metric API, which will be covered later. When we switch the reporter, we don't need to change the metrics in that. And currently, the common is also improving and optimized as well. They work. It can work with some really popular monitoring tools such as the Prometheus and ZipGit. So I think that the common is really convenient to use in just an API. An API will be a bright code. And when we need to make a metric and work on a metric indicator, we need to call the class. And everything can be defined. And then all these metrics will be loaded by the common. So let's have a look at the common metrics instruments. Well, actually, it provides different kinds of instruments, for example, the counter. It counts how many times it was in Christmas during a reporting period. Good forecoding errors or occurrence of the specific events in your device. Another one is the gauge, which is the metric value. And track a single value that can be in Christmas, the Christmas, or explicitly set. Good foreclosure moving variables such as the available memory and basic usage. And the next one is the histogram. Track. It is quite a complicated metric. It can track the entire value distribution of a given metric within a specific time. And it's good for the array or the queue. So the data of the queue is all the number of the people of the queue is changing from 1 to 10, from 1 to 5. So during this period, what we need to count, we need to count the main value or the maximum value or the minimum value. But with the histogram, it can record all the data, all the values we need. It also helps the data structures enable it to be stored in a really smooth area. So if you are interested, you can read all these documentations of the common. Well, the next function is the timer. It allows you to start and stop the timer. And another one is the range sampler. So these are the instruments. And the third one are used quite often in the OpenWisk, but we don't use the last two in the OpenWisk. And in the OpenWisk, the matrix are from the controller and the invoker. All these matrix we call the execution of the year circle is called activation. And we'll monitor the activation memory usage, Kafka database, and HTTP request, and so on. There are over 60 matrix until now. And currently, I only give you some very typical case for example, counter. We use the counter to record the count of the activation set to Kafka. And we also use it to record the count of the non-blocking activation started. So the counter is used to count another one is the gauge. We use it to record the number to record the number of the activations being worked upon for a given controller. The amount of the RAM memory is used for deploy activations for the histogram. We use it we use it invoker to manage the memory usage. And we also use it to record the numbers of the Kafka topic to receive activations to complete. And after all this kind of matrix, so let's have a look at the PromiFuse. Common is only library. The purpose is to collect the matrix for you after the matrix, you need to store it somewhere else, right? In the past, we used the state state. And currently, we treated three PromiFuse as an alternative. PromiFuse is a CNCF project is a system and service monitoring system. It collects matrix from configure targets at given intervals and evaluates the rule expression display the results and can trigger alert if some condition is observed to be true. So I think that it is quite a complete monitoring system. It doesn't have a lot of advantage. For example, it has a really powerful data-searching language, and it's not relied on the distributed storage. And the time series collection happens via a portal over HTTP. In order to get the monitoring data, we can use the static way and dynamic way to find the supporter of the report and also support different kind of the diagrams. So let's see that if we use the open-waste or if we use the open-waste matrix, if we use the Kafka to class the open-waste matrix and see that whether we can and we can find it to the PromiFuse as well. Let's have a look at this one from the middle. The PromiFuse port is the PromiFuse server in the server. The retrieval module is to class the matrix. There are two ways. The first one is to pull the matrix. And when they class the matrix via the pool, it must have the supporter. The matrix must be exposed to the port. The retrievers can get all the matrix and it can also use the push method to class the data. But there are some short-term tasks. For example, this process only lasts for several seconds but the process will take you about 10 seconds. In this way, you will miss a lot of data. In this way, we have the gateway. The temporary storage can be transferred to pool and then it can be collected and stored in the memory. So we can use the query of the PromiFuse to search it. On the right-hand side, the module is called alert manager, which means that when some condition happens, the alert will be sent. It also has the web UI and API claims. All the things are already available. So let's look at the service-defined detected module beside the dynamic one. We can also use the label method to find all these kind of the abnormal conditions. In the common project, we developed a common PromiFuse as for it, which is an open source project. The data is written below. It supports the integration of the common and PromiFuse. It is really simple. As long as you add a really simple statement, the matrix connected by the common will be converted to PromiFuse for a method exposed to the HTTP address or exposed to the HTTP address slash matrix. In this way, this kind of matrix can be consumed by the PromiFuse, and you can add some statements in the PromiFuse, which will enable the PromiFuse can pull the data from these terminals. So that's all the statements that we have to these projects. So let's look at this diagram. We only take the open-source controller here, but currently we exposed both the controller and invoker. In the controller, we use the common to collect the matrix. We use the common and PromiFuse disorder. To expose the stress slash as opposed to a plot. And when I use the PromiFuse, the retriever will just pull the data from these terminals or these sockets, and this way the matrix can be shown on the interface of the PromiFuse. And later, I'd like to give you a simple demo. In the target, you can see that the controller and invoker has already got the matrix, respectively. Well, now I'd like to give you a really simple demo. Well, actually, the demo has already been installed properly, and I mean that's the common, and the PromiFuse project has already been installed. So I just want to show you the result. Well, actually, this one is stored on the cloud, so maybe it's a little bit slow. So here, it got the data of two edges, and here are all the matrix. The one started with the counter, the C means counter, and gate means measurement. And here is the diagrams. These are the matrix collected. Let's pick one. This is monitored by the controller and send the time for the activation, which is sent to the Kafka. And for counter, basically it's a value, either zero, one, two, something like that. So this is two. Basically it's a number. It indicates how many topics are studied. So that's the demo. So this is the demo, and that's the end of my presentation. If you have any questions, please raise your hand. If not, can you use the microphone, please? If you want to write a function on fast platform, and maybe this is a function you need to connect to the third party, like objects and storage, like storage or Kafka, then will you provide some resources, and also there may be a huge number of codes for the function and service. If you use objects, storage, it will suggest you to use cloud service to do that. For example, use the REST for API, call that. If you can use the third party existing services, then just use that service. If that service is not available, then you can bundle your code and the database. That would involve a huge project. So what about IBM? I mean, if I use the IBM service, then will IBM provide some grad service for us? Yes, IBM's functions are integrated with IBM's cloud service. So if you use the services on IBM cloud, it's very convenient. Thank you. So after listening to your presentation to my knowledge, so you use the exporter to provide some metrics for monitoring for Prometheus. So for the image display, do you have any measures in this regard? In our community, there's a developer, develop the Grafana interface, but not on Prometheus. Okay. Thank you. One more question. Thank you. One more question. So will IBM provide some result tracing or monitoring? Yes. What about REST system? REST system is also available. Thank you.