Elasticsearch：一个关于 aggregation 的例子

于 2021-04-12 09:26:57 发布
阅读量1.6k 收藏 2
点赞数
分类专栏： Elastic Elasticsearch 文章标签： elasticsearch 大数据 数据库
本文为博主原创文章，未经博主允许不得转载。
本文链接：https://blog.csdn.net/UbuntuTouch/article/details/115611345
版权

今天的文章来自我一个国外同事的分享。通过这个例子，我们可以了解如何选择我们想要的聚合，排序，以及从 source 中提取字段。这个例子来源于一个需求，在 Elastic 有一个叫做 Contributor 的项目。鼓励大家来参加我们的社区分享。每次分享都会得到一个积分。在每个季度或者年度，我们会根据每个 Contributor 的积分进行排名，并得出最终的贡献奖。

这里有一个问题就是。参加这个活动的每个 Contributor 都会对应于一个独一无二的邮件地址，但是每次分享他的名字可能会有不同。在数据统计时，我们需要依据邮件地址而不是 Contributor 的名字来进行统计。

我们先来看一下如下的一个索引：

PUT scoreboard/_bulk?refresh
{"index":{}}
{ "score" : 1, "@timestamp" : "2021-02-28", "email":"peter@example.org", "name" : "Peter Parker"}
{"index":{}}
{ "score" : 4, "@timestamp" : "2021-02-01", "email":"peter@example.org", "name" : "Peter MiddleName Parker"}
{"index":{}}
{ "score" : 4, "@timestamp" : "2021-02-01", "email":"paul@example.org", "name" : "Paul Paulinson"}
{"index":{}}
{ "score" : 100, "@timestamp" : "2021-01-31", "email":"paul@example.org", "name" : "Paul Paulinson"}
{"index":{}}
{ "score" : 200, "@timestamp" : "2021-03-01", "email":"paul@example.org", "name" : "Paul Paulinson"}
{"index":{}}
{ "score" : 3, "@timestamp" : "2021-02-14", "email":"peter@otherexample.org", "name" : "Peter Parker"}
{"index":{}}
{ "score" : 1, "@timestamp" : "2021-02-28", "email":"other@example.org", "name" : "Someone Other"}
{"index":{}}
{ "score" : 1, "@timestamp" : "2021-02-28", "email":"other@example.org", "name" : "Someone Other"}
{"index":{}}
{ "score" : 1, "@timestamp" : "2021-02-26", "email":"other@example.org", "name" : "Someone Other 123"}
{"index":{}}
{ "score" : 1, "@timestamp" : "2021-02-01", "email":"other@example.org", "name" : "Someone Other 456"}

在上面的索引中，我们可以看到 scoreboard 是一个时序的索引。这是一个抽象处理的 Contributor 的索引。每个 Contributor 的邮件地址是唯一的，但是每次参加活动的名字可能有会有出入。这个好比有些活动，有人在一个场合喜欢用中文名字，而在另外一个场合可能喜欢用英文名字。在统计时，我们必须使用邮件地址来进行统计。我们的最终目的是找出其中的一个月的得分最高的  Contributor。我们的聚合要求：

  1. 限定于某个月
  2. 以邮件地址来进行统计
  3. 按照得分高低进行排列
  4. 最终的名字显示已最近活动一次活动的名字为准，不显示邮件地址（保密）

针对这样的要求，那么我们该如何进行聚合呢？

限定时间范围

我们可以通过 range query 来限定时间的范围：

GET scoreboard/_search
{
  "query": {
    "range": {
      "@timestamp": {
        "gte": "2021-02-01",
        "lt": "2021-03-01"
      }
    }
  }
}

通过上面的搜索，我们把时间的范围限定于 2021 年 2 月份。我们可以得到8个文档。

以邮件地址来进行聚合并统计分数

我们可以通过 terms aggregation 来针对邮件地址来进行统计，并使用 sum aggregation 来统计分数：

GET scoreboard/_search
{
  "size": 0, 
  "query": {
    "range": {
      "@timestamp": {
        "gte": "2021-02-01",
        "lt": "2021-03-01"
      }
    }
  },
  "aggs": {
    "by_user": {
      "terms": {
        "field": "email.keyword",
        "size": 10
      },
      "aggs": {
        "total": {
          "sum": {
            "field": "score"
          }
        }
      }
    }
  }
}

上面统计的结果是：

{
  "took" : 0,
  "timed_out" : false,
  "_shards" : {
    "total" : 1,
    "successful" : 1,
    "skipped" : 0,
    "failed" : 0
  },
  "hits" : {
    "total" : {
      "value" : 8,
      "relation" : "eq"
    },
    "max_score" : null,
    "hits" : [ ]
  },
  "aggregations" : {
    "by_user" : {
      "doc_count_error_upper_bound" : 0,
      "sum_other_doc_count" : 0,
      "buckets" : [
        {
          "key" : "other@example.org",
          "doc_count" : 4,
          "total" : {
            "value" : 4.0
          }
        },
        {
          "key" : "peter@example.org",
          "doc_count" : 2,
          "total" : {
            "value" : 5.0
          }
        },
        {
          "key" : "paul@example.org",
          "doc_count" : 1,
          "total" : {
            "value" : 4.0
          }
        },
        {
          "key" : "peter@otherexample.org",
          "doc_count" : 1,
          "total" : {
            "value" : 3.0
          }
        }
      ]
    }
  }
}

从上面的结果中，我们可以看出来每个邮件地址的统计结果，但是它并没有帮我们进行排序。我们可以依据 total 的结果来进行排序。我们需要更进一步做如下的修改：

GET scoreboard/_search
{
  "size": 0, 
  "query": {
    "range": {
      "@timestamp": {
        "gte": "2021-02-01",
        "lt": "2021-03-01"
      }
    }
  },
  "aggs": {
    "by_user": {
      "terms": {
        "field": "email.keyword",
        "size": 10,
        "order": {
          "total.value": "desc"
        }
      },
      "aggs": {
        "total": {
          "sum": {
            "field": "score"
          }
        }
      }
    }
  }
}

在上面，我添加了 order 的部分。运行上面的查询：

{
  "took" : 1,
  "timed_out" : false,
  "_shards" : {
    "total" : 1,
    "successful" : 1,
    "skipped" : 0,
    "failed" : 0
  },
  "hits" : {
    "total" : {
      "value" : 8,
      "relation" : "eq"
    },
    "max_score" : null,
    "hits" : [ ]
  },
  "aggregations" : {
    "by_user" : {
      "doc_count_error_upper_bound" : 0,
      "sum_other_doc_count" : 0,
      "buckets" : [
        {
          "key" : "peter@example.org",
          "doc_count" : 2,
          "total" : {
            "value" : 5.0
          }
        },
        {
          "key" : "other@example.org",
          "doc_count" : 4,
          "total" : {
            "value" : 4.0
          }
        },
        {
          "key" : "paul@example.org",
          "doc_count" : 1,
          "total" : {
            "value" : 4.0
          }
        },
        {
          "key" : "peter@otherexample.org",
          "doc_count" : 1,
          "total" : {
            "value" : 3.0
          }
        }
      ]
    }
  }
}

这一次，我们可以看到分数是从上到下的排列。

获取 Contributor 的名字

在上面的结果中，它显示了每个人的邮件地址。这个可不好！我们希望显示的是每个 Contributor 的名字。我们需要使用到 top_hits 聚合。并且我们希望得到的是他最近一次使用的名字为准。

GET scoreboard/_search
{
  "size": 0,
  "query": {
    "range": {
      "@timestamp": {
        "gte": "2021-02-01",
        "lt": "2021-03-01"
      }
    }
  },
  "aggs": {
    "by_user": {
      "terms": {
        "field": "email.keyword",
        "size": 10,
        "order": {
          "total.value": "desc"
        }
      },
      "aggs": {
        "total": {
          "sum": {
            "field": "score"
          }
        },
        "top_hits_name": {
          "top_hits": {
            "size": 1,
            "sort": [
              {
                "@timestamp": {
                  "order": "desc"
                }
              }
            ]
          }
        }
      }
    }
  }
}

在上面，我们添加了 top_hits 聚合，并按照时间的顺序进行排序。显示的结果为：

  "aggregations" : {
    "by_user" : {
      "doc_count_error_upper_bound" : 0,
      "sum_other_doc_count" : 0,
      "buckets" : [
        {
          "key" : "peter@example.org",
          "doc_count" : 2,
          "total" : {
            "value" : 5.0
          },
          "top_hits_name" : {
            "hits" : {
              "total" : {
                "value" : 2,
                "relation" : "eq"
              },
              "max_score" : null,
              "hits" : [
                {
                  "_index" : "scoreboard",
                  "_type" : "_doc",
                  "_id" : "1nSCw3gBI6xucLpoqrCy",
                  "_score" : null,
                  "_source" : {
                    "score" : 1,
                    "@timestamp" : "2021-02-28",
                    "email" : "peter@example.org",
                    "name" : "Peter Parker"
                  },
                  "sort" : [
                    1614470400000
                  ]
                }
              ]
            }
          }
        },
    ...

在上面，它显示了 Contributor 的名字，但是在 _source 里含有我们不想要的字段，比如 @timestamp 以及 email。我们可以通过如下的方式来限制这些字段：

GET scoreboard/_search
{
  "size": 0,
  "query": {
    "range": {
      "@timestamp": {
        "gte": "2021-02-01",
        "lt": "2021-03-01"
      }
    }
  },
  "aggs": {
    "by_user": {
      "terms": {
        "field": "email.keyword",
        "size": 10,
        "order": {
          "total.value": "desc"
        }
      },
      "aggs": {
        "total": {
          "sum": {
            "field": "score"
          }
        },
        "top_hits_name": {
          "top_hits": {
            "size": 1,
            "sort": [
              {
                "@timestamp": {
                  "order": "desc"
                }
              }
            ],
            "_source": {
              "includes": "name"
            }
          }
        }
      }
    }
  }
}

在上面，我们使用了 includes 来选择 name，而其它的字段我们并不感兴趣：

  "aggregations" : {
    "by_user" : {
      "doc_count_error_upper_bound" : 0,
      "sum_other_doc_count" : 0,
      "buckets" : [
        {
          "key" : "peter@example.org",
          "doc_count" : 2,
          "total" : {
            "value" : 5.0
          },
          "top_hits_name" : {
            "hits" : {
              "total" : {
                "value" : 2,
                "relation" : "eq"
              },
              "max_score" : null,
              "hits" : [
                {
                  "_index" : "scoreboard",
                  "_type" : "_doc",
                  "_id" : "1nSCw3gBI6xucLpoqrCy",
                  "_score" : null,
                  "_source" : {
                    "name" : "Peter Parker"
                  },
                  "sort" : [
                    1614470400000
                  ]
                }
              ]
            }
          }
        }
     ...

到目前为止，我们已经完成了我们想要的功能。我们通过 top_hits 获得每个 Contributor 的名字。但是这种方法是不是最优的呢？毕竟 top_hits 需要去读取每个 source。

进一步思考

为了找出来 Contributor 的名字，我们可以使用 terms aggregator，并以 @timestamp 来进行排序：

GET scoreboard/_search
{
  "size": 0,
  "query": {
    "range": {
      "@timestamp": {
        "gte": "2021-02-01",
        "lt": "2021-03-01"
      }
    }
  },
  "aggs": {
    "by_user": {
      "terms": {
        "field": "email.keyword",
        "size": 10,
        "order": {
          "total.value": "desc"
        }
      },
      "aggs": {
        "total": {
          "sum": {
            "field": "score"
          }
        },
        "name": {
          "terms": {
            "field": "name.keyword",
            "size": 1,
            "order": {
              "latest.value": "desc"
            }
          },
          "aggs": {
            "latest": {
              "max": {
                "field": "@timestamp"
              }
            }
          }
        }
      }
    }
  }
}

在上面，我们使用了 max aggregation 来获取每个 terms 桶里最大的一个时间，并按照这个时间进行排序。

上面显示的结果为：

{
  "took" : 1,
  "timed_out" : false,
  "_shards" : {
    "total" : 1,
    "successful" : 1,
    "skipped" : 0,
    "failed" : 0
  },
  "hits" : {
    "total" : {
      "value" : 8,
      "relation" : "eq"
    },
    "max_score" : null,
    "hits" : [ ]
  },
  "aggregations" : {
    "by_user" : {
      "doc_count_error_upper_bound" : 0,
      "sum_other_doc_count" : 0,
      "buckets" : [
        {
          "key" : "peter@example.org",
          "doc_count" : 2,
          "total" : {
            "value" : 5.0
          },
          "name" : {
            "doc_count_error_upper_bound" : 0,
            "sum_other_doc_count" : 1,
            "buckets" : [
              {
                "key" : "Peter Parker",
                "doc_count" : 1,
                "latest" : {
                  "value" : 1.6144704E12,
                  "value_as_string" : "2021-02-28T00:00:00.000Z"
                }
              }
            ]
          }
        },
        {
          "key" : "other@example.org",
          "doc_count" : 4,
          "total" : {
            "value" : 4.0
          },
          "name" : {
            "doc_count_error_upper_bound" : 0,
            "sum_other_doc_count" : 2,
            "buckets" : [
              {
                "key" : "Someone Other",
                "doc_count" : 2,
                "latest" : {
                  "value" : 1.6144704E12,
                  "value_as_string" : "2021-02-28T00:00:00.000Z"
                }
              }
            ]
          }
        },
        {
          "key" : "paul@example.org",
          "doc_count" : 1,
          "total" : {
            "value" : 4.0
          },
          "name" : {
            "doc_count_error_upper_bound" : 0,
            "sum_other_doc_count" : 0,
            "buckets" : [
              {
                "key" : "Paul Paulinson",
                "doc_count" : 1,
                "latest" : {
                  "value" : 1.6121376E12,
                  "value_as_string" : "2021-02-01T00:00:00.000Z"
                }
              }
            ]
          }
        },
        {
          "key" : "peter@otherexample.org",
          "doc_count" : 1,
          "total" : {
            "value" : 3.0
          },
          "name" : {
            "doc_count_error_upper_bound" : 0,
            "sum_other_doc_count" : 0,
            "buckets" : [
              {
                "key" : "Peter Parker",
                "doc_count" : 1,
                "latest" : {
                  "value" : 1.6132608E12,
                  "value_as_string" : "2021-02-14T00:00:00.000Z"
                }
              }
            ]
          }
        }
      ]
    }
  }
}

博客
Elasticsearch：没有 “AG” 的 RAG？
04-30 1291
了解如何利用语义搜索和 ELSER 构建一个强大且视觉上吸引人的问答体验，而无需使用 LLMs。想要获得 Elastic 认证？查看下一期的时间！Elasticsearch 拥有众多新功能，帮助你为你的用例构建最佳搜索解决方案。深入学习我们的，了解更多信息，开始，或立即在上尝试 Elastic。你可能听说过（Retrieval Augmented Generation - 检索增强生成），这是一种将你自己的文档与 LLM 结合，以生成类人回答的常用策略。
博客
Elastic：如何成为一名 Elastic 认证工程师，Elastic 认证分析师及 Elastic 认证可观测性工程师
10-28 2万+
Elasticsearch 无疑是是目前世界上最为流行的大数据搜索引擎。根据 DB - Engines 的统计，Elasticsearch 雄踞排行榜第一名，并且市场还在不断地扩大：能够成为一名 Elastic 认证工程师也是很多开发者的梦想。这个代表了 Elastic 的最高认证，在业界也得到了很高的认知度。得到认证的工程师，必须除了具有丰富的 Elastic Stack 知识，而且必须有丰富的操作及有效的解决问题的能力。拥有这个认证证书，也代表了个人及公司的荣誉。针对个人的好处是，你可以..
博客
Elastic：开发者上手指南
02-25 16万+
你们好，我是Elastic的刘晓国。如果大家想开始学习Elastic的话，那么这里将是你理想的学习园地。在我的博客几乎涵盖了你想学习的许多方面。在这里，我来讲述一下作为一个菜鸟该如何阅读我的这些博客文章。我们可以按照如下的步骤来学习：1)Elasticsearch简介：对Elasticsearch做了一个简单的介绍2)Elasticsearch中的一些重要概念:cluster,n..........................................................
博客
Elastic：培训视频 - ​在生产环境中配置 Fleet Server 和 Elastic Agent 之间的安全
01-06 1万+
在这篇文章中，我将会把我写的有些内容录制成视频，供大家参考。希望对大家有所帮助。优酷的视频频道地址在这里。Elastic 简介及Elastic Stack 安装：优酷，腾讯 Elastic Stack docker 部署：优酷，腾讯 Elasticsearch中的一些重要概念（Cluster/Shards/Replica/Document/Type/Index）：优酷，腾讯 开始使用El...............
博客
Elasticsearch 简介
08-08 17万+
Elasticsearch是一个非常强大的搜索引擎。它目前被广泛地使用于各个IT公司。Elasticsearch是由Elastic公司创建并开源维护的。它的开源代码位于https://github.com/elastic/elasticsearch。同时，Elastic公司也拥有Logstash及Kibana开源项目。这个三个开源项目组合在一起，就形成了 ELK软件栈。他们三个共同形成了一个强大的...
博客
在 Elastic 中使用 JOIN 进行威胁狩猎！
05-01 980
LOOKUP JOIN 在许多安全工作流中已经证明了其极大的实用性，但这只是开始。如Elasticsearch 博客中所述，这种类型的连接最接近于 SQL 风格的 LEFT OUTER JOIN，除了改善整体用户体验外，我们还计划扩展连接功能（例如 INNER 连接）。此外，这项功能还使其他搜索语言的语法转换成为可能。请阅读我们最近的博客，了解更多有关自动迁移的信息！总结一下，这种新的连接功能是安全分析师工具箱中的另一个工具，Elastic 搜索 AI 技术提供了许多先进的技术来保护您的数据免受攻击。
博客
Elasticsearch 根据两个字段搜索
05-01 840
探索通过两个字段进行搜索的技术，包括 multi-match 查询、bool 查询和查询时字段加权。想要获得 Elastic 认证？查看下一期的时间！Elasticsearch 拥有众多新功能，帮助你为你的用例构建最佳搜索解决方案。深入学习我们的，了解更多信息，开始，或立即在上尝试 Elastic。在 Elasticsearch 中跨多个字段进行搜索是许多应用中的常见需求。
博客
Elastic Security 8.18 和 9.0 中的新功能
04-30 658
Elastic Security 8.18 和 9.0 带来了帮助安全运营团队更高效工作、快速响应威胁的更新。此版本包括为 Splunk SIEM 用户提供的迁移支持、新的 ES|QL Lookup Join 功能，简化数据丰富和分析，以及多个可用性改进。攻击发现和自动导入现在已正式发布（GA），并且对 Elastic AI Assistant 的改进以及对自定义检测规则的支持也已加入。
博客
Elasticsearch 在 Google Axion 处理器（C4A）上的运行速度提升高达 40%
04-30 435
Elastic 与 Google Cloud 合作，在 C4A 上实现比上一代虚拟机更高的索引吞吐量。这篇文章将介绍我们在 Google Cloud 的 Google Axion 处理器上对 Elasticsearch 进行宏基准测试的结果。，旨在提供更高的性能和效率。我们正在与 Google Cloud 合作，寻找机会为我们的共同客户持续提供最佳体验。我们很高兴地确认，基于 Google Axion 处理器的虚拟机实例系列将帮助我们实现这一目标。
博客
Elasticsearch：一家全球银行如何将搜索引擎转变为其数据支柱
04-30 834
BBVA 通过使用 Elastic 将超过 450 亿个数据点统一到 50 多个银行服务中，实现了客户体验和运营洞察的转型，并实现了亚秒级响应时间。当 BBVA 的 David Jiménez Ausin 回顾 2014 年时，他看到的是一个截然不同的银行业景观。“几乎一切都还通过网页渠道，因为 [银行] 应用程序并不像现在这么成熟，而且每个服务的资讯都存在各自的系统中，” 他回忆道。作为服务于。
博客
Elasticsearch：ES|QL lookup JOIN 介绍 - 8.18/9.0
04-29 1200
​ES|QL LOOKUP JOIN 处理命令将你的 ES|QL 查询结果表中的数据与指定的查找索引中的匹配记录合并。它根据联接字段中的匹配值，将查找索引中的字段作为新列添加到结果表中。团队常常将数据分散在多个索引中，例如日志、IP、用户 ID、主机、员工等。如果没有直接的方式来丰富或关联每个事件与参考数据，那么根本原因分析、安全检查和操作洞察将变得耗时。
博客
Elasticsearch 内存使用指南
04-29 1044
探索 Elasticsearch 的内存需求以及不同类型的内存统计信息。Elasticsearch 拥有丰富的新功能，帮助你为你的使用场景构建最佳搜索解决方案。浏览我们的了解更多信息，开始，或者现在就在上体验 Elastic。
博客
Elastic Platform 8.18 和 9.0：ES|QL Lookup Joins 功能现已推出，Lucene 10！
04-28 1290
Elastic 最新发布的 8.18 和 9.0 版本包含了强大的更新，将显著提升你的体验、增强查询性能并优化日志管理。无论你是在处理搜索、可观察性还是安全用例，本次发布都带来了大量新特性，旨在提高工作流效率并解锁新的可能性。在这篇博客中，我们将按主要主题分解 Elasticsearch 和 Kibana 的关键更新：ES|QL 改进Elasticsearch logsdb 索引模式优化搜索和索引增强Kibana 用户体验升级Lucene 性能提升。
博客
Elastic Observability 9.0/8.18：EDOT 现已正式发布，支持 LLM observability ，以及更多功能
04-28 999
Elastic Observability 9.0/8.18 宣布了几项关键功能：1）​Elastic Distributions of OpenTelemetry （ EDOT ）正式发布 2）​面向 GenAI 应用的 LLM observability 3）对 Logstash 的性能和安全性改进、Elastic Agent 对 AWS EKS 的支持，以及 Discover 的增强。​
博客
Elasticsearch 9.0 和 8.18：为开发者精心打造，带来更快速的 BBQ 体验 — 比 OpenSearch 快 5 倍
04-28 779
我们很高兴向 Elastic Cloud 和自托管用户发布 Elasticsearch 9.0 和 8.18 版本。这些版本中的功能已经向我们的 Elastic Cloud Serverless 用户，他们可以使用在 AWS、和上提供的完全托管的 Elasticsearch。
博客
Elastic Cloud Serverless 现在在 Google Cloud 上正式发布
04-28 1042
Elastic Cloud Serverless 提供了启动和扩展安全、可观察性和搜索解决方案的最快方式 — 无需管理基础设施。今天，我们很高兴宣布 Elastic Cloud Serverless 在 Google Cloud 上正式发布 — 现在已在爱荷华（us-central1）区域提供。Elastic Cloud Serverless 提供了启动和扩展可观察性、安全性和搜索解决方案的最快方式，无需管理基础设施。它基于业界首个。
博客
Elastic Security 简化了预构建 SIEM 检测规则的自定义
04-28 874
自定义和更新预构建 SIEM 检测规则变得更简单了，提升了精准度，扩大了覆盖范围，并节省了时间。使用 Elastic Security，定制和更新预构建检测规则变得前所未有的简单。我们简化了检测工程工作流程，并通过开箱即用的 SIEM 检测规则实现了更广泛的用例覆盖。提供了 1,300 多条由专家编写的检测规则，这些规则映射到中的战术、技术和程序（TTPs）。我们的研究工程师积极维护和优化这些规则，每两周发布一次更新，帮助你在不断演变的威胁面前保持领先，而无需手动维护的负担。
博客
使用 LangGraph 和 Elasticsearch 构建强大的 RAG 工作流
04-26 1233
在这篇博客中，我们将向你展示如何配置和自定义 LangGraph Retrieval Agent 模板与 Elasticsearch，以构建一个强大的 RAG 工作流，实现高效的数据检索和由 AI 驱动的响应。本博客重点介绍如何使用 LangGraph Studio 和 LangGraph CLI 运行并自定义 LangChain Retrieval Agent Template。该模板为构建检索增强生成（RAG）应用提供了框架，并支持多种检索后端，如 Elasticsearch。
博客
更智能的银行体验：生成式 AI 与语义搜索的实际应用
04-25 795
了解 Elastic 与生成式 AI 如何正在改变银行业务，从个性化服务到具备上下文感知的搜索以及更智能的客户支持。在上，Elastic 的首席解决方案架构师 Tim Brophy 解释了。该会议讨论了四个关键挑战：让交易搜索真正为客户服务提升聊天机器人交互，利用实时知识提供个性化客户推荐提高运营效率Brophy 解释道：“生成式 AI 不仅仅是提高效率，它还代表着创新和更深层次的客户互动。
博客
检测特权访问活动：一个新的 Kibana 集成
04-25 1114
特权访问活动是指由具有高权限的用户（如系统管理员或服务账户）执行的操作。这些用户可以修改系统配置、访问敏感数据、管理用户角色、安装软件、更改安全策略，并直接与关键控制系统进行交互。传统的安全措施依赖于预定义的规则和特征签名，但这些方法往往无法检测出新型或复杂的攻击模式。由于特权用户会执行各种管理任务，区分正常操作和可疑行为是一个挑战。特权访问检测包通过机器学习建立用户和实体的行为基线，从而检测出偏离正常使用模式的异常行为。目前，该包主要关注来自合法账户的异常特权访问活动，例如基于管理员的事件和命令。
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值