Elasticsearch：transform 例子

于 2022-10-28 13:32:19 发布
阅读量1.2k 收藏 2
点赞数 2
分类专栏： Elasticsearch Elastic 文章标签： elasticsearch 大数据 搜索引擎 运维 数据库
本文为博主原创文章，未经博主允许不得转载。
本文链接：https://blog.csdn.net/UbuntuTouch/article/details/127569190
版权
Elastic 同时被 2 个专栏收录
1495 篇文章 903 订阅
订阅专栏
Elasticsearch
1023 篇文章 596 订阅
订阅专栏

在今天的文章中，我将展示如何使用 transform 从数据中获得有用的见解。 所有示例都使用 Kibana 示例数据集之一。 有关更详细的分步示例，请参阅教程 “Elasticsearch：Transforms 介绍”。在今天的展示中，我将使用最新的 Elastic Stack 8.4.3 来进行展示。

准备数据

我们将使用 Kibana 中自带的数据 eCommerce，Flight 及 web logs 数据来进行展示：

 

这样，我们就加载了一个叫做  kibana_sample_data_ecommerce 的索引到 Elasticsearch 中了。

按照同样的方法，我们加载上面所示的 Sample flight data：

它生成一个叫做 kibana_sample_data_flights 的索引。

我也加载 Sample web logs 样本数据：

它将生成 kibana_sample_data_logs 索引数据。

寻找你最好的客户

此示例使用电子商务订单样本数据集来查找在假设的网上商店中花费最多的客户。 让我们使用 pivot 类型的转换，以便目标索引包含订单数量、订单总价、唯一产品数量和每个订单的平均价格，以及每个客户的订购产品总量。

我们进入到 transform 的界面：

 

  

 

 

 

 

按照上面的方法，我们把各个项逐个添加，最终我们可以看到如下的表格：

 

除了使用上面的 transform 界面之外，我们也可以使用 API 来完成。我们可以使用 preview transform 及 create transform API 来完成：

 

POST _transform/_preview
{
  "source": {
    "index": "kibana_sample_data_ecommerce"
  },
  "dest" : { 
    "index" : "sample_ecommerce_orders_by_customer"
  },
  "pivot": {
    "group_by": { 
      "user": { "terms": { "field": "user" }},
      "customer_id": { "terms": { "field": "customer_id" }}
    },
    "aggregations": {
      "order_count": { "value_count": { "field": "order_id" }},
      "total_order_amt": { "sum": { "field": "taxful_total_price" }},
      "avg_amt_per_order": { "avg": { "field": "taxful_total_price" }},
      "avg_unique_products_per_order": { "avg": { "field": "total_unique_products" }},
      "total_unique_products": { "cardinality": { "field": "products.product_id" }}
    }
  }
}

由于我们使用了 _preview，目标索引被忽略了。在上面，我们使用了两个 group_by 字段。这意味着转换包含每个 user 和 customer_id 组合的唯一行。 在这个数据集中，这两个字段都是唯一的。 通过将两者都包含在转换中，它为最终结果提供了更多上下文。

preview 转换 API 使你能够提前查看转换的布局，其中填充了一些示例值。 例如：

{
  "preview": [
    {
      "total_order_amt": 3946.9765625,
      "order_count": 59,
      "total_unique_products": 116,
      "avg_unique_products_per_order": 2,
      "customer_id": "10",
      "user": "recip",
      "avg_amt_per_order": 66.89790783898304
    },
    {
      "total_order_amt": 5196.6796875,
      "order_count": 75,
      "total_unique_products": 148,
      "avg_unique_products_per_order": 2,
      "customer_id": "11",
      "user": "fuzzy",
      "avg_amt_per_order": 69.2890625
    },
    {
      "total_order_amt": 9659.125,
      "order_count": 135,
      "total_unique_products": 266,
      "avg_unique_products_per_order": 2,
      "customer_id": "12",
      "user": "brigitte",
      "avg_amt_per_order": 71.54907407407407
    },
  ...
 ]
}

这种 transform 可以更轻松地回答以下问题：

  • 哪些客户花费最多？
  • 哪些客户在每个订单中花费最多？
  • 哪些客户最常订购？
  • 哪些客户订购的不同产品数量最少？

可以单独使用聚合来回答这些问题，但是 transform 允许我们将这些数据作为以客户为中心的索引进行持久化。 这使我们能够大规模分析数据，并为从以客户为中心的角度探索和导航数据提供更大的灵活性。 在某些情况下，它甚至可以使创建可视化变得更加简单。

寻找延误最多的航空公司

此示例使用航班示例数据集来找出延误最多的航空公司。 首先，使用查询过滤器过滤源数据，使其排除所有已取消的航班。 然后将数据转换为包含不同的航班数量、延误分钟数的总和以及航空承运人的飞行分钟数的总和。 最后，使用 bucket_script 确定实际延误的飞行时间百分比。

POST _transform/_preview
{
  "source": {
    "index": "kibana_sample_data_flights",
    "query": { 
      "bool": {
        "filter": [
          { "term":  { "Cancelled": false } }
        ]
      }
    }
  },
  "dest" : { 
    "index" : "sample_flight_delays_by_carrier"
  },
  "pivot": {
    "group_by": { 
      "carrier": { "terms": { "field": "Carrier" }}
    },
    "aggregations": {
      "flights_count": { "value_count": { "field": "FlightNum" }},
      "delay_mins_total": { "sum": { "field": "FlightDelayMin" }},
      "flight_mins_total": { "sum": { "field": "FlightTimeMin" }},
      "delay_time_percentage": { 
        "bucket_script": {
          "buckets_path": {
            "delay_time": "delay_mins_total.value",
            "flight_time": "flight_mins_total.value"
          },
          "script": "(params.delay_time / params.flight_time) * 100"
        }
      }
    }
  }
}

首先，过滤源数据以仅选择未取消的航班。目标索引被忽略，这是因为我们选择了 preview。数据按包含航空公司名称的 carrier 字段分组。此 bucket_script 对聚合返回的结果执行计算。 在这个特定示例中，它计算了延误占用的行程时间百分比。

预览显示，新索引将包含每个 carrier 的如下数据：

{
  "preview": [
    {
      "carrier": "ES-Air",
      "flights_count": 2802,
      "flight_mins_total": 1436927.5130677223,
      "delay_time_percentage": 9.335543983955839,
      "delay_mins_total": 134145
    },
    {
      "carrier": "JetBeats",
      "flights_count": 2833,
      "flight_mins_total": 1451143.6898144484,
      "delay_time_percentage": 8.937088787987832,
      "delay_mins_total": 129690
    },
    {
      "carrier": "Kibana Airlines",
      "flights_count": 2832,
      "flight_mins_total": 1419081.404241085,
      "delay_time_percentage": 9.088273556017194,
      "delay_mins_total": 128970
    },
   ...
  ]
}

这种转换可以更轻松地回答以下问题：

  • 哪个航空公司的延误占飞行时间的百分比最多？

查找可疑的客户端 IP

此示例使用 Web 日志示例数据集来识别可疑客户端 IP。 它转换数据，使新索引包含字节总和以及不同 URL、代理、按位置的传入请求以及每个客户端 IP 的地理目的地的数量。 它还使用过滤器聚合来计算每个客户端 IP 接收到的特定类型的 HTTP 响应。 最终，以下示例将 Web 日志数据转换为以实体为中心的索引，其中实体为 clientip。

PUT _transform/suspicious_client_ips
{
  "source": {
    "index": "kibana_sample_data_logs"
  },
  "dest" : { 
    "index" : "sample_weblogs_by_clientip"
  },
  "sync" : { 
    "time": {
      "field": "timestamp",
      "delay": "60s"
    }
  },
  "pivot": {
    "group_by": {  
      "clientip": { "terms": { "field": "clientip" } }
      },
    "aggregations": {
      "url_dc": { "cardinality": { "field": "url.keyword" }},
      "bytes_sum": { "sum": { "field": "bytes" }},
      "geo.src_dc": { "cardinality": { "field": "geo.src" }},
      "agent_dc": { "cardinality": { "field": "agent.keyword" }},
      "geo.dest_dc": { "cardinality": { "field": "geo.dest" }},
      "responses.total": { "value_count": { "field": "timestamp" }},
      "success" : { 
         "filter": {
            "term": { "response" : "200"}}
        },
      "error404" : {
         "filter": {
            "term": { "response" : "404"}}
        },
      "error5xx" : {
         "filter": {
            "range": { "response" : { "gte": 500, "lt": 600}}}
        },
      "timestamp.min": { "min": { "field": "timestamp" }},
      "timestamp.max": { "max": { "field": "timestamp" }},
      "timestamp.duration_ms": { 
        "bucket_script": {
          "buckets_path": {
            "min_time": "timestamp.min.value",
            "max_time": "timestamp.max.value"
          },
          "script": "(params.max_time - params.min_time)"
        }
      }
    }
  }
}

在这次练习中，我们没有使用 preview，而是直接生成相应的索引 sample_weblogs_by_clientip。在上面，我们使用了 sync 配置。它将转换配置为连续运行。 它使用时间戳字段来同步源索引和目标索引。 最坏情况下的摄取延迟为 60 秒。数据按 clientip 字段分组。filter 聚合，计算响应字段中成功 (200) 响应的出现次数。 以下两个聚合（error 404 和 error 5xx）按错误代码计算错误响应，匹配精确值或响应代码范围。这个 bucket_script 根据聚合的结果计算 clientip 访问的持续时间。

创建转换后，你必须启动它：

POST _transform/suspicious_client_ips/_start

不久之后，第一个结果应该在目标索引中可用：

GET sample_weblogs_by_clientip/_search

搜索结果显示每个客户端 IP 的数据如下：

{
  "took": 0,
  "timed_out": false,
  "_shards": {
    "total": 1,
    "successful": 1,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 1000,
      "relation": "eq"
    },
    "max_score": 1,
    "hits": [
      {
        "_index": "sample_weblogs_by_clientip",
        "_id": "MOeHH_cUL5urmartKj-b5UQAAAAAAAAA",
        "_score": 1,
        "_source": {
          "geo": {
            "src_dc": 1,
            "dest_dc": 2
          },
          "success": 2,
          "error404": 0,
          "clientip": "0.72.176.46",
          "agent_dc": 2,
          "bytes_sum": 4422,
          "responses": {
            "total": 2
          },
          "error5xx": 0,
          "url_dc": 2,
          "timestamp": {
            "duration_ms": 521916980,
            "min": "2022-10-17T07:51:57.333Z",
            "max": "2022-10-23T08:50:34.313Z"
          }
        }
      },
      {
        "_index": "sample_weblogs_by_clientip",
        "_id": "MGNzzFDYQ28eyzVadV_UHVUAAAAAAAAA",
        "_score": 1,
        "_source": {
          "geo": {
            "src_dc": 1,
            "dest_dc": 3
          },
          "success": 3,
          "error404": 0,
          "clientip": "0.207.229.147",
          "agent_dc": 3,
          "bytes_sum": 14174,
          "responses": {
            "total": 3
          },
          "error5xx": 0,
          "url_dc": 3,
          "timestamp": {
            "duration_ms": 694814737,
            "min": "2022-10-19T11:02:32.392Z",
            "max": "2022-10-27T12:02:47.129Z"
          }
        }
      },
  ...

注意：与其他 Kibana 示例数据集一样，Web 日志示例数据集包含相对于你安装它的时间戳，包括未来的时间戳。 连续变换将拾取过去的数据点。 如果你之前安装了 web 日志示例数据集，你可以卸载并重新安装它，时间戳会发生变化。

这种转换可以更轻松地回答以下问题：

  • 哪些客户端 IP 传输的数据量最多？
  • 哪些客户端 IP 与大量不同的 URL 交互？
  • 哪些客户端 IP 的错误率高？
  • 哪些客户端 IP 正在与大量目的地国家/地区进行交互？

查找每个 IP 地址的最后一个日志事件

此示例使用 Web 日志示例数据集从 IP 地址查找最后一个日志。 让我们在连续模式下使用 latest 类型的变换。 它将每个唯一键的最新文档从源索引复制到目标索引，并在新数据进入源索引时更新目标索引。

选择 clientip 字段作为唯一键； 数据按此字段分组。 选择时间戳作为按时间顺序对数据进行排序的日期字段。 对于连续模式，指定用于标识新文档的日期字段，以及检查源索引更改的时间间隔。

 

 

 

 

 

 

此转换创建包含每个客户端 IP 的最新登录日期的目标索引。 当转换以连续模式运行时，目标索引将更新为进入源索引的新数据。 

我们也可以使用 API 来完成：

PUT _transform/last-log-from-clientip
{
  "source": {
    "index": [
      "kibana_sample_data_logs"
    ]
  },
  "latest": {
    "unique_key": [ 
      "clientip"
    ],
    "sort": "timestamp" 
  },
  "frequency": "1m", 
  "dest": {
    "index": "last-log-from-clientip"
  },
  "sync": { 
    "time": {
      "field": "timestamp",
      "delay": "60s"
    }
  },
  "retention_policy": { 
    "time": {
      "field": "timestamp",
      "max_age": "30d"
    }
  },
  "settings": {
    "max_page_search_size": 500
  }
}

在上面，我们定义 clientip 字段来进行分组。我们定义 timestamp 字段来进行排序。我们使用 frequency 来定义检查 source 有没有变化的间隔。我们使用 sync 来定义 延迟的时间以保证 source 和 destination 进行同步。在上面，我们也定义了 retention_policy。早于配置值的文档将从目标索引中删除。

创建转换后，启动它：

POST _transform/last-log-from-clientip/_start

转换处理数据后，搜索目标索引：

GET last_log_event_for_each_ip/_search

搜索结果显示每个客户端 IP 的数据如下：

{
  "took": 1,
  "timed_out": false,
  "_shards": {
    "total": 1,
    "successful": 1,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": {
      "value": 1001,
      "relation": "eq"
    },
    "max_score": 1,
    "hits": [
      {
        "_index": "last_log_event_for_each_ip",
        "_id": "MOeHH_cUL5urmartKj-b5UQAAAAAAAAA",
        "_score": 1,
        "_source": {
          "referer": "http://twitter.com/error/don-lind",
          "request": "/elasticsearch",
          "agent": "Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)",
          "extension": "",
          "memory": null,
          "ip": "0.72.176.46",
          "index": "kibana_sample_data_logs",
          "message": "0.72.176.46 - - [2018-09-18T06:31:00.572Z] \"GET /elasticsearch HTTP/1.1\" 200 7065 \"-\" \"Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322)\"",
          "url": "https://www.elastic.co/downloads/elasticsearch",
          "tags": [
            "success",
            "info"
          ],
          "geo": {
            "srcdest": "US:PH",
            "src": "US",
            "coordinates": {
              "lon": -124.1127917,
              "lat": 40.80338889
            },
            "dest": "PH"
          },
          "utc_time": "2022-12-13T06:31:00.572Z",
          "bytes": 7065,
          "machine": {
            "os": "ios",
            "ram": 12884901888
          },
          "response": 200,
          "clientip": "0.72.176.46",
          "host": "www.elastic.co",
          "event": {
            "dataset": "sample_web_logs"
          },
          "phpmemory": null,
          "timestamp": "2022-12-13T06:31:00.572Z"
        }
      },
  ...

这种转换可以更轻松地回答以下问题：

  • 与特定 IP 地址关联的最新日志事件是什么？

查找向服务器发送最多字节的客户端 IP

此示例使用 Web 日志示例数据集来查找每小时向服务器发送的字节数最多的客户端 IP。 该示例使用带有 top_metrics 聚合的数据 pivot 变换。

按时间字段上的日期直方图（date histogram）对数据进行分组，间隔为一小时。 在字节字段上使用 max 聚合来获取发送到服务器的最大数据量。 如果没有 max 聚合，API 调用仍会返回发送最多字节的客户端 IP，但不会返回它发送的字节数。 在 top_metrics 属性中，指定 clientip 和 geo.src，然后按 bytes 字段降序对它们进行排序。 转换返回发送数据量最大的 client IP 和相应位置的 2 个字母的 ISO 代码。

POST _transform/_preview
{
  "source": {
    "index": "kibana_sample_data_logs"
  },
  "pivot": {
    "group_by": { 
      "timestamp": {
        "date_histogram": {
          "field": "timestamp",
          "fixed_interval": "1h"
        }
      }
    },
    "aggregations": {
      "bytes.max": { 
        "max": {
          "field": "bytes"
        }
      },
      "top": {
        "top_metrics": { 
          "metrics": [
            {
              "field": "clientip"
            },
            {
              "field": "geo.src"
            }
          ],
          "sort": {
            "bytes": "desc"
          }
        }
      }
    }
  }
}
  • 数据按时间字段的日期直方图分组，间隔为一小时。
  • 计算 bytes 字段的最大值。
  • 指定要返回的顶部文档的字段（clientip 和 geo.src）和排序方法（具有最高 bytes 值的文档）。

上面的 API 调用返回一个类似这样的响应：

{
  "preview" : [
    {
      "top" : {
        "clientip" : "223.87.60.27",
        "geo.src" : "IN"
      },
      "bytes" : {
        "max" : 6219
      },
      "timestamp" : "2021-04-25T00:00:00.000Z"
    },
    {
      "top" : {
        "clientip" : "99.74.118.237",
        "geo.src" : "LK"
      },
      "bytes" : {
        "max" : 14113
      },
      "timestamp" : "2021-04-25T03:00:00.000Z"
    },
    {
      "top" : {
        "clientip" : "218.148.135.12",
        "geo.src" : "BR"
      },
      "bytes" : {
        "max" : 4531
      },
      "timestamp" : "2021-04-25T04:00:00.000Z"
    },
    ...
  ]
}

通过客户 ID 获取客户姓名和电子邮件地址

本示例使用电子商务样本数据集创建基于客户 ID 的以实体为中心的索引，并使用 top_metrics 聚合获取客户姓名和电子邮件地址。

按 customer_id 对数据进行分组，然后添加一个 top_metrics 聚合，其中 metrics 是 email、customer_first_name.keyword 和 customer_last_name.keyword 字段。 按 order_date 以降序对 top_metrics 进行排序。 API 调用如下所示：

POST _transform/_preview
{
  "source": {
    "index": "kibana_sample_data_ecommerce"
  },
  "pivot": {
    "group_by": { 
      "customer_id": {
        "terms": {
          "field": "customer_id"
        }
      }
    },
    "aggregations": {
      "last": {
        "top_metrics": { 
          "metrics": [
            {
              "field": "email"
            },
            {
              "field": "customer_first_name.keyword"
            },
            {
              "field": "customer_last_name.keyword"
            }
          ],
          "sort": {
            "order_date": "desc"
          }
        }
      }
    }
  }
}

说明：

  • 数据按 customer_id 字段上的术语聚合进行分组。
  • 指定按订单日期降序返回的字段（电子邮件和姓名字段）。

API 返回类似于以下内容的响应：

{
  "preview" : [
    {
      "last" : {
        "customer_last_name.keyword" : "Long",
        "customer_first_name.keyword" : "Recip",
        "email" : "recip@long-family.zzz"
      },
      "customer_id" : "10"
    },
    {
      "last" : {
        "customer_last_name.keyword" : "Jackson",
        "customer_first_name.keyword" : "Fitzgerald",
        "email" : "fitzgerald@jackson-family.zzz"
      },
      "customer_id" : "11"
    },
    {
      "last" : {
        "customer_last_name.keyword" : "Cross",
        "customer_first_name.keyword" : "Brigitte",
        "email" : "brigitte@cross-family.zzz"
      },
      "customer_id" : "12"
    },
    ...
  ]
}
Elastic 中国社区官方博客
关注
专栏目录
博客
Elasticsearch 开放推理 API 新增阿里云 AI 搜索支持
09-19 1169
我们很高兴地宣布，Elasticsearch 开放推理 API 新增了阿里云 AI 搜索的集成功能。此项工作使 Elastic 用户能够直接连接到阿里云 AI 平台。使用 Elasticsearch 向量数据库构建 RAG 应用程序的开发人员可以使用 semantic_text 存储和使用托管在阿里云 AI 搜索平台上的模型生成的密集和稀疏嵌入。此外，Elastic 用户现在可以集成访问重新排名模型，以增强语义重新排名和LLM 系列。
博客
Elastic 线下 Meetup 将于 2024 年 9 月 21 号在成都举办
08-29 1629
2024 Elastic Meetup 成都站活动，由 Elastic、腾讯、新智锦绣联合举办，现诚邀广大技术爱好者及开发者参加。
博客
Elastic：如何成为一名 Elastic 认证工程师，Elastic 认证分析师及 Elastic 认证可观测性工程师
10-28 2万+
Elasticsearch 无疑是是目前世界上最为流行的大数据搜索引擎。根据 DB - Engines 的统计，Elasticsearch 雄踞排行榜第一名，并且市场还在不断地扩大：能够成为一名 Elastic 认证工程师也是很多开发者的梦想。这个代表了 Elastic 的最高认证，在业界也得到了很高的认知度。得到认证的工程师，必须除了具有丰富的 Elastic Stack 知识，而且必须有丰富的操作及有效的解决问题的能力。拥有这个认证证书，也代表了个人及公司的荣誉。针对个人的好处是，你可以..
博客
Elastic：开发者上手指南
02-25 15万+
你们好，我是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软件栈。他们三个共同形成了一个强大的...
博客
LangChain 和 Elasticsearch 加速构建 AI 检索代理
09-20 519
​Elastic 和 LangChain 很高兴地宣布发布新的 LangGraph 检索代理模板，旨在简化需要代理使用 Elasticsearch 进行代理检索的生成式人工智能 (GenAI) 代理应用程序的开发。此模板预先配置为使用 Elasticsearch，允许开发人员使用 LangChain 和 Elasticsearch 快速构建代理。要立即开始，请访问 github 上的项目：https://github.com/langchain-ai/retrieval-agent-template
博客
Elasticsearch：检索增强生成背后的重要思想
09-20 828
星期天晚上 10 点，我九年级的女儿哭着冲进我的房间。她说她对代数一无所知，注定要失败。我进入超级妈妈模式，却发现我一点高中数学知识都不记得了。于是，我做了任何一位超级妈妈在 2024 年都会做的事情，前往 ChatGPT 寻求帮助。这些生成式 AI 聊天机器人太棒了。我很快就得到了关于如何解决她所有问题的详细解释。“但是妈妈，”她抱怨道，“我们不是这样做的！”如果我能让 ChatGPT 的答案与班级的特定做事方式保持一致就好了……
博客
Elasticsearch：一次生产集群 ES Watcher 失效的深度排查与分析 - 全过程剖析与解决方案
09-19 947
Watcher是 Elasticsearch 提供的一项监控和告警服务，允许用户定义、管理警报规则，并持续跟踪网络和数据的变化。基于 Elasticsearch 的分布式架构，Watcher 可以对基础设施、索引数据、集群健康等多种指标进行实时监控和自动化告警。当预设条件被触发时，Watcher 会及时发送通知。这项功能特别适用于日志数据的监控、应用性能追踪，以及其他需要自动化响应的场景，帮助运维人员快速响应潜在问题，提升系统稳定性和可靠性。1）定时监控数据。
博客
Elastic 的 OpenTelemetry PHP 发行版简介
09-18 934
宣布 OpenTelemetry PHP 的 Elastic 发行版的第一个 alpha 版本。在本篇博文中了解使用 OpenTelemetry 来检测 PHP 应用程序是多么简单。我们很高兴推出 OpenTelemetry PHP 的 Elastic Distribution 的第一个 alpha 版本。在这篇文章中，你将了解如何轻松安装和设置 PHP 应用程序的监控。
博客
Elasticsearch：Open Crawler 现已进入测试阶段
09-18 1634
今天，我们发布了 Open Crawler 0.2 版，该版本也已升级为测试版！Open Crawler 最初于作为技术预览版发布（0.1 版）。从那时起，我们一直在迭代产品并添加了几个新功能。要访问这些更改，你可以使用最新的 Docker 工件，或直接从 GitHub 存储库下载源代码。按照我们文档中的设置说明开始使用。
博客
Observability：日志管理的最佳实践 - 利用日志更快地解决问题
09-17 1088
在当今快速发展的软件开发环境中，高效的日志管理对于维护系统可靠性和性能至关重要。随着基础架构和应用程序组件的不断扩展和复杂化，运营和开发团队的职责也不断增加且越来越复杂。这篇博文概述了有效日志管理的最佳实践，以应对数据量不断增长、基础架构复杂以及快速解决问题的需求等挑战。
博客
Kibana：如何使用魔法公式创建具有影响力的可视化效果？（第 1 部分）
09-16 857
在上一篇博文《作为非设计师设计直观的 Kibana 仪表板》中，我们强调了创建直观仪表板的重要性。它展示了简单的更改（分组主题、更改类型图表等）如何对理解数据产生影响。在提供Kibana 数据分析或课程等课程时，我们强调了这篇博文以及这些更改如何帮助将重要信息带到表面。我喜欢一种互补的方法来实现这一目标：使用两种颜色将最高数据值与常见数据值区分开来。为了说明这个想法，我们将使用示例航班数据数据集。现在，让我们比较两个可视化，按航班总数排名前 10 个目的地国家。哪个可视化的影响更大？
博客
Observability：OpenTelemetry Java Agent Elastic 分布正式发布
09-15 1330
Elastic 宣布 OpenTelemetry (OTel) Java Agent 的 Elastic 发行版正式发布，这是一个与 OTel 完全兼容的代理，具有一组丰富实用的附加功能。随着 Elastic 继续致力于 OpenTelemetry (OTel)，我们很高兴地宣布) 正式上市。
博客
了解 BSI IT Grundschutz：使用 GenAI 搜索你的（私人）PDF 宝藏的秘诀
09-14 1100
有没有想过如何让多年来收集的文档可以通过语义而不是关键字进行搜索？处理充满有价值信息的 PDF 可能具有挑战性，尤其是在分块和创建跨多种语言的可搜索数据时。这篇博文将指导你将文档集合转换为 AI 驱动的语义搜索系统。我们将探索 Elastic 如何为 RAG 提供端到端解决方案：提取 PDF、将其处理成块、向量化内容，并提供一个交互式游乐场来查询和与数据交互。探索如何让你的信息不仅更易于访问，而且真正具有对话性。你将能够测试如何轻松创建相关信息摘要，了解每个给出的答案的相关性分数，并最大限度地了解创建答
博客
用于安全研究的 Elastic Container Project
09-13 1251
​Elastic Stack 是一个模块化数据分析生态系统。虽然这允许工程灵活性，但建立开发实例进行测试可能很麻烦。建立 Elastic Stack 的最简单方法是使用 Elastic Cloud - 这是完全一站式的。但是，在某些情况下，Elastic Cloud 可能不适用于你的测试环境。为了帮助解决这个问题，本博客将为你提供必要的信息，以便快速轻松地建立本地、完全容器化、TLS 安全的 Elastic Stack，并启用 Fleet 和检测引擎。你将能够创建 Fleet 策略，在本地主机或 VM 上
博客
使用 Elastic 和 LM Studio 的 Herding Llama 3.1
09-13 1881
最新的 LM Studio 0.3 更新使 Elastic 的安全 AI Assistant 能够更轻松、更快速地与 LM Studio 托管模型一起运行。在这篇博客中，Elastic 和 LM Studio 团队将向你展示如何在几分钟内开始使用。如果你在同一网络上或在你的机器上本地工作，则不再需要设置代理。
博客
Elastic 线上 Meetup “Elastic 认证及 Watcher 使用分享” 将于 9 月 18 号举办
09-13 673
Elastic 线上 Meetup “Elastic 认证及 Watcher 使用分享” 将于 9 月 18 号举办
博客
Elasticsearch 开放 inference API 为 Hugging Face 添加了原生分块支持
09-13 1341
​借助 Elasticsearch 开放推理 API，你可以使用 Hugging Face 的推理端点（Inference Endpoints）在 Elasticsearch 之外执行推理。这样你就可以使用 Hugging Face 的可扩展基础架构，包括在 GPU 和 AI 加速器上执行推理的能力。使用 Hugging Face 生成的嵌入的能力是作为 Elasticsearch 8.11 中的第一个开放推理 API 集成引入的，从那时起，我们一直在努力工作，并使用更强大的功能对其进行了更新，让您可以事
博客
Elastic：如何将数据转化为可操作的见解？
09-12 783
可操作的洞察不仅仅是一个有趣的数据点或趋势。它是一条信息，可直接导致可以改善你的业务的具体实际行动。与可能告诉你发生了什么的原始数据不同，可操作的洞察可以帮助你了解事件发生的原因——更重要的是，你应该采取什么措施。它们弥合了数据分析和决策之间的差距，将数字转化为你的团队可以实施的明确步骤，以实现目标结果。例如，你的网站数据可能显示用户在完成购买之前不断放弃购物车。这是很好的信息 —— 但你如何处理它？当你深入挖掘以找出许多用户在支付过程中退出时，可操作的洞察就会出现。
评论 1
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

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

抵扣说明：

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

余额充值