npm - flashduty-knowledge-base - Versions diffs - 1.0.1 → 1.0.2 - Mend

flashduty-knowledge-base 1.0.1 → 1.0.2

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (3) hide show

package/dist/en.cjs CHANGED Viewed

@@ -51,42 +51,120 @@ Choose this method when you need to route alerts to different channels based on
 </details>
 </div>
-## Implementation Protocol
----
+## I. Request Description
-Please refer to the [Developer Documentation](https://developer.flashcat.cloud/zh/flashduty/event-api/alert-event) to complete the protocol development.
-## Best Practices
----
+### Request Method
-1. Send events to Flashduty when alert status changes
-2. When an alert recovers, send an event with status "Ok" to close the alert. Otherwise, the alert will remain open. If your alert system doesn't have recovery events, we recommend manually sending recovery events
-3. Labels are event descriptions. You should enrich label content as much as possible (specified when sending or generated through enrichment rules), such as:
-   - Alert source, like host, cluster, check, or metric
-   - Alert ownership information, like team, owner
-   - Alert category information, like class (api, db, net)
+POST, Content-Type:"application/json"
+### Request Parameters:
-## FAQ
----
+QueryString must include the integration_key parameter for access control.
-<details>
-  <summary>Why haven't I received alerts in Flashduty?</summary>
+JsonBody parameters are as follows:
-  #### In Flashduty
-  1. Check if the integration shows **Latest Event Time**? If not, Flashduty hasn't received the push, prioritize checking your system
-  2. If you're using **Shared Integration**, first confirm whether you've configured **Routing Rules**. Without routing rules, the system will reject new pushes since there's no channel to receive your alerts. In this case, simply configure routing rules to your desired channel
+|     Field     | Required |  Type  | Description                                                                                                                                                                                                                                    |
+| :----------: | :------: | :----: | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| event_status |   Yes    | string | Alert event status, enumerated values: Critical, Warning, Info, Ok                                                                                                                                                                               |
+|  alert_key   |   Yes    | string | Event grouping basis, different alert events are grouped into one alert based on this field and time window                                                                                                                                      |
+|  title_rule  |    No    | string | Alert title generation rule, in the form of \`$a::b::$c\`, substrings are separated by \`::\`; each substring can be a fixed string or a variable prefixed with \`$\`. Variable content will be extracted from the labels parameter, error if not found. By default, the system will generate rules by extracting service, cluster, resource, and check tags from the labels field |
+| description  |    No    | string | Alert description, no more than 2048 characters                                                                                                                                                                                                  |
+|    labels    |    No    |  map   | Alert label collection, key is the label name, value is the label value. Labels are event descriptions, crucial for subsequent correlation and noise reduction. 1. Label keys and values are case-sensitive strings. 2. Label keys should not exceed 128 characters. 3. Maximum 50 labels allowed. \`Label content reference\` [Best Practices](#Best-Practices) |
-  #### In Your System
+</div>
-  1. Confirm that your request URL exactly matches the URL in the integration details
-  2. Verify that your service can access the external domain api.flashcat.cloud. If not, you need to enable external network access for your server or specifically for the Flashduty domain
-  3. Print the response from the Flashduty service to check for specific messages
+### Response
-  If you still can't identify the root cause after these steps, please contact us with the **request_id** from the request response
+<div class="md-block">
+Body:
-</details>`,t=`---
+Parameter|Required|Type|Description
+----------|---|---|---
+request_id|Yes|string|Request trace id for issue tracking
+error|No|[Error](#Error)|Error description, returned only when an error occurs
+<span id="Error"></span>
+Error:
+| Parameter | Optional | Type   | Description     |
+| --------- | -------- | ------ | --------------- |
+| code      | Yes      | string | Error code      |
+| message   | Yes      | string | Error message   |
+<span id="Code"></span>
+Code:
+| Error Code           | HTTP Status | Description                                        |
+| -------------------- | ----------- | -------------------------------------------------- |
+| InvalidParameter     | 400         | Parameter error                                    |
+| InvalidContentType   | 400         | Content-Type not supported                         |
+| MethodNotAllowed     | 400         | HTTP method not supported                          |
+| Unauthorized         | 401         | Login authentication failed                        |
+| AccessDenied         | 403         | Permission authentication failed                   |
+| RequestTooFrequently | 429         | Request too frequent                               |
+| RouteNotFound        | 404         | Request Method+Path not matched                    |
+| ResourceNotFound     | 400         | Account resource not purchased, proceed to billing |
+| InternalError        | 500         | Internal or unknown error                          |
+</div>
+### Request Example
+Request:
+\`\`\`
+curl -X POST '{api_host}/event/push/alert/standard?integration_key=$key' \\
+-H 'Content-Type: application/json' \\
+-d '{
+    "event_status": "Warning",
+    "alert_key": "asdfjl1234asdf2s",
+    "description": "cpu idle low than 20%",
+    "title_rule": "$cluster::$resource::$check",
+    "labels": {
+        "service": "engine",
+        "cluster":"nj",
+        "resource":"es.nj.01",
+        "check":"cpu.idle<20%",
+        "metric":"node_cpu_seconds_total"
+    }
+}' -v
+\`\`\`
+Successful response:
+\`\`\`
+{
+    "request_id": "0ace00116215ab4ca0ec5244b8fc54b0"
+}
+\`\`\`
+Failed response:
+\`\`\`
+{
+    "request_id": "0ace00116215abc0ba4e52449bd305b0",
+    "error": {
+        "code": "InvalidParameter",
+        "message": "integration_key is not a valid one"
+    }
+}
+\`\`\`
+<span id="Best-Practices"></span>
+## II. Best Practices
+1. Send events to Flashcat Cloud when alert status changes or labels are updated
+2. When an alert recovers, send an event with status Ok to close the alert. Otherwise, the alert will remain open. If your alert system doesn't have recovery events, we recommend manually sending recovery events
+3. Labels are event descriptions. You should enrich label content as much as possible (specified when sending or generated through enrichment rules), such as:
+   - Alert source information: host, cluster, check, or metric
+   - Alert ownership information: team, owner
+   - Alert category information: class (api, db, net)
+   - Alert details link for jumping to the alert system
+4. alert_key is used to group different alert events into one alert. For example, when a host's cpu.idle drops below threshold, escalates, and recovers, you should send 3 events with the same alert_key, which will be grouped into one alert
+5. title_rule is used to generate alert display titles. It's recommended to include the source system alert name (commonly defined as rule_name or check) and add cluster, host, and other information as auxiliary reminders
+`,t=`---
 title: "Email Integration"
 description: "Generate a unique email address in Flashduty to synchronize alert triggers and recoveries through email"
 date: "2024-05-11T10:00:00+08:00"
@@ -689,14 +767,9 @@ Choose this method when you need to route alerts to different channels based on
 ## In Zabbix
 ---
-<<<<<<< HEAD
 - [7.x version](#v7)
 - [5.x~6.x version](#v5)
 - [3.x~4.x version](#v4)
-=======
-<div class="md-block">
->>>>>>> 798fffa6edf238347e9cac531eac2314fae21c18
 <span id="v7"></span>
@@ -4541,7 +4614,7 @@ Once published, you can access the application via mobile/PC client. First-time
     |Group Bot Webhook|Maximum 100 calls/minute|
     |Sending messages to the same user or group|Maximum 5 calls/second|
-    **Note:** Messages cannot be pushed normally when exceeding limits, please use notification channels reasonably`,O=`---
+    **Note:** Messages cannot be pushed normally when exceeding limits, please use notification channels reasonably`,q=`---
 title: "Dingtalk Integration"
 description: "Integrate with Dingtalk custom application to receive and respond to alerts within Dingtalk"
 date: "2024-05-11T10:00:00+08:00"
@@ -4697,7 +4770,7 @@ After the application is released, you can access it via mobile/PC client. First
 |Enterprise|5,500,000|60|1st of each month|
 **Note:** Messages cannot be pushed normally after exceeding limits, please use notification channels reasonably
-`,q=`---
+`,O=`---
 title: "WeCom Integration"
 description: "Integrate WeCom third-party application to receive and respond to alerts within WeCom"
 date: "2024-05-11T10:00:00+08:00"
@@ -6149,4 +6222,4 @@ If custom content is not set, the system default template will be used for notif
 As shown below:
 <img src="https://download.flashcat.cloud/flashduty/doc/en/fd/template-mail-1.png" width="800">
-`;exports.AWSCW=e;exports.AWSEventBridge=A;exports.AlertWebhook=H;exports.AliyunARMS=l;exports.AliyunCm=c;exports.AliyunCmEvent=d;exports.AliyunSLS=e;exports.AppDynamics=R;exports.AzureMonitor=h;exports.BaiDuBCM=u;exports.CustomAction=V;exports.CustomAlert=n;exports.CustomChange=W;exports.Dingtalk=O;exports.Dynatrace=L;exports.Email=t;exports.GoogleCM=F;exports.Grafana=o;exports.Graylog=k;exports.HuaWeiCES=g;exports.HuaweiyunLTS=x;exports.IncidentWebhook=B;exports.InfluxDB=p;exports.Jiankongbao=_;exports.Jira=G;exports.Lark=Y;exports.Meraki=N;exports.MicrosoftTeams=j;exports.N9e=a;exports.OceanBase=C;exports.OpManager=M;exports.OpenFalcon=m;exports.PagerDuty=f;exports.Prometheus=i;exports.Sentry=S;exports.Skywalking=I;exports.Slack=$;exports.SolarWinds=U;exports.Splunk=T;exports.Templates=z;exports.TencentBK=y;exports.TencentCLS=v;exports.TencentCm=b;exports.TencentEb=w;exports.UptimeKuma=r;exports.VolcEngineEvent=D;exports.VolcEngineMetric=E;exports.VolcEngineTLS=P;exports.Wecom=q;exports.Zabbix=s;
+`;exports.AWSCW=e;exports.AWSEventBridge=A;exports.AlertWebhook=H;exports.AliyunARMS=l;exports.AliyunCm=c;exports.AliyunCmEvent=d;exports.AliyunSLS=e;exports.AppDynamics=R;exports.AzureMonitor=h;exports.BaiDuBCM=u;exports.CustomAction=V;exports.CustomAlert=n;exports.CustomChange=W;exports.Dingtalk=q;exports.Dynatrace=L;exports.Email=t;exports.GoogleCM=F;exports.Grafana=o;exports.Graylog=k;exports.HuaWeiCES=g;exports.HuaweiyunLTS=x;exports.IncidentWebhook=B;exports.InfluxDB=p;exports.Jiankongbao=_;exports.Jira=G;exports.Lark=Y;exports.Meraki=N;exports.MicrosoftTeams=j;exports.N9e=a;exports.OceanBase=C;exports.OpManager=M;exports.OpenFalcon=m;exports.PagerDuty=f;exports.Prometheus=i;exports.Sentry=S;exports.Skywalking=I;exports.Slack=$;exports.SolarWinds=U;exports.Splunk=T;exports.Templates=z;exports.TencentBK=y;exports.TencentCLS=v;exports.TencentCm=b;exports.TencentEb=w;exports.UptimeKuma=r;exports.VolcEngineEvent=D;exports.VolcEngineMetric=E;exports.VolcEngineTLS=P;exports.Wecom=O;exports.Zabbix=s;

package/dist/en.js CHANGED Viewed

@@ -51,42 +51,120 @@ Choose this method when you need to route alerts to different channels based on
 </details>
 </div>
-## Implementation Protocol
----
+## I. Request Description
-Please refer to the [Developer Documentation](https://developer.flashcat.cloud/zh/flashduty/event-api/alert-event) to complete the protocol development.
-## Best Practices
----
+### Request Method
-1. Send events to Flashduty when alert status changes
-2. When an alert recovers, send an event with status "Ok" to close the alert. Otherwise, the alert will remain open. If your alert system doesn't have recovery events, we recommend manually sending recovery events
-3. Labels are event descriptions. You should enrich label content as much as possible (specified when sending or generated through enrichment rules), such as:
-   - Alert source, like host, cluster, check, or metric
-   - Alert ownership information, like team, owner
-   - Alert category information, like class (api, db, net)
+POST, Content-Type:"application/json"
+### Request Parameters:
-## FAQ
----
+QueryString must include the integration_key parameter for access control.
-<details>
-  <summary>Why haven't I received alerts in Flashduty?</summary>
+JsonBody parameters are as follows:
-  #### In Flashduty
-  1. Check if the integration shows **Latest Event Time**? If not, Flashduty hasn't received the push, prioritize checking your system
-  2. If you're using **Shared Integration**, first confirm whether you've configured **Routing Rules**. Without routing rules, the system will reject new pushes since there's no channel to receive your alerts. In this case, simply configure routing rules to your desired channel
+|     Field     | Required |  Type  | Description                                                                                                                                                                                                                                    |
+| :----------: | :------: | :----: | :--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| event_status |   Yes    | string | Alert event status, enumerated values: Critical, Warning, Info, Ok                                                                                                                                                                               |
+|  alert_key   |   Yes    | string | Event grouping basis, different alert events are grouped into one alert based on this field and time window                                                                                                                                      |
+|  title_rule  |    No    | string | Alert title generation rule, in the form of \`$a::b::$c\`, substrings are separated by \`::\`; each substring can be a fixed string or a variable prefixed with \`$\`. Variable content will be extracted from the labels parameter, error if not found. By default, the system will generate rules by extracting service, cluster, resource, and check tags from the labels field |
+| description  |    No    | string | Alert description, no more than 2048 characters                                                                                                                                                                                                  |
+|    labels    |    No    |  map   | Alert label collection, key is the label name, value is the label value. Labels are event descriptions, crucial for subsequent correlation and noise reduction. 1. Label keys and values are case-sensitive strings. 2. Label keys should not exceed 128 characters. 3. Maximum 50 labels allowed. \`Label content reference\` [Best Practices](#Best-Practices) |
-  #### In Your System
+</div>
-  1. Confirm that your request URL exactly matches the URL in the integration details
-  2. Verify that your service can access the external domain api.flashcat.cloud. If not, you need to enable external network access for your server or specifically for the Flashduty domain
-  3. Print the response from the Flashduty service to check for specific messages
+### Response
-  If you still can't identify the root cause after these steps, please contact us with the **request_id** from the request response
+<div class="md-block">
+Body:
-</details>`, n = `---
+Parameter|Required|Type|Description
+----------|---|---|---
+request_id|Yes|string|Request trace id for issue tracking
+error|No|[Error](#Error)|Error description, returned only when an error occurs
+<span id="Error"></span>
+Error:
+| Parameter | Optional | Type   | Description     |
+| --------- | -------- | ------ | --------------- |
+| code      | Yes      | string | Error code      |
+| message   | Yes      | string | Error message   |
+<span id="Code"></span>
+Code:
+| Error Code           | HTTP Status | Description                                        |
+| -------------------- | ----------- | -------------------------------------------------- |
+| InvalidParameter     | 400         | Parameter error                                    |
+| InvalidContentType   | 400         | Content-Type not supported                         |
+| MethodNotAllowed     | 400         | HTTP method not supported                          |
+| Unauthorized         | 401         | Login authentication failed                        |
+| AccessDenied         | 403         | Permission authentication failed                   |
+| RequestTooFrequently | 429         | Request too frequent                               |
+| RouteNotFound        | 404         | Request Method+Path not matched                    |
+| ResourceNotFound     | 400         | Account resource not purchased, proceed to billing |
+| InternalError        | 500         | Internal or unknown error                          |
+</div>
+### Request Example
+Request:
+\`\`\`
+curl -X POST '{api_host}/event/push/alert/standard?integration_key=$key' \\
+-H 'Content-Type: application/json' \\
+-d '{
+    "event_status": "Warning",
+    "alert_key": "asdfjl1234asdf2s",
+    "description": "cpu idle low than 20%",
+    "title_rule": "$cluster::$resource::$check",
+    "labels": {
+        "service": "engine",
+        "cluster":"nj",
+        "resource":"es.nj.01",
+        "check":"cpu.idle<20%",
+        "metric":"node_cpu_seconds_total"
+    }
+}' -v
+\`\`\`
+Successful response:
+\`\`\`
+{
+    "request_id": "0ace00116215ab4ca0ec5244b8fc54b0"
+}
+\`\`\`
+Failed response:
+\`\`\`
+{
+    "request_id": "0ace00116215abc0ba4e52449bd305b0",
+    "error": {
+        "code": "InvalidParameter",
+        "message": "integration_key is not a valid one"
+    }
+}
+\`\`\`
+<span id="Best-Practices"></span>
+## II. Best Practices
+1. Send events to Flashcat Cloud when alert status changes or labels are updated
+2. When an alert recovers, send an event with status Ok to close the alert. Otherwise, the alert will remain open. If your alert system doesn't have recovery events, we recommend manually sending recovery events
+3. Labels are event descriptions. You should enrich label content as much as possible (specified when sending or generated through enrichment rules), such as:
+   - Alert source information: host, cluster, check, or metric
+   - Alert ownership information: team, owner
+   - Alert category information: class (api, db, net)
+   - Alert details link for jumping to the alert system
+4. alert_key is used to group different alert events into one alert. For example, when a host's cpu.idle drops below threshold, escalates, and recovers, you should send 3 events with the same alert_key, which will be grouped into one alert
+5. title_rule is used to generate alert display titles. It's recommended to include the source system alert name (commonly defined as rule_name or check) and add cluster, host, and other information as auxiliary reminders
+`, n = `---
 title: "Email Integration"
 description: "Generate a unique email address in Flashduty to synchronize alert triggers and recoveries through email"
 date: "2024-05-11T10:00:00+08:00"
@@ -689,14 +767,9 @@ Choose this method when you need to route alerts to different channels based on
 ## In Zabbix
 ---
-<<<<<<< HEAD
 - [7.x version](#v7)
 - [5.x~6.x version](#v5)
 - [3.x~4.x version](#v4)
-=======
-<div class="md-block">
->>>>>>> 798fffa6edf238347e9cac531eac2314fae21c18
 <span id="v7"></span>
@@ -4069,7 +4142,7 @@ Choose this method when you need to route alerts to different channels based on
 </div>
 </div>
-`, M = `---
+`, N = `---
 title: "OpManager Alert Events"
 description: "Sync OpManager alert events to Flashduty via webhook for automated alert noise reduction"
 date: "2024-07-05T10:00:00+08:00"
@@ -4203,7 +4276,7 @@ Choose this method when you need to route alerts to different channels based on
 | Attention  | Info           | Info |
 </div>
-`, N = `---
+`, M = `---
 title: "Meraki Alert Events"
 description: "Sync Meraki alert events to Flashduty via webhook for automated alert noise reduction"
 date: "2024-07-05T10:00:00+08:00"
@@ -4541,7 +4614,7 @@ Once published, you can access the application via mobile/PC client. First-time
     |Group Bot Webhook|Maximum 100 calls/minute|
     |Sending messages to the same user or group|Maximum 5 calls/second|
-    **Note:** Messages cannot be pushed normally when exceeding limits, please use notification channels reasonably`, O = `---
+    **Note:** Messages cannot be pushed normally when exceeding limits, please use notification channels reasonably`, q = `---
 title: "Dingtalk Integration"
 description: "Integrate with Dingtalk custom application to receive and respond to alerts within Dingtalk"
 date: "2024-05-11T10:00:00+08:00"
@@ -4697,7 +4770,7 @@ After the application is released, you can access it via mobile/PC client. First
 |Enterprise|5,500,000|60|1st of each month|
 **Note:** Messages cannot be pushed normally after exceeding limits, please use notification channels reasonably
-`, q = `---
+`, O = `---
 title: "WeCom Integration"
 description: "Integrate WeCom third-party application to receive and respond to alerts within WeCom"
 date: "2024-05-11T10:00:00+08:00"
@@ -6164,7 +6237,7 @@ export {
   V as CustomAction,
   e as CustomAlert,
   W as CustomChange,
-  O as Dingtalk,
+  q as Dingtalk,
   L as Dynatrace,
   n as Email,
   F as GoogleCM,
@@ -6177,11 +6250,11 @@ export {
   _ as Jiankongbao,
   G as Jira,
   Y as Lark,
-  N as Meraki,
+  M as Meraki,
   j as MicrosoftTeams,
   t as N9e,
   C as OceanBase,
-  M as OpManager,
+  N as OpManager,
   m as OpenFalcon,
   f as PagerDuty,
   a as Prometheus,
@@ -6199,6 +6272,6 @@ export {
   D as VolcEngineEvent,
   E as VolcEngineMetric,
   P as VolcEngineTLS,
-  q as Wecom,
+  O as Wecom,
   o as Zabbix
 };

package/package.json CHANGED Viewed

@@ -1,6 +1,6 @@
 {
   "name": "flashduty-knowledge-base",
-  "version": "1.0.1",
+  "version": "1.0.2",
   "description": "flashduty knowledge base",
   "type": "module",
   "scripts": {