Google Git
Sign in
apache / metron / 410993daf60dfe898a973fa8a9906ddbffd83208 / . / current-book / metron-deployment / packaging / ambari / index.html
blob: 897b10cf4ee6d8682d728150dd4b66fa511daa74 [file] [log] [blame]
<!DOCTYPE html>
<!--
| Generated by Apache Maven Doxia Site Renderer 1.8 from src/site/markdown/metron-deployment/packaging/ambari/index.md at 2019-05-14
| Rendered using Apache Maven Fluido Skin 1.7
-->
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
<meta charset="UTF-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<meta name="Date-Revision-yyyymmdd" content="20190514" />
<meta http-equiv="Content-Language" content="en" />
<title>Metron &#x2013; Ambari Management Pack Development</title>
<link rel="stylesheet" href="../../../css/apache-maven-fluido-1.7.min.css" />
<link rel="stylesheet" href="../../../css/site.css" />
<link rel="stylesheet" href="../../../css/print.css" media="print" />
<script type="text/javascript" src="../../../js/apache-maven-fluido-1.7.min.js"></script>
<script type="text/javascript">
$( document ).ready( function() { $( '.carousel' ).carousel( { interval: 3500 } ) } );
</script>
</head>
<body class="topBarDisabled">
<div class="container-fluid">
<div id="banner">
<div class="pull-left"><a href="http://metron.apache.org/" id="bannerLeft"><img src="../../../images/metron-logo.png" alt="Apache Metron" width="148px" height="48px"/></a></div>
<div class="pull-right"></div>
<div class="clear"><hr/></div>
</div>
<div id="breadcrumbs">
<ul class="breadcrumb">
<li class=""><a href="http://www.apache.org" class="externalLink" title="Apache">Apache</a><span class="divider">/</span></li>
<li class=""><a href="http://metron.apache.org/" class="externalLink" title="Metron">Metron</a><span class="divider">/</span></li>
<li class=""><a href="../../../index.html" title="Documentation">Documentation</a><span class="divider">/</span></li>
<li class="active ">Ambari Management Pack Development</li>
<li id="publishDate" class="pull-right"><span class="divider">|</span> Last Published: 2019-05-14</li>
<li id="projectVersion" class="pull-right">Version: 0.7.1</li>
</ul>
</div>
<div class="row-fluid">
<div id="leftColumn" class="span2">
<div class="well sidebar-nav">
<ul class="nav nav-list">
<li class="nav-header">User Documentation</li>
<li><a href="../../../index.html" title="Metron"><span class="icon-chevron-down"></span>Metron</a>
<ul class="nav nav-list">
<li><a href="../../../CONTRIBUTING.html" title="CONTRIBUTING"><span class="none"></span>CONTRIBUTING</a></li>
<li><a href="../../../Upgrading.html" title="Upgrading"><span class="none"></span>Upgrading</a></li>
<li><a href="../../../metron-analytics/index.html" title="Analytics"><span class="icon-chevron-right"></span>Analytics</a></li>
<li><a href="../../../metron-contrib/metron-docker/index.html" title="Docker"><span class="none"></span>Docker</a></li>
<li><a href="../../../metron-contrib/metron-performance/index.html" title="Performance"><span class="none"></span>Performance</a></li>
<li><a href="../../../metron-deployment/index.html" title="Deployment"><span class="icon-chevron-down"></span>Deployment</a>
<ul class="nav nav-list">
<li><a href="../../../metron-deployment/Kerberos-ambari-setup.html" title="Kerberos-ambari-setup"><span class="none"></span>Kerberos-ambari-setup</a></li>
<li><a href="../../../metron-deployment/Kerberos-manual-setup.html" title="Kerberos-manual-setup"><span class="none"></span>Kerberos-manual-setup</a></li>
<li><a href="../../../metron-deployment/amazon-ec2/index.html" title="Amazon-ec2"><span class="none"></span>Amazon-ec2</a></li>
<li><a href="../../../metron-deployment/ansible/index.html" title="Ansible"><span class="icon-chevron-right"></span>Ansible</a></li>
<li><a href="../../../metron-deployment/development/index.html" title="Development"><span class="icon-chevron-right"></span>Development</a></li>
<li><a href="../../../metron-deployment/other-examples/index.html" title="Other-examples"><span class="icon-chevron-right"></span>Other-examples</a></li>
<li class="active"><a href="#"><span class="icon-chevron-down"></span>Ambari</a>
<ul class="nav nav-list">
<li><a href="../../../metron-deployment/packaging/ambari/elasticsearch-mpack/index.html" title="Elasticsearch-mpack"><span class="none"></span>Elasticsearch-mpack</a></li>
<li><a href="../../../metron-deployment/packaging/ambari/metron-mpack/index.html" title="Mpack"><span class="none"></span>Mpack</a></li>
</ul>
</li>
<li><a href="../../../metron-deployment/packaging/docker/ansible-docker/index.html" title="Ansible-docker"><span class="none"></span>Ansible-docker</a></li>
<li><a href="../../../metron-deployment/packaging/docker/deb-docker/index.html" title="Deb-docker"><span class="none"></span>Deb-docker</a></li>
<li><a href="../../../metron-deployment/packaging/docker/rpm-docker/index.html" title="Rpm-docker"><span class="none"></span>Rpm-docker</a></li>
<li><a href="../../../metron-deployment/packaging/packer-build/index.html" title="Packer-build"><span class="none"></span>Packer-build</a></li>
</ul>
</li>
<li><a href="../../../metron-interface/index.html" title="Interface"><span class="icon-chevron-right"></span>Interface</a></li>
<li><a href="../../../metron-platform/index.html" title="Platform"><span class="icon-chevron-right"></span>Platform</a></li>
<li><a href="../../../metron-sensors/index.html" title="Sensors"><span class="icon-chevron-right"></span>Sensors</a></li>
<li><a href="../../../metron-stellar/stellar-3rd-party-example/index.html" title="Stellar-3rd-party-example"><span class="none"></span>Stellar-3rd-party-example</a></li>
<li><a href="../../../metron-stellar/stellar-common/index.html" title="Stellar-common"><span class="icon-chevron-right"></span>Stellar-common</a></li>
<li><a href="../../../metron-stellar/stellar-zeppelin/index.html" title="Stellar-zeppelin"><span class="none"></span>Stellar-zeppelin</a></li>
<li><a href="../../../use-cases/index.html" title="Use-cases"><span class="icon-chevron-right"></span>Use-cases</a></li>
</ul>
</li>
</ul>
<hr />
<div id="poweredBy">
<div class="clear"></div>
<div class="clear"></div>
<div class="clear"></div>
<div class="clear"></div>
<a href="http://maven.apache.org/" title="Built by Maven" class="poweredBy"><img class="builtBy" alt="Built by Maven" src="../../../images/logos/maven-feather.png" /></a>
</div>
</div>
</div>
<div id="bodyColumn" class="span10" >
<!--
Licensed to the Apache Software Foundation (ASF) under one
or more contributor license agreements. See the NOTICE file
distributed with this work for additional information
regarding copyright ownership. The ASF licenses this file
to you under the Apache License, Version 2.0 (the
"License"); you may not use this file except in compliance
with the License. You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
limitations under the License.
-->
<h1>Ambari Management Pack Development</h1>
<p><a name="Ambari_Management_Pack_Development"></a></p>
<div class="section">
<h2><a name="Table_of_Contents"></a>Table of Contents</h2>
<ul>
<li><a href="#Overview">Overview</a></li>
<li><a href="#Ambari_Zookeeper_Config_Lifecycle">Ambari Zookeeper Config Lifecycle</a></li>
<li><a href="#Adding_a_new_property">Adding a new property</a></li>
<li><a href="#How_to_identify_errors_in_MPack_changes">How to identify errors in MPack changes</a></li>
<li><a href="#Testing_changes_without_cycling_Vagrant_build">Testing changes without cycling Vagrant build</a></li>
<li><a href="#Configuration_involving_dependency_services">Configuration involving dependency services</a></li>
<li><a href="#Kerberos">Kerberos</a></li>
<li><a href="#Best_practices">Best practices</a></li>
<li><a href="#Upgrading_MPack_Services">Upgrading MPack Services</a></li>
</ul></div>
<div class="section">
<h2><a name="Overview"></a>Overview</h2>
<p>Typically, Ambari Management Pack development will be done in the Vagrant environments. These instructions are specific to Vagrant, but can be adapted for other environemnts (e.g. make sure to be on the correct nodes for server vs agent files)</p>
<p>There are two MPacks:</p>
<ul>
<li>Metron - contains artifacts for deploying the Metron service</li>
<li>Elasticsearch - contains artifacts for installing Elasticsearch and Kibana services</li>
</ul>
<p>There is an <tt>mpack.json</tt> file for each which describes what services the mpack will contain, versions, etc.</p>
<p>Alongside this are two directories, <tt>addon-services</tt> and <tt>common-services</tt>. Below the Metron MPack is described, but this also applies similarly to the Elasticsearch MPack.</p>
<p>The layout of <tt>/common-services/METRON/CURRENT</tt> is</p>
<ul>
<li><tt>/configuration</tt>
<ul>
<li>This contains a set of <tt>*-env.xml</tt> files, relevent to particular components or the service as a whole. These are where properties are defined.</li>
</ul>
</li>
<li><tt>/package</tt>
<ul>
<li><tt>/files</tt>
<ul>
<li>Contains files that get used as provided, in particular Elasticsearch templates.</li>
</ul>
</li>
<li><tt>/scripts</tt>
<ul>
<li>A set of Python scripts that interface with Ambari to manage setup and install</li>
<li><tt>/params</tt>
<ul>
<li>A set of Python scripts for managing parameters from the <tt>*-env.xml</tt> files</li>
</ul>
</li>
<li><tt>/templates</tt>
<ul>
<li>A set of Jinja template files which can be populated with properties</li>
</ul>
</li>
</ul>
</li>
</ul>
</li>
<li><tt>/quicklinks</tt>
<ul>
<li>Contains <tt>quicklinks.json</tt> to define the Ambari quicklinks that should be used in the UI</li>
</ul>
</li>
<li><tt>themes</tt>
<ul>
<li>Manages the Ambari UI themes blocks for organizing the configuration by relevant area.</li>
</ul>
</li>
<li><tt>kerberos.json</tt>
<ul>
<li>Defines the keytabs and other Kerberos configuration to be used when Kerberizing a cluster</li>
</ul>
</li>
<li><tt>metainfo.xml</tt>
<ul>
<li>Defines the METRON service, along with required packages, services, etc. If you need to have the MPack install a new package (e.g. RPM, DEB), add it here.</li>
</ul>
</li>
<li><tt>service_advisor.py</tt>
<ul>
<li>Handles component layout and validation, along with handling some configurations for other services or that needs configs from other services.</li>
</ul>
</li>
</ul>
<p>The layout of <tt>/addon-services/METRON/CURRENT</tt> is</p>
<ul>
<li><tt>/repos</tt>
<ul>
<li>Contains <tt>repoinfo.xml</tt> that defines repositories to install packages from</li>
</ul>
</li>
<li><tt>metainfo.xml</tt>
<ul>
<li>Limited info version of <tt>/common-services/METRON/CURRENT/metainfo.xml</tt></li>
</ul>
</li>
<li><tt>role_command_order.json</tt>
<ul>
<li>Defines the order of service startup and other actions relative to each other.</li>
</ul>
</li>
</ul></div>
<div class="section">
<h2><a name="Ambari_Zookeeper_Config_Lifecycle"></a>Ambari Zookeeper Config Lifecycle</h2>
<p>The source of truth for Metron configuration resides in Zookeeper as a series of JSON documents. There are actually multiple locations that you can populate the Zookeeper configs from:</p>
<ul>
<li>$METRON_HOME/config/zookeeper</li>
<li>Stellar REPL</li>
<li>Management UI</li>
<li>Ambari</li>
</ul>
<p>Any change that works with Metron configuration stored in Zookeeper should always pull the latest config from Zookeeper first before making any changes and publishing them back up to avoid potentially overwriting the latest configs with stale data. The lifecycle for configuration management with Ambari is as follows:</p>
<ul>
<li>First start/install for parsers, enrichment, indexing, or the profiler
<ul>
<li>Perform a PUSH from local disk to Zookeeper</li>
</ul>
</li>
<li>All component start/restart operations for parsers, enrichment, indexing, or the profiler
<ul>
<li>Perform a JSON patch (RFC 6902) on the configs in Zookeeper and push the patched, pretty formatted config up to Zookeeper. Patching is currently applicable to to global.json only.</li>
<li>Pull all configs to the local file system.</li>
</ul>
</li>
</ul>
<p>The patching mechanism we introduced to Ambari for managing the global config is by default additive in nature, though it will also overwrite any existing values with the latest values from Ambari. This means that you can add any properties to the global config outside of Ambari you like, provided you are not modifying values explicitly managed by Ambari. This is important because you will not get any errors when modifying the configuration outside of Ambari. Instead, if you modified es.ip and changed global.json outsided Ambari, you would not see this change in Ambari. Meanwhile, the indexing topology would be using the new value stored in Zookeeper. Remember, Zookeeper is the source of truth. If you were to restart a Metron topology component via Ambari, that es.ip property would now be set back to the value stored in Ambari. So in summary, if it&#x2019;s managed by Ambari, only change that value via Ambari. If it&#x2019;s not, then feel free to use whatever mechanism you like, just be sure to pull the latest config from Zookeeper before making any changes. We make no effort to handle race conditions. It&#x2019;s last commit wins. Below are the global config properties managed by Ambari:</p>
<ul>
<li>es.clustername</li>
<li>es.ip</li>
<li>es.date.format</li>
<li>parser.error.topic</li>
<li>update.hbase.table</li>
<li>update.hbase.cf</li>
<li>profiler.client.period.duration</li>
<li>profiler.client.period.duration.units</li>
</ul></div>
<div class="section">
<h2><a name="Adding_a_new_property"></a>Adding a new property</h2>
<ol style="list-style-type: decimal">
<li>Add the property to the appropriate <tt>*-env.xml</tt> file found in <tt>METRON.CURRENT/configuration</tt>.
<div>
<div>
<pre class="source">&lt;property&gt;
&lt;name&gt;new_property&lt;/name&gt;
&lt;description&gt;New Property description&lt;/description&gt;
&lt;value&gt;Default Value&lt;/value&gt;
&lt;display-name&gt;New Property Pretty Name&lt;/display-name&gt;
&lt;/property&gt;
</pre></div></div>
</li>
</ol>
<p>The appropriate <tt>*-env.xml</tt> file should be selected based on which component depends on the property. This allows Ambari to accurately restart only the affected components when the property is changed. If a property is in <tt>metron-env.xml</tt>, Ambari will prompt you to restart all Metron components.</p>
<ol style="list-style-type: decimal">
<li>
<p>Add the property to the <tt>metron_theme.json</tt> file found in <tt>METRON.CURRENT/themes</tt> if the property was added to a component-specific <tt>*-env.xml</tt> file (<tt>metron-parsers-env.xml</tt> for example) and not <tt>metron-env.xml</tt>. This is necessary for the property to be displayed in the correct tab of the Metron Configs section in the Ambari UI. Using other properties as a guide, add the property to <tt>/configuration/placement/configs</tt> for proper placement and also to <tt>/configuration/widgets</tt> for a specific widget type.</p>
</li>
<li>
<p>Reference the property in <tt>METRON.CURRENT/package/scriptes/params/params_linux.py</tt>, unless it will be used in Ambari&#x2019;s status command. It will be stored in a variable. The name doesn&#x2019;t have to match, but it&#x2019;s preferred that it does. Make sure to use replace <tt>metron-env</tt> the correct <tt>*-env</tt> file, as noted above.</p>
<div>
<div>
<pre class="source">new_property = config['configurations']['metron-env']['new_property']
</pre></div></div>
<p>If this property will be used in the status command, instead make this change in <tt>METRON.CURRENT/package/scriptes/params/status_params.py</tt>. Afterwards, in <tt>params_linux.py</tt>, reference the new property:</p>
<div>
<div>
<pre class="source">new_property = status_params.new_property
</pre></div></div>
<p>This behavior is because Ambari doesn&#x2019;t send all parameters to the status, so it needs to be explicitly provided. Also note that status_params.py parameters are not automatically pulled into the params_linux.py namespace, so we explicitly choose the variables to include. See <a class="externalLink" href="https://docs.python.org/2/howto/doanddont.html#at-module-level">https://docs.python.org/2/howto/doanddont.html#at-module-level</a> for more info.</p>
</li>
<li>
<p>Ambari master services can then import the params:</p>
<div>
<div>
<pre class="source">from params import params
env.set_params(params)
</pre></div></div>
</li>
<li>
<p>The <tt>*_commands.py</tt> files receive the params as an input from the master services. Once this is done, they can be accessed via the variable we set above:</p>
<div>
<div>
<pre class="source">self.__params.new_property
</pre></div></div>
</li>
</ol>
<div class="section">
<h3><a name="Env_file_property_walkthrough"></a>Env file property walkthrough</h3>
<p>To illustrate how property files are carried through to the scripts for our services, we&#x2019;ll run through an existing property, <tt>metron_apps_hdfs_dir</tt>.</p>
<div class="section">
<h4><a name="Defining_the_property"></a>Defining the property</h4>
<p>First the property appears in the appropriate <tt>*-env.xml</tt>, in this case <tt>METRON.CURRENT/configuration/metron-env.xml</tt>.</p>
<div>
<div>
<pre class="source">&lt;property&gt;
&lt;name&gt;metron_apps_hdfs_dir&lt;/name&gt;
&lt;value&gt;/apps/metron&lt;/value&gt;
&lt;description&gt;Metron apps HDFS dir&lt;/description&gt;
&lt;display-name&gt;Metron apps HDFS dir&lt;/display-name&gt;
&lt;/property&gt;
</pre></div></div>
<p>This defines several things</p>
<ol style="list-style-type: decimal">
<li>The name of the property we&#x2019;ll be referencing it by in our code.</li>
<li>The default value of the property.</li>
<li>The description of the property for the Ambari UI.</li>
<li>The pretty name that will be shown in Ambari for the property.</li>
</ol></div>
<div class="section">
<h4><a name="Making_the_property_available_to_scripts"></a>Making the property available to scripts</h4>
<p>Second, we set up the property to be available to the code. This happens in <tt>METRON.CURRENT/packages/scripts/params/params_linux.py</tt>. Just add the following line:</p>
<div>
<div>
<pre class="source">metron_apps_hdfs_dir = config['configurations']['metron-env']['metron_apps_hdfs_dir']
</pre></div></div>
<p>There is one catch to this. If we wanted this to be available to Ambari&#x2019;s status command, we&#x2019;d need to put that line in <tt>METRON.CURRENT/packages/scripts/params/status_params.py</tt> and reference it in <tt>params_linux.py</tt> like so:</p>
<div>
<div>
<pre class="source">metron_apps_hdfs_dir = status_params.metron_apps_hdfs_dir
</pre></div></div>
<p>This behavior is because Ambari doesn&#x2019;t send all parameters to the status, so it needs to be explicitly provided.</p>
<p>In our case, we don&#x2019;t use this parameter directly (but it could be if we wanted to use it exactly). We actually append to it before use in <tt>params_linux.py</tt>:</p>
<div>
<div>
<pre class="source">from resource_management.libraries.functions import format
# ...
hdfs_grok_patterns_dir = format(&quot;{metron_apps_hdfs_dir}/patterns&quot;)
</pre></div></div>
<p>The <tt>format</tt> function is a special Ambari function that will let you create a string with properties in curly braces replaced by their values. In this case, <tt>hdfs_grok_patterns_dir</tt> will be <tt>/apps/metron/patterns</tt> and will be what we now follow in this example.</p>
<p>Note: There are instances where we deviate a bit from this pattern and use format(format(&#x201c;{{some_prop}}&#x201d;)). This is not a mistake. Ambari does not natively support nested properties, and this was a workaround that accomplished being able to initialize values from env.xml files and have them also available to users as Ambari properties later. Here&#x2019;s an example from params_linux.py:</p>
<div>
<div>
<pre class="source">metron_apps_indexed_hdfs_dir = format(format(config['configurations']['metron-indexing-env']['metron_apps_indexed_hdfs_dir']))
</pre></div></div>
<p>and the relavant properties in metron-env.xml and metron-indexing-env.xml</p>
<p>metron-env.xml</p>
<div>
<div>
<pre class="source">&lt;property&gt;
&lt;name&gt;metron_apps_hdfs_dir&lt;/name&gt;
&lt;value&gt;/apps/metron&lt;/value&gt;
&lt;description&gt;Metron apps HDFS dir&lt;/description&gt;
&lt;display-name&gt;Metron apps HDFS dir&lt;/display-name&gt;
&lt;/property&gt;
</pre></div></div>
<p>metron-indexing-env.xml</p>
<div>
<div>
<pre class="source">&lt;property&gt;
&lt;name&gt;metron_apps_indexed_hdfs_dir&lt;/name&gt;
&lt;value&gt;{{metron_apps_hdfs_dir}}/indexing/indexed&lt;/value&gt;
&lt;description&gt;Indexing bolts will write to this HDFS directory&lt;/description&gt;
&lt;display-name&gt;Metron apps indexed HDFS dir&lt;/display-name&gt;
&lt;/property&gt;
</pre></div></div>
</div>
<div class="section">
<h4><a name="Importing_the_parameters_into_scripts"></a>Importing the parameters into scripts</h4>
<p><tt>hdfs_grok_patterns_dir</tt> is used in <tt>METRON.CURRENT/package/scripts/parser_commands.py</tt>, but before we can reference it, we&#x2019;ll need the params available to <tt>parser_commands.py</tt></p>
<p>To make them available, we take them in as part of the <tt>__init__</tt></p>
<div>
<div>
<pre class="source">def __init__(self, params):
if params is None:
raise ValueError(&quot;params argument is required for initialization&quot;)
self.__params = params
# Other initialization
</pre></div></div>
<p>This init is called from various Ambari service methods in <tt>METRON.CURRENT/package/scripts/parser_master.py</tt>, e.g.:</p>
<div>
<div>
<pre class="source">def stop(self, env, upgrade_type=None):
from params import params
env.set_params(params)
commands = ParserCommands(params)
commands.stop_parser_topologies()
</pre></div></div>
<p>Once the params are available to <tt>parser_commands.py</tt>, <tt>hdfs_grok_patterns_dir</tt> is by referencing <tt>self.__params.hdfs_grok_patterns_dir)</tt> In our case, this will create and populate <tt>/apps/metron/patterns</tt> on HDFS, owned by the metron user with appropriate permissions. It&#x2019;ll also log out what it&#x2019;s doing, which is important for being able to debug.</p>
<div>
<div>
<pre class="source">def init_parsers(self):
Logger.info(
&quot;Copying grok patterns from local directory '{0}' to HDFS '{1}'&quot;.format(self.__params.local_grok_patterns_dir,
self.__params.hdfs_grok_patterns_dir))
self.__params.HdfsResource(self.__params.hdfs_grok_patterns_dir,
type=&quot;directory&quot;,
action=&quot;create_on_execute&quot;,
owner=self.__params.metron_user,
mode=0755,
source=self.__params.local_grok_patterns_dir)
Logger.info(&quot;Done initializing parser configuration&quot;)
</pre></div></div>
</div></div>
<div class="section">
<h3><a name="Jinja_Templates_and_properties"></a>Jinja Templates and properties</h3>
<p>Jinja templates allow for the ability to have most of a file defined, but allow variables to be filled in from the properties defined in our <tt>*-env.xml</tt> files.</p>
<p>A variable to be replaced will take the form <tt>{{property_name}}</tt></p>
<p>The properties are made available like any other property, and then the template itself is referenced in Python scripts in the <tt>METRON.CURRENT/package/scripts/</tt> directory.</p></div>
<div class="section">
<h3><a name="Jinja_template_property_walkthrough"></a>Jinja template property walkthrough</h3>
<p>To illustrate the use of a property in a Jinja template, let&#x2019;s take an example of an existing property and walk through exactly how it&#x2019;s implemented.</p>
<p>A straightforward example is <tt>metron_log_dir</tt> in <tt>METRON.CURRENT/configuration/metron-env.xml</tt></p>
<div class="section">
<h4><a name="Defining_the_property"></a>Defining the property</h4>
<p>First, we need the property in the configuration file:</p>
<div>
<div>
<pre class="source">&lt;property&gt;
&lt;name&gt;metron_log_dir&lt;/name&gt;
&lt;value&gt;/var/log/metron&lt;/value&gt;
&lt;description&gt;Log directory for metron&lt;/description&gt;
&lt;display-name&gt;Metron log dir&lt;/display-name&gt;
&lt;/property&gt;
</pre></div></div>
</div>
<div class="section">
<h4><a name="Making_the_property_available_to_templates"></a>Making the property available to templates</h4>
<p>This property isn&#x2019;t used in Ambari&#x2019;s status check, so it was directly added to <tt>METRON.CURRENT/package/scripts/params/params_linux.py</tt>. All we do is add the variable, and reference Ambari&#x2019;s config object appropriately, making sure to reference <tt>metron-env</tt> as the file where the property is located.</p>
<div>
<div>
<pre class="source">metron_log_dir = config['configurations']['metron-env']['metron_log_dir']
</pre></div></div>
<p>The property is referenced in <tt>metron.j2</tt>.</p>
<div>
<div>
<pre class="source">METRON_LOG_DIR=&quot;{{metron_log_dir}}&quot;
</pre></div></div>
</div>
<div class="section">
<h4><a name="Using_the_template_in_scripts"></a>Using the template in scripts</h4>
<p>For that property to actually be used, it is referenced in <tt>rest_master.py</tt>:</p>
<div>
<div>
<pre class="source">from resource_management.core.resources.system import File
from resource_management.core.source import Template
def configure(self, env, upgrade_type=None, config_dir=None):
# Do stuff
env.set_params(params)
File(format(&quot;/etc/sysconfig/metron&quot;),
content=Template(&quot;metron.j2&quot;)
)
# Do stuff
</pre></div></div>
<p>This will create a file on the Ambari agent machine&#x2019;s file system, <tt>/etc/sysconfig/metron</tt>, with the content of <tt>metron.j2</tt>, after replacing <tt>{{metron_log_dir}}</tt> with the value of the property (<tt>/var/log/metron</tt>)</p>
<div>
<div>
<pre class="source">...
METRON_LOG_DIR=&quot;/var/log/metron&quot;
...
</pre></div></div>
</div></div>
<div class="section">
<h3><a name="Defining_presentation_in_the_Ambari_UI"></a>Defining presentation in the Ambari UI</h3>
<p>Where and how a property is displayed can be controlled in the <tt>METRON.CURRENT/themes/metron_theme.json</tt> file. Consider the <tt>enrichment_workers</tt> property that is defined in a component specific <tt>*-env.xml</tt> file, in this case <tt>METRON.CURRENT/configuration/metron-enrichment-env.xml</tt>. The property appears in <tt>METRON.CURRENT/themes/metron_theme.json</tt> in two different sections:</p>
<div>
<div>
<pre class="source">{
&quot;configuration&quot;: {
&quot;layouts&quot;: [...],
&quot;placement&quot;: {
&quot;configs&quot;: [
{
&quot;config&quot;: &quot;metron-enrichment-env/enrichment_workers&quot;,
&quot;subsection-name&quot;: &quot;subsection-enrichment-storm&quot;
},
...
]
},
&quot;widgets&quot;: [
{
&quot;config&quot;: &quot;metron-enrichment-env/enrichment_workers&quot;,
&quot;widget&quot;: {
&quot;type&quot;: &quot;text-field&quot;
}
}
]
}
}
</pre></div></div>
<p>The first setting places the property in the &#x201c;Storm&#x201d; section of the &#x201c;Enrichment&#x201d; tab in Ambari. Sections are defined in <tt>metron_theme.json</tt> under <tt>/configuration/layouts</tt>.</p>
<p>The second setting defines a widget type of <tt>text-field</tt>. See the <a class="externalLink" href="https://cwiki.apache.org/confluence/display/AMBARI/Enhanced+Configs">Ambari Wiki</a> for more detail on widget types.</p>
<p>If a property is defined in <tt>metron-env.xml</tt>, it is not necessary to add it to the <tt>metron_theme.json</tt> file. By default the property will be located under the &#x201c;Advanced&#x201d; tab in the &#x201c;Advanced metron-env&#x201d; section.</p></div></div>
<div class="section">
<h2><a name="How_to_identify_errors_in_MPack_changes"></a>How to identify errors in MPack changes</h2>
<p>Typically, any errors are thrown at one of two times:</p>
<ol style="list-style-type: decimal">
<li>Attempting to install Metron as a whole. These are typically service level definition errors, not property errors. Logs will often be found in <tt>/var/log/ambari-server/ambari-server.log</tt>. Often the log will indicate it was unable to load a particular service or subservice with some more detail.</li>
<li>Running the actual functionality. These typically tend to cause errors in the UI at runtime. Logs are usually found in <tt>/var/log/ambari-agent/ambari-agent.log</tt>.</li>
</ol>
<p>Unfortunately, because errors tend to occur at runtime, it&#x2019;s often necessary to add things like logging statements, or even just throw errors to print out in the Ambari UI.</p>
<p>The primary solution to these is to look in the logs for exceptions, see what&#x2019;s going wrong (Property doesn&#x2019;t exist? Malformed file couldn&#x2019;t be loaded?), and adjust appropriately.</p></div>
<div class="section">
<h2><a name="Testing_changes_without_cycling_Vagrant_build"></a>Testing changes without cycling Vagrant build</h2>
<p>There are techniques we can use to avoid spinning down and spinning back up Vagrant.</p>
<div class="section">
<h3><a name="Directly_modifying_files_in_Ambari"></a>Directly modifying files in Ambari</h3>
<p>This assumes the installation went through, and we&#x2019;re just working on getting our particular feature / adjustment to work properly. This is specific to a single node environment like Vagrant, because of other factors (such as consistency across agents). Multinode environments should generally be used when the feature is already stable and updating is preferably a reinstall of the management pack and the Metron service in general.</p>
<p>Ambari stores the Python files from the service in a couple places. We&#x2019;ll want to update the files, then have Ambari pick up the updated versions and use them as the new basis. A reinstall of Metron is unnecessary for this type of testing.</p>
<p>Specifically, the server files live in</p>
<div>
<div>
<pre class="source">/var/lib/ambari-server/resources/mpacks/metron-ambari.mpack-0.4.0.0/common-services
/var/lib/ambari-server/resources/mpacks/elasticsearch-ambari.mpack-0.4.0.0/common-services
/var/lib/ambari-agent/cache/common-services
</pre></div></div>
<p>e.g. enrichment_commands.py can be found in:</p>
<div>
<div>
<pre class="source">/var/lib/ambari-server/resources/mpacks/metron-ambari.mpack-0.4.0.0/common-services/METRON/0.4.0/package/scripts/enrichment_commands.py
/var/lib/ambari-agent/cache/common-services/METRON/0.4.0/package/scripts/enrichment_commands.py
</pre></div></div>
<p>A <tt>find</tt> command can also be useful in quickly locating the exact location of a file, e.g.</p>
<div>
<div>
<pre class="source">[root@node1 ~]# find /var/lib/ -name enrichment_commands.py
/var/lib/ambari-server/resources/mpacks/metron-ambari.mpack-0.4.0.0/common-services/METRON/0.4.0/package/scripts/enrichment_commands.py
/var/lib/ambari-agent/cache/common-services/METRON/0.4.0/package/scripts/enrichment_commands.py
</pre></div></div>
<p>The steps to update, for anything affecting an Ambari agent node, e.g. setup scripts during the service install process, are:</p>
<ol style="list-style-type: decimal">
<li>Stop Metron through Ambari. If the property in question is used by the topologies, we&#x2019;ll want them stopped, so they can be restarted with the new property. This can sometimes be skipped if the change doesn&#x2019;t affect the topologies themselves, but is a case by case choice.</li>
<li>Edit the file(s) with your changes. The ambari-agent file must be edited, but generally better to update both for consistency.</li>
<li>Restart the Ambari Agent to get the cache to pick up the modified file
<div>
<div>
<pre class="source">ambari-agent restart
</pre></div></div>
</li>
<li>Start Metron through Ambari if it was stopped.</li>
</ol></div>
<div class="section">
<h3><a name="Reinstalling_the_mpack"></a>Reinstalling the mpack</h3>
<p>After we&#x2019;ve modified files in Ambari and the mpack is working, it is a good idea to reinstall it. Fortunately this can be done without rebuilding the Vagrant environment by following these steps:</p>
<ol style="list-style-type: decimal">
<li>Stop Metron through Ambari and remove the Metron service</li>
<li>Rebuild the mpack on your local machine and deploy it to Vagrant, ensuring that all changes made directly to files in Ambari were also made in your local environment
<div>
<div>
<pre class="source">cd metron-deployment
mvn clean package
scp packaging/ambari/metron-mpack/target/metron_mpack-0.4.0.0.tar.gz root@node1:~
</pre></div></div>
</li>
<li>Log in to Vagrant, deploy the mpack and restart Ambari
<div>
<div>
<pre class="source">ssh root@node1
ambari-server install-mpack --mpack=metron_mpack-0.4.0.0.tar.gz --verbose --force
ambari-server restart
</pre></div></div>
</li>
<li>Install the mpack through Ambari as you normally would</li>
<li>
<p>The same steps can be followed for Elasticsearch and Kibana by similary deploying the ES MPack located in elasticsearch-mpack/target.</p>
</li>
</ol></div></div>
<div class="section">
<h2><a name="Configuration_involving_dependency_services"></a>Configuration involving dependency services</h2>
<p>Metron can define expectations on other services, e.g. Storm&#x2019;s <tt>topology.classpath</tt> should be <tt>/etc/hbase/conf:/etc/hadoop/conf</tt>. This happens in <tt>METRON.CURRENT/service_advisor.py</tt>.</p>
<p>The value is defined in a map in <tt>getSTORMSiteDesiredValues(self, is_secured)</tt>. This map is used by <tt>validateSTORMSiteConfigurations</tt> to ensure that the value used by the component is what we need it to be. Generally, only the map should need to be modified.</p>
<p>Properties from the other services can also be used and examined. We use this to build the appropriate URL for Storm, because it differs based on Kerberos security. For example, to retrieve from another service, access the configurations array, retrieve the appropriate config file, retrieve the properties, and finally the desired property.</p>
<div>
<div>
<pre class="source">stormUIServerPort = services[&quot;configurations&quot;][&quot;storm-site&quot;][&quot;properties&quot;][&quot;ui.port&quot;]
</pre></div></div>
<p>The security of the cluster can be checked with</p>
<div>
<div>
<pre class="source">is_secured = self.isSecurityEnabled(services)
</pre></div></div>
<p>Note that the configuration expectations will be properly enforced if the cluster is upgraded (e.g. the Storm URL is properly updated) and it does not need to occur manually.</p></div>
<div class="section">
<h2><a name="Kerberos"></a>Kerberos</h2>
<p>Any scripts interacting with underlying secured tech needs to have <tt>kinit</tt> run as needed. This includes anything interacting with HDFS, HBase, Kafka, Storm, etc. This <tt>kinit</tt> should be run in a conditional statement, to avoid breaking non-Kerberized clusters.</p>
<p>Ambari can run <tt>kinit</tt>, as a given user with the appropriate keytab like so:</p>
<div>
<div>
<pre class="source">if self.__params.security_enabled:
metron_security.kinit(self.__params.kinit_path_local,
self.__params.metron_keytab_path,
self.__params.metron_principal_name,
execute_user=self.__params.metron_user)
</pre></div></div>
<p>The <tt>security_enabled</tt> param is already made available, along with appropriate keytabs for metron, hdfs, kafka, and hbase users.</p></div>
<div class="section">
<h2><a name="Best_practices"></a>Best practices</h2>
<ul>
<li>
<p>Write scripts to be idempotent. The pattern currently used is to write a file out when a task is finished, e.g. setting up ACLs or tables. For example, when indexing is configured, a file is written out and checked based on a property.</p>
<div>
<div>
<pre class="source">def set_configured(self):
File(self.__params.indexing_configured_flag_file,
content=&quot;&quot;,
owner=self.__params.metron_user,
mode=0755)
</pre></div></div>
<p>This is checked in the indexing master</p>
<div>
<div>
<pre class="source">if not commands.is_configured():
commands.init_kafka_topics()
commands.init_hdfs_dir()
commands.set_configured()
</pre></div></div>
</li>
<li>
<p>Ensure ACLs are properly managed. This includes Kafka and HBase. Often this involves a config file written out as above because this isn&#x2019;t idempotent!</p>
<ul>
<li>Make sure to <tt>kinit</tt> as the correct user for setting up ACLs in a secured cluster. This is usually kafka for Kafka and hbase for HBase.</li>
<li>See <tt>set_hbase_acls</tt> in <tt>METRON.CURRENT/package/scripts/enrichment_commands.py</tt> for an HBase example</li>
<li>See <tt>init_kafka_acls</tt> in <tt>METRON.CURRENT/package/scripts/enrichment_commands.py</tt> and <tt>METRON.CURRENT/package/scripts/metron_service.py</tt> for an Kafka example</li>
</ul>
</li>
</ul></div>
<div class="section">
<h2><a name="Upgrading_MPack_Services"></a>Upgrading MPack Services</h2>
<p>Apache Metron currently provides one service as part of its Metron MPack</p>
<ul>
<li>Metron</li>
</ul>
<p>Apache Metron currently provides two services as part of its Elasticsearch MPack</p>
<ul>
<li>Elasticsearch</li>
<li>Kibana</li>
</ul>
<p>There is currently no mechanism provided for multi-version or backwards compatibility. If you upgrade a service, e.g. Elasticsearch 2.x to 5.x, that is the only version that will be supported by Ambari via MPack.</p>
<p>The main steps for upgrading a service are split into add-on and common services for each service within the MPack as follows:</p>
<ul>
<li>Update the common services
<ul>
<li>Change the service directory to use the new product version number</li>
<li>Update metainfo.xml</li>
</ul>
</li>
<li>Update the add-on services
<ul>
<li>Change the service directory to use the new product version number</li>
<li>Update repoinfo.xml</li>
<li>Update metainfo.xml</li>
</ul>
</li>
<li>Update mpack.json</li>
</ul>
<div class="section">
<h3><a name="Update_Elasticsearch"></a>Update Elasticsearch</h3>
<div class="section">
<h4><a name="Update_Common_Services"></a>Update Common Services</h4>
<ol style="list-style-type: decimal">
<li>
<p>Change service directory names for Elasticsearch to the new desired version</p>
<div>
<div>
<pre class="source">metron/metron-deployment/packaging/ambari/metron-mpack/src/main/resources/common-services/ELASTICSEARCH/${YOUR_VERSION_NUMBER_HERE}
</pre></div></div>
<p>e.g.</p>
<div>
<div>
<pre class="source">metron/metron-deployment/packaging/ambari/metron-mpack/src/main/resources/common-services/ELASTICSEARCH/5.6.14
</pre></div></div>
</li>
<li>
<p>Update metainfo.xml</p>
<p>Change the version number and package name in <tt>metron/metron-deployment/packaging/ambari/metron-mpack/src/main/resources/common-services/ELASTICSEARCH/${YOUR_VERSION_NUMBER_HERE}/metainfo.xml</tt>, e.g.</p>
<div>
<div>
<pre class="source">&lt;version&gt;5.6.14&lt;/version&gt;
...
&lt;osSpecifics&gt;
&lt;osSpecific&gt;
&lt;osFamily&gt;any&lt;/osFamily&gt;
&lt;packages&gt;
&lt;package&gt;
&lt;name&gt;elasticsearch-5.6.14&lt;/name&gt;
&lt;/package&gt;
&lt;/packages&gt;
&lt;/osSpecific&gt;
&lt;/osSpecifics&gt;
</pre></div></div>
</li>
</ol></div>
<div class="section">
<h4><a name="Update_Add-on_Services"></a>Update Add-on Services</h4>
<ol style="list-style-type: decimal">
<li>
<p>Change service directory names for Elasticsearch to the new desired version</p>
<div>
<div>
<pre class="source">metron/metron-deployment/packaging/ambari/metron-mpack/src/main/resources/addon-services/ELASTICSEARCH/${YOUR_VERSION_NUMBER_HERE}
</pre></div></div>
<p>e.g.</p>
<div>
<div>
<pre class="source">metron/metron-deployment/packaging/ambari/metron-mpack/src/main/resources/addon-services/ELASTICSEARCH/5.6.14
</pre></div></div>
</li>
<li>
<p>Update repoinfo.xml</p>
<p>See <a class="externalLink" href="https://www.elastic.co/guide/en/elasticsearch/reference/current/rpm.html">https://www.elastic.co/guide/en/elasticsearch/reference/current/rpm.html</a> for the latest info.</p>
<p>Modify the baseurl and repoid in <tt>metron/metron-deployment/packaging/ambari/metron-mpack/src/main/resources/addon-services/ELASTICSEARCH/${YOUR_VERSION_NUMBER_HERE}/repos/repoinfo.xml</tt>, e.g.</p>
<div>
<div>
<pre class="source">&lt;baseurl&gt;https://artifacts.elastic.co/packages/5.x/yum&lt;/baseurl&gt;
&lt;repoid&gt;elasticsearch-5.x&lt;/repoid&gt;
&lt;reponame&gt;ELASTICSEARCH&lt;/reponame&gt;
</pre></div></div>
</li>
<li>
<p>Update metainfo.xml</p>
<p>Change the version number in <tt>metron/metron-deployment/packaging/ambari/metron-mpack/src/main/resources/addon-services/ELASTICSEARCH/${YOUR_VERSION_NUMBER_HERE}/metainfo.xml</tt>. Also make sure to update the &#x201c;extends&#x201d; version to point to the updated common-services version, e.g.</p>
<div>
<div>
<pre class="source">&lt;name&gt;ELASTICSEARCH&lt;/name&gt;
&lt;version&gt;5.6.14&lt;/version&gt;
&lt;extends&gt;common-services/ELASTICSEARCH/5.6.14&lt;/extends&gt;
</pre></div></div>
</li>
</ol></div>
<div class="section">
<h4><a name="Update_mpack.json"></a>Update mpack.json</h4>
<ol style="list-style-type: decimal">
<li>Update the corresponding service_version in the service_versions_map, e.g.
<div>
<div>
<pre class="source">...
&quot;service_versions_map&quot;: [
{
&quot;service_name&quot; : &quot;ELASTICSEARCH&quot;,
&quot;service_version&quot; : &quot;5.6.14&quot;,
&quot;applicable_stacks&quot; : [
...
]
},
...
]
...
</pre></div></div>
</li>
</ol></div></div>
<div class="section">
<h3><a name="Kibana"></a>Kibana</h3>
<p><b>Note:</b> Curator is included with the Kibana service</p>
<div class="section">
<h4><a name="Update_Common_Services"></a>Update Common Services</h4>
<ol style="list-style-type: decimal">
<li>
<p>Change service directory names for Kibana to the new desired version</p>
<div>
<div>
<pre class="source">metron/metron-deployment/packaging/ambari/metron-mpack/src/main/resources/common-services/KIBANA/${YOUR_VERSION_NUMBER_HERE}
</pre></div></div>
<p>e.g.</p>
<div>
<div>
<pre class="source">metron/metron-deployment/packaging/ambari/metron-mpack/src/main/resources/common-services/KIBANA/5.6.14
</pre></div></div>
</li>
<li>
<p>Update metainfo.xml</p>
<p>Change the version number and package name in <tt>metron/metron-deployment/packaging/ambari/metron-mpack/src/main/resources/common-services/KIBANA/${YOUR_VERSION_NUMBER_HERE}/metainfo.xml</tt>, e.g.</p>
<div>
<div>
<pre class="source">&lt;version&gt;5.6.14&lt;/version&gt;
...
&lt;packages&gt;
...
&lt;package&gt;
&lt;name&gt;kibana-5.6.14&lt;/name&gt;
&lt;/package&gt;
&lt;/packages&gt;
</pre></div></div>
</li>
</ol></div>
<div class="section">
<h4><a name="Update_Add-on_Services"></a>Update Add-on Services</h4>
<ol style="list-style-type: decimal">
<li>
<p>Change service directory names for Kibana to the new desired version</p>
<div>
<div>
<pre class="source">metron/metron-deployment/packaging/ambari/metron-mpack/src/main/resources/addon-services/KIBANA/${YOUR_VERSION_NUMBER_HERE}
</pre></div></div>
<p>e.g.</p>
<div>
<div>
<pre class="source">metron/metron-deployment/packaging/ambari/metron-mpack/src/main/resources/addon-services/KIBANA/5.6.14
</pre></div></div>
</li>
<li>
<p>Update repoinfo.xml</p>
<p><b>Note:</b> for Curator, there is a different repo for rhel 6 vs rhel 7</p>
<p>See the following links for current repo information for Kibana and Curator.</p>
<ul>
<li><a class="externalLink" href="https://www.elastic.co/guide/en/kibana/current/rpm.html">https://www.elastic.co/guide/en/kibana/current/rpm.html</a></li>
<li><a class="externalLink" href="https://www.elastic.co/guide/en/elasticsearch/client/curator/current/yum-repository.html">https://www.elastic.co/guide/en/elasticsearch/client/curator/current/yum-repository.html</a></li>
</ul>
<p>Modify the baseurl&#x2019;s and repoid&#x2019;s in <tt>metron/metron-deployment/packaging/ambari/metron-mpack/src/main/resources/addon-services/KIBANA/${YOUR_VERSION_NUMBER_HERE}/repos/repoinfo.xml</tt>, e.g.</p>
<div>
<div>
<pre class="source">&lt;baseurl&gt;https://artifacts.elastic.co/packages/5.x/yum&lt;/baseurl&gt;
&lt;repoid&gt;kibana-5.x&lt;/repoid&gt;
&lt;reponame&gt;KIBANA&lt;/reponame&gt;
...
&lt;baseurl&gt;http://packages.elastic.co/curator/5/centos/6&lt;/baseurl&gt;
&lt;repoid&gt;ES-Curator-5.x&lt;/repoid&gt;
&lt;reponame&gt;CURATOR&lt;/reponame&gt;
</pre></div></div>
</li>
<li>
<p>Update metainfo.xml</p>
<p>Change the version number in <tt>metron/metron-deployment/packaging/ambari/metron-mpack/src/main/resources/addon-services/KIBANA/${YOUR_VERSION_NUMBER_HERE}/metainfo.xml</tt>. Also make sure to update the &#x201c;extends&#x201d; version to point to the updated common-services version, e.g.</p>
<div>
<div>
<pre class="source">&lt;name&gt;KIBANA&lt;/name&gt;
&lt;version&gt;5.6.14&lt;/version&gt;
&lt;extends&gt;common-services/KIBANA/5.6.14&lt;/extends&gt;
</pre></div></div>
</li>
</ol></div>
<div class="section">
<h4><a name="Update_mpack.json"></a>Update mpack.json</h4>
<ol style="list-style-type: decimal">
<li>Update the corresponding service_version in the service_versions_map, e.g.
<div>
<div>
<pre class="source">...
&quot;service_versions_map&quot;: [
{
&quot;service_name&quot; : &quot;KIBANA&quot;,
&quot;service_version&quot; : &quot;5.6.14&quot;,
&quot;applicable_stacks&quot; : [
...
]
},
...
]
...
</pre></div></div>
</li>
</ol></div></div></div>
</div>
</div>
</div>
<hr/>
<footer>
<div class="container-fluid">
<div class="row-fluid">
© 2015-2016 The Apache Software Foundation. Apache Metron, Metron, Apache, the Apache feather logo,
and the Apache Metron project logo are trademarks of The Apache Software Foundation.
</div>
</div>
</footer>
</body>
</html>