OMEGAMON Enhanced 3270UI Webcast. OMEGAMON Architecture overview for a Modernized OMEGAMON Environment

Transcription

1 OMEGAMON Enhanced 3270UI Webcast OMEGAMON Architecture overview for a Modernized OMEGAMON Environment Speaker: Dale Hodson April 19, 2017 Joe Winterton josephw@us.ibm.com

2 Overview: Please ask questions at any time during the conference The goal is to help you get started with use of the Enhanced 3270UI. Remember the OMEGAMON II/OMEGAVIEW CUAs zos will go away (Statement of Direction issued) We want these sessions to be interactive! Feel free to use the chat window for feedback, questions and comments We are NOT recording this web conference so that: People feel free to ask questions (interactive please!) You can share with colleagues who have an interest a recorded version of the basic content we will do later and post for everyone We may need to get back to you if the question will take offline research Please keep your phone on mute when not speaking *6 toggles mute on phone conference facility if your phone does not have Mute button All functions discussed are GA except as noted OMEGAMON XE V540 Levels or higher 2

3 Missed previous sessions? Enhanced 3270UI Webcast Wiki One stop shopping LINK Previous sessions are available on YouTube Or search on Modernizing OMEGAMON Environment Session 1 Introduction to OMEGAMON Enhanced 3270UI (Basic functions) Session 2 Diving deeper with Situations; best practices for OMEGAMON on z/os Session 3 Monitor JVM on zos with the Enhanced 3270UI Session 4 Monitoring Storage with Enhanced 3270UI and OMEGAMON Storage V540 Session 5 Monitoring CICS with the Enhanced 3270UI and OMEGAMON CICS Session 6 Monitoring MQ/Messaging/Broker with the Enhanced 3270 UI Session 7 Monitoring Mainframe Networks and Comm Server with Enhanced 3270 UI 3

4 Possible Future Webcasts are: Problem Solving with OMEGAMON Performance Mgt Suite: DE Situation Status Tree, Managing Performance and availability with Situations Enhanced 3270UI All about security setup to allow sites the level needed Building Workspaces How to modify workspaces or build your own new ones DB2 DB2 realtime and historical thread analysis, SQL analysis, locking conflicts, buffer pool analysis focused. IMS Workloads, application performance and IMSplex management zos CECs, CPU issues and management, Memory (Real and Virtual) issues. USS issues 4

5 Other Announcements OMEGAMON for APM vnext Open Beta Transaction tracking functionality New visibility into JVM and CICS TG resources Join Early Access Program for updates. Next call May More information: OMEGAMON for JVM Redpaper Focus on JVM resources and z/os Connect EE monitoring More information: Reminder Latest information, blogs and videos on Service Management Connect More information: 5

6 Give us input on what webcasts you would like to see next to : Matt Aiken -- msaiken@us.ibm.com

7 OMEGAMON Monitoring Architecture Concepts, Components, and Flow Dale Hodson, OMEGAMON Development, April IBM Corporation

8 What I assume you already know You know OMEGAMON is a set of z/os mainframe-based performance monitors You know that OMEGAMON monitors a variety of systems: z/os, CICS, IMS, DB2, JVM, Storage, Network, MQ, z/vm You know that there are z/os LPARs that represent mainframe machines You know there are CICS regions, IMS regions, TCP Networks, and so forth that are the systems being monitored You know a little about VTAM and TCP/IP for communications You've (maybe) heard of: TOM, TEP, TEMS, and Agents IBM Corporation

9 What you see versus what's behind the scenes If you are an OMEGAMON user, what you see is a collection of screens These might be in a web browser or Windows client (TEP), or they might be on a 3270 (TOM) You move from screen to screen by selecting buttons, menu items, or rows As you move to a new screen, new data is collected and displayed You see real time data, historical data, and event data (Situations) Today we're going to learn what goes on behind these activities Knowing how things work behind the scenes can help you understand how to better use OMEGAMON and what's behind any problems you run into IBM Corporation

10 IBM Corporation So, what are we discussing today? Concepts: You'll learn that all OMEGAMON performance data is contained in tables You'll learn that you use SQL query statements to retrieve performance data You'll learn that the SQL points at tables and also points at locations Components: You'll learn about User Interfaces that request data, Agents that gather data, and servers that manage data flowing between the UIs and Agents You'll learn about non-ui clients that can also request data Flow: You'll learn about the flow of requests and responses between each of the Components, as we track an SQL request from start to finish You'll hear about the protocols used to support these flows Not covering: OMEGAMON Classic, OMEGAMON CUA, OMEGAVIEW Not covering: TEP, SMU, APM (GUIs), Cognitive, Watson, SoMoClo

11 This is Where We're Heading in The Presentation DRA TOM VTAM LU L U P C TEP REST TEPS SOAP Hub TEMS Remote TEMS Remote TEMS OMEGAMON Agent... OMEGAMON OMEGAMON... Agent Agent OMEGAMON Agent IBM Corporation

12 Concepts Performance data: How, What, and Where (How) SQL: Access data that is described in the Catalog SELECT <columns> FROM <application.table> (What) Catalog: Describes the performance data that is available to view Applications (CICS, z/os, DB2, MQ,...) Tables (File Control, Job Summary, Buffer Pools, ) Columns (Job Name, CPU Usage, MB in Use, ) (Where) Topology: Describes the systems that contain performance data Managed System Names (MSN) Managed System Lists (MSL, simply a named set of MSNs) ORIGINNODE (same as MSN) THRUNODE (manages requests/responses to/from ORIGINNODEs) IBM Corporation

13 IBM Corporation SQL

14 SQL overview SQL: Structured Query Language, access data that is described in the Catalog SELECT <columns> FROM <application.table> SQL statements are used to make a request for performance data from any of the OMEGAMONs The SQL statement identifies the Application, Table, and Columns from which we collect the performance data There isn't a real database that is being accessed by the SQL SELECT statement. Instead, the SQL tells an OMEGAMON Agent what data to collect The SQL query will also identify the managed systems from which the performance data should be collected The SQL query might also supply filtering criteria to limit the amount of data returned by the query IBM Corporation

15 SQL overview - a real query SELECT JOBNAME, ASID, CPUPCT, ORIGINNODE FROM KM5.ASCPUUTIL WHERE SYSTEM.PARMA('NODELIST','*MVS_SYSTEM',0) IBM Corporation

16 SQL and tables SQL: Structured Query Language, access data that is described in the Catalog SELECT <columns> FROM <application.table> Why SQL? This concept of performance data contained in tables of rows and columns makes asking for data a simple and consistent operation But generally, you (as an end-user) don't have to request data this way. You simply navigate to an Enhanced 3270 UI screen or a TEP screen and the screen definition contains the SQL statements needed to retrieve your data The results from an SQL query are the performance data you requested The results are returned in rows and columns The more data turned (rows * columns), the more costly it is to retrieve the data IBM Corporation

17 SQL clients - Who sends SQL? SQL: There are a variety of ways to get access to OMEGAMON performance data, and they all eventually result in SQL queries being issued The different ways include: Enhanced 3270 UI (the TOM ) workspaces or SOAP console Tivoli Enterprise Portal (the TEP ) screens SOAP requests via an HTTP client HTTP requests to the Dashboard Data Provider component of the TEPS Command line tools: z/os SPUFIL command, or other home grown IBM Corporation

18 SQL - Retrieve Catalog and Topology information - SELECT APPL_NAME, TABL_NAME, COLM_NAME FROM SYSTEM.SYSCOLUMNS - SELECT ORIGINNODE, THRUNODE FROM O4SRV.INODESTS IBM Corporation

19 SQL - Retrieve Catalog and Topology information, source code <WORKSPACE> <SUBPANEL> HEADER='Catalog' LINES=10 QUERY="SELECT APPL_NAME,TABL_NAME,COLM_NAME FROM SYSTEM.SYSCOLUMNS AT('*HUB') ORDER BY COLM_NAME ASC" DISPLAYCOLS=ALL SORTCOLS=ALL <SUBPANEL> HEADER='Topology' LINES=10 QUERY="SELECT ORIGINNODE,THRUNODE FROM O4SRV.INODESTS AT('*HUB') ORDER BY ORIGINNODE ASC" DISPLAYCOLS=ALL SORTCOLS=ALL <WORKSPACEEND> IBM Corporation

20 SQL - Realtime, Historical, and Events (Situations) The OMEGAMONs collect and display performance data in three ways: Realtime Data is from now Historical Data is from some time frame in the past Events Data is from an event that is being watched (a Situation ) All of these still use SQL to collect the data: Realtime SQL is sent from TOM or TEP on demand by a human user Historical SQL is sent by a program in the TEMS on a timer Events SQL is sent by a program in the TEMS on a timer In each case, the SQL is eventually routed to an Agent, which collects the data The timers for History and Events are set up when you define Historical collections and when you Create and Edit Situations IBM Corporation

21 IBM Corporation The Catalog

22 Catalog contents Catalog: Describes the performance data that is available to view Catalog information is in several Tables, which are accessible via SQL queries The Catalog is used by OMEGAMON components to verify that an SQL query contains tables and columns that are known to the Catalog The Catalog contains information about each column, in each table, and describes if the data is character or numeric, how large the data can be, and the precision and scale of numeric fields Catalog information can be stored in several different locations (Agents, TEPS, TEMS, User Interfaces) and should be identical in all locations (in general) If Catalog information is different at different locations, access to data described in the Catalog might not work as expected IBM Corporation

23 Catalog hierarchy Descriptions of all OMEGAMON data are in the Catalog, and these descriptions form a hierarchy a tree. A leaf node in the tree is APPL.TABLE.COLUMN: APPL: MVS System (KM5)... (and many more APPLs in the Catalog) TABLE: Address Space CPU Utilization COLUMN: CPU Percent... (and many more TABLEs for this APPL)... (and many more COLUMNs for this TABLE) APPL: CICSPlex (KCP) TABLE: CICSplex AID Analysis COLUMN: Terminal ID IBM Corporation

24 Catalog structure Catalog: Describes the performance data that is available to view Applications (CICS, z/os, DB2, MQ,...) Tables (File Control, Job Summary, Buffer Pools,...) Columns (Job Name, CPU Usage, MB in Use, ) When you want to see performance data, you ask for it by identifying the Application, the Table, and the Columns. There are short and long versions of the names of Applications, Tables, and Columns. Application and Table Names: SHORT: KM5.ASCPUUTIL LONG: MVS System.Address Space CPU Utilization Column Names: SHORT: JOBNAME, ASID, CPUPCT LONG: Job Name, ASID, CPU Percent JOBNAME ASID CPU % AAA BBB IBM Corporation

25 Catalog structure Live data in the Enhanced 3270 UI (TOM) IBM Corporation

26 Catalog creation Catalog: Describes the performance data that is available to view The Catalog originates from simple text files for each OMEGAMON product These files come in sets of three for each Application. For example, here are the file names for the OMEGAMON for z/os application (KM5): DOC (dockm5) example on next slides CAT (km5.cat) example on next slides ATR (km5.atr) The contents of these files are read and turned into the Catalog Note: Some information (long names, captions, help text, print formats, enumeration values, etc.) is only available in the text files, not in the Catalog The Self Describing Agent (SDA) component of the OMEGAMON infrastructure can enable automatic copying of new Catalog information between OMEGAMON Agents and other components (TEPS and TEMS) IBM Corporation

27 Catalog creation dockm5 source file IBM Corporation

28 Catalog creation km5.cat source file IBM Corporation

29 IBM Corporation Topology

30 Topology overview Topology: Describes the systems that contain performance data Topology information is in several Tables, which are accessible via SQL queries An SQL query uses the Catalog to know about the contents of each OMEGAMON table, but the SQL has to also be sent to the right places I can ask for CICS data, but I have to get my SQL request routed to the specific CICS regions that I'm interested in To enable this routing, the SQL query must also provide two items: ORIGINNODE(one or more Managed System Names via MSN or MSL) THRUNODE (the TEMS that manages the ORIGINNODE) The ORIGINNODE identifies an end point that collects performance data The THRUNODE identifies the manager that owns the end point SELECT FROM AT('<thrunode>') WHERE ORIGINNODE='<originnode>' You can view every OMEGAMON end point (Agent) and its originnode and thrunode from the TOM's Hub Topology screen IBM Corporation

31 Topology - Displayed in the Enhanced 3270 UI The first two columns are the ORIGINNODE and the THRUNODE: IBM Corporation

32 Topology Routing the SQL to the correct Systems The THRUNODE is the manager (a TEMS) that owns the end point (an Agent) SELECT <columns> FROM <application.table> AT('<thrunode>') Inside the TOM and TEPS, internal code modifies the SQL query on the fly so that the query now contains an AT clause If an SQL query is sent without the AT clause, the query will be managed at the Hub TEMS, which is generally not what you want Instead you want the SQL query to run at the Agent, and the SQL is routed to the correct Agent by specifying the <thrunode> that manages the Agent The SOAP interface (at a TEMS) does not add the AT clause, so SQL queries issued via SOAP must already contain a correct AT clause NOTE: Every SQL query is first sent to the Hub TEMS, then the Hub TEMS routes the query to the appropriate THRUNODE, which then sends the SQL to the Agent IBM Corporation

33 OMEGAMON Components and Flow The Big Picture User starts here: 3270 or PC Use SOAP Use REST DRA OMEGAMON Agent Remote TEMS TOM VTAM LU THRUNODE ORIGINNODE L U SOAP Hub TEMS (There can be many Remote TEMSes, just a few, or dozens, or hundreds) TEP Remote TEMS... (Agents are z/os, CICS, MQ, etc OMEGAMON OMEGAMON... across LPARs and Sysplexes and also Agent Agents for Windows, Unix, etc) Agent P C REST TEPS OMEGAMON Agent IBM Corporation

34 OMEGAMON Components and Flow One SQL query DRA 6 8 OMEGAMON Agent Remote TEMS 7 TOM VTAM LU L U 10 5 Hub TEMS SQL sent from the TOM 1. User of TOM asks for a screen refresh 2. TOM finds the SQL query in the screen definition 3. TOM sends SQL query to DRA 4. DRA relays the SQL query to the Hub TEMS 5. Hub TEMS sends SQL query to Remote TEMS 6. Remote TEMS sends SQL query to Agent 7. Agent collects the data requested in the SQL query 8. Agent returns the data to the Remote TEMS 9. Remote TEMS returns the data to the Hub TEMS 10. Hub TEMS returns the data to the DRA 11. DRA returns the data to the TOM 12. TOM displays the returned data SQL sent from the TEP - Very similar to above - TEP instead of TOM - TEPS instead of DRA IBM Corporation

35 IBM Corporation Almost Done

36 TOM screens of interest: Topology (KOBHBTPO) IBM Corporation

37 TOM screens of interest: Situation Editor (KOBSED1) IBM Corporation

38 TOM screens of interest: the Status Tree (KOBSITST) IBM Corporation