REPORTING(5)

✨ REPORTING(5) ✨

Grid Engine File Formats πŸŽ€


πŸ’– NAME πŸ’–

reporting β€” the Grid Engine reporting file format, bestie. that's it, that's the name.


🌸 DESCRIPTION 🌸

okay so picture this: your Grid Engine system can write a whole reporting file to

$SGE_ROOT/$SGE_CELL/common/reporting

but only if you set reporting=true in the reporting_params of sge_conf(5). that's the vibe check β€” no reporting=true, no file, periodt. πŸ’…

and this doesn't just happen whenever, it happens at intervals of the flush_time specified in that exact same place. same config, same energy. 🫢

so what's actually in this file? literally everything you could ever want for accounting, monitoring and analysis purposes. it's giving main character energy for your whole cluster. πŸ‘‘

here's the tea on what it contains:

  • info about the cluster itself β€” hosts, queues, load values, consumables, etc. the whole squad 🌈
  • info about the jobs running in the cluster πŸ’Ό
  • info about sharetree configuration and usage 🌳

and the way that all this info is time-related?? every single event gets dumped to the reporting file in a configurable interval. it's obsessed with timestamps fr fr. ⏰

which means you get both worlds, no cap:

  • "real time" monitoring of the cluster status πŸ‘€
  • historical analysis for when you need to look back πŸ“œ

both. at the same time. iconic behavior honestly. ✨


more coming, bestie β€” this is just part 1 of 3, don't go anywhere πŸ’œ

🌈 FORMAT 🌈

okay so bestie, the reporting file is literally an ASCII file. Every single line? One record. The fields of a record are separated by a delimiter β€” that's a colon : β€” and yes it's giving very "just split on colon" energy. The reporting file contains records of different type, and each record type has its own specific record structure. No cap.

The first two fields are common to all reporting records:

  • time β€” the time when the record was created. All time values described here are the number of seconds since the Unix epoch (1970-01-01 00:00:00 UTC). So like, seconds since the dawn of Unix time, periodt.
  • record type β€” the type of the accounting record.

The different types of records and their structure are described below, eliding the leading time and record type fields in each case. So imagine those two are always vibing at the front, okay?


πŸ’– new_job πŸ’–

The new_job record is written whenever a new job enters the system (usually by a submission command). It has the following fields:

  • submission_time β€” time when the job was submitted.
  • job_number β€” the job number.
  • task_number β€” the array task id. Always has the value -1 for new_job records (as array tasks haven't been created at that stage).
  • pe_taskid β€” the task id of parallel tasks. Always has the value "none" for new_job records.
  • job_name β€” the job name (from the -N submission option).
  • owner β€” the job owner.
  • group β€” the Unix group of the job owner.
  • project β€” the project the job is running in.
  • department β€” the department the job owner is in.
  • account β€” the account string specified for the job (from the -A submission option).
  • priority β€” the job priority (from the -p submission option).

🌸 job_log 🌸

If joblog=true is specified in the sge_conf(5) reporting_params, a job_log record is written whenever a job, an array task or a PE task changes status. A status change can be the transition from pending to running, but it can also be triggered by user actions, like suspension of a job. It has the following fields:

  • event_time β€” time when the event was generated.
  • event β€” a one word description of the event.
  • job_number β€” the job number.
  • task_number β€” the PE task id. Always has the value -1 for new_job records (as parallel tasks haven't been created at that stage).
  • pe_taskid β€” the task id of parallel tasks. Always has the value "none" for new_job records.
  • state β€” the state of the job after the event was processed.
  • user β€” the user who initiated the event (or special usernames "qmaster", "scheduler" and "execd" for actions of the system itself like scheduling jobs, executing jobs etc.).
  • host β€” the host from which the action was initiated (e.g. the submit host, the qmaster host, etc.).
  • state_time β€” reserved field for later use.
  • submission_time β€” time when the job was submitted.
  • job_name β€” the job name (from the -N submission option).
  • owner β€” the job owner.
  • group β€” the Unix group of the job owner.
  • project β€” the project the job is running in.
  • department β€” the department the job owner is in.
  • account β€” the account string specified for the job (from the -A submission option).
  • priority β€” the job priority (from the -p submission option).
  • message β€” a message describing the reported action.

🧾 acct 🧾

Records of type acct are accounting records. Normally, they are written whenever a job, a task of an array job, or a task of a parallel job terminates. However, for long running jobs an intermediate acct record is created once a day after midnight. This results in multiple accounting records for a particular job and allows for fine-grained resource usage monitoring over time.

Accounting records have the structure described in accounting(5), with the addition of leading time and type fields (which are not used in the accounting file).


πŸŽ€ queue πŸŽ€

Records of type queue contain state information for queues (queue instances). A queue record has the following fields:

  • qname β€” the cluster queue name.
  • hostname β€” the hostname of a specific queue instance.
  • report_time β€” the time when a state change was triggered.
  • state β€” the new queue state. The possible states are single-letter values, as reported by qhost(1) with the -q option.

πŸ¦‹ queue_consumable πŸ¦‹

A queue_consumable record contains information about queue consumable values in addition to queue state information:

  • qname β€” the cluster queue name.
  • hostname β€” the hostname of a specific queue instance.
  • report_time β€” the time when a state change was triggered.
  • state β€” the new queue state.
  • consumables β€” description of consumable values. Information about multiple consumables is separated by space. A consumable description has the format name=actual_value=configured_value.
Consumables are only logged if log_consumables=true is specified in the sge_conf(5) reporting_params, or the consumable is specified in the local or global host_conf(5) report_variables.

πŸ’» host πŸ’»

A host record contains information about hosts and host load values. It contains the following information:

  • hostname β€” the name of the host.
  • report_time β€” the time when the reported information was generated.
  • state β€” the new host state. Currently, Grid Engine doesn't track a host state; the field is reserved for future use. Always contains the value X.
  • load values β€” description of load values. Information about multiple load values is separated by space. A load value description has the format name=actual_value.

πŸ“ host_consumable πŸ“

A host_consumable record contains information about hosts and host consumables. Host consumables can, for example, be licenses. It contains the following information:

  • hostname β€” the name of the host.
  • report_time β€” the time when the reported information was generated.
  • state β€” the new host state. Currently, Grid Engine doesn't track a host state; the field is reserved for future use. Always contains the value X.
  • consumables β€” description of consumable values. Information about multiple consumables is separated by space. A consumable description has the format name=actual_value=configured_value.
Consumables are only logged if log_consumables=true is specified in the sge_conf(5) reporting_params, or the consumable is specified in the local or global host_conf(5) report_variables.

πŸ‘‘ sharelog πŸ‘‘

The Grid Engine qmaster can dump information about sharetree configuration and use to the reporting file. The sge_conf(5) reporting_params can specify sharelog, which sets an interval in which sharetree information will be dumped. It is set in the format HH:MM:SS. A value of 00:00:00 configures qmaster not to dump sharetree information. Intervals of several minutes up to hours are sensible values for this parameter. The record contains the following fields:

  • current time β€” the present time.
  • usage time β€” the time used so far.
  • node name β€” the node name.
  • user name β€” the user name.
  • project name β€” the project name.
  • shares β€” the total shares.
  • job count β€” the job count.
  • level β€” the percentage of shares used.
  • total β€” the adjusted percentage of shares used.
  • long target share β€” the long target percentage of resource shares used.
  • short target share β€” the short target percentage of resource shares used.
  • actual share β€” the actual percentage of resource shares used.
  • usage β€” the combined shares used.
  • cpu β€” the number of CPU seconds used.
  • mem β€” the time integral of memory used (in GB seconds).
  • io β€” the IO done (in GB).
  • long target cpu β€” the long target cpu used.
  • long target mem β€” the long target memory used.
  • long target io β€” the long target IO used.

✨ new_ar ✨

A new_ar record contains information about advance reservation objects. Entries of this type will be added if an advance reservation is created. It contains the following information:

  • submission_time β€” the time when the advance reservation was created.
  • ar_number β€” the advance reservation number identifying the reservation.
  • ar_owner β€” the owner of the advance reservation.

πŸ’œ ar_attribute πŸ’œ

The ar_attribute record is written whenever a new advance reservation was added or the attribute of an existing advance reservation has changed. It has the following fields.

  • event_time β€” the time when the event was generated.
  • submission_time β€” the time when the advance reservation was created.
  • ar_number β€” the advance reservation number identifying the reservation.
  • ar_name β€” name of the advance reservation.
  • ar_account β€” an account string which was specified during the creation of the advance reservation.
  • ar_start_time β€” start time.
  • ar_end_time β€” end time.
  • ar_granted_pe β€” the parallel environment which was selected for an advance reservation.
  • ar_granted_resources β€” the granted resources which were selected for an advance reservation.

πŸ”₯ ar_log πŸ”₯

The ar_log record is written whenever an advance reservation changes status. A status change can be from pending to active, but can also be triggered by system events like host outage. It has the following fields.

  • ar_state_change_time β€” the time when the event occurred which caused a state change.
  • submission_time β€” the time when the advance reservation was created.
  • ar_number β€” the advance reservation number identifying the reservation.
  • ar_state β€” the new state.
  • ar_event β€” an event id identifying the event which caused the state change.
  • ar_message β€” a message describing the event which caused the state change.

πŸ’Έ ar_acct πŸ’Έ

The ar_acct records are accounting records which are written for every queue instance whenever an advance reservation terminates. Advance reservation accounting records comprise following fields.

  • ar_termination_time β€” the time when the advance reservation terminated.
  • submission_time β€” the time when the advance reservation was created.
  • ar_number β€” the advance reservation number identifying the reservation.
  • ar_qname β€” cluster queue name which the advance reservation reserved.
  • ar_hostname β€” the name of the execution host.
  • ar_slots β€” the number of slots which were reserved.

πŸ“‚ FILES πŸ“‚

  • $SGE_ROOT/$SGE_CELL/common/reporting

πŸ‘€ SEE ALSO πŸ‘€

okay bestie, legal era, let's get into it πŸŽ€

the full ✨statement of rights and permissions✨ lives in sge_intro(1), so if you're the type who actually reads the fine print (iconic of you, honestly πŸ‘‘), that's where you go. everything you'd wanna know about who owns what, who can do what, and all the permissions lore is right there in that page.

no cap, this is the part where you go check sge_intro(1) instead of asking me to summarise the legal stuff. i'm a vibe, not a lawyer πŸ’…

and that's a wrap on REPORTING(5), bestie!! πŸ¦‹ you made it all the way to the end, main character energy fr fr 🌈 this lil page is from SGE 8.1.3pre, dated 2011-05-08 β€” yeah she's an elder but she still ate πŸ’– go forth and report responsibly, mwah 🫢✨