Author: zznate
Date: Mon Oct 29 22:53:37 2018
New Revision: 1845181
URL: http://svn.apache.org/viewvc?rev=1845181&view=rev
Log:
CASSANDRA-14835 - Audit Logging in 4.0 blog post from Vinay Chella
Added:
cassandra/site/publish/blog/2018/10/29/
cassandra/site/publish/blog/2018/10/29/audit_logging_cassandra.html
cassandra/site/src/_posts/2018-10-29-audit_logging_cassandra.markdown
Modified:
cassandra/site/publish/blog/index.html
cassandra/site/publish/feed.xml
Added: cassandra/site/publish/blog/2018/10/29/audit_logging_cassandra.html
URL:
http://svn.apache.org/viewvc/cassandra/site/publish/blog/2018/10/29/audit_logging_cassandra.html?rev=1845181&view=auto
==============================================================================
--- cassandra/site/publish/blog/2018/10/29/audit_logging_cassandra.html (added)
+++ cassandra/site/publish/blog/2018/10/29/audit_logging_cassandra.html Mon Oct
29 22:53:37 2018
@@ -0,0 +1,358 @@
+<!DOCTYPE html>
+<html>
+
+
+
+
+<head>
+ <meta charset="utf-8">
+ <meta http-equiv="X-UA-Compatible" content="IE=edge">
+ <meta name="viewport" content="width=device-width, initial-scale=1">
+ <meta name="description" content="Database audit logging is an industry
standard tool for enterprises tocapture critical data change events including
what data changed and whotriggered the ev...">
+ <meta name="keywords" content="cassandra, apache, apache cassandra,
distributed storage, key value store, scalability, bigtable, dynamo" />
+ <meta name="robots" content="index,follow" />
+ <meta name="language" content="en" />
+
+ <title>Audit Logging in Apache Cassandra 4.0</title>
+
+ <link rel="canonical"
href="http://cassandra.apache.org/blog/2018/10/29/audit_logging_cassandra.html";>
+
+ <link rel="stylesheet"
href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.6/css/bootstrap.min.css";
integrity="sha384-1q8mTJOASx8j1Au+a5WDVnPi2lkFfwwEAa8hDDdjZlpLegxhjVME1fgjWPGmkzs7"
crossorigin="anonymous">
+ <link rel="stylesheet" href="./../../../../css/style.css">
+
+
+
+ <link rel="stylesheet"
href="https://use.fontawesome.com/releases/v5.2.0/css/all.css";
integrity="sha384-hWVjflwFxL6sNzntih27bfxkr27PmbbK/iSvJ+a4+0owXq79v+lsFkW54bOGbiDQ"
crossorigin="anonymous">
+
+ <link type="application/atom+xml" rel="alternate"
href="http://cassandra.apache.org/feed.xml"; title="Apache Cassandra Website" />
+</head>
+
+ <body>
+ <!-- breadcrumbs -->
+<div class="topnav">
+ <div class="container breadcrumb-container">
+ <ul class="breadcrumb">
+ <li>
+ <div class="dropdown">
+ <img class="asf-logo" src="./../../../../img/asf_feather.png" />
+ <a data-toggle="dropdown" href="#">Apache Software Foundation <span
class="caret"></span></a>
+ <ul class="dropdown-menu" role="menu" aria-labelledby="dLabel">
+ <li><a href="http://www.apache.org";>Apache Homepage</a></li>
+ <li><a href="http://www.apache.org/licenses/";>License</a></li>
+ <li><a
href="http://www.apache.org/foundation/sponsorship.html";>Sponsorship</a></li>
+ <li><a
href="http://www.apache.org/foundation/thanks.html";>Thanks</a></li>
+ <li><a href="http://www.apache.org/security/";>Security</a></li>
+ </ul>
+ </div>
+ </li>
+
+
+ <li><a href="./../../../../">Apache Cassandra</a></li>
+
+
+
+
+ <li>Audit Logging in Apache Cassandra 4.0</li>
+
+
+
+
+
+
+ </ul>
+ </div>
+
+ <!-- navbar -->
+ <nav class="navbar navbar-default navbar-static-top" role="navigation">
+ <div class="container">
+ <div class="navbar-header">
+ <button type="button" class="navbar-toggle collapsed"
data-toggle="collapse" data-target="#cassandra-menu" aria-expanded="false">
+ <span class="sr-only">Toggle navigation</span>
+ <span class="icon-bar"></span>
+ <span class="icon-bar"></span>
+ <span class="icon-bar"></span>
+ </button>
+ <a class="navbar-brand" href="./../../../../"><img
src="./../../../../img/cassandra_logo.png" alt="Apache Cassandra logo" /></a>
+ </div><!-- /.navbar-header -->
+
+ <div id="cassandra-menu" class="collapse navbar-collapse">
+ <ul class="nav navbar-nav navbar-right">
+ <li><a href="./../../../../">Home</a></li>
+ <li><a href="./../../../../download/">Download</a></li>
+ <li><a href="./../../../../doc/">Documentation</a></li>
+ <li><a href="./../../../../community/">Community</a></li>
+ <li>
+ <a href="./../../../../blog">Blog</a>
+ </li>
+ </ul>
+ </div><!-- /#cassandra-menu -->
+
+
+ </div>
+ </nav><!-- /.navbar -->
+</div><!-- /.topnav -->
+
+ <div class="content">
+ <div class="container">
+ <h2>Audit Logging in Apache Cassandra 4.0</h2>
+ <p>Posted on October 29, 2018 by the Apache Cassandra Community</p>
+ <h5><a href="/blog">« Back to the Apache Cassandra Blog</a></h5>
+ <hr />
+ <p>Database audit logging is an industry standard tool for enterprises to
+capture critical data change events including what data changed and who
+triggered the event. These captured records can then be reviewed later
+to ensure compliance with regulatory, security and operational policies.</p>
+
+<p>Prior to Apache Cassandra 4.0, the open source community did not have a
+good way of tracking such critical database activity. With this goal in
+mind, Netflix implemented
+<a
href="https://issues.apache.org/jira/browse/CASSANDRA-12151";>CASSANDRA-12151</a>
+so that users of Cassandra would have a simple yet powerful audit
+logging tool built into their database out of the box.</p>
+
+<h2 id="why-are-audit-logs-important">Why are Audit Logs Important?</h2>
+
+<p>Audit logging database activity is one of the key components for making
+a database truly ready for the enterprise. Audit logging is generally
+useful but enterprises frequently use it for:</p>
+
+<ol>
+ <li>Regulatory compliance with laws such as <a
href="https://en.wikipedia.org/wiki/Sarbanes%E2%80%93Oxley_Act";>SOX</a>, <a
href="https://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Security_Standard";>PCI</a>
and <a
href="https://en.wikipedia.org/wiki/General_Data_Protection_Regulation";>GDPR</a>
et al. These types of compliance are crucial for companies that are traded on
public stock exchanges, hold payment information such as credit cards, or
retain private user information.</li>
+ <li>Security compliance. Companies often have strict rules for what data can
be accessed by which employees, both to protect the privacy of users but also
to limit the probability of a data breach.</li>
+ <li>Debugging complex data corruption bugs such as those found in massively
distributed microservice architectures like Netflixâs.</li>
+</ol>
+
+<h2 id="why-is-audit-logging-difficult">Why is Audit Logging Difficult?</h2>
+
+<p>Implementing a simple logger in the request (inbound/outbound) path
+sounds easy, but the devil is in the details. In particular, the âfast
+pathâ of a database, where audit logging must operate, strives to do as
+little as humanly possible so that users get the fastest and most
+scalable database system possible. While implementing Cassandra audit
+logging, we had to ensure that the audit log infrastructure does not
+take up excessive CPU or IO resources from the actual database execution
+itself. However, one cannot simply optimize only for performance because
+that may compromise the guarantees of the audit logging.</p>
+
+<p>For example, if producing an audit record would block a thread, it
+should be dropped to maintain maximum performance. However, most
+compliance requirements prohibit dropping records. Therefore, the key to
+implementing audit logging correctly lies in allowing users to achieve
+both performance <em>and</em> reliability, or absent being able to achieve both
+allow users to make an explicit trade-off through configuration.</p>
+
+<hr />
+
+<h2 id="audit-logging-design-goals">Audit Logging Design Goals</h2>
+
+<p>The design goal of the Audit log are broadly categorized into 3
+different areas:</p>
+
+<p><strong>Performance</strong>: Considering the Audit Log injection points are
+live in the request path, performance is an important goal in every
+design decision.</p>
+
+<p><strong>Accuracy</strong> : Accuracy is required by compliance and is thus a
+critical goal. Audit Logging must be able to answer crucial auditor
+questions like âIs every write request to the database being audited?â.
+As such, accuracy cannot be compromised.</p>
+
+<p><strong>Usability & Extensibility</strong>: The diverse Cassandra
ecosystem
+demands that any frequently used feature must be easily usable and
+pluggable (e.g., Compaction, Compression, SeedProvider etc...), so the
+Audit Log interface was designed with this context in mind from the
+start.</p>
+
+<h2 id="implementation">Implementation</h2>
+
+<p>With these three design goals in mind, the
+<a href="https://github.com/OpenHFT";>OpenHFT</a> libraries were an
+obvious choice due to their reliability and high performance. Earlier in
+<a
href="https://issues.apache.org/jira/browse/CASSANDRA-13983";>CASSANDRA-13983</a>
+the <a href="https://github.com/OpenHFT/Chronicle-Queue";>chronical queue
+library</a> of
+OpenHFT was introduced as a BinLog utility to the Apache Cassandra code
+base. The performance of Full Query Logging (FQL) was excellent, but it only
instrumented mutation and read query paths. It was missing a lot of critical
data such as when queries failed, where they came from, and which user issued
the query. The FQL was also single purpose: preferring to drop messages rather
than delay the process (which makes sense for FQL but not for Audit Logging).
Lastly, the FQL didnât allow for pluggability, which would make it harder to
adopt in the codebase for this feature.</p>
+
+<p>As shown in the architecture figure below, we were able to unify the FQL
feature with the AuditLog functionality through the AuditLogManager and
IAuditLogger abstractions. Using this architecture, we can support any output
format: logs, files, databases, etc. By default, the BinAuditLogger
implementation comes out of the box to maintain performance. Users can choose
the custom audit logger implementation by dropping the jar file on Cassandra
classpath and customizing with configuration options in
+<a
href="https://github.com/apache/cassandra/blob/trunk/conf/cassandra.yaml#L1216-L1234";>cassandra.yaml</a>
+file.</p>
+
+<hr />
+
+<h2 id="architecture">Architecture</h2>
+
[... 175 lines stripped ...]
Modified: cassandra/site/publish/blog/index.html
URL:
http://svn.apache.org/viewvc/cassandra/site/publish/blog/index.html?rev=1845181&r1=1845180&r2=1845181&view=diff
==============================================================================
--- cassandra/site/publish/blog/index.html (original)
+++ cassandra/site/publish/blog/index.html Mon Oct 29 22:53:37 2018
@@ -102,6 +102,18 @@
<ul class="blog-post-listing">
<li class="blog-post">
+ <h4><a href="/blog/2018/10/29/audit_logging_cassandra.html">Audit
Logging in Apache Cassandra 4.0</a></h4>
+ <p>Posted on October 29, 2018 by the Apache Cassandra Community</p>
+ <p>Database audit logging is an industry standard tool for
enterprises to
+capture critical data change events including what data changed and who
+triggered the event. These captured records can then be reviewed later
+to ensure compliance with regulatory, security and operational policies.</p>
+
+
+ <h5><a href="/blog/2018/10/29/audit_logging_cassandra.html">Read
more »</a></h5>
+ </li>
+
+ <li class="blog-post">
<h4><a
href="/blog/2018/10/17/finding_bugs_with_property_based_testing.html">Finding
Bugs in Cassandra's Internals with Property-based Testing</a></h4>
<p>Posted on October 17, 2018 by the Apache Cassandra Community</p>
<p>As of September 1st, the Apache Cassandra community has shifted
the focus of Cassandra 4.0 development from new feature work to testing,
validation, and hardening, with the goal of releasing a stable 4.0 that every
Cassandra user, from small deployments to large corporations, can deploy with
confidence. There are several projects and methodologies that the community is
undertaking to this end. One of these is the adoption of property-based
testing, which was <a
href="http://cassandra.apache.org/blog/2018/08/21/testing_apache_cassandra.html";>previously
introduced here</a>. This post will take a look at a specific use of this
approach and how it found a bug in a new feature meant to ensure data integrity
between the client and Cassandra.</p>
Modified: cassandra/site/publish/feed.xml
URL:
http://svn.apache.org/viewvc/cassandra/site/publish/feed.xml?rev=1845181&r1=1845180&r2=1845181&view=diff
==============================================================================
--- cassandra/site/publish/feed.xml (original)
+++ cassandra/site/publish/feed.xml Mon Oct 29 22:53:37 2018
@@ -1,5 +1,208 @@
-<?xml version="1.0" encoding="utf-8"?><feed
xmlns="http://www.w3.org/2005/Atom"; ><generator uri="https://jekyllrb.com/";
version="3.4.3">Jekyll</generator><link
href="http://cassandra.apache.org/feed.xml"; rel="self"
type="application/atom+xml" /><link href="http://cassandra.apache.org/";
rel="alternate" type="text/html"
/><updated>2018-10-18T14:18:30+13:00</updated><id>http://cassandra.apache.org/</id><title
type="html">Apache Cassandra Website</title><subtitle>The Apache Cassandra
database is the right choice when you need scalability and high availability
without compromising performance. Linear scalability and proven fault-tolerance
on commodity hardware or cloud infrastructure make it the perfect platform for
mission-critical data. Cassandra's support for replicating across multiple
datacenters is best-in-class, providing lower latency for your users and the
peace of mind of knowing that you can survive regional outages.
-</subtitle><entry><title type="html">Finding Bugs in Cassandraâs Internals
with Property-based Testing</title><link
href="http://cassandra.apache.org/blog/2018/10/17/finding_bugs_with_property_based_testing.html";
rel="alternate" type="text/html" title="Finding Bugs in Cassandra's Internals
with Property-based Testing"
/><published>2018-10-17T20:00:00+13:00</published><updated>2018-10-17T20:00:00+13:00</updated><id>http://cassandra.apache.org/blog/2018/10/17/finding_bugs_with_property_based_testing</id><content
type="html"
xml:base="http://cassandra.apache.org/blog/2018/10/17/finding_bugs_with_property_based_testing.html";><p>As
of September 1st, the Apache Cassandra community has shifted the focus of
Cassandra 4.0 development from new feature work to testing, validation, and
hardening, with the goal of releasing a stable 4.0 that every Cassandra user,
from small deployments to large corporations, can deploy with confidence. There
are several projects and methodologies that
the community is undertaking to this end. One of these is the adoption of
property-based testing, which was <a
href="http://cassandra.apache.org/blog/2018/08/21/testing_apache_cassandra.html">previously
introduced here</a>. This post will take a look at a specific use of
this approach and how it found a bug in a new feature meant to ensure data
integrity between the client and Cassandra.</p>
+<?xml version="1.0" encoding="utf-8"?><feed
xmlns="http://www.w3.org/2005/Atom"; ><generator uri="https://jekyllrb.com/";
version="3.4.3">Jekyll</generator><link
href="http://cassandra.apache.org/feed.xml"; rel="self"
type="application/atom+xml" /><link href="http://cassandra.apache.org/";
rel="alternate" type="text/html"
/><updated>2018-10-30T11:50:41+13:00</updated><id>http://cassandra.apache.org/</id><title
type="html">Apache Cassandra Website</title><subtitle>The Apache Cassandra
database is the right choice when you need scalability and high availability
without compromising performance. Linear scalability and proven fault-tolerance
on commodity hardware or cloud infrastructure make it the perfect platform for
mission-critical data. Cassandra's support for replicating across multiple
datacenters is best-in-class, providing lower latency for your users and the
peace of mind of knowing that you can survive regional outages.
+</subtitle><entry><title type="html">Audit Logging in Apache Cassandra
4.0</title><link
href="http://cassandra.apache.org/blog/2018/10/29/audit_logging_cassandra.html";
rel="alternate" type="text/html" title="Audit Logging in Apache Cassandra 4.0"
/><published>2018-10-29T20:00:00+13:00</published><updated>2018-10-29T20:00:00+13:00</updated><id>http://cassandra.apache.org/blog/2018/10/29/audit_logging_cassandra</id><content
type="html"
xml:base="http://cassandra.apache.org/blog/2018/10/29/audit_logging_cassandra.html";><p>Database
audit logging is an industry standard tool for enterprises to
+capture critical data change events including what data changed and who
+triggered the event. These captured records can then be reviewed later
+to ensure compliance with regulatory, security and operational
policies.</p>
+
+<p>Prior to Apache Cassandra 4.0, the open source community did not have
a
+good way of tracking such critical database activity. With this goal in
+mind, Netflix implemented
+<a
href="https://issues.apache.org/jira/browse/CASSANDRA-12151">CASSANDRA-12151</a>
+so that users of Cassandra would have a simple yet powerful audit
+logging tool built into their database out of the box.</p>
+
+<h2 id="why-are-audit-logs-important">Why are Audit Logs
Important?</h2>
+
+<p>Audit logging database activity is one of the key components for
making
+a database truly ready for the enterprise. Audit logging is generally
+useful but enterprises frequently use it for:</p>
+
+<ol>
+ <li>Regulatory compliance with laws such as <a
href="https://en.wikipedia.org/wiki/Sarbanes%E2%80%93Oxley_Act">SOX</a>,
<a
href="https://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Security_Standard">PCI</a>
and <a
href="https://en.wikipedia.org/wiki/General_Data_Protection_Regulation">GDPR</a>
et al. These types of compliance are crucial for companies that are traded on
public stock exchanges, hold payment information such as credit cards, or
retain private user information.</li>
+ <li>Security compliance. Companies often have strict rules for what
data can be accessed by which employees, both to protect the privacy of users
but also to limit the probability of a data breach.</li>
+ <li>Debugging complex data corruption bugs such as those found in
massively distributed microservice architectures like Netflixâs.</li>
+</ol>
+
+<h2 id="why-is-audit-logging-difficult">Why is Audit Logging
Difficult?</h2>
+
+<p>Implementing a simple logger in the request (inbound/outbound) path
+sounds easy, but the devil is in the details. In particular, the âfast
+pathâ of a database, where audit logging must operate, strives to do as
+little as humanly possible so that users get the fastest and most
+scalable database system possible. While implementing Cassandra audit
+logging, we had to ensure that the audit log infrastructure does not
+take up excessive CPU or IO resources from the actual database execution
+itself. However, one cannot simply optimize only for performance because
+that may compromise the guarantees of the audit logging.</p>
+
+<p>For example, if producing an audit record would block a thread, it
+should be dropped to maintain maximum performance. However, most
+compliance requirements prohibit dropping records. Therefore, the key to
+implementing audit logging correctly lies in allowing users to achieve
+both performance <em>and</em> reliability, or absent being able to
achieve both
+allow users to make an explicit trade-off through configuration.</p>
+
+<hr />
+
+<h2 id="audit-logging-design-goals">Audit Logging Design
Goals</h2>
+
+<p>The design goal of the Audit log are broadly categorized into 3
+different areas:</p>
+
+<p><strong>Performance</strong>: Considering the Audit Log
injection points are
+live in the request path, performance is an important goal in every
+design decision.</p>
+
+<p><strong>Accuracy</strong> : Accuracy is required by
compliance and is thus a
+critical goal. Audit Logging must be able to answer crucial auditor
+questions like âIs every write request to the database being audited?â.
+As such, accuracy cannot be compromised.</p>
+
+<p><strong>Usability &amp; Extensibility</strong>: The
diverse Cassandra ecosystem
+demands that any frequently used feature must be easily usable and
+pluggable (e.g., Compaction, Compression, SeedProvider etc...), so the
+Audit Log interface was designed with this context in mind from the
+start.</p>
+
+<h2 id="implementation">Implementation</h2>
+
+<p>With these three design goals in mind, the
+<a href="https://github.com/OpenHFT">OpenHFT</a>
libraries were an
+obvious choice due to their reliability and high performance. Earlier in
+<a
href="https://issues.apache.org/jira/browse/CASSANDRA-13983">CASSANDRA-13983</a>
+the <a
href="https://github.com/OpenHFT/Chronicle-Queue">chronical queue
+library</a> of
+OpenHFT was introduced as a BinLog utility to the Apache Cassandra code
+base. The performance of Full Query Logging (FQL) was excellent, but it only
instrumented mutation and read query paths. It was missing a lot of critical
data such as when queries failed, where they came from, and which user issued
the query. The FQL was also single purpose: preferring to drop messages rather
than delay the process (which makes sense for FQL but not for Audit Logging).
Lastly, the FQL didnât allow for pluggability, which would make it harder to
adopt in the codebase for this feature.</p>
+
+<p>As shown in the architecture figure below, we were able to unify the
FQL feature with the AuditLog functionality through the AuditLogManager and
IAuditLogger abstractions. Using this architecture, we can support any output
format: logs, files, databases, etc. By default, the BinAuditLogger
implementation comes out of the box to maintain performance. Users can choose
the custom audit logger implementation by dropping the jar file on Cassandra
classpath and customizing with configuration options in
+<a
href="https://github.com/apache/cassandra/blob/trunk/conf/cassandra.yaml#L1216-L1234">cassandra.yaml</a>
+file.</p>
+
+<hr />
+
+<h2 id="architecture">Architecture</h2>
+
[... 124 lines stripped ...]
Added: cassandra/site/src/_posts/2018-10-29-audit_logging_cassandra.markdown
URL:
http://svn.apache.org/viewvc/cassandra/site/src/_posts/2018-10-29-audit_logging_cassandra.markdown?rev=1845181&view=auto
==============================================================================
--- cassandra/site/src/_posts/2018-10-29-audit_logging_cassandra.markdown
(added)
+++ cassandra/site/src/_posts/2018-10-29-audit_logging_cassandra.markdown Mon
Oct 29 22:53:37 2018
@@ -0,0 +1,211 @@
+---
+layout: post
+title: "Audit Logging in Apache Cassandra 4.0"
+date: 2018-10-29 00:00:00 -0700
+author: the Apache Cassandra Community
+categories: blog
+---
+
+Database audit logging is an industry standard tool for enterprises to
+capture critical data change events including what data changed and who
+triggered the event. These captured records can then be reviewed later
+to ensure compliance with regulatory, security and operational policies.
+
+Prior to Apache Cassandra 4.0, the open source community did not have a
+good way of tracking such critical database activity. With this goal in
+mind, Netflix implemented
+[CASSANDRA-12151](https://issues.apache.org/jira/browse/CASSANDRA-12151)
+so that users of Cassandra would have a simple yet powerful audit
+logging tool built into their database out of the box.
+
+## Why are Audit Logs Important?
+
+Audit logging database activity is one of the key components for making
+a database truly ready for the enterprise. Audit logging is generally
+useful but enterprises frequently use it for:
+
+1. Regulatory compliance with laws such as
[SOX](https://en.wikipedia.org/wiki/Sarbanes%E2%80%93Oxley_Act),
[PCI](https://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Security_Standard)
and [GDPR](https://en.wikipedia.org/wiki/General_Data_Protection_Regulation)
et al. These types of compliance are crucial for companies that are traded on
public stock exchanges, hold payment information such as credit cards, or
retain private user information.
+2. Security compliance. Companies often have strict rules for what data can
be accessed by which employees, both to protect the privacy of users but also
to limit the probability of a data breach.
+3. Debugging complex data corruption bugs such as those found in massively
distributed microservice architectures like Netflix's.
+
+## Why is Audit Logging Difficult?
+
+Implementing a simple logger in the request (inbound/outbound) path
+sounds easy, but the devil is in the details. In particular, the "fast
+path" of a database, where audit logging must operate, strives to do as
+little as humanly possible so that users get the fastest and most
+scalable database system possible. While implementing Cassandra audit
+logging, we had to ensure that the audit log infrastructure does not
+take up excessive CPU or IO resources from the actual database execution
+itself. However, one cannot simply optimize only for performance because
+that may compromise the guarantees of the audit logging.
+
+For example, if producing an audit record would block a thread, it
+should be dropped to maintain maximum performance. However, most
+compliance requirements prohibit dropping records. Therefore, the key to
+implementing audit logging correctly lies in allowing users to achieve
+both performance *and* reliability, or absent being able to achieve both
+allow users to make an explicit trade-off through configuration.
+
+---
+
+## Audit Logging Design Goals
+
+The design goal of the Audit log are broadly categorized into 3
+different areas:
+
+**Performance**: Considering the Audit Log injection points are
+live in the request path, performance is an important goal in every
+design decision.
+
+**Accuracy** : Accuracy is required by compliance and is thus a
+critical goal. Audit Logging must be able to answer crucial auditor
+questions like "Is every write request to the database being audited?".
+As such, accuracy cannot be compromised.
+
+**Usability & Extensibility**: The diverse Cassandra ecosystem
+demands that any frequently used feature must be easily usable and
+pluggable (e.g., Compaction, Compression, SeedProvider etc\...), so the
+Audit Log interface was designed with this context in mind from the
+start.
+
+## Implementation
+
+With these three design goals in mind, the
+[OpenHFT](https://github.com/OpenHFT) libraries were an
+obvious choice due to their reliability and high performance. Earlier in
+[CASSANDRA-13983](https://issues.apache.org/jira/browse/CASSANDRA-13983)
+the [chronical queue
+library](https://github.com/OpenHFT/Chronicle-Queue) of
+OpenHFT was introduced as a BinLog utility to the Apache Cassandra code
+base. The performance of Full Query Logging (FQL) was excellent, but it only
instrumented mutation and read query paths. It was missing a lot of critical
data such as when queries failed, where they came from, and which user issued
the query. The FQL was also single purpose: preferring to drop messages rather
than delay the process (which makes sense for FQL but not for Audit Logging).
Lastly, the FQL didnât allow for pluggability, which would make it harder to
adopt in the codebase for this feature.
+
+As shown in the architecture figure below, we were able to unify the FQL
feature with the AuditLog functionality through the AuditLogManager and
IAuditLogger abstractions. Using this architecture, we can support any output
format: logs, files, databases, etc. By default, the BinAuditLogger
implementation comes out of the box to maintain performance. Users can choose
the custom audit logger implementation by dropping the jar file on Cassandra
classpath and customizing with configuration options in
+[cassandra.yaml](https://github.com/apache/cassandra/blob/trunk/conf/cassandra.yaml#L1216-L1234)
+file.
+
+---
+
+## Architecture
+
[... 122 lines stripped ...]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
