I want to make a report of start and end times of a Autosys job from last three months.
How can i get it. Do i need to check archived history or logs?
If yes, please lemme know the details.
TIA
Autosys internally uses Oracle or Sybase database. As long as the data is available in the DB you can fetch it using autorep command. To get past run time use -r handle.
For example: autorep -J JobA -r -30
The above will give you last 30th run time for the job.
However, due to performance bottleneck that may arise due to historical data in the DBs the DBAs generally purge the data after a while. I have seen period of 1 day to 7 days based on the number of the jobs and database instance power.
Other approximate way would to be use the log files created by autosys if the option stdout is specified with unique filenames.
For example: you can have the attribute as std_out: $JOB_NAME.out.date +%m.%s
In this case the log file will be created as soon as the job starts which you can get from the filename using text function on unix,etc.
For the end-time, you can use the last modified time - this is where the approximate part comes in as the time would depend if your job had an echo to the log file or not. It can either be close or far based on the command of the script.
This method will not let you know the times for the box jobs as they never have a log attribute, for that you can depend on the first job in the box.
Related
I need to somehow get the start_time for the current job run dynamically from Autosys. It would be passed as an argument into our Python script. Current time isn’t good enough, it has to be the time for which the job is currently triggered which was supplied in the Jil. I haven’t found anything other than $AUTO_JOB_NAME that would get any jil attributes.
command: python3 /path/path/script.py —-job_id ${AUTO_JOB_NAME} —-conf file.conf
I want to add something like:
command: python3 /path/path/script.py —-job_id ${AUTO_JOB_NAME} —-conf file.conf —-time ${CURRENT_START_TIME}
And no current Autosys time is not what I’m looking for.
I already looked through documentation and it seems the only values defined in the runtime environment for a job are $AUTORUN and $AUTO_JOB_NAME
Why don't we use current time in the remote agent server where the Python script is hosted. It would be the same as tge job start time yoy are looking for. May differ my milliseconds, but you may experiment on that
i have an autosys box which runs at 7AM and 8AM daily. I understand that if 7AM execution does not finish till 8AM, My box will not be triggered at 8AM again.
I need to send an email from autosys to business stating that previous job is already running that is why next execution is not happening at 8AM. How can i do that? Please try to give the JIL file for it.
Thanks in advance
It all depends how have you licensed Autosys CA schedulers for your project. In our firm, we have configuration setup wherein if an Autosys job fails/terminates/maxruns/etc., it creates high severity incident.
Coming to your query, there's no straight forward way that i am aware of. First, normally we do not schedule same job in frequent intervals, unless it is a reporting job.
Still, if you want the job to generate some sort of alert if first execution exceeds start time of second execution, then you can add max_run_alarm or term_run_time in your JIL as per requirement and set it for 60 min since that's the interval between two executions.
Here is what i have added my script JIL for a data loader job :
max_run_alarm: 150
alarm_if_fail: y
alarm_if_terminated: y
box_terminator: y
term_run_time: 780
Which parameter you want to use will depend on your requirement. If you want to kill the first job then use term_run_time parameter so that second execution "might" start or use max_run_alarm parameter if you just want to send a MAX ALARM notification.
I use both! Hope this was useful.
When i changed the start time of a coordinator job in job.properties in oozie, the job is not taking the changed time, instead its running in the old scheduled time.
Old job.properties:
startMinute=08
startTime=${startDate}T${startHour}:${startMinute}Z
New job.properties:
startMinute=07
startTime=${startDate}T${startHour}:${startMinute}Z
The job is not running at the changed time:07th minute,its running at 08th minute in every hour.
Please can you let me know the solution, how i can make the job pickup the updated properties(changed timing) without restarting or killing the job.
You can't really change the timing of the co-ordinator via any methods given by Oozie(v3.3.2) . When you submit a job the contents properties are stored in the database whereas the actual workflow is in the HDFS.
Everytime you execute the co-ordinator it is necessary to have the workflow in the path specified in properties during job submission but the properties file is not needed. What I mean to imply is the properties file does not come into the picture after submitting the job.
One hack is to update the time directly in the database using SQL query.But I am not sure about the implications of it.The property might become inconsistent across the database.
You have to kill the job and resubmit a new one.
Note: oozie provides a way to change the concurrency,endtime and pausetime as specified in the official docs.
Currenty I have requirement in my enviroment for the autosys email notifition.
Requirement: If the job runs more than the specified time it should trigger an email.
What I am trying is using max_run_alam, but I am not successful.
Lets say i have a job that runs for 10mins(lets say the time as 10.00). i set max_run_alarm as 3. i should get an email at 10.03 where i can goahead and see why the job is running more than the max_run_alarm. if i use max_run_alarm i am able to see in the logs triggering that alarm, but I cannot spend all day monitoring the logs to see which job is taking long as i have many jobs. my question is am i using max_run_alarm in the correct way or is there something else i am missing or is there entirely different way for the emails to generate.
pls advise.
We are using autosys R11 at work. I believe the triggering of emails is already automated in higher versions of autosys, but, in our version, to send automatic emails after a certain time, we create two extra autosys jobs. One autosys job starts at the same time as the job you want to "monitor". This job contains a 'sleep' command. (in your example, the command would be "sleep 180" for the job to run for 3 minutes until completion). The second extra job is the sending of the email and only starts after successful completion of the sleep-job.
To prevent the mail from being send every time the autosys box starts, you have to add your first job as BOX_SUCCESS condition. The sleep-job will run to completion, but the mail-job went from the "ACTIVATED" state to the "INACTIVE" state because the autosys box isn't RUNNING anymore.
we have scheduled one script to run for every 5 mins.
how we can check that whether the script is running for every 5 minutes in linux?
If anyone knows, please Reply..
Thanks in Advance.
We have created the script. But we dont run that script. Our Support team will run this for every minutes. If they found any error, then they will update to us.
How we can cofirm that they r running this script properly or not?
If you don't want to modify your script and you've scheduled it in cron, you could change your cron line to:
*/5 * * * * /home/me/myscript.sh; date >> /tmp/mylog
And check /tmp/mylog - a new line should be added with the date and time every run.
Maybe by making the script log in a logfile with the timestamp, so you can verify if the timestamp is OK, something like:
date >>/tmp/myprocess.log
at the top of the script (or in the loop if that's how you're "running" it) then you can examine the log file to check.
Maybe you could just add a log with a timestamp in your script ?
Then you could see if the script was effectively run every 5 min.
Without changing the script?
atop is a process monitor package that can record history of programs being run, and as root will catch terminations as well. See http://www.atcomputing.nl/Tools/atop/whyatop.html
Also consider the process accounting tools http://www.faqs.org/docs/Linux-mini/Process-Accounting.html