Add process page fault metrics (minor/major) using getrusage on Linux
and Darwin
### Motivation:
Identifying memory pressure and unexpected latency caused by disk I/O is
critical for performance monitoring. Major page faults (which require
disk I/O) are a common cause of unexpected latency in applications.
Adding minor and major page fault metrics allows developers to monitor
these events, providing better visibility into memory access patterns
and application performance.
### Modifications:
- Updated `SystemMetricsMonitor+Linux.swift` to extract `ru_minflt`
(minor faults) and `ru_majflt` (major faults) from the existing
`getrusage(RUSAGE_SELF)` call.
- Updated `SystemMetricsMonitor+Darwin.swift` to include a new
`getrusage(RUSAGE_SELF)` call to extract `ru_minflt` and `ru_majflt`.
- Added `minorPageFaults` and `majorPageFaults` fields to the
`SystemMetricsMonitor.Data` structure.
- Created `process_page_faults_minor_total` and
`process_page_faults_major_total` as default labels in
`SystemMetricsMonitorConfiguration`.
- Updated test suites across both platforms to validate the new metrics
with dedicated cross-check tests.
### Result:
The system metrics monitor now automatically collects and exports two
new gauges (`process_page_faults_minor_total` and
`process_page_faults_major_total`), providing immediate visibility into
process-level memory page faults without requiring any configuration
changes for existing users.
Thanks @Renish-patel for helping and guidance
---------
Co-authored-by: Arumit Kumar <arumitkumar2004@gmail.com>
Co-authored-by: Renish Patel <renishpatel2482001@gmail.com>
Co-authored-by: Vladimir Kukushkin <kukushechkin@mac.com>
Refactor force unwraps to use `try #require` in Linux data provider
tests
### Motivation:
While looking through the test suites, I noticed that
`LinuxDataProviderTests.swift` was still using a pattern of doing an
`#expect(value != nil)` check followed by a force unwrap (`value!`). In
the new Swift Testing framework, the idiomatic and safer way to handle
optionals is by using `try #require()`. Force unwrapping risks crashing
the entire test runner with a fatal error, whereas `#require` gracefully
fails the individual test and provides a clear diagnostic message.
### Modifications:
- Replaced all `#expect(value != nil)` assertions and subsequent force
unwraps with `try #require(value)` in `LinuxDataProviderTests.swift`.
- Cleaned up the local variable assignments to be more concise.
### Result:
The Linux test suite is now safer, won't crash the test runner on
failure, and the code style is consistent with the
`DarwinDataProviderTests.swift` suite.
Thanks for letting me know about this during our review @brandongrubio
:)
Co-authored-by: Brandon Grubio <brandongrubio@gmail.com>
Fix `process_max_fds` on Linux to report the soft limit instead of the
hard limit.
### Motivation:
While looking at how the monitor works across different platforms, we
noticed an inconsistency in how the maximum file descriptors metric
(`process_max_fds`) is reported. On Darwin, the monitor correctly
fetches the soft limit (`rlim_cur`), which is the actual ceiling the
process will hit before things start failing. However, on Linux, it was
pulling the hard limit (`rlim_max`). This is pretty misleading because
the hard limit on Linux is often set super high or even unlimited, which
doesn't reflect the actual enforced limit for the application. The
Prometheus convention is also to report the soft limit for this metric.
### Modifications:
- Swapped out `_rlim.rlim_max` for `_rlim.rlim_cur` in
`SystemMetricsMonitor+Linux.swift` so it pulls the soft limit.
- Added cross-check tests for both Linux and Darwin to verify that
`maxFileDescriptors` actually matches the system's `rlim_cur`.
### Result:
The `process_max_fds` metric on Linux will now accurately report the
soft limit, making it consistent with the Darwin implementation and
standard Prometheus guidelines. You'll now see the actual number of
files your process is allowed to open, rather than a theoretical
ceiling.
Thanks to @Renish-patel for helping me writing tests
Co-authored-by: Renish-patel <renishpatel2482001@gmail.com>
Fix integer truncation in process start time to preserve sub-second
precision
### Motivation:
This PR fixes a bug where the `process_start_time_seconds` metric was
being calculated using integer division, causing the sub-second
fractional component of the start time to be silently truncated. This
resulted in the reported metric being inaccurate by up to ~1 second.
### Modifications:
- Updated the `SystemMetricsMonitor.Data` struct to store
`startTimeSeconds` as a `Double` instead of an `Int` to preserve
fractional seconds.
- Linux: Converted `startTimeTicks` and `clockTicksPerSecond` to
`Double` prior to division in `SystemMetricsMonitor+Linux.swift` to
prevent integer truncation.
- Darwin: Included the `pbi_start_tvusec` (microseconds) field from
`kinfo_proc` to properly calculate the fractional component in
`SystemMetricsMonitor+Darwin.swift`.
- Updated `DarwinDataProviderTests` to compare the `Double` start time
metric against the full sub-second timestamp provided by `sysctl`.
### Result:
This aligns the process start time precision with how CPU time is
currently computed and with Prometheus metric conventions.
Unify repos layout across the ecosystem:
1. Remove `CONTRIBUTORS.md` and mentions of it.
2. Remove `CODE_OF_CONDUCT.md` and mentions of it.
3. From `CONTRIBUTING.md` remove "Writing a Patch" and "Commit Message
Template" sections.
4. Remove `.mailmap` and mentions of it.
5. Remove `dev/git.commit.template` and mentions of it.
6. Remove `SECURITY.md`, if it is referenced somewhere, change it to
reference to the org security file
"https://github.com/apple/swift-log?tab=security-ov-file".
7. Remove copyright header from `Package.swift` and version-specific
package manifests.
8. Add SPI shields to the `README.md`.
9. Add "How to contribute your work" section in `CONTRIBUTING.md`.
10. Add "Add Automated release process" section in `CONTRIBUTING.md`.
Fix Linux open file descriptor count being inflated by 2 due to counting
"." and ".." directory entries
### Motivation:
The `linuxSystemMetrics()` function collects the number of open file
descriptors by enumerating the `/proc/self/fd` directory. The previous
implementation used a `readdir` loop that counted every entry in the
directory, which inadvertently included the `.` and `..` pseudo-entries.
This caused the reported metric to always be inflated by 2 above the
actual number of open file descriptors.
### Modifications:
- Updated `linuxSystemMetrics()` in `SystemMetricsMonitor+Linux.swift`
to check `d_name` and skip the `.` and `..` entries. This is done by
directly checking the bytes to avoid allocating a String for every
iteration.
- Added a new `openFileDescriptors()` test to
`LinuxDataProviderTests.swift` that mirrors the existing Darwin test by
verifying that opening `/dev/null` increases the open file descriptor
count by exactly 1.
### Result:
The `process_open_fds` metric on Linux will now accurately reflect the
exact number of file descriptors open by the process, aligning its
behavior with the Darwin implementation.
Use task-local metrics factory bootstrap in the example.
### Motivation:
`swift-metrics` now supports bootstrapping without the global state.
`swift-system-metrics` should have an up-to date example with all the
best practices.
### Modifications:
- Initialize `SystemMetricsMonitor` with a scoped task-local metrics
factory created by the `swift-otel`.
### Result:
`SystemMetricsMonitor` is initialized and operational without the global
metrics factory.
Prompt: Make dependabot set label
Claude output:
The file already has both changes applied:
- The schedule interval is already set to `"daily"`
- The label `"semver/none"` is already configured
No further changes needed — the dependabot.yml is already up to date.
Document the recommended way of customizing metric labels and dimensions
created by the Swift System Metrics.
### Motivation:
Swift System Metrics creates metric objects with specific labels. These
labels are in prometheus notation. To make Swift System Metrics
compatible with other metrics tools, we need a way to customize the
labels. Swift Metrics has recently received an updated with a metrics
factory providing a way to centrally adjust metric labels and dimensions
on the factory level.
### Modifications:
- The recommended way of customizing metric labels created by the Swift
System Metrics.
### Result:
Swift System Metrics users can customize system metric labels according
to the backend specs of their choice.
Motivation:
Swift 6.0 is no longer supported, we should bump the tools version and
remove it from our CI.
Modifications:
* Bump the Swift tools version to Swift 6.1
* Remove Swift 6.0 jobs where appropriate in main.yml, pull_request.yml
Result:
Code reflects our support window.
We need to gather some statistics on the flakiness of the simulators in
CI. This repo seems like a good candidate — the package is quite stable
and not that popular to raise questions.
Motivation:
Swift 6.3 has been released, we should add it to our CI coverage.
Modifications:
Add additional Swift 6.3 jobs where appropriate in main.yml,
pull_request.yml
Result:
Improved test coverage.
Add `threadCount` gauge w/ Linux and macOS implementations and
corresponding tests.
### Motivation:
Adds a `threadCount` gauge to track metrics for the number of threads in
the process.
### Modifications:
- Add macOS and Linux implementations of a `threadCount` gauge
- On macOS, uses `ProcessTaskInfo` API
- On Linux, uses `sysfs`
- Zombie threads are counted in both cases (reason: resources are in
use, and if not leaked those should be observer to decrement anyways,
soon matching what's "runnable", but if not, these alert of the leak)
- Adds tests, using XCTest to benefit from its default process isolation
(harder to test these with Swift Testing)
- Note that on macOS, tests don't reliably see resource clean-up without
even less reliable waits. So test gauge going up and down in Linux, but
only going up on macOS.
- Adds Grafana chart to the Example dashboard
### Result:
- Exports additional `threadCount` metric
### Testing:
```
$ swift-format lint -r --strict .
```
```
$ uname && xcrun swift test --enable-all-traits
Darwin
[...]
Test Suite 'swift-system-metricsPackageTests.xctest' started at 2026-02-23 19:12:57.942. Test Suite 'ThreadCountTests' started at 2026-02-23 19:12:57.942. Test Case '-[SystemMetricsTests.ThreadCountTests test_threadCount]' started. Test Case '-[SystemMetricsTests.ThreadCountTests test_threadCount]' passed (0.000 seconds). Test Suite 'ThreadCountTests' passed at 2026-02-23 19:12:57.943.
Executed 1 test, with 0 failures (0 unexpected) in 0.000 (0.001) seconds
Test Suite 'swift-system-metricsPackageTests.xctest' passed at 2026-02-23 19:12:57.943.
Executed 1 test, with 0 failures (0 unexpected) in 0.000 (0.001) seconds
Test Suite 'All tests' passed at 2026-02-23 19:12:57.943.
Executed 1 test, with 0 failures (0 unexpected) in 0.000 (0.001) seconds
◇ Test run started.
[...]
✔ Test run with 16 tests in 3 suites passed after 2.009 seconds.
```
```
$ uname && swift test --enable-all-traits
Linux
[...]
Test Suite 'debug.xctest' started at 2026-02-24 03:15:37.877 Test Suite 'ThreadCountTests' started at 2026-02-24 03:15:37.877 Test Case 'ThreadCountTests.test_threadCount' started at 2026-02-24 03:15:37.877 Test Case 'ThreadCountTests.test_threadCount' passed (0.018 seconds) Test Suite 'ThreadCountTests' passed at 2026-02-24 03:15:37.896
Executed 1 test, with 0 failures (0 unexpected) in 0.018 (0.018) seconds
Test Suite 'debug.xctest' passed at 2026-02-24 03:15:37.896
Executed 1 test, with 0 failures (0 unexpected) in 0.018 (0.018) seconds
Test Suite 'All tests' passed at 2026-02-24 03:15:37.896
Executed 1 test, with 0 failures (0 unexpected) in 0.018 (0.018) seconds
◇ Test run started.
[...]
✔ Test run with 13 tests in 3 suites passed after 1.269 seconds.
```
---------
Co-authored-by: Roberto Santos <ra_santos@apple.com>
### Motivation:
For better control over GitHub workflows, switch over to a tags-based
dependency.
### Modifications:
- Switch to tags
- Enable dependabot to get weekly update checks
### Result:
More streamlined and controlled GHA dependency updates.
Integrate swift-temporal-sdk's reusable auto-release workflow for
automated semantic versioning releases. Update CONTRIBUTING.md with a
link to the workflow documentation.
### Motivation
- Automate the release process using semantic versioning labels,
reducing manual overhead and ensuring consistent versioning across
releases.
### Modifications
- Add .github/workflows/auto-release.yml that uses swift-temporal-sdk's
reusable workflow
- Update CONTRIBUTING.md with automated release process documentation
linking to swift-temporal-sdk's workflow README
### Result
- When PRs are merged with semver labels (semver/patch, semver/minor),
the workflow automatically creates GitHub releases. Major releases
require manual creation.
### Test Plan
- Workflow will be validated after merge by labeling PRs with semver
labels and verifying that releases are created automatically.
Remove unsafe `-require-explicit-sendable` flag.
### Motivation:
Existence of the flag prevents the package tags from being used.
### Modifications:
The flag removed from the Package.swift.
### Result:
Package could be used with a tag.
### Motivation
The URL was wrong, it was copy-pasted from another repo and we didn't
update the URL.
### Modifications
Fix the URL.
### Result
Correct URL.
### Test Plan
N/A
### Motivation:
Pre-1.0 cleanup opportunity
### Modifications:
A bunch of small suggestions. They're for your consideration, so feel
free to tell me which ones to revert if needed.
### Result:
Repo ready for 1.0
Remove swift-system-metrics ServiceIntegration example name from the
example dashboard provisioning.
### Motivation:
With the specific service name hardcoded in the dashboard provisioning
config, it is not compatible with other projects where people might want
to just copy-paste this config. All other metrics (CPU%, fds) already
use values across all the reported dimensions.
### Modifications:
Removed `service_name="ServiceIntegrationExample"` filter from the
memory consumption dashboard visualization.
### Result:
Memory dashboard configuration no longer shows memory usage only for the
`ServiceIntegrationExample` service. Any project adopting
`SystemMetricsMonitor` can now copy-paste the config as-is and get the
Process System Metrics dashboard configured automatically in their
Grafana.
Fixes#82
### Motivation:
Most monitoring tools do not collect the data frequently, so there is no
need to update the gauges every 2 seconds if tools are collecting data
every 5-30-60 seconds. 15 seconds is a good middle ground.
### Modifications:
Default interval value and the corresponding docs are updated.
### Result:
With the default configuration, system metrics are collected every 15
seconds.
### Motivation:
Review of content against docs style guides for upcoming 1.0 release
### Modifications:
- adds in default docs curation for the public types and articles
- rework language for Apple style guide as well as active voice, present
tense, and American english spelling choices. Fixes some typos as well.
- shifting content into getting started, revising descriptions, removing
passive voice
- manually linking to metrics API (hosted at SPI)
Before:
```
--- Experimental coverage output enabled. ---
| Abstract | Curated | Code Listing
Types | 100% (2/2) | 50% (1/2) | 50% (1/2)
Members | 100% (6/6) | 0.0% (0/6) | 0.0% (0/6)
Globals | 100% (1/1) | 100% (1/1) | 100% (1/1)
```
After:
```
--- Experimental coverage output enabled. ---
| Abstract | Curated | Code Listing
Types | 100% (2/2) | 100% (2/2) | 50% (1/2)
Members | 100% (6/6) | 100% (6/6) | 0.0% (0/6)
Globals | 100% (1/1) | 100% (1/1) | 0.0% (0/1)
```
To quickly preview locally:
```
gh pr checkout 81
swift package add-dependency https://github.com/swiftlang/swift-docc-plugin --from 1.0.0
swift package --disable-sandbox preview-documentation --target SystemMetrics
```
ex:
<img width="1629" height="1105" alt="Screenshot 2026-01-07 at 4 22
33 PM"
src="https://github.com/user-attachments/assets/36304914-f859-4651-9034-b53d81d4b0c4"
/>
Biggest notable change that you we may not want to run with - I trimmed
down what was at the top level, shifting away from the format that
swift-configuration used, because that information felt overwhelming (it
felt like a giant README trying to shove too much in there), and moved
the getting started into a concise article that I curated inline.
I haven't added, but could, a quick walk through article with image
snapshots w/ `Examples/ServiceIntegration` to show setting it up and
seeing the metrics being reported in a local grafana instance, although
I think the README in that directory is already pretty darned good and
gets to the core for someone who just wants to see it work to get a
sense of what's included.
---------
Co-authored-by: Honza Dvorsky <honza@apple.com>
Rename the `swift-metrics-extras` package and repository to
`swift-system-metrics` to accurately represent its purpose.
### Motivation:
The package name `swift-metrics-extras` suggests a collection of various
metrics-related utilities, but the package contains only one component
collecting and reporting process system metrics. This creates confusion
for potential users and does not accurately describe the package's
purpose. A more descriptive name would make it easier for users to
discover and understand what the package does.
### Modifications:
- (outside of this PR) Repository is already renamed to
`[swift-system-metrics](https://github.com/apple/swift-system-metrics)`.
- References to the repo name is updated across the docs.
### Result:
- https://github.com/apple/swift-system-metrics exists.
- https://github.com/apple/swift-metrics-extras redirects to
https://github.com/apple/swift-system-metrics.
- Existing projects referencing Swift Metrics Extras keep working.
This branch adds a Darwin metrics provider, using macOS system APIs.
### Motivation:
Someone developing or deploying a service on macOS should be able to
take advantage of the same system metrics that are available to Swift
processes running on Linux. (#72)
### Modifications:
- Replaced the stub implementation for Darwin, which previously returned
`nil`
- Implemented unit tests for metrics like CPU time, resident memory, &
open file descriptors
### Result:
Feature parity between macOS and Linux for collecting system metrics.
---------
Co-authored-by: Vladimir Kukushkin <kukushechkin@mac.com>
Add Grafana integration with a provisioned Process System Metrics
dashboard to the Service Integration example.
### Motivation:
Process System Metrics collected and exported in this package ultimately
should be used in a monitoring dashboard. While it is common for
operates to be opinionated about the their dashboards, we also want to
help new users with observability adoption by providing an example
dashboard they can use as an inspiration or directly add to their
project.
### Modifications:
- OTel exporting is added to the `ServiceIntegration` example via
`swift-otel` package.
- A simple Grafana dashboard utilizing the metrics implemented by the
`SystemMetricsMonitor` added to the example.
- A docker-compose deployment added to the example.
### Result:
Users can deploy a sample Grafana dashboard with SystemMetricsMonitor
metrics and use it as an inspiration for creating monitoring for their
services.
<img width="1118" height="1042" alt="Screenshot 2025-12-17 at 17 38 23"
src="https://github.com/user-attachments/assets/584735c0-8823-4b5b-a609-1b8856ee3cc3"
/>
Build the Examples in CI.
### Motivation:
`swift-metrics-extras` now has an `Example/ServiceIntegration`, which
depends on the package, but is not verified in the CI.
### Modifications:
- `Scripts/test-examples.sh` added (inspired by the
[`swift-configuration/Scripts/test-examples.sh`](https://github.com/apple/swift-configuration/blob/main/Scripts/test-examples.sh),
but the structure is different and this one is more simple).
- `pull_request` and `main` workflows use shared
`apple/swift-nio/.github/workflows/swift_test_matrix.yml@main` to run
the script.
### Result:
`Example/ServiceIntegration` is being built in CI on Linux
Improve Linux metrics collection implementation comments
### Motivation:
Implementation details comments were not updated during the `rusage`
adoption for CPU usage metrics.
### Modifications:
Comments updated to accurately reflect the APIs used to collect Linux
metrics.
### Result:
Comments now accurately reflect the APIs used to collect Linux metrics.
Per [GitHub's
announcement](https://github.blog/changelog/2025-09-19-deprecation-of-node-20-on-github-actions-runners/),
Node 20 is being deprecated and runners will begin using Node 24 by
default starting March 4th, 2026.
### Motivation:
Upgrade GitHub Actions to their latest versions to ensure compatibility
with Node 24, as Node 20 will reach end-of-life in April 2026.
### Modifications:
`actions/checkout@v4` -> `actions/checkout@v6`
### Result:
Ready for Node 20 deprecation.
## Summary
Upgrade GitHub Actions to their latest versions to ensure compatibility
with Node 24, as Node 20 will reach end-of-life in April 2026.
## Changes
| Action | Old Version(s) | New Version | Release | Files |
|--------|---------------|-------------|---------|-------|
| `actions/checkout` |
[`v4`](https://github.com/actions/checkout/releases/tag/v4) |
[`v6`](https://github.com/actions/checkout/releases/tag/v6) |
[Release](https://github.com/actions/checkout/releases/tag/v6) |
pull_request_label.yml |
## Context
Per [GitHub's
announcement](https://github.blog/changelog/2025-09-19-deprecation-of-node-20-on-github-actions-runners/),
Node 20 is being deprecated and runners will begin using Node 24 by
default starting March 4th, 2026.
### Why this matters
- **Node 20 EOL**: April 2026
- **Node 24 default**: March 4th, 2026
- **Action**: Update to latest action versions that support Node 24
### Security Note
Actions that were previously pinned to commit SHAs remain pinned to SHAs
(updated to the latest release SHA) to maintain the security benefits of
immutable references.
### Testing
These changes only affect CI/CD workflow configurations and should not
impact application functionality. The workflows should be tested by
running them on a branch before merging.
Signed-off-by: Salman Muin Kayser Chishti <13schishti@gmail.com>
Introduce a proposal for renaming the package to better reflect its
purpose.
### Motivation:
The package name `swift-metrics-extras` suggests a collection of various
metrics-related utilities, but the package contains only one component
collecting and reporting process system metrics. This creates confusion
for potential users and does not accurately describe the package's
purpose. A more descriptive name would make it easier for users to
discover and understand what the package does.
### Modifications:
"SSM-0002: rename the package" proposal doc added
### Result:
A proposal document added.
Add static SDK CI workflow which runs on commits to PRs, merges to main
and daily on main.
---------
Co-authored-by: Vladimir Kukushkin <kukushechkin@mac.com>
Public API proposal doc and implementation.
### Motivation:
As part of the 1.0 release we would like to revise the public API to
simplify adoption and maintenance:
* Reduce public API to a minimum to make it easier to support more
platforms and metrics gathering strategies.
* Decouple `swift-metrics-extras` public interface from the global
`MetricsSystem`.
* Add compatibility with `swift-service-lifecycle`
### Modifications:
"SSM-0001: `swift-metrics-extras` revised public API to support 1.0
roadmap" proposal doc added
### Result:
A proposal doc added.
---------
Co-authored-by: Honza Dvorsky <honza@apple.com>
For non-trivial changes that affect the public API, the Swift Metrics
Extras project adopts a lightweight version of the [Swift
Evolution](https://github.com/apple/swift-evolution/blob/main/process.md)
process.
### Motivation:
Writing a proposal first helps discuss multiple possible solutions
early, apply useful feedback from other contributors, and avoid
reimplementing the same feature multiple times.
### Modifications:
"Proposals" topic and a proposal template added to the documentation.
### Result:
Proposals can now be submitted to the Swift Metrics Extras.
Migrating `swift-metrics-extras` from XCTest to Swift Testing
### Motivation
Swift Testing is a modern alternative to XCTest. Swift Server Ecosystem
packages should serve as reference implementations for modern Swift
features and best practices.
### Modifications
- Almost 1-to-1 migration of test suites, tests, and assertions to Swift
Testing syntax with XCTest import removed
### Result
Successfully executes 6 tests with `swift test --disable-xctest`.
Make Swift 6.0 the minimum support version.
### Motivation:
`swift-metrics-extras` supports 3 latest Swift releases, which is at
this point 6.0, 6.1 and 6.2. Swift 5 is no longer supported.
### Modifications:
- Package.swift swift tools
- CI configs
- Set package `.swiftLanguageMode` to `v5` as a migration to Swift 6
workaround
### Result:
Swift 5 is no longer supported.
Motivation:
Swift 5.9 is no longer supported, we should bump the tools version and
remove it from our CI.
Modifications:
* Bump the Swift tools version to Swift 5.10
* Remove Swift 5.9 jobs where appropriate in main.yml, pull_request.yml
Result:
Code reflects our support window.
add Sendable annotations and use withUnsafeTemporaryAllocation
### Motivation:
I'd like to use swift 6 mode without needing `@preconcurrency`.
While testing with swift 6.1 I noticed a warning about
`String(cString:)` being deprecated and saw an opportunity to use
[withUnsafeTemporaryAllocation](https://developer.apple.com/documentation/swift/withunsafetemporaryallocation(of:capacity:_:)).
### Modifications:
Sendable annotations fix warnings with swift 6 mode.
withUnsafeTemporaryAllocation simplifies part of the code and removes a
heap allocation
### Result:
code like this will compile in swift 6 mode without needing
`@preconcurrency`
```
extension SystemMetrics.Configuration {
/// `SystemMetrics.Configuration` with Prometheus style labels.
///
/// For more information see `SystemMetrics.Configuration`
public static let prometheus = SystemMetrics.Configuration(
labels: .init(
prefix: "process_",
virtualMemoryBytes: "virtual_memory_bytes",
residentMemoryBytes: "resident_memory_bytes",
startTimeSeconds: "start_time_seconds",
cpuSecondsTotal: "cpu_seconds_total",
maxFds: "max_fds",
openFds: "open_fds",
cpuUsage: "cpu_usage"
)
)
}
```
Ronit Sabhaya
Vladimir Kukushkin
dependabot[bot]
Rick Newton-Rogers
Roberto Adlich
Honza Dvorsky
Kohei Ota (inductor)
Joseph Heck
barrytomasini
Salman Chishti
Melissa Kilby
Raphael
Jason Toffaletti