Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI
This information is Copyright 2009 Sun Microsystems
1. Introduction
1.1. Project/Component Working Name:
EOF sag
1.2. Name of Document Author/Supplier:
Author: Garrett D'Amore
1.3 Date of This Document:
16 November, 2009
4. Technical Description
EOF of sag
----------
As part of the process of unravelling dependency trees to allow
removal of some other antiquated software, we have run into a situation
where sag(1) is the last linchpin preventing cleanup of a bunch of other
legacy components.
sag is a tool that generates Tek 4014 format graphs from the output of
"sar". These graphs can be viewed using either the Tek mode window
in xterm(1), or by further converting them to PostScript using posttek(1).
It turns out that the mechanism which sag uses to generate graphs is
incompatible with more modern graphing solutions as it has a few hacks
that depend on the specific quirks of legacy graph(1). An initial
effort at converting the tool to use GNU graph proved to be ... non-trivial,
due largely to the very hackish nature in which the sag abuses graph.
Additionally, these hacks, and other limitations in the tools, actually
produce suboptimal output... indeed this author would even go so far as
to call them outright "ugly", compared to what can be generated with
more clean solutions based on gnuplot, etc.
While it is certainly the case that sag could be updated to use
gnuplot much more elegantly, it is our belief that the effort required
to do so, and to preserve complete command line syntax, is an expense
that is out of balance with the rewards of any such effort. The sag tool
itself is so limited, unfriendly and awkward that we believe that most
sites that have wanted graphical display of sar data have sought
other solutions: either implementing scripts around gnuplot or spreadsheet
programs in house, or by using other 3rd party solutions.
It turns out that there are a much more functional, and usable, options
available from third parties. One example we've looked at in some detail
is kSar (http://ksar.atomique.net/), which is available as an Open Source
Java application. While still having a few rough edges, we believe that
this product (and other options like it) represent a much better solution
for administrators looking to graphically process sar data.
With this in mind, we are requesting to EOF the sag application altogether.
We believe that its loss will be felt by very few, and that the expenses
of keeping sag around far outweigh any benefit we gain by doing so.
We are expressly requesting permission to do this without having a plan
to integrate a "replacement". kSar could potentially be integrated in
the future, but we would prefer not to have this as a dependency for
this effort. Ultimately we believe that this is a case where 3rd party
tools should be used to answer the different needs of administrators.
There is no "drop in" replacement for "sag", in any event.
(Aside: the use of sar based statistics itself is perhaps something
that warrants further examination. In the OpenSolaris era, we have
other options, such as JKstat, and DTrace, which might arguably be
claimed offer far more options for detailed observability into the
system workings. That said, many many organizations over the years
(decades!) have come to rely on raw sar data to help them better understand
what their systems are doing. We believe sar is likely to have utility
for some years to come, as a result.)
6. Resources and Schedule
6.4. Steering Committee requested information
6.4.1. Consolidation C-team Name:
ON
6.5. ARC review type: FastTrack
6.6. ARC Exposure: open
