TARS service information reporting | Full service monitoring

The author | Eaton

Guide language | service after put into running, it’s hard to avoid abnormal, usually through a service log screen problem. However, this way of troubleshooting problems is sometimes inefficient, especially when there are many logs and you don’t know how to start, it is very troublesome. Why not let the service report errors? This article will introduce several information reporting methods in TARS.

Introduction to the

TARS framework integrates the function of service information reporting, including service status statistics reporting, abnormal reporting, attribute statistics reporting and other three information reporting statistical methods, realizing the monitoring of service health in many aspects. The three information reporting modes are implemented using Stat, Notify, and Property respectively. The following figure

The service monitors the state of the service by reporting its own information from different dimensions to these three nodes. So let’s look at these three ways of reporting information.

Status Statistics Report

The so-called status statistics reporting refers to the TARS framework in which services report status information such as invocation time, timeout rate, and exception rate to Stat for statistics.

After the service invocation is reported to the interface, it is stored in the memory temporarily and reported to the Stat service after a certain point in time (the default value is once every minute). We call the time between two reporting time points a statistical interval, in which the same key is accumulated and compared.

Users generally do not need to develop status statistics reports. After services are correctly configured and deployed in the TARS framework, status statistics reports automatically.

Open the service management page of TarsWeb. On the service monitoring page of a service, you can view the status information about the service, including traffic, average time, and timeout rate, as shown in the following figure.

Exception reporting

Service status statistics report enables you to intuitively know the service status and health. However, it is not enough to collect the invocation information of some services in actual application scenarios. For better monitoring, the TARS framework supports reporting exceptions to Notify in the service directly, which can be viewed on the TarsWeb management page, or directly notifying users in combination with other alarm software or platforms. TARS provides exception reporting methods in different languages. This section will be based on examples of TarsCpp and TarsGo, as well as other language versions.

TarsCpp

TarsCpp provides a way to report exceptions using RemoteNotify::report

RemoteNotify::getInstance() - >report(info);
Copy the code

The parameter info indicates the abnormal information to be reported. The type of the parameter is string. You can directly report the string to Notify and view the reported string on the Notify page. For example, to create a TarsCpp service named demo.demoserver. DemoObj, run the following command

/usr/local/tars/cpp/script/cmake_tars_server.sh TestDemo DemoServer Demo
Copy the code

The project directory structure is as follows

DemoServer ├ ─ ─ the build# build directory├ ─ ─ CMakeLists. TXT# cmake build file└ ─ ─ the SRCSource file directory├ ─ ─ CMakeLists. TXT ├ ─ ─ Demo. H# Demo. Tars generated file├ ─ ─ DemoImp. CPPInterface implementation file├ ─ ─ DemoImp. HInterface implementation header file├ ─ ─ DemoServer. CPP# service implementation file├ ─ ─ DemoServer. HService implementation header file└ ─ ─ Demo. Tars# tars interface definition file
Copy the code

CPP then reports a message in the service initialization function DemoServer:: Initialize, so that when the service is started, a DemoServer Start message will be reported as follows

void
DemoServer::initialize(a)
{
    addServant<DemoImp>(ServerConfig::Application + "." + ServerConfig::ServerName + ".DemoObj");
    // Report information
    RemoteNotify::getInstance() - >report("DemoServer Start");
}
Copy the code

After the service is compiled and deployed, the information reported by the service can be seen in the real-time status of the service on TarsWeb, as shown in the following figure

TarsGo

TarsGo provides the following functions to report exceptions, similar in usage to TarsCpp

func ReportNotifyInfo(level int32, info string)
Copy the code

Level refers to the level of an exception, including NOTIFY_NORMAL, NOTIFY_WARN, NOTIFY_ERROR, and INFO.

We create a TarsGo service demo.notifyDemo.demoobj with the following command

$GOPATH/src/github.com/TarsCloud/TarsGo/tars/tools/cmake_tars_server.sh Demo NotifyDemo Demo github.com/ETZhangSX/NotifyDemo
Copy the code

The project directory structure is as follows

NotifyDemo ├ ─ ─ build ├ ─ ─ client │ ├ ─ ─ client. Go │ └ ─ ─ CMakeLists. TXT ├ ─ ─ CMakeLists. TXT ├ ─ ─ config. Conf ├ ─ ─ debugtool │ └ ─ ─ dumpstack. Go ├ ─ ─ demo_imp. Go ├ ─ ─ Demo. The tars ├ ─ ─. Mod ├ ─ ─. Sum ├ ─ ─ main. Go ├ ─ ─ start. Sh └ ─ ─ tars - protocolCopy the code

Like TarsCpp, we add exception reporting in Init of demo_imp. CPP

func (imp *DemoImp) Init(a) (error) {
        tars.ReportNotifyInfo(tars.NOTIFY_ERROR, "ssart")
        return nil
}
Copy the code

After the service is built and deployed, it can also be seen in the real-time status of the service

Exception reporting is a process of active reporting. Developers can actively report service errors through exception reporting, for example, in the try… When a catch catches an error, it reports it.

Attribute statistics reporting

In addition to status statistics and exception reporting, TARS also provides the function of attribute statistics. Developers can report business-related attributes and make statistics. To facilitate business use, TARS currently comes with the following statistics types:

Sum
Average (AVG)
Distribution (distr)
Maximum value (Max)
Minimum value (min)
Count

In TarsCpp, you can create and configure a property report object with createPropertyReport() and report property values by calling the object’s method Report. For example, if we want to monitor the maximum size of an array, we create a property reporting object with the property name array_size and configure the reporting method to be Max, the maximum value.

PropertyReportPtr reportPtr = Application::getCommunicator() - >getStatReport() - >createPropertyReport("array_size", PropertyReport::max());
// vector<int> a;
reportPtr->report(a.size());
Copy the code

Let’s take the example of a simple queue service implemented in C++ that contains two queue operation interfaces

pop: Number used at the front of the eject queue
push: Used to add a number to the queue

And the size of the queue in the service attribute statistics report.

. First of all, we create a new service called Demo PropertyDemo. TestObj service, and the new file Queue. J h, the project structure is as follows

└── Heavy Exercises ── Heavy Exercises ── Heavy Exercises ── Heavy Exercises ── Heavy Exercises ── Heavy Exercises ── heavy Exercises ── heavy Exercises ── heavy Exercises Heavy Exercises ── heavy exercises ── heavy exercises ── heavy exercises ── heavy exercises ── heavy exercises ── heavy exercises ── heavy exercisesCopy the code

Implement a simple thread-safe Queue class in queue.h as follows

#ifndef _QUEUE_H_
#define _QUEUE_H_

#include "util/tc_singleton.h"
#include "util/tc_thread_rwlock.h"

class Queue : public tars::TC_Singleton<Queue>
{
public:
    void Push(int value)
    {
        TC_ThreadWLock wlock(rw_locker_);
        q_.push(value);
    }
    void Pop(a)
    {
        TC_ThreadWLock wlock(rw_locker_);
        if(! q_.empty()) q_.pop(a); }int GetSize(a)
    {
        TC_ThreadRLock rlock(rw_locker_);
        return q_.size(a); }private:
    std::queue<int> q_;
    tars::TC_ThreadRWLocker rw_locker_; / / read/write locks
};
#endif
Copy the code

You can see that the Queue inherits from TC_Singleton, a singleton component provided in TarsCpp, by inheriting this class to make it a singleton.

To modify test. tars, we added two new interfaces pop and push to manipulate the queue of the service. The following

module Demo
{

interface Test
{
    int test(a);
    int push(int value);
    int pop(a);
};

};
Copy the code

Then add the declaration of the interface to testimp.h as follows

virtual int push(int value, tars::TarsCurrentPtr current);
virtual int pop(tars::TarsCurrentPtr current);
Copy the code

The two interfaces are implemented in TestImp. CPP as follows

#include "Queue.h".int TestImp::push(int value, tars::TarsCurrentPtr current)
{
    Queue::getInstance() - >Push(value);
    return 0;
}

int TestImp::pop(tars::TarsCurrentPtr current)
{
    Queue::getInstance() - >Pop(a);return 0;
}
Copy the code

Finally, add the report of queue size in propertyDemo. CPP, as shown below

#include "Queue.h".void *reportFunc(void *pArg)
{
    static PropertyReportPtr reportPtr = NULL;

    // Initialize the distribution data range
    vector<int> v;
    v.push_back(10);
    v.push_back(30);
    v.push_back(50);
    v.push_back(80);
    v.push_back(100);

    // Create the Queuelength property, which uses all the centralized statistical methods, notice DISTRv's initialization
    reportPtr = Application::getCommunicator() - >getStatReport() - >createPropertyReport("queuelength",
                        PropertyReport::sum(),
                        PropertyReport::avg(),
                        PropertyReport::count(),
                        PropertyReport::max(),
                        PropertyReport::min(),
                        PropertyReport::distr(v));
    // Report periodically
    while (1)
    {
        // Reported attributes only support integers
        reportPtr->report(Queue::getInstance() - >GetSize());
        sleep(1);
    }
    return NULL;
}

int
main(int argc, char* argv[])
{
    try
    {
        pthread_t hThread;

        g_app.main(argc, argv);
        // Create a thread to run reportFunc and report the property information
        pthread_create(&hThread, NULL, reportFunc, NULL);

        g_app.waitForShutdown();
    }

    ...
}
Copy the code

In reportFunc, we create reportPtr with queuelength attribute, add the above six statistics policies, and report them at regular times. Then create a thread in the main function to run reportFunc.

After the service is built and deployed, we can see the statistics of the properties in the TarsWeb page service’s feature monitoring, as shown in the figure below

If no statistics can be found, synchronize monitoring information every five minutes.

In the figure above, you can see the values of the six statistics policies, which are the sum, minimum, maximum, distribution, count, and average of the Queue sizes. By calling the service’s interfaces POP and push, which add or pop objects to the Queue and change the Queue size, these values change accordingly.

We can choose policies based on our business needs, such as summation for traffic statistics.

conclusion

This paper introduces three TARS information reporting methods and how to use them. By using these three service information reporting methods, developers can monitor services in multiple dimensions and learn about real-time health status, exception information, and service-related attributes of services, helping developers better manage services.

TARS can quickly build systems and automatically generate code with ease of use and high performance in mind, helping developers and enterprises quickly build their own stable and reliable distributed applications in a microservice manner, allowing developers to focus only on business logic and improve operational efficiency. Multi-language, agile development, high availability, and efficient operations make TARS an enterprise-class product.

TARS micro services to help you digital transformation, welcome to visit:

TARS website: TarsCloud.org

TARS source: github.com/TarsCloud

Linux Foundation official micro services free course: www.edx.org/course/buil…

Get the TARS Official Training Ebook: wj.qq.com/s2/6570357/…

Or scan code to obtain:

TARS service information reporting | Full service monitoring

directory

Introduction to the

Status Statistics Report

Exception reporting

TarsCpp

TarsGo

Attribute statistics reporting

conclusion

Related Posts

The question of programming Languages: When to borrow and when to create?

After learning this JVM, the interviewer really took me no way!

JDK and CGLIB dynamic proxy principle difference?