ambari-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hemanth Yamijala (JIRA)" <>
Subject [jira] [Updated] (AMBARI-17785) Provide support for S3 as a first class destination for log events
Date Sun, 31 Jul 2016 08:43:20 GMT


Hemanth Yamijala updated AMBARI-17785:
    Attachment: AMBARI-17785.patch

Attached patch implements batch mode, asynchronous, periodic upload of log events to S3. It
uses the {{LogSpooler}} class that was refactored out of the {{OutputHDFSFile}} class in AMBARI-17788.
Hence, it is dependent on AMBARI-17788.

> Provide support for S3 as a first class destination for log events
> ------------------------------------------------------------------
>                 Key: AMBARI-17785
>                 URL:
>             Project: Ambari
>          Issue Type: Improvement
>          Components: ambari-logsearch
>            Reporter: Hemanth Yamijala
>            Assignee: Hemanth Yamijala
>         Attachments: AMBARI-17785.patch
> AMBARI-17045 added support for uploading Hadoop service logs from machines to S3. The
intended usage there was as a one time trigger where, on-demand, the log files matching certain
paths can be uploaded to a given S3 bucket and path.
> While useful, there are some use cases where we might need more than this one time activity,
particularly when clusters are deployed on ephemeral machines such as cloud instances:
> * The machines running the logfeeder could be irrevocably lost and in that case we would
not be able to retrieve any logs.
> * If we are copying logs at one time, that were generated over a long period of time,
the time to copy all the logs at the end could extend cluster up-time and cost.
> It would be nice to have an ability to support S3 as another output destination in logsearch
just like Kafka, Solr etc. This JIRA is to track work towards this enhancement.

This message was sent by Atlassian JIRA

View raw message