You're receiving this newsletter because
during the downloading or purchase of Sawmill, you checked the box
to join our mailing list. If you wish to be removed from this list,
please send an email, with the subject line of "UNSUBSCRIBE" to newsletter@sawmill.net
(please include the entire message, as the identifying information
is at the bottom).
News
Streaming Media West, Los Angeles, CA, November 2-3 2010 Please join us at Streaming Media West, where we will be showing
off the latest version of Sawmill, and giving away prizes. Prizes
include Sawmill licenses, t-shirts, mugs and more. SMW is being held
at the Hyatt Regency Century Plaza, and we look forward to seeing
you there!
Sawmill News Sawmill 8.1.7 shipped on October 13, 2010. This is a bug-fix
release--it fixes a few bugs. It also fixes a serious security
vulnerability which potentially allows remote attackers to execute
arbitrary code on the Sawmill server. This release is free to
existing Sawmill 8 users. Because of the security issue, this
release is recommended for anyone using Sawmill 8.1.5 or Sawmill
8.1.6 (earlier versions are not affected by the vulnerability), or
users of earlier version who are experiencing the issues described
in the 8.1.7 version history. You can download Sawmill 8.1.6 from http://sawmill.net/download.html
.
Sawmill 7 users can upgrade to Sawmill 8 for half of the license
price; or if you have Premium Support, the upgrade is free. Major
features of Sawmill 8 include support for Oracle and Microsoft SQL
Server databases, real-time reporting, a completely redesigned web
interface, better multi-processor and multi-core support, and
role-based authentication control.
This issue of the Sawmill Newsletter describes using Report
Table Filters to omit rows of reports as they are displayed.
Get The Most Out Of Sawmill With Professional Services
Looking to get more out of your statistics from Sawmill? Running
short on time, but need the information now to make critical
business decisions? Our Professional Service Experts are available
for just this situation and many others. We will assist in the
initial installation of Sawmill using best practices; work with you
to integrate and configure Sawmill to generate reports in the
shortest possible time. We will tailor Sawmill to your environment,
create a customized solution, be sensitive to your requirements and
stay focused on what your business needs are. We will show you areas
of Sawmill you may not even be aware of, demonstrating these methods
will provide you with many streamlined methods to get you the
information more quickly. Often you'll find that Sawmill's deep
analysis can even provide you with information you've been after but
never knew how to reach, or possibly never realized was readily
available in reports. Sawmill is an extremely powerful tool for your
business, and most users only exercise a fraction of this power.
That's where our experts really can make the difference. Our Sawmill
experts have many years of experience with Sawmill and with a large
cross section of devices and business sectors. Our promise is to
very quickly come up with a cost effective solution that fits your
business, and greatly expand your ROI with only a few hours of fee
based Sawmill Professional Services. For more information, a quote,
or to speak directly with a Professional services expert contact consulting@flowerfire.com.
Tips & Techniques: Using Report Table Filters
Most filtering of reports in Sawmill is done with Report Filters,
including Date/Time filters, or with Zoom filters. This type of
filtering operates at the level of database rows, or events--it
filters out specific events (typically, specific lines of log data),
and then shows a report based on the dataset with those lines
removed. For instance, you might filter out hits on a particular
page (maybe /robots.txt) in a web server log, and if there were 1000
such hits, those 1000 hits will be removed from every report--it
will be as though those hits were not in the database at all.
This newsletter deals with a lesser-known type of filtering, called
Report Table Filters. Report Table Filters do not operate at the
level of database rows, like Report Filters--they operate directly
on the report table. For instance, consider this Hostnames report
from an Apache log source (many columns omitted for simplicity):
Default Hostnames Report
With Report Filters, we could remove all the IP addresses by
filtering on numerical hostnames; or we could remove all the hits on
/robots.txt by filtering on the "page" field, which would probably
slightly affect the numbers from several rows. But what if we want
to see the "major" hosts, i.e., the ones with many page views? What
if we only want to see hosts with more than 100 page views?
Report Filters cannot do this--if you use "page_views > 100" as a
report filter, it will select nothing. That's because Report Filters
operate individually on rows of the database (events), and each web
log event is either a page view, which makes it page_views=1 for
that row, or it's not a page view, which makes it page_views=0 for
that row. No event has anything other than 0 or 1 for its page views
value, so selecting "page_views > 100" selects no events, and
gives an empty table.
Report Table Filters, however, are designed for just this work. They
operate on aggregated data, i.e., they operate on exactly
what you see in the report display. They can be thought of as rules
for hiding rows; they never change the values in a table, they only
make some rows disappear.
To see only rows with page_views > 100, start by clicking Customize
Report in Config. This goes to the Config interface for
editing this report; click the report element ("Hostnames"), and
then the Filters tab. On this tab, you can add a Date Filter
in the top field, a Report Filter in the middle field, or a Report
Table Filter in the bottom field. Report Table Filters use a
specialized Salang syntax--you use cell_by_name('fieldname')
to get the name of a cell in the current row (other syntax options
are available; click Expression Help to see documentation). In this
case, enter:
cell_by_name('page_views') > 100
in the Table filter expression field. This is a Salang expression
which compares the value of the page_views cell, with 100, and
evaluates to "true" if page_views is greater than 100. Rows are displayed
when the expression evaluates to true for that row; they are omitted
when it evaluates to false:
Report Table Filter Expression
Now Save Changes, and click View Reports to return to the report:
Hostnames Report With Report Table Filter
As you can see, the report now shows only those rows with page views
greater than 100.
Note that the Total line (and remainder line, if any) changes to
reflect the visible rows.
Advanced Report Table Filters
Since report table filter expressions are Salang, they can filter on
any criteria--Salang is a fully general programming language.
You can look up external information, examine other rows and cells
of the table, even run separate queries or perform network
operations, to determine whether each row should be visible or not.
This sort of advanced report table filter authoring typically
requires experience scripting in Salang, or assistance from a
Sawmill Expert.
Professional Services
This newsletter describes Report Table Filters, which filter out, or
hide, rows of report tables. If you need assistance with
implementing or configuring report table filters, or with any other
Sawmill tasks, our Sawmill Experts can help. Contact sales@sawmill.net
for more information.