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.
directory
- Introduction to the
- Status Statistics Report
- Exception reporting
- Attribute statistics reporting
- conclusion
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 queuepush
: 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: