Hey David,
"[_local_,_site_]" didn't work, but you put me on the right path. It
seems that "[_enp0s8_]" works! Thanks!
Have you tried [_local_,_site_]? If that doesn't work, perhaps give the
publish address for enp0s8. Be sure to set that on the network_host
field
in the Elasticsearch conf
Hi Laurens,
Have you tried [_local_,_site_]? If that doesn't work, perhaps give the
publish address for enp0s8. Be sure to set that on the network_host field
in the Elasticsearch config and leave network_publish_host empty.
-D...
On Thu, May 11, 2017 at 2:51 PM, Laurens Vets wrote:
> Environm
Environment:
- 2 VMs, each with 2 ip addresses (interfaces enp0s3 & enp0s8) called
node1 and node3
- ES master on node1, data node on node3
- CentOS 7
For some reason, elasticsearch uses the ip attached to enp0s3 as it's
publish address. Due to the way my test environment is set up, this will
Github user ctramnitz commented on the issue:
https://github.com/apache/incubator-metron/pull/579
I agree to both of your points, defining it with the final name from the
beginning would be more efficient and we should come up with a more normalized
and standardized field naming conve
Github user simonellistonball commented on the issue:
https://github.com/apache/incubator-metron/pull/579
Yes, that makes sense, but does have some performance implications of
course. A single mapping would have much faster response, so I would question
the original approach (on which
Well, you do at the moment… I’m still keen on the idea of parsers emitting a
schema of sorts, and then the framework being expanded to use that schema,
along with enrichment schema and stellar output type inference to generate ES
templates, but that’s another story. ES Template specs certainly d
Github user ctramnitz commented on the issue:
https://github.com/apache/incubator-metron/pull/579
Do you have any examples? The previous concept was to use arbitrary (at
least I couldn't find any reference) field names (i.e. source_address or
destination_address) and then further down
I missed elasticsearch, you do need to understand ES indexing to setup the
correct storage etc for the fields you produce.
On May 11, 2017 at 09:48:10, Otto Fowler (ottobackwa...@gmail.com) wrote:
Part of the point of having a framework like metron is that you don’t
*need* to know those things
Part of the point of having a framework like metron is that you don’t
*need* to know those things to contribute parsers.
What you would want to understand are the things at parser scope:
STELLAR,
the MessageParser interface
The base ‘typed’ parsers ( JSONMap, CSVParser, BasicGrokParser )
and your
Hi Mark,
If you’re looking to write Metron parsers you aren’t going to have to worry
about Nifi or Kafka in any level of detail. The parser interface just gets
byte[] and outputs JSON.
Of course I would never recommend avoiding the reading around all the other
exciting bits and components ar
Hi,
I really would like to help with parser development. I am reading up on Nifi,
Kafka and there are probably other topics I am missing now.
As when it comes to Hadoop ecosystem I am pretty much a beginner I will
unfortunately need a month to learn the different components.
Regards,
Mark de R
Github user simonellistonball commented on the issue:
https://github.com/apache/incubator-metron/pull/579
A number of the field name changes seem to depart from Metron conventions.
Is there a reason to change these from matching the metron ip_src_addr style
pattern?
---
If your pro
GitHub user simonellistonball opened a pull request:
https://github.com/apache/incubator-metron/pull/582
METRON-948 Corrected license abbreviation in package.json file
## Contributor Comments
[Please place any comments here. A description of the problem/enhancement,
how to repr
Github user justinleet commented on the issue:
https://github.com/apache/incubator-metron/pull/567
They sneak in because most of our license headers are Javadoc (`/**`)
instead of just comments (`/*`). It's something I noticed when looking at
autoformatting against Checkstyle. So wh
That would be an oversight. It should be Apache. I’ll fix that now.
Simon
> On 11 May 2017, at 12:59, Otto Fowler wrote:
>
> Hey, in the package.json for metron config, it is showing the lic. as MIT,
> but the LICENSE file shows Apache 2.0.
> That doesn’t seem right.
>
Hey, in the package.json for metron config, it is showing the lic. as MIT, but
the LICENSE file shows Apache 2.0.
That doesn’t seem right.
Github user jjmeyer0 commented on the issue:
https://github.com/apache/incubator-metron/pull/567
@merrimanr I reverted the license headers back just in case.
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project
Github user simonellistonball commented on a diff in the pull request:
https://github.com/apache/incubator-metron/pull/581#discussion_r115962297
--- Diff:
metron-deployment/packaging/ambari/metron-mpack/src/main/resources/common-services/METRON/CURRENT/package/scripts/management_ui_mas
18 matches
Mail list logo