Observability：使用 Elastic Agent 跟踪你的 Steam Deck 游戏
作者：来自 Elastic AndersonQ
让我们以不同的方式看待可观察性，并使用我们最喜欢的工具来监控我们的游戏性能。今天，我们将探讨如何使用 Elastic Agent 来监控 Steam Deck，以便我们可以看到我们玩得最多的游戏、它们消耗了多少资源以及 GPU 的表现如何。
我们将介绍：
- 安装 Elastic Agent
- 设置集成
- 使用自定义 API 集成来收集自定义数据
- 构建 Kibana 仪表板
- 导出和导入仪表板
处理数据
系统集成（System Integration）为我们提供了有关正在运行的进程、其名称以及它们使用的 CPU 和内存量的所有数据。我们将使用它来查看该过程使用了多少资源以及查看我们玩得最多的游戏。
GPU 数据
一般来说，可观测性数据不包括 CPU 或 GPU 核心的执行情况。虽然可以收集 NVIDIA GPU 数据，但 Steam Deck 使用定制的 AMD GPU，我们想自己亲自动手做一些工作。
Linux 发行版通常包含 lm_sensors，它存在于 Steam OS 上，为我们提供所需的所有信息。
在我的 Steam Deck 上运行 sensors，我得到以下结果：
nvme-pci-0100
Adapter: PCI adapter
Composite: +45.9°C (low = -273.1°C, high = +82.8°C)
(crit = +84.8°C)
Sensor 1: +45.9°C (low = -273.1°C, high = +65261.8°C)
BAT1-acpi-0
Adapter: ACPI interface
in0: 8.40 V
curr1: 1.74 A
amdgpu-pci-0400
Adapter: PCI adapter
vddgfx: 650.00 mV
vddnb: 655.00 mV
edge: +44.0°C
slowPPT: 7.12 W (avg = 11.10 W, cap = 15.00 W)
fastPPT: 11.10 W (cap = 15.00 W)
steamdeck_hwmon-isa-0000
Adapter: ISA adapter
PD Contract Voltage: 5.00 V
System Fan: 0 RPM
Battery Temp: +25.0°C
PD Contract Current: 1000.00 mA
acpitz-acpi-0
Adapter: ACPI interface
temp1: +54.0°C (crit = +105.0°C)我们所需要的一切都在那里，但是并不是以最佳格式来获取这些数据，让我们使用 sensors -j 获取一个JSON：
{
"nvme-pci-0100":{
"Adapter": "PCI adapter",
"Composite":{
"temp1_input": 31.850,
"temp1_max": 82.850,
"temp1_min": -273.150,
"temp1_crit": 84.850,
"temp1_alarm": 0.000
},
"Sensor 1":{
"temp2_input": 31.850,
"temp2_max": 65261.850,
"temp2_min": -273.150
}
},
"BAT1-acpi-0":{
"Adapter": "ACPI interface",
"in0":{
"in0_input": 8.656
},
"curr1":{
"curr1_input": 0.159
}
},
"amdgpu-pci-0400":{
"Adapter": "PCI adapter",
"vddgfx":{
"in0_input": 0.650
},
"vddnb":{
"in1_input": 0.655
},
"edge":{
"temp1_input": 41.000
},
"slowPPT":{
"power1_average": 2.072,
"power1_input": 2.040,
"power1_cap": 15.000
},
"fastPPT":{
"power2_average": 2.072,
"power2_cap": 15.000
}
},
"steamdeck_hwmon-isa-0000":{
"Adapter": "ISA adapter",
"PD Contract Voltage":{
"in0_input": 5.000
},
"System Fan":{
"fan1_input": 1522.000,
"fan1_fault": 0.000
},
"Battery Temp":{
"temp1_input": 25.000
},
"PD Contract Current":{
"curr1_input": 1.000
}
},
"acpitz-acpi-0":{
"Adapter": "ACPI interface",
"temp1":{
"temp1_input": 42.000,
"temp1_crit": 105.000
}
}
}我们不能让 Elastic Agent 运行任意命令并解析输出，因此，为了使这些数据可用，我们需要一个可以获取这些数据的小型 HTTP 服务器。
我已经用 Go 构建了一个，请继续前往 GitHub - AndersonQ/steamdeck-sensors-api 并安装它或构建你自己的版本。
通过该服务器，我们可以配置 Elastic Agent 来从我们刚刚创建的 API 中收集数据。为了确保它始终正常运行，steamdeck-sensors-api 可以安装并将自身注册为 systemd 服务。
现在我们已经拥有了所需的所有数据，让我们来收集它们。
收集数据
继续安装 Elastic Agent。默认情况下，System 集成被添加到任何 Elastic 代理策略中。继续创建一个策略，我将我的策略称为 Steam Deck，并将一个 Elastic Agent 添加到你的 Steam Deck。
查看常见问题解答，了解如何使用 sudo steamos-readonly disable 禁用只读模式。顺便问一下，你忘记了 sudo 密码吗？你可以轻松重置它，请在此处查看如何重置。
现在我们有了代理和策略，我们可以添加和配置自定义 API 集成。转到 Management > Integrations 并搜索 “custom api”：
将其添加到你的 Steam Deck 策略并进行配置：
- "Dataset name" 设置为
system.gpu - "Request URL":
http://localhost:4242/gpu - "Request Interval": ：30秒 - 如果你愿意，可以选择其他间隔时间。为了开始使用并测试可视化效果，我使用的是 1秒，这样可以实时看到新数据。
- "Request HTTP Method":
GET - "Processors":
- decode_json_fields:
fields: ["message"]
target: "system.gpu"
overwrite_keys: true
add_error_key: true
expand_keys: true
处理器对于正确格式化最终事件至关重要。如果没有它，steamdeck-sensors-api 响应将是 messsage 字段中的字符串。
现在保存并将集成添加到你的 Steam Deck 策略。如果你已经安装了代理，它将自动部署新更新的策略，如果你尚未安装，请去安装代理。
检查数据
转到发现，选择 metrics-* 数据视图。过滤 event.dataset :"system.process"。然后，添加 process.name、system.process.cpu.total.pct 和system.process.memory.size。在你的 Steam Deck 上打开一些游戏并尝试在所有 process metrics 中找到它。 🙂
对于 GPU 数据，请转到 logs-* 数据视图并过滤 event.dataset：“system.gpu”
现在我们只需要创建一个仪表板。
Steam Deck 仪表板
这是我创建的仪表板：
你可以直接导入我 GitHub 仓库里的这个仪表板，稍后我会告诉你如何导入。不过在此之前，我们先看看如何创建一个仪表板，并往里面添加一个可视化。
前往 Dashboards > Create dashboard
- 在查询栏中，添加一个过滤条件，仅显示来自你 Steam Deck 的数据。
过滤条件：host.hostname: "steamdeck"（如果你在设备上修改了主机名，请根据实际情况调整）。 - 点击 Create visualization
- 选择 metrics-* 数据视图
- 搜索 process.cpu
- 将 system.process.cpu.total.pct 拖到可视化区域
它会生成一个类似这样的图表：
接下来：
- 前往右侧的 Breakdown 面板
- 选择 process.name 作为分解维度
- 将 Number of values 设置为 15
- 关闭面板
然后，把可视化类型从 Bar 改为 Treemap
它应该是这样的：
接着，点击右上角的 Save and Return，将可视化保存到仪表板中。
这样，你的仪表板上就有一个展示 Steam Deck 上各个进程 CPU 使用情况的 Treemap 了！ 🎉
好的，现在我们来创建一个用于查看最常玩游戏的可视化。具体步骤如下：
-
点击 Create Visualization
-
在顶部搜索栏中，添加以下过滤条件：
process.working_directory.text: "/home/deck/.local/share/Steam/steamapps/common/*"这个过滤条件会将进程指标限定为工作目录在
/home/deck/.local/share/Steam/steamapps/common/*下的进程，这应该是你所有已安装游戏的路径。⚠️ 注意：
如果你的游戏安装在 SD 卡或其他位置，这个路径可能不同。
如果这个过滤条件没返回数据，你可以先到 Discover 里查看进程指标，找到游戏进程，确认它们实际使用的process.working_directory路径，然后再调整过滤条件。 -
将 process.name 拖到可视化的拖放区域
-
将可视化类型设置为 Tag cloud（标签云）
-
点击 “Top 5 values of process.name”，把 Number of Values 改成 15
-
关闭右侧的配置面板
-
点击 Save and Return
💡 在点击 “Save and Return” 之前，你应该看到一个显示最多15个游戏进程名称的标签云。
仪表板将如下所示：
要使用 GPU 数据构建可视化，请选择 logs-* 数据视图并过滤 event.dataset：“system.gpu”，如下所示：
好的！我会把其他可视化的创建留作练习 😉
导入和导出仪表板
你可以使用 Kibana Saved Objects API 来导入和导出仪表板，步骤如下：
curl -u USER:PASSWORD -X POST -H 'Content-Type: multipart/form-data' -H 'kbn-xsrf: true' YOUR-KIBANA-HOST/api/saved_objects/_import\?createNewCopies\=true --form file=@steam-deck-dashboard.ndjson获取要在此处导入的仪表板。
要导出仪表板，请使用
curl -u USER:PASSWORD -X POST -H 'Content-Type: application/json' -H 'kbn-xsrf: true' YOUR-KIBANA-HOST/api/saved_objects/_export \
-H "Content-Type: application/json; Elastic-Api-Version=2023-10-31" \
-H "kbn-xsrf: string" \
-d '{"objects":[{"id":"YOUR-DASHBOARD-ID","type":"dashboard"}],"excludeExportDetails":true,"includeReferencesDeep":true}' > steam-deck-dashboard.ndjson要查找仪表板 ID，请打开仪表板，检查 URL，它将是这样的：
https://KIBANA-HOST/app/dashboards#/view/<dashboard-id>?
https://KIBANA-HOST/app/dashboards#/view/bfcd09b3-effe-4a65-b58b-b6c3d528cc3e?结论
使用 Elastic Stack 监控我的 Steam Deck 非常有趣，可以深入了解其性能、游戏如何利用资源以及识别正在运行的程序和游戏二进制文件。
最重要的是，这是一种开始使用 Elastic Agent、提取监控数据以及创建可视化和仪表板的有趣方式。它还让我们了解到我们可以收集的大量数据，启发人们以不同的方式使用这些数据。微微一笑：
你可以在 Elastic Cloud 上免费试用，或者在 Docker 上轻松运行你自己的 Elastic Stack，或者下载并手动运行它。
现在你已经知道如何监控你的 Steam Deck 以及如何运行 Elastic Stack，为什么不自己尝试一下呢？
原文：Dec 5th, 2024: [EN] Keep track of your Steam Deck gaming with the Elastic Agent - Advent Calendar - Discuss the Elastic Stack