Thanks to visit codestin.com
Credit goes to github.com

Skip to content

vcarl/oozie-monitor

Folders and files

NameName
Last commit message
Last commit date

Latest commit

 

History

11 Commits
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 

Repository files navigation

Oozie monitor

If you're tired of clicking 15 times and opening 5 tabs just to track a single oozie job, this is the project for you!

Requires a recent version of Node.js, >=v4 is probably fine.

Sample job

Startup

This has to be run from a machine on the same network as Surus, Castor, and Kandula's gateways to work. Rather than set up an EBS instance on the VPN, you can just run it locally.

Clone this repo.

cd oozie-monitor

npm build from within the project directory. This will bundle the javascript that gets served to the browser.

npm start This will start the webserver and a proxy to Kandula, Castor, and Surus. By default the local server serves on 8080, but can be overridden with a PORT environment variable.

On initial load, the page only has a dropdown menu and a textbox. You can pick which server to get the job from with the dropdown, and enter the job ID in the textbox. This updates the URL, so refreshing the page will re-fetch all job statuses. This also means you can go directly to a specific job by specifying it as localhost:8080/#/(surus|castor|kandula)/<job id>

Incomplete jobs (Jobs with status 'RUNNING') are polled periodically, more frequently the further down they are in the tree. When jobs finish successfully, they collapsed. Clicking on an action will collapse the job it's a part of, clicking a collapsed job name will expand it. Links go to the oozie console for that job, the 'R' button refreshes a job, 'kill' kills a job.

Development

How does this work?

Oozie exposes a REST api, which is how this grabs job information. Unfortunately, that API responds with the entire job configuration in addition to its current status, so this app gets very data heavy when fetching large jobs. Each job response weighs in at arount 80kb. To mitigate this, jobs that are collapsed on load (those that already completed successfully) don't load sub-jobs. In practice it loads quickly enough not to cause interruptions.

The website is served via an extremely barebones webserver that manually checks the URL for which file to serve, and attempts to proxy to a specified gateway if none match.

bundle.js is a Webpack 2 bundled React application. It recursively renders Oozie jobs and actions, fetching the job information as it goes.

How do I contribute?

npm run watch will start a development server that watches for file changes and recompiles the application. bundle.js and bundle.js.map are emitted, building source from the src/ folder. The webserver is at /index.js.

Jobs have maximum recursion depth to avoid blowing up the browser. It's set in app.js and is currently 8, but not for any particular reason.

Key files

app.js handles job/server changes, and updates the URL. When both a server and job ID are supplied, it will render the initial Oozie job.

oozie-job.js fetches from the proxy server, and renders the job name, some job controls (refresh, kill, and a link to the oozie console for that job), and each returned action. It also polls the server for changes, with jobs further down the tree being polled more frequently.

oozie-action.js checks for a valid externalId in the action data. If there is one, it renders an OozieJob component (recursively rendering all jobs), if not it renders the name of the action and its status.

About

No description, website, or topics provided.

Resources

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published