您将需要使用Azure Monitor。这是有用信息的链接： https://docs.microsoft.com/en-us/azure/azure-monitor/insights/container-insights-analyze

然后，您可以使用门户查询，或者如果要从门户中导出数据，请使用REST API：

https://docs.microsoft.com/en-us/azure/azure-monitor/platform/rest-api-walkthrough

这个问题已经很老了，但还是让我分享一下我是如何意识到它的：

Linux 有一个名为 RLIMIT_CORE 的内部设置，它限制了应用程序崩溃时您将收到的核心转储的大小 - 您很快就会发现这一点。

接下来，您必须定义保存核心文件的位置，这在文件 /proc/sys/kernel/core_pattern 中完成。给定的路径可以是一个相对文件名（保存在崩溃的二进制文件旁边），一个绝对路径（绝对安装的 namespace）或者 - 这里是有趣的地方 - 一个管道，后跟一个绝对路径到可执行文件（应用程序或脚本）。此脚本将 (according to the docs - see headline Piping core dumps to a program) 作为用户和组 root 启动 - 但此外，它还将 (according to this post in the Linux mailing list) 在全局命名空间中执行 - 换句话说，在容器之外。

如果您像我一样，并且无权访问用于 AKS 集群上的新节点的映像，您希望使用 DaemonSets（一个在每个节点上运行一次的 Pod）设置这些值。

掌握了所有这些知识，您可以执行以下操作：

1. 创建一个 DaemonSet - 在执行初始设置的每台机器上运行的 Pod。
2. 此 DaemonSet 将作为特权容器运行，以允许它切换到根命名空间。
3. 成功切换命名空间后，可以更改/proc/sys/kernel/core_pattern的值。
4. 该值应该类似于 |/bin/dd of=/core/%h.%e.%p.%t（dd 将获取核心文件 stdin，并将其保存到参数 of 定义的位置）。核心文件现在将保存在 /core/。文件名可以用 the docs for core files 中的变量解释。
5. 在知道文件将被保存到根命名空间的 /core/ 之后，我们可以在那里安装我们的存储 - 在我的例子中是 Azure File Storage。 Here's a tutorial of how to mount AzureFileStorage。
6. Pods have the RestartPolicy set to Always。由于 Pod 的工作已完成，并且您不希望它自动重启，因此使用 sleep infinity 让它保持运行。

这篇文章几乎是我在联系 Microsoft 支持时发现的内容的副本。 Here's the thread in their forum，其中包含几乎完成的 DaemonSet 配置。

我会在这里留下一些我在研究期间使用的链接：

• how to generate core file in docker container?
• How to access docker host filesystem from privileged container
• https://medium.com/@patnaikshekhar/initialize-your-aks-nodes-with-daemonsets-679fa81fd20e

旁注：

我也可以只将 AzureFileSystem 安装到每个容器中，并将 /proc/sys/kernel/core_pattern 的值设置为仅 /core/%h.%e.%p.%t，但这需要我提及每个容器上的安装。通过这种方式，我可以释放此管理任务的 pod 配置，并将其放在（在我看来）所属的地方，即初始机器设置。