Execution flow

Every five minutes, the CPU, RAM, and disk timer reads system percentages and creates missing report records with defaults of active status, 30-day retention, a 90 percent upper threshold, email enabled, and a 10-minute delay. On the main server, the MSSQL timer checks connections every five minutes. An alert opens when a measurement is greater than the upper threshold or less than or equal to the lower threshold; the alert closes when the value returns to normal.

Description

Activation status of the report definition. List services read this value and display it in the interface. However, the examined CPU, RAM, disk, and MSSQL timer flows do not check this field before executing a report. Therefore, selecting passive currently does not stop measurement, log, or alert generation; it only marks the record as passive.

Options

Example

Description

Readable name of the monitored resource. When CPU, RAM, and disk records are created automatically, the names “main server cpu”, “main server ram”, and “main server disk” are used respectively. Because the name entered for an MSSQL record is carried into the log label and the subject and body of alert emails, a name that distinguishes the failing connection should be selected.

Example

Description

Specifies the resource measured by the record. CPU, RAM, and disk values are obtained as percentages from psutil system information; if the disk percentage is unavailable, usage of the root file system is calculated. For the MSSQL connection type, the domain is used when present, otherwise the IP is used, up to two connection attempts are made, and the result is recorded as 1 for success and 0 for failure. Code note: the MSSQL timer reads parameter index 3, the log retention field, instead of index 2 when selecting records; consequently, a normal MSSQL definition may not be checked automatically by the current code.

Options

Example

Description

Carries the requested number of days for retaining report logs, and automatically created records default to 30 days. The MSSQL add and update screens save this value. However, the examined report module contains no flow that deletes report logs according to this field; retention of daily application logs is managed through a separate system variable. In addition, because of an index error in the MSSQL timer, this field is incorrectly read as the report type; the MSSQL checking branch is not entered unless the value is 3.

Example

Description

Server IP address used for the MSSQL connection. When the domain field is empty, this value is selected as the connection target. Although the new MSSQL report modal is visually enabled when either an IP or a domain is present, an additional check in the confirmation method prevents submission when IP is empty, so IP is effectively required when creating a record through the current interface.

Example

Description

Connection port of the MSSQL server. When populated, it is passed to the pymssql connection as a separate port parameter; when empty, the driver’s default connection behavior is used. For example, 1433 can be entered for a standard MSSQL installation.

Example

Description

Server name or domain information for the MSSQL connection. When populated, the code uses the domain value as the preferred connection target instead of the IP. The code attempts to support named MSSQL instance formats by converting the stored “____” and “__” sequences into backslashes.

Example

Description

Username passed to the pymssql driver for authentication to the MSSQL connection. An incorrect or unauthorized username causes both connection attempts to fail, produces a log value of 0, and opens an alert when the lower threshold is configured accordingly.

Example

Description

Connection password of the MSSQL user account, passed directly to the pymssql driver. An incorrect password causes the connection to fail. The field is masked as a password input in the interface, but because it is stored as a value in the WDMR record, access rights and record-viewing permissions should be restricted carefully.

Example

Description

Upper alert threshold for the measured numeric value. An alert opens when the current value is strictly greater than this threshold; equality does not create an upper-threshold alert. Automatically created CPU, RAM, and disk records use 90 as the default upper threshold and leave the lower threshold empty. For example, an alert opens when the value is 91 and the upper threshold is 90.

Example

Description

Lower alert threshold for the measured numeric value. If the upper threshold has not been exceeded, an alert opens when the current value is less than or equal to this threshold. Because a failed MSSQL connection produces 0 and the default lower threshold is 0, a connection failure creates an alert; the successful connection value of 1 closes it.

Example

Description

Determines whether an email is sent for an open alert. If no is selected, an alert record is still created and updated when a threshold is violated, but no email is sent. If yes is selected and the alert remains open after the waiting period in parameter 12, one email per alert episode is sent on a subsequent checking cycle using SMTP information from system variables and the Wamserver application recipient list first, or the general recipient list otherwise.

Options

Example

Description

Defines the minimum number of minutes to wait after an alert opens before sending email. The duration is calculated from the alert creation date; the update date advances only to track that the alert continues. No email is sent on the first threshold violation. If the alert is still open in a subsequent five-minute checking cycle, the elapsed duration has reached this value, and no email has previously been sent, the email is sent. The default value is 10 minutes.

Example

Generation and retrieval flow

CPU, RAM, disk, and MSSQL measurements are appended to one daily record formed from the resource identifier and the day. On every cycle, the UTC time label and numeric value are written to parallel lists and the update date advances. A date-range query produces the client identifier for every day, sorts the daily records found, and the frontend converts them into chart data.

Description

Activation field of the log record. However, this parameter is not written when a daily log record is created, and the log retrieval service does not filter by status. Therefore, in the current automatic flow, selecting passive or active has no verified effect on record generation, listing, or chart rendering.

Options

Example

Description

Resource label of the daily log record. Main-server resource labels are written for CPU, RAM, and disk, while the name from the parent report definition is written for MSSQL. Because the same text is also placed in the record-level label field, this value appears as the chart heading in the frontend.

Example

Description

Determines which presentation branch the frontend uses for the record. Automatic Wamserver log generation always creates this field with value 0 for chart, causing the record to be processed as a time-series chart rather than a total-count or single-percent card.

Options

Example

Description

Encodes the measurement series to which the log belongs. Values 0, 1, 2, and 3 are written for CPU, RAM, disk, and MSSQL connection checks respectively. This field is derived from the resource type when the record is created; the log retrieval service finds records by date and parent report identifier and does not additionally filter this field.

Options

Example

Description

Exists in the schema to define how many of the latest measurements should be displayed on the chart. The examined automatic record generation does not write this field and the AnalyzeReportView component does not read it; the component uses its own fixed max_show_point value of 50 at initialization.

Example

Description

Expresses whether the chart should be displayed from a prepared figure or drawn from data lists. Automatic log generation writes value 1 for draw chart by data. However, the current AnalyzeReportView directly uses data lists 9 and 11 without checking field 5, so the selection does not currently change frontend behavior.

Options

Example

Description

Number displayed in the frontend card when report type is total count. Automatic CPU, RAM, disk, and MSSQL log generation configures the report type as chart and therefore does not write this field; it is used only if another producer creates a total-count report.

Example

Description

Single percentage value displayed in the frontend card when report type is percent. Automatic resource logs append percentages to time-series value parameter 14 inside list 13 rather than to this field; consequently, this field remains empty in standard Wamserver daily logs.

Example

Description

Selects the chart component used to render the time series. Automatic logs create the value as 0 for bar. The frontend rendering branch uses numeric values 0–3, but its style calculation compares against the words bar, line, doughnut, and pie, so sizing styles may not be applied. In addition, the doughnut tag is malformed and its component is not imported, while the pie selection invokes the bar component.

Options

Example

Description

Ordered list that stores labels for the horizontal chart axis. For every measurement, the current UTC hour and minute in HH:MM format is appended to child field 10. A measurement is appended to the value list in field 14 at the same time, so matching order and length between the two lists preserves the correct time-to-value relationship in the chart.

Example

Description

Individual time label inside the label list in parameter 9. The system writes the UTC time in HH:MM format on each cycle. Because records are separated by day, this field contains no date; the date is derived from the YYYY-MM-DD portion of the log record client identifier.

Example

Description

List containing data series to be drawn in the chart. When an automatic Wamserver log is first created, one dataset is opened; its caption in field 12 is “%” or “connection” according to the resource, and measurements are appended to child list 13. The frontend produces a separate data and color array for each dataset.

Example

Description

Visible series name of the dataset in the chart. A percent sign is written for CPU, RAM, and disk records, while “connection” is written for an MSSQL connection record. The frontend transfers this value to the Chart.js dataset label field.

Example

Description

Ordered list of measurement points within a dataset. On every timer cycle, the value in field 14 and color in field 15 are appended together. Because the order of this list is kept aligned with the time-label list in parameter 9, the frontend builds the chart by matching identical indexes.

Example

Description

Numeric value of one measurement point. CPU, RAM, and disk store usage percentages; MSSQL stores 1 for a successful connection and 0 for a failed connection. The frontend converts the value with parseFloat before adding it to the chart.

Example

Description

Chart color of one measurement point. Current automatic generation writes the fixed value rgb(163, 1, 83) for all CPU, RAM, disk, and MSSQL points. The frontend appends this value to the dataset backgroundColor array in the same order.

Example

Description

Schema field defining whether point colors are selected automatically or manually. Automatic log generation writes value 1 for manual and appends the fixed color in field 15 to every point. AnalyzeReportView does not separately inspect field 16; current behavior directly reads the colors in field 15.

Options

Example

Description

Defined to carry name-and-color-value mappings for chart labels. Automatic Wamserver log generation does not create this list and AnalyzeReportView does not read field 17 while preparing the chart; it is not actively used in the standard flow.

Example

Description

Name field in a chart-label color mapping. Although presented as part of list 17 in the parameter list, the WDM structure also defines it under measurement-point list 13. The examined producer and Wamserver chart view neither write nor read this field.

Example

Description

Color value in a chart-label color mapping. In standard daily log generation, color is written directly to measurement color field 15, so this field remains empty and is not used by the current Wamserver view.

Example

Description

List defined to store pre-generated chart images with a caption and base64 content. Automatic log generation uses the data-list display type and therefore does not produce this field; the current AnalyzeReportView does not read prepared figures either.

Example

Description

Image caption within the prepared-figure list in parameter 20. Because standard Wamserver report logs do not generate prepared figures, it is not populated automatically and is not displayed by the current report screen.

Example

Description

Base64-encoded image content within the prepared-figure list in parameter 20. The current reporter draws charts in the browser from data lists and therefore does not write an image to this field; adding large image content is not part of the standard flow.

Example

Description

UTC date and time at which the latest measurement was appended to the daily log record. It is assigned when a new record is created and updated whenever a new value is appended. This field does not give the time of each individual measurement; point times are stored in field 10 and the record date is held in the client identifier.

Example

Alert lifecycle

On the first threshold violation, an active alert with email not sent is opened. While the violation continues, the update date of the same alert advances without creating a new record. If the email conditions on the parent report are met and sending succeeds, mail status changes to yes. When the value returns to the normal range, the alert becomes passive and its end date is written; a later new violation creates a separate alert episode.

Description

Shows whether the alert episode is still open. When the measured value is greater than the upper threshold or less than or equal to the lower threshold, a new active record is created if there is no previous alert or the latest alert is closed. The same active record is updated while the violation continues; when the value returns to the normal range, the record is made passive and its end date is written. The active-alert service returns only records whose value is 1.

Options

Example

Description

UTC date and time when the alert episode first opened. The current time is written on the first threshold violation and is not changed while the same alert remains open. Because the email waiting duration is calculated from this creation date rather than the update date, it is the starting point used to determine how long the alert has continued without interruption.

Example

Description

UTC date and time when the alert record was last processed. It is initially written with the same value as the creation date; on every checking cycle while the violation continues, it advances to the current time whether or not an email is sent. It is also updated one final time when the alert closes. This field is not used to calculate the email delay.

Example

Description

UTC date and time when the alert episode closed. It is left empty when a new alert is created. When the measured value returns to the normal range, the status is made passive and the same current time is written to this field and the update date. Therefore, an empty value indicates that the alert has not yet closed, while a populated value indicates that the episode has completed.

Example

Description

Shows whether an email was successfully sent for this alert episode. A new alert opens with no, and no email is sent on the first violation. If email sending is enabled on the parent report, the delay measured from the creation date has elapsed, and the alert is still active in a subsequent checking cycle, sending is attempted. The field changes to yes only when SendMail returns success, preventing a second email until the same alert closes. If sending fails, the field remains no and can be retried in later cycles.

Options

Example