Documentation
¶
Index ¶
Constants ¶
This section is empty.
Variables ¶
This section is empty.
Functions ¶
This section is empty.
Types ¶
type AuthorizedWriters ¶
type AuthorizedWriters struct {
// An array of team IDs that have write access to this object
Teams []string `json:"teams,omitempty"`
// An array of user IDs that have write access to this object
Users []string `json:"users,omitempty"`
}
If your organization has the \"write permissions\" feature enabled, you can use this object to specify the user and team IDs that have write access to the object you're specifying.
type CreateUpdateDetectorRequest ¶
type CreateUpdateDetectorRequest struct {
AuthorizedWriters *AuthorizedWriters `json:"authorizedWriters,omitempty"`
// User-defined JSON object containing metadata
CustomProperties string `json:"customProperties,omitempty"`
// Description of the detector. It appears in the Detector window displayed from the web UI Actions menu
Description string `json:"description,omitempty"`
// The number of milliseconds to wait for late datapoints before rejecting them for inclusion in the detector analysis. The default is to detect and apply a sensible value automatically (this option can also be explicitly chosen by setting the property to 0).
MaxDelay *int32 `json:"maxDelay,omitempty"`
// The displayed name of the detector in the dashboard
Name string `json:"name,omitempty"`
// The SignalFlow program that populates the detector. The program must include one or more detect functions and each detect function must be modified by a publish stream method with a label that's unique across the program. If you wish to support custom notification messages that include input data you must use variables to assign the detect conditions . If more than one line of SignalFlow is included, each line should be separated by either semicolons (\";\") or new line characters (\"\\n\"). See the [Detectors Overview](https://developers.signalfx.com/v2/reference.html#detectors-overview) for more information.
ProgramText string `json:"programText,omitempty"`
// An array of *rules* that define aspects of an alert. These include the alert\\'s severity and the specification of how notifications are sent when the alert is triggered. Each rule is connected to a specific detect function in the programText property by the value of the label in its publish method. The connection is to a set of one or more notification directives and an severity indicator. A single condition can be used in multiple rules if different severity indicators are desired for different notification methods. <p> To see the properties for a rule, expand the definition of the rules array. What you see is the \"rules\" object that specifies a single rule.
Rules []*Rule `json:"rules,omitempty"`
// A an array of keywords that filters detectors by one of their fields. Use tags to indicate the state of a detector or its data source (for example, you can label a detector with a \"prod\" tag to indicate that it monitors a production environment).
Tags []string `json:"tags,omitempty"`
// IDs of teams associated with this detector. Teams associated with a detector can see the detector and its active alerts on the team's landing page in the web UI. The list of teams associated with a detector is independent of notification settings. Teams specified in this field don\\'\\'t automatically get notified of new alerts, and teams that choose to get alerts do not have to display the detector on their team landing page in the web application.
Teams []string `json:"teams,omitempty"`
// Options that control the appearance of a detector in the SignalFx web UI.
VisualizationOptions *Visualization `json:"visualizationOptions,omitempty"`
}
type Detector ¶
type Detector struct {
AuthorizedWriters *AuthorizedWriters `json:"authorizedWriters,omitempty"`
// The time the detector was created in milliseconds (UTC); this corresponds to the receipt of the first request to send an invitation to this email address. This value is always set by the system.
Created int64 `json:"created,omitempty"`
// User ID of the initial creator
Creator string `json:"creator,omitempty"`
// User-defined JSON object containing metadata
CustomProperties *interface{} `json:"customProperties,omitempty"`
// Description of the detector. It appears in the Detector window displayed from the web UI Actions menu
Description string `json:"description,omitempty"`
// System-defined identifier for the detector
Id string `json:"id,omitempty"`
LabelResolution LabelResolution `json:"labelResolution,omitempty"`
// The last time the detector was updated, in milliseconds (UTC) relative to the Unix epoch.
LastUpdated int64 `json:"lastUpdated,omitempty"`
// The user ID of the last person who updated the object. If the last update was by the system, the value is \"AAAAAAAAAA\" This value is always set by the system.
LastUpdatedBy string `json:"lastUpdatedBy,omitempty"`
// Detector modification state. If `true`, the detector can't be modified in anyway; otherwise, anyone can edit it.
Locked bool `json:"locked,omitempty"`
// The number of milliseconds to wait for late datapoints before rejecting them for inclusion in the detector analysis. The default is to detect and apply a sensible value automatically (this option can also be explicitly chosen by setting the property to 0).
MaxDelay *int32 `json:"maxDelay,omitempty"`
// The displayed name of the detector in the dashboard
Name string `json:"name,omitempty"`
// If true one, or more statements in the detector matched too many time series and the matched set was forcefully limited. In this case, the detector is most likely looking at incomplete data or an incomplete aggregation. If this flag is set to true, you can use a series of partition_filter functions to split the data set into manageable pieces then use the union function to rejoin the results in a subsequent computation. Note that the union function still observes the time series limit; some type of aggregation on the partial streams must limit the data set prior to recombining the streams for this approach to work.
OverMTSLimit bool `json:"overMTSLimit,omitempty"`
// The SignalFlow program that populates the detector. The program must include one or more detect functions and each detect function must be modified by a publish stream method with a label that's unique across the program. If you wish to support custom notification messages that include input data you must use variables to assign the detect conditions . If more than one line of SignalFlow is included, each line should be separated by either semicolons (\";\") or new line characters (\"\\n\"). See the [Detectors Overview](https://developers.signalfx.com/v2/reference.html#detectors-overview) for more information.
ProgramText string `json:"programText,omitempty"`
Rules []*Rule `json:"rules,omitempty"`
// A an array of keywords that filters detectors by one of their fields. Use tags to indicate the state of a detector or its data source (for example, you can label a detector with a \"prod\" tag to indicate that it monitors a production environment).
Tags []string `json:"tags,omitempty"`
// IDs of teams associated with this detector. Teams associated with a detector can see the detector and its active alerts on the team's landing page in the web UI. The list of teams associated with a detector is independent of notification settings. Teams specified in this field don\\'\\'t automatically get notified of new alerts, and teams that choose to get alerts do not have to display the detector on their team landing page in the web application.
Teams []string `json:"teams,omitempty"`
// Options that control the appearance of a detector in the SignalFx web UI.
VisualizationOptions *Visualization `json:"visualizationOptions,omitempty"`
}
type LabelResolution ¶
type LabelResolution struct {
// The alert resolution time for the SignalFlow publish statement labeled with the value `label`.
Label string `json:"label,omitempty"`
}
Indicates how often data is analyzed to determine if an alert should be triggered. This is different from the data display resolution used to populate the detector visualization. The data display resolution is automatically set to the coarsest resolution of all of the publish statements associated with the detector, since they are all displayed together in the same visualization.<br> In the object, the label name of each publish statement in the detector is the property key, and the time is the value. For example, to refer to the label resolution of the publish statement with the label *DetectorStatement*, specify `results[index].labelResolution.DetectorStatement`.
type Rule ¶
type Rule struct {
// A description for the rule. Displays as the alert condition in the Alert Rules tab of the detector editor.
Description string `json:"description,omitempty"`
// The label of the publish statement associated with the detect function associated with this rule.
DetectLabel string `json:"detectLabel,omitempty"`
// Indicates whether the associated rule is turned on and being evaluated (false) or is currently turned off and will not fire even if the specified conditions are met (true).
Disabled bool `json:"disabled,omitempty"`
// Array of notification objects to send when the rule is triggered. You can specify more than one object, and each object can be of a different type.<br> To send email notifications:<br> * For one or more individual users, use \"type\": \"Email\" * For one or more entire SignalFx teams, use \"type\": \"TeamEmail\" * For one or more members of a single team, use \"type\": \"Team\" * For one or more members of multiple teams, use \"type\": \"TeamEmail\" <br> * To send emails to a team, the team must already exist. * To send email to specific members of a team, the team must already exist, and you must specify the team members who will receive emails.
Notifications []*notification.Notification `json:"notifications,omitempty"`
// Custom notification message *body* for this rule. The message is displayed when the alert is triggered. The content is plain text. Escape quote characters with a backslash, and indicate a newline with the \"\\n\" string. To insert a SignalFx variable value, specify its name in curly brackets. Double curly brackets (\"{{ }}\") specify a variable that's inserted in place, but some characters in the result may trigger unintended results in SignalFx or the notification server. Triple curly brackets specify a variable that SignalFx escapes as needed so that characters such as quotation marks and angle brackets render properly in notification messages. If you\\'re unsure which style of variable to use, use triple braces, so that all content renders properly. SignalFx does provide recommendations for the notation style to use with each supported variable. For more information see the custom notification messages section of the [Detectors Overview](https://developers.signalfx.com/v2/reference.html#detectors-overview). A full list of available variables with their default notation recommendation is available in the [Message variables](https://docs.signalfx.com/en/latest/detect-alert/set-up-detectors.html#message-variables) section of the \"Set Up Detectors\" topic in the SignalFx User Guide.
ParameterizedBody string `json:"parameterizedBody,omitempty"`
// Custom notification message *subject* for this rule. The message is displayed when the alert is triggered. The content is plain text. Escape quote characters with a backslash, and indicate a newline with the \"\\n\" string. To insert a SignalFx variable value, specify its name in curly brackets. Double curly brackets (\"{{ }}\") specify a variable that's inserted in place, but some characters in the result may trigger unintended results in SignalFx or the notification server. Triple curly brackets specify a variable that SignalFx escapes as needed so that characters such as quotation marks and angle brackets render properly in notification messages. If you\\'re unsure which style of variable to use, use triple braces, so that all content renders properly. SignalFx does provide recommendations for the notation style to use with each supported variable. For more information see the custom notification messages section of the [Detectors Overview](https://developers.signalfx.com/v2/reference.html#detectors-overview). A full list of available variables with their default notation recommendation is available in the [Message variables](https://docs.signalfx.com/en/latest/detect-alert/set-up-detectors.html#message-variables) section of the \"Set Up Detectors\" topic in the SignalFx User Guide.
ParameterizedSubject string `json:"parameterizedSubject,omitempty"`
// URL that you can refer to with the SignalFx `{{runbookURL}}` variable in the `parameterizedBody` or `parameterizedSubject` field.
RunbookUrl string `json:"runbookUrl,omitempty"`
Severity Severity `json:"severity,omitempty"`
Tip string `json:"tip,omitempty"`
}
A single alert rule.
type SearchResults ¶
type SearchResults struct {
// Number of objects that match the search query. If you use paging, `count` is either the value of the `limit` request parameter or the number of objects still undelivered after the request reached the `offset` request parameter.<br> *Note:* If you use paging, count is not the number of objects returned in the response.
Count int32 `json:"count,omitempty"`
// An array of detector definitions that match the request criteria. Each definition is defined as a `Detector`.
Results []Detector `json:"results,omitempty"`
}
type Severity ¶
type Severity string
Severity : Indicates the severity of a triggered alert. You can assign your own semantics to each severity level. See the `Enum` description for the allowed values.<br> **NOTE:** These are enums, and you must enter them exactly as shown: First letter capitalized, all other letters lowercase. <br> The PagerDuty alerting service maps SignalFx severity values to PagerDuty service values, as follows (SignalFx values are at the beginning of the line): * Critical -> Critical * Major -> Critical * Minor -> Error * Warning -> Warning * Info -> Info
type Time ¶
type Time struct {
// The timestamp of the last time to display in the visualization specified in milliseconds since midnight UTC on January 1, 1970
End *int64 `json:"end,omitempty"`
// The number of milliseconds to display in the chart. The range used is a rolling range with the current time at the right border of the chart display. Use 0 to indicate using the default behavior; this corresponds to -15m for most metrics and -1h for AWS metrics listed here, GCP metrics listed here, and Azure metrics listed here.
Range *int64 `json:"range,omitempty"`
// The timestamp of the first time to display in the visualization specified in milliseconds since midnight UTC on January 1, 1970
Start *int64 `json:"start,omitempty"`
// Indicates whether to use an explicit time range or to always show a relative time of the last N milliseconds. If not specified, relative will be used.
Type string `json:"type,omitempty"`
}
Options for the time displayed in the detector visualization.
type ValidateDetectorRequestModel ¶
type ValidateDetectorRequestModel struct {
// User-defined JSON object containing metadata
CustomProperties string `json:"customProperties,omitempty"`
// Description of the detector. It appears in the Detector window displayed from the web UI Actions menu
Description string `json:"description,omitempty"`
// The number of milliseconds to wait for late datapoints before rejecting them for inclusion in the detector analysis. The default is to detect and apply a sensible value automatically (this option can also be explicitly chosen by setting the property to 0).
MaxDelay int32 `json:"maxDelay,omitempty"`
// The displayed name of the detector in the dashboard
Name string `json:"name,omitempty"`
// The SignalFlow program that populates the detector. The program must include one or more detect functions and each detect function must be modified by a publish stream method with a label that's unique across the program. If you wish to support custom notification messages that include input data you must use variables to assign the detect conditions . If more than one line of SignalFlow is included, each line should be separated by either semicolons (\";\") or new line characters (\"\\n\"). See the [Detectors Overview](https://developers.signalfx.com/v2/reference.html#detectors-overview) for more information.
ProgramText string `json:"programText,omitempty"`
// An array of *rules* that define aspects of an alert. These include the alert\\'s severity and the specification of how notifications are sent when the alert is triggered. Each rule is connected to a specific detect function in the programText property by the value of the label in its publish method. The connection is to a set of one or more notification directives and an severity indicator. A single condition can be used in multiple rules if different severity indicators are desired for different notification methods. <p> To see the properties for a rule, expand the definition of the rules array. What you see is the \"rules\" object that specifies a single rule.
Rules []Rule `json:"rules,omitempty"`
// A an array of keywords that filters detectors by one of their fields. Use tags to indicate the state of a detector or its data source (for example, you can label a detector with a \"prod\" tag to indicate that it monitors a production environment).
Tags []string `json:"tags,omitempty"`
// IDs of teams associated with this detector. Teams associated with a detector can see the detector and its active alerts on the team's landing page in the web UI. The list of teams associated with a detector is independent of notification settings. Teams specified in this field don\\'\\'t automatically get notified of new alerts, and teams that choose to get alerts do not have to display the detector on their team landing page in the web application.
Teams []string `json:"teams,omitempty"`
// Options that control the appearance of a detector in the SignalFx web UI. Each element in the array is a 'Visualization'.
VisualizationOptions []Visualization `json:"visualizationOptions,omitempty"`
}
type Visualization ¶
type Visualization struct {
// If true, all data points are displayed; otherwise, data points are sampled. The latter option improves performance.
DisableSampling bool `json:"disableSampling,omitempty"`
// If true, markers are drawn for each datapoint in the visualization.
ShowDataMarkers bool `json:"showDataMarkers,omitempty"`
// If true, a vertical line is displayed on the visualization when an event is triggered.
ShowEventLines bool `json:"showEventLines,omitempty"`
Time *Time `json:"time,omitempty"`
}
Visualization options for a rule
Source Files
Click to show internal directories.
Click to hide internal directories.