metron-platform/metron-parsing/metron-parsers-common/3rdPartyParser.md - metron - Git at Google

 <!--
 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.
 -->

 # Custom Metron Parsers

 We have many stock parsers for normal operations.  Some of these are
 networking and cybersecurity focused (e.g. the ASA Parser), some of
 these are general purpose (e.g. the CSVParser), but inevitably users
 will want to extend the system to process their own data formats.  To
 enable this, this is a walkthrough of how to create and use a custom
 parser within Metron.

 # Writing A Custom Parser
 Before we can use a parser, we will need to create a custom parser.  The
 parser is the workhorse of Metron ingest.  It provides the mapping
 between the raw data coming in via the Kafka value and a `JSONObject`,
 the internal data structure provided.

 ## Implementation

 In order to do create a custom parser, we need to do one of the following:
 * Write a class which conforms to the `org.apache.metron.parsers.interfaces.MessageParser<JSONObject>` and `java.util.Serializable` interfaces
   * Implement `init()`, `validate(JSONObject message)`, and `List<JSONObject> parse(byte[] rawMessage)`
 * Write a class which extends `org.apache.metron.parsers.BasicParser`
   * Provides convenience implementations to `validate` which ensures `timestamp` and `original_string` fields exist.

 Also note that it is possible to specify a configuration option for the charset you would like your parser to use to read data. In order to do so,
 you would call the `setReadCharset` method in your `configure` method when extending `BasicParser`. And then when you're specifying the charset
 to use in the `parse` method, you would use `getReadCharset` as follows `rawMessage = new String(msg, getReadCharset());`. The common configuration
 option key is "`readCharset`" and is passed via a key/value pair in the `parserConfig` JSON section of your overall parser configuration file, e.g.
 ```
 {
   ...
   "parserConfig" : {
     "readCharset" : "UTF_8"
     ...
   }
   ...
 }
 ```

 If implementing the MessageParser interface directly, you would need to handle reading and setting the configuration on your own. Override the `default Charset getReadCharset()` method provided in the `MessageParser` interface.

 ## Example

 In order to illustrate how this might be done, let's create a very
 simple parser that takes a comma separated pair and creates a couple of
 fields:
 * `original_string` -- the raw data
 * `timestamp` -- the current time
 * `first` -- the first field of the comma separated pair
 * `last` -- the last field of the comma separated pair

 For this demonstration, let's create a maven project to compile our
 project.  We'll call it `extra_parsers`, so in your workspace, let's set
 up the maven project:

 * Create the maven infrastructure for `extra_parsers` via
     ```
     mkdir -p extra_parsers/src/{main,test}/java
     ```

 * Create a pom file indicating how we should build our parsers by
   editing `extra_parsers/pom.xml` with the following content:
     ```
     <project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
       <modelVersion>4.0.0</modelVersion>
       <groupId>com.3rdparty</groupId>
       <artifactId>extra-parsers</artifactId>
       <packaging>jar</packaging>
       <version>1.0-SNAPSHOT</version>
       <name>extra-parsers</name>
       <url>http://thirdpartysoftware.org</url>
       <properties>
         <!-- The java version to conform to.  Metron works all the way to 1.8 -->
         <java_version>1.8</java_version>
         <!-- The version of Metron that we'll be targetting. -->
         <metron_version>0.4.1</metron_version>
         <!-- To complete the simulation, we'll depend on a common dependency -->
         <guava_version>19.0</guava_version>
         <!-- We will shade our dependencies to create a single jar at the end -->
         <shade_version>2.4.3</shade_version>
       </properties>
       <dependencies>
         <!--
         We want to depend on Metron, but ensure that the scope is "provided"
         as we do not want to include it in our bundle.
         -->
         <dependency>
           <groupId>org.apache.metron</groupId>
           <artifactId>metron-parsers-common</artifactId>
           <version>${metron_version}</version>
           <scope>provided</scope>
         </dependency>
         <dependency>
           <groupId>com.google.guava</groupId>
           <artifactId>guava</artifactId>
           <version>${guava_version}</version>
         </dependency>
         <dependency>
           <groupId>junit</groupId>
           <artifactId>junit</artifactId>
           <version>3.8.1</version>
           <scope>test</scope>
         </dependency>
       </dependencies>
       <build>
         <plugins>
          <!-- We will set up the shade plugin to create a single jar at the
                end of the build lifecycle.  We will exclude some things and
                relocate others to simulate a real situation.

                One thing to note is that it's a good practice to shade and
                relocate common libraries that may be dependencies in Metron.
                Your jar will be merged with the parsers jar, so the metron
                version will be included for all overlapping classes.
                So, shade and relocate to ensure that YOUR version of the library is used.
           -->

           <plugin>
             <groupId>org.apache.maven.plugins</groupId>
             <artifactId>maven-shade-plugin</artifactId>
             <version>${shade_version}</version>
             <configuration>
               <createDependencyReducedPom>true</createDependencyReducedPom>
               <artifactSet>
                 <excludes>
                   <!-- Exclude slf4j for no reason other than to illustrate how to exclude dependencies.
                        The metron team has nothing against slf4j. :-)
                    -->
                   <exclude>*slf4j*</exclude>
                 </excludes>
               </artifactSet>
             </configuration>
             <executions>
               <execution>
                 <phase>package</phase>
                 <goals>
                   <goal>shade</goal>
                 </goals>
                 <configuration>
                   <shadedArtifactAttached>true</shadedArtifactAttached>
                   <shadedClassifierName>uber</shadedClassifierName>
                   <filters>
                     <filter>
                       <!-- Sometimes these get added and confuse the uber jar out of shade -->
                       <artifact>*:*</artifact>
                       <excludes>
                         <exclude>META-INF/*.SF</exclude>
                         <exclude>META-INF/*.DSA</exclude>
                         <exclude>META-INF/*.RSA</exclude>
                       </excludes>
                     </filter>
                   </filters>
                   <relocations>
                     <!-- Relocate guava as it's used in Metron and I really want 0.19 -->
                     <relocation>
                       <pattern>com.google</pattern>
                       <shadedPattern>com.thirdparty.guava</shadedPattern>
                     </relocation>
                   </relocations>
                   <artifactSet>
                     <excludes>
                       <!-- We can also exclude by artifactId and groupId -->
                       <exclude>storm:storm-core:*</exclude>
                       <exclude>storm:storm-lib:*</exclude>
                       <exclude>org.slf4j.impl*</exclude>
                       <exclude>org.slf4j:slf4j-log4j*</exclude>
                     </excludes>
                   </artifactSet>
                 </configuration>
               </execution>
             </executions>
           </plugin>
           <!--
           We want to make sure we compile using java 1.8.
           -->
           <plugin>
             <groupId>org.apache.maven.plugins</groupId>
             <artifactId>maven-compiler-plugin</artifactId>
             <version>3.5.1</version>
             <configuration>
               <forceJavacCompilerUse>true</forceJavacCompilerUse>
               <source>${java_version}</source>
               <compilerArgument>-Xlint:unchecked</compilerArgument>
               <target>${java_version}</target>
               <showWarnings>true</showWarnings>
             </configuration>
           </plugin>
         </plugins>
       </build>
     </project>
     ```

 * Now let's create our parser  `com.thirdparty.SimpleParser` by creating the file `extra-parsers/src/main/java/com/thirdparty/SimpleParser.java` with the following content:
     ```
     package com.thirdparty;

     import com.google.common.base.Splitter;
     import com.google.common.collect.ImmutableList;
     import com.google.common.collect.Iterables;
     import org.apache.metron.parsers.BasicParser;
     import org.json.simple.JSONObject;

     import java.util.List;
     import java.util.Map;

     public class SimpleParser extends BasicParser {
       @Override
       public void init() {

       }

       @Override
       public List<JSONObject> parse(byte[] bytes) {
         String input = new String(bytes);
         Iterable<String> it = Splitter.on(",").split(input);
         JSONObject ret = new JSONObject();
         ret.put("original_string", input);
         ret.put("timestamp", System.currentTimeMillis());
         ret.put("first", Iterables.getFirst(it, "missing"));
         ret.put("last", Iterables.getLast(it, "missing"));
         return ImmutableList.of(ret);
       }

       @Override
       public void configure(Map<String, Object> map) {

       }
     }
     ```
 * Compile the parser via `mvn clean package` in `extra_parsers`

 * This will create a jar containing your parser and its dependencies (sans Metron dependencies) in `extra-parsers/target/extra-parsers-1.0-SNAPSHOT-uber.jar`

 # Deploying Your Custom Parser

 In order to deploy your newly built custom parser, you would place the jar file above in the `$METRON_HOME/parser_contrib` directory on the Metron host (i.e. any host you would start parsers from or, alternatively, where the Metron REST is hosted).

 ## Example

 Let's work through deploying the example above.

 ### Preliminaries

 We assume that the following environment variables are set:
 * `METRON_HOME` - the home directory for metron
 * `ZOOKEEPER` - The zookeeper quorum (comma separated with port specified: e.g. `node1:2181` for full-dev)
 * `BROKERLIST` - The Kafka broker list (comma separated with port specified: e.g. `node1:6667` for full-dev)
 * `ES_HOST` - The elasticsearch master (and port) e.g. `node1:9200` for full-dev.

 Also, this does not assume that you are using a kerberized cluster.  If you are, then the parser start command will adjust slightly to include the security protocol.

 ### Copy the jar file up

 Copy the jar file located in `extra-parsers/target/extra-parsers-1.0-SNAPSHOT-uber.jar` to `$METRON_HOME/parser_contrib` and ensure the permissions are such that the `metron` user can read and execute.

 ### Restart the REST service in Ambari

 In order for new parsers to be picked up, the REST service must be restarted.  You can do that from within Ambari by restarting the `Metron REST` service.

 ### Create a Kafka Topic

 Create a kafka topic, let's call it `test`.
 ```
 KAFKA_HOME=/usr/hdp/current/kafka-broker
 $KAFKA_HOME/bin/kafka-topics.sh --zookeeper $ZOOKEEPER --create --topic test --partitions 1 --replication-factor 1
 ```

 Note, in a real deployment, that topic would be named something more descriptive and would have replication factor and partitions set to something less trivial.

 ### Configure Test Parser

 Create the a file called `$METRON_HOME/config/zookeeper/parsers/test.json` with the following content:
 ```
 {
   "parserClassName":"com.thirdparty.SimpleParser",
   "sensorTopic":"test"
 }
 ```

 ### Push the Zookeeper Configs

 Now push the config to Zookeeper with the following command.
 ```
 $METRON_HOME/bin/zk_load_configs.sh -m PUSH -i $METRON_HOME/config/zookeeper/ -z $ZOOKEEPER
 ```

 ### Start Parser
 Now we can start the parser and send some data through:

 * Start the parser
     ```
     $METRON_HOME/bin/start_parser_topology.sh -k $BROKERLIST -z $ZOOKEEPER -s test
     ```

 * Send example data through:
     ```
     echo "apache,metron" | /usr/hdp/current/kafka-broker/bin/kafka-console-producer.sh --broker-list $BROKERLIST --topic test
     ```

 * Validate data was written in ES:
     ```
     curl -XPOST "http://$ES_HOST/test*/_search?pretty" -d '
     {
       "_source" : [ "original_string", "timestamp", "first", "last"]
     }
     '
     ```

 * This should yield something like:
     ```
     {
       "took" : 23,
       "timed_out" : false,
       "_shards" : {
         "total" : 1,
         "successful" : 1,
         "failed" : 0
       },
       "hits" : {
         "total" : 1,
         "max_score" : 1.0,
         "hits" : [ {
           "_index" : "test_index_2017.10.04.17",
           "_type" : "test_doc",
           "_id" : "3ae4dd4d-8c09-4f2a-93c0-26ec5508baaa",
           "_score" : 1.0,
           "_source" : {
             "original_string" : "apache,metron",
             "last" : "metron",
             "first" : "apache",
             "timestamp" : 1507138373223
           }
         } ]
       }
     }
     ```

 ### Via the Management UI

 As long as the REST service is restarted after new parsers are added to `$METRON_HOME/parser_contrib`, they are available in the UI to creating and deploying parsers.
	<!--
	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.
	-->

	# Custom Metron Parsers

	We have many stock parsers for normal operations. Some of these are
	networking and cybersecurity focused (e.g. the ASA Parser), some of
	these are general purpose (e.g. the CSVParser), but inevitably users
	will want to extend the system to process their own data formats. To
	enable this, this is a walkthrough of how to create and use a custom
	parser within Metron.

	# Writing A Custom Parser
	Before we can use a parser, we will need to create a custom parser. The
	parser is the workhorse of Metron ingest. It provides the mapping
	between the raw data coming in via the Kafka value and a `JSONObject`,
	the internal data structure provided.

	## Implementation

	In order to do create a custom parser, we need to do one of the following:
	* Write a class which conforms to the `org.apache.metron.parsers.interfaces.MessageParser<JSONObject>` and `java.util.Serializable` interfaces
	* Implement `init()`, `validate(JSONObject message)`, and `List<JSONObject> parse(byte[] rawMessage)`
	* Write a class which extends `org.apache.metron.parsers.BasicParser`
	* Provides convenience implementations to `validate` which ensures `timestamp` and `original_string` fields exist.

	Also note that it is possible to specify a configuration option for the charset you would like your parser to use to read data. In order to do so,
	you would call the `setReadCharset` method in your `configure` method when extending `BasicParser`. And then when you're specifying the charset
	to use in the `parse` method, you would use `getReadCharset` as follows `rawMessage = new String(msg, getReadCharset());`. The common configuration
	option key is "`readCharset`" and is passed via a key/value pair in the `parserConfig` JSON section of your overall parser configuration file, e.g.
	```
	{
	...
	"parserConfig" : {
	"readCharset" : "UTF_8"
	...
	}
	...
	}
	```

	If implementing the MessageParser interface directly, you would need to handle reading and setting the configuration on your own. Override the `default Charset getReadCharset()` method provided in the `MessageParser` interface.

	## Example

	In order to illustrate how this might be done, let's create a very
	simple parser that takes a comma separated pair and creates a couple of
	fields:
	* `original_string` -- the raw data
	* `timestamp` -- the current time
	* `first` -- the first field of the comma separated pair
	* `last` -- the last field of the comma separated pair

	For this demonstration, let's create a maven project to compile our
	project. We'll call it `extra_parsers`, so in your workspace, let's set
	up the maven project:

	* Create the maven infrastructure for `extra_parsers` via
	```
	mkdir -p extra_parsers/src/{main,test}/java
	```

	* Create a pom file indicating how we should build our parsers by
	editing `extra_parsers/pom.xml` with the following content:
	```
	<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
	<modelVersion>4.0.0</modelVersion>
	<groupId>com.3rdparty</groupId>
	<artifactId>extra-parsers</artifactId>
	<packaging>jar</packaging>
	<version>1.0-SNAPSHOT</version>
	<name>extra-parsers</name>
	<url>http://thirdpartysoftware.org</url>
	<properties>
	<!-- The java version to conform to. Metron works all the way to 1.8 -->
	<java_version>1.8</java_version>
	<!-- The version of Metron that we'll be targetting. -->
	<metron_version>0.4.1</metron_version>
	<!-- To complete the simulation, we'll depend on a common dependency -->
	<guava_version>19.0</guava_version>
	<!-- We will shade our dependencies to create a single jar at the end -->
	<shade_version>2.4.3</shade_version>
	</properties>
	<dependencies>
	<!--
	We want to depend on Metron, but ensure that the scope is "provided"
	as we do not want to include it in our bundle.
	-->
	<dependency>
	<groupId>org.apache.metron</groupId>
	<artifactId>metron-parsers-common</artifactId>
	<version>${metron_version}</version>
	<scope>provided</scope>
	</dependency>
	<dependency>
	<groupId>com.google.guava</groupId>
	<artifactId>guava</artifactId>
	<version>${guava_version}</version>
	</dependency>
	<dependency>
	<groupId>junit</groupId>
	<artifactId>junit</artifactId>
	<version>3.8.1</version>
	<scope>test</scope>
	</dependency>
	</dependencies>
	<build>
	<plugins>
	<!-- We will set up the shade plugin to create a single jar at the
	end of the build lifecycle. We will exclude some things and
	relocate others to simulate a real situation.

	One thing to note is that it's a good practice to shade and
	relocate common libraries that may be dependencies in Metron.
	Your jar will be merged with the parsers jar, so the metron
	version will be included for all overlapping classes.
	So, shade and relocate to ensure that YOUR version of the library is used.
	-->

	<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-shade-plugin</artifactId>
	<version>${shade_version}</version>
	<configuration>
	<createDependencyReducedPom>true</createDependencyReducedPom>
	<artifactSet>
	<excludes>
	<!-- Exclude slf4j for no reason other than to illustrate how to exclude dependencies.
	The metron team has nothing against slf4j. :-)
	-->
	<exclude>slf4j</exclude>
	</excludes>
	</artifactSet>
	</configuration>
	<executions>
	<execution>
	<phase>package</phase>
	<goals>
	<goal>shade</goal>
	</goals>
	<configuration>
	<shadedArtifactAttached>true</shadedArtifactAttached>
	<shadedClassifierName>uber</shadedClassifierName>
	<filters>
	<filter>
	<!-- Sometimes these get added and confuse the uber jar out of shade -->
	<artifact>:</artifact>
	<excludes>
	<exclude>META-INF/*.SF</exclude>
	<exclude>META-INF/*.DSA</exclude>
	<exclude>META-INF/*.RSA</exclude>
	</excludes>
	</filter>
	</filters>
	<relocations>
	<!-- Relocate guava as it's used in Metron and I really want 0.19 -->
	<relocation>
	<pattern>com.google</pattern>
	<shadedPattern>com.thirdparty.guava</shadedPattern>
	</relocation>
	</relocations>
	<artifactSet>
	<excludes>
	<!-- We can also exclude by artifactId and groupId -->
	<exclude>storm:storm-core:*</exclude>
	<exclude>storm:storm-lib:*</exclude>
	<exclude>org.slf4j.impl*</exclude>
	<exclude>org.slf4j:slf4j-log4j*</exclude>
	</excludes>
	</artifactSet>
	</configuration>
	</execution>
	</executions>
	</plugin>
	<!--
	We want to make sure we compile using java 1.8.
	-->
	<plugin>
	<groupId>org.apache.maven.plugins</groupId>
	<artifactId>maven-compiler-plugin</artifactId>
	<version>3.5.1</version>
	<configuration>
	<forceJavacCompilerUse>true</forceJavacCompilerUse>
	<source>${java_version}</source>
	<compilerArgument>-Xlint:unchecked</compilerArgument>
	<target>${java_version}</target>
	<showWarnings>true</showWarnings>
	</configuration>
	</plugin>
	</plugins>
	</build>
	</project>
	```

	* Now let's create our parser `com.thirdparty.SimpleParser` by creating the file `extra-parsers/src/main/java/com/thirdparty/SimpleParser.java` with the following content:
	```
	package com.thirdparty;

	import com.google.common.base.Splitter;
	import com.google.common.collect.ImmutableList;
	import com.google.common.collect.Iterables;
	import org.apache.metron.parsers.BasicParser;
	import org.json.simple.JSONObject;

	import java.util.List;
	import java.util.Map;

	public class SimpleParser extends BasicParser {
	@Override
	public void init() {

	}

	@Override
	public List<JSONObject> parse(byte[] bytes) {
	String input = new String(bytes);
	Iterable<String> it = Splitter.on(",").split(input);
	JSONObject ret = new JSONObject();
	ret.put("original_string", input);
	ret.put("timestamp", System.currentTimeMillis());
	ret.put("first", Iterables.getFirst(it, "missing"));
	ret.put("last", Iterables.getLast(it, "missing"));
	return ImmutableList.of(ret);
	}

	@Override
	public void configure(Map<String, Object> map) {

	}
	}
	```
	* Compile the parser via `mvn clean package` in `extra_parsers`

	* This will create a jar containing your parser and its dependencies (sans Metron dependencies) in `extra-parsers/target/extra-parsers-1.0-SNAPSHOT-uber.jar`

	# Deploying Your Custom Parser

	In order to deploy your newly built custom parser, you would place the jar file above in the `$METRON_HOME/parser_contrib` directory on the Metron host (i.e. any host you would start parsers from or, alternatively, where the Metron REST is hosted).

	## Example

	Let's work through deploying the example above.

	### Preliminaries

	We assume that the following environment variables are set:
	* `METRON_HOME` - the home directory for metron
	* `ZOOKEEPER` - The zookeeper quorum (comma separated with port specified: e.g. `node1:2181` for full-dev)
	* `BROKERLIST` - The Kafka broker list (comma separated with port specified: e.g. `node1:6667` for full-dev)
	* `ES_HOST` - The elasticsearch master (and port) e.g. `node1:9200` for full-dev.

	Also, this does not assume that you are using a kerberized cluster. If you are, then the parser start command will adjust slightly to include the security protocol.

	### Copy the jar file up

	Copy the jar file located in `extra-parsers/target/extra-parsers-1.0-SNAPSHOT-uber.jar` to `$METRON_HOME/parser_contrib` and ensure the permissions are such that the `metron` user can read and execute.

	### Restart the REST service in Ambari

	In order for new parsers to be picked up, the REST service must be restarted. You can do that from within Ambari by restarting the `Metron REST` service.

	### Create a Kafka Topic

	Create a kafka topic, let's call it `test`.
	```
	KAFKA_HOME=/usr/hdp/current/kafka-broker
	$KAFKA_HOME/bin/kafka-topics.sh --zookeeper $ZOOKEEPER --create --topic test --partitions 1 --replication-factor 1
	```

	Note, in a real deployment, that topic would be named something more descriptive and would have replication factor and partitions set to something less trivial.

	### Configure Test Parser

	Create the a file called `$METRON_HOME/config/zookeeper/parsers/test.json` with the following content:
	```
	{
	"parserClassName":"com.thirdparty.SimpleParser",
	"sensorTopic":"test"
	}
	```

	### Push the Zookeeper Configs

	Now push the config to Zookeeper with the following command.
	```
	$METRON_HOME/bin/zk_load_configs.sh -m PUSH -i $METRON_HOME/config/zookeeper/ -z $ZOOKEEPER
	```

	### Start Parser
	Now we can start the parser and send some data through:

	* Start the parser
	```
	$METRON_HOME/bin/start_parser_topology.sh -k $BROKERLIST -z $ZOOKEEPER -s test
	```

	* Send example data through:
	```
	echo "apache,metron" \| /usr/hdp/current/kafka-broker/bin/kafka-console-producer.sh --broker-list $BROKERLIST --topic test
	```

	* Validate data was written in ES:
	```
	curl -XPOST "http://$ES_HOST/test*/_search?pretty" -d '
	{
	"_source" : [ "original_string", "timestamp", "first", "last"]
	}
	'
	```

	* This should yield something like:
	```
	{
	"took" : 23,
	"timed_out" : false,
	"_shards" : {
	"total" : 1,
	"successful" : 1,
	"failed" : 0
	},
	"hits" : {
	"total" : 1,
	"max_score" : 1.0,
	"hits" : [ {
	"_index" : "test_index_2017.10.04.17",
	"_type" : "test_doc",
	"_id" : "3ae4dd4d-8c09-4f2a-93c0-26ec5508baaa",
	"_score" : 1.0,
	"_source" : {
	"original_string" : "apache,metron",
	"last" : "metron",
	"first" : "apache",
	"timestamp" : 1507138373223
	}
	} ]
	}
	}
	```

	### Via the Management UI

	As long as the REST service is restarted after new parsers are added to `$METRON_HOME/parser_contrib`, they are available in the UI to creating and deploying parsers.