当前位置:网站首页>Tars dyeing logs collect and record specific logs

Tars dyeing logs collect and record specific logs

2021-01-22 15:29:58 Tars Foundation

author |Eaton

Introduction |
Keeping a log can be said to be a program ape / Yuan's daily development is a routine . In everyday business scenarios , It is often necessary to analyze the logs of specific users , It is difficult to meet the needs of general logging , What's the solution ?TARS The framework contains the function of dyeing log , The ability to log specific users , Solve this problem gracefully . This article will introduce the principle and function of dyeing log , And how to TARS Using dyeing logs in .

Catalog

  • background
  • I've just met you
  • TARS Overview of dyeing function
  • My first experience

    • Take the initiative to open the dyeing log
    • Passively open the dyeing log
    • Add specific logic
  • summary

background

In many business scenarios , You need to track the behavior of specific users , For example, some user feedback services have BUG, Need to check , But the findings were isolated , To find out the logs of these users separately for analysis ; Or is it APP There's a new feature coming online , First, test some users , We need to track the behavior of these users .

In the normal way , To retrieve the logs of these users from the logs that have been recorded . It looks simple , But in the context of micro Services , The calling relationship between services is complex ( Here's the picture ), The logs are distributed on each service node . For a call , You need to get the call chain first , Then find out the node of specific service call , Then get the log from the node , It's a very complicated process .

in addition , Logging consumes the performance of the program , Take up the user's computing resources . So in a formal environment , Daily business will control the amount of log printing , Make sure that log printing does not affect user services . When analyzing specific user behaviors , It's often necessary to record additional logs , To meet the needs of analysis and so on , It's obviously not realistic to directly increase the printing of logs .

so , The traditional way of logging can not satisfy the logging of specific user behavior , Dyeing log is to solve this problem .

I've just met you

What is a dyeing log ? In a call chain , The process of marking a specific requirement , Let the context information in the whole call chain be transmitted all the time , It's like being marked and stained in the beginning , This way of marking logs , We call it the dye log .

Simply speaking , That is, we only want the log information of a few users , Print another copy of the logs of these users by coloring the logs , And collected in the same place , So we can find the logs of these users in one place .

We can use dye logs to locate specific locations , You can also set some specific logic . For example, a wechat user reported that there was a problem with voice transmission , Through the user ID( WeChat ID ) To dye , After the back-end service receives the user's request , The processing log of the user's current call will be printed out , It's very easy to get the key information we need . Besides printing logs , You can also perform specific logic by coloring , For example, a new function is launched , Open to some users , By dyeing , The back-end service can determine whether the user is in the test list , Then execute the corresponding service logic .

TARS Overview of dyeing function

TARS The framework supports the coloring log function , The message of a specific user number can be dyed in a service interface , It is convenient to view the log of all subsequent call message flows caused by the user in real time . The following figure for TARS The dyeing process in

When the dyeing log is opened , In the business by specifying key value , For example, specify QQ Number is 123456 Users of , Subsequent requests of the user will be automatically colored in the framework , And through the log service (tarslog) Centralized printing of dyeing logs .

We just need to get to tarslog Check the corresponding dyeing log on the server where the service is located , The specific path is generally

/usr/local/app/tars/remote_app_log/tars_dyeing/dyeing/

This directory generally contains two kinds of log files : Dyed rolling log and dyed daily log , The formats of log file names are tars_dyeing.dyeing_roll_yyyymmdd.log, tars_dyeing.dyeing_day_yyyymmdd.log, such as :

#  Color scrolling log 
tars_dyeing.dyeing_roll_20201103.log
#  Daily log of dyeing 
tars_dyeing.dyeing_day_20201103.log
The rolling log is the local log of the service , It is generally used to record service debugging information ; The daily log is the remote log of the service , It is generally used to record important business information . When you turn on dyeing , If a request for dyeing is received , An extra copy of both logs will be printed to tarslog, Only the log of printing request is recorded , Save a file every day .

About the usage of scrolling logs and daily logs and more , You can see in the official document The log section , No more details here .

My first experience

TARS There are two ways to open the frame's coloring log: actively and passively . Let's take an example , Learn how to use these two ways to TARS Using dyeing logs in . The example source code used in this chapter can be found in here find .

Take the initiative to open the dyeing log

Take the initiative to open , In the business code of the requesting client , Turn on the dyeing log switch of the frame . The specific process is as follows :

  1. Declare the log switch in the appropriate place in the client program tars::TarsDyeingSwitch The object of .
  2. Call the enableDyeing Method to open the dyeing log . The called service will also turn on the dyeing switch automatically , And print the log to tarslog. If the called service calls other services , Then it is automatically passed to the next service .
  3. Before the dye log switch is turned off , All logs printed by the client and logs printed by the called service , Will print an extra copy to the log service tarslog.
  4. Client switch object deconstruction , Dyeing log off , Subsequent calls and log printing no longer generate dye logs .

below , Let's use an example to learn how to use it on the client side ( The main mediator ) Open the dyeing log on your own initiative .

example

Here we use C++ For example , According to the process just described , Open the dyeing log and call TARS service .

Before we start , We need to prepare one first TARS service , For later clients to call , See source code TestServer Source code . We create a service , Application name is TestApp, service name TestServer,Obj be known as Test,Test.tars The interfaces defined in the file are as follows

module TestApp
{

interface Test
{
    int test(string id, out string output);
};

};

TestImp.h and TestImp.cpp in test The definition and implementation of the interface are as follows

// TestImp.h
virtual int test(const std::string &id, std::string &output, tars::TarsCurrentPtr current);

//TestImp.cpp
int TestImp::test(const std::string &id, std::string &output, tars::TarsCurrentPtr current)
{
    //  Print local logs 
    TLOGDEBUG(__FILE__ << "|" << __LINE__ << "|" << "id: " << id << endl);
    output = id;
    return 0;
}

Build the service and build it in TarsWeb Just issue it with the Ministry of Commerce .

About TARS Service creation and deployment , Reference documents TARS Introduction to development , No more details here .

Next , Let's write a simple client Demo, Finish opening the dyeing log 、 call TARS The process of service interface , as follows

#include <iostream>
#include <string>

#include "servant/Communicator.h"
#include "servant/TarsLogger.h"
#include "util/tc_option.h"
#include "util/tc_file.h"

#include "Test.h"

using namespace std;
using namespace tars;

int main(int argc,char ** argv)
{
    try
    {   //  Initialize the communication agent , For invoking services 
        CommunicatorPtr comm = new Communicator();
        comm->setProperty("locator", "[email protected] -h 192.168.0.121 -p 17890 -t 10000");
        TarsRollLogger::getInstance()->setLogInfo("TestApp", "TestServer", "./log", 100000, 10, comm, "tars.tarslog.LogObj");
        TarsRollLogger::getInstance()->sync(false);
        TarsTimeLogger::getInstance()->setLogInfo(comm, "tars.tarslog.LogObj", "TestApp", "TestServer", "./log");

        {   //  Before opening the dyeing log , Print log , This log will only be printed to the local log .
            TLOGDEBUG     (__FILE__ << "|" << __LINE__ << "|" << "Test Before Dyeing" << endl);
            DLOG        << __FILE__ << "|" << __LINE__ << "|" << "D/Test Before Dyeing" << endl;
        }

        {   //  Declare a log switch object 
            TarsDyeingSwitch dye;
            //  Open the dyeing log 
            dye.enableDyeing();

            /*  After opening the dyeing log , Print log , You'll see it in the local log and the dye log 
             * TLOGDEBUG:  Print local  DEBUG  journal 
             *      DLOG:  Print remote logs by day 
             */
            {
                TLOGDEBUG(__FILE__ << "|" << __LINE__ << "|" << "Test After Dyeing" << endl);
                DLOG   << __FILE__ << "|" << __LINE__ << "|" << "D/Test After Dyeing" << endl;
            }

            //  Generate call agent 
            TestApp::TestPrx prx = comm->stringToProxy<TestApp::TestPrx>("TestApp.TestServer.TestObj");
            string output;
            //  call  test  Interface 
            prx->test("hello", output);
            cout << output << endl;
        }

        // The dye log switch has been destructed , Failure of dyeing function , Future logs will not be printed to the dye log 
        TLOGDEBUG(__FILE__ << "|" << __LINE__ << "|" << "~Dyeing" << endl);
        DLOG   << __FILE__ << "|" << __LINE__ << "|" << "D/~Dyeing" << endl;
    }
    catch(exception& e)
    {
        cerr << "exception:" << e.what() << endl;
    }
    catch (...)
    {
        cerr << "unknown exception." << endl;
    }
    sleep(10); //  Wait for the asynchronous log writing thread to synchronize log data to  logserver
    return 0;
}

You can see , The client contains three log printing , Print only once during the dyeing log on . meanwhile , When the dyeing log is on , Service called TestApp.TestServer.TestObj The interface of test.

After compiling and executing the client , We can find the path of the server where the log service is located /usr/local/app/tars/remote_app_log/tars_dyeing/dyeing/ in , Find the log file , Such as tars_dyeing.dyeing_roll_20201104.log and tars_dyeing.dyeing_day_20201104.log.

  • tars_dyeing.dyeing_roll_20201104.log
#  Use TLOGDEBUG Printed scrolling logs 
192.168.0.121|TestApp.TestServer|2020-11-04 03:56:53|139734968739712|DEBUG|main.cpp|37|Test After Dyeing
  • tars_dyeing.dyeing_day_20201104.log
#  Use DLOG Printed remote logs 
192.168.0.121|TestApp.TestServer|2020-11-04 03:56:53|main.cpp|38|D/Test After Dyeing

It can be seen that , In the log file , Only in TarsDyeingSwitch dye Logs printed in scope .

Interested readers can download the client Source code Try it yourself , Will be one of the IP Replace with... Of the node where you serve IP that will do .

Passively open the dyeing log

Passive on , It refers to the pre-set dyeing conditions on the server side of the request , Judge the transmission of key value , The server turns on its own dyeing log switch , Compared to the active opening , Passive open does not need to modify the client ( The caller ) Business code , It's a non intrusive way . The specific process is as follows :

  1. stay tars In the interface file , adopt routekey To set a parameter of the interface to key, Such as user ID;
  2. stay TarsWeb Pass in the user to be dyed through the framework command ID Value and service of Obj And interface name ;
  3. After the service receives a matching request , Dye the request packet , And print the log to the log service tarslog;
  4. If the service process continues to call other TARS service , Then it is automatically passed to the next service .

Let's take an example , Learn how to passively open dyeing logs .

example

  • Interface test Parameters of id Set to dye key

Here we continue to use the TARS service Demo. stay tars In the interface file , Modify interface test, Use routekey Specify the parameters id For dyeing key, as follows

    int test(routekey string id, out string output);

next , Replace the client ( The caller ) Originally used tars File and recompile the build to complete the modification of the client , There is no need to change the business code .

  • Open the dyeing log and set the ones to be dyed key value (test in id Value )

TARS In the frame Preset some frame commands , Can pass TarsWeb Platform send . Here we can order tars.setdyeing Open the dyeing log , The command format is as follows :

tars.setdyeing dyeingKey dyeingServant [dyeingInterface]

The three parameters are dyeing key value (routekey Tagged parameters , For this example id), Service object name , The name of the interface ( Optional ). For example, the service object in this article is TestApp.TestServer.TestObj, The interface name is test, We want to be right id by 123456 Users of , Then you can issue the following command through the management platform :

tars.setdyeing 123456 TestApp.TestServer.TestObj test

The order passed TarsWeb Page Service management -> More orders -> Custom command To send the , As shown in the figure

If there is no scrolling log output , You can set the log level to DEBUG

Complete the above steps , The opening of dyeing and dyeing users are completed ID Adding values .

When the interface test Yes id by 123456 To the service , The dyeing log will be printed separately , Also saved in the log service (tarslog) The path of the machine /usr/local/app/tars/remote_app_log/tars_dyeing/dyeing/ Under the scrolling log file and by day log file .

Here we can continue to use the client in the previous section , Because you don't need to actively declare and turn on the dye switch in your code , Streamlining client code , Just keep the original interface call logic , Revised as follows

#include <iostream>
#include <string>

#include "servant/Communicator.h"
#include "util/tc_option.h"
#include "util/tc_file.h"

#include "Test.h"

using namespace std;
using namespace tars;

int main(int argc,char ** argv)
{
    try
    {   //  Initialize the communication agent , For invoking services ( Readers don't need to pay attention to )
        CommunicatorPtr comm = new Communicator();
        comm->setProperty("locator", "[email protected] -h 192.168.0.121 -p 17890 -t 10000");

        //  Generate call agent 
        TestApp::TestPrx prx = comm->stringToProxy<TestApp::TestPrx>("TestApp.TestServer.TestObj");
        string output;
        //  call  test  Interface ,  Afferent staining id: 123456
        prx->test("123456", output);
        cout << output << endl;
        //  call  test  Interface ,  Afferent non staining id: tars
        prx->test("tars", output);
        cout << output << endl;
    }
    catch(exception& e)
    {
        cerr << "exception:" << e.what() << endl;
    }
    catch (...)
    {
        cerr << "unknown exception." << endl;
    }
    return 0;
}
Reference client Source code

After compilation and execution , We can do it in the dye log file , for example tars_dyeing.dyeing_roll_20201104.log

192.168.0.121|TestApp.TestServer|2020-11-04 15:58:08|140356905592576|DEBUG|TestImp.cpp|31|id: 123456

Add specific logic

We mentioned that earlier , The ability to add specific logic to the service for dyed users , Next we will continue with TestServer For example , Describes how to add specific logic to users .

The way to achieve it is very simple : By judging whether the incoming request is a dyeing request , Decide whether or not to execute specific logic . for example , We are TestImp.cpp Revision in China TestServer Interface implementation , If the current user is a dyeing user, output Dyeing is on, Ordinary users output users id, The code is as follows

 int TestImp::test(const string &id, string &output, tars::TarsCurrentPtr current)
{   //  Service object name 
    string servantName =  ServerConfig::Application + "." + ServerConfig::ServerName + ".TestObj";

    //  Judge whether it is a dyeing user 
    if (tars::ServantHelperManager::getInstance()->isDyeingReq(id, servantName, "test")) {
        //  The user return value 
        output = "Dyeing is on";
        TLOGDEBUG(__FILE__ << "|" << __LINE__ << "|" << "Test"  << endl);
        DLOG   << __FILE__ << "|" << __LINE__ << "|" << "D/Test"  << endl;
        return 0;
    }
    //  Non coloring user returns user  id
    output = id;
    TLOGDEBUG(__FILE__ << "|" << __LINE__ << "|" << "Test" << endl);

    return 0;
}

In the above code , We use ServantHelperManager Medium isDyeingReq To judge the request ID Whether it's dyed or not , Dyeing returns to true, And in if Add logic to the user execution .isDyeingReq You need to pass in three parameters ,routekey The input parameter value of the identifier (id), Service object name (TestApp.TestServer.TestObj) And interface name (test).

Next , Let's use the client instance in the previous section directly , It contains two interface calls

...
        //  call  test  Interface ,  Afferent staining id: 123456
        prx->test("123456", output);
        cout << output << endl;
        //  call  test  Interface ,  Afferent non staining id: tars
        prx->test("tars", output);
        cout << output << endl;
...

We are already in front of TarsWeb The platform is open to 123456 The dyeing of , It's not open. Right tars The dyeing of , Compile and execute the client , give the result as follows

Dyeing is on
tars

so id by 123456 The request successfully triggered the coloring logic , and id by tars My request didn't .

summary

Dyeing log fills in the deficiency of traditional logging method , In a way similar to dyeing , To achieve a specific user 、 Centralized printing of call chain logs , It is convenient to view and analyze logs .TARS The frame contains the dyeing function , It also provides two ways to open the dyeing log, active and passive , It is convenient for users to choose according to their needs . meanwhile , You can also add extra specific logic to specific requests , Further expand the use of scenarios , Such as grayscale publishing, etc .

TARS The system can be built quickly and the code can be generated automatically while considering the ease of use and high performance , Help developers and enterprises to quickly build their own stable and reliable distributed applications in the way of microservices , This allows developers to focus only on business logic , Improve operational efficiency . Multilingual 、 Agile R & D 、 The features of high availability and efficient operation make TARS Become an enterprise class product .

TARS Microservices help you with digital transformation , Welcome to visit :

TARS Official website :https://TarsCloud.org

TARS Source code :https://github.com/TarsCloud

Linux The foundation official micro service free course :https://www.edx.org/course/bu...

obtain 《TARS Official training eBook 》:https://wj.qq.com/s2/6570357/...

Or scan code to obtain :

QR

版权声明
本文为[Tars Foundation]所创,转载请带上原文链接,感谢
https://chowdera.com/2021/01/20210122152848275j.html