Generic Log Adapters- A Step towards building a ...

SHORT PAPER International Journal of Recent Trends in Engineering, Vol 2, No. 3, November 2009

Generic Log Adapters- A Step towards building a Parser Based Self Healable Autonomic System M.M.Math1, Seetha.M2, U.P.Kulkarni3, and A.R.Yardi4 1

Department of Information Science & Engineering, KLS, Gogte Institute of Technology, Belgaum, India. Research Scholar, Graphic Era University, Dehradun, Uttarkand, India Email: [email protected]. 2 Department of Computer Science & Engineering, G.Narayanamma Institute of Technology, Hyderabad, India. 3 Department of Computer Science & Engineering, S.D.M. College of Engineering and Technology, Dharwad, India.. 4 Dy. Director, Walchand College of Engineering and Technology, Sangli, India. Email: { smaddala2000, upkulkarni, aryardi }@yahoo.com. The concept of Autonomic Computing was proposed to answer this need. Autonomic computing has 4 basic key elements. They are self configuration, self healing, self optimization and self protection. In short these elements are known as self CHOP.

Abstract— Autonomic computing is a promising new

concept in system development. Its objective is to increase reliability by designing systems to be Selfmanaging. The Autonomic system approach of IBM is based on the processing of the log files generated by the applications of different formats. In order to work together with other heterogeneous log files, each log file should be converted to a standard called Common Base Event (CBE), by writing separate code called adapters and then this could be used for further processing. As deployment of applications increases, so are the log files and hence the need for writing separate adapters for each product log file also increases. This makes the work tedious and system more complex. This paper aims at providing an improved version of IBM’s approach by alternate way of writing Generic Log Adapter (GLA). The proposed approach allows each vendor to write their own log file in the format required for them, yet able to coordinate in heterogeneous work culture. This work improves the performance by avoiding writing multiple Adapters as it exists now with IBM.

•

•

• •

Index Terms—: Autonomic computing, Common Base

An autonomic system is an interactive collection of autonomic elements-individual system constituents that contain resources and services to humans and other autonomic elements. Autonomic elements will manage their internal behavior and their relationships with other autonomic elements in accordance with policies that humans or other elements have established. An autonomic element must be able to locate input services that it needs, in turns other elements that requires its output services must be able to locate that element.

Event, Log Trace Analyzer, Regular expressions and Language grammar. I. INTRODUCTION Over the past 20 years, the maturing of Information Technology (IT) has been the primary driver of business change and growth. At the same time, IT management has become increasingly complex because the systems being managed have themselves become complex. Anticipating that support of technology will continue its upward trend of cost and complexity, some forward thinking IT architects have devoted considerable time and effort to devising solutions. It was out of this process that the idea of Autonomic Computing arose.

An autonomic element must have associated with it a set of output services it can perform and a set of input services that it requires expressed in standard format so that other autonomic elements can understand it. An autonomic element is always associated with a log file-a file that lists the action that has occurred. Since these log files are represented in different formats, it is difficult to interrelate different autonomic elements. Hence we need to have a standard format that can be used by the autonomic computing systems. Autonomic computing is the ability of an IT infrastructure to adapt to change in accordance with business policies and objectives. The way to handle the problem of managing a complex IT infrastructure is to

The term “Autonomic Computing” was actually coined in 2001 by Paul Horn, a senior vice president of research for IBM [4]. He saw the trend towards smaller, cheaper and more powerful systems and correctly anticipated the result that are seen today –that companies would begin to assemble a large number of interconnected devices, then struggle to install, configure, manage and maintain them, progress technologically.

© 2009 ACADEMY PUBLISHER

Self configuration: The autonomic system is capable of configuring itself and making dynamic adjustments to that configuration as its environment changes. Self healing: The autonomic system must be able to discover problems or potential problems and find alternate ways of using resources or reconfigure the system to keep functioning smoothly. Self optimization: The autonomic system monitors its constituent parts and fine-tunes workflow to achieve established system goals. Self protection: The autonomic system must be able to protect itself from various types of internal/external attacks and failures to maintain overall system security and integrity.

102

SHORT PAPER International Journal of Recent Trends in Engineering, Vol 2, No. 3, November 2009 be reflected as a configuration change notification through the sensor interface. Web services can (and will) be used to implement sensor-effectors functions. By utilizing a Web services architecture for communication to the managed resource touch point, current approaches to resource management can be reused and wrapped with a Web service

create computer systems and software that could respond to changes in the IT (and ultimately, the business) environment, so the systems can adapt, heal and protect themselves. In an autonomic environment, components work together, communicating with each other and with high-level management tools. They could manage or control themselves and each other. Components could manage themselves to some extent, but from an overall system standpoint, some decisions need to be made by higher level components that can make the appropriate trade-offs based on policies that are in place.

B. Autonomic Manager The autonomic manager is a component that implements the control loop. The architecture dissects the loop into four parts that share knowledge:

Let us start by looking at how a single entity is managed in an autonomic environment. Fig. 1 represents the control loop that is the core of the autonomic architecture.

The Monitor part provides the mechanisms that collect, aggregate, filter, manage, and report details (metrics and topologies) collected from an element. The Analyze part provides the mechanisms that correlate and model complex situations. These mechanisms allow the autonomic manager to learn about the IT environment and help predict future situations The Plan part provides the mechanisms that structure the action needed to achieve goals and objectives. The planning mechanism uses policy information to guide its work The Execute part provides the mechanisms that control the execution of a plan with considerations for on-the-fly updates. II. RELATED WORK IBM’s work over the years on Autonomic Computing has yielded an ‘Autonomic Computing Toolkit [4]’ which assists software developers in enabling components, products, and solutions to become autonomic. The toolkit also provides the base for developers of management software to be able to manage entities that have been properly enabled. The Toolkit has tools like Log Trace Analyzer, Generic Log Adapter, Symptom Catalog, and Correlation Engine etc, which can together implement autonomic solutions [2, 3]. Symptom Catalog is a repository of the rules which are used for monitoring the applications. Symptom Catalog maintains rules and associated steps to be taken for that rule. Fig.2 depicts the IBM’s Autonomic Computing toolkit that provides such a Symptom Catalog..

Figure- 1: IBM’s Autonomic Computing control loop

A. Managed Resources The managed resource [6] is a controlled system component. The managed resource can be a single resource or a collection of resources. The managed resource is controlled through its sensors and effectors. The sensors provide mechanisms to collect information about the state and state transitions of an element. Sensors can be implemented using a set of get operations to retrieve information about the current state, or a set of management events (unsolicited, asynchronous messages, or notifications) that flow when the state of the element changes in a significant way, or both. The effectors are mechanisms that change the state (configuration) of an element. In other words, the effectors are a collection of set commands or application programming interfaces (APIs) that change the configuration of the managed resource in some way. The combination of sensors and effectors form the manageability interface (referred to as the touch point) that is available to an autonomic manager. The architecture encourages the idea that sensors and effectors are linked together. For example, a configuration change that occurs through effectors could © 2009 ACADEMY PUBLISHER

III. PROPOSED WORK Although technologies exist for autonomic behavior of a system, the complex nature and need for a huge knowledge base to operate such tools are what keeping a small scale system administrator from implementing Autonomic solutions. The need for an easier way of maintaining symptom rules for an administrator is evident.

103

SHORT PAPER International Journal of Recent Trends in Engineering, Vol 2, No. 3, November 2009

  Figure-2: ASM Architecture

The Autonomic System approach of IBM is based on the processing of the log files generated by various products [7, 8]. Each product has its own log file format. So each log file could be converted in to a standard called Common Base Event (CBE) before being processed. This could necessitate the additional work of converting each log file to CBE by writing separate code called adapters. Alternatively, in this paper, a better approach to IBM’s work, called a Parser Based Generic Log Adapter, a single tool that converts each log file or interprets each log file thereby avoiding writing separate adapters is being proposed.

Figure-3: Proposed Generic Log Adapter. A. GLA-e-r Features. 1.

Each product defines the log file format and its interpretation using generic notations. 2. These generic notations are to be used to read the heterogeneous log file during run time and parse/interpret each event registered. 3. Run time actions like sending SMS and Email are to be provided. The proposed system could be developed in Java and tested for IIS server. The sample IIS log file format and corresponding log .instances are shown bellow. Program Module- 1,and 2 gives the listing of Know-how (IIS)-LEX and YACC. Fig. 1 represents The GUI system implemented.

. Fig. 3 shows the architecture of the proposed system and its housing in operational environment. Here each product is allowed to define the log file format in its own way using generic notations called ‘regular expressions/Language grammars’ used by compilers. These generic notations (know-how) are different for each product, but themselves are represented in generic notations called regular expressions/Grammars. The Fig. 4 depicts the sequence diagram and also working of the proposed GLA. Following are the steps followed by the GLA. 1 Administrator logs in the GLA-e. 2 GLA-e prompts for log file location and get it from administrator. 3 GLA-e prompts for ‘know how’ location and gets it from administrator . 4 GLA-e prompts for the location lex & yacc tools 5 GLA-e reads ‘know how’ – a regular expression / grammar describing log file format. 6 GLA-e allows administrator to edit ‘Know How’ so that administrator can attach action routines to ‘Know How’ read. 7 Use lex & yacc to generate run time GLA called GLA- r. 8 GLA-r being generated from lex & yacc. 9 GLA-e calls the appropriate routines of GLA-r. 10 The routine GLA-r reads the contents of the log file continuously and takes the action as per the policies specified till the program is being terminated by GLA-e. 11 GLA-e terminâtes GLA-r

© 2009 ACADEMY PUBLISHER

B. IIS log file format: 1. #Software: 2. #version: 3. #date:

---

4.#fields: C. Example of Logfiile Instances 5.#Software: Microsoft Internet Information Services 2.1 6. #version: 2.1 7. #date: 2008-12-19 12 :12 :12 8 .07:33:11 127.0.0.1 GET /index.html 200 9. 07:38:25 127.0.0.1 GET /test.html 404 As an illustration, consider the line number -8 of log file instance with the log file entry as “07:33:11 127.0.0.1 GET /index.html 200”. Program Module-1 and Program Module- 2 gives the Lex and Yacc specification of Know-how and are specified at line number 18 thru 22 and line number from 65 thru 66 respectively. Also, the Program Module-2 specifies the action for this particular 104

SHORT PAPER International Journal of Recent Trends in Engineering, Vol 2, No. 3, November 2009 pattern of log file which is between line numbers 124 thru 127. This action routine could be customized as per the requirements of the administrator

Figure-6 Processing of IIS log file by GLA-e-r

IV. CONCLUSION The autonomic system approach of IBM is based on the processing of the log files generated by the various products. Each product has its own log file format. Hence each log file should be converted into a standard called Common Base Event (CBE), before being processed. This requires writing adapter for every log file for every product. The proposed system eliminates writing adapters for each log file for each product, thereby saving time and cost of code writing. Figure-4 working of GLA-e-r

ACKNOWLEDGEMENTS Authors are grateful to the research associates: Mr. Yashraj Mungale, Ms. Divya Tantri, Ms. Urmila Rathod, and Ms. Jeetal Shah of Gogte Institute of Technology, Belgaum affiliated to Visveswaraya Technological University, Belgaum, Karnataka (INDIA), for their contribution in implementing and experimentally verifying the design concepts proposed. REFERENCES. [1] M.G Hinchey and R. Sterritt, “Self Managing Software in Computer” IEEE Computer Society, volume 39 pages 107-109, February 2006. [2] S. Hariri and Et al., “The Autonomic Computing Paradigm in Cluster Computing”, The Journal of Networks, Software Tools and Applications, Springer Science Business Media B.V.(Kluwer Achadamic Publishers), Volume 9, pages 5-17 January 2006. [3] L.M Durham, M. Mlienkovic, P. Cayton, “Platform support for autonomic Computing: A research vehicle”, IEEE International Conference on Autonomic Computing”, (ICAC ’06), June 2006. [4] E. Patouni , N. Alonistioti, “A Framework for the Deployment of Self Managing and Self Configuring Components in Autonomic Environments”, International Symposium on a world of wireless,

Figure-5 GLA-e-r

© 2009 ACADEMY PUBLISHER

105

SHORT PAPER International Journal of Recent Trends in Engineering, Vol 2, No. 3, November 2009 return URL; } 22 [0-9]+ { yylval.symp =symlock(yytext); return STATUS; } 23 [0-9]\.[0-9] { yylval.symp = symlock(yytext); return VER; } 24 {Logname} { yylval.symp = symlock(yytext); return NAME; } 25 [#] { return yytext[0]; } 26 [ { return yytext[0]; } 27 . | \n { return yytext[0]; } 28 %%

Mobile and Multimedia Networks (WoWMoM 2006), pg. 480-484, June 2006. [5] M. Jarrett and R.Seviora, “Constructing an Autonomic Computing Infrastructure Using Cougar”, Proceedings of the 3rd IEEE International Workshop on Engineering of Autonomic and Autonomous Systems (EASe 2006), pg. 119-128, March 2006. [6] Nami, Mohammad Reza Sharifi, Mohsen “Autonomic Computing: A New Approach”, AMS ’07, 2007. [7] Liu Wen-jie, Li Zhan-huai, “Application of Policies in Autonomic Computing System Based on Partitionable Server”, IEEE workshop on parallel processing, 2007. [8] U.P.Kulkarni, J.V.Vadavi, M.M.Math, A.R.Yardi, “A Symptom Editor: A self Healing Autonomic System” International Journal of Computer Science and Network Security VOL. 8 No. 9, September 2008.

Program Module-2: Know how (IIS) – YACC

29 %{ 30 #include 31 #include "test.h" 32 #include 34 %} 35 %union { 36 struct symtab *symp; 37 } 38 %token SOFTWARE 39 %token NAME 40 %token VERSION 41 %token VER 42 %token DATE 43 %token DD1 44 %token TIME 45 %token IP 46 %token URL 47 %token METHOD 48 %token STATUS 49 %type logformat 50 %type f1 51 %% 52 Logformat: f1 {;} 53 ; 54 f1:'#' header_type {;} 55 | other {;} 56 ; 57 header_type: software 58 | version 59 | date {;} 60 ; 61 software: SOFTWARE ':' NAME '\n' { /* $1 ->Refers to label software $2 ->Refers to name of the software While writing symptom policy, you Are hereby informed use $1,$2….etc while forming expressions in C anguage formats in action routine, attached with this. */ /* call to action_1() */ Action_1(); };

Program Module-1: Know how (IIS) –LEX

1 2 3 4 5 6 7

%{ #include #include #include "test.h" #include "y.tab.h" %} Logd [0-9][0-9][0-9][0-9]\-[0-9] [0-9]\-[0-9][0-9]

8 Logtime [0-9][0-9][:][0-9][0-9][:] [0-9][0-9] 9 Logip[0-9][0-9][0-9]\.[0-9]\. [0-9]\.[0-9] 10 11 12 13

Logurl \/[a-z]+\.[a-z]* Logname [a-zA-Z][a-zA-Z0-9\. \t]* %% Software { yylval.symp = symlock(yytext); return SOFTWARE; } 14 version { yylval.symp = symlock(yytext); return VERSION; } 15 date { yylval.symp = symlock(yytext); return DATE; } 16 [ \t]* {; } 17{Logdd[} { yylval.symp = symlock(yytext); return DD1; } 18 {Logtime} { yylval.symp =symlock(yytext); return TIME; } 19 {Logip} { yylval.symp = symlock(yytext); return IP; } 20 GET | POST { yylval.symp = symlock(yytext); return METHOD; } 21 {logurl} { yylval.symp = symlock(yytext); © 2009 ACADEMY PUBLISHER

106

SHORT PAPER International Journal of Recent Trends in Engineering, Vol 2, No. 3, November 2009 83 char *p; 84for(sp=symtab;spstatus = strdup(s); 87if(sp->software && !strcmp(spsoftware,s)) 88 return sp; 89 if(!sp->software) 90 { 91 sp->software = strdup(s); 92 sp->time = strdup(s); 93 sp->version = strdup(s); 94 sp->date = strdup(s); 95 sp->method = strdup(s); 96 return sp; 97 } 98if(sp->name && !strcmp(sp->name,s)) 99 return sp; 100 if(!sp->name) 101 { 102 sp->name = strdup(s); 103 sp->ver_name = strdup(s); 104 sp->dd1 = strdup(s); 105 sp->ip =strdup(s); 106 sp->url = strdup(s); 107 return sp; 108 } 109 } 110 printf(" error"); 111 exit(1); 112 } 113 void action_1() 114 { 115 printf(" line indicating software\n "); 116 } 117 void action_2() 118 { 119 printf(" line indicating version \n "); 120 } 121 void action_3() 122 { 123 printf(" line indicating date and time:\n "); 124 } 125 void action_4() 126 { 127 printf("line indicating Time,ip,method,urlstatus:”); 128 }

63 version: VERSION ':' VER '\n' { /* $1-> Refers to label version $2-> Refers to software version While writing symptom policy, you Are hereby informed to use $1,$2…etc while forming expressions in C language formats in action routine attached with this. */ /* call to action_2() */ action_2(); }; 64 date: DATE ':' DD1 TIME '\n' { /* $1-> Refers to label date $2-> Refers to actual date(yyyy-mm-dd) $3-> Refers to actual time(hr:min:sec) While writing symptom policy, you are hereby informed to use $1,$2….etc.While forming expressions in C language formats in action routine attached With this */ /* call to action_3() */ Action_3(); } 65 ; 66 other:TIME IP METHOD URL STATUS’\n’ { /* $1-> Refers to actual time(hr:mm:sec) $2-> Refers to IP address $3-> Refers to method invoked $4-> Refers to URL $5-> Refers to status code While writing symptom policy, you are hereby informed to use $1,$2…etc. while Forming expressions in C language formats in action routine attached with this */ /*call to Action_4() */ Action_4(); }; 68 %% 69 main() 70 { 71 yyparse(); 72 } 73 yyerror() 74 { 75 printf("Errorerror"); 76 exit(0); 77 } 78 struct symtab * 79 symlock(s) 80 char *s; 81 { 82 struct symtab *sp;

© 2009 ACADEMY PUBLISHER

107