Permalink
Browse files

Created pgxn preferred folder structure. Split out separate doc file …

…from README
  • Loading branch information...
1 parent 029c5a5 commit afddf76e41ae05714e06ad92fe48e2f9fd910f54 @keithf4 keithf4 committed May 2, 2012
Showing with 106 additions and 108 deletions.
  1. +1 −5 .gitignore
  2. +2 −2 META.json
  3. +6 −6 Makefile
  4. +0 −95 README.md
  5. +97 −0 doc/pg_jobmon.md
  6. 0 { → sql}/pg_jobmon.sql
View
@@ -1,5 +1 @@
-ebit_joblog_stuff.sql
-ofdw.perform_snapshot_newlogger.sql
-ofdw.perform_snapshot_orig.sql
-pg_jobmon_notes
-ofdw.perform_snapshot_logged.sql
+ignore/*
View
@@ -18,8 +18,8 @@
},
"provides": {
"pg_jobmon": {
- "file": "pg_jobmon.sql",
- "docfile": "readme.md",
+ "file": "sql/pg_jobmon.sql",
+ "docfile": "doc/pg_jobmon.md",
"version": "0.1.0",
"abstract": "Job logging and monitoring extension"
}
View
@@ -1,19 +1,19 @@
EXTENSION = pg_jobmon
EXTVERSION = $(shell grep default_version $(EXTENSION).control | \
sed -e "s/default_version[[:space:]]*=[[:space:]]*'\([^']*\)'/\1/")
-DATA = $(filter-out $(wildcard *--*.sql),$(wildcard sql/*.sql))
-DOCS = $(wildcard *.md)
+DATA = $(filter-out $(wildcard sql/*--*.sql),$(wildcard sql/*.sql))
+DOCS = $(wildcard doc/*.md)
PG_CONFIG = pg_config
PG91 = $(shell $(PG_CONFIG) --version | grep -qE " 8\.| 9\.0" && echo no || echo yes)
ifeq ($(PG91),yes)
-all: $(EXTENSION)--$(EXTVERSION).sql
+all: sql/$(EXTENSION)--$(EXTVERSION).sql
-$(EXTENSION)--$(EXTVERSION).sql: $(EXTENSION).sql
+sql/$(EXTENSION)--$(EXTVERSION).sql: sql/$(EXTENSION).sql
cp $< $@
-DATA = $(wildcard *--*.sql) $(EXTENSION)--$(EXTVERSION).sql
-EXTRA_CLEAN = $(EXTENSION)--$(EXTVERSION).sql
+DATA = $(wildcard sql/*--*.sql) sql/$(EXTENSION)--$(EXTVERSION).sql
+EXTRA_CLEAN = sql/$(EXTENSION)--$(EXTVERSION).sql
endif
PGXS := $(shell $(PG_CONFIG) --pgxs)
View
@@ -24,101 +24,6 @@ Make sure all the upgrade scripts for the version you have installed up to the m
Please note that until this extension is officially announced and put into the OmniTI github repository, there may not be upgrade scripts available.
-LOGGING
--------
-
-By default, the status column updates will use the text values from the job_alert_nagios table in the monitoring section. If you
-have a custom set of statuses that you'd like to use, the close, fail or cancel functions that take a custom table name.
-
-*add_job(p_job_name text) RETURNS bigint*
- Create a new entry in the job_log table. p_job_name is automatically capitalized.
- Returns the job_id of the new job.
-
-*add_step(p_job_id bigint, p_action text) RETURNS bigint*
- Add a new step in the job_detail table to an existing job. Pass it the job_id
- created by add_job() and a description of the step.
- Returns the step_id of the new step.
-
-*update_step(p_job_id bigint, p_step_id bigint, p_status text, p_message text) RETURNS void*
- Update the status of the job_id and step_id passed to it.
- p_message is for further information on the status of the step.
-
-*close_job(p_job_id bigint) RETURNS void*
- Used to successfully close the given job_id.
- Defaults to using job_alert_nagios table status text.
-
-*close_job(p_job_id bigint, p_config_table text) RETURNS void*
- Same as above for successfully closing a job but allows you to use custom status
- text that you set up in another table. See MONITORING section for more info.
-
-*fail_job(p_job_id bigint) RETURNS void*
- Used to unsuccessfully close the given job_id.
- Defaults to using job_alert_nagios table status text.
-
-*fail_job(p_job_id bigint, p_config_table text) RETURNS void*
- Same as above for unsuccessfully closing a job but allows you to use custom status
- text that you set up in another table. See MONITORING section for more info.
-
-*cancel_job(v_job_id bigint) RETURNS boolean*
- Used to unsuccessfully terminate the given job_id from outside the running job.
- Calls pg_cancel_backend() on the pid stored for the job in job_log.
- Sets the final step to note that it was manually cancelled in the job_detail table.
- Defaults to using job_alert_nagios table status text.
-
-*cancel_job(v_job_id bigint, p_config_table text) RETURNS boolean*
- Same as above for unsuccessfully, manually cancelling a job but allows you to use custom
- status text that you set up in another table. See MONITORING section for more info.
-
-**Log Tables:**
-
-*job_log*
- Logs the overall job details associated with a job_id. Recommended to make partitioned on start_time if you see high logging traffic or don't
- need to keep the data indefinitely
-
-*job_detail*
- Logs the detailed steps of each job_id associated with jobs in job_log. Recommended to make partitioned on start_time if you see high logging traffic
- or don't need to keep the data indefinitely
-
-
-MONITORING
-----------
-
-*check_job_status(p_history interval, OUT alert_code integer, OUT alert_text text)*
-The above function takes as a parameter the interval of time that you'd like to go backwards to check for bad jobs. It's recommended not to look back any further than the longest interval that a single job runs to help the check run efficiently. For example, if the longest interval between any job is a week, then pass '1 week'.
-
-The alert_code output indicates one of the following 3 statuses:
-* Return code 1 means a successful job run
-* Return code 2 is for use with jobs that support a warning indicator.
- Not critical, but someone should look into it
-* Return code 3 is for use with a critical job failure
-
-This monitoring function was originally created with nagios in mind. By default, all logging functions use the job_alert_nagios table to associate
-
- 1 = OK
- 2 = WARNING
- 3 = CRITICAL
-
-If you'd like these alert codes to be associated with other error text, you can create another table and join against it associating the code with whichever text you'd like. Alternate logging functions are available to make sure your logs get these custom statuses as well.
-See LOGGING section.
-
-The alert_text output is a more detailed message indicating what the actual jobs that failed were.
-
-An example query and output is:
-
- select r.error_text || c.alert_text as alert_status from jobmon.check_job_status('3 days') c
- join jobmon.job_alert_nagios r on c.alert_code = r.error_code;
-
- alert_status
- -------------------------------
- OK(All jobs run successfully)
-
-
-**Monitoring Tables:**
-
-*job_check_config*
-*job_check_log*
-*job_alert_nagios*
-
AUTHOR
------
View
@@ -0,0 +1,97 @@
+pg_jobmon
+=========
+
+LOGGING
+-------
+
+By default, the status column updates will use the text values from the job_alert_nagios table in the monitoring section. If you
+have a custom set of statuses that you'd like to use, the close, fail or cancel functions that take a custom table name.
+
+*add_job(p_job_name text) RETURNS bigint*
+ Create a new entry in the job_log table. p_job_name is automatically capitalized.
+ Returns the job_id of the new job.
+
+*add_step(p_job_id bigint, p_action text) RETURNS bigint*
+ Add a new step in the job_detail table to an existing job. Pass it the job_id
+ created by add_job() and a description of the step.
+ Returns the step_id of the new step.
+
+*update_step(p_job_id bigint, p_step_id bigint, p_status text, p_message text) RETURNS void*
+ Update the status of the job_id and step_id passed to it.
+ p_message is for further information on the status of the step.
+
+*close_job(p_job_id bigint) RETURNS void*
+ Used to successfully close the given job_id.
+ Defaults to using job_alert_nagios table status text.
+
+*close_job(p_job_id bigint, p_config_table text) RETURNS void*
+ Same as above for successfully closing a job but allows you to use custom status
+ text that you set up in another table. See MONITORING section for more info.
+
+*fail_job(p_job_id bigint) RETURNS void*
+ Used to unsuccessfully close the given job_id.
+ Defaults to using job_alert_nagios table status text.
+
+*fail_job(p_job_id bigint, p_config_table text) RETURNS void*
+ Same as above for unsuccessfully closing a job but allows you to use custom status
+ text that you set up in another table. See MONITORING section for more info.
+
+*cancel_job(v_job_id bigint) RETURNS boolean*
+ Used to unsuccessfully terminate the given job_id from outside the running job.
+ Calls pg_cancel_backend() on the pid stored for the job in job_log.
+ Sets the final step to note that it was manually cancelled in the job_detail table.
+ Defaults to using job_alert_nagios table status text.
+
+*cancel_job(v_job_id bigint, p_config_table text) RETURNS boolean*
+ Same as above for unsuccessfully, manually cancelling a job but allows you to use custom
+ status text that you set up in another table. See MONITORING section for more info.
+
+**Log Tables:**
+
+*job_log*
+ Logs the overall job details associated with a job_id. Recommended to make partitioned on start_time if you see high logging traffic or don't
+ need to keep the data indefinitely
+
+*job_detail*
+ Logs the detailed steps of each job_id associated with jobs in job_log. Recommended to make partitioned on start_time if you see high logging traffic
+ or don't need to keep the data indefinitely
+
+
+MONITORING
+----------
+
+*check_job_status(p_history interval, OUT alert_code integer, OUT alert_text text)*
+The above function takes as a parameter the interval of time that you'd like to go backwards to check for bad jobs. It's recommended not to look back any further than the longest interval that a single job runs to help the check run efficiently. For example, if the longest interval between any job is a week, then pass '1 week'.
+
+The alert_code output indicates one of the following 3 statuses:
+* Return code 1 means a successful job run
+* Return code 2 is for use with jobs that support a warning indicator.
+ Not critical, but someone should look into it
+* Return code 3 is for use with a critical job failure
+
+This monitoring function was originally created with nagios in mind. By default, all logging functions use the job_alert_nagios table to associate
+
+ 1 = OK
+ 2 = WARNING
+ 3 = CRITICAL
+
+If you'd like these alert codes to be associated with other error text, you can create another table and join against it associating the code with whichever text you'd like. Alternate logging functions are available to make sure your logs get these custom statuses as well.
+See LOGGING section.
+
+The alert_text output is a more detailed message indicating what the actual jobs that failed were.
+
+An example query and output is:
+
+ select r.error_text || c.alert_text as alert_status from jobmon.check_job_status('3 days') c
+ join jobmon.job_alert_nagios r on c.alert_code = r.error_code;
+
+ alert_status
+ -------------------------------
+ OK(All jobs run successfully)
+
+
+**Monitoring Tables:**
+
+*job_check_config*
+*job_check_log*
+*job_alert_nagios*
File renamed without changes.

0 comments on commit afddf76

Please sign in to comment.