|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
 |
|
Managing WMB Production Environment |
« View previous topic :: View next topic » |
Author |
Message
|
lancelotlinc |
Posted: Fri Oct 01, 2010 7:10 am Post subject: Managing WMB Production Environment |
|
|
 Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
Happy Friday!
Thought I would stir up some fun (er, trouble) and begin a philosophical thread about managing production environments.
I get the whole concept of different thinking between WMB on z/OS and WMB on Distributed. These two environments are worlds apart in some respects and exactly the same in other respects.
For example, in distributed systems (ie. AIX, Linux et. al.), there are many many systems because the cost per system is lower (smaller foot-print, more feet, like a centipede). Whereas, in z/OS-land, the focus is on larger foot-print, fewer feet (like a frog).
Because of the many more system installations a distributed system administrator must manage in a distributed network, the time one person (or one team) can devote to each box is less per box. On the other hand, in z/OS-land, because there are fewer systems, the SysAdmins can slave over every detail on the few boxes and spend much more time per box.
Thus, z/OS system administrators tend not to see the value in self-managing add-ons, dare we say, log4j. Hence the comment in a recent thread, "why is there such a focus on log4j? it wasn't part of the OP's requirement." In my naivetae, I had made an (incorrect) assumption that the benefits and need to use such a utility was accepted and known by all. Apparently, this assumption is incorrect.
The value a utility like log4j brings (and I am just using it as an example, many other distributed systems utilities could easily be substituted here) is self-apparent to experienced distributed systems engineers. They recognize that if you simply write a file to disk, the file will eventually consume too much disk space and require human intervention to correct. On the flip side to that scenario is employing automatic self-managing log file system like log4j which automatically shifts files around, and cleans up after itself so the human doesn't have to do it.
Am I mistaken, or am I right, in that mainframe adminstrators have a different perspective on managing their system compared to distributed systems administrators.
Please don't get me wrong here, I am not being critical of any group. I am merely stating that the systems are managed differently and therefore the people who manage these systems have differing perspectives on how to best do that for their own environment. _________________ http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
Back to top |
|
 |
mqjeff |
Posted: Fri Oct 01, 2010 7:27 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
Certainly distributed vs. zOS is a different mindset.
There's also a mindset in general on application level logging.
One could, for example, use Broker's esql LOG or MbService.log() methods to do all of one's application level logging, and NOT create a new subsystem to handle application level logging (which is what log4j does).
This would then cause any needed events to get passed out to the OS level system log, where normal OS level system log management routines would take over.
There are balances and considerations here - for example, does the application log actually need to contain business-sensitive data.... if so, then clearly one doesn't want to use OS level facilities, one wants a tighter control.
On the flip side, does one really want to one's application team (regardless of how competent) to reinvent and reimplement things that are already in place, and thus require new and additional management and troubleshooting steps (aka, "which log file do I need to look at?") |
|
Back to top |
|
 |
lancelotlinc |
Posted: Fri Oct 01, 2010 7:34 am Post subject: |
|
|
 Jedi Knight
Joined: 22 Mar 2010 Posts: 4941 Location: Bloomington, IL USA
|
Excellent point mqjeff and absolutely valid.
There are some business requirements that would dictate logs be created separate and apart from system logs. System logs should indicate health issues of the system.
A potential business requirement is to log each transaction so business analysts can perform assessment on which transaction types are being sent more frequently, etc. Certainly WebSphere Business Monitor (WBM) is an excellent tool for this. However, if WBM is not yet available to one's environment, one could capture (subscribe) to the WBM data stream created by WMB and write that out to a log until the PO is complete for the other. _________________ http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
Back to top |
|
 |
mqjeff |
Posted: Fri Oct 01, 2010 8:06 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008 Posts: 17447
|
lancelotlinc wrote: |
A potential business requirement is to log each transaction so business analysts can perform assessment on which transaction types are being sent more frequently, etc. |
I would personally never use a file for this kind of "log".
I'd use a database table. fed from a separate flow from a separate MQ queue... Potentially fed from a pub/sub duplication - or just a plain message multiplexer if pub/sub is too complicated.
Databases are designed to hold business data. Messages are business data. Application logs hold information related to the processing of business data, but should generally not hold significant amounts of or meaningful business data themselves (Soxley speaks!). |
|
Back to top |
|
 |
ovasquez |
Posted: Sat Aug 06, 2011 6:47 am Post subject: |
|
|
 Centurion
Joined: 09 Dec 2005 Posts: 141 Location: Lima, Peru
|
For flows in WMB z/OS, i use Database for logs and audit messages, files(node trace) for erros only. _________________ Oscar Vásquez Flores |
|
Back to top |
|
 |
smdavies99 |
Posted: Sat Aug 06, 2011 8:42 am Post subject: |
|
|
 Jedi Council
Joined: 10 Feb 2003 Posts: 6076 Location: Somewhere over the Rainbow this side of Never-never land.
|
Quote: |
Because of the many more system installations a distributed system administrator must manage in a distributed network, the time one person (or one team) can devote to each box is less per box
|
You never cease to amaze me. You actually think that distributed sysadmins devote any time to 'looking after as system'?
Excuse me while I roll around on the floor and have a good laugh.
How about this fo a slightly different scanario.
Quote: |
Because of the many more system installations a distributed system administrator must manage in a distributed network, the time a team can devote to preventative maintenance is largely approaching zero. A More realistic scenario is that until something breaks, it is strictly hands off.
|
How does that seem? Possibly a little closer to the truth? Maybe.
The there is the Broker support team. They are so busy that they can't do an PM either.
So who does the TLC of the system?
In my one place I worked, it was me. No one seemed to want to take an interest in looking after the 10 broker systems w.r.t TLC etc.
Yet, and this was the ironic part,
The other similar systems (JBOSS/ESB) had dedicated teams to do just that.
Why the difference?
IBM. pure and simple. They sold Broker on the premise that it 'just worked'.
I could go on but a pint (or three) of 6x is waiting for me in my local. _________________ WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
Back to top |
|
 |
|
|
 |
|
Page 1 of 1 |
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
|
|
|